DHCPD 4.0.0 - UPDATE

[Dean, Barry]

Eureka, as they say!

I said:
> -----Original Message-----
> From: dhcp-users-bounces at lists.isc.org [mailto:dhcp-users-
> bounces at lists.isc.org] On Behalf Of Dean, Barry
> Sent: 09 February 2009 14:26
> To: dhcp-users at isc.org
> Subject: DHCPD 4.0.0
> 
> 2) A show stopper!
> 	Twice now we have had machines that have picked up a dynamic
> lease, then we have allocated a fixed lease, after doing do we see
> DHCPREQUESTs from the machine for the old dynamic lease followed by a:
> 
> 	DHCPREQUEST for w.x.y.z from aa:bb:cc:dd:ee:ff via e1000g2: lease
> w.x.y.z unavailable.
> 
> 	After which the server stops responding! Not good!

After spending a couple of days on this on and off, I have a test bed where I can replicate the problem.

Here is what I do... I have a single DHCP server (no failover) with one subnet defined. No static IP allocations.

I boot a client (I have tried Ubuntu and Vista), and client gets a dynamic IP. All fine...

I then edit the config and put in a static allocation based on the MAC address like:

host client {
  fixed-address 192.168.1.10 ;
  hardware Ethernet 00:31:72:73:c8:c9 ;
}

I restart dhcpd and wait for the client to refresh its lease (I set max-lease-time to 600 and default-lease-time to 300).

Client comes along with a DHCPREQUEST for the dynamic IP 192.168.1.20 and the log says:

DHCPREQUEST for 192.168.1.20 from 00:31:72:73:c8:c9 via e1000g0: lease 192.168.1.20 unavailable.
DHCPNAK on 192.168.1.20 to 00:31:72:73:c8:c9 via e1000g0

The client keeps using the IP 192.168.1.20 until the lease expires, then starts a DHCPDISCOVER etc.

I can truss the dhcpd process and see the packets being read by recvfrom(), but NOTHING appears in the log and NOTHING happens. Poor client keeps trying until it gives up.

The server has simply stopped responding.

Looking at the source, the error comes from dhcp.c:

        /* If the address the client asked for is ours, but it wasn't
           available for the client, NAK it. */
        if (!lease && ours) {
                log_info ("%s: lease %s unavailable.", msgbuf, piaddr (cip));
                nak_lease (packet, &cip);
                goto out;
        }

At "out" the server does:

      out:
        if (subnet)
                subnet_dereference (&subnet, MDL);
        if (lease)
                lease_dereference (&lease, MDL);
        return;

Question is, who does this result in the server's failure to respond? Is this the expected behaviour, or have a tickled a bug?

We often need to do this procedure when someone installs a machine and later requires a fixed IP for it. In fact most printers get installed first and pick up a dynamic IP then we are asked to change it to a fixed one.

However this is unworkable if some (not all) moves from dynamic to fixed IP leases kills the server sometime in the future.

We had one last week that did it's destructive worst on Sunday, I was trying to restart DHCP and cook the sausages for the children at the same time! Ever tried fixing a DHCP server typing on an iPhone one handed whilst turning sausages with tongs on the other? That's what I call hardcore system administration!

Can anyone suggest a way out of this!

Thanks.

---------------
Barry Dean
Networks Team
http://pcwww.liv.ac.uk/~bvd/