Pi Zero W, new build Pi OS Bullseye Lite, wireless connection to Deco mesh network
Vodafone Ultra Hub router (possibly made by Technicolor) to fibre internet
TP-Link Deco X20 (two units) mesh wifi throughout home
Deco master unit connected to router by cable
Pi-Hole used as DHCP server not ad blocker
DHCP static reservations for several devices, including the Deco master unit
Expected Behaviour:
In router, stop DHCP server, turn off IPv6
In Pi-Hole, activate DHCP server with fast connect and IPv6 options selected
Mesh wifi network should continue uninterrupted with correct reservations being applied
Actual Behaviour:
Home wifi network continues, apparently successfully, but only for a time
Pi-Hole DHCP active leases table populates as expected
When Deco lease expires, the Deco stops working:
The green "active + OK" light changes to red
The home wifi network is not broadcast
This is reproducible - rebooting the working Deco immediately causes the stoppage (presumably when the IP address request is made), then reinstating the router DHCP server makes the Deco work normally again
Debug Token:
Pi-Hole acting only as a DHCP server, not blocking ads, after regaining wifi by switching on the router's DHCP server. https://tricorder.pi-hole.net/AyQJXF0K/
Notes:
The Deco app which controls the set-up of the mesh system is limited, offering only the most basic controls, so I can't find out if it has its own DHCP or routing capability.
Make the address pool start and end both the static address assigned to Deco (if the router will allow that as a setting)
Activate Pi-Hole's DHCP server
That would make two DHCP servers run on the network - will that cause more problems? (I'm reluctant to rush in and try this because the router won't export/import its reservation table, there will be a lot of re-typing if I have to revert, and I'm very likely to make mistakes.)
I'll be very grateful for any hints or tips that anyone has to offer!
The debug log shows that indeed the router's DHCP server is also active:
Scanning all your interfaces for DHCP servers
* Received 344 bytes from wlan0:192.168.1.1
Offered IP address: 192.168.1.17
router: 192.168.1.1
dns-server: 192.168.1.1
* Received 312 bytes from wlan0:192.168.1.17
Offered IP address: 192.168.1.237
Server IP address: 192.168.1.17
dns-server: 192.168.1.17
DHCP packets received on interface wlan0: 2
It looks like the router is giving the Pi-hole its address of .17, possibly through an address reservation in its settings? But the Pi-hole's DHCP is also active, and each is able to give out addresses already in use by the other entity, which will cause problems.
Are you at all able to disable the Deco's DHCP server, or can you edit the ranges it gives out? I found an old thread elsewhere asking about turning it off and it seems this may have never made it as a feature. What are you seeing in yours if you have a good hunt around?
If you cannot turn the Deco DHCP off, can you edit the range? If so, perhaps you could give it a range of just 1 address, and then reserve that for some non-existent device so it never gives it out. Then have the Pi-hole's DHCP cover the rest of the range.
In either case it's best to ensure that Pi-hole has a proper static IP and is not dependant on a DHCP server giving it a fixed address. Though here, this could work, since your Deco's single DHCP address could be .2, reserved for Pi-hole, and then everything else gets .3 to .254 from Pi-hole's DHCP.
This could suggest that the Deco units are looking for some vendor-specific options in the DHCP offer of your router.
However, that kind of behaviour is usually tied to same-manufacturer devices, so I'd consider the Vodafone router unlikely to provide those.
Another explanation would be that your Vodafone router may handle wifi connections as a separate link, and as DHCP broadcasts are same-link only, your Deco's broadcasts for a DHCP server would not be able to reach Pi-hole on a separate link.
You should be able to verify whether that's the case by inspecting Pi-hole's logs for your Deco's respective DHCPDISCOVERs.
If they do not show up, they are not on the same link; if they do, and they don't accept Pi-hole's DHCPOFFER, they may disagree with the offered lease.
Keeping the router's DHCP server with a pool of two or three addresses (two Deco units and potentially Pi-hole's IP, if that's not been set statically on the device hosting Pi-hole) looks like a good attempt at addressing your situation.
Multiple DHCP servers can coexist on the same link.
In general, you should be careful with enabling rapid commit in such a setup, but associated difficulties can be avoided by using non-overlapping DHCP ranges, and further by reserving all pool addresses on your router's DHCP server (which is just what you've planned).
Thanks for the swift reply. The debug log was created after the Pi-Hole Zero was back on the network, so it had to use the router's DHCP server. (The Zero could not be contacted while the Deco was in 'red light' mode).
The Android app that TP-Link provides doesn't give any way of getting into the Deco. So the Deco will unfortunately have to remain a black box.
Thanks, anyway
Thanks so much for another quick reply!
You may have put your finger on something to do with the two Deco units. The master is connected by Ethernet cable to the router. I've just scanned the connected devices on the network and find the Deco master is on its reserved address. But it has also connected via wifi with an IP address from the pool. That puzzles me because the router's own wifi is turned off (as required by the Deco setup instructions).
The second, slave Deco unit does not appear in the scan (perhaps because it only communicates with its master and not directly to the router?).
Thanks too for the info about the multiple DHCP servers. I will try that route if I can't get the Deco to work easily with just the Pi-Hole DHCP server. Also I'll stop using the rapid commit option in Pi-Hole if it could cause problems - another subject way beyond my understanding.
I'll get back to this over the weekend. Thanks again for your help so far.
In a normal 4-message DORA exchange, leases are handed out tentatively, before client acceptancte actually leases them, allowing unused leases to be returned to a respective DHCP server's pool.
A 2-message rapid commit would immediately assign the lease, so the main negative impact here would be quick exhaustion of DHCP pools and duplicate IP address assignments.
But as mentioned, your aspired configuration would avoid that (by using non-overlapping DHCP ranges in conjunction with lease reservations).
Does that mean the master Deco has acquired two IP addresses?
What makes you think it's connected via wifi?
And are you implying that only one of your Decos (presumably, the master?) is failing to (re)acquire a lease through Pi-hole?
Oops, sorry - my novice errors. The two Deco boxes are connecting to the LAN separately with one address each. I unplugged the slave and found I'd set that one's MAC to be static. The slave identifies itself on the router as X20, the master as "Unknown", so I missed the master in the router table of active leases - and then jumped to a silly conclusion.
With the slave powered off and the master Deco plugged in to the router, rebooting the Deco acquired its static address from the Vodafone router, but not from the PiHole when I switched over. As before - with the PiHole as a DHCP server the internet was inaccessible, with the Deco in red-light mode. (Expected, because I've made no significant change.)
I'm still planning what static addresses to use with two DHCP servers, but it's going to take me ages to get that all ready. And now the PiHole ad blocker has stopped working, with the error message PHP error (2): fsockopen(): unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:47
There are error messages in the debug log:
***[ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve www.hot4f.com on lo (127.0.0.1)
[✗] Failed to resolve www.hot4f.com on eth0 (192.168.1.2)
[✓] doubleclick.com is 172.217.167.110 via a remote, public DNS server (8.8.8.8)
[And some similar IPv6 messages]
pihole-FTL daemon is failed
/etc/lighttpd/conf.d does not exist.
Google might take me to an answer, or maybe a rebuild will be the easiest fix.
I'll have to leave all this now, probably until next weekend.
Many thanks for the clear description of "Rapid Commit". I don't see a need for it, so I will exclude it.
