Please follow the below template, it will help us to help you!
If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.
Expected Behaviour:
I have a Raspberry Pi Zero W with Pihole. It's configured to be the network's DHCP and the router's DHCP is disabled. It mostly works for DHCP.
Actual Behaviour:
I am having very similar symptoms as the following post. After some time, clients can't get DHCP, and the logs have that same repeated DHCPDISCOVER, DHCPOFFER
Unfortunately I can't reply to that post to ask about updates or details to the cron job.
I am running log2ram and have had problems where the pihole log or the journal log fills up the /var/log and then no rotations can complete nor additional logging. So I know to look out for full partition, but I suspect RAM usage could also be exhausted.
Anyhow, looking for any remedies from the dev team, or even just notes on how to detect and restart appropriate services. Thanks.
I checked the debug token and didn't see anything. In the meantime I rebooted and the PiHole/DHCP started working again. I did take another debug log, HERE: https://tricorder.pi-hole.net/TFcmlxHp/ (after reboot, DHCP working for clients again).
Your situation likely is different, e.g. you are running Rasperry Pi OS, not Ubuntu, and Pi-hole has seen quite a few updates since that post was written.
I'd recommend to find out about your actual issue first before resorting to blindly apply some workaround from a two year old post.
You haven't given us too many details, apart from DHCPDISCOVER, DHCPOFFER repetitions.
When you observe DHCP request or renewal issues, is your Pi-hole' web interface still accessible?
Is Pi-hole's DNS server still responding, e.g. to nslookups?
Can you still ping your Pi-hole host machine, or ssh into it?
A full DHCP conversation sequence would have DHCPDISCOVER (client), DHCPOFFER (server), DHCPREQUEST (client), DHCPACK (server).
Your observation indicates that Pi-hole's DHCP server is waiting for the client's DHCPREQUEST, which never arrives. This may in turn suggest that perhaps Pi-hole's DHCPOFFER was never received by the client, or that your client does not know where to send its DHCPREQUEST.
And indeed, your debug log shows a connectivity issue with your Pi-hole host machine's wlan0 interface:
*** [ DIAGNOSING ]: Pi-hole diagnosis messages
count last timestamp type message
----- ------------------- ------------ --------------------------------------------------
1 2023-04-08 04:25:06 DNSMASQ_WARN DHCP packet received on wlan0 which has no address
When you look at that time, would that match a period of an observed DHCP outage?
Apologies for my assumptions. I'm running Raspberry Pi OS 32bit 11. Pihole 5.16.2, FTL 5.22.
I'm here about 24 hours later after having restarted that Pi and normal operations. Now I've got issues cropping up again. Here are answers to your questions as of now:
I'm not currently seeing these with tail -f /var/log/pihole.log, but I also re-ran pihole -d and I see in the log that no DHCP was discovered--shouldn't it have discovered itself? (https://tricorder.pi-hole.net/ctTUunHh/)
Not currently. Showing 403 Forbidden
Things got really interesting here. I tried nslookup from the pihole for yahoo.com. It returned results. I ran nslookup from another client which is static IP. No result/no answer. I then tried to ping the Pihole from the other client, and from the Pihole to the other client---no answer! So, then I simply sudo ifconfig down wlan0 then sudo ifconfig up wlan0 and voila. Pings, Pihole interface, and even DHCPs being handled.
I have seen that in the web panel log a number of times and have tried delaying the Pihole startup time, but still see this and ultimately dismiss it.
Anyway, because things simply started behaving differently on an interface up/down, I'm going to give this a few more days and see what happens. To be clear, where I once thought I had a Pihole software problem, I'm currently suspecting a Wifi problem. I know there have been complaints of Pi Zero W's Wifi, but I've used this thing for probably 4 years in this capacity.
How were you able to run nslookup from your Pi-hole host machine?
Is that a Desktop OS with keyboard-video-mouse attached?
This may indeed suggest that your Pi-hole host machine's wifi interface exhibits some sort of erratic behaviour.
It would be helpful if you'd share the output of those ping and nslookup commands, including the commands themselves exactly as run as well as detailing which machine ran those commands (i.e. in particular your Pi-hole host or a client).
Also, if you would not already do so, it'd be of advantage if you'd ping by IP and force nslookup resolution via Pi-hole, in addition to using the system default, e.g.
ping 192.168.1.101
nslookup pi.hole
nslookup pi.hole 192.168.1.101
(assuming 192.168.1.101 is still your Pi-hole host machine's IPv4).
Yes. I have a keyboard and monitor hooked to the Zero.
I'm returning today as I had a bout of problems this morning. Tried to ifconfig up/down, but that didn't resolve it. Could reach pi.hole/admin from machine with static IP. Could ping from Pihole to 192.168.1.100 (static, wired machine). I don't know if this is relevant, but the laptop that couldn't DHCP at the time received an IPv6 link local but not IPv4. A few days ago I got a different Windows machine to behave by disabling IPv6 on the adapter. On the Bullseye pihole I'm using DHCPCD.conf to give it a static IPv4 but nothing about IPv6.
Anyhow, today I tried running pihole -d and also pihole -r. Even tried rebooting the pihole. All the time, didn't see much that looked wrong. Finally, I rebooted my Unifi UAP UC Pros. Then, it all started working again. So not a smoking gun here with the Pihole's wifi, but perhaps also the AP went goofy. I really want to migrate to a wired pihole on a Pi 3b, just don't have the time and want to root cause this.
I am mostly considering this resolved: I was getting so many hints that the Pi Zero W was just struggling with Wifi, paired with a recent Unifi update which has caused many users to have connectivity issues. So, I pulled the plug and migrated Pi Hole to a fresh Raspbian Bullseye load on a Pi 3B which is LAN connected. It's been almost a week now and I haven't had a single issue. I can also "feel" DHCP happening faster.