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.
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:
Dnsmasq-discuss mailing list