Re-activate current lease on DHCPDISCOVER

[Glenn Satchell]

>
> -----Original Message-----
> Date: Thursday, October 09, 2008 6:11:11 pm
> To: "dhcp-users at isc.org" <dhcp-users at isc.org>
> From: "Glenn Satchell" <Glenn.Satchell at uniq.com.au>
> Subject: RE: Re-activate current lease on DHCPDISCOVER
>
>
>>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,
> -
>
> Hi and thanks for responding.
>
> The custom UID hack doesnt seem too bad. Is there any reason not to assign
> the MAC as the UID for all leases?
>
> Thanks.
> -Drew

That's the default for the Microsoft clients, but there's nothing
to stop a given client setting it to any random string.

regards,
-glenn