DHCP Server Not Assigning IPs - Pi-hole Suddenly Stopped Working

[marcosjahn]

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.

Can someone help me, please?

Debug Token:

https://tricorder.pi-hole.net/7q2ThDQ6/

[jfb]

@marcosjahn

the DHCP server stopped working - it no longer assigned IP addresses to devices connected to the network.

The Pi-hole DHCP server is disabled:

*** [ DIAGNOSING ]: Setup variables
...
    DHCP_ACTIVE=false
    DHCP_START=192.168.100.101
    DHCP_END=192.168.100.251
    DHCP_ROUTER=192.168.100.1
    DHCP_ROUTER=192.168.100.1
    DHCP_LEASETIME=2
    PIHOLE_DOMAIN=lan
    DHCP_IPv6=true
    DHCP_rapid_commit=true
...

Your router is your DHCP server, with a 1 minute lease time (that's not a reasonable duration):

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   
   * Received 548 bytes from wlan0:192.168.100.1
     Offered IP address: 192.168.100.55
     Server IP address: N/A
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.100.1
      lease-time: 60 ( 1m )
      netmask: 255.255.255.0
      router: 192.168.100.1
      dns-server: 192.168.100.1
      --- end of options ---
   
   DHCP packets received on interface wlan0: 1

[marcosjahn]

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?

Thank you.

[jfb]

@marcosjahn

Would it be interesting to delete all the log files of my Pi-hole before enabling the DHCP and generating the debug token?

No.

But for reference, the Pi-hole logs are here:

/var/log/pihole

[marcosjahn]

Hello @jfb ! I tried again to enable the DHCP on Pi-hole. Here are the details:

• I removed the logs (to be sure);
• I restarted the Raspberry Pi;
• I accessed the Pi-hole web interface and enabled the DHCP server;
• I accessed the router, disabled the DHCP;
• I restarted the router, to force all devices to reconnect to the network - now with DHCP on Pi-hole;
• After the router restarted, I accessed the router again and verified that the DHCP was disabled;
• Running on the Raspberry Pi, where Pi-hole is installed, I checked if everything was ok:

Ports

rasp@raspberry:~ $ sudo netstat -nltup | grep 'Proto\|:67 \|:547 '

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:67              0.0.0.0:*                           1331/pihole-FTL
udp6       0      0 :::547                  :::*                                1331/pihole-FTL

Current DHCP:

rasp@raspberry:~ $ sudo nmap --script broadcast-dhcp-discover
Starting Nmap 7.80 ( https://nmap.org ) at 2023-11-22 23:09 -03
Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 1:
|     IP Offered: 192.168.100.215
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.100.100
|     IP Address Lease Time: 2m00s
|     Renewal Time Value: 1m00s
|     Rebinding Time Value: 1m45s
|     Subnet Mask: 255.255.255.0
|     Broadcast Address: 192.168.100.255
|     Domain Name Server: 192.168.100.100
|     Domain Name: lan
|_    Router: 192.168.100.1
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 8.57 seconds

• On the computer (Windows), after reconnecting to Wi-Fi, I ran:

ipconfig /release
ipconfig /renew
ipconfig /flushdns

• 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).

• I accessed the Pi-hole web interface again and in Settings > DHCP, no IP was assigned.

• I disabled the DHCP on Pi-hole.
• I enabled the DHCP on the router again and restarted.

Here's the new debug token: https://tricorder.pi-hole.net/P7AHzQA4/

UPDATE: I believe that in the debug token the DHCP will appear as inactive. I had to deactivate it in order to transmit the debug token.

Am I forgetting to configure something?

Thank you!

[deHakkelaar]

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:

sudo nft list ruleset

Or older distros:

sudo iptables -nL