Re-activate current lease on DHCPDISCOVER

[Glenn Satchell]

>From: Drew Weaver <drew.weaver at thenap.com>
>To: "'dhcp-users at isc.org'" <dhcp-users at isc.org>
>Date: Thu, 9 Oct 2008 12:21:12 -0400
>Subject: RE: Re-activate current lease on DHCPDISCOVER
>
>-----Original Message-----
>From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf Of 
Simon Hobson
>Sent: Thursday, October 09, 2008 12:16 PM
>To: dhcp-users at isc.org
>Subject: RE: Re-activate current lease on DHCPDISCOVER
>
>Drew Weaver wrote:
>
>>PC boots up once.
>>
>>Oct  9 08:06:24 c8 dhcpd: DHCPDISCOVER from 00:16:76:e0:d3:5b via 10.1.0.1.9
>>Oct  9 08:06:25 c8 dhcpd: DHCPOFFER on 10.1.0.1.10 to
>>00:16:76:e0:d3:5b (lan-941a75b0) via 10.1.0.1.9
>>Oct  9 08:06:25 c8 dhcpd: DHCPREQUEST for 10.1.0.1.10 from
>>00:16:76:e0:d3:5b (lan-941a75b0) via 10.1.0.1.9
>>Oct  9 08:06:25 c8 dhcpd: DHCPACK on 10.1.0.1.10 to
>>00:16:76:e0:d3:5b (lan-941a75b0) via 10.1.0.1.9
>>
>>Some presses the 'reset' button on the PC.
>>
>>Oct  9 08:07:37 c8 dhcpd: DHCPDISCOVER from 00:16:76:e0:d3:5b via
>>10.1.0.1.9: network 10.1.0.1.8/29: no free leases
>>
>>My question is, why doesn't it just reassign the same lease that it
>>already has? Obviously it isn't using it if it is requesting a lease.
>
>Short, technically correct but not very helpful answer : because it's
>a different client.
>
>Longer answer : The first client is client-id "lan-941a75b0", the
>second one is probably "" - since (to comply with the RFCs) the
>client-id is used as the primary key in the database, they are
>treated as different clients by the server. The correct fix is to get
>all your OSs to not send a client-id, but good luck persuading
>Microsoft to change as they are (AFAIK) the only OS vendor not to
>default to an empty client-id.
>
>It was on the ISC roadmap to provide an administrator option to
>change the database key - at present it is
>"pick_first_value(client_id,hardware)", and changing it to just
>"hardware" would 'fix' your problem. The feature didn't make it, and
>I think it's one of those things that might make it if enough people
>ask for it - or if someone steps up and sponsors it's development.
>
>
>There was also a patch a while ago to modify the behaviour, but I
>don't think it's been maintained.
>---------------
>Well, the Gentoo-Livecd is client 'livecd' so a lot of them have client_ids.
>
>It does seem strange that you cannot just set the key to be the MAC address 
though.
>
>-Drew

The reason is that it is client-id then mac address, is that is what
the RFC specifies the server should use.

A workaround is to define a class that gets matched by PXE Clients. In
that class define the lease time to be very short, say a few minutes.
Then, at least, those leases will expire by themselves pretty quickly.

class "PXE" {
    match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
    max-lease-time 300;
    default-lease-time 300;
}

And now for the ugly hacks department. I haven't tried this but what if
you assigned a client-id to the PXE clients? For example,

class "PXE" {
    match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
    
    # here is the ugly hack
    option dhcp-client-identifier concat(01, hardware);
}

regards,
-glenn