[Dnsmasq-discuss] dnsmasq not overriding leases for static assigments
Jesus M Diaz
jesusm.diazperez at gmail.com
Sun May 16 13:13:37 UTC 2021
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:
1. 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)
2. device disconnect from the router and connects to one AP, and after
reconnecting, request the same ip-addr with a new mac-addr
3. 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'
4. device requests for a new ip-addr with the new mac-addr
5. 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.
6. dnsmasq, despite having identified the client, assigns a new ip-addr
because the old one is in use.
This last step is the wrong one in my opinion, at least inconsistent with
the dnsmasq man page.
*DNSMASQ 'old' lease*:
[20210516-123037] 192.168.0.230 / 88:a3:03:63:ea:55 samsungA30s
*DNSMASQ config for this device*:
dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s
*DNSMASQ logs*:
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP
range: 192.168.255.10 -- 192.168.255.100
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP
range: 192.168.0.251 -- 192.168.0.254
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP
range: 192.168.0.201 -- 192.168.0.250
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP
range: 192.168.0.30 -- 192.168.0.49
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 vendor class:
android-dhcp-10
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 client provides
name: Catuxas
*May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 DHCPREQUEST(eth0)
192.168.0.230 96:8d:d4:63:ea:55 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*
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 broadcast response
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 sent size: 1
option: 53 message-type 6
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 sent size: 4
option: 54 server-identifier 192.168.0.105
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
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP
range: 192.168.255.10 -- 192.168.255.100
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP
range: 192.168.0.251 -- 192.168.0.254
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP
range: 192.168.0.201 -- 192.168.0.250
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP
range: 192.168.0.30 -- 192.168.0.49
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 vendor class:
android-dhcp-10
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 client provides
name: Catuxas
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 DHCPDISCOVER(eth0)
96:8d:d4:63:ea:55
*May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 tags: mobile,
known, pasillo, eth0May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]:
331930296 DHCPOFFER(eth0) 192.168.0.244 96:8d:d4:63:ea:55 *
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options:
1:netmask, 3:router, 6:dns-server, 15:domain-name,
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options:
26:mtu, 28:broadcast, 51:lease-time, 58:T1,
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options:
59:T2, 43:vendor-encap
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 next server:
192.168.0.105
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 1
option: 53 message-type 2
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4
option: 54 server-identifier 192.168.0.105
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4
option: 51 lease-time 30m
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4
option: 58 T1 15m
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4
option: 59 T2 26m15s
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4
option: 1 netmask 255.255.255.0
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4
option: 28 broadcast 192.168.0.255
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 6
option: 15 domain-name triana
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size: 4
option: 3 router 192.168.0.1
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
*TCPDUMP sniffing*:
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)
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)
Client-IP 192.168.0.230
Client-Ethernet-Address 96:8d:d4:63:ea:55
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 96:8d:d4:63:ea:55
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 7: "Catuxas"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
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)
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)
Client-Ethernet-Address 96:8d:d4:63:ea:55
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Server-ID Option 54, length 4: 192.168.0.105
MSG Option 56, length 14: "address in use"
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)
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)
Client-Ethernet-Address 96:8d:d4:63:ea:55
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 96:8d:d4:63:ea:55
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 7: "Catuxas"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
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)
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)
Your-IP 192.168.0.244
Server-IP 192.168.0.105
Client-Ethernet-Address 96:8d:d4:63:ea:55
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.0.105
Lease-Time Option 51, length 4: 1800
RN Option 58, length 4: 900
RB Option 59, length 4: 1575
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 192.168.0.255
Domain-Name Option 15, length 6: "triana"
Default-Gateway Option 3, length 4: 192.168.0.1
Domain-Name-Server Option 6, length 8: 192.168.0.105,192.168.0.1
On Sun, 16 May 2021 at 13:48, Kristof Burek <contact at kalvr.net> wrote:
> 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 at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210516/b72cf352/attachment-0001.htm>
More information about the Dnsmasq-discuss
mailing list