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?
Thanks a lot!Regards,Bernard 

    On Wednesday, 19 September 2018, 1:16, Simon Kelley 
<> wrote:

 On 18/09/18 16:59, Bernard CLABOTS wrote:
> Hi all,
>    I have been trying to replicate an issue of IP conflict on Open-WRT,
> the issue is randomly seen, and I expect in real life, it is related to
> a de-sync of the lease data base with the actual situation (in case a
> switch is between the client and the server and the server is rebooted
> e.g., so that the client acts as though it would have a fixed IP.
> Reported as seen as well when moving a client from one setup to another
> setup where the IP that it used to receive is used on the LAN).
>    I tested with 2 different versions of dnsmasq (2.78 and 2.79).
>    I use Scapy to forge DHCP Requests (see further).
> Setup:
> I have a laptop with a fixed IP inside the range of the DHCP
> ( I then forge a Request of that IP using scapy and I
> cannot explain the behavior:
> 1. I see no ARP whatsoever to the requested IP when DNSMasq handles the
> request.
> 2. When I request the fixed IP for a client with a random MAC, I
> instantly receive an ACK, then I see some unanswered ARP requests
> (*after*) as to "who has [IP just assigned]? Tell" where
> is the DHCP server IP.
> I end up in a situation where the dhcp.leases contains the fake MAC
> associated to the lease, while the ARP table contains the MAC of the
> fixed IP laptop (probably because I'm not sending any IP packet where
> the IP is associated to the fake MAC, so the switch cannot learn it).
> I have observed that Windows 10 has a mechanism to prevent conflicts
> where, whenever a fixed IP is used/configured, after the link is up an
> ARP probe is sent with its own IP. In case it gets answered, the client
> keeps silent and start using a link local IPv4 (169....). Yet I have
> tested with a very old laptop running Windows 3.1 and I can replicate
> the issue.
> But basically, it is puzzling that the device is ARPing *after* the DHCP
> distributed the IP.
> *The all issue seems to boil down to:* why does DNSMasq not check if the
> IP is free before assigning it?
> I thought that unless option "-5" or "--no-ping" was set, DNSMasq would
> always ping once to the assigned IP *before* assignment (I controlled in
> the code and see that actually, there is a mechanism to store the
> positive identification as well as to blacklist IP's in case a client is
> constantly coming back).
> The only ARP I see in this case is *after* the IP is assigned. How come
> DNSMasq is not trying to ping before assignment? Is there an option to
> force this behavior (from the code I guess not)? Is DNSMasq also somehow
> relying on the ARP table and flags that are set on reachability? or
> solely on the _non_ answer to ping?
> Thanks a lot for your assistance.
> Regards,
> Bernard
> Scapy forged packet (I know the source MAC does not match the client
> MAC, but I deem this good enough for testing, AFAIK it is a legal packet):
> dhcp_request = Ether(dst='ff:ff:ff:ff:ff:ff')/IP(src='',
> dst='')/UDP(dport=67,
> sport=68)/BOOTP(xid=RandInt())/DHCP(options=[('message-type',
> 'request'),("server_id",""),("requested_addr",""),("hostname","Scapy"),
> 'end'])
> dhcp_ack = srp1(dhcp_request, iface='enp9s0')

There are two reasons why you are not seeing ARP requests from dnsmasq.

1) DHCP servers (as opposed to clients) use ICMP echo-request AKA ping,
and not ARP to check for address-in-use.

2) Dnsmasq does the ping-check during the DHCPDISCOVER/DHCPOFFER phase
of the protocol, not the DHCPREQUEST/DHCPACK phase.

It's possible for a DHCPREQUEST to create a new  entry in the leases
file, but only if the dhcp-authoritative flag is set. In that case when
dnsmasq sees what looks like a lease renewal for a lease it doesn't know
about, it assumes the lease database was lost, and does the renewal
anyway, recreating the lease entry as it does. Without
dhcp-authoritative, it follows the RFC-approved route of replying with
DHCPNAK, which forces the client to go through the whole
DHCPDISCOVER/DHCPOFFER phase, and that does the ping-check.

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.



Dnsmasq-discuss mailing list


Dnsmasq-discuss mailing list

Reply via email to