Static DHCP host reservation with infinite lease time is overridden by client-requested lease time (option 51)

[gbomacfly]

Versions

• Core version: v6.4.3
• Web version: v6.6
• FTL version: v6.7
• Platform: LXC (Debian), Pi-hole DHCP server

Expected behaviour

For a static DHCP host reservation configured with infinite lease time, the server should grant an infinite lease regardless of what lease time the client requests via DHCP option 51.

Actual behaviour

When a client explicitly requests a specific lease time via DHCP option 51 (Requested Lease Time), FTL grants exactly the client-requested lease time instead of the infinite value configured in the static host reservation.

Steps to reproduce

1. Configure a static DHCP host reservation with infinite lease time:

   dhcp-host=EC:FF:3A:39:26:FA,192.168.178.9,Apple-Watch-von-Sascha,infinite
   

   (as generated in /etc/pihole/dnsmasq.conf from the corresponding entry in pihole.toml)
2. Have a client (in this case an Apple Watch, watchOS) send a DHCPREQUEST that includes option 51 with a specific lease time (Apple devices commonly request 7776000 seconds / 90 days).
3. Observe the DHCPACK from the Pi-hole server.

Evidence (tcpdump)

Client request:

20:27:44.357260 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from ec:ff:3a:39:26:fa, length 300, xid 0xb3b9053
  Client-Ethernet-Address ec:ff:3a:39:26:fa
  DHCP-Message (53): Request
  Client-ID (61): ether ec:ff:3a:39:26:fa
  Requested-IP (50): 192.168.178.9
  Lease-Time (51): 7776000
  Hostname (12): "AppleWaonSascha"

Server reply:

20:27:44.363777 IP 192.168.178.144.67 > 192.168.178.9.68: BOOTP/DHCP, Reply, length 328, xid 0xb3b9053
  Your-IP 192.168.178.9
  Server-IP 192.168.178.144
  DHCP-Message (53): ACK
  Lease-Time (51): 7776000
  RN (58): 3888000
  RB (59): 6804000

The server echoes back the client-requested 7776000 instead of honoring the infinite value from the static host reservation. This is confirmed both in the DHCPACK on the wire and in the resulting /etc/pihole/dhcp.leases entry, which shows a concrete future expiry timestamp instead of 0 (dnsmasq's internal representation of an infinite lease):

1793989192 ec:ff:3a:39:26:fa 192.168.178.9 apple-watch-von-sascha *

For comparison, a static host reservation for a client that does not request a specific lease time correctly shows 0 (infinite) in the leases file:

0 7c:e7:12:6d:d0:d3 192.168.178.17 steamdeck 01:7c:e7:12:6d:d0:d3

Both hosts use the identical dhcp-host=...,infinite syntax in pihole.toml/dnsmasq.conf; the only difference is whether the client sends option 51 in its request.

Additional notes

This was tested with three Apple devices (iPhone, iPad, Apple Watch), all showing the same behaviour, all configured identically to other static reservations (e.g. Steam Deck, various IoT devices) that behave correctly and show Never/infinite expiry. This suggests the issue is specific to how FTL/dnsmasq handles a client-requested lease time (option 51) in combination with an infinite static host reservation, rather than an issue with the reservation config itself.

Config excerpt from pihole.toml:

"EC:FF:3A:39:26:FA,192.168.178.9,Apple-Watch-von-Sascha,infinite",

Generated dnsmasq.conf line:

dhcp-host=EC:FF:3A:39:26:FA,192.168.178.9,Apple-Watch-von-Sascha,infinite

Debug token

https://tricorder.pi-hole.net/yE2Px5wR

[rdwebdesign]

since it would expose unrelated internal network details (hostnames, other reservations, internal domains, etc.)

Note:

Nothing will be exposed.

When you upload a debug log, the log is not publicly available.
Only Pi-hole team will be able to access it and the log will be automatically deleted after 48h.

[gbomacfly]

Ah, thanks a lot, I will edit my issue.

[rdwebdesign]

The debug log doesn't show any issues.

---

I'm not 100% sure, but I think this is a combination of how iOS handles lease times and how dnsmasq handles the request for different values.

Apparently, iOS rejects infinite leases on mobile Wi-Fi connections.

Also, dnsmasq uses the configured lease time in dhcp-host option by default, but if the client requests a different value, this is how dnsmasq behaves:

• if the client requests a longer lease time, dnsmasq ignores it.
• if the client requests a shorter lease time, dnsmasq will use it to avoid holding onto IP addresses unnecessarily, overriding the "infinite" instruction.

I suggest you to try a long lease time (like 60d), but avoid infinite for Apple devices.

@DL6ER,
Can you please check if my interpretation here is correct?

[DL6ER]

@rdwebdesign Your interpretation is correct. The mechanism is calc_time() in src/dnsmasq/rfc2131.c:

unsigned int time = have_config(config, CONFIG_TIME) ? config->lease_time : context->lease_time;

if (opt)
  {
    unsigned int req_time = option_uint(opt, 0, 4);
    if (req_time < 120 )
      req_time = 120; /* sanity */
    if (time == 0xffffffff || (req_time != 0xffffffff && req_time < time))
      time = req_time;
  }

The configured lease time is an upper bound: a client asking for more gets the configured value, a client asking for less gets what it asked for (down to 120 seconds). infinite is 0xffffffff, i.e., an unbounded ceiling, so whatever a client puts into option 51 is always shorter and always wins. That is why the Apple devices end up with 90 days and a real expiry in dhcp.leases, while the Steam Deck (no option 51) keeps 0.

I sent a patch upstream that honors infinite literally when it comes from a dhcp-host reservation:

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2026q3/018526.html

Tested against dnsmasq master, only the reservation case changes:

                                        before    after
host infinite, client asks 90 days      7776000   infinite
host infinite, no option 51             infinite  infinite
host 2h, client asks 300s               300       300
host 2h, client asks 90 days            7200      7200
pool 1h, client asks 90 days            3600      3600
pool 1h, client asks 300s               300       300

Expiring a reserved address early gains nothing, it cannot be handed to anybody else, whereas for a dhcp-range the shortening does return pool addresses sooner - so ranges stay as they are. As src/dnsmasq/ is a verbatim copy of upstream, we pull this in once it is in dnsmasq master.

@gbomacfly Until then, use a long finite lease such as 60d. Note that the reservation itself was never affected: your Apple Watch always got 192.168.178.9, only the expiry differed.

[gbomacfly]

Thanks a lot for the fast response!