DHCP client network configuration script
The DHCP client network configuration script is invoked from time to time by
In general, customizations specific to a particular computer
should be done in the /etc/dhclient.conf file.
When dhclient(8) needs to
invoke the client configuration script, it sets up a number of environment
variables and runs
dhclient-script. In all cases,
$reason is set to the name of the reason why the script
has been invoked. The following reasons are currently defined: BOUND, RENEW,
REBIND, REBOOT, EXPIRE, FAIL and TIMEOUT.
- The DHCP client has done an initial binding to a new address. The new IP
address is passed in $new_ip_address, and the
interface name is passed in $interface. Any options
acquired from the server are passed using the option name described in
except that dashes (‘-’) are replaced by underscores
(‘_’) in order to make valid shell variables, and the
variable names start with new_. So for example, the new subnet mask would
be passed in $new_subnet_mask.
When a binding has been completed, a lot of network parameters
are likely to need to be set up. A new
/etc/resolv.conf needs to be created, using the
values of $new_domain_name and
$new_domain_name_servers (which may list more than
one server, separated by spaces). A default route should be set using
$new_routers, and static routes may need to be set
up using $new_static_routes.
effectively overwrites /etc/resolv.conf, any
information contained therein is lost. If options must be passed to the
resolver, they may be contained in
/etc/resolv.conf.tail, which is appended to the
generated /etc/resolv.conf by
for further information.
- When a binding has been renewed, the script is called as in BOUND, except
that in addition to all the variables starting with $new_, there is
another set of variables starting with $old_. Persistent settings that may
have changed need to be deleted - for example, if a local route to the
bound address is being configured, the old local route should be deleted.
If the default route has changed, the old default route should be deleted.
If the static routes have changed, the old ones should be deleted.
Otherwise, processing can be done as with BOUND.
- The DHCP client has rebound to a new DHCP server. This can be handled as
with RENEW, except that if the IP address has changed, the ARP table
should be cleared.
- The DHCP client has successfully reacquired its old address after a
reboot. This can be processed as with BOUND.
- The DHCP client has failed to renew its lease or acquire a new one, and
the lease has expired. The IP address must be relinquished, and all
related parameters should be deleted, as in RENEW and REBIND.
- The DHCP client has been unable to contact any DHCP servers, and any
leases that have been tested have not proved to be valid. The parameters
from the last lease tested should be deconfigured. This can be handled in
the same way as EXPIRE.
- The DHCP client has been unable to contact any DHCP servers. However, an
old lease has been identified, and its parameters have been passed in as
with BOUND. The client configuration script should test these parameters
and, if it has reason to believe they are valid, should exit with a value
of zero. If not, it should exit with a nonzero value.
The usual way to test a lease is to set up the network as with
REBIND (since this may be called to test more than one lease) and then ping
the first router defined in $routers. If a response is
received, the lease must be valid for the network to which the interface is
currently connected. It would be more complete to try to ping all of the
routers listed in $new_routers, as well as those
listed in $new_static_routes, but current scripts do
not do this.
The original version of
dhclient-script was written for
the Internet Software Consortium by Ted Lemon
⟨firstname.lastname@example.org⟩ in cooperation with Vixie Enterprises.
The OpenBSD implementation of
If more than one interface is being used, there's no obvious way to avoid
clashes between server-supplied configuration parameters - for example, the
stock dhclient-script rewrites /etc/resolv.conf. If
more than one interface is being configured,
/etc/resolv.conf will be repeatedly initialized to the
values provided by one server, and then the other. Assuming the information
provided by both servers is valid, this shouldn't cause any real problems, but
it could be confusing.
dhclient-script was written by
Kenneth R. Westerback