From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Warren <biggerbadderben@gmail.com>
Date: Fri, 11 Jul 2008 12:05:04 -0700
Subject: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear
 WGR614v6
In-Reply-To: <4877ABD6.5060800@ge.com>
References: <200807111217.03285.rgetz@blackfin.uclinux.org>
	<4877A499.8040202@gmail.com> <4877ABD6.5060800@ge.com>
Message-ID: <4877AEE0.6070802@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

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.

Fun stuff...

regards,
Ben