DHCP Leases: Button to Remove

It ain’t that hard to try actually.

Just pull the power plug on the OpenWrt router and all leases and dnsmasq info is destroyed since it all is in /tmp so now the “delete button” is pushed in openwrt…

And power it back on. The lease list is now empty but the network works as before and no one has even noticed dnsmasq was gone. But host name networking doesn’t work since dnsmasq have no lease information.

And then it is only a 12h waiting game for all clients to come home sooner or later to ask for lease renewal again and the dnsmasq lease list start to fill up again. After the leases are registered again you can start using the hostnames again.

1 Like

"...with any devices connected downstream of a network switch that remains powered on"

(and other sernarios too, e.g. a downstream Dumb AP, etc.)

1 Like

It does, remove the lease from file and reload dnsmasq. Everything else is a client's problem. If you don't know how to use it, oh well.

This solved two different problems: 1) the situation I and others reported about the routers not assigning the correct IP after a static lease is set and 2) the other situation when testing a lot of VMs/containers/configurations would be useful to be able to remove a lease from there.

Yes, I know how DNS works, thanks. Not the same thing, as extra implications and not was is being discussed here.

What does that statement mean?

Everything else is a client's problem.

  • Do you mean according to RFC or personal preference?
  • You are aware DHCP servers must make a check, right?
  • You realize DHCP servers don't issue conflicting IPs, right?

1.) But the client's problem is they have a perfectly valid lease that you erased - which they intend to use - maybe that works in DD-WRT, but it seems you're just ignoring that fact. The non functional buttons and other nonsensical things made me concerned about DD-WRT years ago

2.) There's other options than a button that seems to have different functions based on preference, but OK. Good point (rare use case for most, though - creating 100+ VM/MACs every 12 hours, but whatever).

Ad nauseam, this is by design. As long as the "correct IP" is occupied by a previously issued lease, dnsmasq can not, will not, and should not give it out to a different host. It must honor the leases it gave out.

If your specific situation requires that dnsmasq should behave in an unintentional way, especially foregoing safety measures, you are of course free to manually manipulate the leases file as you see fit. However, such manipulation should not be normalized or even encouraged with the introduction of an ill-defined, misleading, and potentially counterproductive UI element.

1 Like

Windows 10/11 also have a lot of on/off switches for users to play with to feel included. But absolutely nothing meaningful happens when switching most of them (changing color doesn’t cunt). For example turning auto updates off, it still updates Windows no matter if you want to or not.

I am probably to old nowadays to get exited about flashy colorful gui (that many nowadays call big groundbreaking upgrade) and a lot of buttons that doesn’t do anything really serious and meaningful.

Why have the lease pool and static assigned leases overlapping to begin with, if you are afraid of dual leases or occupied hidden leases?

2 Likes

It is very easy to understand, let's say you have a sat receiver and originally you have set it to fixed 192.168.1.15 and you go to DHCP and DNS and say well now I want to have the fixed IP 192.168.1.5, you set it, apply it and save it in LuCI. You go to the receiver, restart it and you still have the IP .15
Damn until you manually delete /tmp/dhcp.leases there is no way, that is, you delete it, restart the receiver and omg you already have the IP .5
That's why a few posts ago I said that I totally agreed with this measure.
This applies to any client on the network.
I don't think it's necessary to post photos, right?

I think I understood everything except...

What is "the receiver"?

It seems that you're describing that one needs to restart the client as well. I believe others discussed that too, but it's the first time someone advocating for the feature mentioned it's necessity. When I attempted to discuss this, there was confusion between the "admin" and the "user" of the machine (network segment, etc.) that would need to be physically disconnected (cleared, etc.) to get another lease.

Your statement provides clarification, thanks.

1 Like

By receiver I mean any client on the network configured as a DHCP client
I have put receiver to give an example or like the VU+ that I have at home SET TOP BOX it is still better understood. But this can be a PC, a mobile phone, tablet, CAM camera, etc...
TNX
I am glad that the reason for this request has become clearer.

1 Like

But this does not happen -- unless, again, the new IP (192.168.1.5 in your example) was previously assigned to a different host and that lease has not yet expired.

Observe, if you will, /tmp/dhcp.leases after you change a host's static IP lease assignment. When the host requests a new lease (after having its connection reset), the entry with its old IP gets removed and the entry with the new IP gets added. And yes, I can provide "photos" if necessary.

1 Like

Agree with OP, this feature is very useful when needed. For example, I get new phone and returning the old phone for trade-in, but I want to use same static IP address for new phone. However the lease for the old phone is still active e.g. 7 days to expire. If I can just release it by clicking the button, I can assign the old IP to new phone without waiting for lease to be expired. The old phone will never connect back to the network as it is gone for ever.

In your situation, you can simply delete the DHCP reservation, and then delete it from the DHCP lease table with an ssh session. Or just restart the router. After all, you're talking about 1 device (ok, maybe a few if you have family) every few years... or even if you replace your phone every 6 months.... pretty infrequent. As yourself, does this pass the toothbrush test?

1 Like

Then you have set up your static lease incorrectly: it should be infinite. If you give it a time limit it will keep that clock in the background; which may explain why some people have trouble deleting their leases.

Symmetry in the GUI... if there is a place to add a static lease it would be convenient if the staticness could be reverted at the same location... IMHO that is really orthogonal to documenting what adding/removing the staticness of a lease actually does...
ATM the overview page in the GUI seems to offer an active "Set Static" button even for leases that are already reported as "Static Lease".
Now, the GUI inconsistency can be addressed inmultiple ways, e.g. not showing the button for already static leases, or change its color to signal inactivity. Or add a direct link to allow editing the properties of a static lease. All of this might be complicated to implement and/or not worth the effort, but please let's not believe that the status quo is ideal/perfect...

Not for me it doesn't:


the third lease is a static lease, and its button is greyed out and disabled.

2 Likes

Thanks, I only checked on my phone this morning, so this might be a local rendering issue on my side... that solves the GUI issue (not the symmetry issue but that is more of a bike shedding question anyway).

The equal-and-opposite operation to "Set Static" would not be to remove the lease from the lease file (as the OP requests), or remove the lease from the client (impossibru), but to remove the static lease from the DHCP server configuration. Creating such a button is not a technical problem, communicating what the button actually does is a UX problem: The equal-and-opposite label to "Set Static" is, unfortunately, not simply "Remove".

1 Like

I agree the opposite is and should be to "make dynamic" as this really is only about making a lease static or not. My argument is not to name that button "Remove" but to not make "Set Static" a one-way function, at the very least there should be a link to the static DHCP configuration page.

To be clear, I am aware that we are not revoking a lease here or that we can directly affect clients, but all we discuss is "should we be able to toggle the staticness". And I believe that yes we should, but weakly so: I can live with the status quo (as I said not perfect, but "good enough").

2 Likes

this is just a simple example. When flashing firmware on phone or rooting the phone, or test multiple custom roms on phone, it needs frequently set/reset the lease, especially every OS defaults to random MAC address.