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

Sanitize Solaris build.

Browse Source
This commit is contained in:
Ted Lemon
1999-03-16 06:37:55 +00:00
parent b2f506592a
commit c5b0f52958
22 changed files with 2239 additions and 2234 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
client/clparse.c
View File

@@ -22,7 +22,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: clparse.c,v 1.27 1999/03/16 05:50:29 mellon Exp $ Copyright (c) 1997 The Internet Software Consortium. All rights reserved.\n"; "$Id: clparse.c,v 1.28 1999/03/16 06:37:47 mellon Exp $ Copyright (c) 1997 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -73,7 +73,7 @@ int read_client_conf ()
top_level_config.retry_interval = 300; top_level_config.retry_interval = 300;
top_level_config.backoff_cutoff = 120; top_level_config.backoff_cutoff = 120;
top_level_config.initial_interval = 10; top_level_config.initial_interval = 10;
top_level_config.bootp_policy = ACCEPT; top_level_config.bootp_policy = P_ACCEPT;
top_level_config.script_name = "/etc/dhclient-script"; top_level_config.script_name = "/etc/dhclient-script";
top_level_config.requested_options = default_requested_options; top_level_config.requested_options = default_requested_options;
top_level_config.requested_lease = 7200; top_level_config.requested_lease = 7200;

368
client/dhclient-script.cat8
View File

@@ -1,241 +1,222 @@
dhclient(8) dhclient(8) Maintenance Procedures dhclient(8)
NNAAMMEE
dhclient-script - DHCP client network configuration script NNNNAAAAMMMMEEEE
dhclient-script - DHCP client network configuration script
DDEESSCCRRIIPPTTIIOONN
The DHCP client network configuration script is invoked DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
from time to time by ddhhcclliieenntt((88)). This script is used by The DHCP client network configuration script is invoked from
the dhcp client to set each interface's initial configura<72> time to time by ddddhhhhcccclllliiiieeeennnntttt((((8888)))). This script is used by the
tion prior to requesting an address, to test the address dhcp client to set each interface's initial configuration
once it has been offered, and to set the interface's final prior to requesting an address, to test the address once it
configuration once a lease has been acquired. If no lease has been offered, and to set the interface's final confi-
is acquired, the script is used to test predefined leases, guration once a lease has been acquired. If no lease is
if any, and also called once if no valid lease can be acquired, the script is used to test predefined leases, if
identified. any, and also called once if no valid lease can be identi-
fied.
This script is not meant to be customized by the end user.
However, the script may not work on particular versions of This script is not meant to be customized by the end user.
particular operating systems (indeed, no standard script However, the script may not work on particular versions of
exists for some operating systems), so a pioneering user particular operating systems (indeed, no standard script
may well need to create a new script or modify an existing exists for some operating systems), so a pioneering user may
one. In general, customizations specific to a particular well need to create a new script or modify an existing one.
computer should be done in the //eettcc//ddhhcclliieenntt..ccoonnff script. In general, customizations specific to a particular computer
If you find that you can't make such a customization with<74> should be done in the ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff script. If you
out customizing dhclient.conf, please submit a bug report. find that you can't make such a customization without cus-
tomizing dhclient.conf, please submit a bug report.
OOPPEERRAATTIIOONN
When dhclient needs to invoke the client configuration OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN
script, it writes a shell script into /tmp which defines a When dhclient needs to invoke the client configuration
variety of variables. In all cases, $reason is set to the script, it writes a shell script into /tmp which defines a
name of the reason why the script has been invoked. The variety of variables. In all cases, $reason is set to the
following reasons are currently defined: MEDIUM, PREINIT, name of the reason why the script has been invoked. The
BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL and TIMEOUT. following reasons are currently defined: MEDIUM, PREINIT,
BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL and TIMEOUT.
MMMMEEEEDDDDIIIIUUUUMMMM
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.
MMEEDDIIUUMM PPPPRRRREEEEIIIINNNNIIIITTTT
The DHCP client is requesting that an interface's media The DHCP client is requesting that an interface be config-
type be set. The interface name is passed in $interface, ured as required in order to send packets prior to receiving
and the media type is passed in $medium. 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 giving it
an IP address at all. The interface name is passed in
$interface, and the media type in $medium.
PPRREEIINNIITT If an IP alias has been declared in dhclient.conf, its
The DHCP client is requesting that an interface be config<69> address will be passed in $alias_ip_address, and that ip
ured as required in order to send packets prior to receiv<69> alias should be deleted from the interface, along with any
ing an actual address. For clients which use the BSD routes to it.
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.
1
dhclient(8) dhclient(8)
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 param<61>
eters 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.
SunOS 5.6 Last change: 1
2
dhclient(8) dhclient(8) Maintenance Procedures dhclient(8)
RREEBBOOOOTT
The DHCP client has successfully reacquired its old
address after a reboot. This can be processed as with
BOUND.
EEXXPPIIRREE BBBBOOOOUUUUNNNNDDDD
The DHCP client has failed to renew its lease or acquire a The DHCP client has done an initial binding to a new
new one, and the lease has expired. The IP address must address. The new ip address is passed in $new_ip_address,
be relinquished, and all related parameters should be and the interface name is passed in $interface. The media
deleted, as in RENEW and REBIND. type is passed in $medium. Any options acquired from the
server are passed using the option name described in ddddhhhhccccpppp----
ooooppppttttiiiioooonnnnssss, except that dashes ('-') are replaced by under-
scores ('_') 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.
FFAAIILL Before actually configuring the address, dhclient-script
The DHCP client has been unable to contact any DHCP should somehow ARP for it and exit with a nonzero status if
servers, and any leases that have been tested have not it receives a reply. In this case, the client will send a
proved to be valid. The parameters from the last lease DHCPDECLINE message to the server and acquire a different
tested should be deconfigured. This can be handled in address. This may also be done in the RENEW, REBIND, or
the same way as EXPIRE. REBOOT states, but is not required, and indeed may not be
desirable.
When a binding has been completed, a lot of network parame-
ters 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.
TTIIMMEEOOUUTT If an IP alias has been declared, it must be set up here.
The DHCP client has been unable to contact any DHCP The alias IP address will be written as $alias_ip_address,
servers. However, an old lease has been identified, and and other DHCP options that are set for the alias (e.g.,
its parameters have been passed in as with BOUND. The subnet mask) will be passed in variables named as described
client configuration script should test these parameters previously except starting with $alias_ instead of $new_.
and, if it has reason to believe they are valid, should Care should be taken that the alias IP address not be used
exit with a value of zero. If not, it should exit with a if it is identical to the bound IP address
nonzero value. ($new_ip_address), since the other alias parameters may be
incorrect in this case.
The usual way to test a lease is to set up the network as RRRREEEENNNNEEEEWWWW
with REBIND (since this may be called to test more than When a binding has been renewed, the script is called as in
one lease) and then ping the first router defined in BOUND, except that in addition to all the variables starting
$routers. If a response is received, the lease must be with $new_, there is another set of variables starting with
valid for the network to which the interface is currently $old_. Persistent settings that may have changed need to be
connected. It would be more complete to try to ping all deleted - for example, if a local route to the bound address
of the routers listed in $new_routers, as well as those is being configured, the old local route should be deleted.
listed in $new_static_routes, but current scripts do not If the default route has changed, the old default route
do this. should be deleted. If the static routes have changed, the
old ones should be deleted. Otherwise, processing can be
done as with BOUND.
FFIILLEESS RRRREEEEBBBBIIIINNNNDDDD
Each operating system should generally have its own script The DHCP client has rebound to a new DHCP server. This can
file, although the script files for similar operating sys<79> be handled as with RENEW, except that if the IP address has
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
SunOS 5.6 Last change: 2
3
dhclient(8) dhclient(8) Maintenance Procedures dhclient(8)
servers is valid, this shouldn't cause any real problems,
but it could be confusing.
SSEEEE AALLSSOO changed, the ARP table should be cleared.
dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and
dhclient.leases(5).
AAUUTTHHOORR RRRREEEEBBBBOOOOOOOOTTTT
ddhhcclliieenntt--ssccrriipptt((88)) has been written for the Internet Soft<66> The DHCP client has successfully reacquired its old address
ware Consortium by Ted Lemon <mellon@fugue.com> in cooper<65> after a reboot. This can be processed as with BOUND.
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..
EEEEXXXXPPPPIIIIRRRREEEE
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.
FFFFAAAAIIIILLLL
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.
TTTTIIIIMMMMEEEEOOOOUUUUTTTT
The DHCP client has been unable to contact any DHCP servers.
However, an old lease has been identified, and its parame-
ters have been passed in as with BOUND. The client confi-
guration 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.
FFFFIIIILLLLEEEESSSS
Each operating system should generally have its own script
file, although the script files for similar operating sys-
tems may be similar or even identical. The script files
included in the Internet Software Consortium DHCP distribu-
tion appear in the distribution tree under client/scripts,
and bear the names of the operating systems on which they
are intended to work.
BBBBUUUUGGGGSSSS
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 con-
figured, /etc/resolv.conf will be repeatedly initialized to
the values provided by one server, and then the other.
SunOS 5.6 Last change: 3
Maintenance Procedures dhclient(8)
Assuming the information provided by both servers is valid,
this shouldn't cause any real problems, but it could be
confusing.
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and
dhclient.leases(5).
AAAAUUUUTTTTHHHHOOOORRRR
ddddhhhhcccclllliiiieeeennnntttt----ssssccccrrrriiiipppptttt((((8888)))) 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 hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To
learn more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm....
@@ -259,6 +240,25 @@ AAUUTTHHOORR
4
SunOS 5.6 Last change: 4

220
client/dhclient.cat8
View File

@@ -1,159 +1,156 @@
dhclient(8) dhclient(8) Maintenance Procedures dhclient(8)
NNAAMMEE
dhclient - Dynamic Host Configuration Protocol Client
SSYYNNOOPPSSIISS
ddhhcclliieenntt [ --pp _p_o_r_t ] [ --dd ] [ _i_f_0 [ _._._._i_f_N ] ]
DDEESSCCRRIIPPTTIIOONN NNNNAAAAMMMMEEEE
The Internet Software Consortium DHCP Client, dhclient, dhclient - Dynamic Host Configuration Protocol Client
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 SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
The DHCP protocol allows a host to contact a central ddddhhhhcccclllliiiieeeennnntttt [ ----pppp _p_o_r_t ] [ ----dddd ] [ _i_f_0 [ ..._i_f_N ] ]
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> DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
ration instructions. It then gets a list of all the net<65> The Internet Software Consortium DHCP Client, dhclient, pro-
work interfaces that are configured in the current system. vides a means for configuring one or more network interfaces
For each interface, it attempts to configure the interface using the Dynamic Host Configuration Protocol, BOOTP proto-
using the DHCP protocol. col, or if these protocols fail, by statically assigning an
address.
In order to keep track of leases across system reboots and OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN
server restarts, dhclient keeps a list of leases it has The DHCP protocol allows a host to contact a central server
been assigned in the dhclient.leases(5) file. On which maintains a list of IP addresses which may be assigned
startup, after reading the dhclient.conf file, dhclient on one or more subnets. A DHCP client may request an
reads the dhclient.leases file to refresh its memory about address from this pool, and then use it on a temporary basis
what leases it has been assigned. for communication on network. The DHCP protocol also pro-
vides 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.
When a new lease is acquired, it is appended to the end of On startup, dhclient reads the _d_h_c_l_i_e_n_t._c_o_n_f for configura-
the dhclient.leases file. In order to prevent the file tion instructions. It then gets a list of all the network
from becoming arbitrarily large, from time to time interfaces that are configured in the current system. For
dhclient creates a new dhclient.leases file from its in- each interface, it attempts to configure the interface using
core lease database. The old version of the the DHCP protocol.
dhclient.leases file is retained under the name
_d_h_c_p_d_._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 In order to keep track of leases across system reboots and
unavailable when dhclient is first invoked (generally dur<75> server restarts, dhclient keeps a list of leases it has been
ing the initial system boot process). In that event, old assigned in the dhclient.leases(5) file. On startup, after
leases from the dhclient.leases file which have not yet reading the dhclient.conf file, dhclient reads the
expired are tested, and if they are determined to be dhclient.leases file to refresh its memory about what leases
valid, they are used until either they expire or the DHCP it has been assigned.
server becomes available.
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_p_d._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 una-
vailable when dhclient is first invoked (generally during
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 server
becomes available.
1
SunOS 5.6 Last change: 1
dhclient(8) dhclient(8)
A mobile host which may sometimes need to access a network Maintenance Procedures dhclient(8)
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 identify all network interfaces, elimininat<61>
ing non-broadcast interfaces if possible, and attempt to
configure each interface.
If dhclient should listen and transmit on a port other A mobile host which may sometimes need to access a network
than the standard (port 68), the --pp flag may used. It on which no DHCP server exists may be preloaded with a lease
should be followed by the udp port number that dhclient for a fixed address on that network. When all attempts to
should use. This is mostly useful for debugging purposes. 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.
Dhclient will normally run in the foreground until it has A mobile host may also travel to some networks on which DHCP
configured an interface, and then will revert to running is not available but BOOTP is. In that case, it may be
in the background. To run force dhclient to always run as advantageous to arrange with the network administrator for
a foreground process, the --dd flag should be specified. an entry on the BOOTP database, so that the host can boot
This is useful when running dhclient under a debugger, or quickly on that network rather than cycling through the list
when running it out of inittab on System V systems. of old leases.
CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE
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 identify all network interfaces, elimininating
non-broadcast interfaces if possible, and attempt to config-
ure each interface.
CCOONNFFIIGGUURRAATTIIOONN If dhclient should listen and transmit on a port other than
The syntax of the dhclient.conf(8) file is discussed the standard (port 68), the ----pppp flag may used. It should be
seperately. followed by the udp port number that dhclient should use.
This is mostly useful for debugging purposes.
FFIILLEESS Dhclient will normally run in the foreground until it has
//eettcc//ddhhcclliieenntt..ccoonnff,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess,, configured an interface, and then will revert to running in
//vvaarr//rruunn//ddhhcclliieenntt..ppiidd,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess~~.. the background. To run force dhclient to always run as a
foreground process, the ----dddd flag should be specified. This
is useful when running dhclient under a debugger, or when
running it out of inittab on System V systems.
SSEEEE AALLSSOO CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
dhcpd(8), dhcrelay(8), dhclient.conf(5), The syntax of the dhclient.conf(8) file is discussed
dhclient.leases(5) seperately.
AAUUTTHHOORR FFFFIIIILLLLEEEESSSS
ddhhcclliieenntt((88)) has been written for the Internet Software ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff,,,, ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss,,,, ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ppppiiiidddd,,,,
Consortium by Ted Lemon <mellon@fugue.com> in cooperation ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss~~~~....
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..
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhcpd(8), dhcrelay(8), dhclient.conf(5), dhclient.leases(5)
AAAAUUUUTTTTHHHHOOOORRRR
ddddhhhhcccclllliiiieeeennnntttt((((8888)))) has been written for the Internet Software Con-
sortium by Ted Lemon <mellon@fugue.com> in cooperation with
Vixie Enterprises. To learn more about the Internet
Software Consortium, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To learn
more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm....
2
SunOS 5.6 Last change: 2
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> Maintenance Procedures dhclient(8)
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.
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-
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 main-
tain system-specific configuration code to these operating
systems - instead, the shell script can invoke the native
tools to accomplish the same purpose.
@@ -189,10 +186,13 @@ dhclient(8) dhclient(8)
SunOS 5.6 Last change: 3
3

792
client/dhclient.conf.cat5
View File

@@ -1,594 +1,594 @@
dhclient.conf(5) dhclient.conf(5) Headers, Environments, and Macros dhclient.conf(5)
NNAAMMEE
dhclient.conf - DHCP client configuration file
DDEESSCCRRIIPPTTIIOONN NNNNAAAAMMMMEEEE
The dhclient.conf file contains configuration information dhclient.conf - DHCP client configuration file
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. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
It is parsed by the recursive-descent parser built into The dhclient.conf file contains configuration information
dhclient. The file may contain extra tabs and newlines for _d_h_c_l_i_e_n_t, the Internet Software Consortium DHCP Client.
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 The dhclient.conf file is a free-form ASCII text file. It
behaviour of the client in a wide variety of ways: proto<EFBFBD> is parsed by the recursive-descent parser built into
col timing, information requested from the server, infor<EFBFBD> dhclient. The file may contain extra tabs and newlines for
mation required of the server, defaults to use if the formatting purposes. Keywords in the file are case-
server does not provide certain information, values with insensitive. Comments may be placed anywhere within the
which to override information provided by the server, or file (except within quotes). Comments begin with the #
values to prepend or append to information provided by the character and end at the end of the line.
server. The configuration file can also be preinitialized
with addresses to use on networks that don't have DHCP
servers.
PPRROOTTOOCCOOLL TTIIMMIINNGG The dhclient.conf file can be used to configure the
The timing behaviour of the client need not be configured behaviour of the client in a wide variety of ways: protocol
by the user. If no timing configuration is provided by timing, information requested from the server, information
the user, a fairly reasonable timing behaviour will be required of the server, defaults to use if the server does
used by default - one which results in fairly timely not provide certain information, values with which to over-
updates without placing an inordinate load on the server. ride 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.
The following statements can be used to adjust the timing PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTIIIIMMMMIIIINNNNGGGG
behaviour of the DHCP client if required, however: 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.
_T_h_e ttiimmeeoouutt _s_t_a_t_e_m_e_n_t The following statements can be used to adjust the timing
behaviour of the DHCP client if required, however:
ttiimmeeoouutt _t_i_m_e ;; _T_h_e ttttiiiimmmmeeeeoooouuuutttt _s_t_a_t_e_m_e_n_t
The _t_i_m_e_o_u_t statement determines the amount of time that ttttiiiimmmmeeeeoooouuuutttt _t_i_m_e ;;;;
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.
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 timeout 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
SunOS 5.6 Last change: 1
dhclient.conf(5) dhclient.conf(5)
_T_h_e rreettrryy _s_t_a_t_e_m_e_n_t Headers, Environments, and Macros dhclient.conf(5)
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 _T_h_e rrrreeeettttrrrryyyy _s_t_a_t_e_m_e_n_t
sseelleecctt--ttiimmeeoouutt _t_i_m_e;; rrrreeeettttrrrryyyy _t_i_m_e;;;;
It is possible (some might say desirable) for there to be The _r_e_t_r_y statement determines the time that must pass after
more than one DHCP server serving any given network. In the client has determined that there is no DHCP server
this case, it is possible that a client may be sent more present before it tries again to contact a DHCP server. By
than one offer in response to its initial lease discovery default, this is five minutes.
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 _T_h_e sssseeeelllleeeecccctttt----ttttiiiimmmmeeeeoooouuuutttt _s_t_a_t_e_m_e_n_t
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, sssseeeelllleeeecccctttt----ttttiiiimmmmeeeeoooouuuutttt _t_i_m_e;;;;
the client will take the first offer it sees.
_T_h_e rreebboooott _s_t_a_t_e_m_e_n_t 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 preferable
to the other (e.g., one offer may have the address the
client previously used, and the other may not).
rreebboooott _t_i_m_e;; 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.
When the client is restarted, it first tries to reacquire By default, the select-timeout is zero seconds - that is,
the last address it had. This is called the INIT-REBOOT the client will take the first offer it sees.
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 _T_h_e rrrreeeebbbbooooooootttt _s_t_a_t_e_m_e_n_t
bbaacckkooffff--ccuuttooffff _t_i_m_e;; rrrreeeebbbbooooooootttt _t_i_m_e;;;;
The client uses an exponential backoff algorithm with some When the client is restarted, it first tries to reacquire
randomness, so that if many clients try to configure them<65> the last address it had. This is called the INIT-REBOOT
selves at the same time, they will not make their requests state. If it is still attached to the same network it was
in lockstep. The _b_a_c_k_o_f_f_-_c_u_t_o_f_f statement determines the attached to when it last ran, this is the quickest way to
maximum amount of time that the client is allowed to back get started. The _r_e_b_o_o_t statement sets the time that must
off. It defaults to two minutes. 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 bbbbaaaacccckkkkooooffffffff----ccccuuuuttttooooffffffff _s_t_a_t_e_m_e_n_t
bbbbaaaacccckkkkooooffffffff----ccccuuuuttttooooffffffff _t_i_m_e;;;;
2 The client uses an exponential backoff algorithm with some
randomness, so that if many clients try to configure them-
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
SunOS 5.6 Last change: 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 Headers, Environments, and Macros dhclient.conf(5)
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 maximum amount of time that the client is allowed to back
off. It defaults to two minutes.
rreeqquueesstt [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n ];; _T_h_e iiiinnnniiiittttiiiiaaaallll----iiiinnnntttteeeerrrrvvvvaaaallll _s_t_a_t_e_m_e_n_t
The request statement causes the client to request that iiiinnnniiiittttiiiiaaaallll----iiiinnnntttteeeerrrrvvvvaaaallll _t_i_m_e;;;;
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.
_T_h_e rreeqquuiirree _s_t_a_t_e_m_e_n_t 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 seconds.
rreeqquuiirree [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _];; LLLLEEEEAAAASSSSEEEE RRRREEEEQQQQUUUUIIIIRRRREEEEMMMMEEEENNNNTTTTSSSS AAAANNNNDDDD RRRREEEEQQQQUUUUEEEESSSSTTTTSSSS
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 proto-
col 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.
The require statement lists options that must be sent in There is a variety of data contained in offers that DHCP
order for an offer to be accepted. Offers that do not servers send to DHCP clients. The data that can be specifi-
contain all the listed options will be ignored. cally requested is what are called _D_H_C_P _O_p_t_i_o_n_s. DHCP
Options are defined in
ddddhhhhccccpppp----ooooppppttttiiiioooonnnnssss((((5555)))).
_T_h_e sseenndd _s_t_a_t_e_m_e_n_t _T_h_e rrrreeeeqqqquuuueeeesssstttt _s_t_a_t_e_m_e_n_t
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 rrrreeeeqqqquuuueeeesssstttt [[[[ _o_p_t_i_o_n ] [,,,, ... _o_p_t_i_o_n ];;;;
]}}
The send statement causes the client to send the specified The request statement causes the client to request that any
options to the server with the specified values. These server responding to the client send the client its values
are full option declarations as described in ddhhccpp-- for the specified options. Only the option names should be
ooppttiioonnss((55)). Options that are always sent in the DHCP specified in the request statement - not option parameters.
_T_h_e rrrreeeeqqqquuuuiiiirrrreeee _s_t_a_t_e_m_e_n_t
rrrreeeeqqqquuuuiiiirrrreeee [[[[ _o_p_t_i_o_n ] [,,,, ... _o_p_t_i_o_n ];;;;
3 The require statement lists options that must be sent in
order for an offer to be accepted. Offers that do not con-
tain all the listed options will be ignored.
_T_h_e sssseeeennnndddd _s_t_a_t_e_m_e_n_t
sssseeeennnndddd {{{{ [[[[ _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
dhclient.conf(5) dhclient.conf(5)
SunOS 5.6 Last change: 3
protocol 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 infor<6F>
mation 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 Headers, Environments, and Macros dhclient.conf(5)
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 full option declarations as described in ddddhhhhccccpppp----ooooppppttttiiiioooonnnnssss((((5555)))).
Options that are always sent in the DHCP protocol should not
be specified here, except that the client can specify a
rrrreeeeqqqquuuueeeesssstttteeeedddd----lllleeeeaaaasssseeee----ttttiiiimmmmeeee option other than the default requested
lease time, which is two hours. The other obvious use for
this statement is to send information to the server that
will allow it to differentiate between this client and other
clients or kinds of clients.
pprreeppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; OOOOPPPPTTTTIIIIOOOONNNN MMMMOOOODDDDIIIIFFFFIIIIEEEERRRRSSSS
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 informa-
tion which is useful, but which needs to be supplemented
with local information. To handle these needs, several
option modifiers are available.
If for some option the client should use both a value it _T_h_e ddddeeeeffffaaaauuuulllltttt _s_t_a_t_e_m_e_n_t
supplies, and then any values supplied by the server,
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.
_T_h_e aappppeenndd _s_t_a_t_e_m_e_n_t ddddeeeeffffaaaauuuulllltttt [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;;;
aappppeenndd [[ _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 supplied
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 ddddeeeeffffaaaauuuulllltttt statement.
If for some option the client should first any values sup<75> _T_h_e ssssuuuuppppeeeerrrrsssseeeeddddeeee _s_t_a_t_e_m_e_n_t
plied to it by the server, and then some values it sup<75>
plies, those values should be defined in the aappppeenndd state<74>
ment. The aappppeenndd statement can only be used for options
which allow more than one value to be given.
ssssuuuuppppeeeerrrrsssseeeeddddeeee [[[[ _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 supplied
by the server, these values can be defined in the ssssuuuuppppeeeerrrrsssseeeeddddeeee
statement.
_T_h_e pppprrrreeeeppppeeeennnndddd _s_t_a_t_e_m_e_n_t
4 pppprrrreeeeppppeeeennnndddd [[[[ _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 both a value it
supplies, and then any values supplied by the server, these
values can be defined in the pppprrrreeeeppppeeeennnndddd statement. The
pppprrrreeeeppppeeeennnndddd statement can only be used for options which allow
more than one value to be given.
_T_h_e aaaappppppppeeeennnndddd _s_t_a_t_e_m_e_n_t
aaaappppppppeeeennnndddd [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;;;
If for some option the client should first any values sup-
plied to it by the server, and then some values it supplies,
dhclient.conf(5) dhclient.conf(5)
LLEEAASSEE DDEECCLLAARRAATTIIOONNSS SunOS 5.6 Last change: 4
_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 Headers, Environments, and Macros dhclient.conf(5)
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
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;; those values should be defined in the aaaappppppppeeeennnndddd statement.
The aaaappppppppeeeennnndddd statement can only be used for options which
allow more than one value to be given.
The ffiixxeedd--aaddddrreessss statement is used to set the ip address LLLLEEEEAAAASSSSEEEE DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS
of a particular lease. This is required for all lease _T_h_e lllleeeeaaaasssseeee _d_e_c_l_a_r_a_t_i_o_n
statements. The IP address must be specified as a dotted
quad (e.g., 12.34.56.78).
lllleeeeaaaasssseeee {{{{ _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
PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTIIIIMMMMIIIINNNNGGGG) 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 net-
works where there is no DHCP or BOOTP service, so that the
client can still automatically configure its address. This
is done with the lllleeeeaaaasssseeee 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.
5 A lease statement consists of the lease keyword, followed by
a left curly brace, followed by one or more lease declara-
tion statements, followed by a right curly brace. The fol-
lowing lease declarations are possible:
bbbboooooooottttpppp;;;;
The bbbboooooooottttpppp statement is used to indicate that the lease was
acquired using the BOOTP protocol rather than the DHCP pro-
tocol. It is never necessary to specify this in the client
configuration file. The client uses this syntax in its
lease database file.
iiiinnnntttteeeerrrrffffaaaacccceeee """"_s_t_r_i_n_g"""";;;;
The iiiinnnntttteeeerrrrffffaaaacccceeee lease statement is used to indicate the inter-
face 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 inter-
face number on which it received that lease. If predefined
leases are specified in the dhclient.conf file, the inter-
face should also be specified, although this is not
required.
dhclient.conf(5) dhclient.conf(5)
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"";; SunOS 5.6 Last change: 5
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--lleeaassee((88))..
mmeeddiiuumm ""_m_e_d_i_a _s_e_t_u_p"";; Headers, Environments, and Macros dhclient.conf(5)
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.
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;; ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss _i_p-_a_d_d_r_e_s_s;;;;
rreebbiinndd _d_a_t_e;; The ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss statement is used to set the ip address of
a particular lease. This is required for all lease state-
ments. The IP address must be specified as a dotted quad
(e.g., 12.34.56.78).
ffffiiiilllleeeennnnaaaammmmeeee """"_s_t_r_i_n_g"""";;;;
The ffffiiiilllleeeennnnaaaammmmeeee 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.
sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee """"_s_t_r_i_n_g"""";;;;
6 The sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee statement specifies the name of the boot
server name to use. This is also not used by the standard
client configuration script.
ooooppppttttiiiioooonnnn _o_p_t_i_o_n-_d_e_c_l_a_r_a_t_i_o_n;;;;
The ooooppppttttiiiioooonnnn statement is used to specify the value of an
option supplied by the server, or, in the case of predefined
leases declared in dhclient.conf, the value that the user
wishes the client configuration script to use if the prede-
fined lease is used.
ssssccccrrrriiiipppptttt """"_s_c_r_i_p_t-_n_a_m_e"""";;;;
The ssssccccrrrriiiipppptttt 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 configura-
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 iden-
tified. For more information, see ddddhhhhcccclllliiiieeeennnntttt----lllleeeeaaaasssseeee((((8888))))....
dhclient.conf(5) dhclient.conf(5) mmmmeeeeddddiiiiuuuummmm """"_m_e_d_i_a _s_e_t_u_p"""";;;;
The mmmmeeeeddddiiiiuuuummmm statement can be used on systems where network
interfaces cannot automatically determine the type of net-
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.
eexxppiirree _d_a_t_e;; The dhcp client automatically declares this parameter if it
used a media type (see the mmmmeeeeddddiiiiaaaa statement) when configuring
the interface in order to obtain a lease. This statement
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: SunOS 5.6 Last change: 6
_<_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.
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.
Headers, Environments, and Macros dhclient.conf(5)
7 should be used in predefined leases only if the network
interface requires media type configuration.
rrrreeeennnneeeewwww _d_a_t_e;;;;
rrrreeeebbbbiiiinnnndddd _d_a_t_e;;;;
eeeexxxxppppiiiirrrreeee _d_a_t_e;;;;
The rrrreeeennnneeeewwww 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 rrrreeeebbbbiiiinnnndddd 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 eeeexxxxppppiiiirrrreeee
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.
dhclient.conf(5) dhclient.conf(5) These declarations are automatically set in leases acquired
by the DHCP client, but must also be configured in prede-
fined leases - a predefined lease whose expiry time has
passed will not be used by the DHCP client.
Dates are specified as follows:
OOTTHHEERR DDEECCLLAARRAATTIIOONNSS <_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>
rreejjeecctt _i_p_-_a_d_d_r_e_s_s;;
The reject statement causes the DHCP client to reject The weekday is present to make it easy for a human to tell
offers from servers who use the specified address as a when a lease expires - it's specified as a number from zero
server identifier. This can be used to avoid being con<6F> to six, with zero being Sunday. When declaring a predefined
figured by rogue or misconfigured dhcp servers, although lease, it can always be specified as zero. The year is
it should be a last resort - better to track down the bad specified with the century, so it should generally be four
DHCP server and fix it. digits except for really long leases. The month is speci-
fied 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.
iinntteerrffaaccee ""_n_a_m_e"" {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }} AAAALLLLIIIIAAAASSSS DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS
aaaalllliiiiaaaassss {{{{ _d_e_c_l_a_r_a_t_i_o_n_s ... }}}}
A client with more than one network interface may require Some DHCP clients running TCP/IP roaming protocols may
different behaviour depending on which interface is being require that in addition to the lease they may acquire via
configured. All timing parameters and declarations other DHCP, their interface also be configured with a predefined
than lease and alias declarations can be enclosed in an IP alias so that they can have a permanent IP address even
interface declaration, and those parameters will then be while roaming. The Internet Software Consortium DHCP
used only for the interface that matches the specified client doesn't support roaming with fixed addresses
name. Interfaces for which there is no interface decla<6C> directly, but in order to facilitate such experimentation,
ration will use the parameters declared outside of any the dhcp client can be set up to configure an IP alias using
interface declaration, or the default settings. the aaaalllliiiiaaaassss declaration.
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.
SunOS 5.6 Last change: 7
8
Headers, Environments, and Macros dhclient.conf(5)
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 declaration for the
IP alias address, and a subnet-mask option declaration. A
medium statement should never be included in an alias
declaration.
OOOOTTTTHHHHEEEERRRR DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS
rrrreeeejjjjeeeecccctttt _i_p-_a_d_d_r_e_s_s;;;;
timeout 60; The reject statement causes the DHCP client to reject offers
retry 60; from servers who use the specified address as a server iden-
reboot 10; tifier. This can be used to avoid being configured by
select-timeout 5; rogue or misconfigured dhcp servers, although it should be a
initial-interval 2; last resort - better to track down the bad DHCP server and
reject 192.33.137.209; fix it.
interface "ep0" { iiiinnnntttteeeerrrrffffaaaacccceeee """"_n_a_m_e"""" {{{{ _d_e_c_l_a_r_a_t_i_o_n_s ... }}}}
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;
script "/etc/dhclient-script";
media "media 10baseT/UTP", "media 10base2/BNC";
}
alias { A client with more than one network interface may require
interface "ep0"; different behaviour depending on which interface is being
fixed-address 192.5.5.213; configured. All timing parameters and declarations other
option subnet-mask 255.255.255.255; than lease and alias declarations can be enclosed in an
} interface declaration, and those parameters will then be
This is a very complicated dhclient.conf file - in gen<65> used only for the interface that matches the specified name.
eral, yours should be much simpler. In many cases, it's Interfaces for which there is no interface declaration will
sufficient to just create an empty dhclient.conf file - use the parameters declared outside of any interface
the defaults are usually fine. declaration, or the default settings.
SSEEEE AALLSSOO mmmmeeeeddddiiiiaaaa """"_m_e_d_i_a _s_e_t_u_p"""" [ ,,,, """"_m_e_d_i_a _s_e_t_u_p"""",,,, ... ];;;;
dhcp-options(5), dhclient.leases(5), dhcpd(8),
dhcpd.conf(5), RFC2132, RFC2131.
AAUUTTHHOORR The mmmmeeeeddddiiiiaaaa statement defines one or more media configuration
ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com> parameters which may be tried while attempting to acquire an
under a contract with Vixie Labs. Funding for this pro<72> IP address. The dhcp client will cycle through each media
ject was provided by the Internet Software Consortium. setup string on the list, configuring the interface using
Information about the Internet Software Consortium can be that setup and attempting to boot, and then trying the next
found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. 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
packtes). 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.
SunOS 5.6 Last change: 8
Headers, Environments, and Macros dhclient.conf(5)
SSSSAAAAMMMMPPPPLLLLEEEE
The following configuration file is used on a laptop running
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;
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 general,
yours should be much simpler. In many cases, it's suffi-
cient to just create an empty dhclient.conf file - the
defaults are usually fine.
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhcp-options(5), dhclient.leases(5), dhcpd(8),
dhcpd.conf(5), RFC2132, RFC2131.
AAAAUUUUTTTTHHHHOOOORRRR
ddddhhhhcccclllliiiieeeennnntttt((((8888)))) was written by Ted Lemon <mellon@vix.com> under
a contract with Vixie Labs. Funding for this project was
provided by the Internet Software Consortium. Information
about the Internet Software Consortium can be found at
hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc....
SunOS 5.6 Last change: 9
9

52
client/dhclient.leases.cat5
View File

@@ -1,37 +1,38 @@
dhclient.leases(5) dhclient.leases(5) Headers, Environments, and Macros dhclient.leases(5)
NNAAMMEE
dhclient.leases - DHCP client lease database
DDEESSCCRRIIPPTTIIOONN NNNNAAAAMMMMEEEE
The Internet Software Consortium DHCP client keeps a per<65> dhclient.leases - DHCP client lease database
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 DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
ddhhcclliieenntt..ccoonnff((55)).. The Internet Software Consortium DHCP client keeps a per-
sistent database of leases that it has acquired that are
still valid. The database is a free-form ASCII file con-
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.
FFIILLEESS The format of the lease declarations is described in
//vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff((((5555))))....
SSEEEE AALLSSOO FFFFIIIILLLLEEEESSSS
dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8), ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss
dhcpd.conf(5), RFC2132, RFC2131.
AAUUTTHHOORR SSSSEEEEEEEE AAAALLLLSSSSOOOO
ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com> dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8),
under a contract with Vixie Labs. Funding for this pro<72> dhcpd.conf(5), RFC2132, RFC2131.
ject was provided by the Internet Software Consortium.
Information about the Internet Software Consortium can be AAAAUUUUTTTTHHHHOOOORRRR
found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. ddddhhhhcccclllliiiieeeennnntttt((((8888)))) was written by Ted Lemon <mellon@vix.com> under
a contract with Vixie Labs. Funding for this project was
provided by the Internet Software Consortium. Information
about the Internet Software Consortium can be found at
hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc....
@@ -59,8 +60,7 @@ AAUUTTHHOORR
SunOS 5.6 Last change: 1
1

4
common/bpf.c
View File

@@ -22,7 +22,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: bpf.c,v 1.25 1999/03/16 05:50:31 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; "$Id: bpf.c,v 1.26 1999/03/16 06:37:48 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -274,7 +274,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
result = writev(interface -> wfdesc, iov, 2); result = writev(interface -> wfdesc, iov, 2);
if (result < 0) if (result < 0)
warn ("send_packet: %m"); log_error ("send_packet: %m");
return result; return result;
} }
#endif /* USE_BPF_SEND */ #endif /* USE_BPF_SEND */

4
common/dlpi.c
View File

@@ -108,7 +108,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: dlpi.c,v 1.8 1999/03/16 05:50:33 mellon Exp $ Copyright (c) 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; "$Id: dlpi.c,v 1.9 1999/03/16 06:37:48 mellon Exp $ Copyright (c) 1998, 1999 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
static int strioctl PROTO ((int fd, int cmd, int timeout, int len, char *dp)); static int strioctl PROTO ((int fd, int cmd, int timeout, int len, char *dp));
@@ -504,7 +504,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
0, 0, dbuf, dbuflen); 0, 0, dbuf, dbuflen);
#endif #endif
if (result < 0) if (result < 0)
warn ("send_packet: %m"); log_error ("send_packet: %m");
return result; return result;
} }
#endif /* USE_DLPI_SEND */ #endif /* USE_DLPI_SEND */

4
common/inet_addr.c
View File

@@ -43,7 +43,7 @@ static char rcsid[] = "$NetBSD: inet_addr.c,v 1.6 1996/02/02 15:22:23 mrg Exp $"
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: inet_addr.c,v 1.2 1997/03/29 10:37:51 mellon Exp $ Copyright (c) 1983, 1990, 1993 The Regents of the University of California. All rights reserved.\n"; "$Id: inet_addr.c,v 1.3 1999/03/16 06:37:49 mellon Exp $ Copyright (c) 1983, 1990, 1993 The Regents of the University of California. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -58,7 +58,7 @@ static char copyright[] =
*/ */
int int
inet_aton(cp, addr) inet_aton(cp, addr)
char *cp; const char *cp;
struct in_addr *addr; struct in_addr *addr;
{ {
register u_long val; register u_long val;

4
common/lpf.c
View File

@@ -23,7 +23,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: lpf.c,v 1.7 1999/03/16 05:50:34 mellon Exp $ Copyright (c) 1995, 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; "$Id: lpf.c,v 1.8 1999/03/16 06:37:49 mellon Exp $ Copyright (c) 1995, 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -202,7 +202,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
result = sendto (interface -> wfdesc, buf, bufp + len, 0, result = sendto (interface -> wfdesc, buf, bufp + len, 0,
&sa, sizeof sa); &sa, sizeof sa);
if (result < 0) if (result < 0)
warn ("send_packet: %m"); log_error ("send_packet: %m");
return result; return result;
} }
#endif /* USE_LPF_SEND */ #endif /* USE_LPF_SEND */

4
common/nit.c
View File

@@ -23,7 +23,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: nit.c,v 1.21 1999/03/16 05:50:35 mellon Exp $ Copyright (c) 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; "$Id: nit.c,v 1.22 1999/03/16 06:37:49 mellon Exp $ Copyright (c) 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -284,7 +284,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
result = putmsg (interface -> wfdesc, &ctl, &data, 0); result = putmsg (interface -> wfdesc, &ctl, &data, 0);
if (result < 0) if (result < 0)
warn ("send_packet: %m"); log_error ("send_packet: %m");
return result; return result;
} }
#endif /* USE_NIT_SEND */ #endif /* USE_NIT_SEND */

7
common/parse.c
View File

@@ -22,7 +22,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: parse.c,v 1.16 1999/03/16 05:50:36 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; "$Id: parse.c,v 1.17 1999/03/16 06:37:49 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -782,7 +782,7 @@ int parse_cshl (data, cfile)
struct data_string *data; struct data_string *data;
FILE *cfile; FILE *cfile;
{ {
char ibuf [128]; u_int8_t ibuf [128];
int ilen = 0; int ilen = 0;
int tlen = 0; int tlen = 0;
struct option_tag *sl = (struct option_tag *)0; struct option_tag *sl = (struct option_tag *)0;
@@ -1381,7 +1381,8 @@ int parse_non_binary (expr, cfile, lose, context)
case STRING: case STRING:
token = next_token (&val, cfile); token = next_token (&val, cfile);
if (!make_const_data (expr, val, strlen (val), 1, 1)) if (!make_const_data (expr, (unsigned char *)val,
strlen (val), 1, 1))
log_fatal ("can't make constant string expression."); log_fatal ("can't make constant string expression.");
break; break;

4
common/raw.c
View File

@@ -35,7 +35,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: raw.c,v 1.14 1999/03/16 05:50:36 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; "$Id: raw.c,v 1.15 1999/03/16 06:37:50 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -112,7 +112,7 @@ size_t send_packet (interface, packet, raw, len, from, to, hto)
result = writev(interface -> wfdesc, iov, 2); result = writev(interface -> wfdesc, iov, 2);
if (result < 0) if (result < 0)
warn ("send_packet: %m"); log_error ("send_packet: %m");
return result; return result;
} }
#endif /* USE_SOCKET_SEND */ #endif /* USE_SOCKET_SEND */

8
common/socket.c
View File

@@ -30,7 +30,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: socket.c,v 1.34 1999/03/16 05:50:37 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; "$Id: socket.c,v 1.35 1999/03/16 06:37:50 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -188,10 +188,10 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
retry++ < 10); retry++ < 10);
#endif #endif
if (result < 0) { if (result < 0) {
warn ("send_packet: %m"); log_error ("send_packet: %m");
if (errno == ENETUNREACH) if (errno == ENETUNREACH)
warn ("send_packet: please consult README file %s", log_error ("send_packet: please consult README file %s",
"regarding broadcast address."); "regarding broadcast address.");
} }
return result; return result;
} }

4
common/upf.c
View File

@@ -22,7 +22,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: upf.c,v 1.9 1999/03/16 05:50:38 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; "$Id: upf.c,v 1.10 1999/03/16 06:37:50 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -233,7 +233,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
result = writev(interface -> wfdesc, iov, 2); result = writev(interface -> wfdesc, iov, 2);
if (result < 0) if (result < 0)
warn ("send_packet: %m"); log_error ("send_packet: %m");
return result; return result;
} }
#endif /* USE_UPF_SEND */ #endif /* USE_UPF_SEND */

2
includes/dhcpd.h
View File

@@ -300,7 +300,7 @@ struct lease_state {
#endif #endif
#ifndef CL_DEFAULT_BOOTP_POLICY #ifndef CL_DEFAULT_BOOTP_POLICY
# define CL_DEFAULT_BOOTP_POLICY ACCEPT # define CL_DEFAULT_BOOTP_POLICY P_ACCEPT
#endif #endif
#ifndef CL_DEFAULT_SCRIPT_NAME #ifndef CL_DEFAULT_SCRIPT_NAME

3
includes/tree.h
View File

@@ -36,7 +36,7 @@ typedef struct _pair {
/* A data buffer with a reference count. */ /* A data buffer with a reference count. */
struct buffer { struct buffer {
int refcnt; int refcnt;
char data [1]; unsigned char data [1];
}; };
/* XXX The mechanism by which data strings are returned is currently /* XXX The mechanism by which data strings are returned is currently
@@ -125,7 +125,6 @@ struct data_string; /* forward */
struct packet; /* forward */ struct packet; /* forward */
struct option_state; /* forward */ struct option_state; /* forward */
struct decoded_option_state; /* forward */ struct decoded_option_state; /* forward */
enum statement_op; /* forward */
struct universe { struct universe {
char *name; char *name;

300
relay/dhcrelay.cat8
View File

@@ -1,218 +1,214 @@
dhcrelay(8) dhcrelay(8) Maintenance Procedures dhcrelay(8)
NNAAMMEE
dhcrelay - Dynamic Host Configuration Protocol Relay Agent
SSYYNNOOPPSSIISS
ddhhccrreellaayy [ --pp _p_o_r_t ] [ --dd ] [ --qq ] [ --ii _i_f_0 [ ...... --ii _i_f_N
] ] [ --aa ] [ --AA _l_e_n_g_t_h ] [ --DD ] [ --mm _a_p_p_e_n_d | _r_e_p_l_a_c_e |
_f_o_r_w_a_r_d | _d_i_s_c_a_r_d ] _s_e_r_v_e_r_0 [ _._._._s_e_r_v_e_r_N ]
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP Relay Agent, dhcre<72>
lay, provides a means for relaying DHCP and BOOTP requests
from a subnet to which no DHCP server is directly to one
or more DHCP servers on other subnets.
OOPPEERRAATTIIOONN
The DHCP Relay Agent listens for DHCP and BOOTP queries
and responses. When a query is received from a client,
dhcrelay forwards it to the list of DHCP servers specified
on the command line. When a reply is received from a
server, it is broadcast or unicast (according to the relay
agent's ability or the client's request) on the network
from which the original request came.
CCOOMMMMAANNDD LLIINNEE NNNNAAAAMMMMEEEE
The names of the network interfaces that dhcrelay should dhcrelay - Dynamic Host Configuration Protocol Relay Agent
attempt to configure may be specified on the command line
using the --ii option. If no interface names are specified
on the command line dhcrelay will identify all network
interfaces, elimininating non-broadcast interfaces if pos<6F>
sible, and attempt to configure each interface.
If a relay agent is running on a system that is connected SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
to one or more networks on which no DHCP servers are pre<72> ddddhhhhccccrrrreeeellllaaaayyyy [ ----pppp _p_o_r_t ] [ ----dddd ] [ ----qqqq ] [ ----iiii _i_f_0 [ ............ ----iiii _i_f_N ] ]
sent, and is also connected to one or more networks on [ ----aaaa ] [ ----AAAA _l_e_n_g_t_h ] [ ----DDDD ] [ ----mmmm _a_p_p_e_n_d | _r_e_p_l_a_c_e | _f_o_r_w_a_r_d
which DHCP servers _a_r_e connected, it is may not be helpful | _d_i_s_c_a_r_d ] _s_e_r_v_e_r_0 [ ..._s_e_r_v_e_r_N ]
for the relay agent to relay requests from those networks
on which a DHCP server already exists. To avoid such a
situation, the interfaces on which the relay agent should
listen should be specified with the --ii flag.
Note that in some cases it _i_s helpful for the relay agent DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
to forward requests from networks on which a DHCP server The Internet Software Consortium DHCP Relay Agent, dhcrelay,
is running to other DHCP servers. This would be the case provides a means for relaying DHCP and BOOTP requests from a
if two DHCP servers on different networks were being used subnet to which no DHCP server is directly to one or more
to provide backup service for each other's networks. DHCP servers on other subnets.
If dhcrelay should listen and transmit on a port other OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN
than the standard (port 67), the --pp flag may used. It The DHCP Relay Agent listens for DHCP and BOOTP queries and
should be followed by the udp port number that dhcrelay responses. When a query is received from a client, dhcrelay
should use. This is mostly useful for debugging purposes. forwards it to the list of DHCP servers specified on the
command line. When a reply is received from a server, it is
broadcast or unicast (according to the relay agent's ability
or the client's request) on the network from which the ori-
ginal request came.
Dhcrelay will normally run in the foreground until it has CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE
configured an interface, and then will revert to running The names of the network interfaces that dhcrelay should
in the background. To run force dhcrelay to always run as attempt to configure may be specified on the command line
using the ----iiii option. If no interface names are specified on
the command line dhcrelay will identify all network inter-
faces, elimininating non-broadcast interfaces if possible,
and attempt to configure each interface.
If a relay agent is running on a system that is connected to
one or more networks on which no DHCP servers are present,
and is also connected to one or more networks on which DHCP
servers _a_r_e connected, it is may not be helpful for the
relay agent to relay requests from those networks on which a
DHCP server already exists. To avoid such a situation, the
interfaces on which the relay agent should listen should be
specified with the ----iiii flag.
Note that in some cases it _i_s helpful for the relay agent to
forward requests from networks on which a DHCP server is
running to other DHCP servers. This would be the case if
two DHCP servers on different networks were being used to
provide backup service for each other's networks.
1 If dhcrelay should listen and transmit on a port other than
the standard (port 67), the ----pppp flag may used. It should be
followed by the udp port number that dhcrelay should use.
This is mostly useful for debugging purposes.
dhcrelay(8) dhcrelay(8) SunOS 5.6 Last change: 1
a foreground process, the --dd flag should be specified.
This is useful when running dhcrelay under a debugger, or
when running it out of inittab on System V systems.
Dhcrelay will normally print its network configuration on
startup. This can be annoying in a system startup script
- to disable this behaviour, specify the --qq flag.
RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIOONNSS
If the --aa flag is set the relay agent will append an agent
option field to each request before forwarding it to the
server. Agent option fields in responses sent from
servers to clients will be stripped before forwarding such
responses back to the client.
The agent option field will contain two agent options: the
Circuit ID suboption and the Agent ID suboption. Cur<75>
rently, the Circuit ID will be the printable name of the
interface on which the client request was received. The
Agent ID will be the value that the relay agent stores in
the DHCP packet's giaddr field. The client supports
inclusion of a Remote ID suboption as well, but this is
not used by default.
_N_o_t_e_: The Agent ID suboption is not defined in the current Maintenance Procedures dhcrelay(8)
Relay Agent Information Option draft (draft-ietf-dhc-
agent-options-03.txt), but has been proposed for inclusion
in the next draft.
Relay Agent options are added to a DHCP packet without the
knowledge of the DHCP client. The client may have filled
the DHCP packet option buffer completely, in which case
there theoretically isn't any space to add Agent options.
However, the DHCP server may be able to handle a much
larger packet than most DHCP clients would send. The
current Agent Options draft requires that the relay agent
use a maximum packet size of 576 bytes.
It is recommended that with the Internet Software Consor<6F>
tium DHCP server, the maximum packet size be set to about
1400, allowing plenty of extra space in which the relay
agent can put the agent option field, while still fitting
into the Ethernet MTU size. This can be done by specify<66>
ing the --AA flag, followed by the desired maximum packet
size (e.g., 1400).
Note that this is reasonably safe to do even if the MTU Dhcrelay will normally run in the foreground until it has
between the server and the client is less than 1500, as configured an interface, and then will revert to running in
long as the hosts on which the server and client are run<75> the background. To run force dhcrelay to always run as a
ning support IP fragmentation (and they should). With foreground process, the ----dddd flag should be specified. This
some knowledge as to how large the agent options might get is useful when running dhcrelay under a debugger, or when
in a particular configuration, this parameter can be tuned running it out of inittab on System V systems.
as finely as necessary.
Dhcrelay will normally print its network configuration on
startup. This can be annoying in a system startup script -
to disable this behaviour, specify the ----qqqq flag.
RRRREEEELLLLAAAAYYYY AAAAGGGGEEEENNNNTTTT IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN OOOOPPPPTTTTIIIIOOOONNNNSSSS
If the ----aaaa flag is set the relay agent will append an agent
option field to each request before forwarding it to the
server. Agent option fields in responses sent from servers
to clients will be stripped before forwarding such responses
back to the client.
The agent option field will contain two agent options: the
Circuit ID suboption and the Agent ID suboption. Currently,
the Circuit ID will be the printable name of the interface
on which the client request was received. The Agent ID
will be the value that the relay agent stores in the DHCP
packet's giaddr field. The client supports inclusion of a
Remote ID suboption as well, but this is not used by
default.
2 _N_o_t_e: The Agent ID suboption is not defined in the current
Relay Agent Information Option draft (draft-ietf-dhc-agent-
options-03.txt), but has been proposed for inclusion in the
next draft.
Relay Agent options are added to a DHCP packet without the
knowledge of the DHCP client. The client may have filled
the DHCP packet option buffer completely, in which case
there theoretically isn't any space to add Agent options.
However, the DHCP server may be able to handle a much larger
packet than most DHCP clients would send. The current
Agent Options draft requires that the relay agent use a max-
imum packet size of 576 bytes.
It is recommended that with the Internet Software Consortium
DHCP server, the maximum packet size be set to about 1400,
allowing plenty of extra space in which the relay agent can
put the agent option field, while still fitting into the
Ethernet MTU size. This can be done by specifying the ----AAAA
flag, followed by the desired maximum packet size (e.g.,
1400).
Note that this is reasonably safe to do even if the MTU
between the server and the client is less than 1500, as long
as the hosts on which the server and client are running
dhcrelay(8) dhcrelay(8)
SunOS 5.6 Last change: 2
It is possible for a relay agent to receive a packet which
already contains an agent option field. If this packet
does not have a giaddr set, the standard requires that the
packet be discarded.
If giaddr is set, the server may handle the situation in
one of four ways: it may _a_p_p_e_n_d its own set of relay
options to the packet, leaving the supplied option field
intact. It may _r_e_p_l_a_c_e the existing agent option field.
It may _f_o_r_w_a_r_d the packet unchanged. Or, it may _d_i_s_c_a_r_d
it.
Which of these behaviours is followed by the Internet
Software Consortium DHCP Relay Agent may be configured
with the --mm flag, followed by one of the four keywords
specified in _i_t_a_l_i_c_s above.
When the relay agent receives a reply from a server that
it's supposed to forward to a client, and Relay Agent
Information option processing is enabled, the relay agent
scans the packet for Relay Agent Information options and
removes them. As it's scanning, if it finds a Relay
Agent Information option field containing an Agent ID sub<75>
option that matches one of its IP addresses, that option
is recognized as its own. If no such option is found,
the relay agent can either drop the packet, or relay it
anyway. If the --DD option is specified, all packets that
don't contain a match will be dropped.
SSPPEECCIIFFYYIINNGG DDHHCCPP SSEERRVVEERRSS
The name or IP address of at least one DHCP server to
which DHCP and BOOTP requests should be relayed must be
specified on the command line.
SSEEEE AALLSSOO Maintenance Procedures dhcrelay(8)
dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc-
agent-options-03.txt.
BBUUGGSS
It should be possible for the user to define the Circuit
ID and Remote ID values on a per-interface basis.
The relay agent should not relay packets received on a
physical network to DHCP servers on the same physical net<65>
work - if they do, the server will receive duplicate pack<63>
ets. In order to fix this, however, the relay agent
needs to be able to learn about the network topology,
which requires that it have a configuration file.
AAUUTTHHOORR support IP fragmentation (and they should). With some
ddhhccrreellaayy((88)) has been written for the Internet Software knowledge as to how large the agent options might get in a
Consortium by Ted Lemon <mellon@fugue.com> in cooperation particular configuration, this parameter can be tuned as
with Vixie Enterprises. To learn more about the Internet finely as necessary.
Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn
It is possible for a relay agent to receive a packet which
already contains an agent option field. If this packet does
not have a giaddr set, the standard requires that the packet
be discarded.
If giaddr is set, the server may handle the situation in one
of four ways: it may _a_p_p_e_n_d its own set of relay options to
the packet, leaving the supplied option field intact. It
may _r_e_p_l_a_c_e the existing agent option field. It may _f_o_r_w_a_r_d
the packet unchanged. Or, it may _d_i_s_c_a_r_d it.
3 Which of these behaviours is followed by the Internet
Software Consortium DHCP Relay Agent may be configured with
the ----mmmm flag, followed by one of the four keywords specified
in _i_t_a_l_i_c_s above.
When the relay agent receives a reply from a server that
it's supposed to forward to a client, and Relay Agent Infor-
mation option processing is enabled, the relay agent scans
the packet for Relay Agent Information options and removes
them. As it's scanning, if it finds a Relay Agent Informa-
tion option field containing an Agent ID suboption that
matches one of its IP addresses, that option is recognized
as its own. If no such option is found, the relay agent
can either drop the packet, or relay it anyway. If the ----DDDD
option is specified, all packets that don't contain a match
will be dropped.
SSSSPPPPEEEECCCCIIIIFFFFYYYYIIIINNNNGGGG DDDDHHHHCCCCPPPP SSSSEEEERRRRVVVVEEEERRRRSSSS
The name or IP address of at least one DHCP server to which
DHCP and BOOTP requests should be relayed must be specified
on the command line.
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc-
agent-options-03.txt.
BBBBUUUUGGGGSSSS
It should be possible for the user to define the Circuit ID
and Remote ID values on a per-interface basis.
dhcrelay(8) dhcrelay(8) The relay agent should not relay packets received on a phy-
sical network to DHCP servers on the same physical network -
if they do, the server will receive duplicate packets. In
order to fix this, however, the relay agent needs to be able
to learn about the network topology, which requires that it
have a configuration file.
more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm..
SunOS 5.6 Last change: 3
Maintenance Procedures dhcrelay(8)
AAAAUUUUTTTTHHHHOOOORRRR
ddddhhhhccccrrrreeeellllaaaayyyy((((8888)))) has been written for the Internet Software Con-
sortium by Ted Lemon <mellon@fugue.com> in cooperation with
Vixie Enterprises. To learn more about the Internet
Software Consortium, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To learn
more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm....
@@ -259,6 +255,10 @@ dhcrelay(8) dhcrelay(8)
4
SunOS 5.6 Last change: 4

6
server/confpars.c
View File

@@ -22,7 +22,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: confpars.c,v 1.64 1999/03/16 05:50:42 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; "$Id: confpars.c,v 1.65 1999/03/16 06:37:51 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -782,7 +782,7 @@ int parse_allow_deny (oc, cfile, flag)
{ {
enum dhcp_token token; enum dhcp_token token;
char *val; char *val;
char rf = flag; unsigned char rf = flag;
struct expression *data = (struct expression *)0; struct expression *data = (struct expression *)0;
int status; int status;
@@ -998,7 +998,7 @@ struct class *parse_class_declaration (cfile, group, type)
return (struct class *)0; return (struct class *)0;
data.terminated = 1; data.terminated = 1;
data.data = &data.buffer -> data [0]; data.data = &data.buffer -> data [0];
strcpy (data.data, val); strcpy ((char *)data.data, val);
} else if (token == NUMBER_OR_NAME || token == NUMBER) { } else if (token == NUMBER_OR_NAME || token == NUMBER) {
memset (&data, 0, sizeof data); memset (&data, 0, sizeof data);
if (!parse_cshl (&data, cfile)) if (!parse_cshl (&data, cfile))

33
server/dhcp.c
View File

@@ -22,7 +22,7 @@
#ifndef lint #ifndef lint
static char copyright[] = static char copyright[] =
"$Id: dhcp.c,v 1.82 1999/03/16 05:50:43 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; "$Id: dhcp.c,v 1.83 1999/03/16 06:37:52 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n";
#endif /* not lint */ #endif /* not lint */
#include "dhcpd.h" #include "dhcpd.h"
@@ -384,7 +384,8 @@ void nak_lease (packet, cip)
return; return;
} }
if (!make_const_data (&oc -> expression, if (!make_const_data (&oc -> expression,
dhcp_message, strlen (dhcp_message), 1, 0)) { (unsigned char *)dhcp_message,
strlen (dhcp_message), 1, 0)) {
log_error ("No memory for expr_const expression."); log_error ("No memory for expr_const expression.");
option_cache_dereference (&oc, "nak_lease"); option_cache_dereference (&oc, "nak_lease");
return; return;
@@ -1072,7 +1073,8 @@ void ack_lease (packet, lease, offer, when, msg)
oc = (struct option_cache *)0; oc = (struct option_cache *)0;
if (option_cache_allocate (&oc, "ack_lease")) { if (option_cache_allocate (&oc, "ack_lease")) {
if (make_const_data (&oc -> expression, if (make_const_data (&oc -> expression,
lease -> host -> name, ((unsigned char *)
lease -> host -> name),
strlen (lease -> host -> name), strlen (lease -> host -> name),
1, 0)) { 1, 0)) {
oc -> option = dhcp_universe.options [i]; oc -> option = dhcp_universe.options [i];
@@ -1101,7 +1103,8 @@ void ack_lease (packet, lease, offer, when, msg)
oc = (struct option_cache *)0; oc = (struct option_cache *)0;
if (option_cache_allocate (&oc, "ack_lease")) { if (option_cache_allocate (&oc, "ack_lease")) {
if (make_const_data (&oc -> expression, if (make_const_data (&oc -> expression,
h -> h_name, ((unsigned char *)
h -> h_name),
strlen (h -> h_name) + 1, strlen (h -> h_name) + 1,
1, 1)) { 1, 1)) {
oc -> option = oc -> option =
@@ -1680,16 +1683,18 @@ struct lease *find_lease (packet, share, ours)
if (packet -> packet_type == DHCPREQUEST && fixed_lease) { if (packet -> packet_type == DHCPREQUEST && fixed_lease) {
fixed_lease = (struct lease *)0; fixed_lease = (struct lease *)0;
db_conflict: db_conflict:
warn ("Both dynamic and static leases present for %s.", log_error ("Dynamic and static leases present for %s.",
piaddr (cip)); piaddr (cip));
warn ("Either remove host declaration %s or remove %s", log_error ("Remove host declaration %s or remove %s",
(fixed_lease && fixed_lease -> host (fixed_lease && fixed_lease -> host
? (fixed_lease -> host -> name ? (fixed_lease -> host -> name
? fixed_lease -> host -> name : piaddr (cip)) ? fixed_lease -> host -> name
: piaddr (cip)), : piaddr (cip))
piaddr (cip)); : piaddr (cip)),
warn ("from the dynamic address pool for %s", piaddr (cip));
ip_lease -> subnet -> shared_network -> name); log_error ("from the dynamic address pool for %s",
ip_lease -> subnet -> shared_network -> name
);
if (fixed_lease) if (fixed_lease)
ip_lease = (struct lease *)0; ip_lease = (struct lease *)0;
strcpy (dhcp_message, strcpy (dhcp_message,

532
server/dhcpd.cat8
View File

@@ -1,372 +1,353 @@
dhcpd(8) dhcpd(8) Maintenance Procedures dhcpd(8)
NNAAMMEE
dhcpd - Dynamic Host Configuration Protocol Server
SSYYNNOOPPSSIISS
ddhhccppdd [ --pp _p_o_r_t ] [ --ff ] [ --dd ] [ --qq ] [ --ccff _c_o_n_f_i_g_-_f_i_l_e ]
[ --llff _l_e_a_s_e_-_f_i_l_e ] [ _i_f_0 [ _._._._i_f_N ] ]
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP Server, dhcpd,
implements the Dynamic Host Configuration Protocol (DHCP)
and the Internet Bootstrap Protocol (BOOTP). DHCP allows
hosts on a TCP/IP network to request and be assigned IP
addresses, and also to discover information about the net<65>
work to which they are attached. BOOTP provides similar
functionality, with certain restrictions.
CCOONNTTRRIIBBUUTTIIOONNSS
Development of this software is funded through contribu<62>
tions and support contracts. Please see ddhhccpp--ccoonnttrriibb((55))
for information on how you can contribute.
OOPPEERRAATTIIOONN
The DHCP protocol allows a host which is unknown to the
network administrator to be automatically assigned a new
IP address out of a pool of IP addresses for its network.
In order for this to work, the network administrator allo<6C>
cates address pools in each subnet and enters them into
the dhcpd.conf(5) file.
On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and stores a
list of available addresses on each subnet in memory.
When a client requests an address using the DHCP protocol,
dhcpd allocates an address for it. Each client is
assigned a lease, which expires after an amount of time
chosen by the administrator (by default, one day). Before
leases expire, the clients to which leases are assigned
are expected to renew them in order to continue to use the
addresses. Once a lease has expired, the client to which
that lease was assigned is no longer permitted to use the
leased IP address.
In order to keep track of leases across system reboots and
server restarts, dhcpd keeps a list of leases it has
assigned in the dhcpd.leases(5) file. Before dhcpd
grants a lease to a host, it records the lease in this
file and makes sure that the contents of the file are
flushed to disk. This ensures that even in the event of
a system crash, dhcpd will not forget about a lease that
it has assigned. On startup, after reading the
dhcpd.conf file, dhcpd reads the dhcpd.leases file to
refresh its memory about what leases have been assigned.
New leases are appended to the end of the dhcpd.leases NNNNAAAAMMMMEEEE
file. In order to prevent the file from becoming dhcpd - Dynamic Host Configuration Protocol Server
1
dhcpd(8) dhcpd(8)
arbitrarily large, from time to time dhcpd creates a new
dhcpd.leases file from its in-core lease database. Once
this file has been written to disk, the old file is
renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
dhcpd.leases. If the system crashes in the middle of
this process, whichever dhcpd.leases file remains will
contain all the lease information, so there is no need for
a special crash recovery process.
BOOTP support is also provided by this server. Unlike
DHCP, the BOOTP protocol does not provide a protocol for
recovering dynamically-assigned addresses once they are no
longer needed. It is still possible to dynamically
assign addresses to BOOTP clients, but some administrative
process for reclaiming addresses is required. By
default, leases are granted to BOOTP clients in perpetu<74>
ity, although the network administrator may set an earlier
cutoff date or a shorter lease length for BOOTP leases if
that makes sense.
BOOTP clients may also be served in the old standard way,
which is to simply provide a declaration in the dhcpd.conf
file for each BOOTP client, permanently assigning an
address to each client.
Whenever changes are made to the dhcpd.conf file, dhcpd SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
must be restarted. To restart dhcpd, send a SIGTERM ddddhhhhccccppppdddd [ ----pppp _p_o_r_t ] [ ----ffff ] [ ----dddd ] [ ----qqqq ] [ ----ccccffff _c_o_n_f_i_g-_f_i_l_e ] [
(signal 15) to the process ID contained in ----llllffff _l_e_a_s_e-_f_i_l_e ] [ _i_f_0 [ ..._i_f_N ] ]
_/_v_a_r_/_r_u_n_/_d_h_c_p_d_._p_i_d, and then re-invoke dhcpd. Because the
DHCP server database is not as lightweight as a BOOTP DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
database, dhcpd does not automatically restart itself when The Internet Software Consortium DHCP Server, dhcpd, imple-
it sees a change to the dhcpd.conf file. ments the Dynamic Host Configuration Protocol (DHCP) and the
Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a
TCP/IP network to request and be assigned IP addresses, and
also to discover information about the network to which they
are attached. BOOTP provides similar functionality, with
certain restrictions.
CCCCOOOONNNNTTTTRRRRIIIIBBBBUUUUTTTTIIIIOOOONNNNSSSS
Development of this software is funded through contributions
and support contracts. Please see ddddhhhhccccpppp----ccccoooonnnnttttrrrriiiibbbb((((5555)))) for
information on how you can contribute.
OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN
The DHCP protocol allows a host which is unknown to the net-
work administrator to be automatically assigned a new IP
address out of a pool of IP addresses for its network. In
order for this to work, the network administrator allocates
address pools in each subnet and enters them into the
dhcpd.conf(5) file.
Note: We get a lot of complaints about this. We realize On startup, dhcpd reads the _d_h_c_p_d._c_o_n_f file and stores a
that it would be nice if one could send a SIGHUP to the list of available addresses on each subnet in memory. When
server and have it reload the database. This is not a client requests an address using the DHCP protocol, dhcpd
technically impossible, but it would require a great deal allocates an address for it. Each client is assigned a
of work, our resources are extremely limited, and they can lease, which expires after an amount of time chosen by the
be better spent elsewhere. So please don't complain administrator (by default, one day). Before leases expire,
about this on the mailing list unless you're prepared to the clients to which leases are assigned are expected to
fund a project to implement this feature, or prepared to renew them in order to continue to use the addresses. Once
do it yourself. a lease has expired, the client to which that lease was
assigned is no longer permitted to use the leased IP
address.
CCOOMMMMAANNDD LLIINNEE In order to keep track of leases across system reboots and
The names of the network interfaces on which dhcpd should server restarts, dhcpd keeps a list of leases it has
listen for broadcasts may be specified on the command assigned in the dhcpd.leases(5) file. Before dhcpd grants
line. This should be done on systems where dhcpd is a lease to a host, it records the lease in this file and
unable to identify non-broadcast interfaces, but should makes sure that the contents of the file are flushed to
not be required on other systems. If no interface names disk. This ensures that even in the event of a system
are specified on the command line dhcpd will identify all crash, dhcpd will not forget about a lease that it has
network interfaces which are up, elimininating non-broad<61> assigned. On startup, after reading the dhcpd.conf file,
cast interfaces if possible, and listen for DHCP broad<61> dhcpd reads the dhcpd.leases file to refresh its memory
casts on each interface. about what leases have been assigned.
2 SunOS 5.6 Last change: 1
dhcpd(8) dhcpd(8)
Maintenance Procedures dhcpd(8)
If dhcpd should listen on a port other than the standard
(port 67), the --pp flag may used. It should be followed by
the udp port number on which dhcpd should listen. This is
mostly useful for debugging purposes.
To run dhcpd as a foreground process, rather than allowing
it to run as a daemon in the background, the --ff flag
should be specified. This is useful when running dhcpd
under a debugger, or when running it out of inittab on
System V systems.
To have dhcpd log to the standard error descriptor, spec<65> New leases are appended to the end of the dhcpd.leases file.
ify the --dd flag. This can be useful for debugging, and In order to prevent the file from becoming arbitrarily
also at sites where a complete log of all dhcp activity large, from time to time dhcpd creates a new dhcpd.leases
must be kept but syslogd is not reliable or otherwise can<61> file from its in-core lease database. Once this file has
not be used. Normally, dhcpd will log all output using been written to disk, the old file is renamed _d_h_c_p_d._l_e_a_s_e_s~,
the syslog(3) function with the log facility set to and the new file is renamed dhcpd.leases. If the system
LOG_DAEMON. crashes in the middle of this process, whichever
dhcpd.leases file remains will contain all the lease infor-
mation, so there is no need for a special crash recovery
process.
Dhcpd can be made to use an alternate configuration file BOOTP support is also provided by this server. Unlike DHCP,
with the --ccff flag, or an alternate lease file with the --llff the BOOTP protocol does not provide a protocol for recover-
flag. Because of the importance of using the same lease ing dynamically-assigned addresses once they are no longer
database at all times when running dhcpd in production, needed. It is still possible to dynamically assign
these options should be used oonnllyy for testing lease files addresses to BOOTP clients, but some administrative process
or database files in a non-production environment. for reclaiming addresses is required. By default, leases
are granted to BOOTP clients in perpetuity, although the
network administrator may set an earlier cutoff date or a
shorter lease length for BOOTP leases if that makes sense.
When starting dhcpd up from a system startup script (e.g., BOOTP clients may also be served in the old standard way,
/etc/rc), it may not be desirable to print out the entire which is to simply provide a declaration in the dhcpd.conf
copyright message on startup. To avoid printing this file for each BOOTP client, permanently assigning an address
message, the --qq flag may be specified. to each client.
CCOONNFFIIGGUURRAATTIIOONN Whenever changes are made to the dhcpd.conf file, dhcpd must
The syntax of the dhcpd.conf(5) file is discussed seper<65> be restarted. To restart dhcpd, send a SIGTERM (signal 15)
ately. This section should be used as an overview of the to the process ID contained in /_e_t_c/_d_h_c_p_d._p_i_d, and then re-
configuration process, and the dhcpd.conf(5) documentation invoke dhcpd. Because the DHCP server database is not as
should be consulted for detailed reference information. lightweight as a BOOTP database, dhcpd does not automati-
cally restart itself when it sees a change to the dhcpd.conf
file.
Note: We get a lot of complaints about this. We realize
that it would be nice if one could send a SIGHUP to the
server and have it reload the database. This is not techn-
ically impossible, but it would require a great deal of
work, our resources are extremely limited, and they can be
better spent elsewhere. So please don't complain about
this on the mailing list unless you're prepared to fund a
project to implement this feature, or prepared to do it
yourself.
SSuubbnneettss CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE
dhcpd needs to know the subnet numbers and netmasks of all The names of the network interfaces on which dhcpd should
subnets for which it will be providing service. In addi<64> listen for broadcasts may be specified on the command line.
tion, in order to dynamically allocate addresses, it must This should be done on systems where dhcpd is unable to
be assigned one or more ranges of addresses on each subnet identify non-broadcast interfaces, but should not be
which it can in turn assign to client hosts as they boot. required on other systems. If no interface names are speci-
Thus, a very simple configuration providing DHCP support fied on the command line dhcpd will identify all network
might look like this: interfaces which are up, elimininating non-broadcast
subnet 239.252.197.0 netmask 255.255.255.0 {
range 239.252.197.10 239.252.197.250;
}
Multiple address ranges may be specified like this:
subnet 239.252.197.0 netmask 255.255.255.0 { SunOS 5.6 Last change: 2
3
Maintenance Procedures dhcpd(8)
dhcpd(8) dhcpd(8)
interfaces if possible, and listen for DHCP broadcasts on
each interface.
range 239.252.197.10 239.252.197.107; If dhcpd should listen on a port other than the standard
range 239.252.197.113 239.252.197.250; (port 67), the ----pppp flag may used. It should be followed by
} the udp port number on which dhcpd should listen. This is
mostly useful for debugging purposes.
If a subnet will only be provided with BOOTP service and To run dhcpd as a foreground process, rather than allowing
no dynamic address assignment, the range clause can be it to run as a daemon in the background, the ----ffff flag should
left out entirely, but the subnet statement must appear. be specified. This is useful when running dhcpd under a
debugger, or when running it out of inittab on System V sys-
tems.
To have dhcpd log to the standard error descriptor, specify
the ----dddd flag. This can be useful for debugging, and also at
sites where a complete log of all dhcp activity must be kept
but syslogd is not reliable or otherwise cannot be used.
Normally, dhcpd will log all output using the syslog(3)
function with the log facility set to LOG_DAEMON.
LLeeaassee LLeennggtthhss Dhcpd can be made to use an alternate configuration file
DHCP leases can be assigned almost any length from zero with the ----ccccffff flag, or an alternate lease file with the ----llllffff
seconds to infinity. What lease length makes sense for flag. Because of the importance of using the same lease
any given subnet, or for any given installation, will vary database at all times when running dhcpd in production,
depending on the kinds of hosts being served. these options should be used oooonnnnllllyyyy for testing lease files or
database files in a non-production environment.
For example, in an office environment where systems are When starting dhcpd up from a system startup script (e.g.,
added from time to time and removed from time to time, but /etc/rc), it may not be desirable to print out the entire
move relatively infrequently, it might make sense to allow copyright message on startup. To avoid printing this mes-
lease times of a month of more. In a final test environ<6F> sage, the ----qqqq flag may be specified.
ment on a manufacturing floor, it may make more sense to
assign a maximum lease length of 30 minutes - enough time
to go through a simple test procedure on a network appli<6C>
ance before packaging it up for delivery.
It is possible to specify two lease lengths: the default CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
length that will be assigned if a client doesn't ask for The syntax of the dhcpd.conf(5) file is discussed
any particular lease length, and a maximum lease length. seperately. This section should be used as an overview of
These are specified as clauses to the subnet command: the configuration process, and the dhcpd.conf(5) documenta-
tion should be consulted for detailed reference information.
subnet 239.252.197.0 netmask 255.255.255.0 { SSSSuuuubbbbnnnneeeettttssss
range 239.252.197.10 239.252.197.107; dhcpd needs to know the subnet numbers and netmasks of all
default-lease-time 600; subnets for which it will be providing service. In addi-
max-lease-time 7200; tion, in order to dynamically allocate addresses, it must be
| assigned one or more ranges of addresses on each subnet
which it can in turn assign to client hosts as they boot.
Thus, a very simple configuration providing DHCP support
might look like this:
This particular subnet declaration specifies a default subnet 239.252.197.0 netmask 255.255.255.0 {
lease time of 600 seconds (ten minutes), and a maximum range 239.252.197.10 239.252.197.250;
lease time of 7200 seconds (two hours). Other common }
values would be 86400 (one day), 604800 (one week) and
2592000 (30 days).
Each subnet need not have the same lease--in the case of
an office environment and a manufacturing environment
served by the same DHCP server, it might make sense to
have widely disparate values for default and maximum lease
times on each subnet.
BBOOOOTTPP SSuuppppoorrtt
Each BOOTP client must be explicitly declared in the
dhcpd.conf file. A very basic client declaration will
specify the client network interface's hardware address
and the IP address to assign to that client. If the
client needs to be able to load a boot file from the
server, that file's name must be specified. A simple
SunOS 5.6 Last change: 3
4
dhcpd(8) dhcpd(8) Maintenance Procedures dhcpd(8)
bootp client declaration might look like this:
host haagen { Multiple address ranges may be specified like this:
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}
OOppttiioonnss subnet 239.252.197.0 netmask 255.255.255.0 {
DHCP (and also BOOTP with Vendor Extensions) provide a range 239.252.197.10 239.252.197.107;
mechanism whereby the server can provide the client with range 239.252.197.113 239.252.197.250;
information about how to configure its network interface }
(e.g., subnet mask), and also how the client can access
various network services (e.g., DNS, IP routers, and so
on).
These options can be specified on a per-subnet basis, and, If a subnet will only be provided with BOOTP service and no
for BOOTP clients, also on a per-client basis. In the dynamic address assignment, the range clause can be left out
event that a BOOTP client declaration specifies options entirely, but the subnet statement must appear.
that are also specified in its subnet declaration, the
options specified in the client declaration take prece<63>
dence. An reasonably complete DHCP configuration might
look something like this:
subnet 239.252.197.0 netmask 255.255.255.0 { LLLLeeeeaaaasssseeee LLLLeeeennnnggggtttthhhhssss
range 239.252.197.10 239.252.197.250; DHCP leases can be assigned almost any length from zero
default-lease-time 600 max-lease-time 7200; seconds to infinity. What lease length makes sense for any
option subnet-mask 255.255.255.0; given subnet, or for any given installation, will vary
option broadcast-address 239.252.197.255; depending on the kinds of hosts being served.
option routers 239.252.197.1;
option domain-name-servers 239.252.197.2, 239.252.197.3;
option domain-name "isc.org";
}
A bootp host on that subnet that needs to be in a differ<65> For example, in an office environment where systems are
ent domain and use a different name server might be added from time to time and removed from time to time, but
declared as follows: move relatively infrequently, it might make sense to allow
lease times of a month of more. In a final test environ-
ment on a manufacturing floor, it may make more sense to
assign a maximum lease length of 30 minutes - enough time to
go through a simple test procedure on a network appliance
before packaging it up for delivery.
host haagen { It is possible to specify two lease lengths: the default
hardware ethernet 08:00:2b:4c:59:23; length that will be assigned if a client doesn't ask for any
fixed-address 239.252.197.9; particular lease length, and a maximum lease length. These
filename "/tftpboot/haagen.boot"; are specified as clauses to the subnet command:
option domain-name-servers 192.5.5.1;
option domain-name "vix.com";
}
A more complete description of the dhcpd.conf file syntax subnet 239.252.197.0 netmask 255.255.255.0 {
is provided in dhcpd.conf(5). range 239.252.197.10 239.252.197.107;
default-lease-time 600;
max-lease-time 7200;
|
FFIILLEESS This particular subnet declaration specifies a default lease
//eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,, time of 600 seconds (ten minutes), and a maximum lease time
//vvaarr//ddbb//ddhhccppdd..lleeaasseess~~.. of 7200 seconds (two hours). Other common values would be
86400 (one day), 604800 (one week) and 2592000 (30 days).
Each subnet need not have the same lease-in the case of an
office environment and a manufacturing environment served by
the same DHCP server, it might make sense to have widely
disparate values for default and maximum lease times on each
subnet.
BBBBOOOOOOOOTTTTPPPP SSSSuuuuppppppppoooorrrrtttt
Each BOOTP client must be explicitly declared in the
dhcpd.conf file. A very basic client declaration will
specify the client network interface's hardware address and
5 SunOS 5.6 Last change: 4
dhcpd(8) dhcpd(8)
Maintenance Procedures dhcpd(8)
SSEEEE AALLSSOO
dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)
AAUUTTHHOORR
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
contract with Vixie Labs. Funding for this project was
provided by the Internet Software Consortium. Information
about the Internet Software Consortium can be found at
hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
the IP address to assign to that client. If the client
needs to be able to load a boot file from the server, that
file's name must be specified. A simple bootp client
declaration might look like this:
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}
OOOOppppttttiiiioooonnnnssss
DHCP (and also BOOTP with Vendor Extensions) provide a
mechanism whereby the server can provide the client with
information about how to configure its network interface
(e.g., subnet mask), and also how the client can access
various network services (e.g., DNS, IP routers, and so on).
These options can be specified on a per-subnet basis, and,
for BOOTP clients, also on a per-client basis. In the
event that a BOOTP client declaration specifies options that
are also specified in its subnet declaration, the options
specified in the client declaration take precedence. An
reasonably complete DHCP configuration might look something
like this:
subnet 239.252.197.0 netmask 255.255.255.0 {
range 239.252.197.10 239.252.197.250;
default-lease-time 600 max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 239.252.197.255;
option routers 239.252.197.1;
option domain-name-servers 239.252.197.2, 239.252.197.3;
option domain-name "isc.org";
}
A bootp host on that subnet that needs to be in a different
domain and use a different name server might be declared as
follows:
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
option domain-name-servers 192.5.5.1;
option domain-name "vix.com";
}
A more complete description of the dhcpd.conf file syntax is
provided in dhcpd.conf(5).
SunOS 5.6 Last change: 5
Maintenance Procedures dhcpd(8)
FFFFIIIILLLLEEEESSSS
////eeeettttcccc////ddddhhhhccccppppdddd....ccccoooonnnnffff,,,, ////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss,,,, ////eeeettttcccc////ddddhhhhccccppppdddd....ppppiiiidddd,,,,
////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss~~~~....
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)
AAAAUUUUTTTTHHHHOOOORRRR
ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon <mellon@vix.com> under a
contract with Vixie Labs. Funding for this project was
provided by the Internet Software Consortium. Information
about the Internet Software Consortium can be found at
hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc....
@@ -391,6 +372,25 @@ AAUUTTHHOORR
6
SunOS 5.6 Last change: 6

1864
server/dhcpd.conf.cat5
View File

File diff suppressed because it is too large Load Diff

254
server/dhcpd.leases.cat5
View File

@@ -1,189 +1,186 @@
dhcpd.leases(5) dhcpd.leases(5) Headers, Environments, and Macros dhcpd.leases(5)
NNAAMMEE
dhcpd.leases - DHCP client lease database
DDEESSCCRRIIPPTTIIOONN NNNNAAAAMMMMEEEE
The Internet Software Consortium DHCP Server keeps a per<65> dhcpd.leases - DHCP client lease database
sistent database of leases that it has assigned. This
database is a free-form ASCII file containing a series of
lease declarations. Every time a lease is acquired,
renewed or released, its new value is recorded at the end
of the lease file. So if more than one declaration
appears for a given lease, the last one in the file is the
current one.
When dhcpd is first installed, there is no lease database. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
However, dhcpd requires that a lease database be present The Internet Software Consortium DHCP Server keeps a per-
before it will start. To make the initial lease database, sistent database of leases that it has assigned. This data-
just create an empty file called /var/db/dhcpd.leases. base is a free-form ASCII file containing a series of lease
declarations. Every time a lease is acquired, renewed or
released, its new value is recorded at the end of the lease
file. So if more than one declaration appears for a given
lease, the last one in the file is the current one.
In order to prevent the lease database from growing with<74> When dhcpd is first installed, there is no lease database.
out bound, the file is rewritten from time to time. However, dhcpd requires that a lease database be present
First, a temporary lease database is created and all known before it will start. To make the initial lease database,
leases are dumped to it. Then, the old lease database is just create an empty file called /etc/dhcpd.leases.
renamed /var/db/dhcpd.leases~. Finally, the newly writ<69>
ten lease database is moved into place.
There is a window of vulnerability where if the dhcpd pro<72> In order to prevent the lease database from growing without
cess is killed or the system crashes after the old lease bound, the file is rewritten from time to time. First, a
database has been renamed but before the new one has been temporary lease database is created and all known leases are
moved into place, there will be no /var/db/dhcpd.leases. dumped to it. Then, the old lease database is renamed
In this case, dhcpd will refuse to start, and will require /etc/dhcpd.leases~. Finally, the newly written lease data-
manual intervention. DDOO NNOOTT simply create a new lease base is moved into place.
file when this happens - if you do, you will lose all your
old bindings, and chaos will ensue. Instead, rename
/var/db/dhcpd.leases~ to /var/db/dhcpd.leases, restoring
the old, valid lease file, and then start dhcpd. This
guarantees that a valid lease file will be restored.
FFOORRMMAATT There is a window of vulnerability where if the dhcpd pro-
Lease descriptions are stored in a format that is parsed cess is killed or the system crashes after the old lease
by the same recursive descent parser used to read the database has been renamed but before the new one has been
ddhhccppdd..ccoonnff((55)) and ddhhcclliieenntt..ccoonnff((55)) files. Currently, the moved into place, there will be no /etc/dhcpd.leases. In
only declaration that is used in the dhcpd.leases file is this case, dhcpd will refuse to start, and will require
the lleeaassee declaration. manual intervention. DDDDOOOO NNNNOOOOTTTT simply create a new lease file
when this happens - if you do, you will lose all your old
bindings, and chaos will ensue. Instead, rename
/etc/dhcpd.leases~ to /etc/dhcpd.leases, restoring the old,
valid lease file, and then start dhcpd. This guarantees
that a valid lease file will be restored.
lleeaassee _i_p_-_a_d_d_r_e_s_s {{ _s_t_a_t_e_m_e_n_t_s_._._. }} FFFFOOOORRRRMMMMAAAATTTT
Lease descriptions are stored in a format that is parsed by
the same recursive descent parser used to read the
ddddhhhhccccppppdddd....ccccoooonnnnffff((((5555)))) and ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff((((5555)))) files. Currently, the
only declaration that is used in the dhcpd.leases file is
the lllleeeeaaaasssseeee declaration.
Each lease declaration include the single IP address that lllleeeeaaaasssseeee _i_p-_a_d_d_r_e_s_s {{{{ _s_t_a_t_e_m_e_n_t_s... }}}}
has been leased to the client. The statements within the
braces define the duration of the lease and to whom it is
assigned.
The start and end time of a lease are recorded using the Each lease declaration include the single IP address that
``starts'' and ``ends'' statements: has been leased to the client. The statements within the
braces define the duration of the lease and to whom it is
assigned.
The start and end time of a lease are recorded using the
``starts'' and ``ends'' statements:
1 SunOS 5.6 Last change: 1
dhcpd.leases(5) dhcpd.leases(5)
Headers, Environments, and Macros dhcpd.leases(5)
ssttaarrttss _d_a_t_e;;
eennddss _d_a_t_e;;
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 ssssttttaaaarrrrttttssss _d_a_t_e;;;;
eeeennnnddddssss _d_a_t_e;;;;
The weekday is present to make it easy for a human to tell Dates are specified as follows:
when a lease expires - it's specified as a number from
zero to six, with zero being Sunday. The day of week is
ignored on input. 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 sec<65>
ond also a number between 0 and 59.
Lease times are specified in Greenwich Mean Time (GMT), _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
not in the local time zone. Since Greenwich is actually
on Daylight Savings Time part of the year, there is proba<62>
bly nowhere in the world where the times recorded on a
lease are always the same as wall clock times. On a unix
machine, one can often figure out the current time in GMT
by typing ddaattee --uu.
The MAC address of the network interface that was used to The weekday is present to make it easy for a human to tell
acquire the lease is recorded with the hhaarrddwwaarree statement: when a lease expires - it's specified as a number from zero
to six, with zero being Sunday. The day of week is ignored
on input. 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.
hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _m_a_c_-_a_d_d_r_e_s_s;; Lease times are specified in Greenwich Mean Time (GMT), not
in the local time zone. Since Greenwich is actually on
Daylight Savings Time part of the year, there is probably
nowhere in the world where the times recorded on a lease are
always the same as wall clock times. On a unix machine, one
can often figure out the current time in GMT by typing ddddaaaatttteeee
----uuuu.
The MAC address is specified as a series of hexadecimal The MAC address of the network interface that was used to
octets, seperated by colons. acquire the lease is recorded with the hhhhaaaarrrrddddwwwwaaaarrrreeee statement:
If the client used a client identifier to acquire its hhhhaaaarrrrddddwwwwaaaarrrreeee _h_a_r_d_w_a_r_e-_t_y_p_e _m_a_c-_a_d_d_r_e_s_s;;;;
address, the client identifier is recorded using the uuiidd
statement:
uuiidd _c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r;; The MAC address is specified as a series of hexadecimal
octets, seperated by colons.
The client identifier is recorded as a series of hexadeci<63> If the client used a client identifier to acquire its
mal octets, regardless of whether the client specifies an address, the client identifier is recorded using the uuuuiiiidddd
ASCII string or uses the newer hardware type/MAC address statement:
format.
If the client sends a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e uuuuiiiidddd _c_l_i_e_n_t-_i_d_e_n_t_i_f_i_e_r;;;;
option, as specified in some versions of the DHCP-DNS
Interaction draft, that hostname is recorded using the
cclliieenntt--hhoossttnnaammee statement.
cclliieenntt--hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; The client identifier is recorded as a series of hexadecimal
octets, regardless of whether the client specifies an ASCII
string or uses the newer hardware type/MAC address format.
If the client sends its hostname using the _H_o_s_t_n_a_m_e If the client sends a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e
option, as Windows 95 does, it is recorded using the option, as specified in some versions of the DHCP-DNS
Interaction draft, that hostname is recorded using the
cccclllliiiieeeennnntttt----hhhhoooossssttttnnnnaaaammmmeeee statement.
cccclllliiiieeeennnntttt----hhhhoooossssttttnnnnaaaammmmeeee """"_h_o_s_t_n_a_m_e"""";;;;
2
SunOS 5.6 Last change: 2
dhcpd.leases(5) dhcpd.leases(5)
hhoossttnnaammee statement.
hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";;
The DHCP server may determine that a lease has been mis<69> Headers, Environments, and Macros dhcpd.leases(5)
used in some way, either because a client that has been
assigned a lease NAKs it, or because the server's own
attempt to see if an address is in use prior to reusing it
reveals that the address is in fact already in use. In
that case, the aabbaannddoonneedd statement will be used to indi<64>
cate that the lease should not be reassigned.
aabbaannddoonneedd;;
Abandoned leases are reclaimed automatically. When a
client asks for a new address, and the server finds that
there are no new addresses, it checks to see if there are
any abandoned leases, and allocates the least recently
abandoned lease. The standard mechanisms for checking
for lease address conflicts are still followed, so if the
abandoned lease's IP address is still in use, it will be
reabandoned.
If a client rreeqquueessttss an abandoned address, the server If the client sends its hostname using the _H_o_s_t_n_a_m_e option,
assumes that the reason the address was abandoned was that as Windows 95 does, it is recorded using the hhhhoooossssttttnnnnaaaammmmeeee state-
the lease file was corrupted, and that the client is the ment.
machine that responded when the lease was probed, causing
it to be abandoned. In that case, the address is immedi<64>
ately assigned to the client.
FFIILLEESS hhhhoooossssttttnnnnaaaammmmeeee """"_h_o_s_t_n_a_m_e"""";;;;
//vvaarr//ddbb//ddhhccppdd..lleeaasseess
SSEEEE AALLSSOO The DHCP server may determine that a lease has been misused
dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, in some way, either because a client that has been assigned
RFC2131. a lease NAKs it, or because the server's own attempt to see
if an address is in use prior to reusing it reveals that the
address is in fact already in use. In that case, the aaaabbbbaaaannnn----
ddddoooonnnneeeedddd statement will be used to indicate that the lease
should not be reassigned.
AAUUTTHHOORR aaaabbbbaaaannnnddddoooonnnneeeedddd;;;;
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
contract with Vixie Labs. Funding for this project was
provided by the Internet Software Corporation. Informa<6D>
tion about the Internet Software Consortium can be found
at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
Abandoned leases are reclaimed automatically. When a
client asks for a new address, and the server finds that
there are no new addresses, it checks to see if there are
any abandoned leases, and allocates the least recently aban-
doned lease. The standard mechanisms for checking for
lease address conflicts are still followed, so if the aban-
doned lease's IP address is still in use, it will be reaban-
doned.
If a client rrrreeeeqqqquuuueeeessssttttssss an abandoned address, the server
assumes that the reason the address was abandoned was that
the lease file was corrupted, and that the client is the
machine that responded when the lease was probed, causing it
to be abandoned. In that case, the address is immediately
assigned to the client.
FFFFIIIILLLLEEEESSSS
////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, RFC2131.
AAAAUUUUTTTTHHHHOOOORRRR
ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon <mellon@vix.com> under a
contract with Vixie Labs. Funding for this project was
provided by the Internet Software Corporation. Information
about the Internet Software Consortium can be found at
hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc....
@@ -193,6 +190,9 @@ AAUUTTHHOORR
3
SunOS 5.6 Last change: 3