On Thu, 24 Jun 2004, Joey Morin wrote:
> this is precisely what many cable and dsl ISPs do. rogers here in
> ontario, for example. as long as you're not down for more than 4 days,
> you get the same IP next time you connect.
The only reason for the time to be finite at all is due to addresses
On Thu, 24 Jun 2004, Justin Ellison wrote:
> On Thu, 2004-06-24 at 14:26, Adam Nellemann wrote:
> > > On Thu, 24 Jun 2004, Adam Nellemann wrote:
> > >
> > > It insures that existing access isn't killed by the loss of the lease.
> > > Without persistent mappings, the reincarnated server may reassign an
> > > address to a different client, resulting in two clients with the same
> > > address.
> ISC DHCPd does issue a ping to the IP before issuing a lease - so
> realistically, this could only happen if the hosts on the LAN were
> blocking pings.
Or not happening to respond for some other reason.
> The problem is that dhcp is supposed to re-offer the same IP over and
> over to an existing MAC. This is what's being lost in a reboot of
> m0n0wall. There aren't any quick and easy hooks in the DHCPd to execute
> a script upon a lease (that I know of), so more than likely the better
> solution would be to have a PHP script run via cron, and parse
> dhcpd.log. Any new mappings that weren't present before could be stored
> in config.xml. Upon bootup, we could build a quick dhcpd.leases file
> from those entries. Given the excellent uptime of most m0n0walls, the
> script probably wouldn't need to be ran that often.
First of all, IMNSHO information of that form doesn't belong in
config.xml, for a couple of reasons:
1) The config file should only be written by explict user changes, rather
than becoming a catch-all for all sorts of persistent information that
isn't really "configuration".
2) The more "cooks" that get their paws into the config file, the greater
the chance that something will hiccup and hose it.
And nothing so complicated is needed for the explicit reboot case,
anyway. As long as writing CF once per reboot is acceptable, all that's
needed during the reboot is:
1) Mount /conf read/write
2) Copy /etc/dhcpd.leases to /conf/
3) Dismount /conf (implied by the reboot, anyway)
4) Copy /conf/dhcpd.leases to /etc/
Note that this even works for firmware upgrades, since the upgrade process
preserves /conf/*, not just /conf/comfig.xml.
On Thu, 24 Jun 2004, Melvin Backus wrote:
> At 02:54 PM 6/24/2004, Fred Wright wrote:
> >It insures that existing access isn't killed by the loss of the lease.
> >Without persistent mappings, the reincarnated server may reassign an
> >address to a different client, resulting in two clients with the same
> I could be mistaken, but I believe I read somewhere that at least some
> implementations of DHCP the server would attempt to determine if anyone was
> using a specific IP address before assigning it from the pool, even though
It can't do that reliably. In particular, static mappings should expect
to survive the client's being powered off, and it can't very well answer
pings in that state. :-)
> I'm not sure which of the MANY implementations I was dealing with at the
> time, but it's a rather simple means of allowing for example 2 DHCP servers
> on the same subnet serving the same addresses. If one of them goes down,
> the other can and will continue to serve the entire subnet. Most of the
If you *really* want multiple DHCP servers to offer addresses from the
same pool, you need some way to keep them synchronized.
On Fri, 25 Jun 2004, Adam Nellemann wrote:
> Well then, now we have at least one good reason for having some kind
> of "static only" feature (checkbox or otherwise)!
> Until then, you could probably enter a cmd.line in the config.xml,
> forcing the dhcp server not to use a dynamic pool (assuming such a
> cmd.line is run after m0n0wall has finished starting and configuring
> the DHCP server?) However, I am not the person to tell you exactly how
> this should be done???
There is no "command line" feature to do this, but the way to avoid a
dynamic pool is simply to leave it out of the dhcpd.conf.
On Fri, 25 Jun 2004, Adam Nellemann wrote:
> Joey Morin wrote:
> > This one time, at band camp, Stefan Thuering said:
> >>1. each client broadcasts a dhcp request
> >>2. both servers look in their static list
> >>3. the server that finds the client sends the answer back
> >>4. the other server will keep quite IF it only allows static clients!
> > wouldn't the server that doesn't find the client in it's static list reply
> > with a 'deny'?
There is no "deny" at this level, just the lack of an offer.
The protocol goes like this:
1) The client broadcasts a DHCPDISCOVER, giving its client ID (among other
2) Zero or more servers respond with DHCPOFFERs suggesting IP addresses
and lease times.
3) The client chooses an offer and sends a DHCPREQUEST to the offering
server for the assignment.
4) If the server still considers the offer valid, it responds with
DHCPACK. Otherwise, the client has to go back to step 3 or step 1.
It's also legal for the client to begin with step 3 if it currently has an
address that it prefers to keep, but the server may refuse.
The main thing that makes DHCP ugly is that it involves IP-based
communication by a client that has no IP address, requiring various
kludges to get the packets through.
> Hmm, would that cause the client not to respond to the other server?
> What about the whole idea of two DHCP servers on one subnet, would
> they interfere with each other? (assuming the DHCP servers aren't made
> and/or set up to be "multi-DHCP-server aware"?)
It's perfectly legal to have multiple servers, but it gets complicated
when they aren't mutually exclusive with respect to both IP addresses and
"client IDs" (normally the MAC addresses).