DietPi
DietPi copied to clipboard
MichaIng
DietPi-Software | Solve conflict between Pi-hole and WiFi hotspot DHCP servers
Creating a bug report/issue
Required Information
-
DietPi version |
cat /boot/dietpi/.versionG_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=19 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng' G_LIVE_PATCH_STATUS[0]='applied' G_LIVE_PATCH_STATUS[1]='applied' -
Distro version |
echo $G_DISTRO_NAME $G_RASPBIANbookworm 0 -
Kernel version |
uname -aLinux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux -
SBC model |
echo $G_HW_MODEL_NAMERPi 4 Model B (aarch64) -
Power supply used | (EG: 5V 1A RAVpower)
-
SD card used | (EG: SanDisk ultra)
Steps to reproduce
- on a fresh dietpi image
- dietpi-software, install pihole (using eth0)
- enable DHCP server in pihole
- disable DHCP on the LAN router
- dietpi-config, Onboard WiFi: On, WiFi Available On
- reboot
- dietpi-software, install WiFi Hotspot
Expected behaviour
- installation to be successful
- to access LAN through the Hotspot
Actual behaviour
- errors occurs during the WiFi Hotspot installation Job for isc-dhcp-server.service failed because the control process exited with error code. See "systemctl status isc-dhcp-server.service" and "journalctl -xeu isc-dhcp-server.service" for details. ... [FAILED] DietPi-Software | systemctl start isc-dhcp-server
Extra details
Pi-hole diagnosis, reports the following: DNSMASQ CONFIG FTL failed to bind DHCP server socket: Address already in use
After reboot Pi-hole diagnosis, reports the following: DNSMASQ_WARN no address range available for DHCP request via wlan0
journalctl -u isc-dhcp-server
Jul 16 12:55:33 DietPi systemd[1]: Starting isc-dhcp-server.service - LSB: DHCP server...
Jul 16 12:55:33 DietPi isc-dhcp-server[491]: Launching IPv4 server only.
Jul 16 12:55:33 DietPi dhcpd[505]: Internet Systems Consortium DHCP Server 4.4.3-P1
Jul 16 12:55:33 DietPi dhcpd[505]: Copyright 2004-2022 Internet Systems Consortium.
Jul 16 12:55:33 DietPi dhcpd[505]: All rights reserved.
Jul 16 12:55:33 DietPi dhcpd[505]: For info, please visit https://www.isc.org/software/dhcp/
Jul 16 12:55:33 DietPi dhcpd[533]: Internet Systems Consortium DHCP Server 4.4.3-P1
Jul 16 12:55:33 DietPi dhcpd[533]: Copyright 2004-2022 Internet Systems Consortium.
Jul 16 12:55:33 DietPi dhcpd[533]: All rights reserved.
Jul 16 12:55:33 DietPi dhcpd[533]: For info, please visit https://www.isc.org/software/dhcp/
Jul 16 12:55:33 DietPi dhcpd[533]: Wrote 0 leases to leases file.
Jul 16 12:55:33 DietPi dhcpd[533]: Can't bind to dhcp address: Address already in use
Jul 16 12:55:33 DietPi dhcpd[533]: Please make sure there is no other dhcp server
Jul 16 12:55:33 DietPi dhcpd[533]: running and that there's no entry for dhcp or
Jul 16 12:55:33 DietPi dhcpd[533]: bootp in /etc/inetd.conf. Also make sure you
Jul 16 12:55:33 DietPi dhcpd[533]: are not running HP JetAdmin software, which
Jul 16 12:55:33 DietPi dhcpd[533]: includes a bootp server.
Jul 16 12:55:33 DietPi dhcpd[533]:
Jul 16 12:55:33 DietPi dhcpd[533]: If you think you have received this message due to a bug rather
Jul 16 12:55:33 DietPi dhcpd[533]: than a configuration issue please read the section on submitting
Jul 16 12:55:33 DietPi dhcpd[533]: bugs on either our web page at www.isc.org or in the README file
Jul 16 12:55:33 DietPi dhcpd[533]: before submitting a bug. These pages explain the proper
Jul 16 12:55:33 DietPi dhcpd[533]: process and the information we find helpful for debugging.
Jul 16 12:55:33 DietPi dhcpd[533]:
Jul 16 12:55:33 DietPi dhcpd[533]: exiting.
Jul 16 12:55:35 DietPi isc-dhcp-server[491]: Starting ISC DHCPv4 server: dhcpdcheck syslog for diagnostics. ... failed!
Jul 16 12:55:35 DietPi isc-dhcp-server[491]: failed!
Jul 16 12:55:35 DietPi systemd[1]: isc-dhcp-server.service: Control process exited, code=exited, status=1/FAILURE
Jul 16 12:55:35 DietPi systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
Jul 16 12:55:35 DietPi systemd[1]: Failed to start isc-dhcp-server.service - LSB: DHCP server.
systemctl status isc-dhcp-server
× isc-dhcp-server.service - LSB: DHCP server
Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)
Active: failed (Result: exit-code) since Sun 2023-07-16 12:55:35 CEST; 1min 58s ago
Docs: man:systemd-sysv-generator(8)
Process: 491 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
CPU: 75ms
Jul 16 12:55:33 DietPi dhcpd[533]: bugs on either our web page at www.isc.org or in the README file
Jul 16 12:55:33 DietPi dhcpd[533]: before submitting a bug. These pages explain the proper
Jul 16 12:55:33 DietPi dhcpd[533]: process and the information we find helpful for debugging.
Jul 16 12:55:33 DietPi dhcpd[533]:
Jul 16 12:55:33 DietPi dhcpd[533]: exiting.
Jul 16 12:55:35 DietPi isc-dhcp-server[491]: Starting ISC DHCPv4 server: dhcpdcheck syslog for diagnostics. ... failed!
Jul 16 12:55:35 DietPi isc-dhcp-server[491]: failed!
Jul 16 12:55:35 DietPi systemd[1]: isc-dhcp-server.service: Control process exited, code=exited, status=1/FAILURE
Jul 16 12:55:35 DietPi systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
Jul 16 12:55:35 DietPi systemd[1]: Failed to start isc-dhcp-server.service - LSB: DHCP server.
Hmm maybe for this scenario, it might be best to disable isc-dhcp-server and to reconfigure dnsmasq to serve both interfaces. https://serverfault.com/questions/952220/dnsmasq-on-2-interfaces
What a coincidence that I just talked with @StephanStS about this question.
In theory both should work concurrently if the Pi-hole DHCP server is configured to listen on and bind to the Ethernet-side network only, as the isc-dhcp-server is configured to do so on the WiFi network only. But even if it is possible to configure both DHCP server this way, it is somehow unnecessary to run two of them.
We already thought about adding some auto-configuration when having Pi-hole (or AdGuard Home) and the WiFi Hotspot both installed:
- Configure
isc-dhcp-serverto serve Pi-hole/AdGuard Home as DNS server to WiFi DHCP clients. I cannot imagine a case where this is not wanted, when having both installed on the same system? - Configure Pi-hole/AdGuard Home to be the DHCP server for the WiFi AP. The thing here is that we cannot know whether the admin needs/wants the DHCP server on the Ethernet-side network as well or not. Enabling it automatically could lead to a DHCP server conflict with the router. So we would either need to add an interactive prompt (+ optional
dietpi.txtsetting for automation) about this or configure the DHCP server for the WiFi network only. I think with Pi-hole this is possible, but I am not sure whether it can be done via shell commands with AdGuard Home.
Just to get all options: Is there a way to configure the Pi-hole DHCP server listen on eth0 only, so that both DHCP server can run concurrently? I am pretty sure that dnsmasq can be manually configured to do so, but not sure about the web UI. Currently it definitely tries to listen on wlan0 as well, which is the main issue here:
DNSMASQ_WARN no address range available for DHCP request via wlan0
Thank you for the feedback. As a quick and dirty solution I tried to run both dhcp servers concurently: pihole dhcp only for eth0 and isc-dhcp-server only for the wlan0, but since I did not succeed to do that I thought to ask for help.
For the above link I don't understand what ap 0 and ap1 are and how they are related to eth0 and wlan0.
I'm happy to test and give feedback
update: I did some progress on this topic. The LAN (Pihole + dhcp) works as expected. I can connect on the hotspot without internet connection or access to the LAN IP range. This is the last bit that I have to sort it out.
Hereunder you can see what I did so far. Any help will be much appreciated.
apt remove isc-dhcp-server
nano /etc/dnsmasq.d/02-pihole-dhcp.conf
dhcp-authoritative
interface=eth0
dhcp-range=192.168.1.2,192.168.1.251,255.255.255.0,24h
dhcp-option=option:router,192.168.1.1
dhcp-leasefile=/etc/pihole/dhcp.leases
domain=lan
local=/lan/
dhcp-rapid-commit
create a new file
nano /etc/dnsmasq.d/99-access-point.conf
interface=wlan0
dhcp-range=192.168.42.2,192.168.42.251,255.255.255.0,24h
nano /etc/dhcpcd.conf
interface wlan0
static ip_address=192.168.42.1/24
nano /etc/hostapd/hostapd.conf
interface=wlan0
driver=nl80211
ssid=DietPi-HotSpot
country_code=DE
hw_mode=g
channel=7
wmm_enabled=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=dietpihotspot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
nano /etc/default/hostapd
DAEMON_CONF="/etc/hostapd/hostapd.conf"
nano /etc/sysctl.conf
net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sh -c "iptables-save > /etc/iptables.ipv4.nat"
nano /etc/rc.local
iptables-restore < /etc/iptables.ipv4.nat
reboot
Just did some testing and most of the steps should not be needed as they are already managed by our hotspot install process. I did it quite simple:
-
apt purge isc-dhcp-server -
apt autoremove -
nano /etc/dnsmasq.d/99-dietpi-hotspot.conf
dhcp-range=wlan0,192.168.42.2,192.168.42.251,24h
dhcp-option=wlan0,option:router,192.168.42.1
systemctl restart pihole-FTL.service
Result for wlan0 DHCP request looks like this.
wlan0
root@DietPi4:~# nmap --script broadcast-dhcp-discover -e wlan0
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-17 10:35 CEST
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 1:
| IP Offered: 192.168.42.251
| DHCP Message Type: DHCPOFFER
| Server Identifier: 192.168.42.1
| IP Address Lease Time: 2m00s
| Renewal Time Value: 1m00s
| Rebinding Time Value: 1m45s
| Subnet Mask: 255.255.255.0
| Broadcast Address: 192.168.42.255
| Domain Name Server: 192.168.42.1
| Domain Name: lan
|_ Router: 192.168.42.1
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 3.83 seconds
root@DietPi4:~#
@Joulinar: I did a fresh installation and followed your instructions. I had to edit nano /etc/dnsmasq.d/02-pihole-dhcp.conf and specify the interface, otherwise pihole and dhcp will not work on the local LAN. I just inserted interface=eth0 before dhcp-range=192.168.1.2,192.168.1.251,255.255.255.0,24h
Now it works like a charm.
Thank you so much for your quick an professional feedback.
After a longer testing it seems that pihole send the following warning: DNSMASQ_WARN Ignoring duplicate dhcp-option 3
According to pihole documentation this means: DHCP options specified more than once are ignored. The corresponding option ID is given by OPTNUM
I checked all the files in etc/dnsmasq.d/ and I could not find any "dhcp-option=" duplicates
Comparing your dnsmasq config and Joulinar's:
dhcp-option=option:router,192.168.1.1
vs
dhcp-option=wlan0,option:router,192.168.42.1
There are sadly no clear per-interface blocks, but probably adding the interface name to this setting allows it to be defined multiple times as it is then valid for the individual interface only? So with Pi-hole + WiFi AP, the two relevant blocks could look like this, assuming that 192.168.1.1 is the Ethernet-side IP:
dhcp-range=eth0,192.168.1.2,192.168.1.251,24h
dhcp-option=eth0,option:router,192.168.1.1
dhcp-range=wlan0,192.168.42.2,192.168.42.251,24h
dhcp-option=wlan0,option:router,192.168.42.1
Here the manpage: https://manpages.debian.org/dnsmasq#O,
- So indeed the interface name is one of optional comma-separated tags. And the option and IP range is only applied if all tags are matched.
The interface= option needs to be skipped or set to interface=eth0,wlan0, if I understand it correctly, to either listen on all interfaces or limit it to the two used ones explicitly.
Not sure whether the Pi-hole web interface sets conflicting settings by default?
Problem or challenge on /etc/dnsmasq.d/02-pihole-dhcp.conf is, it's a dynamic configuration file and can be overwritten by PiHole itself as soon as you change something on the web interface. 🤔
Not sure if it would make sense to check with PiHole devs if they could add the interface specification by default 😉
@MichaIng
I did the update as you proposed and pihole does not send any warning anymore.
dhcp-range=eth0,192.168.1.2,192.168.1.254,255.255.255.0,24h
dhcp-option=eth0,option:router,192.168.1.1
dhcp-leasefile=/etc/pihole/dhcp.leases
Just wondering how can be specified that dhcp-leasefile is applicable only for eth0 ? Maybe not that important since the IP's range is different than wlan0 I tried dhcp-leasefile=eth0,/etc/pihole/dhcp.leases but it is not working
Not sure if it would make sense to check with PiHole devs if they could add the interface specification by default 😉
AFAIK, there are other interface-dependant settings anyway, so at some point during install/configuration Pi-hole scripts need to know the interface name and can then apply it to dnsmasq without downsides. So yeah, sounds like a reasonable idea.
I did the update as you proposed and pihole does not send any warning anymore.
Geeat!
Just wondering how can be specified that dhcp-leasefile is applicable only for eth0 ?
Indeed, according to the manpage the dhcp-leasefile option does not support tags. But AFAIK the way the info is stored, it is not needed, i.e. a single lease file can be used for all leases across multiple interfaces. Naturally different interfaces need to have different IP ranges, if you do not use a bridge (right?).
But AFAIK the way the info is stored, it is not needed, i.e. a single lease file can be used for all leases across multiple interfaces.
On my test, I was able to see Hotspot DHCP clients listed within PiHole DHCP overview 🤣
Indeed, according to the manpage the
dhcp-leasefileoption does not support tags. But AFAIK the way the info is stored, it is not needed, i.e. a single lease file can be used for all leases across multiple interfaces. Naturally different interfaces need to have different IP ranges, if you do not use a bridge (right?).
Yes indeed, I do not use a bridge.
On my test, I was able to see Hotspot DHCP clients listed within PiHole DHCP overview 🤣
But is it a problem? Pi-hole is also used by the WiFi clients. I mean yeah it is probably confusing as/if you can only configure the eth0 side DHCP settings, but it is the same server, so ... 😃.
Hi, first time doing this so please excuse me if it's wrong place or something else. Hope it helps and thank you for DietPi! <3
These are steps how I made both play nice together.
- Enable DHCP in Pi-hole and ignore possible errors.
- Stop ISC and Pi-hole servers:
service isc-dhcp-server stopservice pihole-FTL stop - Add
local-address 192.168.42.1;to dhcpd.conf so it looks like this: (everything else was left as default, edit address if needed, my RPi ethernet static address is 192.168.1.5)nano /etc/dhcp/dhcpd.conf
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
local-address 192.168.42.1;
subnet 192.168.42.0 netmask 255.255.255.0 {
range 192.168.42.10 192.168.42.50;
option broadcast-address 192.168.42.255;
option routers 192.168.42.1;
option domain-name "local";
option domain-name-servers 192.168.1.5;
}
This will make sure isc-dhcp-server properly binds only to wlan0 interface.
5. Add interface=eth0 and bind-interfaces to a new file in /etc/dnsmasq.d/ so it persists Pi-hole web interface changes and is easier to implement in installation script so it looks like this:
nano /etc/dnsmasq.d/66-pihole-dhcp-interface-bind.conf
interface=eth0
bind-interfaces
This will make sure dnsmasq properly binds only to eth0 interface.
6. Start ISC and Pi-hole servers:
service isc-dhcp-server start
service pihole-FTL start
7. Hopefully both started without error so you can do checks:
lsof -i :53
netstat -tuln | grep :53
lsof -i :67
netstat -tuln | grep :67
This is my filtered response to show only binds from these two services:
root@NAS:~# lsof -i :53
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pihole-FT 6507 pihole 6u IPv4 61080 0t0 UDP 192.168.1.5:domain
pihole-FT 6507 pihole 7u IPv4 61081 0t0 TCP 192.168.1.5:domain (LISTEN)
pihole-FT 6507 pihole 8u IPv4 61082 0t0 UDP localhost:domain
pihole-FT 6507 pihole 9u IPv4 61083 0t0 TCP localhost:domain (LISTEN)
pihole-FT 6507 pihole 10u IPv6 61084 0t0 UDP [fe80::dea6:32ff:fe2f:5472]:domain
pihole-FT 6507 pihole 11u IPv6 61085 0t0 TCP [fe80::dea6:32ff:fe2f:5472]:domain (LISTEN)
pihole-FT 6507 pihole 12u IPv6 61089 0t0 UDP localhost:domain
pihole-FT 6507 pihole 13u IPv6 61090 0t0 TCP localhost:domain (LISTEN)
root@NAS:~# netstat -tuln | grep :53
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.5:53 0.0.0.0:* LISTEN
tcp6 0 0 fe80::dea6:32ff:fe2f:53 :::* LISTEN
tcp6 0 0 ::1:53 :::* LISTEN
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 192.168.1.5:53 0.0.0.0:*
udp6 0 0 ::1:53 :::*
udp6 0 0 fe80::dea6:32ff:fe2f:53 :::*
root@NAS:~# lsof -i :67
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pihole-FT 6507 pihole 4u IPv4 61077 0t0 UDP *:bootps
dhcpd 6556 root 10u IPv4 63147 0t0 UDP 192.168.42.1:bootps
root@NAS:~# netstat -tuln | grep :67
udp 0 0 192.168.42.1:67 0.0.0.0:*
udp 0 0 0.0.0.0:67 0.0.0.0:*
@hipi66 Did you test whether the DHCP server for WiFi does actually work with this setup? Because, from the man page:
This statement causes the DHCP server to listen for DHCP requests sent to the specified address, rather than requests sent to all addresses. Since serving directly attached DHCP clients implies that the server must respond to requests sent to the all-ones IP address, this option cannot be used if clients are on directly attached networks; it is only realistically useful for a server whose only clients are reached via unicasts, such as via DHCP relay agents.
Note: This statement is only effective if the server was compiled using the USE_SOCKETS #define statement, which is default on a small number of operating systems, and must be explicitly chosen at compile-time for all others.
And it makes sense in the way that DHCP (discovery) requests are sent to broadcast address, not to the DHCP server directly, so binding it to a particular address should make these requests invisible.
Also dhcpd does already start bound to the wlan0 interface, as of /etc/default/isc-dhcp-server. So AFAIK that one is not the problem, but dnsmasq only, solved with
interface=eth0
bind-interfaces
in its config, as you suggested.
However, this again means two dedicated DHCP servers, while you could serve both interfaces with a single DHCP server only.
Yes, tested with 3 Android phones and laptop running Windows and Linux.
This line makes discovery possible: option broadcast-address 192.168.42.255;
What you say about it already being bound to only wlan0 doesn't work as it should because without binding it to address it binds to something "more" that is interfering with dnsmasq; binding only dnsmasq to eth0 is not enough for it to work, you still get error. (might be similar to dnsmasq interface=eth0 without bind-interfaces in which case dnsmasq will bind to all interfaces but ignore everything that's not from eth0)
I know it's two DHCP servers active at same time but it solves a problem for a case when PI-hole is not installed or not running.
isc-dhcp-server could be replaced with dnsmasq for WiFi AP; install scripts would only have to deal with dnsmasq conf files in that case... (did not test this but sound reasonable) Also, it's EOL since 2022 and no longer maintained.
Above it however seems to have worked without binding dhcpd to an address 🤔: https://github.com/MichaIng/DietPi/issues/6485#issuecomment-1637135151
Guess I need to test myself and check ss -tulpn output about how exactly it binds or not binds in which case.
Not sure if I'm looking at the right place but first line of comment that shows up when I click on "#6485 (comment)" is:
apt remove isc-dhcp-server
So any leftover is-dhcp-server conf files and changes to them should do nothing...
Oh you are right, I just saw that /etc/dhcpcd.conf edit, and was already wondering about the interface option, but that one is dhcpcd, not dhcpd, which was not even explicitly installed, but Pi-hole's dnsmasq is configured to server the WiFi hotspot.
I need to figure out how local-address works and whether it can break some setups as mentioned in the man page. Else, it would be a reasonable default for our config, do be more explicit about the interface/address it is supposed to serve, and spare users at least one configuration step, when aiming to run a second DHCP server for some reason.
@MichaIng
I've sent you mail that might help with investigation, not to clutter this topic.
I was wrong about isc-dhcp-server not binding to wlan0, I checked and it does. Sorry. Everything works with only doing dnsmasq portion. Putting separate file with interface=eth0 and bind-interfaces into /etc/dnsmasq.d/ on Pihole install is all needed to work.
local-address statement does bind isc-dhcp-server to IP address but it makes no difference as DHCPDISCOVER message that client sends gets delivered to every device on network segment, even ones without IP address.
With local-address 192.168.42.1;
root@NAS:~# netstat -tuln | grep :67
udp 0 0 192.168.42.1:67 0.0.0.0:*
udp 0 0 0.0.0.0:67 0.0.0.0:*
Without local-address 192.168.42.1; root@NAS:~# netstat -tuln | grep :67 udp 0 0 0.0.0.0:67 0.0.0.0:* udp 0 0 0.0.0.0:67 0.0.0.0:*
Thanks for clarification.
So indeed broadcast messages are received by an application when bound to a unicast address. I was just thinking that the DHCP server might ignore them with local-address set, if not sent explicitly to this unicast address.