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

Jesus M Diaz jesusm.diazperez at gmail.com
Sun May 16 17:48:59 UTC 2021


> at 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
>
>
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]
>
> set:mobile,
>    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

(yes, I know, it is a different device than before, but exactly same
configuration and scenario)


> > (...)
> >
> > 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.
>
>
That's interesting, I will search those posts.

Thanks for the ideas!

Jesus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210516/fc52e576/attachment-0001.htm>


More information about the Dnsmasq-discuss mailing list