Re-activate current lease on DHCPDISCOVER

[Simon Hobson]

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.