I'm not sure why the existing behaviour is a problem, and I'm concerned
by the comment in the github bug:
Apparently, iOS rejects infinite leases on mobile Wi-Fi connections.
which, if true, would make the new behaviour a problem. Unfortunately,
Google AI seems to have decided that infinite leases are a problem,
based solely on that comment :)
I have no Apple devices, so can't test this.
Happy to take the patch if it can be explained to me how this solves a
real problem, and we are sure it doesn't add an new problem.
It's also worth noting that if it's 50/50 which behaviour is "correct",
there's a built-in bias towards the _existing_ behaviour. Gratuitously
changing such subtle details risks breaking existing installations which
rely on the old behaviour and their owners almost certainly don't realise.
Simon.
On 09.08.2026 09:32, Dominik Derigs wrote:
Hi Simon,
a `dhcp-host` reservation with `infinite` silently ends up with a finite
lease
as soon as the client sends option 51. calc_time() treats the configured
lease
time as an upper bound, and `infinite` is an unbounded one, so whatever the
client asks for is shorter and wins. Apple devices request 7776000
seconds in
every DHCPREQUEST, so every iPhone/iPad/Watch with a reservation is
affected.
The attached patch honors `infinite` literally when it comes from `dhcp-
host`:
for a reserved address there is nothing to be gained from expiring it
early.
`dhcp-range` is left alone - there, granting a client's shorter request
does
return pool addresses sooner.
Reproducer, with a client sending option 51 = 7776000 for its reserved
address:
dnsmasq -d --port=0 --dhcp-authoritative \
--dhcp-range=10.99.0.100,10.99.0.200,255.255.255.0,1h \
--dhcp-host=02:aa:bb:cc:dd:ee,10.99.0.9,testhost,infinite
The DHCPACK lease time is 7776000 before and 4294967295 with the patch. A
finite `dhcp-host` lease time and pool addresses behave exactly as
before, in
both directions.
Downstream report: https://github.com/pi-hole/FTL/issues/3014
Best regards,
Dominik
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
