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

[Jerry Van Baren]

Ben Warren wrote:
> 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.

Oops, wrong.

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

You are right, I should learn to read better.  Robin needs to use 
wireshark to see what the actual packet exchange is doing.  It looks 
like the DHCP server thinks that .9 is unallocated, the target is 
requesting that IP address since it had it before, and then a Bad 
Thing[tm] happens.  The question for Wireshark is: what exactly is the 
Bad Thing[tm] that happened?
* Why does the target (apparently) respond to an ARP with an IP address 
that it (presumably) *doesn't own yet*?
* Does the target think it still owns the lease to .9 but the DHCP 
server thinks it timed out?
* Did the target use a different MAC address than the first time, 
confusing the DHCP server?
* Is the DHCP server screwed up? (REBOOT the Netgear - does that fix it?)

[snip]

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

Oops, he clearly states "with a new(er) router netgear WGR614v6 - 
firmware version V2.0.19_1.0.19NA."  Googlebuzz seems to indicate it is 
running vxWorks.  REBOOT the Netgear - it might help.

gvb