The problems remain:
Agreed. Let's not add a button that does not achieve anything.
Yet there's at least one other firmware that does it and nobody complains about it.
What does it achieve in "the other firmware"?
Which firmware, and what does it actually do when you remove a lease?
Using tcpdump and dnsmasq's logging, I have definitely seen cases where requests came in for the correct MAC address, and dnsmasq logged the correct MAC address (and a matching DHCP client ID option, MAC address prefixed with 01:), yet it refused to serve the static lease's IP address without showing why.
I've also tried editing the lease to include both the MAC address and id:01: as addresses to match, and nothing changes.
I've even forced the client to request the correct IP address by editing the client's lease state and setting the interface's address, only to have dnsmasq reply with a DHCPNAK (address not available). WTF?
The moment I remove the hostname from the lease reservation, suddenly dnsmasq starts answering with the correct, configured IP address.
The two interfaces of the BMC definitely have different MAC addresses, too. I've seen the same issue happen with other leases that are for Linux machines or the like.
While a remove lease button wouldn't do anything for to fix that problem, it sure would make it easier when trying to debug dnsmasq's lease behavior. Currently, I have to do this, and hope that the brief dns interruption doesn't interrupt web browsing on family members' machines:
/etc/init.d/dnsmasq stop; sed -i /homeassistant/d /tmp/dhcp.leases; /etc/init.d/dnsmasq start
One actual use case for the remove-lease button itself was when I moved homeassistant from a Home Assistant Yellow (Pi CM4) to a VM. When I shut down the Yellow, I had to manually go remove the lease for the Yellow before the name would allocate properly to the VM.
Let's see your /etc/config/dhcp file
As I stated before this is a thing in DD-WRT:
Seems to simply remove lease from the file and reloads.
And then what? The client still has an active lease which means it's still using the IP. When it requests a renewal, I assume that the DHCP server will still issue said IP, right? In the meantime, what happens if another device is issued a lease with the same IP -- now you have a conflict and both devices have issues.
I'm guessing that most people haven't even clicked that button. And, quite honestly, I think that DD-WRT's user base is shrinking, so there may not be as many users to complain.
You are right, but that's besides the point. What happens with the client is a problem of the client.
Having the button there just solves all the problems above where the router keeps serving the same (sometimes incorrect) IP just because at some point that MAC was assigned that IP.
Yes, it isn't perfect. But at least if you a assign a static lease you've a way to remove the old dynamic one from the lease file...
That's fairly logical behaviour. If the MAC address for a static lease is changed, the device with the new MAC address will not be able to receive it straight away. The device with the old MAC address is still occupying it in the lease file, dnsmasq has no way of knowing whether or not it is gone. dnsmasq has to err on the side of "the lease has not expired yet" to not run the risk of conflicting IPs on the network.
Also really annoying behavior as well. Yes, it makes sense and dnsmasq doesn't know if the client is still there or not however the proposed button makes it more flexible and easier to deal with.
No, it's not that simple... there is a non-zero chance that another device will be issued the a new lease with the same address. That is a problem because it causes a conflict.
Further, there will be differing expectations about what the result of that button should be... many people will think (incorrectly) that the client in question will be kicked and blocked from the network. That will not happen. People will be confused.
That is also not guaranteed. dnsmasq uses a hash of the MAC address to calculate the IP it will hand out. It'll just do the same thing again. And the client will request a renewal of the existing lease, and as long as the address hasn't been re-issued, the result should be an ack. So the lease that you deleted will just re-appear.
No, it depends on the configuration. Might be sequential:
--dhcp-sequential-ip Dnsmasq is designed to choose IP addresses for DHCP clients using a hash of the client's MAC address. This normally allows a client's address to remain stable long-term, even if the client sometimes allows its DHCP lease to expire. In this default mode IP addresses are distributed pseudo-randomly over the entire available address range. There are sometimes circumstances (typically server deployment) where it is more convenient to have IP addresses allocated sequentially, starting from the lowest available address, and setting this flag enables this mode. Note that in the sequential mode, clients which allow a lease to expire are much more likely to move IP address; for this reason it should not be generally used.
Or the client might have a static lease set at that point.
In both cases it will assign a new, and correct, IP.
And guess what... that's even worse because that non-zero chance of a collision becomes significantly higher... possibly even 100%. Because the lease was not revoked, it was simply erased from the table. If you rent an apartment and the landlord throws away all their lease paperwork, you still have a copy that says you are legally entitled to live there until the lease expires. If they try to issue a lease to a new tenant, it will cause a collision.
I never said you're wrong, what I'm saying is that the collisions and whatnot are a client problem and I think those types of issues are besides the point. The client/user has to know what he's doing - it's not like DD-WRT is a mass product made for users that don't know what DHCP is.
I get that the button may cause confusion, however, at least, just make it so when a static lease is added the existing dynamic lease for the MAC is removed from the file and dnsmasq reloaded.
This would fix half of the annoyances without being "confusing" and potentially problematic.
In the apartment rental example I gave, is the problem a tenant problem or a landlord issue??
No, they’re not. Because it will have deleterious downstream effects. Why would anyone add a feature that could very reasonably be used incorrectly and with the wrong expectations that would then cause new problems.
While openwrt is obviously used by many advanced users, it’s also not intended to be exclusive to that crowd. Yes, many Openwrt users are new to networking. It doesn’t make sense to create a new (and entirely unnecessary) feature that is almost guaranteed to cause confusion and then blame the user when things go wrong.
On the surface this makes sense. But it can still cause problems because the lease is still valid and there is nothing to force the client to renew now so that it can get the new address.
If a client received a DHCP lease by the router, it has every expectation to use it for the fully validity of its lifetime - and it will do so.
I've used that before. It doesn't do what seem to be the original request (when described in detail - when asked to review the thread for detail). As a networking n00b years ago, it actually caused me great confusion when my devices continued to operate as normal after hitting that button.
You just admitted to what everybody's been explaining.
That's not what the RFCs say about behavior of a DHCP server, but OK.
I now understand, that they just want a button (that does nothing).
Why are you concerned with assigning specific IP addresses to specific devices? If you need to reference a particular host, the correct way is to use DNS.
Let's use your 10.0.0.201 device example. Let's name it "foobar". As long as foobar sends its name to DHCP, dnsmasq will answer DNS queries for "foobar" with whatever IP address was assigned to foobar (which is 10.0.0.201).
Some time later, you set a static lease 10.0.0.10 to foobar. It will not take this IP address until the 10.0.0.201 lease expires. But that's OK, because you used DNS to refer to foobar by name instead of IP address. Dnsmasq will continue to answer 10.0.0.201 for foobar until the lease expires. Afterwards, dnsmasq will return 10.0.0.10 for foobar.
So if you use DNS (which works out-of-the-box on OpenWrt!), then it doesn't matter what IP address gets leased. The specific IP address would just be an implementation detail.
