[Dnsmasq-discuss] Duplicate IP detection with fixed IP
Simon Kelley
simon at thekelleys.org.uk
Wed Sep 19 12:52:37 BST 2018
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.
More information about the Dnsmasq-discuss
mailing list