[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6
Jerry Van Baren
gerald.vanbaren at ge.com
Mon Jul 14 14:29:28 CEST 2008
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
More information about the U-Boot
mailing list