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
(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.
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.
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.
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.
Hi Denys, I can confirm it now works, thanks. Dave