[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Foreword:  As Wolfgang noted, Robin's emails apparently are being 
discarded by Sourceforge.  I'm dual-subscribed - home and work - and 
only received emails from Robin on the email that was directly addressed 
to me.

Robin Getz wrote:
> On Fri 11 Jul 2008 14:52, Jerry Van Baren pondered:
>> Ben Warren wrote:
>>> Robin Getz wrote:
>>>> I was trying out U-Boot 1.1.3 with a new(er) router netgear WGR614v6 - 
>>>> firmware version V2.0.19_1.0.19NA, on a Blackfin BF537-STAMP.
>>>>
>>>> http://kbserver.netgear.com/products/wgr614v6.asp
>>>>
>>>> and found that dhcp fails :( 
>>>> bfin> dhcp
>>>> BOOTP broadcast 1
>>>> BOOTP broadcast 2
>>>> BOOTP broadcast 3
>>>> BOOTP broadcast 4
>>>> BOOTP broadcast 5
>>>>
>>>> Retry count exceeded; starting again
>>>>
>>>> When turning on some more verbose debug messages (in the net driver & in 
> the 
>>>> network code, not all of which exists in U-Boot release or trunk), we can 
> see 
>>>> exactly what is going on...
>>>>
>>>> =============================
>> First DHCP request...
>>
>>>> bfin> dhcp
>>>> Eth_halt: ......
>>>> Eth_init: ......
>>>> BOOTP broadcast 1
>>>> setting transaction ID to 3268fe22
>>>> BFIN EMAC send: length = 343
>>>> BFIN EMAC rx: length = 552
>>>> packet received
>>>> packet received
>>>> Receive from protocol 0x800
>>>> Got IP
>>>> len=308, v=45
>>>> passing packet len= 280
>>>> DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3
>>>> Filtering pkt = 0
>>>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3
>>>> DHCP: state=SELECTING bp_file: ""
>>>> TRANSITIONING TO REQUESTING STATE
>>>> IP was: 0.0.0.0
>>>> IP now: 192.168.0.9
>> ...worked.
> 
> No - the DCHP server offered an address, When U-Boot does a DHCPREQUEST 
> (confirming it can have that address) it gets a DHCP NAK.

Right.  My confusion.

>>>> Bootfile:
>>>> DhcpSendRequestPkt: Sending DHCPREQUEST
>> Why is the second DHCP request being sent? 
> 
> This is not a 2nd DHCP request being sent. This is part of the DHCP protocol.

Right.  My confusion.

>> What is the second DHCP  
>> request asking for (sniff the net with wireshark). 
> 
> I can send you the wireshark file, but it is exactly as I described.
> 
> http://www.ietf.org/rfc/rfc1533.txt
> 
> Client sends DHCPDISCOVER
> server sends DHCPOFFER
> Client sends DHCPREQUEST
> Server sends ARP
> Client responds to ARP before it should
> Server sends DHCPNAK, because someone on the network is using the IP number 
> (and doesn't bother to check the MAC - and notice that is the machine that it 
> just gave the IP number to).
> Clients tosses the offer info (it did get NAKed), and starts over.

RFC-1533 is "DHCP Options and BOOTP Vendor Extensions".  RFC-2131 
"Dynamic Host Configuration Protocol" appears to be the right RFC.

The above sequence is somewhat odd and I would contend that it should be 
classified as a DHCP server bug.  Quoting from RFC-2131:

-------------------------------------------------------------------------
2.2 Dynamic allocation of network addresses

[snip]

As a consistency check, the allocating server SHOULD probe the reused 
address *before* allocating the address, e.g., with an ICMP echo 
request, and the client SHOULD probe the newly received address, e.g., 
with ARP.
-------------------------------------------------------------------------

My emphasis on the word *before*.  The Netgear is apparently probing 
*after* allocating the IP address and then *withdrawing* it's allocation 
when u-boot (improperly) responds to the ARP (the ARP is probably is a 
side effect of a ICMP probe).  This would explain why we have not been 
bitten by this bug before.

Of course u-boot needs to abide by Postel's Prescription: "Be liberal in 
what you accept, and conservative in what you send."
   <http://www.postel.org/postel.html>

IMHO, the Netgear WGR614v6 bug triggered a u-boot bug, for which we have 
a proposed/accepted (applied?) bug fix.

[snip]

Best regards,
gvb