in dnsmasq dhcp: leases: button to delete lease

[knebb]

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

[Patrick M. Hausen]

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.

[franco]

> 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

[pseudonym3k]

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?

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.

[pseudonym3k]

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.

Thank you very much Franco.

[RobLatour]

Is this still on the table? 

I ran into a situation yesterady that I needed to reset which device was using a specific ip address and could not;  In short, I'm using the Network Time Service with OPNSense and have attached to my system a stratum 1 time server at IP address 192.168.7.24. Various devices on the network reference this IP address specifically.  The device I am now using is a replacement to the old one and has a different different mac.

With the old way of doing things this was simple, but with dnsmasq not giving up the on the lease on the old device, even after I restart the dnsmasq service, it seems I'm stuck with a misconfigured network until the old lease expires later today.

Some sort of delete button on the old lease would be very helpful.

[Monviech (Cedrik)]

A lease delete button for dnsmasq is currently not on the table, because it lacks a standard interface to delete a lease during runtime.

It has some compilable helpers that fake a dhcp release, but they do not compile cleanly/work on freebsd currently. We tried but investing more time there does not make much sense.

In KEA we are planning to add it, since it does have an interface to delete leases via unix socket.

https://github.com/opnsense/core/pull/10019

[pseudonym3k]

I saw that note on Github, that this wasn't going to be pursued.

I've been using a script to stop DMSmasq, edit files to remove the stuck lease, then restart DNSmasq. I haven't noticed any side effects, error log entries, etc. to indicate any problems, but I don't know how to actually confirm there isn't any problem caused by that. But I'm just a home user with a simple network, if I ever do cause myself some problem I can live with having to recover from it.

I thought I read somewhere that KEA was being deprecated?

[Monviech (Cedrik)]

No KEA is not deprecated, we are currently working on making it more feature complete.

What is deprecated is their REST Api control agent thing but we are working on replacing it.

Starting and stopping dnsmasq was one of the approaches I took when I tried to implement a lease delete button, but it just does not scale well. If I have to maintain this functionality it should be native. As long as it isn't I will not work on workarounds to that core issue. I hope thats understandable.

For KEA this is feasible because it exposes a proper runtime interface, but this is purely a technical difference — both dnsmasq and KEA remain fully supported solutions.

[RobLatour]

@Monviech thank you for the update and the explanation.

[pseudonym3k]

(...) it should be native. As long as it isn't I will not work on workarounds to that core issue. I hope thats understandable.

I used the provided 'delete button' with past Dnsmasq routers I had, it worked well, but that was quite some time ago. Yes I can understand how that might not be compatible with OPNsense now. Thank you for trying to get it working.

I only mentioned my script in case anyone else wants to explore something like that for themselves. I'm not sharing the script itself since I have no way of knowing what harm it could cause.

Thank you for clarifying on KEA. I wish I knew where I read that KEA was deprecated, as I got the impression it was the whole module, not just an API. Good to know it is actively maintained.

[nero355]

I wish I knew where I read that KEA was deprecated, as I got the impression it was the whole module, not just an API.

KEA and the now EOL declared ISC are made by the same people so maybe you mixed up something there ?

The reason that ISC is now a plug-in for OPNsense is that KEA has replaced it so it would be weird to declare KEA deprecated ;)

[pseudonym3k]

I agree, that's why I thought it was really weird when I read that. I wish I could remember where. If I run across it again I'll post it.

ETA: I did some quick searches, and while I didn't find the reference I'm looking for, there are quite a few posts out there of others who thought the same thing. Wondering if something was worded in such a way to suggest it and has since been revised.

[Monviech (Cedrik)]

Most likely this was misinterpreted by some actionable individual and then it was spread via word to mouth.

https://github.com/opnsense/core/issues/9647