[Dnsmasq-discuss] dnsmasq not overriding leases for static assigments

Kristof Burek contact at kalvr.net
Sun May 16 12:23:32 UTC 2021

Hi, Jesus and dnsmasq-discuss,

> ... if dnsmasq is supposed to be able to abandon a lease when a known
> and legit mac-address is requesting that same ip-address, and the static
> lease is configured, why is it not doing it?

How do you know that the client is requesting the same IP address?  (Have
you been able to sniff the packets?)  Does the client "know" when its MAC
address has changed?  In the case of disconnecting wired and reverting to
Wi-Fi (the scenario I referred to in my earlier email) the client device
"knows" something has happened and _immediately_ does something about it,
i.e. tries to re-connect using the other MAC address (issues new DHCP
discover [DHCPDISCOVER]requests etc).

In your case your client might change the AP it is using but might not have
the nous to grok that its MAC address has changed so may not even issue a
new DHCP request --- at least until DHCP option T1 has expired.  And then it
wouldn't be a "discover" [DHCPDISCOVER] request (as in my scenario) but a
"renew" [DHCPREQUEST] request which probably and understandably wouldn't be
accounted for in dnsmasq's current logic.

So, I don't know if there is a minimum value for T1, but try setting it to
say 5 seconds for the static IP devices that move AP and see what happens?
(This will, of course, mean a fair amount of extra DHCP traffic on your
network but I venture that it won't swamp other traffic as long as the
number of such devices isn't too large.)

(My theory goes that if your clients can't tell when their MAC address has
changed, but try to renew their DHCP lease 5 seconds [/the minimum T1 value]
after the last one was granted then, on moving AP, re-connection will happen
within 2.5 seconds on average.  If "renew" doesn't work then it would have
to be a "re-bind" which is issued after T2 expires if "renewal" failed after
T1's expiry, so make T2 say 10 seconds? UGGGGHHHH!)

You will of course need to tag these devices in dnsmasq's config
appropriately so you can give just those the special T1 and T2 values.

Otherwise you will just have to make the lease times as short as possible (I
believe 2min is the minimum) so that DHCP starts right from the beginning.

Let me tell you that, in a way, I hope my first solution doesn't work as I
consider it supremely inelegant!  But, if it does I would be pleased both
for you and for myself! ... There would still be <= 5|10 seconds downtime of
connectivity which isn't that great.  If it doesn't work then one possible
solution would be to modify dnsmasq to abandon leases associated with a
particular MAC address when receiving packets other than "discover". Hmmm,
Mr Kelly is busy enough as it is I suspect and who knows what else this
could break.  That's why it would be good to know if TP-Link are developing
their equipment according to any RFCs.

Kindness to all kinds

More information about the Dnsmasq-discuss mailing list