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

Hmmm, do you have more than one port connected to the same ethernet?  Is 
the second DHCP request using a different MAC address?  Did the DHCP 
server understand that the first DHCP operation succeeded?

What does your DHCP server have for client lease information?  I forgot 
where this is stashed, somewhere on /var for linux.  IIRC:
   find /var -name "*lease*"

>> Transmitting DHCPREQUEST packet: len = 343
>> BFIN EMAC send: length = 343
>> BFIN EMAC rx: length = 64
>> packet received
>> packet received
>> Receive from protocol 0x806
>> Got ARP
>> Got ARP REQUEST, for 192.168.0.9, return our MAC

This is standard protocol to check if anyone *else* is using the IP 
address that is about to be allocated.  The big question is why it is 
sending the .9 IP address to this target and then DHCPNAKing it when 
this target responds appropriately to the ARP.  What DHCP server are you 
using (linux/bind, Windows, ?other?).

>> BFIN EMAC send: length = 42
>> BFIN EMAC rx: length = 552
>> packet received
>> packet received
>> Receive from protocol 0x800
>> Got IP
>> len=272, v=45
>> passing packet len= 244
>> DHCPHandler: got packet: (src=67, dst=68, len=244) state: 4
>> Filtering pkt = 0
>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=244) state: 4
>> DHCP State: REQUESTING
>> you just got DHCP NAKed
>>
>> ===================
>>
>> What is happening, is that the server offers an IP number to U-Boot 
>> (192.168.0.9), U-Boot does a DHCPREQUEST, the server does a ARP asking 
>> for "who has 192.168.0.9", and U-Boot responds "I do" (This is the problem). 
>> The server then sends the requester (U-Boot) a DHCP NAK saying that someone 
>> else on the network is already using that address.
>>
>>   
> This seems goofy.  Have you tried your fix with other DHCP servers to 
> verify that it works?  If so, which ones?  I unfortunately can't try 
> anything right now but will play around a bit tonight.
> 
> regards,
> Ben


Best regards,
gvb