Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6
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 :(
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...
============================= 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 Bootfile: DhcpSendRequestPkt: Sending DHCPREQUEST 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 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
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
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 :(
[snip]
Hi Robin,
Are you running Windows for your DHCP server? Is this your problem "dhcp problems with Windows Server"? http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/24262/focus=24265
gvb
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
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.
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.
Fun stuff...
regards, Ben
Makes a slow day go faster. :-)
gvb
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-)
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
participants (2)
-
Ben Warren -
Jerry Van Baren