Client list mysteriously blanked out

Help
1

Expected Behaviour:

My client list should be resolving to an IP or the hostname I've defined in my /etc/hosts file. It was performing in this manner up until this afternoon. In case this is relevant, I modified a bunch of my docker stack earlier today, though my pi-hole is running on a dedicated raspberry pi. One of the containers I implemented was watchtower, and I'm wondering if this is correlated.

Actual Behaviour:

My client list is full of blank entries. I'm not even getting an IP address. I've checked, and I don't have any privacy settings enabled. Link to a photo of what I'm talking about.

Debug Token:

5ikfeuynmo

2

Your debug log looks normal.

What is the output of this command (checking to see what clients are logged in the pihole log)?

tail -n 50 /var/log/pihole.log

3

Yeah, functionality is still working. Tail of the log below...

Dec  3 02:56:40 dnsmasq[607]: 29541 192.168.0.170/50310 cached update.synodns.com is <CNAME>
Dec  3 02:56:40 dnsmasq[607]: 29541 192.168.0.170/50310 cached update-global.synodns.com is <CNAME>
Dec  3 02:56:40 dnsmasq[607]: 29541 192.168.0.170/50310 cached d678xndbtuwrj.cloudfront.net is 13.33.167.55
Dec  3 02:56:40 dnsmasq[607]: 29542 192.168.0.170/50310 query[AAAA] update.synology.com from 192.168.0.170
Dec  3 02:56:40 dnsmasq[607]: 29542 192.168.0.170/50310 cached update.synology.com is <CNAME>
Dec  3 02:56:40 dnsmasq[607]: 29542 192.168.0.170/50310 cached update.synodns.com is <CNAME>
Dec  3 02:56:40 dnsmasq[607]: 29542 192.168.0.170/50310 cached update-global.synodns.com is <CNAME>
Dec  3 02:56:40 dnsmasq[607]: 29542 192.168.0.170/50310 cached d678xndbtuwrj.cloudfront.net is NODATA-IPv6
Dec  3 02:56:46 dnsmasq[607]: 29543 192.168.0.109/57546 query[A] d.dropbox.com from 192.168.0.109
Dec  3 02:56:46 dnsmasq[607]: 29543 192.168.0.109/57546 forwarded d.dropbox.com to 8.8.4.4
Dec  3 02:56:46 dnsmasq[607]: 29543 192.168.0.109/57546 reply d.dropbox.com is <CNAME>
Dec  3 02:56:46 dnsmasq[607]: 29543 192.168.0.109/57546 reply d.v.dropbox.com is <CNAME>
Dec  3 02:56:46 dnsmasq[607]: 29543 192.168.0.109/57546 reply d-sjc.v.dropbox.com is 162.125.33.7
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 query[A] prod.http1.us-west-2.prodaa.netflix.com from 192.168.0.119
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 forwarded prod.http1.us-west-2.prodaa.netflix.com to 8.8.4.4
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 reply prod.http1.us-west-2.prodaa.netflix.com is 54.191.146.222
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 reply prod.http1.us-west-2.prodaa.netflix.com is 35.162.37.58
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 reply prod.http1.us-west-2.prodaa.netflix.com is 52.88.206.137
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 reply prod.http1.us-west-2.prodaa.netflix.com is 52.39.73.74
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 reply prod.http1.us-west-2.prodaa.netflix.com is 52.39.128.157
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 reply prod.http1.us-west-2.prodaa.netflix.com is 52.11.72.81
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 reply prod.http1.us-west-2.prodaa.netflix.com is 35.164.83.231
Dec  3 02:56:46 dnsmasq[607]: 29544 192.168.0.119/49751 reply prod.http1.us-west-2.prodaa.netflix.com is 34.215.58.212
Dec  3 02:56:52 dnsmasq[607]: 29545 192.168.0.109/56692 query[A] imap.gmail.com from 192.168.0.109
Dec  3 02:56:52 dnsmasq[607]: 29545 192.168.0.109/56692 forwarded imap.gmail.com to 8.8.4.4
Dec  3 02:56:52 dnsmasq[607]: 29545 192.168.0.109/56692 reply imap.gmail.com is <CNAME>
Dec  3 02:56:52 dnsmasq[607]: 29545 192.168.0.109/56692 reply gmail-imap.l.google.com is 108.177.112.109
Dec  3 02:56:52 dnsmasq[607]: 29545 192.168.0.109/56692 reply gmail-imap.l.google.com is 108.177.112.108
Dec  3 02:56:52 dnsmasq[607]: 29546 192.168.0.170/48955 query[AAAA] grafana.com from 192.168.0.170
Dec  3 02:56:52 dnsmasq[607]: 29546 192.168.0.170/48955 cached grafana.com is NODATA-IPv6
Dec  3 02:56:52 dnsmasq[607]: 29547 192.168.0.170/40887 query[A] grafana.com from 192.168.0.170
Dec  3 02:56:52 dnsmasq[607]: 29547 192.168.0.170/40887 cached grafana.com is 107.178.222.220
Dec  3 02:56:52 dnsmasq[607]: 29548 192.168.0.170/56159 query[AAAA] grafana.com from 192.168.0.170
Dec  3 02:56:52 dnsmasq[607]: 29548 192.168.0.170/56159 cached grafana.com is NODATA-IPv6
Dec  3 02:56:52 dnsmasq[607]: 29549 192.168.0.170/50544 query[A] raw.githubusercontent.com from 192.168.0.170
Dec  3 02:56:52 dnsmasq[607]: 29549 192.168.0.170/50544 forwarded raw.githubusercontent.com to 8.8.4.4
Dec  3 02:56:52 dnsmasq[607]: 29550 192.168.0.170/35988 query[AAAA] raw.githubusercontent.com from 192.168.0.170
Dec  3 02:56:52 dnsmasq[607]: 29550 192.168.0.170/35988 forwarded raw.githubusercontent.com to 8.8.4.4
Dec  3 02:56:52 dnsmasq[607]: 29550 192.168.0.170/35988 reply raw.githubusercontent.com is <CNAME>
Dec  3 02:56:52 dnsmasq[607]: 29550 192.168.0.170/35988 reply github.map.fastly.net is NODATA-IPv6
Dec  3 02:56:52 dnsmasq[607]: 29551 192.168.0.170/43060 query[AAAA] raw.githubusercontent.com from 192.168.0.170
Dec  3 02:56:52 dnsmasq[607]: 29551 192.168.0.170/43060 cached raw.githubusercontent.com is <CNAME>
Dec  3 02:56:52 dnsmasq[607]: 29551 192.168.0.170/43060 cached github.map.fastly.net is NODATA-IPv6
Dec  3 02:56:52 dnsmasq[607]: 29549 192.168.0.170/50544 reply raw.githubusercontent.com is <CNAME>
Dec  3 02:56:52 dnsmasq[607]: 29549 192.168.0.170/50544 reply github.map.fastly.net is 151.101.0.133
Dec  3 02:56:52 dnsmasq[607]: 29549 192.168.0.170/50544 reply github.map.fastly.net is 151.101.64.133
Dec  3 02:56:52 dnsmasq[607]: 29549 192.168.0.170/50544 reply github.map.fastly.net is 151.101.128.133
Dec  3 02:56:52 dnsmasq[607]: 29549 192.168.0.170/50544 reply github.map.fastly.net is 151.101.192.133
Dec  3 02:57:01 dnsmasq[607]: 29552 192.168.0.104/41410 query[A] msmetrics.ws.sonos.com from 192.168.0.104
Dec  3 02:57:01 dnsmasq[607]: 29552 192.168.0.104/41410 /etc/pihole/gravity.list msmetrics.ws.sonos.com is 0.0.0.0
4

Try two things:

sudo service pihole-FTL restart

If no improvement, clear browser cache and restart browser

5

Hmm, seeing some odd behavior. When I restart the service, my IP's pop back into the client list for ~15 seconds before they get wiped again. Clearing the cache / trying a different browser doesn't solve the issue.

6

@Mcat12 Have you seen this before?

7

Please reboot the Pi and see if that resolves it.

8

A reboot did not solve the problem.

It's not a huge deal, as the blocking is still working. But at this point I'm more curious than anything...

9

I am curious as well.

10

Perhaps another relevant piece of info -- the one IP that is showing up in the client table is the only one not in my /etc/hosts file. I'm wondering if the table gets wiped when trying to resolve the IP's against that table.

I'll try wiping the /etc/hosts file to see if that has any impact.

11

Replying to myself... the issue is definitely with the /etc/hosts file. When I wiped all of my entries, I solved the issue. When I try to add back a mapping, the issue re-presents itself for any IP in the hosts file.

12

What are the contents of the hosts file?

13

Here's what it is currently. Link to result in the client list on the admin page. The one blank device is at 192.168.0.170.

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
192.168.0.170   crystal
14

The one line I don't see in the /etc/hosts file is the alternate loopback address. This is typically the fifth line down. Don't know if it's related to the problem, but all my Pi-Holes have this entry by default.

127.0.1.1 raspberrypi

The name listed here is the first entry in your /etc/pihole/local.list file.

15

Added that line back in. Still no dice.

16

And for what it's worth, my /etc/pihole/local.list looks like:

192.168.0.101 raspberrypi
192.168.0.101 pi.hole
17

The local list is included in your debug log - that's how I got the name for your device.

One more easy thing to try: run pihole -r and select the repair option.

The next step after this might be to temporarily (if possible) suspend the changes in the docker container with watchtower and see if that resolves it.

18

The repair didn't solve the issue. I've also had watchtower disabled for the last few hours; that hasn't helped either.

19

OK. Perhaps one of the devs will have some insight.

20

Share some recent lines from the FTL log (/var/log/pihole-FTL.log). It will log whenever it gets a new client, and that might help find the issue. Also, run dig -x 192.168.0.170 and share the output.