Hello everyone!
My Pi-hole stopped working a few days ago. I've tried several ways to fix it, but nothing has worked.
Expected Behaviour:
Pi-Hole assigns IPs correctly.
Actual Behaviour:
Without any apparent reason (I didn't change any settings on the Pi-hole or my router), the DHCP server stopped working - it no longer assigned IP addresses to devices connected to the network.
Everything seemed okay:
When running:
"sudo netstat -nltup | grep 'Proto|:67 |:547 '", the ports appeared to be correctly open.
"sudo nmap --script broadcast-dhcp-discover", my Pi-hole's IP address was correctly displayed under "Server Identifier".
I suspected that the SD card might be compromised. I switched the SD card (which meant a new installation of Pi-hole), but the problem persisted.
I believe that when I generated the log, the DHCP on Pi-Hole was already disabled (since I did many tests trying to solve the issue). I will enable it again and generate a new debug token.
Would it be interesting to delete all the log files of my Pi-hole before enabling the DHCP and generating the debug token? If so, where are these logs located?
After that, I noticed that the computer had an invalid IPv4 (outside the range configured in Pi-hole). Only IPV6 was assigned. This also happened with the Raspberry Pi (where Pi-hole is running).
169.254.104.72 is a Link Local Address automatically generated and assigned to the interface by the OS (Windows) when no DHCP lease can be acquired.
For example if the client DHCP discover broadcast doesnt get through to Pi-hole.
You can check if the initial DHCP broadcast gets through without having to switch on the DHCP service on Pi-hole by installing tcpdump on the Pi-hole host:
sudo apt install tcpdump
If you switch Wifi off and on again on your phone, you should see something like below:
pi@ph5b:~ $ sudo tcpdump -nti any udp port 67
[..]
eth0 B IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 0c:2f:b0:xx:xx:xx, length 308
If not, you have to dig deeper in your network setup.
EDIT: Also check if no local firewall is blocking udp 67-68: