Old clients showing in the Top Clients

I previously raised this enquiry, however, it was automatically closed after 7 days from the last comment/update, which I added a comment on Sept 3rd.

(Old clients showing in the Top Clients (blocked only) view)

Any possibility of getting a response and a resolution?

Thanks

Better upload a new debug log and post the token?
They expire after 48 hours and get purged from the Pi-hole tricorder server.

You could try "Flush network table" in the Pi-hole settings:

http://pi.hole/admin/settings.php

Did you try stopping pihole-FTL before flushing?

sudo systemctl stop pihole-FTL

Flush, then restart:

sudo systemctl start pihole-FTL

https://tricorder.pi-hole.net/sg4In6KQ/

have done this now and uploaded the debug log token

OK, so pi-hole has been running for a few hours now after flusing the cache between stopping and restarting the FTL service and the same record of an old device and what was its IP has reappeared in the Top Clients lists.

The device and what was its IP address, do not physically exist within my network and no other devices have taken its place.
Any ideas why it keeps coming back?

What cache did you flush?

Sorry, I probably should have been more verbose in my recommendation:
There is no cache to clear, instead, you should have clicked Flush network table via Pi-hole's Settings | System.

Also, run from your Pi-hole machine, please share the output of:

echo ">top-clients(12) >quit" | nc localhost 4711

Also, whats make model of the router?

sorry for the delayed response.
The "flush" was by running pihole flush from the command line on my pihole machine.
I've now clicked the "Flush network table" button in Settings>System.

When I run "echo ">top-clients(12) >quit" | nc localhost 4711", the following is returned:

0 27997 172.16.200.241 pi.hole
1 27680 172.16.200.242 sd-vm-pihole-02.sandoverdrive.local
2 19306 172.16.200.247 sd-vm-uptimekuma-01.sandoverdrive.local
3 14181 172.16.100.103
4 12608 172.16.254.250 sd-uckg2p.sandoverdrive.local
5 7466 172.16.130.147
6 3949 172.16.200.202 rs815nas.sandoverdrive.local
7 2943 172.16.110.91 playstation5.sandoverdrive.local
8 2816 172.16.130.177
9 2596 172.16.110.201 sd-nuc-magicmirror-01.sandoverdrive.local
10 2537 172.16.200.250 sd-vm-wireguard-01.sandoverdrive.local
11 2404 172.16.130.126

This doesn't list the IP/device that I am seeing the pi-hole GUI.

What device would that be?

Could you share a screenshot?

Sorry for the late reply.
I am running an Edgerouter4 and there is no reference to the IP address or fqdn of the machine in question.

I originally had my pi-hole on a RasPi4 but ditched it for a VM in Proxmox, so it was a clean install from scratch. The IP and fqdn has been there from day 1.

admin can answer this very well.

Edgerouter is Ubiquiti.
Can you login to the shell on this box and check the file /etc/hosts ?

Eg:

cat /etc/hosts

EDIT: You could query that Edgerouter for what names it knows about with below (replace <EDGEROUTER_IP> with the actual IP):

echo 172.16.200.{1..254} | xargs -n 1 dig +short @<EDGEROUTER_IP> -x

EDIT2: Oh you have a couple of subnets.
Adjust above for the particular subnet!

EDIT3: Or if one big happy /12 subnet (could take a while if run below through xargs):

echo 172.{16..31}.{0..254}.{1..254}

Oops, was bout to head to the couch when I noticed above:

Using .local as a private top-level domain conflicts with Multicast DNS and may cause problems for users.

(Appendix G)

There was no reference to the IP address and/or device's fqdn in the hosts file on the Edgerouter.

Also, rather than running "echo 172.16.200.{1..254} | xargs -n 1 dig +short @<EDGEROUTER_IP> -x" for the entire IP range of the subnet, I narrowed the IP range to only the single IP address that I am seeing in pi-hole - 172.16.200.210, but I get the following response:
;; communications error to 172.16.254.251#53: timed out
;; communications error to 172.16.254.251#53: timed out
;; communications error to 172.16.254.251#53: timed out
;; no servers could be reached

Yes, i changed the <EDGEROUTER_IP> for the actual IP address of the Edgerouter

That command was tailored to query the box that does DHCP services for your network.
Most routers register hostnames in DNS that are advertised during the DHCP lease negotiation.
Is the Edgerouter doing DHCP services for your network?
If not, run that command against the box that does DHCP for your network?

If its a single IP that your're interested in, you can do below instead to do a reverse lookup (IP to name instead of name to IP):

dig +short @<DHCP_SERVER_IP> -x <CLIENT_IP>

Eg:

$ dig +short @10.0.0.2 -x 10.0.0.3
nas.home.dehakkelaar.nl.

Pi-hole does something similar to discover hostnames.

Also, what about below two?

Yes, the Edgerouter is performing the DHCP service for my network.
When I run dig +short @172.16.254.251 -x 172.16.200.210, I still get the same error as before:
;; communications error to 172.16.254.254#53: timed out
;; communications error to 172.16.254.254#53: timed out
;; communications error to 172.16.254.254#53: timed out
;; no servers could be reached

I'm not sure how the .local TLD would impact my setup and resolve my issue.
I don't have mDNS enabled anywhere within my network.

Either that Edgerouter box doesnt run a DNS service,
or no route exists from the host that you run that dig from to the Edgerouter IP 172.16.254.251.

You can search the logs for where Pi-hole gets those <OLD_HOSTNAME>'s from with below:

sudo less --pattern='is <OLD_HOSTNAME>' /var/log/pihole/pihole.log

Eg:

$ sudo less --pattern='is hakpc'  /var/log/pihole/pihole.log
[..]
Sep 15 03:00:00 dnsmasq[29841]: query[PTR] 143.0.0.10.in-addr.arpa from 127.0.0.1
Sep 15 03:00:00 dnsmasq[29841]: forwarded 143.0.0.10.in-addr.arpa to 10.0.0.2
Sep 15 03:00:02 dnsmasq[29841]: reply 10.0.0.143 is hakpc.home.dehakkelaar.nl

Above you see from top to bottom the reverse lookup made (the [PTR] query) by Pi-hole (127.0.0.1) for the 10.0.0.143 IP,
the IP address the query is being forwarded to (10.0.0.2 which is my DHCP server),
and the hakpc.home.dehakkelaar.nl reply from 10.0.0.2.

You might not have enabled it, but your OS can OOTB.
Windows 10 and up have mDNS default enabled.
Many Linux distros run an mDNS daemon OOTB.
And MacOS has Bonjour.

I would sort out the .local thingy first before troubleshooting any other issues.
You never know :wink:

Whats weird from above is that you address 172.16.254.251 as destination, but the error displays a different IP 172.16.254.254 thats trying to connect to.
Not sure whats going on here.

EDIT:

ip route get 172.16.254.251

traceroute -n 172.16.254.251

?

The .254 address is a virtual IP for .251.
I get the same result whether I specify either address.

Regards,
Darren