On 19/09/18 11:09, Bernard CLABOTS wrote: > Thanks a lot for this answer. > > Indeed, it is a special case as we have a simple two way Request/ACK, > this is also what is seen with some implementations when quickly > unplugging/re-plugging the cable, it is legal AFAIK. > > I also agree on the necessity to be efficient in case of loss of the > lease dB. > > Yet reading the RFC-2131, I saw: > If the client's request is invalid (e.g., the client has moved > to a new subnet), servers SHOULD respond with a DHCPNAK message to > the client. Servers SHOULD NOT respond if their information is not > guaranteed to be accurate. For example, a server that identifies a > request for an expired binding that is owned by another server SHOULD > NOT respond with a DHCPNAK unless the servers are using an explicit > mechanism to maintain coherency among the servers. > > **//___^Referring to the first sentence, I agree it is only a should. > Though, the next sentence is, according to your explanation, also > relevant in this case, so DNSMasq should not respond if the information > is not guaranteed to be accurate. Which also means that changing the > authoritative flag, we risk to end up in the exemplified case where > DNSMasq cannot guarantee that the requested IP is belonging to another > DHCP Server, so it should not NAK and we are going in circles... > We can of course discuss whether the Request is invalid simply because > that IP is currently used by another device while not even assigned > through DHCP. I would argue that the DNSMasq code explicitly accept that > requesting the IP of the server fulfills this condition, which IMHO is a > similar case. > **//___^ > Anyhow, moving forward to resolve the issue I face, is there any way to > force the RFC behavior of NAK-ing and forcing the 4 way exchange? >
If you don't set dhcp-authoritative, then the client will eventually move to the four-way exchange, but it may take some time, as it involves time-outs. The reason for this is that the dnsmasq server has to assume there are other DHCP servers on the network which may hold a lease for the client. The differences in behaviour are these. Without dhcp-authoritative: 1) A client sending DHCPREQUEST in init-reboot state which doesn't have a lease in the database will be ignored. 2) A client sending a DHCPREQUEST in rebind mode which doesn't have a lease in the database will be ignored. In renew mode (ie unicast request) it will get a DHCPNAK. 3) A client sending a request with the wrong server-id will be ignored. With dhcp-authoritative 1) A client sending DHCPREQUEST in init-reboot state which doesn't have a lease will have the lease created 2) A client sending a DHCPREQUEST in renew or rebind mode which doesn't have a lease in the database will have a lease created. 3) A client sending a request in INIT_REBOOT or SELECTING state with the wrong server-id will get a DHCPNAK. Cheers, Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
