NAME
dhclient
—
Dynamic Host Configuration Protocol
(DHCP) client
SYNOPSIS
dhclient |
[-dqu ] [-c
file] [-i
options] [-L
file] [-l
file] interface |
DESCRIPTION
The dhclient
utility provides a means for
configuring network interfaces using DHCP, BOOTP, or if these protocols
fail, by statically assigning an address.
The name of the network interface that
dhclient
should attempt to configure must be
specified on the command line.
The options are as follows:
-c
file- Specify an alternate location to /etc/dhclient.conf for the configuration file.
-d
- Forces
dhclient
to always run as a foreground process. By default,dhclient
runs in the foreground until it has configured the interface, and then will revert to running in the background. -i
optionsdhclient
will ignore any values provided by leases for the options specified. This list will override any ignore statements in dhclient.conf(5). options must be a comma separated list of valid option names. Invalid option names will cause the entire list to be discarded.-L
file- Specify a file to write the option data to. This
causes
dhclient
to write two pseudo-leases, “offered” and “effective”, to the specified file. The offered block will contain the lease offered by the DHCP server; the effective block will contain the modified lease used to configure the interface. -l
file- Specify an alternate location to /var/db/dhclient.leases.⟨IFNAME⟩ for the leases file.
-q
- Forces
dhclient
to be less verbose on startup. -u
- Forces
dhclient
to reject leases with unknown options in them. The default behaviour is to accept such lease offers.
The DHCP protocol allows a host to contact a central server which maintains a list of IP addresses which may be assigned on one or more subnets. A DHCP client may request an address from this pool, and then use it on a temporary basis for communication on the network. The DHCP protocol also provides a mechanism whereby a client can learn important details about the network to which it is attached, such as the location of a default router, the location of a name server, and so on.
On startup, dhclient
reads
/etc/dhclient.conf for configuration instructions.
It then attempts to configure the network interface
interface with DHCP. The special value
“egress” may be used instead of a network interface name. In
this case dhclient
will look for the network
interface currently in the interface group “egress” and
configure it with DHCP. If there is more than one network interface in the
egress group dhclient
will exit with an error.
When configuring the interface, dhclient
attempts to remove any existing addresses, gateway routes that use the
interface, and non-permanent
arp(8) entries. Conversely, if the interface is later manipulated to
add or delete addresses then dhclient
will
automatically exit. It thus automatically exits whenever a new
dhclient
is run on the same interface.
Once the interface is configured, dhclient
constructs a
resolv.conf(5) file. It does this only when one or both of
the options domain-name
and
domain-name-servers
is present. (note that these
options may be offered by the DHCP server but suppressed by
dhclient.conf(5)). If a resolv.conf is constructed,
dhclient
appends any contents of the
resolv.conf.tail(5) file, which are read once at start up.
The constructed resolv.conf is copied into
/etc/resolv.conf whenever the default route goes out
the interface dhclient
is running on.
dhclient
monitors the system for changes to the
default route and re-checks whether it should write its resolv.conf when
possible changes are detected.
In order to keep track of leases across system reboots and server
restarts, dhclient
keeps a list of leases it has
been assigned in the
/var/db/dhclient.leases.⟨IFNAME⟩
file. IFNAME represents the network interface of the
DHCP client (e.g. em0), one for each interface. On startup, after reading
the
dhclient.conf(5) file, dhclient
reads
the leases file to refresh its memory about what leases it has been
assigned.
Old leases are kept around in case the DHCP server is unavailable
when dhclient
is first invoked (generally during the
initial system boot process). In that event, old leases from the
dhclient.leases.⟨IFNAME⟩
file which have not yet expired are tested, and if they are determined to be
valid, they are used until either they expire or the DHCP server becomes
available.
A mobile host which may sometimes need to access a network on
which no DHCP server exists may be preloaded with a lease for a fixed
address on that network. When all attempts to contact a DHCP server have
failed, dhclient
will try to validate the static
lease, and if it succeeds, it will use that lease until it is restarted.
A mobile host may also travel to some networks on which DHCP is not available but BOOTP is. In that case, it may be advantageous to arrange with the network administrator for an entry on the BOOTP database, so that the host can boot quickly on that network rather than cycling through the list of old leases.
dhclient
requires at least one
/dev/bpf* file for each broadcast network interface.
See bpf(4) for more information.
SIGNALS
While running, dhclient
reacts to a few
different signals:
HUP
- On receiving
HUP
dhclient
will restart itself, reading dhclient.conf(5) and obtaining a new lease. INT
- On receiving
INT
dhclient
will exit after attempting to remove any routes, interface addresses or temporary files it created. QUIT
- On receiving
QUIT
dhclient
will dump core and exit without attempting to remove any routes, interface addresses or temporary files it created. TERM
- On receiving
TERM
dhclient
will exit without attempting to remove any routes, interface addresses or temporary files it created. USR1, USR2
- On receiving either
USR1
orUSR2
,dhclient
will exit after attempting to remove any routes, interface addresses or temporary files it created.
FILES
- /etc/dhclient.conf
- DHCP client configuration file
- /var/db/dhclient.leases.⟨IFNAME⟩
- database of acquired leases
SEE ALSO
bpf(4), dhclient.conf(5), dhclient.leases(5), dhcp(8), dhcpd(8), dhcrelay(8)
AUTHORS
dhclient
was written by
Ted Lemon ⟨mellon@fugue.com⟩ and
Elliot Poger ⟨elliot@poger.com⟩.
The current implementation was reworked by Henning Brauer ⟨henning@openbsd.org⟩.