[Dnsmasq-discuss] Openwrt and reboots again...

Simon Kelley simon at thekelleys.org.uk
Wed Feb 1 10:34:39 GMT 2006


Stephen Rose wrote:
> I've read the previous exchange about Dnsmasq and reboots with Openwrt. 
>   I've also read the bug activity at Openwrt.org.  I'm running Openntp 
> so time format is not an issue.  Also, I would like to continue using 
> the /tmp partition so the flash is not written.  This only causes me one 
> problem.  When I reboot the router (running Dnsmasq), the leases file is 
> cleared.  When each machine's lease runs out (Windows XP in this case) 
> and it tries to renew its lease, it gets an error because there's no 
> previous lease.  But it actually gets the same ip address and a new 
> entry in the lease file when this happens.  Is there any way that 
> Dnsmasq could only give an error to the client if the requested address 
> isn't available?  It's not a problem for me that the lease file would 
> need time after a reboot to be reconstructed while the leases expired. 
> The real problem is the error drops all my Putty windows.  :-)
> 

I'm guessing that what happens is that the client sends a DHCPREQUEST to 
renew its lease and dnsmasq returns DHCPNAK: lease not found. The client 
then does DHCPDISCOVER-DHCPOFFER-DHCPREQUEST-DHCPACK and gets a new 
lease, but for the same address. (Checking the logs on the openWRT box 
will tell you if this is the case.

My first reaction to this is that returning a DHCPNAK to an attempt to 
renew an unknown lease is the correct thing to do, and can't be changed, 
but when I actually looked at the RFC it wasn't clear that that's true. 
In fact, RFC2131 says almost nothing about sending a DHCPNAK to a client 
in RENEWING state. (It has plenty to say about SELECTING and 
INIT_REBOOT, but that's not relevant here.)

As far as I can see, there are no bad consequences to just accepting a 
renewal of a previously-unknown lease, except in the case that the 
renewal is broadcast (ie rebinding) and picked up by both the correct 
server and another which happens to be on the same network. To avoid 
that, I would probably only change the behaviour when the 
dhcp-authoritative configuration is set, since that already has the 
meaning of "optimise for the case that I'm the only DHCP server on this 
network."

I'll post a query about this to IETF mailing list.

Cheers,

Simon.






More information about the Dnsmasq-discuss mailing list