Hi Kevin, Le Mon, 1 Jun 2015 02:02:27 -0700, Kevin Benton <blak...@gmail.com> a écrit :
> 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? That's my opinion too (although I can see a flip side to the coin: if clients honor NAKs from any sever, then a rogue machine could break a local noetwork by NAKing any and all DHCPREQUESTs, effectively DoSing the whole segment at least). > 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. RFC 2131 says a server SHOULD send a DHCPNAK if it detects a DHCP request for e.g. the wrong network. It also says "If the client receives a DHCPNAK message, the client restarts the configuration process", which, while there is no "MUST" in it, seems to me like a non-optional requirement to honor DHCPNAKs. > On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko <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] > > *Sent:* Wednesday, May 27, 2015 9:32 AM > > *To:* Vladislav Grishenko > > *Cc:* Brian Haley; Simon Kelley; 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> > > 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@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > > > > > > > > > -- > > > > Kevin Benton > > > > > Amicalement, -- Albert. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss