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