I am running pi-hole v 5.0 on my raspberry pi 4 with cloudflare as upstream DNS. My laptop and phone DNS are set to the pi (192.168.1.211) manually; router (verizon fios) is left alone. The pi is plugged into my router via ethernet cable and I'm listening on eth0. I would expect it to continue to respond to DNS requests indefinitely while running.
Actual Behaviour:
My pi randomly stops receiving packets on port 53 (confirmed via tcpdump that packets are leaving my computer but not being received by the pi). Sometimes it stops receiving packets from both devices, but sometimes just from one. This happens about once a day. Sometimes this is accompanied by nslookup failing at my pi IP (192.168.1.211). In the case of the below debug log that was still working but no packets received. The last test for ipv6 always fails but I don't know whether it has something to do with that or not. I have also checked for an infinite loop / high cpu usage (negative), plenty of room on sd card. I have tried restarting the pihole-FTL service, restarting things via the admin page, etc. The only thing I have found to get things running again is to do a full reboot. Any help would be appreciated, thank you!
Sounds like you ran tcdump on the client - by itself, that wouldn't allow conclusions about why your RPi didn't answer.
You'd have to run tcdump on your RPi to establish whether DNS packets are received or not. If a DNS packet indeed never makes it to your RPi's NIC, then your Pi-hole running on it would not be involved in this.
Anything between your client and yor RPi could introduce the error then: a defective ethernet cable, a defective ethernet port on either RPi or the router, or some software in your router supressing packets (though that's more likely to happen for certain replies, e.g. by discarding a reply when DNS rebind protection is enabled).
You can safely ignore that IPv6 issue.
You don't have upstream IPv6 connectivity at all (no IPv6 gateway), and that's in line with your eth0 interface showing only a link-local IPv6 address, as your network doesn't advertise any IPv6 prefix.
However, your debug log shows an issue with your IPv4 gateway:
*** [ DIAGNOSING ]: Networking
[i] Default IPv4 gateway: 192.168.1.1
192.168.1.1
* Pinging 192.168.1.1
192.168.1.1...
[✗] Gateway did not respond.
This would explain why Pi-hole doesn't provide and answer, as forwarding DNS requests to upstream DNS servers relies on the gateway to be operational.
Commonly, lack of gateway connectivity indicates a configuration problem. You wouldn't be able to resolve any DNS queries until that is resolved.
It would be highly unlikely that a gateway fails intermittently only, but could be explained by the same hardware related failures mentioned above.
Another cause to always consider when it comes to inexplicable behaviour of RPis: Under-voltage issues.
You could check for recent occurences of those by running the following command on your RPi:
I ran tcpdump on my laptop, and then also on the RPi. This is the command that I ran: sudo tcpdump -npi eth0 -vvv host 192.168.1.211 and port 53 (on my mac it's en0 instead). When things are working, I see the packets on both ends. However, when pi-hole stops working and I run the commands again, packets are being sent from the mac but not received by the RPi. I can still use the web admin interface, and ssh into the RPi, so that is why I am trying to figure out if it's an issue instead with pi-hole or the router and not the RPi itself. Any suggestions to debug here would be appreciated.
My gateway has never pinged on the pi-hole log. When I read the FAQ entry, it looked like a gateway not pinging didn't necessarily indicate an issue with the gateway. However, it does look like I can type ping 192.168.1.1 on the terminal on either the RPi or the mac and the gateway responds. Is there a reason why the gateway would not ping in the debug script? I can try to look into the settings on my verizon fios router and see if there are possible issues with that too. Any suggestions on what to look for would be appreciated.
Unfortunately the log does not return any under-voltage issues, so that does not appear to be the culprit.
You are limiting tcpdump to the eth0 interface (and ask for very verbose output, which is probably not needed at this time).
An RPi 4 also features a WiFi interface. If that interface was using the same IP as your ethernet link, there is a slight chance that some stray packets get routed via wlan0 (if that's still active).
Such packets would then both escape attention of your tcpdump as well as being ignored by Pi-hole if that's not configured to listen on all interfaces.
See if the following command produces any more output during a DNS failure (terminates after receiving c=10 packets, change that as required):
sudo tcpdump -i any -c 10 -n host 192.168.1.211 and port 53
If it doesn't, my previous remark would remain valid:
In that case, see if you can preclude faulty hardware by changing cables and/or ethernet ports.
I wouldn't call that unfortunately.
You may want to watch this over a longer period, though. The searched logs cover only the most recent period, maybe one or two days.
This seems like it might very well be the issue... I just checked it looks like the WiFi is still on and has the same IP. I turned the WiFi off and will see if the issue persists. If this was the issue, it could explain why packets were sometimes being received from my phone when they weren't being received from my computer.
Haha, fair enough I will keep an eye out for this too.
I will keep an eye out for this too.