Question Re: UID

[Kevin C. Miller]

Assume that client A sends a uid to the server, and the entire 
exchange is completed. The client goes away, lease expires.

Now client B comes along, and gets the same lease as A, but it 
doesn't send a UID. It appears that in this case (from looking at the 
leases file), that the uid isn't cleared from the lease structure, 
when it should be.

My understanding is that we'd like to keep the UID around after the 
lease expires, in order to match clients against this value when 
choosing an IP on a DISCOVER. However, if there are no existing 
leases that match, then the UID from the old lease should be deleted.

My first pass indicates that perhaps adding additional cleanup to 
dhcp.c:384 (near binding_scope_dereference) would be a good idea.

I'm seeing some odd behavior that I believe is related to this. 
Here's a longer example of the above:

client A -> DHCPDISCOVER (uid: "foo")
server 1 -> DHCPOFFER (128.2.76.99)
client A -> DHCPREQUEST (128.2.76.99, uid: "foo")
server 1 -> DHCPACK (128.2.76.99)
  leases file: lease 128.2.76.99 { hardware A; binding state ACTIVE; 
uid "foo" }

[time passes]
  leases file: lease 128.2.76.99 { hardware A; binding state BACKUP; 
uid "foo" }
(using failover)

client B -> DHCPDISCOVER ()
server 1 -> DHCPOFFER (128.2.76.99)
client B -> DHCPREQUEST (128.2.76.99)
server 1 -> DHCPACK (128.2.76.99)
  leases file: lease 128.2.76.99 { hardware B; binding state ACTIVE; 
uid "foo" }

[time passes]
client B -> DHCPREQUEST (128.2.76.99)

At this point, the server uses the uid for purposes of comparison (in 
find_lease), and the uid doesn't match. Result:
server 1 -> DHCPNAK (128.2.76.99)

-Kevin


---------------------------------------------------
Kevin C. Miller <kcm at cmu.edu>
Network Group
Carnegie Mellon University