On 29/10/11 17:43, 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.
You have two possible solutions, either...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.
OK, good to know. Not something I can easily deploy, as Dnsmasq is
bundled as part of the router firmware, but I can submit a bug report to
have this addressed in a future release. (Or more painfully install a
custom Dnsmasq via optware.)
What is the downside to enabling this option?
The only downside is that time effectively stops whilst dnsmasq and/or
the router is down. Without this option if the router is switched off
for two hours, then a lease with two hours or less to run will expire
when it comes back. With the option the two hours is lost and the lease
will have two hours still to run. Might be a problem on a network with
high client churn and a shortage of addresses.
...arrange that on boot dnsmasq is not started until after NTP has
done its stuff...
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'll repeat my test case while watching the time setting, and make sure
the client gets its lease only after the time has been set correctly.
Delaying the start of Dnsmasq until NTP runs introduces other problems.
NTP depends on the Internet connection working, so if the WAN link is
down, that'll mean that internal DNS is also down. As a result, LAN
devices are harder to reach to troubleshoot, and my security cameras
won't be able to find the internal SMTP server that spools notification
emails while the WAN is down. (There are work arounds, of course, like
using IPs for this scenario, or running an internal NTP server.)
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?
You didn't comment on this, other than ti say it is supported by the
DHCP spec. What's the advantage to returning a short lease? Why doesn't
Dnsmasq itself simply write a zero to the lease file?
The client, when requesting a lease can ask for a particular time. The
DHCP server chooses the time to grant. dnsmasq simply returns the
smaller of the client-requested time or the lease time in the dnsmasq
configuration. I guess that makes sense: if a client knows it only needs
an hour, there's no point in giving it a day.
Simon.
Thanks,
-Tom
