Where does DHCPD store its backup of the dhcpd.leases file?

Jessica Meyer jessmeyer82 at gmail.com
Mon Jul 20 08:46:08 UTC 2009


Dear Simon

> The server will automatically delete any leases that aren't within a defined
> range. Eg, if you have a "range 192.168.1.100 192.168.1.199" statement, and
> create a lease for 192.168.1.27, then that fake lease will automatically be
> deleted on startup - and you'll see it logged I think.

Okay, and fixed-addresses aren't in ranges - that would explain why
DHCPD deletes these leases. I cannot put them in ranges because then
they would be treated as dynamic IP addresses. I'm a little out of
ideas now. Maybe reserved-leases would do it, but I have not found any
reference on how to create them - I need it in a configuration file.
At the moment I use host{} statmenents with fixed-address in it, like
so:

host 00001229b180 {
	hardware ethernet 00:00:12:29:b1:80;
	fixed-address 192.168.10.15;
}

If there's a way how to use reserved-statements, I would be happy. But
as far as I understand, there's no "reserved" statement in the
configuration file (dhcpd.conf), but they're in the lease file, right?

> I'd have thought reserved leases should deal with your problem - they
> shouldn't be ignored as they are treated exactly the same as any other lease
> except tat they will never be reallocated to another client.

Well, we've tested that in our lab environment and as far as I can
remember, I think the problem was that the leasequery did not answer
with the client's mac address, i.e. the leasequery gave back a
LEASEACTIVE but without a mac address, which I need. I'm not sure
anymore, but I think that was the problem.

> It won't help with users that manually configure their machine as those
> devices will never have an active lease, and I'd have thought that it should
> be correct behaviour to NOT respond that the lease is active.

Absolutely. I'm working in a DOCSIS (cable modem) environment and for
some strange reasons the CMTS (cable modem termination system) needs a
DHCPLEASEACTIVE with the client's IP and MAC address - if there's no
such answer from DHCPD, it won't create an ARP table entry and the
customer can not surf. This is a security feature ("source-verify").
In our lab I found out that LEASEQUERY only works for the CMTS if
there is a lease in dhcpd.leases.

> Relying on the DHCP server to say a lease is active when a user
> manually configures their device seems like a recipe for
> trouble - what are you trying to do that needs it ?

Yeah, but I saw commercial products which did it exactly like that
(reverse-engineered with a network sniffer). I'm open for other
solutions, but what I need are fixed IP addresses which should act
like normal leases - and I need the client IP and MAC address in
leaseactive responses.

Jess



More information about the dhcp-users mailing list