mir/isc-dhcp
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/dhcp synced 2025-09-01 23:05:29 +00:00
Code Issues Releases Wiki Activity

Merge from branch - Remove pre-formatted man pages from the

Browse Source 
repository.
This commit is contained in:
Murray
2002-06-09 22:46:49 +00:00
parent 0d5e25bc07
commit 7d1223521e
4 changed files with 0 additions and 1254 deletions
Download Patch File Download Diff File Expand all files Collapse all files

264
client/dhclient-script.cat8
View File

@@ -1,264 +0,0 @@
dhclient-script(8) dhclient-script(8)
NNAAMMEE
dhclient-script - DHCP client network configuration script
DDEESSCCRRIIPPTTIIOONN
The DHCP client network configuration script is invoked
from time to time by ddhhcclliieenntt((88)). This script is used by
the dhcp client to set each interface's initial configura<72>
tion prior to requesting an address, to test the address
once it has been offered, and to set the interface's final
configuration once a lease has been acquired. If no lease
is acquired, the script is used to test predefined leases,
if any, and also called once if no valid lease can be
identified.
This script is not meant to be customized by the end user.
If local customizations are needed, they should be possi<73>
ble using the enter and exit hooks provided (see HOOKS for
details). These hooks will allow the user to override
the default behaviour of the client in creating a
//eettcc//rreessoollvv..ccoonnff file.
No standard client script exists for some operating sys<79>
tems, even though the actual client may work, so a pio<69>
neering user may well need to create a new script or mod<6F>
ify an existing one. In general, customizations specific
to a particular computer should be done in the
//eettcc//ddhhcclliieenntt..ccoonnff file. If you find that you can't make
such a customization without customizing
//eettcc//ddhhcclliieenntt..ccoonnff or using the enter and exit hooks,
please submit a bug report.
HHOOOOKKSS
When it starts, the client script first defines a shell
function, mmaakkee__rreessoollvv__ccoonnff ,, which is later used to create
the //eettcc//rreessoollvv..ccoonnff file. To override the default
behaviour, redefine this function in the enter hook
script.
On after defining the make_resolv_conf function, the
client script checks for the presence of an executable
//eettcc//ddhhcclliieenntt--eenntteerr--hhooookkss script, and if present, it
invokes the script inline, using the Bourne shell '.' com<6F>
mand. The entire environment documented under OPERATION
is available to this script, which may modify the environ<6F>
ment if needed to change the behaviour of the script. If
an error occurs during the execution of the script, it can
set the exit_status variable to a nonzero value, and
//eettcc//ddhhcclliieenntt--ssccrriipptt will exit with that error code imme<6D>
diately after the client script exits.
After all processing has completed, //eettcc//ddhhcclliieenntt--ssccrriipptt
checks for the presence of an executable //eettcc//ddhhcclliieenntt--
eexxiitt--hhooookkss script, which if present is invoked using the
'.' command. The exit status is passed in the
1
dhclient-script(8) dhclient-script(8)
exit_status shell variable, and will always be zero if the
script succeeded at the task for which it was invoked.
OOPPEERRAATTIIOONN
When dhclient needs to invoke the client configuration
script, it writes a shell script into /tmp which defines a
variety of variables. In all cases, $reason is set to the
name of the reason why the script has been invoked. The
following reasons are currently defined: MEDIUM, PREINIT,
BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL and TIMEOUT.
MMEEDDIIUUMM
The DHCP client is requesting that an interface's media
type be set. The interface name is passed in $interface,
and the media type is passed in $medium.
PPRREEIINNIITT
The DHCP client is requesting that an interface be config<69>
ured as required in order to send packets prior to receiv<69>
ing an actual address. For clients which use the BSD
socket library, this means configuring the interface with
an IP address of 0.0.0.0 and a broadcast address of
255.255.255.255. For other clients, it may be possible
to simply configure the interface up without actually giv<69>
ing it an IP address at all. The interface name is
passed in $interface, and the media type in $medium.
If an IP alias has been declared in dhclient.conf, its
address will be passed in $alias_ip_address, and that ip
alias should be deleted from the interface, along with any
routes to it.
BBOOUUNNDD
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. The media type is passed in $medium. Any
options acquired from the server are passed using the
option name described in ddhhccpp--ooppttiioonnss, 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.
Before actually configuring the address, dhclient-script
should somehow ARP for it and exit with a nonzero status
if it receives a reply. In this case, the client will
send a DHCPDECLINE message to the server and acquire a
different address. This may also be done in the RENEW,
REBIND, or REBOOT states, but is not required, and indeed
may not be desirable.
When a binding has been completed, a lot of network
2
dhclient-script(8) dhclient-script(8)
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, seperated by spaces). A
default route should be set using $new_routers, and static
routes may need to be set up using $new_static_routes.
If an IP alias has been declared, it must be set up here.
The alias IP address will be written as $alias_ip_address,
and other DHCP options that are set for the alias (e.g.,
subnet mask) will be passed in variables named as
described previously except starting with $alias_ instead
of $new_. Care should be taken that the alias IP address
not be used if it is identical to the bound IP address
($new_ip_address), since the other alias parameters may be
incorrect in this case.
RREENNEEWW
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.
RREEBBIINNDD
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.
RREEBBOOOOTT
The DHCP client has successfully reacquired its old
address after a reboot. This can be processed as with
BOUND.
EEXXPPIIRREE
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.
FFAAIILL
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.
TTIIMMEEOOUUTT
The DHCP client has been unable to contact any DHCP
3
dhclient-script(8) dhclient-script(8)
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.
FFIILLEESS
Each operating system should generally have its own script
file, although the script files for similar operating sys<79>
tems may be similar or even identical. The script files
included in the Internet Software Consortium DHCP distri<72>
bution appear in the distribution tree under
client/scripts, and bear the names of the operating sys<79>
tems on which they are intended to work.
BBUUGGSS
If more than one interface is being used, there's no obvi<76>
ous way to avoid clashes between server-supplied configu<67>
ration 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 ini<6E>
tialized 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.
SSEEEE AALLSSOO
dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and
dhclient.leases(5).
AAUUTTHHOORR
ddhhcclliieenntt--ssccrriipptt((88)) has been written for the Internet Soft<66>
ware Consortium by Ted Lemon <mellon@fugue.com> in cooper<65>
ation with Vixie Enterprises. To learn more about the
Internet Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc..
To learn more about Vixie Enterprises, see
hhttttpp::////wwwwww..vviixx..ccoomm..
4

264
client/dhclient.cat8
View File

@@ -1,264 +0,0 @@
dhclient(8) dhclient(8)
NNAAMMEE
dhclient - Dynamic Host Configuration Protocol Client
SSYYNNOOPPSSIISS
ddhhcclliieenntt [ --pp _p_o_r_t ] [ --dd ] [ --DD ] [ --qq ] [ --cc ] [ --llff
_l_e_a_s_e_-_f_i_l_e ] [ --ppff _p_i_d_-_f_i_l_e ] [ --ccff _c_o_n_f_i_g_-_f_i_l_e ] [ --ss
server ] [ --ww ] [ _i_f_0 [ _._._._i_f_N ] ]
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP Client, dhclient,
provides a means for configuring one or more network
interfaces using the Dynamic Host Configuration Protocol,
BOOTP protocol, or if these protocols fail, by statically
assigning an address.
OOPPEERRAATTIIOONN
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 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 the _d_h_c_l_i_e_n_t_._c_o_n_f for configu<67>
ration instructions. It then gets a list of all the net<65>
work interfaces that are configured in the current system.
For each interface, it attempts to configure the interface
using the DHCP protocol.
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 dhclient.leases(5) file. On
startup, after reading the dhclient.conf file, dhclient
reads the dhclient.leases file to refresh its memory about
what leases it has been assigned.
When a new lease is acquired, it is appended to the end of
the dhclient.leases file. In order to prevent the file
from becoming arbitrarily large, from time to time
dhclient creates a new dhclient.leases file from its in-
core lease database. The old version of the
dhclient.leases file is retained under the name
_d_h_c_l_i_e_n_t_._l_e_a_s_e_s_~ until the next time dhclient rewrites the
database.
Old leases are kept around in case the DHCP server is
unavailable when dhclient is first invoked (generally dur<75>
ing the initial system boot process). In that event, old
leases from the dhclient.leases 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
1
dhclient(8) dhclient(8)
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,
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.
CCOOMMMMAANNDD LLIINNEE
The names of the network interfaces that dhclient should
attempt to configure may be specified on the command line.
If no interface names are specified on the command line
dhclient will normally identify all network interfaces,
elimininating non-broadcast interfaces if possible, and
attempt to configure each interface.
It is also possible to specify interfaces by name in the
ddhhcclliieenntt..ccoonnff((55)) file. If interfaces are specified in
this way, then the client will only configure interfaces
that are either specified in the configuration file or on
the command line, and will ignore all other interfaces.
If the DHCP client should listen and transmit on a port
other than the standard (port 68), the --pp flag may used.
It should be followed by the udp port number that dhclient
should use. This is mostly useful for debugging purposes.
If a different port is specified for the client to listen
on and transmit on, the client will also use a different
destination port - one greater than the specified destina<6E>
tion port.
The DHCP client normally transmits any protocol messages
it sends before acquiring an IP address to,
255.255.255.255, the IP limited broadcast address. For
debugging purposes, it may be useful to have the server
transmit these messages to some other address. This can
be specified with the --ss flag, followed by the IP address
or domain name of the destination.
The DHCP client will normally run in the foreground until
it has configured an interface, and then will revert to
running in the background. To run force dhclient to
always run as a foreground process, the --dd flag should be
specified. This is useful when running the client under a
debugger, or when running it out of inittab on System V
systems.
2
dhclient(8) dhclient(8)
The client writes a temporary shell script whenever it
invokes dhclient-script. This script is normally deleted
after the client runs, but it can be helpful when debug<75>
ging the client script to see what the client wrote. The
client can be configured not to delete these scripts by
specifying the --DD flag.
The client normally prints a startup message and displays
the protocol sequence to the standard error descriptor
until it has acquired an address, and then only logs mes<65>
sages using the ssyysslloogg ((33)) facility. The --qq flag pre<72>
vents any messages other than errors from being printed to
the standard error descriptor.
The DHCP client normally gets its configuration informa<6D>
tion from //eettcc//ddhhcclliieenntt..ccoonnff,, its lease database from
//vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess and stores its process ID in a
file called //vvaarr//rruunn//ddhhcclliieenntt..ppiidd.. To specify different
names and/or locations for these files, use the --ccff,, --llff
and --ppff flags, respectively, followed by the name of the
file. This can be particularly useful if, for example,
//vvaarr//ddbb or //vvaarr//rruunn has not yet been mounted when the DHCP
client is started.
The DHCP client normally exits if it isn't able to iden<65>
tify any network interfaces to configure. On laptop com<6F>
puters and other computers with hot-swappable I/O buses,
it is possible that a broadcast interface may be added
after system startup. The --ww flag can be used to cause
the client not to exit when it doesn't find any such
interfaces. The ddhhccppccccpp ((88)) program can then be used to
notify the client when a network interface has been added
or removed, so that the client can configure an IP address
on that interface.
CCOONNFFIIGGUURRAATTIIOONN
The syntax of the dhclient.conf(8) file is discussed
seperately.
FFIILLEESS
//eettcc//ddhhcclliieenntt..ccoonnff,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess,,
//vvaarr//rruunn//ddhhcclliieenntt..ppiidd,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess~~..
SSEEEE AALLSSOO
dhcpd(8), dhcrelay(8), dhclient.conf(5),
dhclient.leases(5)
AAUUTTHHOORR
ddhhcclliieenntt((88)) has been written for the Internet Software
Consortium by Ted Lemon <mellon@fugue.com> in cooperation
with Vixie Enterprises. To learn more about the Internet
Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn
more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm..
3
dhclient(8) dhclient(8)
This client was substantially modified and enhanced by
Elliot Poger for use on Linux while he was working on the
MosquitoNet project at Stanford.
The current version owes much to Elliot's Linux enhance<63>
ments, but was substantially reorganized and partially
rewritten by Ted Lemon so as to use the same networking
framework that the Internet Software Consortium DHCP
server uses. Much system-specific configuration code was
moved into a shell script so that as support for more
operating systems is added, it will not be necessary to
port and maintain system-specific configuration code to
these operating systems - instead, the shell script can
invoke the native tools to accomplish the same purpose.
4

660
client/dhclient.conf.cat5
View File

@@ -1,660 +0,0 @@
dhclient.conf(5) dhclient.conf(5)
NNAAMMEE
dhclient.conf - DHCP client configuration file
DDEESSCCRRIIPPTTIIOONN
The dhclient.conf file contains configuration information
for _d_h_c_l_i_e_n_t_, the Internet Software Consortium DHCP
Client.
The dhclient.conf file is a free-form ASCII text file.
It is parsed by the recursive-descent parser built into
dhclient. The file may contain extra tabs and newlines
for formatting purposes. Keywords in the file are case-
insensitive. Comments may be placed anywhere within the
file (except within quotes). Comments begin with the #
character and end at the end of the line.
The dhclient.conf file can be used to configure the
behaviour of the client in a wide variety of ways: proto<74>
col timing, information requested from the server, infor<6F>
mation required of the server, defaults to use if the
server does not provide certain information, values with
which to override information provided by the server, or
values to prepend or append to information provided by the
server. The configuration file can also be preinitialized
with addresses to use on networks that don't have DHCP
servers.
PPRROOTTOOCCOOLL TTIIMMIINNGG
The timing behaviour of the client need not be configured
by the user. If no timing configuration is provided by
the user, a fairly reasonable timing behaviour will be
used by default - one which results in fairly timely
updates without placing an inordinate load on the server.
The following statements can be used to adjust the timing
behaviour of the DHCP client if required, however:
_T_h_e ttiimmeeoouutt _s_t_a_t_e_m_e_n_t
ttiimmeeoouutt _t_i_m_e ;;
The _t_i_m_e_o_u_t statement determines the amount of time that
must pass between the time that the client begins to try
to determine its address and the time that it decides that
it's not going to be able to contact a server. By
default, this timeout is sixty seconds. After the time<6D>
out has passed, if there are any static leases defined in
the configuration file, or any leases remaining in the
lease database that have not yet expired, the client will
loop through these leases attempting to validate them, and
if it finds one that appears to be valid, it will use that
lease's address. If there are no valid static leases or
unexpired leases in the lease database, the client will
restart the protocol after the defined retry interval.
1
dhclient.conf(5) dhclient.conf(5)
_T_h_e rreettrryy _s_t_a_t_e_m_e_n_t
rreettrryy _t_i_m_e;;
The _r_e_t_r_y statement determines the time that must pass
after the client has determined that there is no DHCP
server present before it tries again to contact a DHCP
server. By default, this is five minutes.
_T_h_e sseelleecctt--ttiimmeeoouutt _s_t_a_t_e_m_e_n_t
sseelleecctt--ttiimmeeoouutt _t_i_m_e;;
It is possible (some might say desirable) for there to be
more than one DHCP server serving any given network. In
this case, it is possible that a client may be sent more
than one offer in response to its initial lease discovery
message. It may be that one of these offers is prefer<65>
able to the other (e.g., one offer may have the address
the client previously used, and the other may not).
The _s_e_l_e_c_t_-_t_i_m_e_o_u_t is the time after the client sends its
first lease discovery request at which it stops waiting
for offers from servers, assuming that it has received at
least one such offer. If no offers have been received by
the time the _s_e_l_e_c_t_-_t_i_m_e_o_u_t has expired, the client will
accept the first offer that arrives.
By default, the select-timeout is zero seconds - that is,
the client will take the first offer it sees.
_T_h_e rreebboooott _s_t_a_t_e_m_e_n_t
rreebboooott _t_i_m_e;;
When the client is restarted, it first tries to reacquire
the last address it had. This is called the INIT-REBOOT
state. If it is still attached to the same network it
was attached to when it last ran, this is the quickest way
to get started. The _r_e_b_o_o_t statement sets the time that
must elapse after the client first tries to reacquire its
old address before it gives up and tries to discover a new
address. By default, the reboot timeout is ten seconds.
_T_h_e bbaacckkooffff--ccuuttooffff _s_t_a_t_e_m_e_n_t
bbaacckkooffff--ccuuttooffff _t_i_m_e;;
The client uses an exponential backoff algorithm with some
randomness, so that if many clients try to configure them<65>
selves at the same time, they will not make their requests
in lockstep. The _b_a_c_k_o_f_f_-_c_u_t_o_f_f statement determines the
maximum amount of time that the client is allowed to back
off. It defaults to two minutes.
2
dhclient.conf(5) dhclient.conf(5)
_T_h_e iinniittiiaall--iinntteerrvvaall _s_t_a_t_e_m_e_n_t
iinniittiiaall--iinntteerrvvaall _t_i_m_e;;
The _i_n_i_t_i_a_l_-_i_n_t_e_r_v_a_l statement sets the amount of time
between the first attempt to reach a server and the second
attempt to reach a server. Each time a message is sent,
the interval between messages is incremented by twice the
current interval multiplied by a random number between
zero and one. If it is greater than the backoff-cutoff
amount, it is set to that amount. It defaults to ten sec<65>
onds.
LLEEAASSEE RREEQQUUIIRREEMMEENNTTSS AANNDD RREEQQUUEESSTTSS
The DHCP protocol allows the client to request that the
server send it specific information, and not send it other
information that it is not prepared to accept. The pro<72>
tocol also allows the client to reject offers from servers
if they don't contain information the client needs, or if
the information provided is not satisfactory.
There is a variety of data contained in offers that DHCP
servers send to DHCP clients. The data that can be
specifically requested is what are called _D_H_C_P _O_p_t_i_o_n_s.
DHCP Options are defined in
ddhhccpp--ooppttiioonnss((55)).
_T_h_e rreeqquueesstt _s_t_a_t_e_m_e_n_t
rreeqquueesstt [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n ];;
The request statement causes the client to request that
any server responding to the client send the client its
values for the specified options. Only the option names
should be specified in the request statement - not option
parameters. By default, the DHCP server requests the
subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers and host-name options.
In some cases, it may be desirable to send no parameter
request list at all. To do this, simply write the
request statement but specify no parameters:
request;
_T_h_e rreeqquuiirree _s_t_a_t_e_m_e_n_t
rreeqquuiirree [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _];;
The require statement lists options that must be sent in
order for an offer to be accepted. Offers that do not
contain all the listed options will be ignored.
_T_h_e sseenndd _s_t_a_t_e_m_e_n_t
3
dhclient.conf(5) dhclient.conf(5)
sseenndd {{ [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n
]}}
The send statement causes the client to send the specified
options to the server with the specified values. These
are full option declarations as described in ddhhccpp--
ooppttiioonnss((55)). Options that are always sent in the DHCP pro<72>
tocol should not be specified here, except that the client
can specify a rreeqquueesstteedd--lleeaassee--ttiimmee option other than the
default requested lease time, which is two hours. The
other obvious use for this statement is to send informa<6D>
tion to the server that will allow it to differentiate
between this client and other clients or kinds of clients.
OOPPTTIIOONN MMOODDIIFFIIEERRSS
In some cases, a client may receive option data from the
server which is not really appropriate for that client, or
may not receive information that it needs, and for which a
useful default value exists. It may also receive infor<6F>
mation which is useful, but which needs to be supplemented
with local information. To handle these needs, several
option modifiers are available.
_T_h_e ddeeffaauulltt _s_t_a_t_e_m_e_n_t
ddeeffaauulltt [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;
If for some option the client should use the value sup<75>
plied by the server, but needs to use some default value
if no value was supplied by the server, these values can
be defined in the ddeeffaauulltt statement.
_T_h_e ssuuppeerrsseeddee _s_t_a_t_e_m_e_n_t
ssuuppeerrsseeddee [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;
If for some option the client should always use a locally-
configured value or values rather than whatever is sup<75>
plied by the server, these values can be defined in the
ssuuppeerrsseeddee statement.
_T_h_e pprreeppeenndd _s_t_a_t_e_m_e_n_t
pprreeppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;
If for some set of options the client should use a value
you supply, and then use the values supplied by the
server, if any, these values can be defined in the pprreeppeenndd
statement. The pprreeppeenndd statement can only be used for
options which allow more than one value to be given.
This restriction is not enforced - if you ignore it, the
behaviour will be unpredictable.
_T_h_e aappppeenndd _s_t_a_t_e_m_e_n_t
4
dhclient.conf(5) dhclient.conf(5)
aappppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;
If for some set of options the client should first use the
values supplied by the server, if any, and then use values
you supply, these values can be defined in the aappppeenndd
statement. The aappppeenndd statement can only be used for
options which allow more than one value to be given.
This restriction is not enforced - if you ignore it, the
behaviour will be unpredictable.
LLEEAASSEE DDEECCLLAARRAATTIIOONNSS
_T_h_e lleeaassee _d_e_c_l_a_r_a_t_i_o_n
lleeaassee {{ _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n [ ... _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n _] }}
The DHCP client may decide after some period of time (see
PPRROOTTOOCCOOLL TTIIMMIINNGG) decide that it is not going to succeed in
contacting a server. At that time, it consults its own
database of old leases and tests each one that has not yet
timed out by pinging the listed router for that lease to
see if that lease could work. It is possible to define
one or more _f_i_x_e_d leases in the client configuration file
for networks where there is no DHCP or BOOTP service, so
that the client can still automatically configure its
address. This is done with the lleeaassee statement.
NOTE: the lease statement is also used in the
dhclient.leases file in order to record leases that have
been received from DHCP servers. Some of the syntax for
leases as described below is only needed in the
dhclient.leases file. Such syntax is documented here for
completeness.
A lease statement consists of the lease keyword, followed
by a left curly brace, followed by one or more lease dec<65>
laration statements, followed by a right curly brace.
The following lease declarations are possible:
bboooottpp;;
The bboooottpp statement is used to indicate that the lease was
acquired using the BOOTP protocol rather than the DHCP
protocol. It is never necessary to specify this in the
client configuration file. The client uses this syntax
in its lease database file.
iinntteerrffaaccee ""_s_t_r_i_n_g"";;
The iinntteerrffaaccee lease statement is used to indicate the
interface on which the lease is valid. If set, this
lease will only be tried on a particular interface. When
the client receives a lease from a server, it always
records the interface number on which it received that
lease. If predefined leases are specified in the
5
dhclient.conf(5) dhclient.conf(5)
dhclient.conf file, the interface should also be speci<63>
fied, although this is not required.
ffiixxeedd--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;;
The ffiixxeedd--aaddddrreessss statement is used to set the ip address
of a particular lease. This is required for all lease
statements. The IP address must be specified as a dotted
quad (e.g., 12.34.56.78).
ffiilleennaammee ""_s_t_r_i_n_g"";;
The ffiilleennaammee statement specifies the name of the boot
filename to use. This is not used by the standard client
configuration script, but is included for completeness.
sseerrvveerr--nnaammee ""_s_t_r_i_n_g"";;
The sseerrvveerr--nnaammee statement specifies the name of the boot
server name to use. This is also not used by the stan<61>
dard client configuration script.
ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n;;
The ooppttiioonn statement is used to specify the value of an
option supplied by the server, or, in the case of prede<64>
fined leases declared in dhclient.conf, the value that the
user wishes the client configuration script to use if the
predefined lease is used.
ssccrriipptt ""_s_c_r_i_p_t_-_n_a_m_e"";;
The ssccrriipptt statement is used to specify the pathname of
the dhcp client configuration script. This script is used
by the dhcp client to set each interface's initial config<69>
uration prior to requesting an address, to test the
address once it has been offered, and to set the inter<65>
face's final configuration once a lease has been acquired.
If no lease is acquired, the script is used to test prede<64>
fined leases, if any, and also called once if no valid
lease can be identified. For more information, see
ddhhcclliieenntt--ssccrriipptt((88))..
mmeeddiiuumm ""_m_e_d_i_a _s_e_t_u_p"";;
The mmeeddiiuumm statement can be used on systems where network
interfaces cannot automatically determine the type of net<65>
work to which they are connected. The media setup string
is a system-dependent parameter which is passed to the
dhcp client configuration script when initializing the
interface. On Unix and Unix-like systems, the argument is
passed on the ifconfig command line when configuring te
interface.
6
dhclient.conf(5) dhclient.conf(5)
The dhcp client automatically declares this parameter if
it used a media type (see the mmeeddiiaa statement) when con<6F>
figuring the interface in order to obtain a lease. This
statement should be used in predefined leases only if the
network interface requires media type configuration.
rreenneeww _d_a_t_e;;
rreebbiinndd _d_a_t_e;;
eexxppiirree _d_a_t_e;;
The rreenneeww statement defines the time at which the dhcp
client should begin trying to contact its server to renew
a lease that it is using. The rreebbiinndd statement defines
the time at which the dhcp client should begin to try to
contact _a_n_y dhcp server in order to renew its lease. The
eexxppiirree statement defines the time at which the dhcp client
must stop using a lease if it has not been able to contact
a server in order to renew it.
These declarations are automatically set in leases
acquired by the DHCP client, but must also be configured
in predefined leases - a predefined lease whose expiry
time has passed will not be used by the DHCP client.
Dates are specified as follows:
_<_w_e_e_k_d_a_y_> _<_y_e_a_r_>//_<_m_o_n_t_h_>//_<_d_a_y_> _<_h_o_u_r_>::_<_m_i_n_u_t_e_>::_<_s_e_c_o_n_d_>
The weekday is present to make it easy for a human to tell
when a lease expires - it's specified as a number from
zero to six, with zero being Sunday. When declaring a
predefined lease, it can always be specified as zero. The
year is specified with the century, so it should generally
be four digits except for really long leases. The month
is specified as a number starting with 1 for January. The
day of the month is likewise specified starting with 1.
The hour is a number between 0 and 23, the minute a number
between 0 and 59, and the second also a number between 0
and 59.
AALLIIAASS DDEECCLLAARRAATTIIOONNSS
aalliiaass {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }}
Some DHCP clients running TCP/IP roaming protocols may
require that in addition to the lease they may acquire via
DHCP, their interface also be configured with a predefined
IP alias so that they can have a permanent IP address even
while roaming. The Internet Software Consortium DHCP
client doesn't support roaming with fixed addresses
directly, but in order to facilitate such experimentation,
the dhcp client can be set up to configure an IP alias
using the aalliiaass declaration.
7
dhclient.conf(5) dhclient.conf(5)
The alias declaration resembles a lease declaration,
except that options other than the subnet-mask option are
ignored by the standard client configuration script, and
expiry times are ignored. A typical alias declaration
includes an interface declaration, a fixed-address decla<6C>
ration for the IP alias address, and a subnet-mask option
declaration. A medium statement should never be included
in an alias declaration.
OOTTHHEERR DDEECCLLAARRAATTIIOONNSS
rreejjeecctt _i_p_-_a_d_d_r_e_s_s;;
The reject statement causes the DHCP client to reject
offers from servers who use the specified address as a
server identifier. This can be used to avoid being con<6F>
figured by rogue or misconfigured dhcp servers, although
it should be a last resort - better to track down the bad
DHCP server and fix it.
iinntteerrffaaccee ""_n_a_m_e"" {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }}
A client with more than one network interface may require
different behaviour depending on which interface is being
configured. All timing parameters and declarations other
than lease and alias declarations can be enclosed in an
interface declaration, and those parameters will then be
used only for the interface that matches the specified
name. Interfaces for which there is no interface decla<6C>
ration will use the parameters declared outside of any
interface declaration, or the default settings.
ppsseeuuddoo ""_n_a_m_e" "_r_e_a_l_-_n_a_m_e"" {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }}
Under some circumstances it can be useful to declare a
pseudo-interface and have the DHCP client acquire a con<6F>
figuration for that interface. Each interface that the
DHCP client is supporting normally has a DHCP client state
machine running on it to acquire and maintain its lease.
A pseudo-interface is just another state machine running
on the interface named _r_e_a_l_-_n_a_m_e, with its own lease and
its own state. If you use this feature, you must provide
a client identifier for both the pseudo-interface and the
actual interface, and the two identifiers must be differ<65>
ent. You must also provide a seperate client script for
the pseudo-interface to do what you want with the IP
address. For example:
interface "ep0" {
send dhcp-client-identifier "my-client-ep0";
}
pseudo "secondary" "ep0" {
send dhcp-client-identifier "my-client-ep0-secondary";
script "/etc/dhclient-secondary";
}
8
dhclient.conf(5) dhclient.conf(5)
The client script for the pseudo-interface should not con<6F>
figure the interface up or down - essentially, all it
needs to handle are the states where a lease has been
acquired or renewed, and the states where a lease has
expired. See ddhhcclliieenntt--ssccrriipptt((88)) for more information.
mmeeddiiaa ""_m_e_d_i_a _s_e_t_u_p"" _[ ,, ""_m_e_d_i_a _s_e_t_u_p"",, _._._. _];;
The mmeeddiiaa statement defines one or more media configura<72>
tion parameters which may be tried while attempting to
acquire an IP address. The dhcp client will cycle
through each media setup string on the list, configuring
the interface using that setup and attempting to boot, and
then trying the next one. This can be used for network
interfaces which aren't capable of sensing the media type
unaided - whichever media type succeeds in getting a
request to the server and hearing the reply is probably
right (no guarantees).
The media setup is only used for the initial phase of
address acquisition (the DHCPDISCOVER and DHCPOFFER pack<63>
tes). Once an address has been acquired, the dhcp client
will record it in its lease database and will record the
media type used to acquire the address. Whenever the
client tries to renew the lease, it will use that same
media type. The lease must expire before the client will
go back to cycling through media types.
SSAAMMPPLLEE
The following configuration file is used on a laptop run<75>
ning NetBSD 1.3. The laptop has an IP alias of
192.5.5.213, and has one interface, ep0 (a 3com 3C589C).
Booting intervals have been shortened somewhat from the
default, because the client is known to spend most of its
time on networks with little DHCP activity. The laptop
does roam to multiple networks.
timeout 60;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
reject 192.33.137.209;
interface "ep0" {
send host-name "andare.fugue.com";
send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
send dhcp-lease-time 3600;
supersede domain-name "fugue.com rc.vix.com home.vix.com";
prepend domain-name-servers 127.0.0.1;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name;
require subnet-mask, domain-name-servers;
9
dhclient.conf(5) dhclient.conf(5)
script "/etc/dhclient-script";
media "media 10baseT/UTP", "media 10base2/BNC";
}
alias {
interface "ep0";
fixed-address 192.5.5.213;
option subnet-mask 255.255.255.255;
}
This is a very complicated dhclient.conf file - in gen<65>
eral, yours should be much simpler. In many cases, it's
sufficient to just create an empty dhclient.conf file -
the defaults are usually fine.
SSEEEE AALLSSOO
dhcp-options(5), dhclient.leases(5), dhcpd(8),
dhcpd.conf(5), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com>
under a contract with Vixie Labs. Funding for this pro<72>
ject was provided by the Internet Software Consortium.
Information about the Internet Software Consortium can be
found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
10

66
client/dhclient.leases.cat5
View File

@@ -1,66 +0,0 @@
dhclient.leases(5) dhclient.leases(5)
NNAAMMEE
dhclient.leases - DHCP client lease database
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP client keeps a per<65>
sistent database of leases that it has acquired that are
still valid. The database is a free-form ASCII file con<6F>
taining one valid declaration per lease. If more than
one declaration appears for a given lease, the last one in
the file is used. The file is written as a log, so this
is not an unusual occurrance.
The format of the lease declarations is described in
ddhhcclliieenntt..ccoonnff((55))..
FFIILLEESS
//vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess
SSEEEE AALLSSOO
dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8),
dhcpd.conf(5), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com>
under a contract with Vixie Labs. Funding for this pro<72>
ject was provided by the Internet Software Consortium.
Information about the Internet Software Consortium can be
found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
1