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

[Ben Warren <biggerbadderben@gmail.com>]

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