[Dnsmasq-discuss] Query about solving a DHCPNAK issue

Vladislav Grishenko themiron at mail.ru
Tue May 26 22:26:06 BST 2015


> On 02/02/2015 05:47 PM, Brian Haley wrote:
> >>
> >>> The one thing I'm curious about is if dnsmasq is restarted while a
> >>> VM holds a lease, how will it respond?  As someone else has
> >>> pointed-out to me - isc-dhcp will respond with a DHCPNAK in that
> >>> case, and wondered why there would be a difference with dnsmasq.
> >>> Different interpretation of an RFC?
> >>
> >>
> >> If by "dnsmasq is restarted" you mean "dnsmasq is restarted and
> >> therefore has its lease database deleted", then the RFC says that if
> >> a server gets a renewal for an unknown lease, it should return
> >> DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is
> >> set, when instead it quietly re-creates the lease.
> >
> > Yes, your assumption is correct, as --leasefile-ro is used it knows of
> > no current leases, and by default get a DHCPNAK.
> >
> >> dhcp-authoritative gives permission to dnsmasq to violate the RFC in
> >> a way which is useful in certain circumstances.
> >
> > Thanks, it does seem to do what I want with my initial testing.
> 
> Hi Simon,
> 
> Replying to my old thread since using --dhcp-authoritative seems to have
> introduced an issue where a DHCP client can get a NAK when using multiple
> dnsmasq servers on the same subnet (they both have the same host
> information, >1 running just to get HA).
> 
> Short story is that both dnsmasq's return the same lease info, but when
the
> client ACKs (sending to broadcast), one agent ACKs and the other agent
> NAKs.
> The tcpdump shows this better than I'm describing:
> 
> https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html
> 
> Does that seem like normal operation to you?  Does this second dnsmasq
> assume this response is from a rogue server and NAKs since it didn't send
out
> the offer?
> 

Hi Brian,

Second dnsmasq assume the client request is to another server and responds
with NAK in authoritative mode.
The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't
check server id for anything but offer packet.
Bug is already fixed in bb 1.23.x, see commit 
http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52
e588c0

Best Regards, Vladislav Grishenko





More information about the Dnsmasq-discuss mailing list