<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>at identification happen???<br>
> ><br>
> ><br>
> will answer #5 and #6 together: in the config file line for this device<br>
> <br>
> dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s<br>
> <br>
> I am setting a name (samsungA30s), a tag (mobile) and a mac-addr pattern<br>
> that both the initial lease and the new one match.<br>
> <br>
> In the dnsmasg log I pasted before, for the new dhcp request after the dhcp<br>
> renewal fails, it can be seen several tags:<br>
> <br>
> May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 tags: mobile, known, pasillo, eth0<br>
> <br>
>    - tag:pasillo, set in the config file to all clients connecting through<br>
>    that AP, and I can identify them because the AP changes the mac-addr of the<br>
>    clieny with part of it owns mac-addr:<br>
> <br>
> dhcp-mac=set:pasillo,96:8d:d4:*:*:*<br>
> <br>
> <br>
>    - tag:mobile, set in the dhcp-host line above<br>
>    - tag:eth0, set automatically because it is the interface where the dhcp<br>
>    request came through<br>
>    - tag:know, set automatically because the client is identified as<br>
>    configured in the config file<br>
> <br>
> So, this is how the identification happens and I can know it did happen<br>
<br>
More like<br>
} So, this is how the identification should happen and I hope it did happen<br>
<br></blockquote><div><br></div><div>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 ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>> > >    assigns a new ip-addr because the old one is in use.<br>
> ><br>
> ><br>
> > Which is good.<br>
> ><br>
> ><br>
> Unless in the dnsmasq man page it is said:<br>
> <br>
> -G, --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][tag:<tag>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore]<br>
<br>
set:mobile,<br>
   dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s<br>
<br>
Note that the 'set:' is before '<hwaddr>'<br>
<br></blockquote><div><br></div><div>well, you are right, and that could mean something, let me try changing the line in the configuration file to:</div><div><br></div><div><font face="monospace">dhcp-host=*:*:*:d0:4d:e3,set:mobile,xiaomi-a2</font><br></div><div><br></div><div>and ... it doesn't work, exactly the same situation than before, and the two leases can be seen:</div><div><br></div><div><font face="monospace">  [20210516-181226] 192.168.0.232   / a4:50:46:d0:4d:e3 xiaomi-a2<br>  [20210516-180445] 192.168.0.222   / 96:8d:d4:d0:4d:e3 *</font><br></div><div><br></div><div>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<br></div><div><br></div><div>(yes, I know, it is a different device than before, but exactly same configuration and scenario)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> (...)<br>
> <br>
> As a special case, in DHCPv4, it is possible to include more than one<br>
> hardware address. eg:<br>
> *--dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2* This allows<br>
> an IP address to be associated with multiple hardware addresses, and gives<br>
> dnsmasq permission to abandon a DHCP lease to one of the hardware addresses<br>
> when another one asks for a lease. Beware that this is a dangerous thing to<br>
> do, it will only work reliably if only one of the hardware addresses is<br>
> active at any time and there is no way for dnsmasq to enforce this. It is,<br>
> for instance, useful to allocate a stable IP address to a laptop which has<br>
> both wired and wireless interfaces.<br>
> In this case, the behaviour is not the expected, hence, cannot be good.<br>
<br>
I think some pieces of the puzzle are missing.<br>
<br>
<br>
<br>
> And this is my only point. I am not arguing if tp-link one-mesh<br>
> access-points are doing well by changing the client mac-address, nor if I<br>
> am being smart or stupid using wildcards to identify dhcp-clients, nor if<br>
> my whole configuration makes sense. The only point is why dnsmasq is not<br>
> abandoning the previous lease if the man page says it would do it.<br>
<br>
IIRC was on the mailinglist in the last six months a "works for me" report<br>
about switching from ethernet to WIFI and keeping IPv4 address.<br>
<br></blockquote><div><br></div><div>That's interesting, I will search those posts.</div><div><br></div><div>Thanks for the ideas!</div><div><br></div><div>Jesus M</div><div><br></div><div><br></div><div><br></div></div></div>