Problem/issues with DHCP

[Arnout Vandecappelle]

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.

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.


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

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-0-netmask
Type: text/x-diff
Size: 725 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20081106/65f3d59c/attachment-0001.bin>