<div dir="ltr">That's an easy one, I have the 'old' lease, the dnsmasq config and logs, and tcpdump sniffing (see below). But the short story is:<br><ol><li>device asked some time ago for an ip-addr, and as it is configured to get a static one, it got it (logged in the 'old' lease)</li><li>device disconnect from the router and connects to one AP, and after reconnecting, request the same ip-addr with a new mac-addr</li><li>dnsmasq sees the 'old', and before even checking anything else (I know this because there are no 'tags' assigned to the device), respond with 'address in use'</li><li>device requests for a new ip-addr with the new mac-addr</li><li>dnsmasq identify the client (assigns the tags 'known' -it is in the config file-, 'eth0' -interfaz-, 'mobile' -assigned to this device in the config file- and 'pasillo' assigned in the config file to all devices connected to that AP.</li><li>dnsmasq, despite having identified the client, assigns a new ip-addr because the old one is in use.</li></ol>This last step is the wrong one in my opinion, at least inconsistent with the dnsmasq man page.<br><br><b>DNSMASQ 'old' lease</b>:<br><br><font face="monospace">[20210516-123037] 192.168.0.230 / 88:a3:03:63:ea:55 samsungA30s</font><br><br><b>DNSMASQ config for this device</b>:<br><br><font face="monospace">dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s</font><br><br><b>DNSMASQ logs</b>:<br><br><font face="monospace">May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP range: 192.168.255.10 -- 192.168.255.100<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP range: 192.168.0.251 -- 192.168.0.254<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP range: 192.168.0.201 -- 192.168.0.250<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP range: 192.168.0.30 -- 192.168.0.49<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 vendor class: android-dhcp-10<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 client provides name: Catuxas<br><b>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 DHCPREQUEST(eth0) 192.168.0.230 96:8d:d4:63:ea:55 <br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 DHCPNAK(eth0) 192.168.0.230 96:8d:d4:63:ea:55 address in use</b><br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 broadcast response<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 sent size: 1 option: 53 message-type 6<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 sent size: 4 option: 54 server-identifier 192.168.0.105<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 sent size: 14 option: 56 message 61:64:64:72:65:73:73:20:69:6e:20:75:73:65<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP range: 192.168.255.10 -- 192.168.255.100<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP range: 192.168.0.251 -- 192.168.0.254<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP range: 192.168.0.201 -- 192.168.0.250<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP range: 192.168.0.30 -- 192.168.0.49<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 vendor class: android-dhcp-10<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 client provides name: Catuxas<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 DHCPDISCOVER(eth0) 96:8d:d4:63:ea:55 <br><b>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 tags: mobile, known, pasillo, eth0<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 DHCPOFFER(eth0) 192.168.0.244 96:8d:d4:63:ea:55 </b><br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options: 1:netmask, 3:router, 6:dns-server, 15:domain-name, <br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options: 26:mtu, 28:broadcast, 51:lease-time, 58:T1, <br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options: 59:T2, 43:vendor-encap<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 next server: 192.168.0.105<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 1 option: 53 message-type 2<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4 option: 54 server-identifier 192.168.0.105<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4 option: 51 lease-time 30m<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4 option: 58 T1 15m<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4 option: 59 T2 26m15s<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4 option: 1 netmask 255.255.255.0<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4 option: 28 broadcast 192.168.0.255<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 6 option: 15 domain-name triana<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4 option: 3 router 192.168.0.1<br>May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 8 option: 6 dns-server 192.168.0.105, 192.168.0.1<br></font><br><b>TCPDUMP sniffing</b>:<br><br><font face="monospace">13:15:37.327596 96:8d:d4:63:ea:55 > 6c:72:20:05:96:6e, ethertype IPv4 (0x0800), length 338: (tos 0x0, ttl 64, id 34573, offset 0, flags [DF], proto UDP (17), length 324)<br> 192.168.0.230.68 > 192.168.0.105.67: [no cksum] BOOTP/DHCP, Request from 96:8d:d4:63:ea:55, length 296, xid 0x1ab4688f, Flags [none] (0x0000)<br> Client-IP 192.168.0.230<br> Client-Ethernet-Address 96:8d:d4:63:ea:55<br> Vendor-rfc1048 Extensions<br> Magic Cookie 0x63825363<br> DHCP-Message Option 53, length 1: Request<br> Client-ID Option 61, length 7: ether 96:8d:d4:63:ea:55<br> MSZ Option 57, length 2: 1500<br> Vendor-Class Option 60, length 15: "android-dhcp-10"<br> Hostname Option 12, length 7: "Catuxas"<br> Parameter-Request Option 55, length 10: <br> Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name<br> MTU, BR, Lease-Time, RN<br> RB, Vendor-Option<br>13:15:37.335311 6c:72:20:05:96:6e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 64264, offset 0, flags [none], proto UDP (17), length 328)<br> 192.168.0.105.67 > 255.255.255.255.68: [bad udp cksum 0xc256 -> 0x10b1!] BOOTP/DHCP, Reply, length 300, xid 0x1ab4688f, Flags [Broadcast] (0x8000)<br> Client-Ethernet-Address 96:8d:d4:63:ea:55<br> Vendor-rfc1048 Extensions<br> Magic Cookie 0x63825363<br> DHCP-Message Option 53, length 1: NACK<br> Server-ID Option 54, length 4: 192.168.0.105<br> MSG Option 56, length 14: "address in use"<br>13:15:37.520272 96:8d:d4:63:ea:55 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 338: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 324)<br> 0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request from 96:8d:d4:63:ea:55, length 296, xid 0x13c8dab8, Flags [none] (0x0000)<br> Client-Ethernet-Address 96:8d:d4:63:ea:55<br> Vendor-rfc1048 Extensions<br> Magic Cookie 0x63825363<br> DHCP-Message Option 53, length 1: Discover<br> Client-ID Option 61, length 7: ether 96:8d:d4:63:ea:55<br> MSZ Option 57, length 2: 1500<br> Vendor-Class Option 60, length 15: "android-dhcp-10"<br> Hostname Option 12, length 7: "Catuxas"<br> Parameter-Request Option 55, length 10: <br> Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name<br> MTU, BR, Lease-Time, RN<br> RB, Vendor-Option<br>13:15:37.540462 6c:72:20:05:96:6e > 96:8d:d4:63:ea:55, ethertype IPv4 (0x0800), length 346: (tos 0x0, ttl 64, id 11490, offset 0, flags [none], proto UDP (17), length 332)<br> 192.168.0.105.67 > 192.168.0.244.68: [bad udp cksum 0x83f7 -> 0x89b7!] BOOTP/DHCP, Reply, length 304, xid 0x13c8dab8, Flags [none] (0x0000)<br> Your-IP 192.168.0.244<br> Server-IP 192.168.0.105<br> Client-Ethernet-Address 96:8d:d4:63:ea:55<br> Vendor-rfc1048 Extensions<br> Magic Cookie 0x63825363<br> DHCP-Message Option 53, length 1: Offer<br> Server-ID Option 54, length 4: 192.168.0.105<br> Lease-Time Option 51, length 4: 1800<br> RN Option 58, length 4: 900<br> RB Option 59, length 4: 1575<br> Subnet-Mask Option 1, length 4: 255.255.255.0<br> BR Option 28, length 4: 192.168.0.255<br> Domain-Name Option 15, length 6: "triana"<br> Default-Gateway Option 3, length 4: 192.168.0.1<br> Domain-Name-Server Option 6, length 8: 192.168.0.105,192.168.0.1</font><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 16 May 2021 at 13:48, Kristof Burek <<a href="mailto:contact@kalvr.net">contact@kalvr.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, Jesus and dnsmasq-discuss,<br>
<br>
> ... if dnsmasq is supposed to be able to abandon a lease when a known<br>
> and legit mac-address is requesting that same ip-address, and the static<br>
> lease is configured, why is it not doing it?<br>
<br>
How do you know that the client is requesting the same IP address? (Have<br>
you been able to sniff the packets?) Does the client "know" when its MAC<br>
address has changed? In the case of disconnecting wired and reverting to<br>
Wi-Fi (the scenario I referred to in my earlier email) the client device<br>
"knows" something has happened and _immediately_ does something about it,<br>
i.e. tries to re-connect using the other MAC address (issues new DHCP<br>
discover [DHCPDISCOVER]requests etc).<br>
<br>
In your case your client might change the AP it is using but might not have<br>
the nous to grok that its MAC address has changed so may not even issue a<br>
new DHCP request --- at least until DHCP option T1 has expired. And then it<br>
wouldn't be a "discover" [DHCPDISCOVER] request (as in my scenario) but a<br>
"renew" [DHCPREQUEST] request which probably and understandably wouldn't be<br>
accounted for in dnsmasq's current logic.<br>
<br>
So, I don't know if there is a minimum value for T1, but try setting it to<br>
say 5 seconds for the static IP devices that move AP and see what happens?<br>
(This will, of course, mean a fair amount of extra DHCP traffic on your<br>
network but I venture that it won't swamp other traffic as long as the<br>
number of such devices isn't too large.)<br>
<br>
(My theory goes that if your clients can't tell when their MAC address has<br>
changed, but try to renew their DHCP lease 5 seconds [/the minimum T1 value]<br>
after the last one was granted then, on moving AP, re-connection will happen<br>
within 2.5 seconds on average. If "renew" doesn't work then it would have<br>
to be a "re-bind" which is issued after T2 expires if "renewal" failed after<br>
T1's expiry, so make T2 say 10 seconds? UGGGGHHHH!)<br>
<br>
You will of course need to tag these devices in dnsmasq's config<br>
appropriately so you can give just those the special T1 and T2 values.<br>
<br>
Otherwise you will just have to make the lease times as short as possible (I<br>
believe 2min is the minimum) so that DHCP starts right from the beginning.<br>
<br>
Let me tell you that, in a way, I hope my first solution doesn't work as I<br>
consider it supremely inelegant! But, if it does I would be pleased both<br>
for you and for myself! ... There would still be <= 5|10 seconds downtime of<br>
connectivity which isn't that great. If it doesn't work then one possible<br>
solution would be to modify dnsmasq to abandon leases associated with a<br>
particular MAC address when receiving packets other than "discover". Hmmm,<br>
Mr Kelly is busy enough as it is I suspect and who knows what else this<br>
could break. That's why it would be good to know if TP-Link are developing<br>
their equipment according to any RFCs.<br>
<br>
Kindness to all kinds<br>
Kristof<br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div>