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 Kristof _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
