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

Simon Kelley simon at thekelleys.org.uk
Wed Feb 1 19:52:39 GMT 2006


Stephen Rose wrote:
> Simon Kelley wrote:
> 
>>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.
> 
> 
> I checked the logs.  That is indeed what's happening during the dialog 
> with Windows XP.  I have a D-link access point that seems to need a 
> couple of DHCPREQUEST-DHCPNAK cycles before it finally decides to 
> DHCPDISCOVER.  That device has an entry in both the ethers file and the 
> hosts file, so it can't get another address.  At the very least, I would 
> expect devices that are pinned like that to not need leases.  Just a 
> thought.
> 
> Steve
> 

Feedback from the DHCP gurus was positive, so I've built a test version
which should behave better under these circumstances (as long as
"dhcp-authoritative" is set in /etc/dnsmasq.conf)

I'll send you a copy by private mail, please could you test it?

Cheers,

Simon.






More information about the Dnsmasq-discuss mailing list