Hi Simon, I am definitely not a DHCP expert and I don't want either to become a pain. Yet... I can read that not only the behavior is not inline with RFC, but it even contradicts the RFC: "3.2 Client-server interaction - reusing a previously allocated network address If a client remembers and wishes to reuse a previously allocated network address, a client may choose to omit some of the steps described in the previous section. The timeline diagram in figure 4 shows the timing relationships in a typical client-server interaction for a client reusing a previously allocated network address."
=> So My iPhone is legit. "Servers with knowledge of the client's configuration parameters respond with a DHCPACK message to the client. Servers SHOULD NOT check that the client's network address is already in use; the client may respond to ICMP Echo Request messages at this point." => Invalidates the fix you did in 2017:" | commit 5ce3e76fbf89e942e8c54ef3e3389facf0d9067a | | Author: Simon Kelley <si...@thekelleys.org.uk> | | Date: Fri Apr 28 22:14:20 2017 +0100 | | | | DHCPv4: do ICMP-ping check in all cases other that current lease. | "=> This is a real Bug affecting the current behavior. I would really appreciate that you unlink the authoritative link to always breaking this statement:"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." I agree that the example exposes a philosophy similar to what you implemented, in the sense that being an authoritative server somehow fulfils the second part of the example, but the example is just an example. IMHO not having a trace of the lease in combination with being authoritative should/could be interpreted as a potential Rogue client attempting a MIM attack which is actually an accurate info to be used to NAK the request, or arguably not answer at all. Could you at least make this behavior configurable? Thanks a lot!!! I am not sure I understand what the implications might be that you fear in NAK-ing the request. Thanks a lot! Regards, Bernard
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasqfirstname.lastname@example.org http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss