<div dir="ltr"><div>Inline</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>
> That's an easy one,<br>
<br>
Okay. Here other easy one: Reply below previous text.<br>
<br></blockquote><div><br></div><div>Nice to see easy comments.</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">
> I have the 'old' lease, the dnsmasq config and logs,<br>
> and tcpdump sniffing (see below). But the short story is:<br>
> <br>
> 1. device asked some time ago for an ip-addr, and as it is configured to<br>
> get a static one, it got it (logged in the 'old' lease)<br>
> 2. device disconnect from the router and connects to one AP, and after<br>
> reconnecting, request the same ip-addr with a new mac-addr<br>
<br>
a.k.a. DHCP renewal<br></blockquote><div><br></div><div>sure, I explained the story instead of using formal names, that's ok.</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>
> 3. dnsmasq sees the 'old', and before even checking anything else (I<br>
> know this because there are no 'tags' assigned to the device), respond with<br>
> 'address in use'<br>
<br>
Actual "IPv4 address in use"<br></blockquote><div><br></div><div>same than previous coment</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>
> 4. device requests for a new ip-addr with the new mac-addr<br>
<br>
That new MAC address is the root cause of the "problem".<br>
<br></blockquote><div><br></div><div>never said otherwise.</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>
> 5. dnsmasq identify the client (assigns the tags 'known' -it is in the<br>
> config file-, 'eth0' -interfaz-, 'mobile' -assigned to this device in the<br>
> config file- and 'pasillo' assigned in the config file to all devices<br>
> connected to that AP.<br>
<br>
I don't understand that . I think it tries to explain "available IPv4<br>
address in best fit dhcp-range".<br>
<br>> 6. dnsmasq, despite having identified the client,<br>
<br>
And how did that identification happen???<br>
<br></blockquote><div><br></div><div>will answer #5 and #6 together: in the config file line for this device (did you see it in the previous post?):</div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><font face="monospace"><span style="color:rgb(0,0,0);white-space:pre-wrap">dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s</span><br></font></div><div><br></div><div>I am setting a name (samsungA30s), a tag (mobile) and a mac-addr pattern that both the initial lease and the new one match.</div><div><br></div><div>In the dnsmasg log I pasted before, for the new dhcp request after the dhcp renewal fails, it can be seen several tags:</div><div><br></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><font face="monospace">May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 tags: mobile, known, pasillo, eth0</font></span><br></div><div><ul><li>tag:pasillo, set in the config file to all clients connecting through that AP, and I can identify them because the AP changes the mac-addr of the clieny with part of it owns mac-addr:</li></ul></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div><font face="monospace">dhcp-mac=set:pasillo,96:8d:d4:*:*:*</font></div></div></blockquote><div class="gmail_quote"><div><ul><li>tag:mobile, set in the dhcp-host line above</li><li>tag:eth0, set automatically because it is the interface where the dhcp request came through</li><li>tag:know, set automatically because the client is identified as configured in the config file</li></ul></div><div>So, this is how the identification happens and I can know it did happen</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></blockquote><div><br></div><div>Unless in the dnsmasq man page it is said:</div><div><br></div><div><dt style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><b>-G, --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][tag:<tag>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore]</b></dt><dd style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><p>(...)</p></dd><dd style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><p>As a special case, in DHCPv4, it is possible to include more than one hardware address. eg: <b>--dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2</b> This allows an IP address to be associated with multiple hardware addresses, and gives dnsmasq permission to abandon a DHCP lease to one of the hardware addresses when another one asks for a lease. Beware that this is a dangerous thing to do, it will only work reliably if only one of the hardware addresses is active at any time and there is no way for dnsmasq to enforce this. It is, for instance, useful to allocate a stable IP address to a laptop which has both wired and wireless interfaces.</p></dd></div><div>In this case, the behaviour is not the expected, hence, cannot be good. </div><div><br></div><div>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.</div><div><br></div><div>Thanks</div><div><br></div></div></div>