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

Kristof Burek contact at kalvr.net
Sat May 15 15:30:14 UTC 2021


Hi Jesus and dnsmasq-discuss,

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

I'd be very interested to know which IETF/RFC this behaviour is specified in
before I embark on using mesh networking with dnsmasq myself.  Do mesh
devices _really_ do MAC-Address translation these days?  If so, then how is
a stand-alone DHCP server meant to know that it's talking to a device to
which it has already allocated an IP address and which wants to keep using
that address.  If the MAC address gets translated then all devices' ARP
tables would need updating too if they communicate with the device whose MAC
address got translated.

AFAIU the capability to specify multiple MAC addresses in the doc' snippet
you quoted is to account for when a wired device is disconnected and then
uses a different MAC address to re-connect via wifi.  But in that case it
_genuinely_ is a different device doing the (re-)connecting.  It seems to me
that this kind of MAC-Address Translation could be fraught with
compatibility issues and that maybe the DHCP server integrated into TP-Link
One-Mesh handles all these incompatibilities just fine.  A stand-alone DHCP
server maybe just can't for static IP address allocation!

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

Just to clarify the picture:  physically the Ethernet frame containing the
DHCP request/s will come via the link whose MAC is aN:bN:cN:dN:eN:fN (and
dnsmasq will have no way of knowing this value), but --- in the absence of
translation of course --- the DHCP request's frame's source MAC address (to
which any DHCP offer etc messages will presumably be directed) is still
A:B:C:D:E:F.  So maybe try removing the facility that does the MAC
translation or see if there are any other options to configure it, e.g. some
kind of exclusion list.

With MAC-address translation of this kind it seems to me that there either
has to be a protocol to update other devices as to this change of MAC
address or maybe you could consider using IPv6 which almost certainly
handles this sort of thing better.

As I'm just getting into using dnsmasq I find this a really interesting set
of observations, but I acknowledge I probably didn't help you much.

Kindness to all kinds
Kristof [maiden contribution to the list]





More information about the Dnsmasq-discuss mailing list