Pi-hole should start up dnsmasq-dhcp when DHCP option is enabled in webinterface
Actual Behaviour:
dnsmasq outputs "Too few arguments" error in logs
Debug Token:
lxux3xme3p
Steps I did:
I installed Pi-hole on my Raspberry Pi (set up through OpenHABianPi)
DNS resolution/logging works as expected
I have "Too few arguments" error in logs:
$ sudo systemctl status dnsmasq.service
β dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2018-07-11 20:08:47 CEST; 40s ago
Process: 11046 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf (code=exited, status=0/SUCCESS)
Process: 11104 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
Process: 11098 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
Process: 11095 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Main PID: 11103 (dnsmasq)
CGroup: /system.slice/dnsmasq.service
ββ11103 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service
Jul 11 20:08:47 openHABianPi systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Jul 11 20:08:47 openHABianPi dnsmasq[11095]: dnsmasq: syntax check OK.
Jul 11 20:08:47 openHABianPi dnsmasq[11104]: Too few arguments.
Jul 11 20:08:47 openHABianPi systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
Steps tried to solve problem:
looked at generated configs in /etc/dnsmasq.d/ but didn't find obvious pitfalls
installation script complained about existing /etc/dnsmasq.conf (which it didn't change). Replaced that with template from Pi-hole GitHub repository but didn't change the error
Hi, OpenHABian isn't one of our supported platforms, and it looks like it may use configuration files that we do not. Can you point us to a link where we can see how the Pi-hole package is installed?
OpenHABianPi is based on Debian Jessie (I think the same as the raspbian distribution). Documentation is here: openHABian | openHAB
This should come without special configuration for dnsmasq because out of the box it is configured as DHCP client.
Your best option at this point is to use FTLDNS beta.
I think because your environment already has an embedded dnsmasq, it will cause a lot of headaches trying to isolate the issue with it.
FTLDNS beta does not need dnsmasq to work any longer.
You would most likely have to disable dnsmasq from running so that FTLDNS can take over port 53.
The installer WILL fail at starting DNS. It is to be expected since dnsmasq is active and using port 53.
After install, I recommend editing /etc/systemd/resolved.conf and un-commenting DNSStubListener=yes and change it to DNSStubListener=no
then run sudo systemctl restart systemd-resolved.
This should release port 53 and you'd be able at this point to start pihole-FTL as your DNS resolver with sudo systemctl start pihole-FTL.service
Okay, I switched.
The installer successfully could start FTLDNS, and I now re-enabled DHCP, but it still doesn't work - I don't get an error output, but my windows client doesn't get an IP address
Is that correct, or is there a pihole-FTL-dhcp missing (just as dnsmasq-dhcp)?
The compelling reason is that it makes a hassle-free OpenHAB setup.
And as I have a 24/7 running Raspberry Pi I thought of using it as DHCP server, and that's where Pi-hole came in.
I don't think that port 67 is blocked because when OpenHAB is running (which isn't the case during my tests now) there's a special listener that sniffs DHCP reqests/replies using them for looking for network devices. This also works when there's an DHCP server running by mirroring the traffic to port 6767 - see see manual for firewall config.
I will have a more detailed look into that tomorrow. Thanks for your help so far!
Not yet as I am currently running only a DHCP server and want that to get running before I do the next step. Firewall configuration for duplicating (not only forwarding) DHCP traffic to port 6767 is required when DHCP server and OpenHAB run in parallel.
Solution was easier than I thought... seems to be a windows problem, but don't know why. I always did ipconfig /renew on both my computer and my notebook - identical results.
Network config:
Raspberry --- Router )) (( Notebook
For testing purposes (maybe Router does something strange?) I did this:
Raspberry --- Switch --- Notebook
and it worked immediately. (even ipconfig /renew works)
Then I switched back to previous config, and it still worked (maybe because I had disabled WiFi in between). I then disabled Ethernet on my desktop, re-enabled it, and then it worked there too. Crazy Windows... (recent Windows 10)
Does windows somehow cache the DHCP server information and can't switch between DHCP servers? I don't get that...
So thank you very much for your very fast and convenient support - sorry for the problems on my side.
I made a small donation on pi-hole.net as additional thank you. Keep up the good work!
It shouldn't ... When the IP lease expires or when the client connects to a (the) network, it broadcasts a DHCPDISCOVER message to see if any DHCP servers are available.
In it's turn the DHCP server (when hit with a DHCPDISCOVER requests) replies back with a DHCPOFFER message, which offers the client an IPv4 address lease.
If there is no respond from a DHCP server, the client assigns itself an Automatic Private IPv4 address (APIPA).
The client accepts the first offer received by broadcasting a DHCPREQUEST message for the offered IPv4 address and the server accepts the request by sending the client a DHCPACK message.
(overkill on the information on this one)
That's all happening on port 67 and 68.
Did you release the IPs first ?
ipconfig /release and then /renew ?
It could have been that you were requesting a /renew only, and since it already had a lease on the IPs.
Since a new DHCPDISCOVER was never requested (because /release was not used) the DHCPREQUEST was going to the Original DHCP server IP that leased the IP in the first place.
Thank's I quite understand what's happening on network level, but I wasn't sure about Windows level. Yes, I only did the /renew without a /release -- now I get it why it behaved like it did, sorry. Thanks for the explanation!