Hello,
I would like to request a new button on the "Active DHCP Leases" list next to the "Set Static" called "Remove" that would remove an existing lease.
Removing a lease is useful and it is mostly just about deleting the line from /tmp/dhcp.leases and by restarting dnsmasq afterwards. Other firmwares like DD-WRT to it and it seems to work.
Thank you.
Please excuse my obvious ignorance: for what exactly? The device in question would neither lose its lease nor receive a different IP upon renewal.
It is useful when you're testing a ton of devices, containers or VMs and you need to cleanup your DHCP leases. You may run out of space or you simply want to see if the device is able to properly request a new clean lease and everything works properly.
There are other more annoying cases, for instance if you plan to assign a static lease to a device and it already has an IP, then it will keep the old address until the lease expires. The static leases UI also doesn't deal very well with this scenario.
The device in question would neither lose its lease nor receive a different IP upon renewal.
Yes that may happen under a bunch of cases, however not having a way to remove it is way worse. Besides dnsmasq will most likely eventually support FORCERENEW that will fix that problem.
I'm not saying a "Remove" button will make everything perfect and fix everything. I'm just saying it can be there and if you search there are lot of people looking for ways to remove leases as well.
Is such a fringe case realistically remedied by a "remove this one single lease" button? How many hundreds (or thousands?) of leases are we talking about, and is it practical to click the "remove" button and restart dnsmasq equally a hundred times?
LuCI conveniently orders DHCP leases by age, the most recent on top.
Removing a lease from the leases file will not change anything about that. The device reconnecting or the lease on the device expiring will, and the button cannot do that for you.
I'm not trying to be confrontational, but unless and until dnsmasq gains FORCERENEW functionality I'm not convinced a "remove" button solves much of anything except very superficial cosmetic issues, bought with the wrong impression that it actually did something.
It is way easier with a "Remove" button than with nothing 
I'm not entirely sure if DD-WRT is restarting dnsmasq but it does seem to work.
Here's the problem, while the old lease is on the table (and not expired) the device will not be leased with the new static IP.
Just try it yourself. Pick some device that was assigned 10.0.0.201 automatically, then set it to 10.0.0.10. Until that first automatic lease expires the device will never be able to get the x.10. It doesn't really matter if the device disconnects and reconnects, once it asks for a lease the router will happily serve x.201 because it was already on the table.
Having the button would make this easier, as I could just set the static lease, then, delete the old lease and reconnect the device.
Sorry, but I cannot confirm that. Neither in a quick test right now, nor ever before did I have to manually edit or empty /tmp/dhcp.leases for a device to pick up a new/changed static lease.
You will have to restart the client to get it to renew a release already given before halftime or later of the leasetime.
You can delete the whole lease file or restart the whole router without anything happening to the leases before the timer in the clients runs out so the router can’t do anything about this issue.
You can set leasetime to 5min to speed up the process while doing testing and dev.
Like @flygarn12 said, there's no method to force a client to renew its DHCP lease before the lease time is up, so that button, not only useless for a large majority of users, is also meaningless as it will not force client to renew DHCP lease, at least not immediately.
Having said that, if it's so important to you, why won't you implement it (and ideally only show the button when the lease time is set to the minimum -- two minutes) and send a PR to the OpenWrt luci repo?
This was NEVER under question. I even gave out a few examples where I would restart the device.
That would defeat the point.
edit: Looks like I misinterpreted. Is this about wanting to remove an active DHCP lease without waiting for it to expire?
Firstly, I don't like the idea of a delete button next to an add button.
Miss click? Especially if you're doing a large number of operations. You would then have to revert all the changes at once using the luci menu.
Secondly, if you're doing management of a large amount of items. IMO you're better off scripting and using uci or editing command line files?
Finally, I think we already have a reasonable method to manage DHCP static leases under the DHCP and DNS menu? If we do want this functionality, why does it need to be on the main menu?
For example:
cgi-bin/luci/admin/network/dhcp)
Actually, the client remembers the last IP it was leased and usually attempts to re-request it specifically. You can see this using tcpdump or Wireshark.
That may be true in some circunstantes but not on this one. Even if the client is doing a clean request, dnsmasq will still serve the same lease if it is on the table for that MAC.
That's very different from the ability to remove dynamic leases on the other screen. Besides as I described that feature also has issues if the device is already listed on the table and has an IP assigned from a previous dynamic lease (even if the device is not connected).
Arguably that is the point of the lease file.
The client will likely receive the same IP anyway, lease file or not. By default, dnsmasq chooses the IPs it gives out using a hash of the requesting devices' MAC address.
However, if there's a static lease on file (i.e., a dhcp-host option) for the requesting device's MAC address, dnsmasq will always give out that assigned static IP address, even if the device had a different lease in the leases file before.
At best, the "remove" button could resolve one very specific scenario: If a device received a static lease before and should be returned to a dynamically assigned lease. Not sure if that is worth all the fuzz, though.
The only way to guarantee correct ip address lease if you make these kind of big network changes is to restart the client involved or the whole network if you change complete subnets.
Or setup the static address before connecting the client to the network.
Once the client has got hold of a IP address, any address! the client will hang on to it as long as it lives.
Per the second screen capture we also have the list of dynamic leases under the DHCP menu?
Why main menu?
I swear I've had multiple times where dnsmasq refused to give the configured static lease IP to a mac address, until I fully told the client to release the lease, stopped dnsmasq, removed it from the lease file, started dnsmasq, and then told the client to renew.
And even then, sometimes it still refuses to give the configured static IP and will outright reject the IP as not available if I edit the client's dhcp client state to make it request that IP.
Having a "remove" button on the dhcp page would help with troubleshooting those cases.
On default OpenWrt installations, DHCP is handled by two different daemons: dnsmasq for DHCPv4, and odhcpd for DHCPv6. On dnsmasq, you can edit /var/dhcp.leases (leasefile option in config dnsmasq) and send SIGHUP to dnsmasq to reload the lease database.
Last time I looked, this isn't possible with odhcpd because its lease database is in memory only. No, the leasefile option in config odhcpd is not the answer because odhcpd never reads from it. It's only used together with leasetrigger to add DNS entries to dnsmasq.
So to make a "delete lease" function work, you would first need to switch to dnsmasq for both DHCPv4 and DHCPv6, or add some kind of lease database editing function to odhcpd.
That one is in /tmp also like the odhcp lease file.
I can assure you this is not what's currently going on. @DanaGoyette also have seen it refusing to serve the static IP.
I believe you, even though I cannot reproduce your problem and provoke the misbehaviour you describe. Are you positive it is dnsmasq's fault, and not a problem with your setup or your client?
