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