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

Jesus M Diaz jesusm.diazperez at gmail.com
Wed May 19 18:04:06 UTC 2021


Apologies for not responding before, I was making more tests.

I tested (again) with explicit mac-addr (4 ones) instead of using wildcards
... and it worked fine, for example:

May 18 17:07:04 cinemateka dnsmasq-dhcp[2497]: 1123473942 DHCPREQUEST(eth0)
> 192.168.0.249 a4:50:46:d0:4d:e3
> May 18 17:07:04 cinemateka dnsmasq-dhcp[2497]: abandoning lease to
> 96:8d:d4:d0:4d:e3 of 192.168.0.249
> May 18 17:07:04 cinemateka dnsmasq-dhcp[2497]: 1123473942 tags: mobile,
> known, eth0
> May 18 17:07:04 cinemateka dnsmasq-dhcp[2497]: 1123473942 DHCPACK(eth0)
> 192.168.0.249 a4:50:46:d0:4d:e3 xiaomi-a2


but I am not crazy and I know it failed, so what did I do? I downgraded
dnsmasq version to 2.75 that was the one I had initially, and:

May 19 09:05:16 cinemateka dnsmasq-dhcp[2212]: 2882342319 DHCPREQUEST(eth0)
> 192.168.0.249 96:8d:d4:d0:4d:e3
> May 19 09:05:16 cinemateka dnsmasq-dhcp[2212]: 2882342319 DHCPNAK(eth0)
> 192.168.0.249 96:8d:d4:d0:4d:e3 address in use
> May 19 09:05:16 cinemateka dnsmasq-dhcp[2212]: 2882342319 broadcast
> response


Same configuration file (except the line "dhcp-ignore-clid" I had to
comment, because that option is not valid in 2.75).

So I don't know why, my 2.75 is not working, and I don't know why (it was a
feature introduced in 2.47 I think). I have to say the 2.85 version I am
running was compiled in my box, cloning the sources from git://
thekelleys.org.uk/dnsmasq.git, while 2.75 was installed from binaries using
the repository of the Alt-F project. No idea if this is relevant.

The good point is that it is working now and whatever happened it is not
happening now.

Thanks a lot everybody for the ideas and questions that forces me to
investigate further.

Regards
Jesus M



On Tue, 18 May 2021 at 21:58, Geert Stappers via Dnsmasq-discuss <
dnsmasq-discuss at lists.thekelleys.org.uk> wrote:

> On Mon, May 17, 2021 at 10:21:57PM +0100, Jesus M Diaz wrote:
> > Simon Kelly wrote:
> > > To answer the question, the host doesn't get the same address because
> > > "multiple MAC addresses on the same line" is NOT the same as a MAC
> > > address with wildcards in it. If you had
> > >
> > > dhcp-host=96:8d:d4:d0:4d:e3,a4:50:46:d0:4d:e3,192.168.0.217
> > >
> > > then it would work, but
> > >
> > > dhcp-host=*:*:*:d0:4d:e3,192.168.0.217
> > >
> > > doesn't.
> > >
> > > I can't see why the code shouldn't  be altered to make this work, this
> > > is just a case that nobody anticipated.
> > >
> >
> > I tried with explicit mac-addresses (it's annoying to write 4 versions,
> but
> > not a big deal if it works), and I got the same result.
>
> Acknowledge on "Does not work with four explicit MAC addresses"
>
> What about  _two_ MAC addresses like
>
>    dhcp-host=*:*:*:d0:4d:e3,*:*:*:d0:4d:e3,192.168.0.217
>
> ???
>
>
> > > A possibly more tidy solution to this problem is to configure your
> > > clients to send client-IDs in their DHCP requests. If client-IDs are
> > > present, they totally override MAC addresses, so a client which always
> > > send the same clienr-ID will always be identified and keep the same IP
> > > address, even if its MAC address changes. Of course this only works if
> > > you're OS/DHCP client combination allows configuration of client-IDs.
> > > AFAIK all the common Linux ones do.
> > >
> > That would be really great, but unfortunately I don't control all the
> > devices, some of them being mobile phones with very little room to
> > configure.
>
> Consider that such "configuration" is already in place, that the DHCP
> client already sents a device name. Either factory default like
> "Android-d0-4d-e3" or end user tuned like "Bobs Collar".
>
>
> >  Thanks!
>
> Make another visit the mailinglist archive. Find back again
> the two MAC address posting (and share this time the link with us)
> IIRC is it a simular situation  ( same problem =>  same solution )
>
>
>
> Groeten
> Geert Stappers
> --
> Silence is hard to parse
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210519/e81a882c/attachment.htm>


More information about the Dnsmasq-discuss mailing list