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.