<div dir="ltr">That fix is interesting. Doesn't ignoring a NAK sort of defeat the point of the 'authoritative' NAKing in the first place?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko <span dir="ltr"><<a href="mailto:themiron@mail.ru" target="_blank">themiron@mail.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> On 02/02/2015 05:47 PM, Brian Haley wrote:<br>
> >><br>
> >>> The one thing I'm curious about is if dnsmasq is restarted while a<br>
> >>> VM holds a lease, how will it respond?  As someone else has<br>
> >>> pointed-out to me - isc-dhcp will respond with a DHCPNAK in that<br>
> >>> case, and wondered why there would be a difference with dnsmasq.<br>
> >>> Different interpretation of an RFC?<br>
> >><br>
> >><br>
> >> If by "dnsmasq is restarted" you mean "dnsmasq is restarted and<br>
> >> therefore has its lease database deleted", then the RFC says that if<br>
> >> a server gets a renewal for an unknown lease, it should return<br>
> >> DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is<br>
> >> set, when instead it quietly re-creates the lease.<br>
> ><br>
> > Yes, your assumption is correct, as --leasefile-ro is used it knows of<br>
> > no current leases, and by default get a DHCPNAK.<br>
> ><br>
> >> dhcp-authoritative gives permission to dnsmasq to violate the RFC in<br>
> >> a way which is useful in certain circumstances.<br>
> ><br>
> > Thanks, it does seem to do what I want with my initial testing.<br>
><br>
> Hi Simon,<br>
><br>
> Replying to my old thread since using --dhcp-authoritative seems to have<br>
> introduced an issue where a DHCP client can get a NAK when using multiple<br>
> dnsmasq servers on the same subnet (they both have the same host<br>
> information, >1 running just to get HA).<br>
><br>
> Short story is that both dnsmasq's return the same lease info, but when<br>
the<br>
> client ACKs (sending to broadcast), one agent ACKs and the other agent<br>
> NAKs.<br>
> The tcpdump shows this better than I'm describing:<br>
><br>
> <a href="https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html" target="_blank">https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html</a><br>
><br>
> Does that seem like normal operation to you?  Does this second dnsmasq<br>
> assume this response is from a rogue server and NAKs since it didn't send<br>
out<br>
> the offer?<br>
><br>
<br>
</div></div>Hi Brian,<br>
<br>
Second dnsmasq assume the client request is to another server and responds<br>
with NAK in authoritative mode.<br>
The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't<br>
check server id for anything but offer packet.<br>
Bug is already fixed in bb 1.23.x, see commit<br>
<a href="http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52
e588c0" target="_blank">http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52<br>
e588c0</a><br>
<br>
Best Regards, Vladislav Grishenko<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>