[Dnsmasq-discuss] dnsmasq ignoring some clients

[Simon Kelley]

Chris Marget wrote:
> On Thu, 2 Oct 2008, Simon Kelley wrote:
> 
>>Chris Marget wrote:
>>
>>
>>>    Option: (t=50,l=4) Requested IP Address = 255.255.255.255
>>>        Option: (50) Requested IP Address
>>>        Length: 4
>>>        Value: FFFFFFFF
>>
>>                  ^^^^^^^^
>>The client is asking for IP address 255.255.255.255, that doesn't look 
>>right at all. A server identifier of 1.2.3.4 looks suspicious too, is 
>>that the IP address of you DHCP server?
> 
> 
> Hi Simon.  Thank you for your attention.
> 
> Here's the scoop.  the client is a disk image of a pre-installed linux
> system.  I got it here:  http://jailtime.org/download:centos:v5.2
> 
> It's a pre-built "drop into your xvm engine" kind of thing, and comes
> with the baggage of the environment of the guy who built it.
> 
> So, yes, the client is very confused about his environment.
> 
> I agree that asking for 255.255.255.255 is somewhat strange, but
> shouldn't dnsmasq NAK this request just like any other transplanted
> client?
> 
> My other DHCP server (ISC - running on a different box) serves this
> client just fine.  The authoritative statement is required, of course.
> Here's the transaction according to the ISC server's debug output:
> 
> DHCPREQUEST for 255.255.255.255 (1.2.3.4) from 00:16:3e:11:11:11 via nge0: wrong network.
> DHCPNAK on 255.255.255.255 to 00:16:3e:11:11:11 via nge0
> DHCPDISCOVER from 00:16:3e:11:11:11 via nge0
> DHCPOFFER on 192.168.1.81 to 00:16:3e:11:11:11 via nge0
> DHCPREQUEST for 192.168.1.81 (192.168.1.8) from 00:16:3e:11:11:11 via nge0
> DHCPACK on 192.168.1.81 to 00:16:3e:11:11:11 via nge0
> 
>

Hand-running the first request packet through the dnsmasq code reveals 
that it's being ignored because the server-identifier (1.2.3.4) doesn't 
match. RFC-2131 compliant behaviour is to silently ignore any DHCP 
packets which don't have a correct server-id so in the simple case 
that's correct.

Life is made more complicated because the --dhcp-authoritative flag is 
set, which says, essentially "violate the RFC in a way which provides 
more useful behaviour on a network with only one DHCP server." For 
dnsmasq that means accept DHCPREQUEST for clients in INIT-REBOOT 
RENEWING or REBINDING state, even if they don't have an existing lease.
It doesn't have any effect when a client is in SELECTING state, which 
yours, bizarrely, seems to be. It looks like ISC have done things 
differently, and NAK SELECTING clients with mismatched server-ids when 
in authoritative mode.

Since all of this behaviour violates the RFC by design, there's no 
standard to say who is right. Clearly the ISC behaviour is better in 
this case, but it's fairly dangerous since it's NAKing a broadcast 
packet. If there really was another server out there which could respond 
to the broadcast, then not staying silent will mess things up.

It's not clear to me if a behaviour change for dnsmasq makes sense. Any 
contributions from the list would be welcome. Maybe I'll take this to 
the mailing list where the IETF DHCP gods hang out.

Cheers,

Simon.