PiHole doesn't work as DHCP

hi, i have installed PiHole on an old PC running CentOS 9, but i'm not able to use it as a dhcp server, if i shutdown dhcp services in my router, all my devices doesn't able to connect to wifi.

Thanks for helping me

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

Does this post help?

Thanks, I have already read it, but no luck

1 Like

anyone have some idea? I' didn't find anything

That would suggest a networking issue then.

A DHCP server can only answer a client's broadcast on the same link/network segment.

If your network is split into several segments (e.g. when using additional network equipment like another router or layer-3 switch, or software like VLANs), you'd have to configure DHCP relays on the respective equipment.

Thanks for reply.
Network is the same 192.168.1.10/24
Firewall is down
piholeFTL is up and running w/o error
port 67 and 68 is open but not in listening
I don't have any other device on my network

Please upload a fresh debug log and post the new token. Your old log has expired.

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

Thanks

Your debug log shows Pi-hole's DHCP server to be enabled, and luckily, it also contains the corresponding details for the DHCP negotiation when Discovering active DHCP servers:

*** [ DIAGNOSING ]: Pi-hole log
-rw-r-----. 1 pihole pihole 4.1K May  4 01:18 /var/log/pihole/pihole.log

 -----tail of pihole.log------
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 DHCPDISCOVER(enp0s31f6) 6c:<redacted>:3d 
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 tags: enp0s31f6
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 DHCPOFFER(enp0s31f6) 192.168.1.183 6c:<redacted>:3d 
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 next server: 192.168.1.2
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 broadcast response
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  1 option: 53 message-type  2
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  4 option: 54 server-identifier  192.168.1.2
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  4 option: 51 lease-time  1d
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  4 option: 58 T1  12h
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  4 option: 59 T2  21h
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  4 option:  1 netmask  255.255.255.0
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  4 option: 28 broadcast  192.168.1.255
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  4 option:  6 dns-server  192.168.1.2
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  3 option: 15 domain-name  lan
 May 4 01:18:36 dnsmasq-dhcp[6478]: 194415368 sent size:  4 option:  3 router  192.168.1.1

This confirms that
a) the DHCPDISCOVER broadcast has indeed reached Pi-hole's DHCP server at 192.168.1.2,
b) Pi-hole's DHCP server has replied with the correct DHCPOFFER.

But Pi-hole's DHCPDISCOVER broadcast (as initiated by pihole-FTL dhcp-discover) is not receiving that offer:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   DHCP packets received on interface enp0s31f6: 0

This would suggest that something interferes with Pi-hole's DHCP server sending that DHCPOFFER via port 67 (either broadcasting to 255.255.255.255 or unicasting to the offered IP address), or with the client receiving the reply via port 68.

reading the log i see dhcpdiscover only for mac address 6c...3d which is the machine running pi hole connected through ethernet, other device connected through wi-fi is not present.
I tried using netcat from my pc to server on port 67 and 68 and is working

Glad it is working for you now. :slight_smile:

Yes, those are the lines that were logged when the debug log script was [DIAGNOSING]: Discovering active DHCP servers.
As mentioned, we were lucky those were included in its [DIAGNOSING]: Pi-hole log section, given that the debug log script would only record a few of the the first and last entries from pihole.log.

I have no idea why same-host DHCP negotiation failed in the debug log.
But since it's working for other machines now, you probably can ignore that, as your Pi-hole host machine's IP should be static anyway if you run it as DHCP server.

I'm sorry, I'm probably got it wrong, netcat on port 67 and 68 works, pi-hole doesn't.

Oh, sorry I misunderstood your statement:
So it's just netcat that shows some interaction with ports 67 and 68.
Hopwveer, using netcat only tells you that the ports are accessible by unicasts.

Your observation doesn't change my analysis, though:
As explained, your debug log demonstrates Pi-hole is behaving correctly, sending a DHCPOFFER as a reaction to a client's DHCPDISCOVER, but something interferes with Pi-hole's DHCP server sending it via port 67, or with the client receiving it via port 68

Instead of relying on netcat or the somewhat limited debug log output, you could manually search Pi-hole's logs for previous DHCP negotiations, e.g. by running:

sudo grep dhcp /var/log/pihole/pihole.log*

Sorry for the delay, i read all the log in pihole.log and i didn't find anything regarding dhcp negotistions, i tried several restart, different configuration on modem (linkem) such as firewall, dhcp off / on but limited on different subnet ecc.
I also tried to shutdown pihole services and setup dhcpd, to exlude pihole fault, neither dhcpd works.
I'm out of idea

If Pi-hole's logs would not register even a single DHCPDISCOVER (besides the one initiated by the debug log), then that would suggest that your clients respective broadcasts would not reach your Pi-hole.

As broadcasts are same-link only, this could be the case if your Pi-hole resides on a different link/a different network segment than your clients.
If they are all on the same link, a lack of DHPCDISCOVER would suggest that something is blocking those requests from reaching Pi-hole.

Of course, it may also be possible that none of your clients sent a DHCPDISCOVER, which may also explain their absence.

With Pi-hole's DHCP server disabled and your router's DHCP server enabled, what is the output of the following statement run from your Pi-hole machine:

sudo pihole-FTL dhcp-discover

Scanning all your interfaces for DHCP servers
Timeout: 10 seconds

DHCP packets received on interface enp0s31f6: 0
DHCP packets received on interface lo: 0

Your router's DHCP server should have replied to Pi-hole's DHCPDISCOVER broadcast.

Since there is no answer, that would reinforce the assumption that Pi-hole is on a different network segment:

Since you state you have no other devices on your network, you should look for other possible causes that split your network into multiple segments, e.g. VLANs (including guest networks as sometimes offered by routers) or virtualisation environments that you perhaps use to host your Pi-hole.

Also, some routers may offer an option to isolate a client from accessing other devices in your home network.

I didn't use any virtualization environments, but i think the problem is in my linkem router, if i connect my pc and pihole server directly with a ethernet cable, my pc is able to get an ip address

In that case, you should consider to work through your router's configuration using the leads I gave you.
Are you connecting Pi-hole to a VLAN (e.g. a guest network)?
Some routers may tie a certain ethernet port to such a guest network.
Or is your router isolating clients from one another?

You may increase your chances for an answer by sharing your router's make and model here, preferably in your topic's title, to better attract users with relevant experiences.
And you should also consider to consult your router's documentation and support channels.

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