I have searched around quite a bit and have yet to find a solution for this. I have found a few instances of similar issues, but no satisfactory resolution.
The problem: Somehow, incorrect client ID to IP mappings are being populated in the pi-hole network DB (and thus visible on the Tools > network page as well as polluting the query stats pages with incorrect values). By "incorrect" I mean that there are hostname->IP mappings shown in the network page for IP addresses that are not being used. (Previously, it was also combining multiple clients or mixing up clients, but I resolved that by making static DHCP entries for the affected clients). It appears the issue may actually stem from info tied to incorrect MAC addresses (i.e. an old hostname/IP combo gets connected to a MAC address for a totally different device that already has a proper hostname and IP)
(the x.x.x.25 IP and Amazon-Echo-Dot.jaawn.home hostname are the correct values for this device. The x.x.x.201 IP is not in use on the network and does not appear in any ARP info, DHCP, or DNS lookups. There is a device called "Jons-iPad" but it has a totally different IP address, obviously a different MAC address, and its correct hostname is Jons-iPad.jaawn.home. It appears further down the network table correctly).
Additional info:
All DNS lookups now return the correct hostname/IP info. This includes reverse lookups for the IPs (including that the "phantom" IPs correctly show no entries). The only place these phantom hostnames/IPs appear is in the pi-hole network DB (and the pages that depend on it). The rogue entries do not appear anywhere in DNS, DHCP, or ARP info on the pi or on the router. When I clear the network DB, the phantom entries return after a short time.
My router is running pfsense and it is handling DHCP for the network. All DNS is routed to the pi. All are fully up to date on latest versions.
What I have tried:
Clearing the network table, DHCP leases, and ARP cache on both the pi and router
Making static DHCP entries for affected clients to give them a dedicated IP and hostname in DHCP
Enabling the router's local DNS resolver, but disabling it in all settings in favor of the pi, then enabling conditional forwarding in the pi-hole config. This should (in theory) mean the router's DNS resolver is only used for getting a hostname for DHCP entries and it appears to be working as expected.
For some other "user" perspective, let me offer this has been brought up from time to time and I haven't seen a proposed resolution that completely fixes it for me, either.
When I've run into this issue (and it has been many times over the last couple of years), this is the process I used to resolve it:
Create an entry for the problem device listing in Local DNS/DNS Records (enter the desired hostname and the IP address that is currently assigned to your client device)
Go to Tools/Network and locate the entry for the device you are "correcting"; delete this entry
Wait a minute or two (assuming the device is active on the LAN), then check Tools/Network again for the problem device. Keep checking until it shows up again; when it appears, it should have the information you entered above in the Local DNS/DNS Records list.
Upon confirmation of the info in the prior step, go to Local DNS/DNS Records and delete the entry you created in the first step.
This process has enable me to fix problem entries and have the changes "stick" indefinitely, even if the devices IP address later changes via DHCP assignment.
Hopefully that helps work around this issue for those who might encounter it.
Thanks for the suggestion. I tried it and so far both affected devices show correctly. We'll see if it stays that way. I suppose I could set up both static DHCP entries and custom DNS entries for anything this happens to (so that it's a one-time fix), but that might mean eventually every device will need to be manually set that way, which really isn't ideal.
I started trying to dig through the code on Github but it isn't immediately clear what all populates the network-related tables in pi-hole's database. I am also looking through the database tables themselves and it seems like the issue might stem from old entries not being cleared from one of them. I'll see if I can find a way to recreate the problem and hopefully find a permanent solution
Well, I have stopped being able to reproduce the issue after editing the pihole-FTL.conf file and setting MAXNETAGE to 1, restarting the service, then commenting out my change and restarting the service again. This could absolutely just be a coincidence, but I'm leaving a comment here in case it helps anyone else who stumbles on this in the future.
At any rate, the root cause definitely seems related to the approaches taken to allow 1 client with both an IPv4 and an IPv6 entry to be treated as a single entity in various parts of the pi-hole configuration. It's also allowing separate clients to wind up combined together in unintentional ways sometimes. I'm not sure if it's an issue with DB joins or assumptions in certain bits of logic, but for now I can't troubleshoot anymore because it stopped happening.
