Problem/issues with DHCP

[Chris Johns]

Arnout Vandecappelle wrote:
> On Wednesday 05 November 2008 16:22:46 Gene Smith wrote:
>> Mostly, DHCP/BOOTP code is working OK. But I have had some problems that
>> may or may not be user related:
>>
>> 1. I want to use the feature that allows you to specify a default static
>> address while using DHCP. This requires the use of the failsafe dhcp
>> code, rtems_bsdnet_do_dhcp_failsafe. The code first sets up the
>> interface (eth0 in my case) with the static address. Then it calls
>> do_dhcp_init() which removes the static address and attempts to get an
>> address via dhcp. My problem was that the dhcp packets (discover, offer,
>> etc) never occurred and I could not ping the static address either, so
>> the unit remained offline.
> 
>  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 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 ?

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

> 
>> 2. When the rtems dhcp client requests a renewal on its current address,
>> but the server decides to give out a different address, a NAK is
>> returned by the server. RTEMS then requests address 0.0.0.0 and the
>> request/NAK cycle continues indefinitely. I don't know if this is
>> correct or if RTEMS should fall back in its state machine to doing a new
>> DISCOVER/OFFER and accept a new address. This would require a call also
>> to remove_address() which did not work (for me) as described above.
> 
>  RTEMS really should fall back to a new offer.  The RTEMS DHCP code doesn't 
> handle the non-common case well.  Up to a few months ago, anything except an 
> ACK would even cause a panic...  (it did nicely release the networking 
> semaphore before panicking though :-P )
> 

I agree it should fall back to a new offer.

Regards
Chris