DHCP not working with "Too few arguments" error log


Expected Behaviour:

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:


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

Pi-hole v3.3.1-0-gfbee18e
dnsmasq 2.76-5+rpt1+deb9u1

So what am I doing wrong?

Thanks in advance


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?


This thread says it shall be possible: https://community.openhab.org/t/pi-hole-running-on-openhabian/35111 that’s why I tried it.

OpenHABianPi is based on Debian Jessie (I think the same as the raspbian distribution). Documentation is here: https://www.openhab.org/docs/installation/openhabian.html#features
This should come without special configuration for dnsmasq because out of the box it is configured as DHCP client.

What do you mean by “where we can see how the Pi-hole package is installed”? I used the piping to bash method described here https://github.com/pi-hole/pi-hole to install it manually


what’s the content of /etc/dhcpcd.conf ?


Stripped from comments it’s this:

option rapid_commit

option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
option interface_mtu

require dhcp_server_identifier

slaac private

interface eth0
static ip_address=
static routers=
static domain_name_servers=


To be precise: I had the error in the logs from first start of Pi-hole, even without DHCP - just re-read my logs ^^


Your OS seems to have been packed with an existing dnsmasq instance.

does the OS have NetworkManager ?
does which NetworkManager output anything ?

or maybe /etc/systemd/resolved.conf (if present) has an DNSStubListener=yes entry ?


I think it doesn’t. “which” doesn’t output anything, and there’s no /etc/NetworkManager directory

This file exists, but everything is commented out


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


If there is no compelling reason to run this OS, PiHole works nicely with a standard Raspbian Stretch install.


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)?

$ sudo systemctl status pihole-FTL
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; generated; vendor preset: enabled)
Active: active (exited) since Wed 2018-07-11 21:52:07 CEST; 13s ago
Docs: man:systemd-sysv-generator(8)
Process: 25733 ExecStop=/etc/init.d/pihole-FTL stop (code=exited, status=0/SUCCESS)
Process: 25794 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)

Jul 11 21:51:57 openHABianPi systemd[1]: Starting LSB: pihole-FTL daemon…
Jul 11 21:51:57 openHABianPi pihole-FTL[25794]: Not running
Jul 11 21:52:07 openHABianPi su[25864]: Successful su for pihole by root
Jul 11 21:52:07 openHABianPi su[25864]: + ??? root:pihole
Jul 11 21:52:07 openHABianPi su[25864]: pam_unix(su:session): session opened for user pihole by (uid=0)
Jul 11 21:52:07 openHABianPi pihole-FTL[25794]: FTL started!
Jul 11 21:52:07 openHABianPi systemd[1]: Started LSB: pihole-FTL daemon.

I did that too


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.


DHCP is enabled form the /admin/ interface. If DHCP is enabled and it’s working, the interface should show DHCP as being enabled.

Same parameters should be in /etc/dnsmasq.d/02-pihole-dhcp.conf.
(replace IPs with whatever your range is).

Does it pull a 169 ip ?

Maybe your OpenHABianPi has ports 67 (UDP - required for DHCP) and it does not allow incoming request on (at least port) 67.

There are several tools for Windows to test for DHCP server broadcasts in a LAN.

Try setting an IP manually on the windows NIC from the range served by the DHCP server. See if you can connect like that.


Upon searching on google, there seem to be a lot of reports of DHCP server related issues (on port 67) on OpenHab (thanks @technicalpyro).

Do a search and see if you can find a resolution to that.

Pi-hole seems to be working fine, DHCP issue seems to be related to OpenHABianPi.


Yes webinterface always says DHCP is running, config file looks similar.

No it says:

An error occurred while renewing interface Ethernet : unable to contact your DHCP server. Request has timed out.

and as previous lease from router is still active, it uses this and keeps its ip address.

Just to confirm this is now looking good?

$ sudo netstat -pln | grep :6
udp 0 0* 25877/pihole-FTL
udp 0 0* 534/dhcpcd

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!


did you forward requests on 67 to 6767 as stated by the manual ?

See this also:

From the looks of it, a request by windows IS placed on port 67 but never receives a response.


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.


There’s definitely something blocking the DHCP requests from hitting the DHCP server on port 67.

see if adding this to iptables will allow DHCP requests:

sudo iptables --append INPUT --match udp --protocol udp --sport 67 --dport 67 --jump ACCEPT
sudo iptables --append OUTPUT --match udp --protocol udp --sport 67 --dport 67 --jump ACCEPT


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!