[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Ben Warren]

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

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

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

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

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

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Ben Warren]

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

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

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

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Ben Warren]

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-)

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

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

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

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

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgearWGR614v6

[Ben Warren]

Hi Robin,

Robin Getz wrote:
> On Fri 11 Jul 2008 14:21, Ben Warren pondered:
>   
>> Robin Getz wrote:
>>     
> [snip]
>   
>>>   
>>>       
>> 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.
>>     
>
> Some other random netgears that I have in my home, plus whatever is attached 
> to our corp network - it works on them all (but on those it worked before as 
> well).
>
> -Robin
While your fix works, wouldn't it be more correct to remove the call to 
BootpCopyNetParams() on line 927?  My understanding of the purpose of 
the DHCPDISCOVER state is for determining if there are reachable DHCP 
servers, not for actually acquiring an address.  I'm a bit wary because 
I don't know why that call was put there in the first place.  I guess in 
theory you could short-circuit the DHCPREQUEST state, but the code 
doesn't do that.

thanks,
Ben

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6

[Ben Warren]

Robin Getz wrote:
> On Fri 11 Jul 2008 18:05, Ben Warren pondered:
>   
>> Hi Robin,
>>
>> Robin Getz wrote:
>>     
>>> On Fri 11 Jul 2008 14:21, Ben Warren pondered:
>>>   
>>>       
>>>> Robin Getz wrote:
>>>>     
>>>>         
>>> [snip]
>>>   
>>>       
>>>>>   
>>>>>       
>>>>>           
>>>> 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.
>>>>     
>>>>         
>>> Some other random netgears that I have in my home, plus whatever is
>>> attached to our corp network - it works on them all (but on those it
>>> worked before as well).
>>>
>>> -Robin
>>>       
>> While your fix works, wouldn't it be more correct to remove the call to 
>> BootpCopyNetParams() on line 927?  
>>     
>
> That seems to work as well - but changes the operation a little.
>
> Before - the U-Boot had set source IP number to the IP number it had been 
> offered (my first patch leaves it that way). With the call to 
> BootpCopyNetParams() removed, it does a broadcast (Source IP is 0.0.0.0 - 
> just like the RFC says it should do).
>
> I have no idea if some other broken DHCP server historically needed that, or 
> what was going on - so that is why I only fixed the operation on the wire - 
> not changed it from it's existing state (which AFAICT - _is_ wrong).
>
> I'm more than happy to send the patch that remove the call (and makes things 
> more correct, fixes the bug, and makes things smaller) - but I'm also 
> hesitant since I don't want to break it for anyone else :)
>
>   
>> My understanding of the purpose of  
>> the DHCPDISCOVER state is for determining if there are reachable DHCP 
>> servers, not for actually acquiring an address.  I'm a bit wary because 
>> I don't know why that call was put there in the first place.  I guess in
>> theory you could short-circuit the DHCPREQUEST state, but the code 
>> doesn't do that.
>>     
>
> The code does do that. The call to BootpCopyNetParams() sets up the network, 
> and allows the ARP code in ./net/net.c to respond (before it should) this is 
> what causes the problem I was/am having.
>
> Either fix is fine with me - let me know which one you want.
>
> -Robin
>
>   
I'm a bit of an idealist, so I say let's do it right (remove the call to 
BootpCopyNetParams()).  Unless somebody with some historical perspective 
weighs in, we'll pull it in as soon as the next merge window opens and 
see what happens.

thanks a lot,
Ben

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6

[Wolfgang Denk]

In message <4877E18C.2040102@gmail.com> you wrote:
> Robin Getz wrote:
> > On Fri 11 Jul 2008 18:05, Ben Warren pondered:
> >   
> >> Hi Robin,
> >>
> >> Robin Getz wrote:
> >>     
> >>> On Fri 11 Jul 2008 14:21, Ben Warren pondered:
> >>>   
> >>>> Robin Getz wrote:

Hm... this looks as if there was some longer discussion, but I cannot
find any traces of this on the mailing list.

Would be interesting to know what you discussed. At least if it should
result in any changes to the existing code.

> > Before - the U-Boot had set source IP number to the IP number it had been 
> > offered (my first patch leaves it that way). With the call to 
> > BootpCopyNetParams() removed, it does a broadcast (Source IP is 0.0.0.0 - 
> > just like the RFC says it should do).

??? Setting the source IP addr to 0 does not mean we're broadcasting?

Could you please fill us in on what you discussed?

> > I have no idea if some other broken DHCP server historically needed that, or 
> > what was going on - so that is why I only fixed the operation on the wire - 
> > not changed it from it's existing state (which AFAICT - _is_ wrong).

It seems Robin is claiming this - what exactly is wrong?

> > I'm more than happy to send the patch that remove the call (and makes things 
> > more correct, fixes the bug, and makes things smaller) - but I'm also 
> > hesitant since I don't want to break it for anyone else :)

Before anybody removes anything I want to know exactly what's going on
here, please.

> > The code does do that. The call to BootpCopyNetParams() sets up the network, 
> > and allows the ARP code in ./net/net.c to respond (before it should) this is 
> > what causes the problem I was/am having.

Please explain...

> I'm a bit of an idealist, so I say let's do it right (remove the call to 
> BootpCopyNetParams()).  Unless somebody with some historical perspective 
> weighs in, we'll pull it in as soon as the next merge window opens and 
> see what happens.

Please explain...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A conservative is a man with two perfectly good legs  who  has  never
learned to walk.                              - Franklin D. Roosevelt

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6

[Ben Warren]

Wolfgang Denk wrote:
> In message <4877E18C.2040102@gmail.com> you wrote:
>   
>> Robin Getz wrote:
>>     
>>> On Fri 11 Jul 2008 18:05, Ben Warren pondered:
>>>   
>>>       
>>>> Hi Robin,
>>>>
>>>> Robin Getz wrote:
>>>>     
>>>>         
>>>>> On Fri 11 Jul 2008 14:21, Ben Warren pondered:
>>>>>   
>>>>>           
>>>>>> Robin Getz wrote:
>>>>>>             
>
> Hm... this looks as if there was some longer discussion, but I cannot
> find any traces of this on the mailing list.
>
> Would be interesting to know what you discussed. At least if it should
> result in any changes to the existing code.
>
>   
Strange - there was plenty of inane conversation between gvb and myself, 
but the list was always CC'd.  It shows up on gmane:
http://news.gmane.org/gmane.comp.boot-loaders.u-boot

Essentially, Robin found a bug whereby the DHCP client is responding to 
ARP requests before all the handshaking is finished, causing his new 
Netgear router to NAK the overall request.

Hopefully you can follow the thread, otherwise I'll be happy to fill you in.

regards,
Ben

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6

[Wolfgang Denk]

In message <4877E8E2.70506@gmail.com> you wrote:
>
> >> Robin Getz wrote:
> >>     
> >>> On Fri 11 Jul 2008 18:05, Ben Warren pondered:
> >>>   
> >>>       
> >>>> Hi Robin,
> >>>>
> >>>> Robin Getz wrote:
> >>>>     
> >>>>         
> >>>>> On Fri 11 Jul 2008 14:21, Ben Warren pondered:
> >>>>>   
> >>>>>           
> >>>>>> Robin Getz wrote:
> >>>>>>             
> >
> > Hm... this looks as if there was some longer discussion, but I cannot
> > find any traces of this on the mailing list.
> >
> > Would be interesting to know what you discussed. At least if it should
> > result in any changes to the existing code.
> >
> Strange - there was plenty of inane conversation between gvb and myself, 
> but the list was always CC'd.  It shows up on gmane:
> http://news.gmane.org/gmane.comp.boot-loaders.u-boot

Yes, but above quote shows at least three messages from Robin which did
not make it to the list.

Actually I cannot even find the initial posting (by Robin?) of this
thread.

> Essentially, Robin found a bug whereby the DHCP client is responding to 
> ARP requests before all the handshaking is finished, causing his new 
> Netgear router to NAK the overall request.
> 
> Hopefully you can follow the thread, otherwise I'll be happy to fill you in.

Sorry, with parts of the communication missing it's difficult to
follow.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No user-servicable parts inside. Refer to qualified service personnel.

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6

[Ben Warren]

Wolfgang,

On Fri, Jul 11, 2008 at 4:05 PM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> On Fri 11 Jul 2008 18:41, Ben Warren pondered:
>> I'm a bit of an idealist, so I say let's do it right (remove the call to
>> BootpCopyNetParams()).  Unless somebody with some historical perspective
>> weighs in, we'll pull it in as soon as the next merge window opens and
>> see what happens.
>
>
> Fix DHCP protocol so U-Boot does not respond on the network with it's offered
> IP number until after it has received a DHCP ACK message. Also ensures that
> U-Boot does it's DHCPREQUEST as broadcast (per RFC 2131).
>
>
> Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org>
>
Acked-by: Ben Warren <biggerbadderben@gmail.com>
> --- net/bootp.c 2008-07-11 12:05:18.000000000 -0400
> +++ net/bootp.c 2008-07-11 18:58:15.000000000 -0400
> @@ -924,8 +924,6 @@
>                        if (NetReadLong((ulong*)&bp->bp_vend[0]) == htonl(BOOTP_VENDOR_MAGIC))
>                                DhcpOptionsProcess((u8 *)&bp->bp_vend[4], bp);
>
> -                       BootpCopyNetParams(bp); /* Store net params from reply */
> -
>                        NetSetTimeout(TIMEOUT * CFG_HZ, BootpTimeout);
>                        DhcpSendRequestPkt(bp);
>  #ifdef CFG_BOOTFILE_PREFIX
>

I can't pull this in today.  Please apply directly so it gets in RC1

thanks,
Ben

[U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6

[Wolfgang Denk]

In message <f8328f7c0807141542u1a4a0d0m7b5742c59fec17aa@mail.gmail.com> you wrote:
> Wolfgang,
> 
> On Fri, Jul 11, 2008 at 4:05 PM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> > On Fri 11 Jul 2008 18:41, Ben Warren pondered:
> >> I'm a bit of an idealist, so I say let's do it right (remove the call to
> >> BootpCopyNetParams()).  Unless somebody with some historical perspective
> >> weighs in, we'll pull it in as soon as the next merge window opens and
> >> see what happens.
> >
> >
> > Fix DHCP protocol so U-Boot does not respond on the network with it's offered
> > IP number until after it has received a DHCP ACK message. Also ensures that
> > U-Boot does it's DHCPREQUEST as broadcast (per RFC 2131).
> >
> >
> > Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org>
> >
> Acked-by: Ben Warren <biggerbadderben@gmail.com>
> > --- net/bootp.c 2008-07-11 12:05:18.000000000 -0400
> > +++ net/bootp.c 2008-07-11 18:58:15.000000000 -0400
> > @@ -924,8 +924,6 @@
> >                        if (NetReadLong((ulong*)&bp->bp_vend[0]) == htonl(BOOTP_VENDOR_MAGIC))
> >                                DhcpOptionsProcess((u8 *)&bp->bp_vend[4], bp);
> >
> > -                       BootpCopyNetParams(bp); /* Store net params from reply */
> > -
> >                        NetSetTimeout(TIMEOUT * CFG_HZ, BootpTimeout);
> >                        DhcpSendRequestPkt(bp);
> >  #ifdef CFG_BOOTFILE_PREFIX
> >
> 
> I can't pull this in today.  Please apply directly so it gets in RC1

I had to manually apply that and then create a commit that at least
attributes the patch correclty, but the date is wrong - my problem was
that I nver received the original, complete patch by email.

Robin, will you *please* fix your e-mail issues to the list?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human race has one really effective weapon, and that is laughter.
                                                         - Mark Twain