Wolfgang requested:
Can you please re-send this question in form of a (suggested / potential) patch? That would be much more readable.
Sorry for the delay - traveling over the weekend...
============================================= --- ../cvs/u-boot_1.1.1/net/net.c 2004-07-02 04:45:14.000000000 -0700 +++ ./u-boot_1.1.1/net/net.c 2004-10-25 05:59:54.000000000 -0700 @@ -1241,7 +1241,7 @@ case ARPOP_REPLY: /* arp reply */ /* are we waiting for a reply */ if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC) - break; + return; #ifdef ET_DEBUG printf("Got ARP REPLY, set server/gtwy eth addr (%02x:%02x:%02x:%02x:%02x:%02x)\n", arp->ar_data[0], arp->ar_data[1], @@ -1276,7 +1276,7 @@ #endif return; } - + break; case PROT_RARP: #ifdef ET_DEBUG puts ("Got RARP\n"); =======================================================
This will fix the issue described previously, where:
1. u-boot initiates a tftp transfer 2. u-boot sets a flag "NetArpWaitPacketMAC = 1" 3. u-boot sends ARP Request on network to find the MAC address of tftp server 4. server is a little slow, and u-boot has not yet received the ARP so, u-boot sends ARP Request on network to find the MAC address of tftp server 5. tftp server responds back to first request with it's MAC address, and u-boot sees this, and accepts it. 6. u-boot sets the flag "NetArpWaitPacketMAC = 0" as it got the ARP reply 7. tftp server responds back to second request with it's MAC address, and u-boot sees this, and accepts it.
At this point as u-boot is not waiting (NetArpWaitPacketMAC is 0) for ARP reply breaks out of the switch that handles ARP reply. But this break is not to return from the complete handler and thus falls into RARP handler code.
8. u-boot prints out "invalid RARP header".