Bug 6614

Summary: Questionable implementation of RFC2132 - udhcpc
Product: Busybox Reporter: David Freedman <lcreg-busybox>
Component: Standard ComplianceAssignee: unassigned
Status: RESOLVED FIXED    
Severity: major CC: busybox-cvs
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Host: Target:
Build:

Description David Freedman 2013-10-25 12:59:49 UTC
Hi there,

I produce an RFC2132 compliant (I believe) DHCP server, 

This server has a behavioural mechanism which, if enabled, omits option 54 (Server ID) in the DHCPOFFER message.

The reason for this, is that the server does not have an IP address, it communicates solely
through Ethernet (so broadcast listen and unicast MAC response). 

udhcpc seemingly requires a server ID, if you don't provide one, it responds with:

bb_error_msg("no server ID, ignoring packet");

and processing stops.

ISC DHCP client does not display this behaviour.

Nothing I appear to have read in RFC2132 indicates that this 'option' is mandatory in all cases,  there is no RFC2119 language (MUST, SHOULD) which indicates this, but it is clear in which scenarios it is needed (for example, unicast IP response)

At present, no users with dhcpc can obtain a lease from my server, I suggest to people that they should use ISC DHCPc instead.

Regards,

David Freedman
Claranet
Comment 1 Denys Vlasenko 2013-10-28 23:09:23 UTC
(In reply to comment #0)
> Hi there,
> 
> I produce an RFC2132 compliant (I believe) DHCP server, 
> 
> This server has a behavioural mechanism which, if enabled, omits option 54
> (Server ID) in the DHCPOFFER message.
> 
> The reason for this, is that the server does not have an IP address, it
> communicates solely
> through Ethernet (so broadcast listen and unicast MAC response). 
> 
> udhcpc seemingly requires a server ID, if you don't provide one, it responds
> with:
> 
> bb_error_msg("no server ID, ignoring packet");
> 
> and processing stops.
> 
> ISC DHCP client does not display this behaviour.
> 
> Nothing I appear to have read in RFC2132 indicates that this 'option' is
> mandatory in all cases,  there is no RFC2119 language (MUST, SHOULD) which
> indicates this, but it is clear in which scenarios it is needed (for example,
> unicast IP response)

RFC 2131:

""'
2. Protocol Summary
...
   ...  A DHCP server always returns its own address in the 'server
   identifier' option. ...
"""

"""
3.1 Client-server interaction - allocating a network address
...
     ... The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected ...
"""

"""
4.3.2 DHCPREQUEST message

   A DHCPREQUEST message may come from a client responding to a
   DHCPOFFER message from a server, from a client verifying a previously
   allocated IP address or from a client extending the lease on a
   network address.  If the DHCPREQUEST message contains a 'server
   identifier' option, the message is in response to a DHCPOFFER
   message.  Otherwise, the message is a request to verify or extend an
   existing lease.
"""

If server ID is not provided, client can't send it back
in its DHCPREQUEST answer to DHCPOFFER.
IOW: it can't specify to which of potentially many DHCP
servers it is replying to. (DHCPREQUEST packet is broadcast,
so its destination IP address can't be used for that.)

A server-id-less DHCP server looks like a corner case with
questionable validity.
validity.
Comment 2 David Freedman 2013-10-28 23:21:20 UTC
Hi Denys,

""'
2. Protocol Summary
...
   ...  A DHCP server always returns its own address in the 'server
   identifier' option. ..."

No RFC2119 language here, my server doesn't have an address, therefore it won't respond with one.

This is quite deliberate, as it needs to impersonate a server on many VLANs that may belong to customers, it can't be seen to be stealing an address from their subnets. 

"3.1 Client-server interaction - allocating a network address
...
     ... The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected ...
""""

That's fine, we just use 0.0.0.0 as the server identifier, the option MUST be included, but it doesn't say anything about the option value. 

"""
4.3.2 DHCPREQUEST message

   A DHCPREQUEST message may come from a client responding to a
   DHCPOFFER message from a server, from a client verifying a previously
   allocated IP address or from a client extending the lease on a
   network address.  If the DHCPREQUEST message contains a 'server
   identifier' option, the message is in response to a DHCPOFFER
   message.  Otherwise, the message is a request to verify or extend an
   existing lease.
"""

yes, the key bit of this sentence is "If the DHCPREQUEST message contains a 'server identifier' option" , 
we do have one present, it is just blank. 

"If server ID is not provided, client can't send it back
in its DHCPREQUEST answer to DHCPOFFER."

We can send back Server-ID : 0.0.0.0, we're still including the option. 

"it can't specify to which of potentially many DHCP
servers it is replying to."

It's replying to the server at 0.0.0.0

>A server-id-less DHCP server looks like a corner case

Not sure I would call it a 'corner case', there is good support in ISC dhcp client and Microsoft Windows for this. 

Dave.
Comment 3 David Freedman 2013-10-28 23:26:24 UTC
Hi Denys, 

Here is an example output from isc dhclient:

Oct 28 23:24:05 moo dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Oct 28 23:24:05 moo dhclient: DHCPREQUEST of 192.168.13.7 on eth0 to 255.255.255.255 port 67
Oct 28 23:24:05 moo dhclient: DHCPOFFER of 192.168.13.7 from 0.0.0.0
Oct 28 23:24:05 moo dhclient: DHCPACK of 192.168.13.7 from 0.0.0.0
Oct 28 23:24:05 moo dhclient: bound to 192.168.13.7 -- renewal in 13518626 seconds.

Dave.
Comment 4 Denys Vlasenko 2013-11-03 18:21:55 UTC
Fixed in git:

commit 8d3efaf35eb9d138114563bba4173c39c1231198
Author: Denys Vlasenko <vda.linux@googlemail.com>
Date:   Sun Nov 3 19:20:54 2013 +0100

    udhcpc: allow zero server-id. Closes 6614.


Please try current git.
Comment 5 David Freedman 2013-11-06 14:18:54 UTC
Hi Denys,

I can confirm it now works, thanks.

Dave