Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6
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
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
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
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
participants (2)
-
Ben Warren -
Wolfgang Denk