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

Jesus M Diaz jesusm.diazperez at gmail.com
Sun May 16 10:18:29 UTC 2021

Thanks for the answers, although they have more questions than real
answers, lol

I will try to summarize everything here.

This the the diagram of my home network:

>                     /             \
>                    /---[AP2]-----\ \
>                   /               \ \
> Wireless Clients -----[AP3]------\ \ \
>                   \               \ \ \
>                    \ ------------[Router]------- Internet
>                                    / |
>                    /--[Hub]--\    /  |
>    Wired Clients --           ---/   |
>                    \---------/       |
>                                      |
>                               DHCP (dnsmasq)

Few wireless clients will always connect to the same AP (including the
router), simply due to where they are located in the house. Other, on the
other hand, will by definition change from one AP to other (mobile phones,
for example), so I cannot know which AP would be their link point.
Regardless the AP used or if they connect to the router wired, dnsmasq will
see all DHCP requests from the same interface, eth0.

To the general question 'why TP-Link APs translate the mac'? I do not
really know (and I have asked them, without an answer), but my guess is
that it is to avoid too many arp-table changes among the 4 AP devices, so
the router will know where to send the packets all the time. And by the
way, no, the embedded DHCP server cannot control the multiple mac-addr for
the same host, that was indeed the main reason I moved to an external DHCP
server (later on I found dnsmasq much more flexible and giving me other
useful functionalities, so I'm happy with the move).

But being a very interesting discussion here, the topic was actually
another: if dnsmasq is supposed to be able to abandon a lease when a known
and legit mac-address is requesting that same ip-address, and the static
lease is configured, why is it not doing it?

Jesus M

On Sat, 15 May 2021 at 12:38, Jesus M Diaz <jesusm.diazperez at gmail.com>

> Hello,
> I have a 'TP-Link One-Mesh' system at home formed by the main router and
> three satellite access-points. It works really well making a good coverage
> over the house with smooth change from one AP to the other, but it has a
> caveat: for DHCP requests, the AP change the client mac-address with a
> combination of the three last duplas from the own AP mac-addr and the last
> three ones from the client itself.
> So, imagine my client mac-addr is A:B:C:D:E:F and my APs mac-addr are
> aN:bN:cN:dN:eN:fN, with N a number to identify the AP.
> If the client connects directly to the router, the dhcp request will come
> from A:B:C:D:E:F. But if it connects to one of the AP, the dhcp request
> will come from dN:eN:fN:D:E:F.
> This is not a problem for dynamic assignments (well, sometimes is for the
> name link in the dns part, but not critical).
> But when I have static leases the problems. I have defined dhcp-hosts
> entries with multiple mac-addr, something the documentations explain as:
> *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, 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.*
> But the reality is that when a second request comes, dnsmasq finds the IP
> is in used and assigns a new one from the global pool, instead of the
> static one.
> I have tried the configuration either using wildcards (*:*:*:D:E:F, given
> the last part of the mac-addr remains unchanged), but also defining each
> one of the possible cases
> (d1:e1:f1:D:E:F,d2:e2:f2:D:E:F,d3:e3:f3:D:E:F,A:B:C:D:E:F). Same outcome in
> both cases.
> Am I doing something wrong? Any idea how to fix this?
> Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210516/ae0580e7/attachment-0001.htm>

More information about the Dnsmasq-discuss mailing list