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
