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