[Dnsmasq-discuss] dnsmasq ignoring some clients
chris at logsoft.com
Thu Oct 2 22:01:59 BST 2008
On Thu, 2 Oct 2008, Simon Kelley wrote:
> Chris Marget wrote:
> > On Thu, 2 Oct 2008, Simon Kelley wrote:
> >>Chris Marget wrote:
> > DHCPREQUEST for 255.255.255.255 (22.214.171.124) 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 (126.96.36.199) 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.
Interesting, thanks Simon!
I've actually used 3 different linux builds from jailtime.org: debian,
cenots and ubuntu. They all behave the same way. ...Well, dnsmasq
silently ignores them anyway.
In my envioronment, it's not all that big of a deal to have the ISC
daemon around, only serving up addresses to clients using the xensource
...Though it feels a little bit dirty to have two "authoritative"
servers on the LAN!
More information about the Dnsmasq-discuss