Problem/issues with DHCP

[Chris Johns]

Arnout Vandecappelle wrote:
> On Friday 07 November 2008 00:22:45 Chris Johns wrote:
>>>  Ah yes, I encountered a similar problem when I implemented _failsafe().
>>>  The issue was with the netmask, or rather the broadcast address.  Before
>>> configuring an address, IP will be 0.0.0.0, netmask 0.0.0.0 and broadcast
>>> 255.255.255.255.  However, after an address is configured, if you set it
>>> back to 0.0.0.0, the networking code will set the netmask to 255.0.0.0
>>> and therefore the broadcast address to 255.255.255.0.  I did still see
>                                            ^^^^^^^^^^^^^ 0.255.255.255, of 
> course
>>> DISCOVERs coming out of the DHCP client, but they weren't forwarded by
>>> the switch and never arrived at the DHCP server.
>> Are you saying the 'bootpc_fakeup_interface' fails to set the netmask to
>> 0.0.0.0 as it is documented in that code it wants to ?
> 
>  To be honest, I don't remember exactly.  I never really checked if the 
> netmask or broadcast address were set correctly; I just noticed that even 
> after setting netmask to 0.0.0.0 and broadcast to 255.255.255.255, broadcast 
> packets were sent to 0.255.255.255...
> 
> 
>>> I then dived into the networking code (which is copied from FreeBSD)...
>>> and shied away in horror.  In the end, I just implemented a quick fix in
>>> the FreeBSD-derived part of the code that detects the address 0.0.0.0 and
>>> sets netmask to 0.0.0.0 in that case.  I never submitted that patch
>>> because it was in the FreeBSD code which isn't supposed to be touched,
>>> and I'm not 100% sure it's the right thing to do.  It does work for me,
>>> though.  I've attached the patch now.
>> I do not think this patch should be accepted because it changes the stack's
>> behaviour in a way that might break other code.
> 
>  I tend to agree, that's why I never submitted it.  Still, in all cases I can 
> imagine where you set the IP address to 0.0.0.0, I think you'd set netmask to 
> 0.0.0.0 and broadcast to 255.255.255.255 anyway.
> 
> 
>  If you have a better patch, I'd be glad to use it!
> 

I have taken a look at this problem and found the solution. The broadcast 
address was never sent correctly after the first attempt as this thread had 
indicated. Setting the interface address in fakeup added a route in the 
interface so further calls to set the address resulted in an EEXISTS error due 
to that route being present. This error caused the code to give up bring up 
the interface yet let dhcp requests be sent. The stack did what it could given 
the state of the interface. Ignoring the error and letting the remainder of 
the fake up finish fixed the problem.

I also cleaned up the open socket in dhcp_init. I think that was leaking 
memory on a failure.

Patches are coming soon.

Regards
Chris