[Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

Thu Oct 13 21:15:15 BST 2016

Hi,
Why not just use existing HAVE_BROKEN_RTC?CLOCK_BOOTIME is linux-specific, non-portable, absent in older (but still running) kernels and logically is the same as CLOCK_MONOTONIC except counting suspended/sleep time. In turn using CLOCK_MONOTONIC is already there in times() form when HAVE_BROKEN_RTC is enabled.

Best Regards, Vladislav Grishenko

		_____________________________
From: John Knight <john.knight at belkin.com>
Sent: четверг, октября 13, 2016 11:00 ПП
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
To: Albert ARIBAUD <albert.aribaud at free.fr>
Cc:  <dnsmasq-discuss at lists.thekelleys.org.uk>

Hi Albert,

That sounds like a very good idea to use CLOCK_BOOTTIME. Good suggestion.

When I did a search for difftime in the source code... there are quite a few calls... each one is a potential issue with respect to time going backwards.  I only see one instance that actually considers the case if time goes backwards and that is in dnsmasq.c where it does difftime(now, daemon->last_resolv) and compares the result to both > 1.0 and < -1.0.   So in general, I am somewhat concerned about possible affects of changing time on dnsmasq.  We have seen some issues in the past which we suspected were probably caused by changing the time, so your suggested change could potentially fix some other issues.

Thanks!

John

-----Original Message-----
From: Albert ARIBAUD [mailto:albert.aribaud at free.fr]
Sent: Thursday, October 13, 2016 2:16 AM
To: John Knight
Cc: dnsmasq-discuss at lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour

Hi,

Just a generic comment: from what I can see, all absolute times in dnsmasq are returned bu dnsmasq_time() which calls either times() or time(). This, IIUC, corresponds to CLOCK_REALTIME in clock_gettime(), which is indeed affected when (re)setting the time.

Maybe a fix to time jump issues would be (in Linux at least) to replace
time() with clock_gettime(CLOCK_BOOTTIME,...) which seems to have been designed to get around discontinuities caused by settimeofday().

Note: maybe dates used for logging purposes should still use time() or
clock_gettime(CLOCK_REALTIME) in order to remain comparable to other logs in the same system -- or maybe not.

Sources: man times, man time, man clock_gettime.

HTH,

Amicalement,
Albert.

Le Wed, 12 Oct 2016 23:50:11 +0000
John Knight <John.Knight at belkin.com> a écrit:

> Hi,
>
> I think I may know what the issue is... it appears that the time may
> be changed by ntp in my failure scenario as suggested by the URLs
> referencing ntp in the dnsmasq.log file.  There are numerous
> references to difftime in dnsmasq code.  One of which acknowledges
> potential problem if the clock goes backwards... and is handled by
> comparing last_resolv >1.0 and < -1.0 to accommodate such a
> possibility.  However, in function poll_resolv(), the difftime() call
> checks for > 0.0, assuming the modification time of the file is
> greater than the last_change time.  If the time had changed on the
> router, then its possible that the modification time of the
> /etc/resolv.conf could be less than that of the last_change.  I think
> this needs to be a check for != 0.  If the time is changed negatively,
> then the existing code will not work properly me thinks.
> Its imperative that latest gets set in order for the reload_servers()
> code to run... and if the time is not right, then the
> reload_servers() won't get called.  This specific code (poll_resolv)
> hasn't changed, and if I am right, it is also broken in 2.76.
>
> What do you think?  I am going to make the change locally and re-test
> and see if I can make it fail again.  Unfortunately, it doesn't always
> fail, but I have reproduced it twice now, hopefully it will happen
> again if my fix is not right.
>
> Best Regards,
>
> John Knight
>
> __________________________________________________________________
> Confidential This e-mail and any files transmitted with it are the
> property of Belkin International, Inc. and/or its affiliates, are
> confidential, and are intended solely for the use of the individual or
> entity to whom this e-mail is addressed. If you are not one of the
> named recipients or otherwise have reason to believe that you have
> received this e-mail in error, please notify the sender and delete
> this message immediately from your computer. Any other use, retention,
> dissemination, forwarding, printing or copying of this e-mail is
> strictly prohibited. Pour la version fran?aise:
> http://www.belkin.com/email-notice/French.html F?r die deutsche
> ?bersetzung: http://www.belkin.com/email-notice/German.html
> __________________________________________________________________

Amicalement,
--
Albert.

__________________________________________________________________ Confidential This e-mail and any files transmitted with it are the property of Belkin International, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Pour la version française: http://www.belkin.com/email-notice/French.html Für die deutsche Übersetzung: http://www.belkin.com/email-notice/German.html __________________________________________________________________
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss at lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20161013/22a15b02/attachment-0001.html>