[Dnsmasq-discuss] leases being removed from lease file on startup
tmetro+dnsmasq at gmail.com
Sat Oct 29 13:22:15 BST 2011
Simon Kelley wrote:
> Tom Metro wrote:
>> The router gets rebooted daily, and I'm trying to get the "static" lease
>> to persist across reboots. Here's what I'm seeing:
>> 4. Router is rebooted.
>> 5. Initially cctv1 still exists in lease file.
>> 6. A ping of cctv1 fails with a bad host name, and has disappeared from
>> the lease file.
>> What caused it to disappear from the lease file?
> The expiration time (first field in the relevant line in the leases
> file) is less (earlier) than the current time.
> What value is there.
Here are the lease file entries seen for cctv1 over the course of my
108 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6
51 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6
4294967295 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6
Is that time value suppose to be the usual seconds from epoch?
The last one corresponds to Feb 7 02:28:15 2106. Seems pretty
"infinite." The first two seem like they would cause the entry to expire
as soon as it is created.
It may be relevant to point out that the router gets its time
initialized to epoch on boot, and set via NTP (what appears to be)
fairly late in the boot-up process. Maybe it is possible the first two
lines show leases acquired before the time was correctly set? Even
still, 108 and 51 seconds are ridiculously short lease periods.
Does Dnsmasq examine the lease expiration times when it first reads in
the lease file and throw out all entries that are expired? (Does it care
if the entry is *way* in the future, as in the case where it thinks the
current time is near epoch, but the expiration is correct time +
whatever was added for the "infinite" lease?)
> You configuration means that dnsmasq will offer an infinite lease to
> the cctv, but it may choose to take out a shorter lease.
Out of curiosity, why? This seems to break the expectations set by
having an "infinite" option. (And the man page doesn't appear to address
this quirk. I assume this behavior is part of the DHCP spec.)
Generally, that shouldn't be a problem. Presumably the client is aware
of the lease expiration and will appropriately request a renewal.
But in my observation, it seemed like the client was unaware of the
expiration and never requested a lease renewal.
> The following hack may solve your problem.
> 2) edit the leases file and make the lease expiry time for cctv1 0
> Note that 0 means "infinite - never expires" in this context.
Would such a change remain perpetually, or are there circumstances where
Dnsmasq would overwrite that entry?
Whether manually edited as a one-off or dynamically edited via a script,
this is going to effectively mean a 2nd place that needs to have
knowledge of which clients have static IPs. It's starting to border on
diminishing returns for using DHCP. Static entries in /etc/hosts would
also solve these problems, at the expense of having to configure each
client with a static IP.
> The relevant situation is when a client renews a lease which dnsmasq
> doesn't know about. without "dhcp-authoritative" it will reject the
> transaction and cause the client to go through a complete DHCP cycle -
> that complies with the standard. With "dhcp-authoritative" is will
> quietly put the lease into the database and continue as if nothing were
Ah, got it. That makes sense. So it's not that Dnsmasq will somehow know
about the client, it's just that it'll accept a renewal from a client it
The stock configuration for Dnsmasq on the router has no persistent
lease file and dhcp-authoritative set. I added a persistent lease file
(residing on a USB Flash drive) and left dhcp-authoritative set. Sounds
like it should have no bearing on the testing I'm doing at the moment.
Thanks for the clarification.
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
More information about the Dnsmasq-discuss