DHCP issue - sometimes

Help
1

Please follow the below template, it will help us to help you!

Expected Behaviour:

Pihole is DHCP server and everything gets IP addresses when required.

Actual Behaviour:

Pihole is DHCP server however sometimes one or two devices don't get given an IP address. Either a full restart of the raspberry Pi or simply pihole restartdns solves the issue straight away.. Relates to https://www.reddit.com/r/pihole/comments/bexf4q/. Have tried most things suggested in that thread but still happens. Have recently updated to 4.3 hoping that it would be fixed but alas it's still happening. It only started when I upgraded to 4.2 - prior to 4.2 there was no issue. I've also tried changing the DHCP range that Pihole can allocate and also giving the most affected device (probably because its the one I use the most) a static IP address but neither have made a difference.

Debug Token:

Debug when issue is happening https://tricorder.pi-hole.net/pkvybunjce
Debug after issue has happend and is fixed by pihole restartdns https://tricorder.pi-hole.net/oc9xps2ygn

2

Above one is contradicting logic.
How can you have a DHCP problem on this device if you set a static IP address so it becomes in depend of the DHCP process (wont need DHCP to get an IP) ?

What OS is this client running ?
If a Windows client, you can renew DHCP lease by running below one:

C:\>ipconfig /renew

Windows IP Configuration


Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : dehakkelaar.nl
   IPv4 Address. . . . . . . . . . . : 10.0.0.11
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.0.1

Tunnel adapter isatap.dehakkelaar.nl:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : dehakkelaar.nl

On Pi-hole, this would result in below loggings:

pi@noads:~ $ pihole -t
Jun  4 01:31:01 dnsmasq-dhcp[1997]: DHCPREQUEST(eth0) 10.0.0.11 00:1e:0b:9d:xx:xx
Jun  4 01:31:01 dnsmasq-dhcp[1997]: DHCPACK(eth0) 10.0.0.11 00:1e:0b:9d:xx:xx desktop

If a Linux client connected via WiFi (wlan0 interface), below one releases and acquires a new DHCP lease:

$ sudo dhclient -r wlan0; sudo dhclient -v wlan0
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlan0/00:1f:3c:99:xx:xx
Sending on   LPF/wlan0/00:1f:3c:99:xx:xx
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPREQUEST of 10.0.0.220 on wlan0 to 255.255.255.255 port 67
DHCPOFFER of 10.0.0.220 from 10.0.0.2
DHCPACK of 10.0.0.220 from 10.0.0.2
RTNETLINK answers: File exists
bound to 10.0.0.220 -- renewal in 42734 seconds.

On Pi-hole, this would result in below loggings:

pi@noads:~ $ pihole -t
Jun  4 01:35:00 dnsmasq-dhcp[1997]: DHCPRELEASE(eth0) 10.0.0.220 00:1f:3c:99:xx:xx
Jun  4 01:35:04 dnsmasq-dhcp[1997]: DHCPDISCOVER(eth0) 10.0.0.220 00:1f:3c:99:xx:xx
Jun  4 01:35:04 dnsmasq-dhcp[1997]: DHCPOFFER(eth0) 10.0.0.220 00:1f:3c:99:xx:xx
Jun  4 01:35:04 dnsmasq-dhcp[1997]: DHCPREQUEST(eth0) 10.0.0.220 00:1f:3c:99:xx:xx
Jun  4 01:35:05 dnsmasq-dhcp[1997]: DHCPACK(eth0) 10.0.0.220 00:1f:3c:99:xx:xx laptop
3

DHCP lease is set at 1 hour (per the reddit thread) however the problem occurred long before it was set to 1 hour. The static IP is set on the Pihole not the device itself so it still has to request an IP (even if it is requesting the same one - it still has to ask). The issue only started when I upgraded to pihole v4.2. Prior to that no issue whatsoever.

The most affected device is an iPhone but it also happens occassionally on a Windows laptop as well. I've used the renew lease option on the iPhone when the issue is occurring but it doesn't fix the issue. I'll have a look at the Pihole tail next time it happens. I've just tested it now (while the issue isn't occurring) and get the below each time I do it.

iOS

Jun  4 07:05:42 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.150 18:65:90:49:1b:74
Jun  4 07:05:42 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.150 18:65:90:49:1b:74 xxxxxxxxxiPhone
Jun  4 07:05:43 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi
Jun  4 07:05:43 dnsmasq-dhcp[16036]: RTR-SOLICIT(br0) 18:65:90:49:1b:74
Jun  4 07:05:43 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) 2a02:c7f:dc67:e00::
Jun  4 07:05:43 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) fd4e:1772:a6ef::
Jun  4 07:05:43 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74

Windows (again not having an issue at the time) took almost two minutes to produce the below (seems to take a while for it to send the DHCP request to the server). ipconfig /renew was run at 07:13 but as you can see from the below nothing hit the dhcp until 2 minutes later.

Jun  4 07:15:28 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.166 d8:fc:93:04:b4:fb
Jun  4 07:15:28 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.166 d8:fc:93:04:b4:fb UK110345

When I did the iOS renew lease the first time the below happened to occur just after. This is from a Sonos speaker which of late sometimes has trouble being seen on the network also. Not sure if it is related.

Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.211 b8:e9:37:d6:8b:60
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.211 b8:e9:37:d6:8b:60 SonosZP
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 07:03:33 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi
4

Yeah I thought bout that later.
Sometimes a bit confusing what is meant with set static IP :wink:
Maybe they should have named it static reservation instead.

During that 2 minutes, are other devices able to get a lease and does it take so long as well ?

That doesnt look good.
If the Sonos speaker can push out that many DHCP requests within a second, it could stress the Pi-hole DHCP daemon to the limits and holding up other requests.
I would disconnect that one for a while for diagnosing.
Also make sure no other DHCP service is active on your network.
Check all devices that are able to function as a DHCP server to be sure.
Initially the DHCP request is broadcasted on port 67 UDP to all devices connected on the network segment.
If two DHCP servers answer, things usually go wrong :wink:

5

Hi
Thanks for your hep.

I don't think anything tried at the time. The laptop hadn't actually sent the request to the pihole (or at least it hadn't shown up in the tail). I've just tried now. Laptop ipconfig /renew and while that was taking it's time I connected the iphone to the wifi - results below.

Jun  4 12:45:04 dnsmasq-dhcp[16036]: DHCPRELEASE(br0) 192.168.0.150 18:65:90:49:1b:74
Jun  4 12:45:04 dnsmasq-dhcp[16036]: DHCPDISCOVER(br0) 18:65:90:49:1b:74
Jun  4 12:45:04 dnsmasq-dhcp[16036]: DHCPOFFER(br0) 192.168.0.150 18:65:90:49:1b:74
Jun  4 12:45:05 dnsmasq-dhcp[16036]: DHCPRELEASE(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:05 dnsmasq-dhcp[16036]: RTR-SOLICIT(br0)
Jun  4 12:45:05 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) 2a02:c7f:dc67:e00::
Jun  4 12:45:05 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) fd4e:1772:a6ef::
Jun  4 12:45:05 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi
Jun  4 12:45:05 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.150 18:65:90:49:1b:74
Jun  4 12:45:05 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.150 18:65:90:49:1b:74 xxxxxiPhone
Jun  4 12:45:05 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) 2a02:c7f:dc67:e00::
Jun  4 12:45:05 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) fd4e:1772:a6ef::
Jun  4 12:45:06 dnsmasq-dhcp[16036]: DHCPSOLICIT(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:06 dnsmasq-dhcp[16036]: DHCPADVERTISE(br0) fd4e:1772:a6ef::136 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:06 dnsmasq-dhcp[16036]: DHCPADVERTISE(br0) 2a02:c7f:dc67:e00::136 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:06 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:06 dnsmasq-dhcp[16036]: DHCPREPLY(br0) fd4e:1772:a6ef::136 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:06 dnsmasq-dhcp[16036]: DHCPDISCOVER(br0) 18:65:90:49:1b:74
Jun  4 12:45:06 dnsmasq-dhcp[16036]: DHCPOFFER(br0) 192.168.0.150 18:65:90:49:1b:74
Jun  4 12:45:06 dnsmasq-dhcp[16036]: RTR-SOLICIT(br0)
Jun  4 12:45:06 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) 2a02:c7f:dc67:e00::
Jun  4 12:45:06 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) fd4e:1772:a6ef::
Jun  4 12:45:07 dnsmasq-dhcp[16036]: DHCPSOLICIT(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:07 dnsmasq-dhcp[16036]: DHCPADVERTISE(br0) fd4e:1772:a6ef::136 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:07 dnsmasq-dhcp[16036]: DHCPADVERTISE(br0) 2a02:c7f:dc67:e00::136 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:07 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.150 18:65:90:49:1b:74
Jun  4 12:45:07 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.150 18:65:90:49:1b:74 xxxxxxiPhone
Jun  4 12:45:07 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:07 dnsmasq-dhcp[16036]: DHCPREPLY(br0) fd4e:1772:a6ef::136 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:45:08 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi
Jun  4 12:45:09 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi
Jun  4 12:45:11 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi

I tried again - this time using renew lease on the iphone while the laptop was waiting it's 2 minutes and something odd happens. I have two tails running. One is everything (e.g. pihole -t) and the other is pihole -t | grep 'DHCP|RTR'. While the laptop is waiting it's two minutes - on the everything tail I can see the iphone renew request immediately (as soon as I request it) while on the grep'd tail it doesn't show at all. The laptop request shows on both once it's done it thing a couple of minutes later.

iphone renew from everything tail

Jun  4 12:55:50 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.150 18:65:90:49:1b:74
Jun  4 12:55:50 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.150 18:65:90:49:1b:74 xxxxxiPhone
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-SOLICIT(br0) 18:65:90:49:1b:74
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) 2a02:c7f:dc67:e00::
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) fd4e:1772:a6ef::
Jun  4 12:55:51 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) 2a02:c7f:dc67:e00::
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) fd4e:1772:a6ef::
Jun  4 12:55:51 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi
Jun  4 12:55:52 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:55:54 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74

Subsequent laptop renew from everything tail (a couple of minutes later)

Jun  4 12:57:42 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.166 d8:fc:93:04:b4:fb
Jun  4 12:57:42 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.166 d8:fc:93:04:b4:fb UK110345

Everything on grep tail. None of this shows until the laptop has done it's thing (so appears at 12:57:42)

Jun  4 12:55:32 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi
Jun  4 12:55:50 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.150 18:65:90:49:1b:74
Jun  4 12:55:50 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.150 18:65:90:49:1b:74 xxxxxiPhone
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-SOLICIT(br0) 18:65:90:49:1b:74
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) 2a02:c7f:dc67:e00::
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) fd4e:1772:a6ef::
Jun  4 12:55:51 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) 2a02:c7f:dc67:e00::
Jun  4 12:55:51 dnsmasq-dhcp[16036]: RTR-ADVERT(br0) fd4e:1772:a6ef::
Jun  4 12:55:51 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:22:69:56:fc:b8:27:eb:b0:90:56 raspberrypi
Jun  4 12:55:52 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:55:54 dnsmasq-dhcp[16036]: DHCPINFORMATION-REQUEST(br0) 00:01:00:01:20:cc:9b:c4:18:65:90:49:1b:74
Jun  4 12:57:42 dnsmasq-dhcp[16036]: DHCPREQUEST(br0) 192.168.0.166 d8:fc:93:04:b4:fb
Jun  4 12:57:42 dnsmasq-dhcp[16036]: DHCPACK(br0) 192.168.0.166 d8:fc:93:04:b4:fb UK110345

I would have thought that any DHCP daemon could handle 10 requests at the same time given how large some networks can be???

I can do if absolutely needed (if there's nothing else to try) however it is in use all day. I forgot I left the tail running from this morning. I've been back through it as far as I can go (about 40 minutes) and it didn't do it during that time.

The only other device capable is the router and its definitely turned off on that (both ipv4 and ipv6 dhcp servers).

Any other thoughts on what to try? Did the debug logs provided initially show anything odd/out of the ordinary?

6

Better luck with below one:

tailf /var/log/pihole.log | grep dnsmasq-dhcp

I wasnt sure if I was looking at the full log, there could have been many more that followed :wink:
Yeah it should be able to handle lots more then 10 at same time.

To be more sure, you could install nmap and have nmap query your router for DHCP (unicast and not broadcast):

sudo apt install nmap

Below I'm querying my router 10.0.0.1 that has DHCP disabled:

pi@noads:~ $ sudo nmap -sU -p67 --script dhcp-discover 10.0.0.1

Starting Nmap 7.40 ( https://nmap.org ) at 2019-06-04 15:44 CEST
Nmap scan report for 10.0.0.1
Host is up (-0.20s latency).
PORT   STATE         SERVICE
67/udp open|filtered dhcps
MAC Address: 50:46:5D:6C:xx:xx (Asustek Computer)

Nmap done: 1 IP address (1 host up) scanned in 12.96 seconds

Wait for a dev or a mod to look into the debug log.

7

sudo nmap -sU -p67 --script dhcp-discover 192.168.0.1

Starting Nmap 7.40 ( https://nmap.org ) at 2019-06-04 14:03 UTC
Nmap scan report for 192.168.0.1
Host is up (0.00072s latency).
PORT STATE SERVICE
67/udp closed dhcps
MAC Address: 90:21:06:21:xx:xx (BSkyB)

Nmap done: 1 IP address (1 host up) scanned in 1.91 seconds

Will do

8

The only issue I found in debug logs is that the IPv6 address you have configured does not exist. Run pihole -r to reconfigure this.

9

Hmm odd - I've done a pihole -r recently so not sure why that is. I've done it again now so will see if that fixes it (fingers crossed).
I forgot to take a copy of additional lists (did the teleport but forgot to copy the additional lists) - I do have them written down somewhere (can't seem to find them at the moment). I presume there is no backup of these kept upon reconfigure?

10

You don't lose ad list settings when you reconfigure.

11

Was just thinking about this again this morning as I hadn't had the issue since reconfigure and was going to post that it seems to have solved it. However it's just happened again.
Debug while happening https://tricorder.pi-hole.net/oo49km395u
Debug after pihole restartdns https://tricorder.pi-hole.net/lqg014xf71

Any other ideas of what I can try?

Yeah I think I must have cleaned up the lists a while back. Managed to find teleport from a while back and used that instead.

12

Nothing in either of those debug logs is showing a problem.

13

Hmm. Any other ideas as to what it might be?

14

DHCP_LEASETIME=1

Is there any particular reason you have your lease time set so short? This increases your DHCP traffic significantly compared to a duration of 1 day or 1 week.

15

That was from when I was trying to work it out based on the advice in the subreddit and I just haven’t changed it back. The issue was occurring well before I changed it to 1 hour however

16

Its just done it again. https://tricorder.pi-hole.net/903wv0jig2

17

Any other thoughts on this? It's still doing it - although since the reconfigure it seems to be less likely to occur.

18

Is it only one client thats having issues ?
I would focus on that client.

EDIT: Maybe another divece on the network misbehaving causing an IP conflict.
To scan for devices and IP's, install nmap:

sudo apt install nmap

And ping scan:

nmap -sP 192.168.0.0/24

19

Mostly yes (iPhone) however it's the device I use most. Occasionally the laptop (windows) has issues as well.

I'm beginning to wonder if it's happening when switching between either mobile data or pi wifi (5Ghz) and the router wifi (2.4Ghz). It always gets stuck on the router wifi but that could be because it's the only wifi that reaches the other end of the house and I've had it running perfectly fine without issues like this for months. It was only the upgrade to pihole 4.2 and restarting dns on the pihole fixes it so not sure.

20

Power cycle all the devices, AP's, extenders, routers etc.
Make sure all those devices have latest firmware etc.