Solution here is to keep it as it is until a solution is found? (or change the Range Extender )
Workaround would be to "tag" those devices and give them a fixed IP, along with their entry in the /etc/hosts - but I'd love to avoid this, if possible...
Question - out of curiosity;
Independently of the MAC addresses "masked" behind the RE's one, how this impact the identifiability of a client?
Correct me if I'm wrong, but devices are not identified by MAC Address, but via their IPs (as any DNS does), and names (in my case) are fetched from the /etc/hosts, right?
I mean, if the'd be identified by MAC, they'd be showing up as one single client, and not like 3 different client, with the same name, but with their own query count.
Maybe they have their own stats because they actually have different IPs, but the name is randomly-picked from one of the client having that MAC address?
Whenever this fetching by IP address returns no results we fall back to checking the Network table as a secondary source of truth. This is typically helpful when a device has a host name for its IPv4 address but not for its IPv6 address. having the network table as secondary source of host names will give us the expected host name also for the IPv6 address (belonging to the same device).
In your case, one of the devices with the same MAC but different IPs had the hostname galaxy_a7. And the network table thinks that it can get a hostname for this one device here. So it got the same name for all three devices.
We're currently working on a Network table improvement which will keep IP -> hostname associations and may be better suited to think about possible ways around this.
You may need to add your range extender as an upstream DNS server to get the names from it.
Note: Most models of RE adopt Proxy mode by default and cannot be changed. RE355 and RE450 only support Universal Mode
Part B:If Range Extender is working in Universal Mode
In this mode, Range Extender will replace all its clients’ MAC addresses with RE’s own MAC address! That means we only need to type RE’s MAC address in the MAC Filtering of the router:
Okay, so that's bad. It means that the range extender knows the host names of the devices but does not tell us. Who is their DHCP server? I guess it has to be the range extender itself, otherwise the router would have no idea that it would have to give them distinct addresses (they all look to be the same device).
When we find out who is the DHCP server, then we may be able to do something more.
Their DHCP server is the router, on the RE the DHCP is set to Off:
(It's in Italian but i guess it's understandable, lemme know if something's not clear)
In that case, your TP-Link is likely only acting as a DHCP relay agent, so it doesn't know the names, but your router should.
We could also experiment with configuring your TP-Link as DHCP server, but should first establish whether your router is currently aware of the correct names or not.
If you request reverse lookups for a TP-Link connected client from your router, does that yield the correct names? E.g. what is the output of the following command when run on your Pi-hole machine, assuming your router lives at .1?
This is very bad and some very strange behavior of the router. How could anyone in the network know any host names (without you configuring them manually somewhere)?...
Could I convince you to try to use the Pi-hole DHCP server and if it is only for testing? I use it myself for several years and never had a single issue with it. The benefit of this is that Pi-hole immediately has all the DHCP host names knowledge.
Believe it or not, I was doing some research about it yesterday, I spent the entire afternoon trying to get it to work, it worked for a while but then it was either unstable as hell or I wasn't able to reach any LAN IPs, no guides online on how to configure OpenWRT on this freaking TP-Link trashcan, well long story short, ended up by bricking it, while trying to roll back to stock firmware (don't laugh, please...)
I'm back with my old RE, still a TP-Link, still the same MAC masking behavior, so nothing changed (at least as per the initial configuration...)
Usually this is just a switch to on. The inbuilt DHCP server pings an IP address before handing out a new lease to ensure there is no old lease (generated by the router) for this IP address. This should eliminate the possibility for IP conflicts.
Since it's not a blocking problem, as per the PiHole functionality, I'll leave it as it is (DHCP on my router, DNS on PiHole) waiting for that "patch" to come out:
In the meantime, I can workaround it by simply giving a name to those clients (A.Watches, Firestick...)
)
) , tried with every client connected (3, atm)