See the log update instantly in admin/taillog.php after accessing a never-before accessed website.
Operating System:
Debian 10 on the Pi; macOS 13.1 on the laptop I'm using for testing.
Hardware:
Raspberry PI 4B, MacBook Air M1 2020.
Actual Behaviour:
Log is initially empty and doesn't update upon browsing, at least not straight away (it sometimes updates after sitting on the page for a while). Even manually tailing pihole.log in a shell shows the most recent request was > 10 minutes ago.
It may be that there's another DNS server in play which prevents some of the browsing from going through Pi-hole. Your debug log may reveal more about that.
To test it, open the /admin/taillog.php in your browser, and also open a terminal on the Pi-hole and tail the dnsmasq log manually (instead of using pihole -t) to get an OS-level perspective.
sudo tail -f /var/log/pihole.log
Put them side by side and observe; they should be matching up in near realtime.
Now open a terminal on your Mac and try some random lookups forcing the use of Pi-hole (substitute in the IP of your Pi-hole)
dig example.com @ip_of_pihole
They should be showing up on both straight away. Try a few other domains. If they are all showing up then it looks like, in your normal browsing, some of that query traffic is going elsewhere.
Hmm I suspected that might be the case when I saw this in the debug log:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds
Received 374 bytes from wlan0:192.168.1.1
...more info about my modem/router
Received 300 bytes from wlan0:192.168.1.10
Please correct me if I'm wrong, but this seems to suggest that I have both my modem/router (192.168.1.1) and Pi-hole answering DNS queries...but why??
I have the modem/router set up to use the Pi as both my primary and secondary DNS servers, plus I'm using unbound on the Pi to create a recursive DNS server and it should be the only thing answering queries, right?
I have a basic knowledge of how DNS works but 90% of that debug log completely befuddles me...I'm very tempted to re-run the setup wizard since I had things working well at one stage, but recently went overseas and shut off power to my house completely for 3 months, so upon arriving home all sorts of system clock and locale settings were out of whack and the Pi was practically useless LOL (at least for my use cases; no ability to update software, surf the web, get accurate results from Pi-hole, etc.).
At that point I threw up my hands and left it for like a month, and now I've just started trying to get things working again.
Anyway does anything else in the log stick out to you? MTIA
That section is showing which DHCP servers are responding, which means that your router appears to still be running DHCP. If you're using Pi-hole for DHCP then that should be the only one on the network.
But I'd also expect your router to be appearing in your logs if it's using Pi-hole as its upstream DNS. I'd turn off the router's DHCP so that is fixed, then have your devices disconnect and reconnect to pick up the Pi-hole's DHCP, and then see how it goes from there.
A handy tip for this kind of situation – have the Pi-hole's DHCP range go from, say, .10 to .139, and the router's DHCP go from .140 to .254. The router's DHCP will be off normally. If you need to take the Pi-hole offline for any reason, that normally breaks your network. But now you can temporarily re-enable the router's DHCP and be safe in the knowledge there will be no IP address clashes from the different ranges.
Once the DHCP thing is sorted and the OS and Pi-hole updated it may all be fixed. The Teleporter tool has got your back when it comes to saving your settings. Handy if you go nuclear and decide to start from a fresh OS install.
Debug logs are only available to Pi-hole staff. If anything is out of place they will notice it. If you want to peruse your most recent debug log you can do so with
OMG I feel so silly for missing this! You are right; I have both devices' DHCP servers on, so that will definitely muck things up; even I know that with my limited knowledge about this stuff LOL. I could swear I turned the Pi's DHCP server off yesterday, but apparently not!
Wow that's a super-awesome idea! Totally makes sense when you explain it but I never would have thought of doing that myself! Thanks
I've got chrony installed and working well now, and that's allowed me to sudo apt update && sudo apt upgrade, so the OS and Pi-hole package should be all good, right?
Oops, sorry I just automatically assumed that you were a staff member! All good, you've been very helpful anyway. Thanks again!
OK cool, after running pihole -up almost everything looks great...only issues thrown at me by the installer were:
[i] Target: Tracking
[✗] Status: Connection Refused
[✗] List download failed: no cached list available
[i] Target: &
[✗] Status: Connection Refused
[✗] List download failed: no cached list available
[i] Target: Telemetry
[✗] Status: Connection Refused
[✗] List download failed: no cached list available
[i] Target: Lists
[✗] Status: Connection Refused
[✗] List download failed: no cached list available
It looks like the phrase "Tracking & Telemetry Lists" has found its way into the list URLs themselves. I suspect this has happened due to that phrase being inadvertently pasted into the Address section on the Adlists page. Pi-hole can take space-delimited list URLs and add them all at once, so that would explain the phrase being turned into single word addresses, which of course are invalid and won't work.
Have a look in the Adlists page and scroll down to see all the lists (set the dropdown to All). Do you see those four words in there? If so, hit the delete button on them and you should be sorted. You can test with pihole -g if you want to be absolutely sure it's fixed.
