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.
