[Dnsmasq-discuss] Duplicate IP detection with fixed IP

[Bernard CLABOTS]

Hi Simon,   Sorry to come back to this question again. You wrote:"I don't think it would be possible to make this hack any more safe by
doing the ping-check before re-creating the lease. The whole premise is
that the client attempting to renew is already configured, but the
server lost track of it. So doing a ping-check would expect to get a
reply from the already-configured client."

Well, actually, I see at least two ways to improve that behavior, especially starting from the fact that assuming that the lease dB was corrupted is weird and not safe:
1. ARP the IP to see if you receive any answer other than the client asking the IP (more efficient but fails if using proxy arp).
2. PING the IP and expect to receive an answer from that same MAC (might fail if device is set to not answer ping).
if not, then reject and force 4 way. Indeed, if you receive no answer, you can no longer assume that this is the legit owner of the IP. Anyway, if the client is legitimate, the algorithm will most probably give him the same IP.
The main drawback is an increased handling time, but that only occurs if the lease is unknown.

 

    On Wednesday, 19 September 2018, 13:01, Simon Kelley <simon at thekelleys.org.uk> wrote:
 

 

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.




   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20181005/76cffa86/attachment.html>