Two different IP addresses leased out to the same device

[David Coulthart]

On Sep 9, 2009, at 11:45 AM, Simon Hobson wrote:
> Frank has hinted at this, I'll expand and explain.
>
> As far as the server is concerned, they are different clients as  
> required by the RFC.
>
> One lease has a UID (aka Client-ID) which therefore forms the  
> primary key in the database - the other has no UID and so the server  
> falls back to using the MAC address.
>
> This is a longstanding issue when a machine boots with multiple DHCP  
> clients - and it's mostly down to Microsoft that the problem exists.  
> The RFC doesn't specify what should be in the Client-ID, and  
> Microsoft decided that putting the MAC address in there made sense.  
> This isn't wrong, just different to everyone else who default to not  
> supplying a Client-ID at all.
>
> It first started popping up when people were multi-booting into  
> Windows and other OS's like Linux. Then PXE came along and added to  
> it. There have been patches to fudge the request packets (either  
> remove the Client-ID or add it).
>
> A proposed feature that I believe never made it was to allow the  
> administrator to configure the database key - it currently defaults  
> to "pick-first(client-id, hardware)". If changed to just plain  
> "hardware" then Client-ID would be ignored.

What is the expected behavior on lease renewal if a client is  
initially issued a lease keyed on UID/Client-ID, but then the client's  
hardware address is added to a class that is denied access to the pool  
from which the original lease was issued?  I would hope the "deny  
members of" configuration would take precedence even though it's based  
on hardware address instead of UID, but I believe I'm seeing behavior  
that suggests otherwise.  Note this is on an older 3.0.x release, so  
if this is a bug known to be fixed in a later version that would  
definitely prompt me to upgrade sooner.

Thanks,
Dave Coulthart