[Dnsmasq-discuss] Failure to respond to DHCPDISCOVER messages after changed time on router

Simon Kelley simon at thekelleys.org.uk
Thu Apr 16 15:38:15 BST 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/04/15 22:19, John Knight wrote:
> Hi,
> 
> 
> We discovered that a change in the router's time via NTP will
> cause dnsmasq to stop answering DHCPDISCOVER.  In the wan.cap, NTP
> server gives an earlier time to the DUT and cause the dhcp server
> to stop working (ie. Answering DHCPDISCOVER)
> 
> Our DUT's time is Aug 5, 2015 16:19:22.575786000, but NTP server 
> provides Aug 5, 2015 16:00:19.588536000 which is about 19 mins
> before the DUT's time. Thus the dhcp server stop to work until
> 19mins later. During this 19 minute time period, dnsmasq does NOT
> answer dhcpdiscover or give out IP leases. After 19 minutes has
> expired, we see dnsmasq come back to life and begin answering
> dhcpdiscover messages again.
> 
> I realize that this is an abnormal scenario, but we need to
> safeguard against this kind of failure.  It is showing up in our
> testing.  One thought on preventing this would be to in effect do a
> lease renew after the time has changed on the router.  I am not
> sure how to cause dnsmasq to refresh all of it's leases?  Or should
> we be more forceful and force expiration of the leases and restart
> dnsmasq?  Any suggestions on how to best handle this scenario?
> 
> One concern we have too is security.  If the NTP messages are 
> hijacked and the time is changed, it could cause dnsmasq to stop 
> functioning thus affecting the router's users.  So, I think its 
> necessary that we address this.  Hopefully someone has some 
> recommendations on how to deal with this.
> 
> Regards,  John
> 
> 

There's two aspects to this. The first is unstable clock time. This
has come up before, and there's a solution already in the code: if you
compile dnsmasq with HAVE_BROKEN_RTC then is runs in a mode which
works fine, independent of what the system time is. (It uses system
uptime for the time, rather than clock time, and stores lease
time-remaining in the leases file, rather than clock-time when lease
expiries.) This addresses the usual problem, which is that NTP warps
the time far into the future and all the DHCP leases instantly expire.


Second is the problem you are seeing when putting the clock
_backwards_. I'm slightly worried by this. Could you do some more
checks, and maybe run dnsmasq under a debugger, to see what's
happening? Does dnsmasq respond to DNS requests during the 19 minutes?
I wonder if it's spinning in a loop somewhere, and deaf to all input.
Also, what version of the code are you using? Does it have the new
inotify facility?


Cheers,


Simon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlUvyVcACgkQKPyGmiibgrdeogCgpOLLJfHn0WoLIQNIkfA9H7D1
gFYAnip4Q9AqvFAndWWsi00IEzBDv76Z
=KVSw
-----END PGP SIGNATURE-----



More information about the Dnsmasq-discuss mailing list