[Dnsmasq-discuss] dnsmasq not overriding leases for static assigments

[Jesus M Diaz]

Inline

>
> > That's an easy one,
>
> Okay.  Here other easy one:  Reply below previous text.
>
>
Nice to see easy comments.


> > 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
>
> a.k.a.  DHCP renewal
>

sure, I explained the story instead of using formal names, that's ok.


> >    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'
>
> Actual "IPv4 address in use"
>

same than previous coment


>
> >    4. device requests for a new ip-addr with the new mac-addr
>
> That new MAC address is the root cause of the "problem".
>
>
never said otherwise.


>
> >    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.
>
> I don't understand that   .  I think it tries to explain "available IPv4
> address in best fit dhcp-range".
>
> >    6. dnsmasq, despite having identified the client,
>
> And how did that identification happen???
>
>
will answer #5 and #6 together: in the config file line for this device
(did you see it in the previous post?):

dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s

I am setting a name (samsungA30s), a tag (mobile) and a mac-addr pattern
that both the initial lease and the new one match.

In the dnsmasg log I pasted before, for the new dhcp request after the dhcp
renewal fails, it can be seen several tags:

May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 tags: mobile,
known, pasillo, eth0

   - 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:

dhcp-mac=set:pasillo,96:8d:d4:*:*:*


   - tag:mobile, set in the dhcp-host line above
   - tag:eth0, set automatically because it is the interface where the dhcp
   request came through
   - tag:know, set automatically because the client is identified as
   configured in the config file

So, this is how the identification happens and I can know it did happen


>
> >    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]*

(...)

As a special case, in DHCPv4, it is possible to include more than one
hardware address. eg:
*--dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2* 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.
In this case, the behaviour is not the expected, hence, cannot be good.

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.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210516/65a574f5/attachment.htm>