When I assign a status DHCP reservation to an existing device, there is no way to delete the device's current DHCP address assignment from the GUI.
Looking for an option to do so in order for it to instead get the new, static assignment.
Thats because the clients need to update/get changed DHCP details themselves.
Pi-hole can not force a client to renew its DHCP lease at any moment.
You can wait until the DHCP lease expires on the client (Pi-hole DHCP default = 24 hours).
Or release/renew the DHCP lease on the client.
For Windows you can do for example:
ipconfig /release
ipconfig /renew
For Linux:
sudo dhclient -r eth0; sudo dhclient -v eth0
No, this is not sufficient as the server will gladly "renew" an existing IP address. It may work on some OS, but certainly not all and certainly not ones for which I want to assign statics.
Instead I want the Pi-Hole to send a DHCPNAK and force the new static reservation.
See: https://www.serverbrain.org/network-services-2003/how-the-dhcp-lease-renewal-process-works-1.html
The dnsmasq software embedded in pihole-FTL handles the DHCP functions. If dnsmasq cannot do this, then Pi-hole cannot.
1 Like
Your reasoning is slightly flawed if I understand correctly.
A DHCP server will never initiate DHCP traffic .
It wont make contact with its clients on its own.
The clients initiate and the DHCP server answers.
On most Linux clients, you have the dhclient binary that is called on before the lease expires.
It runs once, assigning IP's for the interfaces, and thats it.
It doesnt keep on running waiting for some DHCP server to contact it in a daemon fashion way.
So you cant create a button in the web GUI telling the client to release its lease instantly so it can accept a new one.
Either you have to wait out the lease period or manually release the current lease on the client itself so it can accept new one.
1 Like
You should be able to do so manually by deleting a lease from Pi-hole's lease file at /etc/pihole/dhcp.leases.
@deHakkelaar is right:
DHCPNAK is a DHCP server's reply to a client's request, not a message a DHCP server will send on its own.
What you seem to aim at is to initiate renewal of a client's DHCP lease by a DHCP server.
While this has long been specified in RFC 3203 - DHCP reconfigure extension as a FORCERENEW unicast, it has never reached significant implementation support in DHCP servers.
A major reason is that unauthenticated use of such a message would pose a substantial security threat, so RFC 3202 requires that "the FORCERENEW message MUST be authenticated using the procedures as described in [DHCP-AUTH]".
But alas, corresponding RFC 3118 - Authentication for DHCP Messages has never seen much support either, as it would rely on proper prior client-side configuration of authentication details- and that somehow defeats the very idea of a DHCP server provided configuration.
So I doubt we will see support increasing for this in the future.
Even if you would find a DHCP server that does support RFC 3202 - support in end user client OS is also lacking.
And even if it would be present in your OS, it would still be the client's decision how to deal with that message (it's probably safe to assume that a client with a static configured IP will ignore it, and rightfully so).
That's correct.
But it's also the client that will try to renew an existing lease for its current IP address, and it will do so well before its current lease expires. As long as the existing lease is valid, DHCP will renew it - and that seems to be what's causing your concern.
While there is merit in invalidating an existing lease, I probably wouldn't want it as a UI feature.
First, it would still require a user to manually force a client to renew its DHCP lease immediately afterwards.
And then it also poses the risk of accidentally deleting lease information for a static client correctly registered with Pi-hole's DHCP on client start (and I refer to on-device static configuration here, not a DHCP lease reservation).
Unless rebooted, the static client may never inform Pi-hole's DHCP server of its static address again.
Without that information, the DHCP service may assign that same static IP address to any client requesting a new lease, causing it to fail, which in turn may result in the new client not being able to join the network at all.
These side effects may occur a long time after lease deletion, making it harder to associate misbehaviour with it, and thus harder to troubleshoot.
To avoid these confusions, I'd rather not expose such a feature via Pi-hole's UI, at least not without properly guarding against potential side effects (which may not be possible in code, as obviously the user as well as uncontrollable client devices are involved) - but that's just my personal opinion. 
2 Likes
I am moving clients from dynamic to static DHCP reservations in this case. The "copy" button next to a dynamic reservation actually copies all the relevant data into the static reservation definition field.
For me at that point its not possible to "renew" on the client to get the newly defined status reservation since the server will renew the existing lease.
The workaround right now is to disable pi-hole DHCP, toggle DHCP on the client and then restart the Pi-hole DHCP server and refresh the client.
The upside is this clears the dynamic reservation for the host, but the downside is it clears the dynamic reservations for everything else too.
The default behavior of the DHCP server is to do an ICMP ping before it assigns addresses, so that works ok in this scenario.
I assumed than when I had the client "refresh" its address in this case, the server would see the static and issue the DHCPNAK in response, but clearly thats out of scope for pihole.
So I suppose what I am asking for is a UI button next to the copy button to remove the line from /etc/pihole/dhcp.leases so long as that file does not require the DHCP server be restarted.
Just to cross-link:
https://github.com/pi-hole/AdminLTE/issues/1026
2 Likes
O my, @Bucking_Horn quoting RFC's again.
He's like an RFC handbook
Super !!!
@JeremyLaurenson, the DHCP assigning of IP's is still dynamic in nature even when creating a static reservation.
The reservation is a static one (eg the IP wont change) but the IP address is still handed out dynamically via DHCP (the D in DHCP).
A true static IP can still only be configured on the client itself and not via DHCP.
For example, I have my NAS configured with a static IP on the device itself (not via DHCP).
And on top, for fallback, created a DHCP reservation with the same IP to make sure that if the NAS would loose its static IP address assignment somehow, it would still be assigned the same IP via DHCP.
The wording "static DHCP lease reservation" might confuse allot of people.
Better to just say "DHCP lease reservation" instead and drop the word "static".
In my understanding, a NAK is an error state of something going wrong.
Thats not the case here so it would be inappropriate for a DHCP server to send a NAK when a client makes contact.
Plus would be hard to implement as Pi-hole would need to keep a record of which clients would need a NAK (only once) if the user desires so.
In the end, you still have to release/renew the lease on the client anyway if want the changes to take effect immediately.
So that defeats the purpose of sending those NAK's.
Server doesnt need a restart but a reload.
But the problem with removing a current active lease from the dhcp.leases file is that this is a one side operation.
The client isnt informed that its lease was removed server side.
This could inadvertently cause other issues with users that are not familiar with DHCP.
Ok, I get it - you guys are not interested in solving a usability problem. I think that its likely then something that I will take up and script myself since Dnsmasq has scripting extensions.
While we're not solving the issue and quoting RFCs and talking mechanics of DHCP, from the DHCP RFC 3203:
" If the server wants to assign a new IP address to the client, it will reply to the DHCP REQUEST with a DHCP NAK. The client will then go back to the init state and broadcast a DHCP DISCOVER message."
-Jeremy Laurenson
CCIE 8849
Distinguished Architect, Cisco Systems.
No, far from that.
We are discussing a feature request here.
I've supplied advice on how to deal with this manually (at least as far as deleting the lease itself is involved, also acknowledging -even meriting- your request), and I've explained in detail my reservations against incorporating this in Pi-hole's UI, explicitly marking that as my personal opinion.
Those two quotes are in line.
Note that it is the client that initiates the conversation, not the DHCP server. A DHCP server cannot simply issue a DHCPNAK out of context. I've already mentioned the RFC that is instead meant to tackle this, and explained why it hasn't found much implementation support thus far.
If you succeed in this, the Pi-hole team would be happy to consider your contribution. Pi-hole is a community-driven project, the development team welcomes input such as yours. A feature request backed by a reference implementation is much more likely to be accepted, though of course, the final decision rests with the development team.
1 Like
I am not suggesting the server initiate a NAK, Im suggesting that when I do an ifconfig /renew it'll NAK it
As discussed above, Pi-hole's embedded DHCP server dnsmasq does issue DHCPNAKs, but prefers to honor existing valid leases over newly defined lease reservations (hence my advice on a manual work around). It's this behaviour of dnsmasq that doesn't sit well with you as well as other users, but I wouldn't know how other users of dnsmasq think about this.
It would be great if you would be able to get on top of this by scripting dnsmasq and share your findings with the community here.
If that turns out not to be possible, it would probably be prudent to approach the maintainer of dnsmasq, and the more people get behind this, the better.
Trying to impress ?
I'll show you how its done without any NAK's:
pi@noads:~ $ grep laptop /etc/dnsmasq.d/04-pihole-static-dhcp.conf
pi@noads:~ $
pi@noads:~ $ grep laptop /etc/pihole/dhcp.leases
1592165473 00:1f:29:xx:xx:xx 10.0.0.16 laptop *
dehakkelaar@laptop:~$ ip -4 -br address show eth0
eth0 UP 10.0.0.16/24
pi@noads:~ $ grep laptop /etc/dnsmasq.d/04-pihole-static-dhcp.conf
dhcp-host=00:1F:29:xx:xx:xx,10.0.0.199,laptop
dehakkelaar@laptop:~$ sudo dhclient -r -4 -v eth0
Killed old client process
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/00:1f:29:xx:xx:xx
Sending on LPF/eth0/00:1f:29:xx:xx:xx
Sending on Socket/fallback
DHCPRELEASE on eth0 to 10.0.0.2 port 67
pi@noads:~ $ grep laptop /etc/pihole/dhcp.leases
pi@noads:~ $
dehakkelaar@laptop:~$ sudo dhclient -4 -v eth0
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/00:1f:29:xx:xx:xx
Sending on LPF/eth0/00:1f:29:xx:xx:xx
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPREQUEST of 10.0.0.199 on eth0 to 255.255.255.255 port 67
DHCPOFFER of 10.0.0.199 from 10.0.0.2
DHCPACK of 10.0.0.199 from 10.0.0.2
bound to 10.0.0.199 -- renewal in 36551 seconds.
dehakkelaar@laptop:~$ ip -4 -br address show eth0
eth0 UP 10.0.0.199/24
pi@noads:~ $ grep laptop /etc/pihole/dhcp.leases
1592167949 00:1f:29:xx:xx:xx 10.0.0.199 laptop *
Dont forget to press the "Save" button (like I did) after adding a reservation!
Trying to explain that I know how DHCP works, since the answer to the request seems to be trying to "educate" me. I am well aware of release/renew cycles.
Again... trying to "educate" me. I am well aware of release/renew cycles.
As I mentioned in the original post, the devices I am working with continue to simply try renew the existing lease. They do not have robust release commands or access to CLI at all for that matter. This is the case with a variety of devices such as cameras, alarms and other IoT equipment
I am perusing the dnsmasq team.
Is Cisco interested in sponsoring new features and code?
1 Like
Yes thats what we do here.
Educate and get educated.
I've learned quite a bit here sticking around.
And I believe I just educated myself a bit.
dhclient does daemonize itself for every interface that it acquires an IP lease for (two interfaces in below example):
dehakkelaar@laptop:~$ sudo netstat -nltup | grep 'Proto\|dhclient'
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:68 0.0.0.0:* 1711/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 599/dhclient
From what I read/understand, it waits for the lease to expire so it can renew.
And keeps the 68 port, thats used as the client source port for DHCP communication, in a listening state so no other processes can interfere/occupy that port ... if I'm correct.
Would you be able to give feedback what the dnsmasq team has to say ?
They will probably also throw RFC's at you.
And those devices that wont allow to release their lease manually are just plain stupid