staticdhcpd in non-authoritative mode will send NAKs for clients it does not manage (anymore) about staticdhcpd

[GoogleCodeExporter]

Hi, Mark.

I'm afraid you might have overlooked something with this issue: all of the 
cases your patch (thanks for sending one!) addresses are those where the client 
has already received a "lease" from the server: the client's communication is 
unicast from that point forth.

What this means is that the client will only ask the DHCP server it knows about 
for help when it wants to renew or otherwise manage its lease, and if the 
server doesn't know about the client any more, it can't be sure it's providing 
correct information.

The correct behaviour would seem to be NAKing the request to force the client 
to return to the DISCOVER state so it can find a DHCP server that does have the 
capacity to provide current information, since the alternative would cause the 
client to retain stale configuration data that might result in things like IP 
clashes or broken routing.

Original comment by red.hamsterx on 24 Jan 2011 at 2:40

[GoogleCodeExporter]

That indeed is what I also observed. In the end, I commented out those NAKs.

Original comment by [email protected] on 25 Jan 2011 at 11:55

[GoogleCodeExporter]

Can either of you provide me with an example flow of why you would want a 
client to retain its lease after a DHCP server has forgotten about it?

Original comment by red.hamsterx on 25 Jan 2011 at 11:59

• Changed state: Accepted

[GoogleCodeExporter]

In 1.5.4 src/dhcp.py line 455, the case is for renew and rebinding. Why would 
we NACK a lease that we do not know about. Isn't this broadcast?

Original comment by [email protected] on 28 Jan 2011 at 11:24

[GoogleCodeExporter]

Okay, I see the case that was overlooked now.

RENEWs should be NAKed because the lease is no longer valid after you've 
removed the entry (those are unicast), meaning that allowing the server to 
pretend the lease is still good could be detrimental to the network, but 
REBINDs should be ignored, since those are a broadcast plea for any server to 
pick up the lease.

This should be addressed in r306 in the dev-branch. (With luck, I'll find time 
to test all the revisions on Sunday and push out an update, though I doubt I'll 
be able to redo logging and the web UI this weekend -- maybe one or the other)

Original comment by red.hamsterx on 29 Jan 2011 at 8:34

• Changed state: Started

[GoogleCodeExporter]

Much longer soak period than I'd expected (months, not days), but it looks like 
it's working properly.

Original comment by red.hamsterx on 22 Jun 2011 at 11:30

• Changed state: Fixed