DHCP Not responding

Decided to switch from the router to the Pi-Hole as my DHCP server. Copied over all my reserved allocations, copied the setting from the router. Set the IP addresses in the PI to be static, same as the router reservation. So far so good.

Enabling the Pi and disabling the router, not actually getting an address either for the reserved HW or within the normal DHCP range. Times out waiting both my Windows VM and my desktop. However, if I use NMAP to query all seems to be working I get an address returned.

i.e.
This is from the Pi-Hole

sudo nmap --script broadcast-dhcp-discover -e eth0
Starting Nmap 7.80 ( https://nmap.org ) at 2021-06-08 09:54 +08
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     IP Offered: 192.168.70.69
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.70.250
|     IP Address Lease Time: 2m00s
|     Renewal Time Value: 1m00s
|     Rebinding Time Value: 1m45s
|     Subnet Mask: 255.255.255.0
|     Broadcast Address: 192.168.70.255
|     Domain Name: lan
|     Domain Name Server: 192.168.70.250, 192.168.70.200
|_    Router: 192.168.70.1

& the router

sudo nmap --script broadcast-dhcp-discover -e eth0
Starting Nmap 7.80 ( https://nmap.org ) at 2021-06-08 10:04 +08
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     IP Offered: 192.168.70.90
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.70.1
|     IP Address Lease Time: 2m00s
|     Renewal Time Value: 1m00s
|     Rebinding Time Value: 1m45s
|     Subnet Mask: 255.255.255.0
|     Broadcast Address: 192.168.70.255
|     Domain Name Server: 192.168.70.250, 192.168.70.200
|_    Router: 192.168.70.1

As a DNS server it has been fine for ages. I was just planning on building a router out of another Pi and figured at least for now to give me one less thing to do I'd offload the DHCP

Please upload a debug log and post just the token that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

I've turned the DHCP server back on so it is active and moved the range it allocates outside of that the router allocates. i.e. the router is .60 -.99, pi-hole .120 - .129 in case it reports 2 server active when the debug run. Didn't want to knock Mrs B off in the middle of her classes.

nqdix0uqe1

What DNS server is this?

dns-server: 192.168.70.200

That's the pi-hole, the Wi-Fi interface, I forget which now but something complained with only 1 DNS server so I have it set to 'Listen on all interfaces' and put that is as the 2nd DNS.

I went through and removed .200 and that reminded me what the issue is. If I leave it blank in the router then the router returns the gateway address i.e. itself and then forwards the request to the DNS on the WAN, currently OpenDNS so bypasses the Pi-Hole for 1/2 the requests.

You don't want that. Try the following things in order on the router DHCP settings:

  1. Pi-hole IP listed twice.
  2. Unused IP from your LAN listed in the second spot.
  3. 0.0.0.0 in the second spot

Thanks.

Okay done that. listed Pi-Hole twice in the router and that's working, removed it from the Pi DHCP configuration too, so there is only the single DNS there. I've put Wireshark on and can see what is happening or rather is not happening.

Using nmap the Pi-Hole responds to the DHCP discover but from the other clients does not. Although sometimes I am seeing broadcast DHCP request with no discover preceding it and sometimes the clients will send a request direct to the router

The only difference I can see is with nmap there is a source IP rather than 0.0.0.0 broadcast since it comes form an already established client. Everyone else is up and expecting internet so will have to put it back to normal for now.

Your above observation seems normal.

An active DHCP client that already has acquired a lease will begin lease renewal by direct unicasts to the DHCP server that issued that lease. Only when that DHCP server is not responding or denying the request will a client try to renegotiate a lease by broadcasting for available DHCP servers again.

Also, note that nmap's broadcast-dhcp-discover script is not telling you the full truth when multiple DHCP servers are present on the same link, as it registers only the very first DHCP answer it receives.

I am only having one server active at any time.

I've since setup the server on my NAS to prove that it is not a network thing and that works fine, responds to clients and to nmap. Tried again this morning before everyone else was up and needing stuff working but no joy from the Pi from clients.