Wolfgang Denk wrote:
Why does your server do that? It just TALKED with 192.168.0.2, so it should really be able to remember which MAC address it used to send the ICMP replies to.
The server is a stock 2.6.4 kernel (SuSe 9.1) - so I think that the issue might be wide spread. I will ask on the LKML why it does this.
Why should U-Boot respond? It has completed it's network task, and shut down the network driver. It does not even attempt to receive any packets from the network any more.
OK - this is more of a development issue than anything I guess - most people will not be having U-boot sit on their network for days on end, like I do now. I would be interested in understanding based on the lists usage - how many people use u-boot to load a kernel, vs just use it to run a standalone application as shown in the examples directory.
For U-Boot this is a S.E.P. (Somebody Else's Problem).
Yeah - my problem as soon as the network admin figures out what is going on, and tells me I can't have U-boot plugged into the network. :( There is so much ARP/RARP traffic that the subnet performance is about 1/10 of what it should be. So far the only person complaining was me, and now I will stop.
U-Boot does not care about this (and there is no reason why it should).
I agree (almost) - it is a development issue that is only a problem during bring up and testing of U-boot. There is no reason to change production level code to fix a development issue.
Thanks -Robin