[Dnsmasq-discuss] leases being removed from lease file on startup

[Simon Kelley]

On 29/10/11 13:22, Tom Metro wrote:
> 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
> testing:
>
> 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.

It's worse than that, the expiry times are 108 and 51 seconds after 1st 
of Jan 1970 ie. well in the past. The NTP thing is exactly the problem. 
You have two possible solutions, either arrange that on boot dnsmasq is 
not started until after NTP has done its stuff, or re-compile dnsmasq 
with the HAVE_BROKEN_RTC flag. HAVE_BROKEN_RTC removes the need for sane 
system times and stores relative rather than absolute times in the 
leases file. Because it changes the meaning of the first field, you 
should delete any existing lease file when going from one setting to the 
other.
>
> 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?)
>

Sort of. The time is absolute time of lease expiry, and infinite is 
represented by zero.
>
>> 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.)
>

It is.
> 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.
>
>

A changing system clock confused things.

>> 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
>> wrong.
>
> 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
> doesn't know.
>
> 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.
>
>   -Tom
>

Cheers,

Simon.