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

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

Ben Warren wrote:
> Jerry Van Baren wrote:
>> 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 :( 
>>
>> More correctly, the *second* DHCP request 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.
>>
>>>> Bootfile:
>>>> DhcpSendRequestPkt: Sending DHCPREQUEST
>>
>> Why is the second DHCP request being sent?  What is the second DHCP 
>> request asking for (sniff the net with wireshark).  It should be 
>> asking for its current IP address (e.g. a renewal) if anything.
>>
> I think this is how it's supposed to work, but don't quote me...  Client 
> starts in 'Discover' state, sending a broadcast looking for servers.  
> One or more servers respond with proposals.  Client changes to 'Request' 
> state, and sends a request.  Server then has the option of sending an 
> ARP to see if the IP address is already taken and eventually sends ACK 
> or NAK.

Yes, but that describes the *first* DHCP which *succeeded* (above).  The 
target then initiates a second DHCP (presumably with the same MAC 
address and, I would presume/deduce with a lease renewal request rather 
than a "gimme a new IP" request) which the server(?) bungles.

> But why the NAK in this case?  The server should recognize that it 
> offered this IP address to the device with this MAC address.  Maybe it 
> is a timing thing like somebody saw a while ago with a Windows DHCP server.

Yes, Windows is my suspicion too, our emails probably crossed in the server.

> Fun stuff...
> 
> regards,
> Ben

Makes a slow day go faster.  :-)

gvb