Unexpected behavior when moving from 'unknown' to 'known'

[David Sotnick]

I recently upgraded from dhcp-server 3.0.1r5 to 3.0.5r2, and then to
3.0.6. My operating system is FreeBSD 6.2-CURRENT.

I have cases where users machines will be unknown, that is there is no
host entry for the host (when it is new out of the box), and then once the
machine is built-out ("bootstrapped"), a host entry is added to the dhcp
config file.

We have a small range of IP addresses we hand out to these uknown-clients,
and a separate range for the client when it is known to us. Both ranges
are in the same subnet.

Under version 3.0.1r5 this was all working fine, but now I'm seeing some
reproducable and undesired effects.

Here's the class and subnet definition:

class "dynamic-hosts" {
    match hardware;
}

# begin:mac-metro-buildout
subnet 138.72.199.0 netmask 255.255.255.128 {
  option routers 138.72.199.126;
  option broadcast-address 138.72.199.127;
  option subnet-mask 255.255.255.128;

  # Dynamic DHCP pool for new hosts not yet in DHCP
  pool {
    allow unknown-clients;
    ddns-updates off;
    range 138.72.199.1 138.72.199.63;
    default-lease-time 3600;
    max-lease-time 3600;
  }

  # Dynamic DHCP pool with ddns-enabled for dynamic hosts:
  pool {
    deny unknown-clients;
    allow members of "dynamic-hosts";
    ddns-updates on;
    range 138.72.199.64 138.72.199.124;
    default-lease-time 3600;
    max-lease-time 3600;
  }
}
# end:mac-metro-buildout

And here's a sample host entry for one of these hosts, after it's been
built-out and is now 'known' to us, and in DHCP:

host macbrenda-en0 {
  option host-name "macbrenda";
  ddns-hostname "macbrenda";
  hardware ethernet 00:17:f2:09:da:8e;
}
subclass "dynamic-hosts" 1:00:17:f2:09:da:8e;

In case you were going to ask, I'm matching against 'hardware' and not
'dhcp-client-identifier', in my class statement because I want to match
against something the user cannot change.

Now, when the host first connects, it's unknown (the above host entry
doesn't yet exist in the config), and so it gets assigned an IP from the
pool for unknown-clients. The client gets a lease from the range in the
first pool, and the lease gets written to the dhcpd.leases file.

Now for the interesting part... The client then gets added to the dhcp
config file, and is now considered 'known', and is part of the subclass
'dynamic-hosts'. BUT, (I assume) since there is a lease for the client in
the dhcpd.leases file, the dhcp-server is responding to DHCP requests from
the client with "no free leases"

Aug  6 17:17:23 arbiter dhcpd: DHCPDISCOVER from 00:17:f2:09:da:8e via 138.72.129.254: network 138.72.129/24: no free leases

So I stop the dhcp-server, remove the two lease/binding entries for the
host, and start the server again, and now, when the client connects, it
obtains the lease, as it should, from the pool of known-clients.

Since I wrote this, I realized I have "deny duplicates;" at the top of my
config file. I added "allow duplicates;" to the subnet declaration for the
subnet above, and it seems to have fixed the problem.

Is this expected behavior?

Thanks,
David Sotnick
--
Tech. Lead - Unix Infrastructure
Pixar Animation Studios
Emeryville, CA