Pi-hole setup and working well. Moved DHCP duties from the Wi-Fi router to Pi-hole. Also moving some devices, which have static IP addresses, to static DHCP leases. This working well for many devices... get the MAC address, enter it and the desired IP address and a host name. Easy-peazy.
But then there is our Ooma Telo VOIP device. Like some other devices, it had a static IP address. I removed the static IP info and changed the IP type to "Dynamic (DHCP)" ... and when the system restarted, it had a regular (non-static) DHCP lease. Found the device listed in Pi-hole's DHCP list, got the MAC address (which is the same as in the Internet networking settings on the Telo), and created another static DHCP lease. Easy. Then restart the Ooma..
Aaaaaand, no go. The Ooma didn't get the static DHCP lease, it got the regular dynamic lease.
Multiple restarts, no joy. Tried all the way to Ooma level 3 support. Nope. Is it Ooma? Is it Pi-hole? Is Ooma not taking the correct static IP from DHCP or is Pi-hole not correctly providing it?
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
New data:
Have found a second device that is refusing to get a static DHCP lease...
Device: RainMachine Pro 16 (automatic sprinkler controller).
Previously it was set to a static IP. I've changed the DHCP scope and this IP (.98) is within the new range. Initially I thought I'd changed it to DCHP, but apparently not, so I just thought the RainMachine was picking up the static DHCP lease, but it wasn't (both the static IP address and the static DHCP lease were using the same IP address). Once I actually set the RainMachine to DHCP, it is now using .251... very different from what was wanted.
Am doing a bit more searching on this. A Google search for "why a device won't take a static dhcp lease" turned up this:
In the discussion thread, item #10 says this:
It's because "client-id" is same kind of condition as "mac-address". You're telling RouterOS that it should give 10.1.2.2 to client which has mac-address 00:04:20:07:A9:E3 AND sends client id "squeezebox". Remove client ids and all will work as you need it. To describe entries, use comments (comment="something" in command line or yellow sheet icon in WinBox).
So, am wondering if Pi-hole is sending too much data to the devices in question during DHCP negotiations, and they are then discarding the static DHCP lease due to the inclusion of hostname data. This is just a thought, and I don't know if hostname data is included and if this is why they aren't responding, only that the provided example seems to go in that direction.
They are the only ones sporting hyphens (-) instead of colons (:) as separators.
pihole-FTL is a tailored version of dnsmasq, and dnsmasq's documentation isn't very concise nor comprehensive on the exact format of <hwaddr>, but at least all the examples for its dhcp-host option do use the colon variant.
I'd guess the hyphens will prevent pihole-FTL from recognising 00-18-BA-5E-BA-77 as a matching DHCP lease reservation if your client would identify itself as 00:18:BA:5E:BA:77, so that it would hand out a free IP address from its pool instead.
Could you please verify that assumption by changing your lease reservations accordingly?
To prompt renegotiation, that may require pihole restartdns, and perhaps also a reboot of your client.
You, sir, are a steely-eyed DHCP god! Great catch, that worked. I'm sure I used the dash variant of the MAC address because my network scanner utility is showing me them with the dashes, and I did a copy-paste, not thinking there would be any issue. Are there any conditions in which the dashes would work? If not, perhaps the Pi-hole code should check for dashes and either convert them to colons automatically, or alert the user.
