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

[Ben Warren]

Jerry Van Baren wrote:
> 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.
>
No, what you show as the first one succeeding is the result of the 
'proposal' when the board enters the REQUESTING state (the call to 
DhcpSendrequestPkt() is in the SELECTING state prior to entering the 
REQUESTING state).  At least that's what the code tells me.
>> 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.
>
I don't know, in this case he mentions it's a Linksys router.  I think 
they either run Linux or VxWorks, but who knows now that Cisco owns them.
>> Fun stuff...
>>
>> regards,
>> Ben
>
> Makes a slow day go faster.  :-)
>
Better than writing documentation, which I really should get to.
B-)