DHCP Stopped Working Today

Help
1

Expected Behaviour:

Pihole should be my DHCP server. It's been working smoothly for months. This morning I attempted to add a DHCP reservation for a new iPad. That's when DHCP seemed to break.

Actual Behaviour:

Pihole stopped handing out DHCP leases this morning.

RasPi 3B+, running older version of pihole because I've got no compelling reason to upgrade and none of the features in newer pihole are needed on my little network.

The messages regarding 10.8.0.0/24 are openvpn IP space. I've got openvpn running happily on the pi. If I connect to VPN over cellular, I'm handed a correct 10.8.0.8/24 IP, DNS goes through the pihole, and I can access "internal" resources. It looks like something is borked with the internal "slice" of pihole in 10.0.0.0/8 IP space.

Looking in pihole.log, I see the following:

Jan 23 00:13:57 dnsmasq-dhcp[739]: DHCPREQUEST(eth0) 10.0.0.194 08:78:08:49:2b:46
Jan 23 00:13:57 dnsmasq-dhcp[739]: DHCPACK(eth0) 10.0.0.194 08:78:08:49:2b:46 android-c7492eb846563d8d

[ similar REQ and ACK pairs repeated over and over ]
[ all is working normally ]

Jan 23 08:26:10 dnsmasq-dhcp[739]: DHCPRELEASE(eth0) 10.0.0.105 90:b2:1f:55:5a:ee
Jan 23 08:26:10 dnsmasq-dhcp[739]: DHCPREQUEST(eth0) 172.20.10.5 90:b2:1f:55:5a:ee
Jan 23 08:26:10 dnsmasq-dhcp[739]: DHCPNAK(eth0) 172.20.10.5 90:b2:1f:55:5a:ee wrong network

[ above is unusual double request from an iPad for a 10. and 172. IP. I don't use 172.16.0.0/12 ]

Jan 23 08:26:10 dnsmasq-dhcp[739]: DHCPDISCOVER(eth0) 90:b2:1f:55:5a:ee
Jan 23 08:26:10 dnsmasq-dhcp[739]: DHCPOFFER(eth0) 10.0.0.105 90:b2:1f:55:5a:ee
Jan 23 08:26:11 dnsmasq-dhcp[739]: DHCPREQUEST(eth0) 10.0.0.105 90:b2:1f:55:5a:ee
Jan 23 08:26:11 dnsmasq-dhcp[739]: DHCPACK(eth0) 10.0.0.105 90:b2:1f:55:5a:ee BowTiePad

[ above is full DORA cycle and iPad is on a 10. IP ]

Jan 23 09:08:36 dnsmasq-dhcp[739]: DHCPDISCOVER(eth0) 04:e5:36:2e:ad:8e
Jan 23 09:08:36 dnsmasq-dhcp[739]: DHCPOFFER(eth0) 10.0.0.170 04:e5:36:2e:ad:8e
Jan 23 09:08:36 dnsmasq-dhcp[739]: DHCPDISCOVER(eth0) 04:e5:36:2e:ad:8e
Jan 23 09:08:36 dnsmasq-dhcp[739]: DHCPOFFER(eth0) 10.0.0.170 04:e5:36:2e:ad:8e
Jan 23 09:08:37 dnsmasq-dhcp[739]: DHCPREQUEST(eth0) 10.0.0.170 04:e5:36:2e:ad:8e
Jan 23 09:08:37 dnsmasq-dhcp[739]: DHCPACK(eth0) 10.0.0.170 04:e5:36:2e:ad:8e iPad

[ above is last DHCP traffic, what follows is what looks like DHCP server restarting ]

Jan 23 09:14:51 dnsmasq-dhcp[24637]: DHCP, IP range 10.0.0.150 -- 10.0.0.200, lease time 2h
Jan 23 09:19:27 dnsmasq-dhcp[24882]: DHCP, IP range 10.0.0.150 -- 10.0.0.200, lease time 2h

Debug Token:

https://tricorder.pi-hole.net/bGpbgu6J/

One of the messages in pihole -d that baffles me is this:

[i] Default IPv4 gateway: 10.0.0.1
10.0.0.1
   * Pinging 10.0.0.1
10.0.0.1...
[✗] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546)

From the command line of the pihole I can ping the gateway (10.0.0.1) from wlan0 and eth0:

$ ping -I wlan0 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 10.0.0.253 wlan0: 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=1039 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=2.55 ms
[ . . .]
$ ping -I eth0 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 10.0.0.53 eth0: 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.496 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.440 ms
2

You are not kidding. You are running an ancient version (almost two years old).

You are also running modified code:

*** [ DIAGNOSING ]: Web version
[i] Web: v4.3 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Branch: master
[i] Commit: v4.3-0-g44aff72-dirty
[i] Status:  M scripts/pi-hole/php/header.php
            ?? index-new.php
            ?? scripts/pi-hole/php/footer.php-BAK
            ?? scripts/pi-hole/php/header-new.php
            ?? scripts/pi-hole/php/header.php-BAK
            ?? scripts/pi-hole/php/uptime.php
[i] Diff: diff --git a/scripts/pi-hole/php/header.php b/scripts/pi-hole/php/header.php
          index e070bc8..e211e65 100644
          --- a/scripts/pi-hole/php/header.php
          +++ b/scripts/pi-hole/php/header.php
          @@ -299,11 +299,6 @@ if($auth) {
        ...

You might consider upgrading just so we can help you more. None of us on the team have run that version in a long, long time.

3

That came across as snarky.

I didn't mean it that way.

What I was trying to convey was that "it's working, no reason to take a chance on breaking it".

Besides, my Pi4 is busy running Corelight @Home. :slight_smile:

4

I tweaked the code to add uptime to the top left:

image

5

From your debug log, a few things noted:

*** [ DIAGNOSING ]: Setup variables
    ...
    PIHOLE_INTERFACE=eth0
    PIHOLE_INTERFACE=wlan0
    PIHOLE_INTERFACE=tun0
    IPV4_ADDRESS=10.0.0.53/24

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the tun0 interface:
   10.8.0.1/24 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)

Did you intend to have three active interfaces on the Pi?

6

Idea was to send tun0 which is from VPN space to the PI, eth0 which is primary wired, and wlan0 which is backup wlan.

7

Ok.

pihole -r and then selecting repair, followed by a successful pihole -up

https://tricorder.pi-hole.net/yM5jOEmo/

DHCP Still not being served.

Logging in to the UI I see a bouncing ! which says:

Warning in `dnsmasq` core:
no address range available for DHCP request via lo
Check out [our documentation](https://docs.pi-hole.net/ftldns/dnsmasq_warn/) for further information.

The link suggests this warning is a non-issue for the loopback interface.

8

Just for future reference consider updating once a year at a minimum. There are a few security ‘exploits’ in older software, you (or anyone else) should not leave it that long before updating :confused:

E.g https://nvd.nist.gov/vuln/detail/CVE-2020-11108

(Just trying to convince you on why updating is a good thing)

10

Likely not related to your DHCP issue - it seems your gravity database is not yet populated correctly:

*** [ DIAGNOSING ]: contents of /var/log
-rw-r--r-- 1 pihole pihole 124K Jan 23 14:14 /var/log/pihole-FTL.log

   -----tail of pihole-FTL.log------
   [2022-01-23 14:11:20.527 12863/T12867] Count of gravity domains not available. Please run pihole -g

Please run pihole -g. :wink:

That sequence shows that Pi-hole has correctly answered your client's request for a specific IP address and send out the correct message acknowledging that request.

Hence, it would be your client that continues to send a request for that IP, despite being told that its request was successful.

This may suggest
a) a misbehaving client
I think I recall an issue a while ago where a bug in a certain dhcp client software had caused a similar issue - I'll see if I can find that topic to link it here, but feel free to search our forums as well.
b) the DHCPACK message didn't reach your client
I see no indication that would have happened, but as you employ both wlan0 and eth0 interfaces, your client may have gotten confused if reply packages wouldn't have been routed by the same interface MAC they've been sent to.
Just to be sure, you could consider to disable wifi on your RPi 3B+ to rule this out.

11

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.