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? >> 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 (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. 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?) -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/
