On Wed, 23 Jun 2004, Melvin Backus wrote:
> get an address. I see your point about leases not surviving reboots. Does
> that apply only to the CD version or the generic-pc and soekris versions too?
It certainly applies to the Soekris version AFAIK, because CF has a
limited number of write cycles. It would probably be acceptable to write
something to CF prior to rebooting (I think it already has a kludge like
that for DynDNS), but that only helps *orderly* reboots.
The main problem on a CF-based system is that the dhcpd doesn't separate
the two different levels of persistency. The RFCs don't require *leases*
to survive server reboots, but say that every effort should be made to
insure that the *mappings* survive. Thus, if the server crashes, a client
may lose it's lease, but when it gets another one it should have the same
address as before.
Since mappings only change rarely, writing them to CF would be
acceptable. But keeping *lease* information updated on CF would wear it
out. Unfortunately, AFAIK the current dhcpd keeps both kinds of
information in one file.
On Thu, 24 Jun 2004, Adam Nellemann wrote:
> Note also that any static mappings are NOT allowed to lie within the
> choosen dynamic IP range, so it is not an option to use all the
> dynamic IPs for the static mappings.
There's no reason in principle for this restriction. It might be worth a
warning, but the dynamic assignment could certainly skip over any
"obstacles". I don't know if that's a dhcpd restriction or just a
> What is needed, is some way of telling m0n0wall not to dole out any
> dynamic IPs, but only honor requests from the MACs in the list of
> static mappings.
This is supported by dhcpd itself - one simply omits the
"range" parameter from dhcpd.conf.