Problem/issues with DHCP

Fri Feb 20 04:59:04 UTC 2009

Hi

Could I have an early look at any DHCP changes please?  I'm debugging 
through some issues.  I can't seem to follow your description on where 
the problem is.

I've back ported the small changes in cvs to our 4.7 based software.

The first issue I've had is that the DHCP code would not use the replies 
our router would send.  It was failing in bootpc_call(), when checking 
the size of the response against the define BOOTP_MIN_LEN, which is 300. 
  I skimmed the RFCs for this definition, but I don't see it explicitly. 
  I can only see that all the members of the bootp_packet / dhcp_packet 
structure are required, except for vend, which is variable length?  The 
linux server I tried pads to 300 bytes.

Should BOOTP_MIN_LEN be around 241? That's my rough calculation for a 
packet without padding.

My next issue was with a minimally configured linux server, when 
renewing the lease.  The server gives the following settings;

dhcpc: smc: inet: 10.1.1.114      mask: 255.255.255.0
              srv: 10.1.1.20         gw: 0.0.0.0

And I get this error;
bootpc_adjust_interface: add net route, error=114

114 is ENETUNREACH, I think because the server doesn't provide a gateway 
address.  That's OK, the error is ignored, but later when the task tries 
to broadcast a message I get the error

bootpc_call: sosend: 118

Where the send error is EHOSTUNREACH .  I don't understand this, because 
broadcast messages were OK before the interface was reconfigured with 
bootpc_adjust_interface().

If I use the same settings for a static IP configuration, broadcast 
messages are sent OK to the local network, eg to 10.255.255.255 .  The 
configuration of a static IP uses a procedure in rtems_bsdnet_setup() 
which looks the same as bootpc_adjust_interface().

I tried the multicast fix in bug 1381, which doesn't seem to help.

Chris Johns wrote:
> 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
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 

-- 

Mick Davis
Goanna Technologies Pty Ltd
+61 8 9444 2634

"Shock your lizard today!"