[U-Boot-Users] ethact, ethprim and NET_MULTI

[U-Boot-Users] ethact, ethprim and NET_MULTI

[vb]

Greetings,

I am trying to bring up a system with two ethernet interfaces, and
don't seem to be able to understand the intended behavior of the
multiinterface system.

Say when one tries pinging over an interface which is down, u-boot
starts browsing over registered ethernet interfaces, making the next
one in the list active and so on. So, after the ping attempt the
current interface value could change.

Is this really what is required - changing the active interface with
the user unaware of it?

What are the semantics of the environment variables "ethprim" and
"ethact"?.I tried to look through the documentation, and found
nothing.

Any help would be highly appreciated,

Regards,
/vb

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Ben Warren]

--- vb <vb@vsbe.com> wrote:

> Greetings,
> 
> I am trying to bring up a system with two ethernet
> interfaces, and
> don't seem to be able to understand the intended
> behavior of the
> multiinterface system.
> 
> Say when one tries pinging over an interface which
> is down, u-boot
> starts browsing over registered ethernet interfaces,
> making the next
> one in the list active and so on. So, after the ping
> attempt the
> current interface value could change.
> 
> Is this really what is required - changing the
> active interface with
> the user unaware of it?
> 
This is how it works.  The user is hardly unaware,
though.

> What are the semantics of the environment variables
> "ethprim" and
> "ethact"?.I tried to look through the documentation,
> and found
> nothing.
> 
'ethprime' lets you specify which interface to try
first.  'ethact' points to the interface that is
currently active.  It is modified by the Ethernet
driver and you should only touch it if you want to
override for some reason.

regards,
Ben

[U-Boot-Users] ethact, ethprim and NET_MULTI

[vb]

Ben,

thank you for a quick reply.

It is still very puzzling to me: unless I'm missing something, the
only place where this environment variable is referenced is
net/eth,c:eth_initialize().

So, each time one tries any operation requiring network
communications, the active interface may change for some inappropriate
reason - say one tried pinging with the cable not in the socket, or
the host being pinged down.

What is the rationale behind this moving active interface at any
(quite possibly non intentional) disturbance?

Regards,
/vb

On 3/8/07, Ben Warren <bwarren@qstreams.com> wrote:
>
> --- vb <vb@vsbe.com> wrote:
>
> > Greetings,
> >
> > I am trying to bring up a system with two ethernet
> > interfaces, and
> > don't seem to be able to understand the intended
> > behavior of the
> > multiinterface system.
> >
> > Say when one tries pinging over an interface which
> > is down, u-boot
> > starts browsing over registered ethernet interfaces,
> > making the next
> > one in the list active and so on. So, after the ping
> > attempt the
> > current interface value could change.
> >
> > Is this really what is required - changing the
> > active interface with
> > the user unaware of it?
> >
> This is how it works.  The user is hardly unaware,
> though.
>
> > What are the semantics of the environment variables
> > "ethprim" and
> > "ethact"?.I tried to look through the documentation,
> > and found
> > nothing.
> >
> 'ethprime' lets you specify which interface to try
> first.  'ethact' points to the interface that is
> currently active.  It is modified by the Ethernet
> driver and you should only touch it if you want to
> override for some reason.
>
> regards,
> Ben
>

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Ben Warren]

vb,

--- vb <vb@vsbe.com> wrote:


> It is still very puzzling to me: unless I'm missing
> something, the
> only place where this environment variable is
> referenced is
> net/eth,c:eth_initialize().

Correct
> 
> So, each time one tries any operation requiring
> network
> communications, the active interface may change for
> some inappropriate
> reason - say one tried pinging with the cable not in
> the socket, or
> the host being pinged down.
> 
Also correct
> What is the rationale behind this moving active
> interface at any
> (quite possibly non intentional) disturbance?

Well, I can't speak to the author's original
intentions.  You've probably noticed that the TCP/IP
capabilities of U-boot are very limited.  A board has
a single address which is not bound to a specific
interface.

I expect that the most common use for Ethernet
connectivity is TFTP.  I guess it's assumed that you
have things cabled properly, and if not, you don't
care which interface is used to get your image.

What's the downside?  A 10-second timeout?

regards,
Ben

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Wolfgang Denk]

In message <917337.93885.qm@web302.biz.mail.mud.yahoo.com> you wrote:
> 
> > What is the rationale behind this moving active
> > interface at any
> > (quite possibly non intentional) disturbance?
> 
> Well, I can't speak to the author's original
> intentions.  You've probably noticed that the TCP/IP
> capabilities of U-boot are very limited.  A board has
> a single address which is not bound to a specific
> interface.

I'm not  sure  what  you  mean  by  "single  address".  Each  network
interface  has  it's  own  MAC  address,  which  often  is  mapped to
different IP addresses (note that this is not  a  requirement  -  all
interfaces could use the same IP address, too).

> I expect that the most common use for Ethernet
> connectivity is TFTP.  I guess it's assumed that you
> have things cabled properly, and if not, you don't
> care which interface is used to get your image.

The intention is to provide support  for  redundant  network  connec-
tions.  In  a  system with sevral interfaces you will be able to boot
over the network even if one cablke breaks  or  one  TFTP  server  is
down. The chosen timeout is a compromise between ebing long enough to
allow for tempoorary network glitches and being short enough to allow
for a reasonable fast boot in case of network problems on the primary
/ current interface.

Note that the timeout is adjustable.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
EMACS belongs in <sys/errno.h>: Editor too big!

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Ben Warren]

--- Wolfgang Denk <wd@denx.de> wrote:
> 
> I'm not  sure  what  you  mean  by  "single 
> address".  Each  network
> interface  has  it's  own  MAC  address,  which 
> often  is  mapped to
> different IP addresses (note that this is not  a 
> requirement  -  all
> interfaces could use the same IP address, too).
> 
Of course every MAC has its own address.  I was
referring to IP addresses.  I've probably missed
something, but I don't see a mechanism for
provisioning IP addresses on a per-interface basis.  I
don't see the need for that either...

regards,
Ben

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Vadim Bendebury]

Sorry, Wolfgang, I missed your reply before sending an email on
another thread. Anyway, the thing is that quite often different
interfaces are connected to different subnets and switching interfaces
is completely useless.

IMHO it should be possible to disable this "autoswitch" behavior.

cheers,
vadim


On 3/8/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <917337.93885.qm@web302.biz.mail.mud.yahoo.com> you wrote:
> >
> > > What is the rationale behind this moving active
> > > interface at any
> > > (quite possibly non intentional) disturbance?
> >
> > Well, I can't speak to the author's original
> > intentions.  You've probably noticed that the TCP/IP
> > capabilities of U-boot are very limited.  A board has
> > a single address which is not bound to a specific
> > interface.
>
> I'm not  sure  what  you  mean  by  "single  address".  Each  network
> interface  has  it's  own  MAC  address,  which  often  is  mapped to
> different IP addresses (note that this is not  a  requirement  -  all
> interfaces could use the same IP address, too).
>
> > I expect that the most common use for Ethernet
> > connectivity is TFTP.  I guess it's assumed that you
> > have things cabled properly, and if not, you don't
> > care which interface is used to get your image.
>
> The intention is to provide support  for  redundant  network  connec-
> tions.  In  a  system with sevral interfaces you will be able to boot
> over the network even if one cablke breaks  or  one  TFTP  server  is
> down. The chosen timeout is a compromise between ebing long enough to
> allow for tempoorary network glitches and being short enough to allow
> for a reasonable fast boot in case of network problems on the primary
> / current interface.
>
> Note that the timeout is adjustable.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> EMACS belongs in <sys/errno.h>: Editor too big!
>

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Ben Warren]

On Fri, 2007-03-09 at 09:01 -0800, Vadim Bendebury wrote:
> Sorry, Wolfgang, I missed your reply before sending an email on
> another thread. Anyway, the thing is that quite often different
> interfaces are connected to different subnets and switching interfaces
> is completely useless.
> 
> IMHO it should be possible to disable this "autoswitch" behavior.
> 
> cheers,
> vadim
> 
Send a patch and it will be considered.

Ben

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Wolfgang Denk]

In message <f608b67d0703090901m49143780i2638379fec23920d@mail.gmail.com> you wrote:
> Sorry, Wolfgang, I missed your reply before sending an email on
> another thread. Anyway, the thing is that quite often different
> interfaces are connected to different subnets and switching interfaces

Yes, this is exactly the intended use. You connect  different  inter-
faces  to  different networks to provide redundant ethernet capabili-
ties.

> is completely useless.

Redundancy is useless? Maybe for you. Others pay alot of money for it.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You cannot propel yourself forward by patting yourself on the back.

[U-Boot-Users] ethact, ethprim and NET_MULTI

[vb]

On 3/9/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <f608b67d0703090901m49143780i2638379fec23920d@mail.gmail.com> you wrote:
> > Sorry, Wolfgang, I missed your reply before sending an email on
> > another thread. Anyway, the thing is that quite often different
> > interfaces are connected to different subnets and switching interfaces
>
> Yes, this is exactly the intended use. You connect  different  inter-
> faces  to  different networks to provide redundant ethernet capabili-
> ties.
>
> > is completely useless.
>
> Redundancy is useless? Maybe for you. Others pay alot of money for it.
>

Hey Wolfgang, let's not get personal here, it's just business :-)

I appreciate your point, *in certain setups* it is quite advantageous
to be able to try using a different interface.

But in some other setups (let's say there is a system with a
controller with two interfaces - once serving the external port, and
another one serving the backplane) it is completely pointless to try
to say tftpboot off any other interface but the external port.

cheers,
vadim
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> You cannot propel yourself forward by patting yourself on the back.
>

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Wolfgang Denk]

In message <f608b67d0703090925v1714b02cm78ea07f8a8090ec2@mail.gmail.com> you wrote:
>
> > Redundancy is useless? Maybe for you. Others pay alot of money for it.
> 
> Hey Wolfgang, let's not get personal here, it's just business :-)

I did not intend to get personal. I just tried to explicate my
position.

> I appreciate your point, *in certain setups* it is quite advantageous
> to be able to try using a different interface.

And I agree that in certain setups it may be not beneficial, but on
the other hand I don't see why it would be harmful there.

> But in some other setups (let's say there is a system with a
> controller with two interfaces - once serving the external port, and
> another one serving the backplane) it is completely pointless to try
> to say tftpboot off any other interface but the external port.

OK. So when does it hurt you? You define ethprime  such  that  U-Boot
will  start  using  the  correct  interface. If you command U-Boot to
perform a network download it will try doing this, using the  correct
interface.  If  your  network  and  your  servers  are  OK, this will
succeed. Fine. If your network connection or your servers  have  some
temporary  glitches,  this  should  be  handled gracefully by U-Boots
retry mechanism. So this situation is handled on, too. Only  if  your
network  connection  and/or  your  servers are inoperative for a long
time then U-Boot will try and switch interfaces, which will not  help
in  your  setup.  But  then  -  what  sort of damage is done? If your
network resp. server did not work for such a long time as the  U-Boot
timeout,  then  chances  that they would start working after this are
not exactly high. Continueing to try loading from  the  non-operative
interface  is  not much better that trying to download from the other
interface which does not work either. So what do you lose?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The amount of time between slipping on the peel and  landing  on  the
pavement is precisely 1 bananosecond.

[U-Boot-Users] ethact, ethprim and NET_MULTI

[vb]

Wolfgang,

what happens if all interfaces are failing - does it come back to
ethprime after trying them all and stops or does it keep trying until
stopped by the operator with an arbitrary interface as the current
one?

That seemed to have happened to me: I tried using an interface, it did
not work, I went to see what happened, turned out the hub was down,
but after I brought the hub back online the thing still didn't work -
why - another interface became "current"!

Also, in some situations it is harmful to expose internal IP addresses
on an external network - but u-boot would never have a second though
about it :-)

cheers,
vadim



On 3/9/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <f608b67d0703090925v1714b02cm78ea07f8a8090ec2@mail.gmail.com> you wrote:
> >
> > > Redundancy is useless? Maybe for you. Others pay alot of money for it.
> >
> > Hey Wolfgang, let's not get personal here, it's just business :-)
>
> I did not intend to get personal. I just tried to explicate my
> position.
>
> > I appreciate your point, *in certain setups* it is quite advantageous
> > to be able to try using a different interface.
>
> And I agree that in certain setups it may be not beneficial, but on
> the other hand I don't see why it would be harmful there.
>
> > But in some other setups (let's say there is a system with a
> > controller with two interfaces - once serving the external port, and
> > another one serving the backplane) it is completely pointless to try
> > to say tftpboot off any other interface but the external port.
>
> OK. So when does it hurt you? You define ethprime  such  that  U-Boot
> will  start  using  the  correct  interface. If you command U-Boot to
> perform a network download it will try doing this, using the  correct
> interface.  If  your  network  and  your  servers  are  OK, this will
> succeed. Fine. If your network connection or your servers  have  some
> temporary  glitches,  this  should  be  handled gracefully by U-Boots
> retry mechanism. So this situation is handled on, too. Only  if  your
> network  connection  and/or  your  servers are inoperative for a long
> time then U-Boot will try and switch interfaces, which will not  help
> in  your  setup.  But  then  -  what  sort of damage is done? If your
> network resp. server did not work for such a long time as the  U-Boot
> timeout,  then  chances  that they would start working after this are
> not exactly high. Continueing to try loading from  the  non-operative
> interface  is  not much better that trying to download from the other
> interface which does not work either. So what do you lose?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> The amount of time between slipping on the peel and  landing  on  the
> pavement is precisely 1 bananosecond.
>

[U-Boot-Users] ethact, ethprim and NET_MULTI

[Wolfgang Denk]

In message <f608b67d0703091448m3d109ebeyc5c3165d506d6a33@mail.gmail.com> you wrote:
> 
> what happens if all interfaces are failing - does it come back to
> ethprime after trying them all and stops or does it keep trying until
> stopped by the operator with an arbitrary interface as the current
> one?

It continues cycling through the configured interfaces.

> That seemed to have happened to me: I tried using an interface, it did
> not work, I went to see what happened, turned out the hub was down,
> but after I brought the hub back online the thing still didn't work -
> why - another interface became "current"!

If you had waited for the second inteface to time out you would have
seen that U-Boot re-tried the first one which then should have worked.

> Also, in some situations it is harmful to expose internal IP addresses
> on an external network - but u-boot would never have a second though
> about it :-)

It would not even have a first thought, as U-Boot never "exposes" any
IP addresses if you use appropriate protocols like DHCP or BOOTP. All
it "exposes" is it's MAC address.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I like your game but we have to change the rules."