A couple of new things: 1. I have updated the version of dnsmasq from 2.72 to 2.82, cloned from *https://salsa.debian.org/debian/dnsmasq <https://salsa.debian.org/debian/dnsmasq>* and compiled locally.
2. Now I see a more explicit message in the log, making very clear the wrong behaviour: tail -f /opt/var/log/dhcp | grep d0:4d:e3 May 17 09:11:38 cinemateka dnsmasq-dhcp[1726]: 1039677414 DHCPREQUEST(eth0) 192.168.0.217 96:8d:d4:d0:4d:e3 *May 17 09:11:38 cinemateka dnsmasq-dhcp[1726]: 1039677414 DHCPNAK(eth0) 192.168.0.217 96:8d:d4:d0:4d:e3 address in useMay 17 09:11:38 cinemateka dnsmasq-dhcp[1726]: not using configured address 192.168.0.217 because it is leased to a4:50:46:d0:4d:e3* May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 3254867558 DHCPDISCOVER(eth0) 96:8d:d4:d0:4d:e3 *May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 3254867558 DHCPOFFER(eth0) 192.168.0.234 96:8d:d4:d0:4d:e3 May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: not using configured address 192.168.0.217 because it is leased to a4:50:46:d0:4d:e3* May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 402483634 DHCPDISCOVER(eth0) 96:8d:d4:d0:4d:e3 May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 402483634 DHCPOFFER(eth0) 192.168.0.234 96:8d:d4:d0:4d:e3 May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 402483634 DHCPREQUEST(eth0) 192.168.0.234 96:8d:d4:d0:4d:e3 May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 402483634 DHCPACK(eth0) 192.168.0.234 96:8d:d4:d0:4d:e3 xiaomi-a2 So, dnsmasq clearly identifies the client and it knows there is a static lease configured, but it ignores it. I also found other thread in the mailing list (not sure if this was the one you talked of, Geert), *[Dnsmasq-discuss] "multiple MAC addresses in a single dhcp-host" vs "multiple dhcp-host lines with the same IP address"*, where in the answers Simon Kelly says: Yes. The difference is that in the normal case of multiple lines, once the IP address is leased to a MAC address, if another MAC address turns up asking for a lease, it won't be offered that IP address (typically it will be offered one from the pool) *With multiple MAC addresses on a single line, when the second MAC address turns up, the IP address will be unceremoniously ripped away from the first MAC address, and given to the second one.* But that is not being my case. Thanks Jesus M Diaz On Mon, 17 May 2021 at 07:28, Geert Stappers via Dnsmasq-discuss < dnsmasq-discuss@lists.thekelleys.org.uk> wrote: > On Sun, May 16, 2021 at 06:48:59PM +0100, Jesus M Diaz wrote: > > > > > > > > So, this is how the identification happens and I can know it did > happen > > > > > > More like > > > } So, this is how the identification should happen and I hope it did > happen > > > > > > > > well, setting the tag 'mobile' and 'known' means dnsmasq found it in the > > config file, that is a good hint to assume it was identified ;-) > > > > > > > > > > > > > assigns a new ip-addr because the old one is in use. > > > > > > > > > > Which is good. > > > > > > > > > Unless in the dnsmasq man page it is said: > > > > > > > > -G, > --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][tag:<tag>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore] > > > > > > } dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s > > > > > > Note that the 'set:' is before '<hwaddr>' > > > > > > > > well, you are right, and that could mean something, let me try changing > the > > line in the configuration file to: > > > > dhcp-host=*:*:*:d0:4d:e3,set:mobile,xiaomi-a2 > > > > and ... it doesn't work, exactly the same situation than before, and the > > two leases can be seen: > > > > [20210516-181226] 192.168.0.232 / a4:50:46:d0:4d:e3 xiaomi-a2 > > [20210516-180445] 192.168.0.222 / 96:8d:d4:d0:4d:e3 * > > > > the lease with a name is the new one, so, a new hint dnsmasq identifies > the > > client and set the configured name removing it from the previous lease > ... > > but assigns a new ip-addr > > > [ ... ] > > > > both wired and wireless interfaces. > > > > In this case, the behaviour is not the expected, hence, cannot be > good. > > > > > > I think some pieces of the puzzle are missing. > > > > > > > > > > > > > And this is my only point. I am not arguing if tp-link one-mesh > > > > access-points are doing well by changing the client mac-address, nor > if I > > > > am being smart or stupid using wildcards to identify dhcp-clients, > nor if > > > > my whole configuration makes sense. The only point is why dnsmasq is > not > > > > abandoning the previous lease if the man page says it would do it. > > > > > > IIRC was on the mailinglist in the last six months a "works for me" > report > > > about switching from ethernet to WIFI and keeping IPv4 address. > > > > > > > > That's interesting, I will search those posts. > > Please do. > > > > Thanks for the ideas! > > AIUI are more ideas needed. > > > > Jesus M > > > > Groeten > Geert Stappers > -- > Silence is hard to parse > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss >
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
