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

John Knight John.Knight at belkin.com
Wed Apr 15 23:30:16 BST 2015


After thinking about this a little more, lease renew is generally initiated by the clients, so I don't think this would work.  What if there was an API that would take the old time and the new time and pass it to dnsmasq so that it could come up with a delta time and then adjust all of the leases it has under its control?  I think this would work.  However, I am not sure why it stops responding to DHCCPDISCOVER.  After updating the leases, perhaps dnsmasq needs to be restarted as well to put it into a good state.

John


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







__________________________________________________________________ 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 __________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150415/0fd1ef83/attachment-0001.html>


More information about the Dnsmasq-discuss mailing list