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

[Geert Stappers]

On Sun, May 16, 2021 at 03:40:52PM +0100, Jesus M Diaz wrote:
> > > > ...
> > >    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
> 
> 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
 
More like
} So, this is how the identification should happen and I hope 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]


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

Note that the 'set:' is before '<hwaddr>'


> (...)
> 
> 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.

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.




Groeten
Geert Stappers
-- 
Silence is hard to parse