> 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?
Yes, without overriding serverid to one from incoming request packet, the server’s nak could be pointless. But with overriding, it’ll introduce the same naking issue even with clients which were checking server id and ignoring naks from non-selected servers. Dnsmasq starts to nak request from selecting clients in 2.46, see the story here http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q4/002476.html Point of busybox’s udhcpc changes is described here https://bugs.busybox.net/show_bug.cgi?id=4267 As for ISC DHCP, it’s known client ignores NAK from non-selected servers in SELECTING state. As for server, it allow run-time control over weither or not a server, participating in failover, verifies server id option. This commit contains the old and new descriptions https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commitdiff;h=7116a34fc9b1fb307bcdca22e6963254289ecb80 Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com] Sent: Monday, June 01, 2015 5:15 PM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue 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? 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? On Mon, Jun 1, 2015 at 2:58 AM, Vladislav Grishenko <themi...@mail.ru <mailto:themi...@mail.ru> > wrote: Hi Kevin, ы > why do DHCP servers like dnsmasq generate them in the first place? Because it’s per dnsmasq configuration and the effects are well-described in the man. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -K, --dhcp-authoritative Should be set when dnsmasq is definitely the only DHCP server on a network. 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). you definitely have multiple dhcp servers, so this option is misused under your circumstances, not? Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com <mailto:blak...@gmail.com> ] Sent: Monday, June 01, 2015 2:02 PM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk <mailto:dnsmasq-discuss@lists.thekelleys.org.uk> Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue I understand, but that eliminates the whole 'correcting rouge dhcp offers' part of the authoritative mode. 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? 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. On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko <themi...@mail.ru <mailto:themi...@mail.ru> > wrote: Hi Kevin, Ignoring all naks – would be, but the fix is different. That fix ignores all naks except from the selected/requested server only, it’s ok. Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com <mailto:blak...@gmail.com> ] Sent: Wednesday, May 27, 2015 9:32 AM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk <mailto:dnsmasq-discuss@lists.thekelleys.org.uk> Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue 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 <themi...@mail.ru <mailto:themi...@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 <http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0> e588c0 Best Regards, Vladislav Grishenko _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk <mailto:Dnsmasq-discuss@lists.thekelleys.org.uk> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Kevin Benton -- Kevin Benton -- Kevin Benton
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
