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

[Simon Kelley]

On 30/10/11 18:06, Tom Metro wrote:
> Simon Kelley wrote:
>> Tom Metro wrote:
>>> Simon Kelley wrote:
>>>> ...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.
>>>
>>> OK, but even if Dnsmasq thinks the current time is 0 (1st Jan 1970), why
>>> would the "infinite" lease be set to a duration that is only a few
>>> minutes in the future? I don't get that.
>>
>> Good point, I'm not sure I can explain it without intensive
>> investigation. It works Ok when the system clock is stable.
>
> In the router logs I see:
>
> Dec 31 20:01:11 wifi-gw daemon.info dnsmasq-dhcp[583]: read
> /etc/dnsmasq/dhcp/dhcp-hosts
> Dec 31 20:01:11 wifi-gw user.info rcheck[610]: Time not yet set. Only
> "all day, everyday" restrictions will be activated.
> Oct 30 13:40:23 wifi-gw daemon.info dnsmasq-dhcp[583]: DHCPDISCOVER(br0)
> 00:13:02:c9:3b:dc
> Oct 30 13:40:23 wifi-gw daemon.info dnsmasq-dhcp[583]: DHCPOFFER(br0)
> 192.168.1.200 00:13:02:c9:3b:dc
> Oct 30 13:40:23 wifi-gw daemon.info dnsmasq-dhcp[583]: DHCPREQUEST(br0)
> 192.168.1.200 00:13:02:c9:3b:dc
> Oct 30 13:40:23 wifi-gw daemon.info dnsmasq-dhcp[583]: DHCPACK(br0)
> 192.168.1.200 00:13:02:c9:3b:dc monk
>
> The DHCPDISCOVER from this client is arriving right about the same time
> the router is getting its time set. This client's lease duration ended
> up being 192 seconds.
>
> Just seconds later (at 13:40:55) another client requests a
> (non-infinite) lease, and gets a value of 604800, corresponding to Jan
> 7 1970, which matches the default lease time of 7 days.
>
> So the unexplained behavior seems to be with infinite leases. Maybe the
> calculation results in a overflow and it wraps around?
>
> It also can be observed from this that Dnsmasq is apparently capturing
> the present time value at some point in its startup, rather than
> grabbing a fresh value as lease expiration times are calculated. That
> sounds like possibly a bug.
>
>
> HAVE_BROKEN_RTC flag sounds like a good solution here.
>
> I see in the log:
> Oct 30 14:50:14 wifi-gw daemon.info dnsmasq[2206]: compile time options:
> IPv6 GNU-getopt no-RTC no-DBus no-I18N DHCP TFTP no-IDN
>
> Is "no-RTC" different from HAVE_BROKEN_RTC?
>

no-RTC imples HAVE_BROKEN_RTC. That puts a completely different light on 
things!

The first field of each line in the leases file is a lease _duration_ 
absolute (ie seconds since epoch) times won't appear there are all. That 
explains your second client fine, but not the first one.

Could you switch on --log-dhcp and repeat the test? The time-warping 
shouldn't be having any bad effects as the whole system is driven by 
uptime, not clock time when HAVE_BROKEN_RTC is set.
>
>>> What I'm wondering is will Dnsmasq do anything undesirable if it is
>>> started before the time is set correctly, but no leases are requested
>>> until after the time is set.
>>
>> Probably not.
>
> I repeated the test case by requesting a lease from my test client while
> the time was set correctly. I observed in the lease file:
>
> 4294964494 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6
    ^^^^^^^^^

Seems like a very long lease time, or a short negative one.

>
> (Expires Feb  7 01:41:34 2106.)
>
> I rebooted the router. Examined the lease file, and this entry had
> disappeared. Actually, the only leases I do see listed are for clients
> that requested a lease post-reboot.
>
> I tried again, requesting a lease for the client, then I introduced a
> syntax error into the Dnsmasq config file to cause it to fail to start
> on reboot, then rebooted the router.
>
> These two lines correspond to what was in the lease file before and
> after the reboot:
>
> 4294964076 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6
> 4294963974 00:14:d1:f1:c7:e6 192.168.1.225 cctv1 01:00:14:d1:f1:c7:e6
>
> I don't get why the expiration time would have changed.

Neither do I. It shouldn't have got anywhere near the leasefile with a 
broken config.
>
> I removed the syntax error and restarted Dnsmasq. As before, the lease
> file no longer shows cctv1. It lists two clients that sent DHCPDISCOVERs
> as soon as Dnsmasq came online, plus one other client that is currently
> offline. All three having non-infinite leases, and showing times that
> are about 7 days from epoch, and the offline client's entry is slightly
> smaller, post-reboot.
>
>
> (Does using HAVE_BROKEN_RTC cause Dnsmasq to write to the lease file
> frequently to decrement the time to expiration? Normally the lease file
> is only written to when a lease is requested/expired, right?)

HAVE_BROKEN_RTC stores the lease length in the leases file. One reason 
for doing this to reduce the number of writes to the lease file, to 
avoid wearing flash filesystems.

without HAVE_BROKEN_RTC -> file written each time a lease is renewed.
with HAVE_BROKEN_RTC -> file written only when a new lease is created or 
an old one expires without renewal.

Cheers,

Simon.