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

2021-05-19 Thread Jesus M Diaz 
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@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@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-18 Thread Geert Stappers via Dnsmasq-discuss 
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@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-17 Thread Jesus M Diaz 
>
> 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. It's true that I
tried this using 2.75, now that I am running 2.85 I can try again (yes, I
updated again with the current code from thekelleys.co.uk).


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

 Thanks!
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-17 Thread Jesus M Diaz 
A couple of new things:

1. I have updated the version of dnsmasq from 2.72 to 2.82, cloned
from *https://salsa.debian.org/debian/dnsmasq
* and compiled locally.

2. Now I see a more explicit message in the log, making very clear the
wrong behaviour:

tail -f /opt/var/log/dhcp | grep d0:4d:e3
May 17 09:11:38 cinemateka dnsmasq-dhcp[1726]: 1039677414 DHCPREQUEST(eth0)
192.168.0.217 96:8d:d4:d0:4d:e3

*May 17 09:11:38 cinemateka dnsmasq-dhcp[1726]: 1039677414 DHCPNAK(eth0)
192.168.0.217 96:8d:d4:d0:4d:e3 address in useMay 17 09:11:38 cinemateka
dnsmasq-dhcp[1726]: not using configured address 192.168.0.217 because it
is leased to a4:50:46:d0:4d:e3*
May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 3254867558
DHCPDISCOVER(eth0) 96:8d:d4:d0:4d:e3

*May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 3254867558 DHCPOFFER(eth0)
192.168.0.234 96:8d:d4:d0:4d:e3 May 17 09:11:41 cinemateka
dnsmasq-dhcp[1726]: not using configured address 192.168.0.217 because it
is leased to a4:50:46:d0:4d:e3*
May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 402483634 DHCPDISCOVER(eth0)
96:8d:d4:d0:4d:e3
May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 402483634 DHCPOFFER(eth0)
192.168.0.234 96:8d:d4:d0:4d:e3
May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 402483634 DHCPREQUEST(eth0)
192.168.0.234 96:8d:d4:d0:4d:e3
May 17 09:11:41 cinemateka dnsmasq-dhcp[1726]: 402483634 DHCPACK(eth0)
192.168.0.234 96:8d:d4:d0:4d:e3 xiaomi-a2

So, dnsmasq clearly identifies the client and it knows there is a static
lease configured, but it ignores it.

I also found other thread in the mailing list (not sure if this was the one
you talked of, Geert), *[Dnsmasq-discuss] "multiple MAC addresses in a
single dhcp-host" vs "multiple dhcp-host lines with the same IP address"*,
where in the answers Simon Kelly says:

Yes. The difference is that in the normal case of multiple lines, once
the IP address is leased to a MAC address, if another MAC address turns
up asking for a lease, it won't be offered that IP address (typically it
will be offered one from the pool) *With multiple MAC addresses on a
single line, when the second MAC address turns up, the IP address will
be unceremoniously ripped away from the first MAC address, and given to
the second one.*

But that is not being my case.

Thanks
Jesus M Diaz




On Mon, 17 May 2021 at 07:28, Geert Stappers via Dnsmasq-discuss <
dnsmasq-discuss@lists.thekelleys.org.uk> wrote:

> On Sun, May 16, 2021 at 06:48:59PM +0100, Jesus M Diaz wrote:
> > > >
> > > > 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=[][,id:|*][,set:][tag:][,][,][,][,ignore]
> > >
> > > }   dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s
> > >
> > > Note that the 'set:' is before ''
> > >
> > >
> > 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
> >
>[ ... ]
> > > > 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.
>
> Please do.
>
>
> > Thanks for the ideas!
>
> AIUI are more ideas needed.
>
>
> > Jesus M
>
>
>
> Groeten
> Geert Stappers
> --
> Silence is hard to parse
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
>

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

2021-05-17 Thread Geert Stappers via Dnsmasq-discuss 
On Sun, May 16, 2021 at 06:48:59PM +0100, Jesus M Diaz wrote:
> > >
> > > 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=[][,id:|*][,set:][tag:][,][,][,][,ignore]
> >
> > }   dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s
> >
> > Note that the 'set:' is before ''
> >
> >
> 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
> 
   [ ... ]
> > > 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.

Please do.

 
> Thanks for the ideas!

AIUI are more ideas needed.

 
> Jesus M



Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-16 Thread Jesus M Diaz 
> 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=[][,id:|*][,set:][tag:][,][,][,][,ignore]
>
> set:mobile,
>dhcp-host=set:mobile,*:*:*:63:ea:55,samsungA30s
>
> Note that the 'set:' is before ''
>
>
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
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-16 Thread Geert Stappers via Dnsmasq-discuss 
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=[][,id:|*][,set:][tag:][,][,][,][,ignore]


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

Note that the 'set:' is before ''


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

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-16 Thread Jesus M Diaz 
Inline

>
> > That's an easy one,
>
> Okay.  Here other easy one:  Reply below previous text.
>
>
Nice to see easy comments.


> > I have the 'old' lease, the dnsmasq config and logs,
> > and tcpdump sniffing (see below). But the short story is:
> >
> >1. device asked some time ago for an ip-addr, and as it is configured
> to
> >get a static one, it got it (logged in the 'old' lease)
> >2. device disconnect from the router and connects to one AP, and after
> >reconnecting, request the same ip-addr with a new mac-addr
>
> a.k.a.  DHCP renewal
>

sure, I explained the story instead of using formal names, that's ok.


> >3. dnsmasq sees the 'old', and before even checking anything else (I
> >know this because there are no 'tags' assigned to the device),
> respond with
> >'address in use'
>
> Actual "IPv4 address in use"
>

same than previous coment


>
> >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
(did you see it in the previous post?):

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


>
> >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=[][,id:|*][,set:][tag:][,][,][,][,ignore]*

(...)

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.

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.

Thanks
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-16 Thread Geert Stappers via Dnsmasq-discuss 
On Sun, May 16, 2021 at 02:13:37PM +0100, Jesus M Diaz wrote:
> On Sun, 16 May 2021 at 13:48, Kristof Burek wrote:
> > >  
> > How do you know that the client is requesting the same IP address?  (Have
> > you been able to sniff the packets?)  Does the client "know" when its MAC
> > address has changed?
> 
> That's an easy one,

Okay.  Here other easy one:  Reply below previous text.

> I have the 'old' lease, the dnsmasq config and logs,
> and tcpdump sniffing (see below). But the short story is:
> 
>1. device asked some time ago for an ip-addr, and as it is configured to
>get a static one, it got it (logged in the 'old' lease)
>2. device disconnect from the router and connects to one AP, and after
>reconnecting, request the same ip-addr with a new mac-addr

a.k.a.  DHCP renewal


>3. dnsmasq sees the 'old', and before even checking anything else (I
>know this because there are no 'tags' assigned to the device), respond with
>'address in use'

Actual "IPv4 address in use"


>4. device requests for a new ip-addr with the new mac-addr

That new MAC address is the root cause of the "problem".


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



>assigns a new ip-addr because the old one is in use.
 

Which is good.




Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-16 Thread Discuss via Dnsmasq-discuss 
On Sun, May 16, 2021 at 11:18:29AM +0100, Jesus M Diaz wrote:
> Thanks for the answers, although they have more questions than real
> answers, lol

Those questions are real answers.

OKay, let me repharse that: Those questions are real responses.


Consider to respond to them to get you further.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-16 Thread Jesus M Diaz 
That's an easy one, I have the 'old' lease, the dnsmasq config and logs,
and tcpdump sniffing (see below). But the short story is:

   1. device asked some time ago for an ip-addr, and as it is configured to
   get a static one, it got it (logged in the 'old' lease)
   2. device disconnect from the router and connects to one AP, and after
   reconnecting, request the same ip-addr with a new mac-addr
   3. dnsmasq sees the 'old', and before even checking anything else (I
   know this because there are no 'tags' assigned to the device), respond with
   'address in use'
   4. device requests for a new ip-addr with the new mac-addr
   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.
   6. dnsmasq, despite having identified the client, assigns a new ip-addr
   because the old one is in use.

This last step is the wrong one in my opinion, at least inconsistent with
the dnsmasq man page.

*DNSMASQ 'old' lease*:

[20210516-123037] 192.168.0.230   / 88:a3:03:63:ea:55 samsungA30s

*DNSMASQ config for this device*:

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

*DNSMASQ logs*:

May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP
range: 192.168.255.10 -- 192.168.255.100
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP
range: 192.168.0.251 -- 192.168.0.254
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP
range: 192.168.0.201 -- 192.168.0.250
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 available DHCP
range: 192.168.0.30 -- 192.168.0.49
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 vendor class:
android-dhcp-10
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 client provides
name: Catuxas

*May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 DHCPREQUEST(eth0)
192.168.0.230 96:8d:d4:63:ea:55 May 16 13:15:37 cinemateka
dnsmasq-dhcp[3324]: 448030863 DHCPNAK(eth0) 192.168.0.230 96:8d:d4:63:ea:55
address in use*
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 broadcast response
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 sent size:  1
option: 53 message-type  6
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 sent size:  4
option: 54 server-identifier  192.168.0.105
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 448030863 sent size: 14
option: 56 message  61:64:64:72:65:73:73:20:69:6e:20:75:73:65
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP
range: 192.168.255.10 -- 192.168.255.100
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP
range: 192.168.0.251 -- 192.168.0.254
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP
range: 192.168.0.201 -- 192.168.0.250
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 available DHCP
range: 192.168.0.30 -- 192.168.0.49
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 vendor class:
android-dhcp-10
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 client provides
name: Catuxas
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 DHCPDISCOVER(eth0)
96:8d:d4:63:ea:55

*May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 tags: mobile,
known, pasillo, eth0May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]:
331930296 DHCPOFFER(eth0) 192.168.0.244 96:8d:d4:63:ea:55 *
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options:
1:netmask, 3:router, 6:dns-server, 15:domain-name,
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options:
26:mtu, 28:broadcast, 51:lease-time, 58:T1,
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 requested options:
59:T2, 43:vendor-encap
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 next server:
192.168.0.105
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  1
option: 53 message-type  2
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  4
option: 54 server-identifier  192.168.0.105
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  4
option: 51 lease-time  30m
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  4
option: 58 T1  15m
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  4
option: 59 T2  26m15s
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  4
option:  1 netmask  255.255.255.0
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  4
option: 28 broadcast  192.168.0.255
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  6
option: 15 domain-name  triana
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  4
option:  3 router  192.168.0.1
May 16 13:15:37 cinemateka dnsmasq-dhcp[3324]: 331930296 sent size:  8
option:  6 dns-server  192.168.0.105, 192.168.0.1

*TCPDUMP sniffing*:

13:15:37.327596 96:8d:d4:63:ea:55 > 6c:72:20:05:96:6e,

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

2021-05-16 Thread Kristof Burek 
Hi, Jesus and dnsmasq-discuss,

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

How do you know that the client is requesting the same IP address?  (Have
you been able to sniff the packets?)  Does the client "know" when its MAC
address has changed?  In the case of disconnecting wired and reverting to
Wi-Fi (the scenario I referred to in my earlier email) the client device
"knows" something has happened and _immediately_ does something about it,
i.e. tries to re-connect using the other MAC address (issues new DHCP
discover [DHCPDISCOVER]requests etc).

In your case your client might change the AP it is using but might not have
the nous to grok that its MAC address has changed so may not even issue a
new DHCP request --- at least until DHCP option T1 has expired.  And then it
wouldn't be a "discover" [DHCPDISCOVER] request (as in my scenario) but a
"renew" [DHCPREQUEST] request which probably and understandably wouldn't be
accounted for in dnsmasq's current logic.

So, I don't know if there is a minimum value for T1, but try setting it to
say 5 seconds for the static IP devices that move AP and see what happens?
(This will, of course, mean a fair amount of extra DHCP traffic on your
network but I venture that it won't swamp other traffic as long as the
number of such devices isn't too large.)

(My theory goes that if your clients can't tell when their MAC address has
changed, but try to renew their DHCP lease 5 seconds [/the minimum T1 value]
after the last one was granted then, on moving AP, re-connection will happen
within 2.5 seconds on average.  If "renew" doesn't work then it would have
to be a "re-bind" which is issued after T2 expires if "renewal" failed after
T1's expiry, so make T2 say 10 seconds? U!)

You will of course need to tag these devices in dnsmasq's config
appropriately so you can give just those the special T1 and T2 values.

Otherwise you will just have to make the lease times as short as possible (I
believe 2min is the minimum) so that DHCP starts right from the beginning.

Let me tell you that, in a way, I hope my first solution doesn't work as I
consider it supremely inelegant!  But, if it does I would be pleased both
for you and for myself! ... There would still be <= 5|10 seconds downtime of
connectivity which isn't that great.  If it doesn't work then one possible
solution would be to modify dnsmasq to abandon leases associated with a
particular MAC address when receiving packets other than "discover". Hmmm,
Mr Kelly is busy enough as it is I suspect and who knows what else this
could break.  That's why it would be good to know if TP-Link are developing
their equipment according to any RFCs.

Kindness to all kinds
Kristof


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-16 Thread Jesus M Diaz 
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:

 /--[AP1]\
> / \
>/---[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?

Thanks!
Jesus M



On Sat, 15 May 2021 at 12:38, Jesus M Diaz 
wrote:

> 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,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.*
>
>
> 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.
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-15 Thread Petr Menšík 
Hi Jesus,

To my best knowledge, access-points are usually transparent from direct
end clients. They do not change hardware address of clients going to AP
or any machines behind it.

In my experience, hardware access points doing just AP transparent
bridge are not problematic. Directly connected devices usually do not
have any problems. Problematic are often often clients behind wireless
client doing "transparent" bridge, which cannot be completely
transparent. In my schematics, only client-eth3 would have hardware
address mangled, because client-bridge3 connects to AP with single HW
address, but can provide connectivity for more than single client.
Usually those clients are highly problematic.

 client-w1 -\
 client-w2 -[ AP ]  [ router ] - [AP2]
client-eth3 --- client-bridge3 -/

If your APs indeed transform mac addresses of directly connected
clients, replacing them with different kind of AP or configuration might
work. I would expect AP directly connected to router/switch by cable
should work without problems.

Problems should arise with client-bridge3 and similar. That includes
also any kind of "repeaters" covering blind spots, when connected by
wifi itself. Without special connection it would connect its own clients
using different hw address. Just because client cannot use multiple mac
addresses without some hacks. Those hacks are usually on link layer.

If you have multiple APs, I would recommend using just APs connected by
ethernet cable to common switch. Avoid "transparent" clients, they often
work only half way.

My opinions, which might be wrong.

Cheers,
Petr

On 5/15/21 1:38 PM, Jesus M Diaz wrote:
> 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,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.*
> 
> 
> 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.
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík



OpenPGP_signature
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq not overriding leases for static assigments, by design

2021-05-15 Thread Geert Stappers via Dnsmasq-discuss 
On Sat, May 15, 2021 at 12:38:16PM +0100, Jesus M Diaz wrote:
> Hello,
 
Hi,


> 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.
 
Why?  Long / verbose:  I wonder **why** the Acces Point makes that change.


> 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,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.*
> 
> 
> 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?

Changing the Access Point configuration???
Changing the Access Points???

 
> Thanks in advance.

Please keep us, this mailinglist (archive), posted.



Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

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

2021-05-15 Thread Kristof Burek 
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]



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss