Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6
Foreword: As Wolfgang noted, Robin's emails apparently are being discarded by Sourceforge. I'm dual-subscribed - home and work - and only received emails from Robin on the email that was directly addressed to me.
Robin Getz wrote:
On Fri 11 Jul 2008 14:52, Jerry Van Baren pondered:
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 :( 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.
No - the DCHP server offered an address, When U-Boot does a DHCPREQUEST (confirming it can have that address) it gets a DHCP NAK.
Right. My confusion.
Bootfile: DhcpSendRequestPkt: Sending DHCPREQUEST
Why is the second DHCP request being sent?
This is not a 2nd DHCP request being sent. This is part of the DHCP protocol.
Right. My confusion.
What is the second DHCP request asking for (sniff the net with wireshark).
I can send you the wireshark file, but it is exactly as I described.
http://www.ietf.org/rfc/rfc1533.txt
Client sends DHCPDISCOVER server sends DHCPOFFER Client sends DHCPREQUEST Server sends ARP Client responds to ARP before it should Server sends DHCPNAK, because someone on the network is using the IP number (and doesn't bother to check the MAC - and notice that is the machine that it just gave the IP number to). Clients tosses the offer info (it did get NAKed), and starts over.
RFC-1533 is "DHCP Options and BOOTP Vendor Extensions". RFC-2131 "Dynamic Host Configuration Protocol" appears to be the right RFC.
The above sequence is somewhat odd and I would contend that it should be classified as a DHCP server bug. Quoting from RFC-2131:
------------------------------------------------------------------------- 2.2 Dynamic allocation of network addresses
[snip]
As a consistency check, the allocating server SHOULD probe the reused address *before* allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP. -------------------------------------------------------------------------
My emphasis on the word *before*. The Netgear is apparently probing *after* allocating the IP address and then *withdrawing* it's allocation when u-boot (improperly) responds to the ARP (the ARP is probably is a side effect of a ICMP probe). This would explain why we have not been bitten by this bug before.
Of course u-boot needs to abide by Postel's Prescription: "Be liberal in what you accept, and conservative in what you send." http://www.postel.org/postel.html
IMHO, the Netgear WGR614v6 bug triggered a u-boot bug, for which we have a proposed/accepted (applied?) bug fix.
[snip]
Best regards, gvb
participants (1)
-
Jerry Van Baren