[Dnsmasq-discuss] Query about solving a DHCPNAK issue

[Kevin Benton]

That fix is interesting. Doesn't ignoring a NAK sort of defeat the point of
the 'authoritative' NAKing in the first place?

On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko <themiron at mail.ru>
wrote:

> > 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
>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150526/d05be576/attachment.html>