Oh wow! A fresh thread on the thing I just googled! I've had this problem since starting to use the Pi.hole as my DHCP server.
Here's an example; there's a Reolink Hub on this network which should have 192.168.1.123, but DHCP leases have clearly renewed and re-assigned it 192.168.1.108 - except that is named SCSMP01, a friend's desktop I worked on months ago.
Here's another example - SHDT-Z370XPSLI should be my desktop, which I'm on right now - pic 2 for the device's IP info - but it also seems to have KALILINUX. That's a VM that hasn't been online in over a month.
And here's some more examples of simply confusing naming. There are two MORE SHDTs in here (sure, probably for the LAN port - above was WiFi) as well as SCSLT02 (hasn't been online here in ~3 months) which seems to be shared by my Ubnt AP.
To be honest, the MAIN time I find myself getting frustrated by this issue is when I want to go hunting for the IP of a device--like the Reolink Hub, which is what led me to looking for this question just now--and having a tough time using the lease table to ACTUALLY pin down an IP. Old names and multiple IPs blur to make it just... Confusing.
It's a bit like the lease table doesn't query for new names from the devices if it recognises a previously used IP in it's list? As if 1.108 was once used for SCSLT01 so this NEW machine requesting 1.108 must also be that device? I'm no expert in how the Pi.hole works but that's my hunch!
Thanks for your help, in advance, everyone! (and thanks for the perfectly timed thread, haha!)
This isn't the same issue - you are referring to Pi-hole's Network overview, whereas MartynK's observation relates to Pi-hole's dashboard.
I'm going to split this in a separate topic.
Oh and by the way - flushing the network table does resolve this, but only in that it removes ALL resolved names, including those that are correct and incorrect. The incorrect entries inevitably return after a while though.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Your debug log shows two active DHCP servers on your network, your router's and Pi-hole's:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 548 bytes from eth0:192.168.1.1
Offered IP address: 192.168.1.100
DHCP options:
Message type: DHCPOFFER (2)
router: 192.168.1.1
dns-server: 192.168.1.192
dns-server: 1.1.1.1
--- end of options ---
* Received 300 bytes from eth0:192.168.1.192
Offered IP address: 192.168.1.164
DHCP options:
Message type: DHCPOFFER (2)
dns-server: 192.168.1.192
domain-name: "lan"
router: 192.168.1.1
--- end of options ---
Since your router is offering an IP of 192.168.1.100, while your Pi-hole runs on 192.168.1.192, that would demonstrate that your router's DHCP range isn't restricted to accommodate just your Pi-hole host machine's IP (which would be the recommended way to allow for DHCP servers to coexist).
In that scenario, your router may hand out DHCP leases for MACs that Pi-hole is also aware of, but with different IPs. Nevertheless, Pi-hole would of course receive DNS requests from those IPs, which it may associate with its own stored knowledge.
This would contribute to your observation, so you should address this first before further analysis.
Either restrict your router's DHCP range as suggested, or disable its DHCP server and make sure your Pi-hole machine has a static IP.
When done, ensure that all your devices have acquired or renewed their DHCP leases from Pi-hole's DHCP server, e.g. by dis- and reconnecting a device to your network, or by power-cycling a device.
Ooh, interesting - okay I think I get that. Unfortunately at the moment I'm on a crappy TP-Link Router and as far as I can see in there, I can only set a DHCP range if I'm using the router AS a DHCP server, otherwise the option is hidden. It's functioning in Relay mode, so it should be sending all DHCP queries to the defined address (1.192) instead. I'm not even sure why the router is offering 1.100 - that should be a NAS, and the router at 1.1.
I intend to move to an OPNsense unit soon which may negate this issue, but in the meantime I will see if I can find some obscure setting in here - I may have to set the device to DHCP server, change that setting, then set it BACK to being a Relay.
Just to be clear - if possible, you're saying that my DHCP lease range in the router should ONLY be 192.168.1.192-192, right?
Your debug log shows your router's DHCP server to be active, as there clearly is a DHCP server operating at 192.168.1.1.
It would be preferred if you would switch it off, but you should only do so after making sure your Pi-hole machine is configured for a static IP (via its OS's network management tool, not via Pi-hole's DHCP).
That, plus a DHCP lease reservation for your Pi-hole machine on your router's DHCP server, and/or an IP of 192.168.1.192 statically configured on the Pi-hole machine itself.
But disabling the router's DHCP server would be preferred.
Yep, definitely do (or did!) believe you, I'm just certain I had that setting switched off - except it wasn't! Must have done something at some point to reset network settings and forgotten to check it, or something - I did have it offline for a while on end, so perhaps it's a default to re-enable when left off. Anyway that solves THAT problem!
I'll reflush the table per the console inputs mentioned and see how it goes for a few days - I think I've managed to also add a static mapping for the Pihole too, so that should help. There's a bunch of static leases in here I can't delete but hopefully those no longer take effect now that it's back in relay mode!
Thanks for your help - will report back again with an update if it's worked (or hasn't!) soon!
