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