NAME
dhcpd - dynamic host configuration protocol daemon
SYNOPSIS
dhdpd [-qar] [-t[level]] [-d[level]] [-f configfile] [-c
cachefile] [-p poolfile] [host ...]
DESCRIPTION
Dhcpd is a client and a server for the Dynamic Host Confi-
guration Protocol. As a client it collects DHCP data to
configure the Ethernet networks with, and as a server it
answers DHCP queries from other machines.
This manual page describes the operation of dhcpd, the asso-
ciated configuration file is described in dhcp.conf(5).
(The latter, together with boot(8), is of more practical
value when it comes to getting a machine's networks inter-
faces up and running. See the options section below for
debugging DCHP problems.)
Initialization
On a normal startup, i.e. none of the -q, -a or -r options
are given, dhcpd determines what IP devices are present, and
which of those are Ethernets. For each network it looks for
information in the configuration file as if it were a server
answering a query for that network. If any information is
found then the IP address is configured and the information
stored in the cache file.
Client Operation
For each still unconfigured network a DHCP DISCOVER request
is broadcast on that network. If a DHCP OFFER reply is
received then a DHCP REQUEST is broadcast for the IP address
offered, and if a DHCP ACK is received then the network is
configured and the information stored in the cache file.
If no reply is received then another query is sent after 4
seconds, and then again after 8 seconds, doubling each time
until 64 seconds. Every 64 seconds thereafter a request is
broadcast until a reply is received.
Once configured the DHCP lease, rebind and renew times are
computed. At the renew time a DHCP REQUEST is sent to the
DHCP server to extend the lease. Normally we get an answer
and refresh our information, but if no reply is received we
wait for half the remaining time until the rebind time and
keep retrying and halving the remaining time. When the
rebind time is reached the DHCP REQUEST is broadcast to try
and reach some other DHCP server. Halving the remaining
time again and again until the lease expires. At that point
we go back to square one and broadcast a DHCP DISCOVER.
If at any point a DHCP NAK is received we start over com-
pletely. After a DHCP OFFER an ARP request is transmitted
just before the DHCP REQUEST to check if the address offered
is already in use. If an ARP reply is received before the
DHCP ACK then after the ACK we send a DHCP DECLINE to the
server to tell that the address isn't what we want and again
we start over.
Router Discovery
The gateway offered by the DHCP server is made known to the
TCP/IP server by sending an ICMP router advertisement to the
local interface with a short lifetime and a low priority.
Then up to three router solicitations are broadcast three
seconds apart to look for a router. If a router answers
with a router advertisement then we no longer worry about
routing for that interface. Otherwise the router informa-
tion is refreshed before it expires and another solicitation
is sent out. This happens about twice an hour.
Server Operation
Once all networks so marked are configured the daemon starts
answering requests by other machines or relaying requests to
other DHCP servers. DHCP requests are answered if informa-
tion for a client can be found in the configuration file, or
if a free address can be found in the pool file, or if a
client rerequests an address it already owns.
If the daemon is both a server and a relay for a network
then it will try to answer a request and only relay if it
has no answer.
Nothing more to do?
If the daemon finds out that all networks have an infinite
lease (configured with a fixed address), there is no router
information to keep warm, and it isn't a server then it sim-
ply exits.
Asynchronous I/O?
MINIX 3 doesn't have the asynchronous I/O that Minix-vmd
has, so under MINIX 3 the daemon only works with one network
at a time. If it's stuck on the same network for 32 seconds
then that network is closed and another network is tried for
32 seconds. This usually works ok as a client, but as a
server it can only handle one network.
OPTIONS
-q Read and print the cache and pool file contents, show-
ing DHCP information for each network, and the IP
addresses in the pool with lease times and current/last
owners of those addresses.
-a Add the named hosts (or IP addresses) to the pool file.
-r Remove hosts from the pool file.
[-t[level]]
Set the test level (by default 1). At test level 1 all
networks are seen as unconfigured, will not be config-
ured and no data will be put in the cache. The program
will just act as-if. At test level 2 the interfaces
will not be configured from the configuration file, the
data must come from a remote server. At level 3 the
renewal, rebind and lease time will be 60, 120 and 180
seconds. At level 4 these times will be 60, 60, and
120. At level 5 these times will be 60, 60, and 60.
These test levels are meant to debug the DHCP client
code, and are best used with a high debug level.
[-d[level]]
Set the debug level (by default 1). At debug level 1
the program shows Ethernet and IP addresses as they are
determined or configured, DHCP messages sent and
received with little detail (one line per message), and
memory use. At debug level 2 each DHCP packet is
decoded and shown in detail. At debug level 3 device
opens and closes are shown. The debugging level may
also be increased by 1 at runtime by sending signal
SIGUSR1 or turned off (set to 0) with SIGUSR2.
-f configfile
Names the configuration file, by default
/etc/dhcp.conf.
-c cachefile
Names the cache file, by default /usr/adm/dhcp.cache.
-p poolfile
Names the IP address pool, by default
/usr/adm/dhcp.pool.
SEE ALSO
RFC-2131, RFC-1533, dhcp.conf(5), hosts(5), ifconfig(8),
inet(8), boot(8), inetd(8), nonamed(8).
DIAGNOSTICS
"'/etc/dhcp.conf', line ..."
The program exits on any configuration file error. You
have to correct the error and restart the program.
"No lease set for address ..."
There must be a lease time defined for addresses in the
pool. Correct and restart the program.
"###### declines #.#.#.# saying '...'"
A client with the given client identifier (usually 01
followed by the client's Ethernet address) declines an
IP address, hopefully with a message telling why. This
usually means that the IP address is already in use by
another host. This program, acting as a client, will
tell what other host in its message, but Windows has no
additional info alas.
"Got a NAK from #.#.#.# [through #.#.#.#] saying '...'"
The server with the given IP address doesn't want us to
have or keep the IP address we were offered or are
rerequesting. This could mean that the server has for-
gotten about us and has given our address to another
machine. This is bad if our lease hasn't yet expired.
There may be a relay involved, and there may even be a
text message with precise information.
"#.#.#.# offered by #.#.#.# is already in use by #:#:#:#:#:#"
We got an ARP reply for an offered address. We won't
accept it, and send out a DECLINE when we get an ACK.
"DHCP packet too big, ..."
You've got way to much information in the configuration
file, more than fits in a minimum size DHCP packet.
(Notify the author if you really need to send more
information. He doesn't think anyone needs to.)
"Pool table is corrupt"
You will have to remove and refill the pool file.
Chaos may ensue if there are active clients and they
don't use ARP to detect each other. (Most do.)
BUGS
There is no randomization of timers. Modern systems don't
blink under the load of several clients broadcasting a few
packets in sync.
There is no extra time spent waiting for an ARP reply. It
is assumed that any IP stack will immediately respond, so
that the DHCP server can't possibly beat it at sending out
an ACK. (The DHCP server has to commit the lease to stable
storage first anyway.)
Way more nonsense can be sent in a DHCP packet that MINIX 3
could do something with, but nobody does so we don't bother.
DHCP was invented by a rabid gerbil on speed.
AUTHOR
Kees J. Bot <kjb@cs.vu.nl>