[U-Boot-Users] question about net/net.c

[Robin Getz]

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".