Minix Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
DHCPD(8)                    System Manager's Manual                   DHCPD(8)

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  Configuration
       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 associated
       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 interfaces 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 completely.  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 information  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 information 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 simply 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, showing 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  configured  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 forgotten 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>

                                                                      DHCPD(8)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | SEE ALSO | DIAGNOSTICS | BUGS | AUTHOR