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

[Simon Kelley]

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
>