<div dir="ltr">I understand, but that eliminates the whole 'correcting rouge dhcp offers' part of the authoritative mode. <div><br></div><div>If we are teaching clients to ignore NAKs from other DHCP servers, why do DHCP servers like dnsmasq generate them in the first place? Wouldn't it be logically consistent to make a change to dnsmasq to prevent it from generating a NAK if the client is communicating with a different server?<div><br><div>Is the client behavior regarding NAKs outlined in one of the DHCP RFCs? It does seem like there is a lot of confusion around what authoritative servers should be doing.</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 10:40 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 lang="RU" link="blue" vlink="purple"><div><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi Kevin,<br><br>Ignoring all naks – would be, but the fix is different.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">That fix ignores all naks except from the selected/requested server only, it’s ok.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial Narrow",sans-serif;color:#1f497d">Best Regards, Vladislav Grishenko<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Kevin </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Benton [mailto:<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>] <br><b>Sent:</b> Wednesday, May 27, 2015 9:32 AM<br><b>To:</b> Vladislav Grishenko<br><b>Cc:</b> Brian Haley; Simon Kelley; <a href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">dnsmasq-discuss@lists.thekelleys.org.uk</a><br><b>Subject:</b> Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue<u></u><u></u></span></p></div></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">That fix is interesting. Doesn't ignoring a NAK sort of defeat the point of the 'authoritative' NAKing in the first place?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko <<a href="mailto:themiron@mail.ru" target="_blank">themiron@mail.ru</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">> 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>><u></u><u></u></p></div></div><p class="MsoNormal">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=e2318bbad786d6f9ebff704490246bfe52e588c0" target="_blank">http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52<br>e588c0</a><br><br>Best Regards, Vladislav Grishenko<u></u><u></u></p><div><div><p class="MsoNormal"><br><br><br>_______________________________________________<br>Dnsmasq-discuss mailing list<br><a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">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><u></u><u></u></p></div></div></blockquote></div><p class="MsoNormal"><br><br clear="all"><u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <u></u><u></u></p><div><div><p class="MsoNormal">Kevin Benton<u></u><u></u></p></div></div></div></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>