Web interface not showing clients connected, no blocking occuring since update to 4.3.2

Please follow the below template, it will help us to help you!

Expected Behaviour:

Pihole should work as expected as it did with v4.3.1 (i.e clients connect to dhcp server on pi, get IP addresses) all connections from those clients are logged and either allowed/blocked.

Actual Behaviour:

Now it seems to only show queriers logged that have come from the pi itself (127.0.0.1). I have DHCP turned on on the pi, turned off on my router, This seems to be working as all my clients on the network have internet access but the Pi isn't doing any blocking or registering them as even being connected according to the web admin interface. As I say in 4.3.1 it worked fine but I saw there was an update, so I logged onto the pi via ssh and firstly, did apt-get update and apt-get dist-upgrade, then ran pihole -up. It was after this it seemed to be working but then when I checked it a couple of days later the above issue had arisen. I ran pihole -r which seemed to fix it again, but yet again after a few days it broke again in the same way.

I thought perhaps I had file system corruption so I went and completely wiped the SD card in my pi, reinstalled Raspbian Buster Lite image to it, updated it with apt-get update and dist-upgrade, set that up how I had it setup before, installed pi-hole with the curl command, set that up how I had it set up before, turned on DHCP etc. plugged the pi into my network and powered it up and I had issues right away with the web interface stating the connection was lost and that DNS service wasn't running. So I ran pihole -r via ssh and that fixed that problem but then it just went right back how it was before I reinstalled everything as explained above.

I know it isn't blocking anything because when I look at one of those adblock test pages it says i'm not blocking ads.

Debug Token:

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

From a client that you believe should be using Pi-Hole as DNS server, run the following and see what server replies and the answer. The only DNS server that know the IP of pi.hole is Pi-Hole.

nslookup pi.hole

Thanks for the reply.

I get this response when I enter that command:

Server: 10.55.1.250
Address: 10.55.1.250#53

** server can't find pi.hole: SERVFAIL

Well I fixed the problem by reverting back to raspbian stretch. Using exact same configurations it all works like a charm right from the get go just like v4.3.1 did with buster before I updated.

I did try reinstalling buster yet again first but without running apt-get update or dist-upgrade and instead installed pihole. That didn't work either. So presumably, this is a issue with 4.3.2 specifically running on buster?

We are not aware of any such issues. I have three instances of Pi-Hole running on Buster, both V4.3.1 and V4.3.2 and no similar problems.

Consider this me making you aware of the issue then.

The same thing seems to have happened to me.

I'm running Buster and earlier today I updated Pihole with pihole -up and it has been updated to 4.3.2.

Since then, Pihole no longer works. I can run pihole -d and it seems to show everything as fine. But, if I point a device purely at Pihole for DNS, nothing gets resolved. I've checked my Query log and since the update to 4.3.2. the only client has been "localhost".

Everything was working fine before the update and nothing else has changed on the Pi. Is there any way of rolling back or trying anything else to test or help fix?

EDIT:
I seem to be getting this a lot in the log now, and it doesn't look like I had it before:

Sep 21 19:50:30 dnsmasq[6254]: query[PTR] 50.0.168.192.in-addr.arpa from 127.0.0.1
Sep 21 19:50:30 dnsmasq[6254]: forwarded 50.0.168.192.in-addr.arpa to 192.168.0.1
Sep 21 19:50:30 dnsmasq[6254]: reply 192.168.0.50 is NXDOMAIN

EDIT 2:
From a device using just pihole, if I try an nslookup, I get DNS request timed out.

NSlookup is successful on the Pi itself though.

A pihole status shows
[✓] DNS service is running
[✓] Pi-hole blocking is Enabled

Do you have Conditional Forwarding enabled?

Please provide some more information on the Buster install that will help us debug the potential issue. The information provided is insufficient for use to be able to look in to anything.

What more can I tell you about it? I downloaded the buster lite image from the official page, released in July. I restored the image to an sd card. I changed the default pi username and the password and gave it a static ip in etc/dhcpcd.conf and enabled auto login and the ssh server and altered the hostname using raspi-config. That was all i did to it in terms of changing default values.

After I Installed pi-hole and set that up with defaults values except i set the dns servers to use cloudflare. Turned dhcp on, and hey presto it worked for over a month until i updated pi-hole to v4.3.2 the other day.

I think I may have fixed it.

It seems as though that the upgrade had changed the interface in which Pihole was listening on (from eth0 to tun0).

I've edited the /etc/pihole/setupVars.conf and changed it back to eth0 and then ran pihole -r which seems to have worked.

I'm now seeing other clients in the Query Log and my nslookup is working correctly too.

Are you sure it fixed it? It seems running pihole -r fixes the thing for me but only for a short amount of time before it breaks again. Also I reinstalled Buster and pihole again just to see if the interface got changed to tun0 but it didn't; it stayed as eth0 for me the whole time. As I say though I ran pihole -r and that fixed the thing, only for it to break a few hours later.

I've gone back to Stretch, again, and unsurprisingly it has worked flawlessly since.

It's been running ok for me since I did the changes above. I'm running on a pi v4.

OK so I've realised some things. Long story short the pihole is working on buster, it's my wifi clients that aren't using the pihole as their dns for some reason. Turned out using my wireless laptop to do the configuration and testing was why it appeared broken; when I was configuring and testing stretch I did it with my wired PC which works with the pihole as expected.

So essentially; pihole works for wired clients only. And I have absolutely no idea why. If I do nslookup pi.hole from my laptop it has the correct ip but gives a server fail error. And yet all wireless clients gain their ips from the pi's dhcp server still, and they all claim their dns is the pihole's IP. I had a look for similar issues on this and couldn't really find much help other than someone else who has the same router as I do (netgear r7800) and it he had this exact same issue pop up when he updated his router's firmware. His solution was to revert to an older firmware.

However the firmware he updated that he thought caused the problem was the same firmware my router has been using since january, but I didn't have this issue until I updated to pihole v4.3.2 at the end of last month. Is it possible 4.3.2 has introduced some sort of incompatibility with my router?

I've fixed it. Downgraded the router firmware to 1.0.2.60 which was the one it was on before January this year. Just like the other person I mentioned it has fixed the issue.

What I will never understand is how the Router, after being updated to 1.0.2.62 in January by myself, went for 9 months give or take a few days without any issue at all, against all odds apparently working fine with the pihole, then decided to suffer the problems related to this latest firmware only and apparently completely coincidentally when I updated pihole. That's one hell of a coincidence.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.