Pi-hole instance can statically asign IP addresses, but cannot do so dynamically

Help
1

I apologize if this is formatted incorrectly, as this is the first post I have ever made on any forum asking for help. I have never run into an issue that was unique (no other posts on any related forum about the same or tangentially related problem). I assume this is user error, but the behavior is strange enough that it might not be.

Expected Behavior:

Pi-hole should dynamically allocate IP addresses when acting as a DHCP server.

  • 64bit pi-os lite (headless version of 64bit pi-os)
  • Pi4, 8gb, 0.5tb disk
  • Installed via download and install script

Actual Behavior:

Pi-hole is not dynamically allocating IP addresses but is allocating statically set IP addresses. To state another way to avoid confusion: a client is set to DHCP, and Pi-hole correctly assigns it an IP address when Pi-hole is told to give that client a specific, static IP based on its MAC address, but if Pi-hole is not used to assign a static IP to that client, it will not issue an IP address to that client device dynamically.

Obviously port 67 is open (otherwise static IP addresses set via Pi-hole would not be given to respective machines asking for an IP via DHCP). The box for telling Pi-hole to only allocate IPs to known devices is NOT checked; checking, saving, unchecking, and saving again has no effect. IP range is not overly large (pretty typical 255.255.0.0 net mask). Pi-hole is set to dynamically allocate IPs ranging from 10.0.100.1 to 10.0.255.254. There are no other DHCP servers on the network that PI-hole is attached to and running on. DHCP guarding via top level inward-facing firewall has no effect on this behavior, but is disabled in order to remove any issues potentially caused by it. Once a device is connected via static IP assignment from Pi-hole, it is allocated the proper net mask, gateway, and can see other devices on the network in addition to accessing the internet. The only other service running on the Pi-hole server, other than default systemd services from the OS, is Unbound. Unbound works as expected in all capacities and is both seen and used by devices handed IPs statically by Pi-hole.

This error occurred after a power supply failure killed my previous pi that was running Pi-hole + Unbound without this issue. Previous Pi was the same hardware (Pi4, 8gb, 0.5tb disk). I am on all new hardware (pi, hard drive, power supply) and running a fresh install of Pi-hole following official docs exactly. Teleport from the old server was tested and had no effect on this issue vs manual configuration.

An interesting bit of unexpected behavior is that if I assign a device a static IP on Pi-hole (one which does not dynamically change is MAC address), allow it to connect, delete the static assignment from Pi-hole but leave the timed IP lease, disconnect and then reconnect the same device, that device will not be handed an IP by Pi-hole and will remain disconnected from the network even though Pi-hole has an active DHCP lease for that device.

I have never seen behavior like that from any DHCP server and am at a loss for what could cause it.

There is no debug token or error recognized by Pi-hole so I assume there is either a bug causing this or it is user error. (also I have no debug token to report) Normally it is user error, so I would like to rule that out prior to chasing down a bug that is not there.

Any help would be highly appreciated as I am completely stumped.

Debug Token:

No debug token was created by the system.

2

You need to generate the token:

  • execute sudo pihole -d;
  • upload the log when asked (answering with Y);
  • post here just the token URL that is generated after the log is uploaded.
3

One remark, if the clients are acquiring IP details via DHCP, they are all dynamically assigned.
The D in DHCP for dynamic.
Dont confuse a true static IP configured manually on the device itself with a static DHCP reservation coming from Pi-hole or your router!

4

I apologize if I caused any confusion with the terminology, I do not know of another word to use to describe the difference between the two ways a user can direct a DHCP server to assign IP addresses. Maybe if you replace any time I say “dynamically” with “randomly” the concept I am attempting to describe will become clear.

Edit: I am aware of the distinction between the two “static” IP assignment methods.

5

One is a DHCP reservation, the other is not.

EDIT: You have a regular DHCP lease;
a DHCP lease reservation;
and a true static IP configured on the device itself.

6

Debug token generated:

URL: https://tricorder.pi-hole.net/6Tu62k5o/

7

Since you did not know any other word to describe the difference I was wondering if you have not (by accident) configured something like this : https://unix.stackexchange.com/questions/773084/dnsmasq-pool-without-assigned-ip#773088

A lot of DHCP Servers have the option that if there is no Static DHCP IP Address Mapping based on the MAC Address (a.k.a. DHCP Reservation) for a Client to not give it any IP Address at all !! :wink:

8

I know this is an option but it is disabled underneath pi-hole’s UI. Toggling it on and off again doesn’t effect the behavior. I have not checked dnsmasq configs directly since I have not touched those configs on the server. Pi-hole is the only thing that has modified the configuration of dnsmasq. I’ll check to see if they were misconfigured by Pi-hole and/or are not being reconfigured properly upon configuration edits within Pi-holes UI and repost after that.

9

I checked and dnsmasq is not being misconfigured by Pi-hole (at least so far as the config file is concerned). As I had attempted to say in the original post, Pi-hole is configured to hand out IP’s to all requests, not just known clients, and it looks like dnsmasq is not being misconfigured to behave differently than the UI is displaying.

10

I tested a server running just dnsmasq and gravity without Pi-hole on top of it and it works as it should with the same settings that are entered through Pi-holes UI.

I then tested a re-installation of Pi-hole via docker and did a teleport style backup and it again worked (in that it handed out IP addresses).

I reinstalled Pi-hole on bare metal again and that too worked as expected…

EDIT: everything below this line was posted but I was completely wrong in thinking it was a bug with Pi-hole. See later posting for correction.

Because a teleport level backup was used in each instance (i.e. settings/configs are unchanged), I am going to call this a bug… I have not blown away the original, broken instance so I can rip information from it if needed to help anybody who needs it.

Since this is a bug in Pi-hole that was resolved by re-installing it and restoring from a teleport backup, I am going to close this post. I will report this as a bug and be as helpful as possible in hunting it.

1 Like
11

Glad to hear you solved your issue.

I had a look at your debug log yesterday, but didn't find the time to compile an answer then.

Your DHCP configuration looked good, no obvious misconfiguration.

I can't quote from it anymore, since the log has since expired, but I recall it to having contained a few dhcp log lines.
Those lines demonstrated that some of your devices were REQUESTing to be assigned specific IPs from the far end of your DHCP range (e.g. .254). Pi-hole NAKed those because it had a DHCP reservation for the device's MAC, and offered the reserved IP instead.

I wonder how these devices had been assigned an IP at all.

I also noticed some of your devices to be TP-Link or Ubiquiti, i.e. potentially additional networking equipment.

When looking for an explanation of your observation, I'd have guessed that it was a result of your power supply failure:

Could it be possible that during the time that your Pi-hole's DHCP was down, other network equipment would have re-instantiated their own DHCP server?

Also, your new Pi-hole was completely unaware of DHCP leases that had been active at the time of your old Pi-hole's failure.

This may have lead to situations where your new Pi-hole would have handed out an IP to one device that another device already had acquired from the old Pi-hole. In turn, the client may then have declined the offered IP on DAD, and Pi-hole probably would have continued to issue the same IP, being unaware that it is already in use.

If that had been the case, your observation should have ceased after all your clients leases had expired and they had renewed their DHCP lease with your new Pi-hole, so the DHCP server would again have a complete list of all its DHCP clients's active IPs.

12

I did some digging because I do not have another DHCP server on the network aside from Pi-hole, and it turns out that there is a bug in gen1 ubiquiti switches (24 and 48 port models), which I have a few of, that will cause them to act as erroneous DHCP servers, and hand out leases to devices with odd parameters. The power supply failure also killed a few other network services, one of which was a firewall that, among other things, was responsible for DHCP guarding… I checked the logs for the DHCP guard and sure enough, after it came back online it had blocked a network switch (of all things) from acting as an erroneous server on the network…

Long story short is that gen1 48port ubiquiti switches have a bug which can cause this behavior. It likely would have happened to any service (Pi-hole, technitium, etc).

I would have never investigated that if you hadn’t mentioned that possibility. Thank you.

2 Likes
13

W-T-F ?!?! Another weird Ubiquiti thing !!! :enraged_face:

Can you tell us the exact models ?
Firmware versions ?

Since I have 8-port and 16-port UniFi models I am guessing it won’t happen, but you never know with those guys…

14

I’ll say this, since it is still pertinent to the topic at hand: the firmware version are at the latest as of writing (version 7.2.123) and ubiquiti is aware of the problem but has not addressed it. The exact models are gen1 48port and 24port switches. Ubiquity gen1 hardware naming was pretty simple as they offered few products and were a much smaller company back then. If you wan a model # (if you can call it that) then they are US-48-G1 and US-24-G1, which stand for United States-48/24 port-gen1.

To that end, I will say that this is a fairly complex network where the vast majority of traffic is internal with 2 layers of aggregation before the client level is hit (hub and spoke model) and this is the first such bug I have encountered that is directly attributable to them.

I probably should have had a redundant power supply running that bank of computers to avoid outages like this so I view this as more my fault for not properly protecting critical network services at a hardware level. That, however, is starting to get off of the posted topic.

1 Like