I used this with the old version a lot. now I have to wait days for leases to be expire, it is frustrating. I want to see if a device is still active on my network. if I reboot opnsense it will just give the active valid lease so, rebooting does not work. If I had a button like before I can just delete the lease and see if the device requests again without rebooting. Also, when I add a static ip the dhcp lease stays.
Is there a way to delete the ip lease so I may better control my network? not having it seems illogical as it is very handy and useful to have.
Thanks in advance
I am in similar situation and hoping for a straightforward, clean solution.
I have some devices I need a reserved DHCP address assigned. The wifi mac is not printed anywhere, I have to connect to ethernet or wifi first to get that. I set up a reserved IP assignment in DNSMasq, then reboot the device. It just gets the dynamic IP back. The devices have no options to do anything else.
If I use the magnifier glass next to the dynamic lease in DNSmasq it takes me to the static assignment record. But still the device IP doesn't change until the lease expires.
The workarounds I have used:
1. Stop DNSMasq, edit the DNSMasq active leases file and remove unwanted leases or change the lease time, then start DNSMasq again. I haven't seen any side effects but I don't like editing files as I'll never know when it might cause a problem.
2. After the static assignment is in place, do a factory reset on the device then configure it again. Doable but not really desirable. And doesn't always work; some devices STILL get the dynamic active lease back.
3. Set the default lease time to something short *before* I connect the new device for the first time. I also need to wait until some devices (that tend to behave badly during lease renewals) are not going to be renewing during this time. If I forget to alter the default lease time then it's back to #1 or #2 or have to wait for the lease to expire, before I can finish setting up the new device.
Are there any other options I can use, to get the reserved IP assigned when the device can't cause it to happen?
I did read in Github and elsewhere that adding a delete lease function is not planned, for reasons such as possible inconsistencies. Could the active lease time be edited in the GUI to some minimum time, like five minutes, so DNSMasq could expire it in a normal way and assign the reserved IP?
Hi,
sorry to say but I guess you two do not understand how DHCP leases are designed...
DHCP leases have a lease time configured. Usually something about 7,200 seconds. This lease time will be send to the client together with the IP information.
So in order this is what happens when a client is configured to use DHCP:
1. client boots and sends a broadcast (dst address: 255.255.255.255, src address: 0.0.0.0) to DISCOVER the DHCP server
2. The DHCP server replies as broadcast including a suggestion (!) for IP configuration (called OFFER)
3. Client receives this reply and checks the provided information
4. In case the client can not accept the IP information (for some reason) it waits and re-starts with 1.
5. If the information is fine it will send a REQUEST packet asking the DHCP to use the requested IP
6. DHCP server confirms the use of the address and provides additional information (lease time, ntp server, ...) with an ACK
7. client is working with the provided information
8. when half (!) of the lease time has been passed, the client sends a renewal request for further usage of the IP
9a. DHCP server confirms the usage- lease time starts again. Client does 8 again after half of the time has passed
9b. If client does not get reply, it waits until 3/4 of the lease time has passed and sends the renewal request- see 8.
9c. If DHCP server refuses the further usage, does not reply at all or the lease time has passed the client releases the IP (and has not IP configuration any more)
So for you request this means:
On behalf of the DHCP server (OPNSense) you can not force a client to release or re-request an IP! If the DHCP lease time has not passed the client is still allowed to use the IP. At least until half of the time has passed. IF you reboot your server it usually does not know about the already given leases and when a client re-request after half time it might get a new IP (because the server is not aware of the already existing lease). In the end, rebooting the server (or letting him "forget" the lease) causes more trouble....
However, I see your issue. My suggestion:
Configure your DHCP server (TBH unsure if this is possible with DNSmasq) to give unknown clients only a VERY short lease time (ie 60 seconds). And for the known clients (which means there is a static lease configured) the default lease time. Thus, your client re-requests the IP very frequently and you can easily move the dynamic lease to a static one and the client will pick it up after 30 seconds....
[EDIT]:
Just checked for the ISC DHCP server on OPNSense:
Configure default lease to 60 seconds. An overwrite this default setting in every static lease by setting it to 7,200.
/KNEBB
Hi Knebb,
I don't think you understand the issue, or I'm not understanding your suggestion.
Just to clarify, we are using DNSmasq not ISC. ISC already has a delete button.
The issue is the new client has *already* joined the wifi and now I am stuck dealing with that lease.
Yes the default lease could be very short. Refer my option #3, a temporary short lease. But that only works if I know when the client will join so I can be ahead of it.
A permanant short lease is possible but means most of my clients (dynamic) will constantly renew, maybe that works for the OP but it's not desirable for me. My default lease is intentionally long.
FWIW I have had several routers with DNSMasq in the past, though it has been some years ago. This wasn't an issue with those implementations. I do not recall how they worked, I found my old notes and I don't have any steps written down. So it had to be something obvious like a delete button, or a device reboot caused a static assignment to replace any dynamic that existed - something along the lines of the router handling the issue, not me.
Dnsmasq will not get a lease delete button.
Adjust your workflow around that fact, maybe stop to micromanage DHCP leases and just turn them into reservations without changing the IP address?
For Dnsmasq it doesnt matter if the lease is inside the range, it will be reserved unlike in ISC.
Reference, we tried but decided against it ultimately: https://github.com/opnsense/core/pull/8899
DHCP is a contract between client and server that for as long as the lease time is valid, the IP is allowed to be used ONLY by the client and unique. There is no control protocol that can update the fact that the server deleted the lease to the client. Only the client can send a DHCPRELEASE to tell the server to delete the lease. Deleting leases on the server is always unexpected for clients and not a good workflow.
As I mentioned I did read in github and others that the delete button is not coming (I am not the OP of this thread).
It's not about micromanaging... that's unfair and rather harsh. There are many uses for specific IP assignment and getting it all set up in one go, instead of breaking the task up because a lease won't expire for some times. Yes the client should be doing the release but not all devices do it.
I'm unclear why other DHCP products and even at least some past DNSMasq products were able to help here, but this one won't.
The best course of action would be asking over at Dnsmasq for a canonical way to delete a single lease on FreeBSD?
Cheers,
Franco
Quote from: pseudonym3k on January 15, 2026, 09:14:22 PMI'm unclear why other DHCP products and even at least some past DNSMasq products were able to help here, but this one won't.
They faked it! @Monviech (Cedrik) has confirmed my post: there is no way a given lease can be recalled! Earliest will be half of lease time. If there were products offering a "delete lease" button they deleted the mapping but did not remove the IP from the client.
You can archive your goal but you have to re-design your setup then. Create static mappings for you known clients, reduce lease time for unknown clients. You might consider to move dynamic clients to a different (V)LAN if this option is not suitable. Or join you new client to a different net to discover the MAC (although it is mostly written somewhere), create a static mapping and move it to the target net.
However: based on technical implementation you simply can not "delete" a given lease. If other product offer this it is faked!
Quote from: knebb on January 16, 2026, 09:15:38 AMthere is no way a given lease can be recalled
I'm not sure this is true. At Franco's suggestion I've sent a message to Simon Kelley, the developer of DNSMasq, as I searched his discussion list archives and found out he provided a script that could be attached to a button to remove a lease without stopping DNSMasq. This is what I likely used way back when since I don't remember having these issues. I've asked if this is still available or if he can recommend another method to settle this issue. I hope he'll respond to my query.
ETA: Here's a quote from Simon Kelley on DNSMasq discussion list: "dhcp_release works by faking up a DHCP message as if it's coming from the DHCP client, which tells the server to release the lease."
This is exactly what I'm hoping for, a way to tell DNSMasq to perform all standard processes to release the lease.
What knebb said is true. On a protocol level, there's no way for the server to revoke a lease once it's been given out to the client for the lifetime it was given out.
Yes you can restart the server and forget the lease, but technically speaking the two are not the same.
Cheers,
Franco
And while I was writing the above edit, I've had a reply from Simon Kelley:
In the dnsmasq source tree, there's a directory called
contrib/lease-tools
which contains what you're looking for.
Cheers,
Simon.
Would someone from OPNsense be able to take a look at this and see if it is possible to implement?
Im not sure if we are going in circles now?
https://github.com/opnsense/core/pull/8899#issuecomment-3031389959
dhcp_release(6) works on the surface: it basically fakes the client releasing the lease.
I don't mind integrating it if it works as a stand alone tool, but there's no ETA and the work still needs to be done.
Cheers,
Franco
I thought it required dbus initially to send the command. I guess I assumed wrong.
Quote from: franco on January 16, 2026, 06:07:23 PMI don't mind integrating it if it works as a stand alone tool,
Could the lease tools be pushed to the appropriate directory? Then some of us could run from command line while waiting for GUI integration?
Ok, re-read the specs and can confirm the above offered "delete the ip on server" appears to be working. Although with a minor inconvinience:
For the server the IP is not assigned while it is still in use by the client.
So what happens when another client requests an IP address?
-client A has IP .12 and its leases got deleted on the server side
-client A still uses this IP as long as half of lease time hast not elapsed
-client B starts DHCPDISCOVER to get an IP
-server offers IP .12 to client B as it is marked as available
-client B sends an ARP request to check the IP
-client A sends ARP reply ("this is my IP")
-client B send DCHPDECLINE to server
-server marks this IP as "invalid" for further usage
-client B starts over with DHCPDISCOVER
-server offers different IP .13 to client B and client B uses this one...
-on the client A when half lease time has elapsed it'll ask for further usage of IP .12
-server declines further usage (as it is marked invalid) with DHCPNACK
-client A starts over with DHCPDISCOVER and will get a different IP .14
So indeed the protocol is fail-safe and you can delete a lease on the server side without any friction in the network.
The minor glicht I mentioned is the fact there is an IP address in use which (for the server) has not bee assigned. At least for half of lease time.
And this is not reflected in the server state...
And there is a second problem:
The IP will not be release or renewed before half of the lease time has passed. So when using a static lease for this client it will use the IP not earlier. And this is the same for both cases where I delete the lease on server side or create a static lease....
So I still do not REALLY see the advantage of such a "delete" functionality.
/KNEBB
My regular workflow is:
- connect new $DEVICE to network
- look up lease in the "DHCP UI"
- create static mapping
- delete dynamic lease (if necessary)
- powercycle device
Specifically if you connect a whole lot of new IoT thingies - who cares about lease times etc? Switch it off and on again, the IP stack in these things is reduced to the max, anyway.
> So indeed the protocol is fail-safe and you can delete a lease on the server side without any friction in the network.
yes but
> The minor glicht [...]
> And there is a second problem [...]
> So I still do not REALLY see the advantage [...]
:)
As I said I don't mind if there is a canonical tool which there is. I'll try to get it into the dnsmasq port. If it compiles and works it's good enough for the GUI button.
Cheers,
Franco
Quote from: knebb on January 19, 2026, 08:44:29 AMFor the server the IP is not assigned while it is still in use by the client.
So what happens when another client requests an IP address?
Maybe I'm not fully understanding your scenario, but it seems like what you describe is same or close to what happens when the client itself sends the DHCP release? (Meaning, the client we did the phony release for, still thinks it has the lease, but it doesn't actually have it, right? So another client can request it, same as if the release was genuine?)
The difference I see, one client thinks it has a lease and the other one doesn't. But in both cases (for different reasons) they both will experience DNS and internet connection issues until a new lease is assigned. I don't know what transpires to get a client, that didn't request a release itself, to pick up the a lease. I don't remember having any trouble in this area with past DNSMasq routers that I've used, but maybe I just didn't happen to experience any.
Quote from: franco on January 19, 2026, 09:41:51 AMAs I said I don't mind if there is a canonical tool which there is. I'll try to get it into the dnsmasq port. If it compiles and works it's good enough for the GUI button.
Thank you very much Franco.