[U-Boot-Users] ethact, ethprim and NET_MULTI
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
--- 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
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
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
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
--- 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
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@denx.de EMACS belongs in <sys/errno.h>: Editor too big!
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
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
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@denx.de You cannot propel yourself forward by patting yourself on the back.
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
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@denx.de The amount of time between slipping on the peel and landing on the pavement is precisely 1 bananosecond.
participants (4)
-
Ben Warren -
Vadim Bendebury -
vb -
Wolfgang Denk