<div dir="ltr">Let me rephrase it slightly. What is the point of dnsmasq NAKing client responses to other servers if the clients are being programmed to ignore the NAKs? <div><br></div><div>On the surface it looks like it's either pointless behavior on the server's part or incorrect logic in the DHCP client. Am I missing something?<div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 2:58 AM, 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,<u></u><u></u></span></p><span class=""><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:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> </span><span lang="EN-US">why do DHCP servers like dnsmasq generate them in the first place?<u></u><u></u></span></p></span><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Because it’s per dnsmasq configuration and the effects are well-described in the man. <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:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html" target="_blank">http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html</a><u></u><u></u></span></p><p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;color:black">-K, --dhcp-authoritative</span></b><span lang="EN-US" style="font-size:11.0pt;color:black"><u></u><u></u></span></p><p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US" style="font-size:11.0pt;color:black">Should be set when <b>dnsmasq is definitely the only DHCP server on a network</b>. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum).<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:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">you definitely have multiple dhcp servers, so this option is misused under your circumstances, not?<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 style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Kevin Benton [mailto:<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>] <br><b>Sent:</b> Monday, June 01, 2015 2:02 PM</span></p><div><div class="h5"><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></div></div><p></p></div></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">I understand, but that eliminates the whole 'correcting rouge dhcp offers' part of the authoritative mode. <u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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?<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">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.<u></u><u></u></p></div></div></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Tue, May 26, 2015 at 10:40 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"><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.</span><u></u><u></u></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.</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></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</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></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</span><u></u><u></u></p></div></div><div><div><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-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt"><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><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>