[SOLVED] DHCP issue - Pihole can't assign ip

Expected Behaviour:

Pi-Hole should assign ip to every devices on the network configured to.

Actual Behaviour:

On 2 devices (Xiaomi Mi6 with Oreo 8.0.0 and a Microsoft Surface 2017 with Windows 10 1809) the Pi-Hole doesn’t assign the ip, and the log shows multiple DHCP activity.

Xiaomi Mi6 pihole.log
Microsoft Surface pihole.log

As far as I remember, the DHCP was working before the update to version 4.3.1.

Current configuration

Pi-Hole 4.3.1 clean install on a Raspberry Pi Zero W, with on top Raspbian 10 Buster.
The Raspberry has also installed QBittorrent (but I was having DHCP issues before the installation of QBittorrent)

What I tried

I tried to power cycle every networking devices (access point, Raspberry, modem).
I also tried to uninstall and do a clean install of the PiHole. The reinstall worked for the first 2 hours, maybe because it was the 1st time the Pi-Hole met the Xiaomi???
After that nothing, as before the devices cannot get an IP.

Debug Token:

https://tricorder.pi-hole.net/evszlw3mhj

Looking at the logs you linked, everything seems normal from the Pi-hole side of things

Jul  7 11:46:31 dnsmasq-dhcp[11832]: DHCPDISCOVER(wlan0) 4c:49:e3:60:46:d9
Jul  7 11:46:31 dnsmasq-dhcp[11832]: DHCPOFFER(wlan0) 192.168.1.64 4c:49:e3:60:46:d9
Jul  7 11:46:31 dnsmasq-dhcp[11832]: DHCPDISCOVER(wlan0) 4c:49:e3:60:46:d9
Jul  7 11:46:31 dnsmasq-dhcp[11832]: DHCPOFFER(wlan0) 192.168.1.64 4c:49:e3:60:46:d9
Jul  7 11:46:31 dnsmasq-dhcp[11832]: DHCPDISCOVER(wlan0) 4c:49:e3:60:46:d9
Jul  7 11:46:31 dnsmasq-dhcp[11832]: DHCPOFFER(wlan0) 192.168.1.64 4c:49:e3:60:46:d9
Jul  7 11:46:31 dnsmasq-dhcp[11832]: DHCPDISCOVER(wlan0) 4c:49:e3:60:46:d9
Jul  7 11:46:31 dnsmasq-dhcp[11832]: DHCPOFFER(wlan0) 192.168.1.64 4c:49:e3:60:46:d9

Jul  7 11:46:32 dnsmasq-dhcp[11832]: DHCPREQUEST(wlan0) 192.168.1.64 4c:49:e3:60:46:d9
Jul  7 11:46:32 dnsmasq-dhcp[11832]: DHCPACK(wlan0) 192.168.1.64 4c:49:e3:60:46:d9 MI6-Mi6diMarco
Jul  7 11:46:37 dnsmasq-dhcp[11832]: DHCPREQUEST(wlan0) 192.168.1.64 4c:49:e3:60:46:d9
Jul  7 11:46:37 dnsmasq-dhcp[11832]: DHCPACK(wlan0) 192.168.1.64 4c:49:e3:60:46:d9 MI6-Mi6diMarco
Jul  7 11:46:42 dnsmasq-dhcp[11832]: DHCPREQUEST(wlan0) 192.168.1.64 4c:49:e3:60:46:d9
Jul  7 11:46:42 dnsmasq-dhcp[11832]: DHCPACK(wlan0) 192.168.1.64 4c:49:e3:60:46:d9 MI6-Mi6diMarco

The devices are misbehaving and I cannot really see why. The messages are as expected:

DHCPDISCOVER

Sent by the client as the first step of the DHCP client/server interaction. The purpose of the DHCPDISCOVER is for the client to “discover” what servers are out there and what network parameters they have to offer.

DHCPOFFER

Sent by the server to the client in response to a DHCPDISCOVER. The server uses the DHCPOFFER message to “offer” an IP address, lease time, and network configuration parameters to the client.

DHCPREQUEST

Sent by the client to the server in response to a DHCPOFFER. The “server identifier” field of the DHCPREQUEST indicates which server the client has chosen to further interact with. All servers that sent the client a DHCPOFFER receive the DHCPREQUEST. The ones that are not chosen simply use the message as notification that they have not been chosen. The server that is chosen responds to the request, either with a DHCPACK or a DHCPNAK.

DHCPACK

Sent by the server to the client in response to a DHCPREQUEST. The DHCPACK indicates that the server “acknowledges” the request, and the DHCPACK message contains fields which indicate the IP address, lease time, and network configuration parameters that the client is being configured with.

However, your clients are seemingly ignoring the replies and are querying the DHCP server hard (normally, they aren’t repeated!).


I just checked and we touched the DHCP related code last in release v4.2 (Feb 3) when introducing rapid commit. This shouldn’t have changed anything otherwise, though.

From your debug log, it seems you are not using rapid commit:

#/etc/pihole/setupVars.conf
DHCP_rapid_commit=false

You may want to try enabling it from the web interface settings page.

1 Like

A few days later…
Now it works perfectly, but I didn’t do anything. I don’t know, I think it’s solved.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.