mir/isc-dhcp
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/dhcp synced 2025-08-30 13:57:50 +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
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 */
#include "dhcpd.h"
@@ -73,7 +73,7 @@ int read_client_conf ()
top_level_config.retry_interval = 300;
top_level_config.backoff_cutoff = 120;
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.requested_options = default_requested_options;
top_level_config.requested_lease = 7200;

274
client/dhclient-script.cat8
View File

@@ -1,34 +1,35 @@
dhclient(8) dhclient(8)
Maintenance Procedures dhclient(8)
NNAAMMEE
NNNNAAAAMMMMEEEE
dhclient-script - DHCP client network configuration script
DDEESSCCRRIIPPTTIIOONN
The DHCP client network configuration script is invoked
from time to time by ddhhcclliieenntt((88)). This script is used by
the dhcp client to set each interface's initial configura<EFBFBD>
tion prior to requesting an address, to test the address
once it has been offered, and to set the interface's final
configuration once a lease has been acquired. If no lease
is acquired, the script is used to test predefined leases,
if any, and also called once if no valid lease can be
identified.
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
The DHCP client network configuration script is invoked from
time to time by ddddhhhhcccclllliiiieeeennnntttt((((8888)))). This script is used by the
dhcp client to set each interface's initial configuration
prior to requesting an address, to test the address once it
has been offered, and to set the interface's final confi-
guration 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 identi-
fied.
This script is not meant to be customized by the end user.
However, the script may not work on particular versions of
particular operating systems (indeed, no standard script
exists for some operating systems), so a pioneering user
may well need to create a new script or modify an existing
one. In general, customizations specific to a particular
computer should be done in the //eettcc//ddhhcclliieenntt..ccoonnff script.
If you find that you can't make such a customization with<EFBFBD>
out customizing dhclient.conf, please submit a bug report.
exists for some operating systems), so a pioneering user may
well need to create a new script or modify an existing one.
In general, customizations specific to a particular computer
should be done in the ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff script. If you
find that you can't make such a customization without cus-
tomizing dhclient.conf, please submit a bug report.
OOPPEERRAATTIIOONN
OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN
When dhclient needs to invoke the client configuration
script, it writes a shell script into /tmp which defines a
variety of variables. In all cases, $reason is set to the
@@ -36,22 +37,21 @@ OOPPEERRAATTIIOONN
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
The DHCP client is requesting that an interface's media
type be set. The interface name is passed in $interface,
and the media type is passed in $medium.
PPRREEIINNIITT
The DHCP client is requesting that an interface be config<69>
ured as required in order to send packets prior to receiv<69>
ing an actual address. For clients which use the BSD
socket library, this means configuring the interface with
an IP address of 0.0.0.0 and a broadcast address of
255.255.255.255. For other clients, it may be possible
to simply configure the interface up without actually giv<69>
ing it an IP address at all. The interface name is
passed in $interface, and the media type in $medium.
PPPPRRRREEEEIIIINNNNIIIITTTT
The DHCP client is requesting that an interface be config-
ured as required in order to send packets prior to receiving
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.
If an IP alias has been declared in dhclient.conf, its
address will be passed in $alias_ip_address, and that ip
@@ -60,162 +60,163 @@ PPRREEIINNIITT
1
SunOS 5.6 Last change: 1
dhclient(8) dhclient(8)
Maintenance Procedures dhclient(8)
BBOOUUNNDD
BBBBOOOOUUUUNNNNDDDD
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.
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 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.
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.
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<EFBFBD>
eters are likely to need to be set up. A new
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.
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
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.
RRRREEEENNNNEEEEWWWW
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.
RRRREEEEBBBBIIIINNNNDDDD
The DHCP client has rebound to a new DHCP server. This can
be handled as with RENEW, except that if the IP address has
2
SunOS 5.6 Last change: 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
changed, the ARP table should be cleared.
RRRREEEEBBBBOOOOOOOOTTTT
The DHCP client has successfully reacquired its old address
after a reboot. This can be processed as with BOUND.
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.
new one, and the lease has expired. The IP address must be
relinquished, and all related parameters should be deleted,
as in RENEW and REBIND.
FFAAIILL
The DHCP client has been unable to contact any DHCP
servers, and any leases that have been tested have not
proved to be valid. The parameters from the last lease
tested should be deconfigured. This can be handled in
the same way as EXPIRE.
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.
TTIIMMEEOOUUTT
The DHCP client has been unable to contact any DHCP
servers. However, an old lease has been identified, and
its parameters have been passed in as with BOUND. The
client configuration script should test these parameters
and, if it has reason to believe they are valid, should
exit with a value of zero. If not, it should exit with a
nonzero value.
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.
with REBIND (since this may be called to test more than one
lease) and then ping the first router defined in $routers.
If a response is received, the lease must be valid for the
network to which the interface is currently connected. It
would be more complete to try to ping all of the routers
listed in $new_routers, as well as those listed in
$new_static_routes, but current scripts do not do this.
FFIILLEESS
FFFFIIIILLLLEEEESSSS
Each operating system should generally have its own script
file, although the script files for similar operating sys<EFBFBD>
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 distri<EFBFBD>
bution appear in the distribution tree under
client/scripts, and bear the names of the operating sys<EFBFBD>
tems on which they are intended to work.
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.
BBUUGGSS
If more than one interface is being used, there's no obvi<EFBFBD>
ous way to avoid clashes between server-supplied configu<EFBFBD>
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<EFBFBD>
tialized to the values provided by one server, and then
the other. Assuming the information provided by both
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.
3
SunOS 5.6 Last change: 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
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).
AAUUTTHHOORR
ddhhcclliieenntt--ssccrriipptt((88)) has been written for the Internet Soft<66>
ware Consortium by Ted Lemon <mellon@fugue.com> in cooper<65>
ation with Vixie Enterprises. To learn more about the
Internet Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc..
To learn more about Vixie Enterprises, see
hhttttpp::////wwwwww..vviixx..ccoomm..
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....
@@ -257,8 +258,7 @@ AAUUTTHHOORR
SunOS 5.6 Last change: 4
4

190
client/dhclient.cat8
View File

@@ -1,155 +1,156 @@
dhclient(8) dhclient(8)
Maintenance Procedures dhclient(8)
NNAAMMEE
NNNNAAAAMMMMEEEE
dhclient - Dynamic Host Configuration Protocol Client
SSYYNNOOPPSSIISS
ddhhcclliieenntt [ --pp _p_o_r_t ] [ --dd ] [ _i_f_0 [ _._._._i_f_N ] ]
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
ddddhhhhcccclllliiiieeeennnntttt [ ----pppp _p_o_r_t ] [ ----dddd ] [ _i_f_0 [ ..._i_f_N ] ]
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP Client, dhclient,
provides a means for configuring one or more network
interfaces using the Dynamic Host Configuration Protocol,
BOOTP protocol, or if these protocols fail, by statically
assigning an address.
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
The Internet Software Consortium DHCP Client, dhclient, pro-
vides a means for configuring one or more network interfaces
using the Dynamic Host Configuration Protocol, BOOTP proto-
col, or if these protocols fail, by statically assigning an
address.
OOPPEERRAATTIIOONN
The DHCP protocol allows a host to contact a central
server which maintains a list of IP addresses which may be
assigned on one or more subnets. A DHCP client may
request an address from this pool, and then use it on a
temporary basis for communication on network. The DHCP
protocol also provides a mechanism whereby a client can
learn important details about the network to which it is
attached, such as the location of a default router, the
location of a name server, and so on.
OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN
The DHCP protocol allows a host to contact a central server
which maintains a list of IP addresses which may be assigned
on one or more subnets. A DHCP client may request an
address from this pool, and then use it on a temporary basis
for communication on network. The DHCP protocol also 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.
On startup, dhclient reads the _d_h_c_l_i_e_n_t_._c_o_n_f for configu<EFBFBD>
ration instructions. It then gets a list of all the net<EFBFBD>
work interfaces that are configured in the current system.
For each interface, it attempts to configure the interface
using the DHCP protocol.
On startup, dhclient reads the _d_h_c_l_i_e_n_t._c_o_n_f for configura-
tion instructions. It then gets a list of all the network
interfaces that are configured in the current system. For
each interface, it attempts to configure the interface using
the DHCP protocol.
In order to keep track of leases across system reboots and
server restarts, dhclient keeps a list of leases it has
been assigned in the dhclient.leases(5) file. On
startup, after reading the dhclient.conf file, dhclient
reads the dhclient.leases file to refresh its memory about
what leases it has been assigned.
server restarts, dhclient keeps a list of leases it has been
assigned in the dhclient.leases(5) file. On startup, after
reading the dhclient.conf file, dhclient reads the
dhclient.leases file to refresh its memory about what leases
it has been assigned.
When a new lease is acquired, it is appended to the end of
the dhclient.leases file. In order to prevent the file
from becoming arbitrarily large, from time to time
dhclient creates a new dhclient.leases file from its in-
core lease database. The old version of the
dhclient.leases file is retained under the name
_d_h_c_p_d_._l_e_a_s_e_s_~ until the next time dhclient rewrites the
database.
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
unavailable when dhclient is first invoked (generally dur<EFBFBD>
ing the initial system boot process). In that event, old
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.
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)
Maintenance Procedures dhclient(8)
A mobile host which may sometimes need to access a network
on which no DHCP server exists may be preloaded with a
lease for a fixed address on that network. When all
attempts to contact a DHCP server have failed, dhclient
will try to validate the static lease, and if it succeeds,
will use that lease until it is restarted.
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.
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
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, elimininat<EFBFBD>
ing non-broadcast interfaces if possible, and attempt to
configure each interface.
dhclient will identify all network interfaces, elimininating
non-broadcast interfaces if possible, and attempt to config-
ure each interface.
If dhclient should listen and transmit on a port other
than the standard (port 68), the --pp flag may used. It
should be followed by the udp port number that dhclient
should use. This is mostly useful for debugging purposes.
If dhclient should listen and transmit on a port other than
the standard (port 68), the ----pppp flag may used. It should be
followed by the udp port number that dhclient should use.
This is mostly useful for debugging purposes.
Dhclient will normally run in the foreground until it has
configured an interface, and then will revert to running
in the background. To run force dhclient to always run as
a foreground process, the --dd flag should be specified.
This is useful when running dhclient under a debugger, or
when running it out of inittab on System V systems.
configured an interface, and then will revert to running in
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.
CCOONNFFIIGGUURRAATTIIOONN
CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
The syntax of the dhclient.conf(8) file is discussed
seperately.
FFIILLEESS
//eettcc//ddhhcclliieenntt..ccoonnff,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess,,
//vvaarr//rruunn//ddhhcclliieenntt..ppiidd,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess~~..
FFFFIIIILLLLEEEESSSS
////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff,,,, ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss,,,, ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ppppiiiidddd,,,,
////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss~~~~....
SSEEEE AALLSSOO
dhcpd(8), dhcrelay(8), dhclient.conf(5),
dhclient.leases(5)
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhcpd(8), dhcrelay(8), dhclient.conf(5), dhclient.leases(5)
AAUUTTHHOORR
ddhhcclliieenntt((88)) has been written for the Internet Software
Consortium by Ted Lemon <mellon@fugue.com> in cooperation
with Vixie Enterprises. To learn more about the Internet
Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn
more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm..
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)
Maintenance Procedures 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<EFBFBD>
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 maintain system-specific configuration code to
these operating systems - instead, the shell script can
invoke the native tools to accomplish the same purpose.
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.
@@ -188,11 +189,10 @@ dhclient(8) dhclient(8)
SunOS 5.6 Last change: 3
3

716
client/dhclient.conf.cat5
View File

@@ -1,288 +1,293 @@
dhclient.conf(5) dhclient.conf(5)
Headers, Environments, and Macros dhclient.conf(5)
NNAAMMEE
NNNNAAAAMMMMEEEE
dhclient.conf - DHCP client configuration file
DDEESSCCRRIIPPTTIIOONN
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
The dhclient.conf file contains configuration information
for _d_h_c_l_i_e_n_t_, the Internet Software Consortium DHCP
Client.
for _d_h_c_l_i_e_n_t, the Internet Software Consortium DHCP Client.
The dhclient.conf file is a free-form ASCII text file.
It is parsed by the recursive-descent parser built into
dhclient. The file may contain extra tabs and newlines
for formatting purposes. Keywords in the file are case-
The dhclient.conf file is a free-form ASCII text file. It
is parsed by the recursive-descent parser built into
dhclient. The file may contain extra tabs and newlines for
formatting purposes. Keywords in the file are case-
insensitive. Comments may be placed anywhere within the
file (except within quotes). Comments begin with the #
character and end at the end of the line.
The dhclient.conf file can be used to configure the
behaviour of the client in a wide variety of ways: proto<EFBFBD>
col timing, information requested from the server, infor<EFBFBD>
mation required of the server, defaults to use if the
server does not provide certain information, values with
which to override information provided by the server, or
values to prepend or append to information provided by the
server. The configuration file can also be preinitialized
with addresses to use on networks that don't have DHCP
servers.
behaviour of the client in a wide variety of ways: protocol
timing, information requested from the server, information
required of the server, defaults to use if the server does
not provide certain information, values with which to over-
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.
PPRROOTTOOCCOOLL TTIIMMIINNGG
The timing behaviour of the client need not be configured
by the user. If no timing configuration is provided by
the user, a fairly reasonable timing behaviour will be
used by default - one which results in fairly timely
updates without placing an inordinate load on the server.
PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTIIIIMMMMIIIINNNNGGGG
The timing behaviour of the client need not be configured by
the user. If no timing configuration is provided by the
user, a fairly reasonable timing behaviour will be used by
default - one which results in fairly timely updates without
placing an inordinate load on the server.
The following statements can be used to adjust the timing
behaviour of the DHCP client if required, however:
_T_h_e ttiimmeeoouutt _s_t_a_t_e_m_e_n_t
_T_h_e ttttiiiimmmmeeeeoooouuuutttt _s_t_a_t_e_m_e_n_t
ttiimmeeoouutt _t_i_m_e ;;
ttttiiiimmmmeeeeoooouuuutttt _t_i_m_e ;;;;
The _t_i_m_e_o_u_t statement determines the amount of time that
must pass between the time that the client begins to try
to determine its address and the time that it decides that
it's not going to be able to contact a server. By
default, this timeout is sixty seconds. After the time<EFBFBD>
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.
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)
Headers, Environments, and Macros dhclient.conf(5)
_T_h_e rreettrryy _s_t_a_t_e_m_e_n_t
rreettrryy _t_i_m_e;;
_T_h_e rrrreeeettttrrrryyyy _s_t_a_t_e_m_e_n_t
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.
rrrreeeettttrrrryyyy _t_i_m_e;;;;
_T_h_e sseelleecctt--ttiimmeeoouutt _s_t_a_t_e_m_e_n_t
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.
sseelleecctt--ttiimmeeoouutt _t_i_m_e;;
_T_h_e sssseeeelllleeeecccctttt----ttttiiiimmmmeeeeoooouuuutttt _s_t_a_t_e_m_e_n_t
sssseeeelllleeeecccctttt----ttttiiiimmmmeeeeoooouuuutttt _t_i_m_e;;;;
It is possible (some might say desirable) for there to be
more than one DHCP server serving any given network. In
this case, it is possible that a client may be sent more
than one offer in response to its initial lease discovery
message. It may be that one of these offers is prefer<EFBFBD>
able to the other (e.g., one offer may have the address
the client previously used, and the other may not).
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).
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.
The _s_e_l_e_c_t-_t_i_m_e_o_u_t is the time after the client sends its
first lease discovery request at which it stops waiting for
offers from servers, assuming that it has received at least
one such offer. If no offers have been received by the
time the _s_e_l_e_c_t-_t_i_m_e_o_u_t has expired, the client will accept
the first offer that arrives.
By default, the select-timeout is zero seconds - that is,
the client will take the first offer it sees.
_T_h_e rreebboooott _s_t_a_t_e_m_e_n_t
_T_h_e rrrreeeebbbbooooooootttt _s_t_a_t_e_m_e_n_t
rreebboooott _t_i_m_e;;
rrrreeeebbbbooooooootttt _t_i_m_e;;;;
When the client is restarted, it first tries to reacquire
the last address it had. This is called the INIT-REBOOT
state. If it is still attached to the same network it
was attached to when it last ran, this is the quickest way
to get started. The _r_e_b_o_o_t statement sets the time that
must elapse after the client first tries to reacquire its
old address before it gives up and tries to discover a new
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 bbbbaaaacccckkkkooooffffffff----ccccuuuuttttooooffffffff _s_t_a_t_e_m_e_n_t
bbaacckkooffff--ccuuttooffff _t_i_m_e;;
bbbbaaaacccckkkkooooffffffff----ccccuuuuttttooooffffffff _t_i_m_e;;;;
The client uses an exponential backoff algorithm with some
randomness, so that if many clients try to configure them<EFBFBD>
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
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
Headers, Environments, and Macros dhclient.conf(5)
maximum amount of time that the client is allowed to back
off. It defaults to two minutes.
_T_h_e iiiinnnniiiittttiiiiaaaallll----iiiinnnntttteeeerrrrvvvvaaaallll _s_t_a_t_e_m_e_n_t
iiiinnnniiiittttiiiiaaaallll----iiiinnnntttteeeerrrrvvvvaaaallll _t_i_m_e;;;;
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
The _i_n_i_t_i_a_l-_i_n_t_e_r_v_a_l statement sets the amount of time
between the first attempt to reach a server and the second
attempt to reach a server. Each time a message is sent,
the interval between messages is incremented by twice the
current interval multiplied by a random number between
zero and one. If it is greater than the backoff-cutoff
amount, it is set to that amount. It defaults to ten sec<EFBFBD>
onds.
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.
LLEEAASSEE RREEQQUUIIRREEMMEENNTTSS AANNDD RREEQQUUEESSTTSS
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 pro<EFBFBD>
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.
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.
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)).
servers send to DHCP clients. The data that can be specifi-
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 rreeqquueesstt _s_t_a_t_e_m_e_n_t
_T_h_e rrrreeeeqqqquuuueeeesssstttt _s_t_a_t_e_m_e_n_t
rreeqquueesstt [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n ];;
rrrreeeeqqqquuuueeeesssstttt [[[[ _o_p_t_i_o_n ] [,,,, ... _o_p_t_i_o_n ];;;;
The request statement causes the client to request that
any server responding to the client send the client its
values for the specified options. Only the option names
should be specified in the request statement - not option
parameters.
The request statement causes the client to request that any
server responding to the client send the client its values
for the specified options. Only the option names should be
specified in the request statement - not option parameters.
_T_h_e rreeqquuiirree _s_t_a_t_e_m_e_n_t
_T_h_e rrrreeeeqqqquuuuiiiirrrreeee _s_t_a_t_e_m_e_n_t
rreeqquuiirree [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _];;
rrrreeeeqqqquuuuiiiirrrreeee [[[[ _o_p_t_i_o_n ] [,,,, ... _o_p_t_i_o_n ];;;;
The require statement lists options that must be sent in
order for an offer to be accepted. Offers that do not
contain all the listed options will be ignored.
order for an offer to be accepted. Offers that do not con-
tain all the listed options will be ignored.
_T_h_e sseenndd _s_t_a_t_e_m_e_n_t
_T_h_e sssseeeennnndddd _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
]}}
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 full option declarations as described in ddhhccpp--
ooppttiioonnss((55)). Options that are always sent in the DHCP
options to the server with the specified values. These are
3
SunOS 5.6 Last change: 3
dhclient.conf(5) dhclient.conf(5)
Headers, Environments, and Macros dhclient.conf(5)
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
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.
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 infor<EFBFBD>
mation which is useful, but which needs to be supplemented
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.
_T_h_e ddeeffaauulltt _s_t_a_t_e_m_e_n_t
_T_h_e ddddeeeeffffaaaauuuulllltttt _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 ] ;;
ddddeeeeffffaaaauuuulllltttt [[[[ _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<EFBFBD>
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.
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.
_T_h_e ssuuppeerrsseeddee _s_t_a_t_e_m_e_n_t
_T_h_e ssssuuuuppppeeeerrrrsssseeeeddddeeee _s_t_a_t_e_m_e_n_t
ssuuppeerrsseeddee [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;
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 sup<EFBFBD>
plied by the server, these values can be defined in the
ssuuppeerrsseeddee statement.
configured value or values rather than whatever is supplied
by the server, these values can be defined in the ssssuuuuppppeeeerrrrsssseeeeddddeeee
statement.
_T_h_e pprreeppeenndd _s_t_a_t_e_m_e_n_t
_T_h_e pppprrrreeeeppppeeeennnndddd _s_t_a_t_e_m_e_n_t
pprreeppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;
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 pprreeppeenndd statement.
The pprreeppeenndd statement can only be used for options which
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,
SunOS 5.6 Last change: 4
Headers, Environments, and Macros dhclient.conf(5)
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.
_T_h_e aappppeenndd _s_t_a_t_e_m_e_n_t
LLLLEEEEAAAASSSSEEEE DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS
_T_h_e lllleeeeaaaasssseeee _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 first any values sup<75>
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.
4
dhclient.conf(5) dhclient.conf(5)
LLEEAASSEE DDEECCLLAARRAATTIIOONNSS
_T_h_e lleeaassee _d_e_c_l_a_r_a_t_i_o_n
lleeaassee {{ _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n [ ... _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n _] }}
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
PPRROOTTOOCCOOLL TTIIMMIINNGG) decide that it is not going to succeed in
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 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.
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
@@ -291,149 +296,151 @@ LLEEAASSEE DDEECCLLAARRAATTIIOONNSS
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<EFBFBD>
laration statements, followed by a right curly brace.
The following lease declarations are possible:
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:
bboooottpp;;
bbbboooooooottttpppp;;;;
The bboooottpp statement is used to indicate that the lease was
acquired using the BOOTP protocol rather than the DHCP
protocol. It is never necessary to specify this in the
client configuration file. The client uses this syntax
in its lease database file.
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.
iinntteerrffaaccee ""_s_t_r_i_n_g"";;
iiiinnnntttteeeerrrrffffaaaacccceeee """"_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<EFBFBD>
fied, although this is not required.
ffiixxeedd--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;;
The ffiixxeedd--aaddddrreessss statement is used to set the ip address
of a particular lease. This is required for all lease
statements. The IP address must be specified as a dotted
quad (e.g., 12.34.56.78).
5
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)
SunOS 5.6 Last change: 5
ffiilleennaammee ""_s_t_r_i_n_g"";;
The ffiilleennaammee statement specifies the name of the boot
Headers, Environments, and Macros dhclient.conf(5)
ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss _i_p-_a_d_d_r_e_s_s;;;;
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.
sseerrvveerr--nnaammee ""_s_t_r_i_n_g"";;
sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee """"_s_t_r_i_n_g"""";;;;
The sseerrvveerr--nnaammee statement specifies the name of the boot
server name to use. This is also not used by the stan<EFBFBD>
dard client configuration script.
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.
ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n;;
ooooppppttttiiiioooonnnn _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<EFBFBD>
fined leases declared in dhclient.conf, the value that the
user wishes the client configuration script to use if the
predefined lease is used.
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.
ssccrriipptt ""_s_c_r_i_p_t_-_n_a_m_e"";;
ssssccccrrrriiiipppptttt """"_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<EFBFBD>
uration prior to requesting an address, to test the
address once it has been offered, and to set the inter<EFBFBD>
face's final configuration once a lease has been acquired.
If no lease is acquired, the script is used to test prede<EFBFBD>
fined leases, if any, and also called once if no valid
lease can be identified. For more information, see
ddhhcclliieenntt--lleeaassee((88))..
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))))....
mmeeddiiuumm ""_m_e_d_i_a _s_e_t_u_p"";;
mmmmeeeeddddiiiiuuuummmm """"_m_e_d_i_a _s_e_t_u_p"""";;;;
The mmeeddiiuumm statement can be used on systems where network
interfaces cannot automatically determine the type of net<EFBFBD>
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 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.
The dhcp client automatically declares this parameter if
it used a media type (see the mmeeddiiaa statement) when con<EFBFBD>
figuring the interface in order to obtain a lease. This
statement should be used in predefined leases only if the
network interface requires media type configuration.
rreenneeww _d_a_t_e;;
rreebbiinndd _d_a_t_e;;
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
6
SunOS 5.6 Last change: 6
dhclient.conf(5) dhclient.conf(5)
Headers, Environments, and Macros dhclient.conf(5)
eexxppiirree _d_a_t_e;;
The rreenneeww statement defines the time at which the dhcp
client should begin trying to contact its server to renew
a lease that it is using. The rreebbiinndd statement defines
the time at which the dhcp client should begin to try to
contact _a_n_y dhcp server in order to renew its lease. The
eexxppiirree statement defines the time at which the dhcp client
must stop using a lease if it has not been able to contact
a server in order to renew it.
should be used in predefined leases only if the network
interface requires media type configuration.
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.
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.
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:
_<_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_>
<_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.
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 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.
AALLIIAASS DDEECCLLAARRAATTIIOONNSS
aalliiaass {{ _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 ... }}}}
Some DHCP clients running TCP/IP roaming protocols may
require that in addition to the lease they may acquire via
@@ -442,94 +449,98 @@ AALLIIAASS DDEECCLLAARRAATTIIOONNSS
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.
7
the dhcp client can be set up to configure an IP alias using
the aaaalllliiiiaaaassss declaration.
dhclient.conf(5) dhclient.conf(5)
SunOS 5.6 Last change: 7
OOTTHHEERR DDEECCLLAARRAATTIIOONNSS
rreejjeecctt _i_p_-_a_d_d_r_e_s_s;;
The reject statement causes the DHCP client to reject
offers from servers who use the specified address as a
server identifier. This can be used to avoid being con<6F>
figured by rogue or misconfigured dhcp servers, although
it should be a last resort - better to track down the bad
DHCP server and fix it.
iinntteerrffaaccee ""_n_a_m_e"" {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }}
Headers, Environments, and Macros 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;;;;
The reject statement causes the DHCP client to reject offers
from servers who use the specified address as a server iden-
tifier. This can be used to avoid being configured by
rogue or misconfigured dhcp servers, although it should be a
last resort - better to track down the bad DHCP server and
fix it.
iiiinnnntttteeeerrrrffffaaaacccceeee """"_n_a_m_e"""" {{{{ _d_e_c_l_a_r_a_t_i_o_n_s ... }}}}
A client with more than one network interface may require
different behaviour depending on which interface is being
configured. All timing parameters and declarations other
than lease and alias declarations can be enclosed in an
interface declaration, and those parameters will then be
used only for the interface that matches the specified
name. Interfaces for which there is no interface decla<EFBFBD>
ration will use the parameters declared outside of any
interface declaration, or the default settings.
used only for the interface that matches the specified name.
Interfaces for which there is no interface declaration will
use the parameters declared outside of any interface
declaration, or the default settings.
mmeeddiiaa ""_m_e_d_i_a _s_e_t_u_p"" _[ ,, ""_m_e_d_i_a _s_e_t_u_p"",, _._._. _];;
mmmmeeeeddddiiiiaaaa """"_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<EFBFBD>
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 mmmmeeeeddddiiiiaaaa statement defines one or more media configuration
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.
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.
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: 8
8
Headers, Environments, and Macros dhclient.conf(5)
dhclient.conf(5) 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;
@@ -557,38 +568,27 @@ dhclient.conf(5) dhclient.conf(5)
fixed-address 192.5.5.213;
option subnet-mask 255.255.255.255;
}
This is a very complicated dhclient.conf file - in gen<EFBFBD>
eral, yours should be much simpler. In many cases, it's
sufficient to just create an empty dhclient.conf file -
the defaults are usually fine.
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.
SSEEEE AALLSSOO
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhcp-options(5), dhclient.leases(5), dhcpd(8),
dhcpd.conf(5), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com>
under a contract with Vixie Labs. Funding for this pro<EFBFBD>
ject was provided by the Internet Software Consortium.
Information about the Internet Software Consortium can be
found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
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

42
client/dhclient.leases.cat5
View File

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

4
common/bpf.c
View File

@@ -22,7 +22,7 @@
#ifndef lint
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 */
#include "dhcpd.h"
@@ -274,7 +274,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
result = writev(interface -> wfdesc, iov, 2);
if (result < 0)
warn ("send_packet: %m");
log_error ("send_packet: %m");
return result;
}
#endif /* USE_BPF_SEND */

4
common/dlpi.c
View File

@@ -108,7 +108,7 @@
#ifndef lint
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 */
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);
#endif
if (result < 0)
warn ("send_packet: %m");
log_error ("send_packet: %m");
return result;
}
#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
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 */
#include "dhcpd.h"
@@ -58,7 +58,7 @@ static char copyright[] =
*/
int
inet_aton(cp, addr)
char *cp;
const char *cp;
struct in_addr *addr;
{
register u_long val;

4
common/lpf.c
View File

@@ -23,7 +23,7 @@
#ifndef lint
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 */
#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,
&sa, sizeof sa);
if (result < 0)
warn ("send_packet: %m");
log_error ("send_packet: %m");
return result;
}
#endif /* USE_LPF_SEND */

4
common/nit.c
View File

@@ -23,7 +23,7 @@
#ifndef lint
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 */
#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);
if (result < 0)
warn ("send_packet: %m");
log_error ("send_packet: %m");
return result;
}
#endif /* USE_NIT_SEND */

7
common/parse.c
View File

@@ -22,7 +22,7 @@
#ifndef lint
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 */
#include "dhcpd.h"
@@ -782,7 +782,7 @@ int parse_cshl (data, cfile)
struct data_string *data;
FILE *cfile;
{
char ibuf [128];
u_int8_t ibuf [128];
int ilen = 0;
int tlen = 0;
struct option_tag *sl = (struct option_tag *)0;
@@ -1381,7 +1381,8 @@ int parse_non_binary (expr, cfile, lose, context)
case STRING:
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.");
break;

4
common/raw.c
View File

@@ -35,7 +35,7 @@
#ifndef lint
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 */
#include "dhcpd.h"
@@ -112,7 +112,7 @@ size_t send_packet (interface, packet, raw, len, from, to, hto)
result = writev(interface -> wfdesc, iov, 2);
if (result < 0)
warn ("send_packet: %m");
log_error ("send_packet: %m");
return result;
}
#endif /* USE_SOCKET_SEND */

6
common/socket.c
View File

@@ -30,7 +30,7 @@
#ifndef lint
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 */
#include "dhcpd.h"
@@ -188,9 +188,9 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
retry++ < 10);
#endif
if (result < 0) {
warn ("send_packet: %m");
log_error ("send_packet: %m");
if (errno == ENETUNREACH)
warn ("send_packet: please consult README file %s",
log_error ("send_packet: please consult README file %s",
"regarding broadcast address.");
}
return result;

4
common/upf.c
View File

@@ -22,7 +22,7 @@
#ifndef lint
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 */
#include "dhcpd.h"
@@ -233,7 +233,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto)
result = writev(interface -> wfdesc, iov, 2);
if (result < 0)
warn ("send_packet: %m");
log_error ("send_packet: %m");
return result;
}
#endif /* USE_UPF_SEND */

2
includes/dhcpd.h
View File

@@ -300,7 +300,7 @@ struct lease_state {
#endif
#ifndef CL_DEFAULT_BOOTP_POLICY
# define CL_DEFAULT_BOOTP_POLICY ACCEPT
# define CL_DEFAULT_BOOTP_POLICY P_ACCEPT
#endif
#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. */
struct buffer {
int refcnt;
char data [1];
unsigned char data [1];
};
/* XXX The mechanism by which data strings are returned is currently
@@ -125,7 +125,6 @@ struct data_string; /* forward */
struct packet; /* forward */
struct option_state; /* forward */
struct decoded_option_state; /* forward */
enum statement_op; /* forward */
struct universe {
char *name;

292
relay/dhcrelay.cat8
View File

@@ -1,209 +1,214 @@
dhcrelay(8) dhcrelay(8)
Maintenance Procedures dhcrelay(8)
NNAAMMEE
NNNNAAAAMMMMEEEE
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 ]
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
ddddhhhhccccrrrreeeellllaaaayyyy [ ----pppp _p_o_r_t ] [ ----dddd ] [ ----qqqq ] [ ----iiii _i_f_0 [ ............ ----iiii _i_f_N ] ]
[ ----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
| _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<EFBFBD>
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.
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
The Internet Software Consortium DHCP Relay Agent, dhcrelay,
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.
OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN
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 ori-
ginal request came.
CCOOMMMMAANNDD LLIINNEE
CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE
The names of the network interfaces that dhcrelay should
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<EFBFBD>
sible, and attempt to configure each interface.
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 pre<EFBFBD>
sent, 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 --ii flag.
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.
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.
SunOS 5.6 Last change: 1
Maintenance Procedures dhcrelay(8)
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.
If dhcrelay should listen and transmit on a port other
than the standard (port 67), the --pp flag may used. It
should be followed by the udp port number that dhcrelay
should use. This is mostly useful for debugging purposes.
Dhcrelay will normally run in the foreground until it has
configured an interface, and then will revert to running
in the background. To run force dhcrelay to always run as
1
dhcrelay(8) dhcrelay(8)
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.
configured an interface, and then will revert to running in
the background. To run force dhcrelay to always run as a
foreground process, the ----dddd 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.
startup. This can be annoying in a system startup script -
to disable this behaviour, specify the ----qqqq flag.
RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIOONNSS
If the --aa flag is set the relay agent will append an agent
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.
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<EFBFBD>
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.
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.
_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.
_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 maximum packet size of 576 bytes.
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 Consor<EFBFBD>
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<EFBFBD>
ing the --AA flag, followed by the desired maximum packet
size (e.g., 1400).
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 run<EFBFBD>
ning support IP fragmentation (and they should). With
some knowledge as to how large the agent options might get
in a particular configuration, this parameter can be tuned
as finely as necessary.
between the server and the client is less than 1500, as long
as the hosts on which the server and client are running
2
SunOS 5.6 Last change: 2
dhcrelay(8) dhcrelay(8)
Maintenance Procedures dhcrelay(8)
support IP fragmentation (and they should). With some
knowledge as to how large the agent options might get in a
particular configuration, this parameter can be tuned as
finely as necessary.
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.
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.
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.
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
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<EFBFBD>
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.
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.
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.
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.
SSEEEE AALLSSOO
SSSSEEEEEEEE AAAALLLLSSSSOOOO
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.
BBBBUUUUGGGGSSSS
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<EFBFBD>
work - if they do, the server will receive duplicate pack<EFBFBD>
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.
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.
AAUUTTHHOORR
ddhhccrreellaayy((88)) has been written for the Internet Software
Consortium by Ted Lemon <mellon@fugue.com> in cooperation
with Vixie Enterprises. To learn more about the Internet
Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn
SunOS 5.6 Last change: 3
3
dhcrelay(8) dhcrelay(8)
Maintenance Procedures dhcrelay(8)
more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm..
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....
@@ -253,12 +258,7 @@ dhcrelay(8) dhcrelay(8)
SunOS 5.6 Last change: 4
4

6
server/confpars.c
View File

@@ -22,7 +22,7 @@
#ifndef lint
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 */
#include "dhcpd.h"
@@ -782,7 +782,7 @@ int parse_allow_deny (oc, cfile, flag)
{
enum dhcp_token token;
char *val;
char rf = flag;
unsigned char rf = flag;
struct expression *data = (struct expression *)0;
int status;
@@ -998,7 +998,7 @@ struct class *parse_class_declaration (cfile, group, type)
return (struct class *)0;
data.terminated = 1;
data.data = &data.buffer -> data [0];
strcpy (data.data, val);
strcpy ((char *)data.data, val);
} else if (token == NUMBER_OR_NAME || token == NUMBER) {
memset (&data, 0, sizeof data);
if (!parse_cshl (&data, cfile))

23
server/dhcp.c
View File

@@ -22,7 +22,7 @@
#ifndef lint
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 */
#include "dhcpd.h"
@@ -384,7 +384,8 @@ void nak_lease (packet, cip)
return;
}
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.");
option_cache_dereference (&oc, "nak_lease");
return;
@@ -1072,7 +1073,8 @@ void ack_lease (packet, lease, offer, when, msg)
oc = (struct option_cache *)0;
if (option_cache_allocate (&oc, "ack_lease")) {
if (make_const_data (&oc -> expression,
lease -> host -> name,
((unsigned char *)
lease -> host -> name),
strlen (lease -> host -> name),
1, 0)) {
oc -> option = dhcp_universe.options [i];
@@ -1101,7 +1103,8 @@ void ack_lease (packet, lease, offer, when, msg)
oc = (struct option_cache *)0;
if (option_cache_allocate (&oc, "ack_lease")) {
if (make_const_data (&oc -> expression,
h -> h_name,
((unsigned char *)
h -> h_name),
strlen (h -> h_name) + 1,
1, 1)) {
oc -> option =
@@ -1680,16 +1683,18 @@ struct lease *find_lease (packet, share, ours)
if (packet -> packet_type == DHCPREQUEST && fixed_lease) {
fixed_lease = (struct lease *)0;
db_conflict:
warn ("Both dynamic and static leases present for %s.",
log_error ("Dynamic and static leases present for %s.",
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 -> host -> name
? fixed_lease -> host -> name : piaddr (cip))
? fixed_lease -> host -> name
: piaddr (cip))
: piaddr (cip)),
piaddr (cip));
warn ("from the dynamic address pool for %s",
ip_lease -> subnet -> shared_network -> name);
log_error ("from the dynamic address pool for %s",
ip_lease -> subnet -> shared_network -> name
);
if (fixed_lease)
ip_lease = (struct lease *)0;
strcpy (dhcp_message,

388
server/dhcpd.cat8
View File

@@ -1,184 +1,186 @@
dhcpd(8) dhcpd(8)
Maintenance Procedures dhcpd(8)
NNAAMMEE
NNNNAAAAMMMMEEEE
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 ] ]
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
ddddhhhhccccppppdddd [ ----pppp _p_o_r_t ] [ ----ffff ] [ ----dddd ] [ ----qqqq ] [ ----ccccffff _c_o_n_f_i_g-_f_i_l_e ] [
----llllffff _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<EFBFBD>
work to which they are attached. BOOTP provides similar
functionality, with certain restrictions.
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
The Internet Software Consortium DHCP Server, dhcpd, imple-
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.
CCOONNTTRRIIBBUUTTIIOONNSS
Development of this software is funded through contribu<EFBFBD>
tions and support contracts. Please see ddhhccpp--ccoonnttrriibb((55))
for information on how you can contribute.
CCCCOOOONNNNTTTTRRRRIIIIBBBBUUUUTTTTIIIIOOOONNNNSSSS
Development of this software is funded through contributions
and support contracts. Please see ddddhhhhccccpppp----ccccoooonnnnttttrrrriiiibbbb((((5555)))) 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<EFBFBD>
cates address pools in each subnet and enters them into
the dhcpd.conf(5) file.
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.
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.
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
file. In order to prevent the file from becoming
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.
1
SunOS 5.6 Last change: 1
dhcpd(8) dhcpd(8)
Maintenance Procedures 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.
New leases are appended to the end of the dhcpd.leases file.
In order to prevent the file from becoming 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 infor-
mation, 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 recover-
ing 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 perpetuity, 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.
file for each BOOTP client, permanently assigning an address
to each client.
Whenever changes are made to the dhcpd.conf file, dhcpd
must be restarted. To restart dhcpd, send a SIGTERM
(signal 15) to the process ID contained in
_/_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
database, dhcpd does not automatically restart itself when
it sees a change to the dhcpd.conf file.
Whenever changes are made to the dhcpd.conf file, dhcpd must
be restarted. To restart dhcpd, send a SIGTERM (signal 15)
to the process ID contained in /_e_t_c/_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 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
technically 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.
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.
CCOOMMMMAANNDD LLIINNEE
CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE
The names of the network interfaces on which dhcpd should
listen for broadcasts may be specified on the command
line. This should be done on systems where dhcpd is
unable to identify non-broadcast interfaces, but should
not be required on other systems. If no interface names
are specified on the command line dhcpd will identify all
network interfaces which are up, elimininating non-broad<EFBFBD>
cast interfaces if possible, and listen for DHCP broad<61>
casts on each interface.
listen for broadcasts may be specified on the command line.
This should be done on systems where dhcpd is unable to
identify non-broadcast interfaces, but should not be
required on other systems. If no interface names are speci-
fied on the command line dhcpd will identify all network
interfaces which are up, elimininating non-broadcast
2
SunOS 5.6 Last change: 2
dhcpd(8) dhcpd(8)
Maintenance Procedures dhcpd(8)
interfaces if possible, and listen for DHCP broadcasts on
each interface.
If dhcpd should listen on a port other than the standard
(port 67), the --pp flag may used. It should be followed by
(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.
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.
it to run as a daemon in the background, the ----ffff flag should
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, spec<EFBFBD>
ify the --dd 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 can<EFBFBD>
not be used. Normally, dhcpd will log all output using
the syslog(3) function with the log facility set to
LOG_DAEMON.
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.
Dhcpd can be made to use an alternate configuration file
with the --ccff flag, or an alternate lease file with the --llff
with the ----ccccffff flag, or an alternate lease file with the ----llllffff
flag. Because of the importance of using the same lease
database at all times when running dhcpd in production,
these options should be used oonnllyy for testing lease files
or database files in a non-production environment.
these options should be used oooonnnnllllyyyy for testing lease files or
database files in a non-production environment.
When starting dhcpd up from a system startup script (e.g.,
/etc/rc), it may not be desirable to print out the entire
copyright message on startup. To avoid printing this
message, the --qq flag may be specified.
copyright message on startup. To avoid printing this mes-
sage, the ----qqqq flag may be specified.
CCOONNFFIIGGUURRAATTIIOONN
The syntax of the dhcpd.conf(5) file is discussed seper<65>
ately. This section should be used as an overview of the
configuration process, and the dhcpd.conf(5) documentation
should be consulted for detailed reference information.
CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
The syntax of the dhcpd.conf(5) file is discussed
seperately. This section should be used as an overview of
the configuration process, and the dhcpd.conf(5) documenta-
tion should be consulted for detailed reference information.
SSuubbnneettss
SSSSuuuubbbbnnnneeeettttssss
dhcpd needs to know the subnet numbers and netmasks of all
subnets for which it will be providing service. In addi<EFBFBD>
tion, in order to dynamically allocate addresses, it must
be assigned one or more ranges of addresses on each subnet
subnets for which it will be providing service. In addi-
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:
@@ -187,49 +189,50 @@ SSuubbnneettss
range 239.252.197.10 239.252.197.250;
}
SunOS 5.6 Last change: 3
Maintenance Procedures dhcpd(8)
Multiple address ranges may be specified like this:
subnet 239.252.197.0 netmask 255.255.255.0 {
3
dhcpd(8) dhcpd(8)
range 239.252.197.10 239.252.197.107;
range 239.252.197.113 239.252.197.250;
}
If a subnet will only be provided with BOOTP service and
no dynamic address assignment, the range clause can be
left out entirely, but the subnet statement must appear.
If a subnet will only be provided with BOOTP service and no
dynamic address assignment, the range clause can be left out
entirely, but the subnet statement must appear.
LLeeaassee LLeennggtthhss
LLLLeeeeaaaasssseeee LLLLeeeennnnggggtttthhhhssss
DHCP leases can be assigned almost any length from zero
seconds to infinity. What lease length makes sense for
any given subnet, or for any given installation, will vary
seconds to infinity. What lease length makes sense for any
given subnet, or for any given installation, will vary
depending on the kinds of hosts being served.
For example, in an office environment where systems are
added from time to time and removed from time to time, but
move relatively infrequently, it might make sense to allow
lease times of a month of more. In a final test environ<EFBFBD>
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 appli<EFBFBD>
ance before packaging it up for delivery.
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.
It is possible to specify two lease lengths: the default
length that will be assigned if a client doesn't ask for
any particular lease length, and a maximum lease length.
These are specified as clauses to the subnet command:
length that will be assigned if a client doesn't ask for any
particular lease length, and a maximum lease length. These
are specified as clauses to the subnet command:
subnet 239.252.197.0 netmask 255.255.255.0 {
range 239.252.197.10 239.252.197.107;
@@ -237,38 +240,39 @@ LLeeaassee LLeennggtthhss
max-lease-time 7200;
|
This particular subnet declaration specifies a default
lease time of 600 seconds (ten minutes), and a maximum
lease time of 7200 seconds (two hours). Other common
values would be 86400 (one day), 604800 (one week) and
2592000 (30 days).
This particular subnet declaration specifies a default lease
time of 600 seconds (ten minutes), and a maximum 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.
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
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 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
specify the client network interface's hardware address and
4
SunOS 5.6 Last change: 4
dhcpd(8) dhcpd(8)
Maintenance Procedures dhcpd(8)
bootp client declaration might look like this:
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;
@@ -276,21 +280,20 @@ dhcpd(8) dhcpd(8)
filename "/tftpboot/haagen.boot";
}
OOppttiioonnss
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).
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 prece<EFBFBD>
dence. An reasonably complete DHCP configuration might
look something like this:
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;
@@ -302,9 +305,9 @@ OOppttiioonnss
option domain-name "isc.org";
}
A bootp host on that subnet that needs to be in a differ<EFBFBD>
ent domain and use a different name server might be
declared as follows:
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;
@@ -314,35 +317,37 @@ OOppttiioonnss
option domain-name "vix.com";
}
A more complete description of the dhcpd.conf file syntax
is provided in dhcpd.conf(5).
FFIILLEESS
//eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,,
//vvaarr//ddbb//ddhhccppdd..lleeaasseess~~..
A more complete description of the dhcpd.conf file syntax is
provided in dhcpd.conf(5).
5
SunOS 5.6 Last change: 5
dhcpd(8) dhcpd(8)
Maintenance Procedures dhcpd(8)
SSEEEE AALLSSOO
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)
AAUUTTHHOORR
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
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
hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc....
@@ -385,12 +390,7 @@ AAUUTTHHOORR
SunOS 5.6 Last change: 6
6

1298
server/dhcpd.conf.cat5
View File

File diff suppressed because it is too large Load Diff

210
server/dhcpd.leases.cat5
View File

@@ -1,54 +1,54 @@
dhcpd.leases(5) dhcpd.leases(5)
Headers, Environments, and Macros dhcpd.leases(5)
NNAAMMEE
NNNNAAAAMMMMEEEE
dhcpd.leases - DHCP client lease database
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP Server keeps a per<EFBFBD>
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.
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
The Internet Software Consortium DHCP Server keeps a per-
sistent database of leases that it has assigned. This data-
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.
When dhcpd is first installed, there is no lease database.
However, dhcpd requires that a lease database be present
before it will start. To make the initial lease database,
just create an empty file called /var/db/dhcpd.leases.
just create an empty file called /etc/dhcpd.leases.
In order to prevent the lease database from growing with<EFBFBD>
out bound, the file is rewritten from time to time.
First, a temporary lease database is created and all known
leases are dumped to it. Then, the old lease database is
renamed /var/db/dhcpd.leases~. Finally, the newly writ<EFBFBD>
ten lease database is moved into place.
In order to prevent the lease database from growing without
bound, the file is rewritten from time to time. First, a
temporary lease database is created and all known leases are
dumped to it. Then, the old lease database is renamed
/etc/dhcpd.leases~. Finally, the newly written lease data-
base is moved into place.
There is a window of vulnerability where if the dhcpd pro<EFBFBD>
There is a window of vulnerability where if the dhcpd pro-
cess is killed or the system crashes after the old lease
database has been renamed but before the new one has been
moved into place, there will be no /var/db/dhcpd.leases.
In this case, dhcpd will refuse to start, and will require
manual intervention. DDOO NNOOTT 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
/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.
moved into place, there will be no /etc/dhcpd.leases. In
this case, dhcpd will refuse to start, and will require
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.
FFOORRMMAATT
Lease descriptions are stored in a format that is parsed
by the same recursive descent parser used to read the
ddhhccppdd..ccoonnff((55)) and ddhhcclliieenntt..ccoonnff((55)) files. Currently, the
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 lleeaassee declaration.
the lllleeeeaaaasssseeee declaration.
lleeaassee _i_p_-_a_d_d_r_e_s_s {{ _s_t_a_t_e_m_e_n_t_s_._._. }}
lllleeeeaaaasssseeee _i_p-_a_d_d_r_e_s_s {{{{ _s_t_a_t_e_m_e_n_t_s... }}}}
Each lease declaration include the single IP address that
has been leased to the client. The statements within the
@@ -60,125 +60,127 @@ FFOORRMMAATT
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;;
ssssttttaaaarrrrttttssss _d_a_t_e;;;;
eeeennnnddddssss _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
_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. 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<EFBFBD>
ond also a number between 0 and 59.
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.
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 proba<EFBFBD>
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.
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 of the network interface that was used to
acquire the lease is recorded with the hhaarrddwwaarree statement:
acquire the lease is recorded with the hhhhaaaarrrrddddwwwwaaaarrrreeee statement:
hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _m_a_c_-_a_d_d_r_e_s_s;;
hhhhaaaarrrrddddwwwwaaaarrrreeee _h_a_r_d_w_a_r_e-_t_y_p_e _m_a_c-_a_d_d_r_e_s_s;;;;
The MAC address is specified as a series of hexadecimal
octets, seperated by colons.
If the client used a client identifier to acquire its
address, the client identifier is recorded using the uuiidd
address, the client identifier is recorded using the uuuuiiiidddd
statement:
uuiidd _c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r;;
uuuuiiiidddd _c_l_i_e_n_t-_i_d_e_n_t_i_f_i_e_r;;;;
The client identifier is recorded as a series of hexadeci<EFBFBD>
mal octets, regardless of whether the client specifies an
ASCII string or uses the newer hardware type/MAC address
format.
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 a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e
option, as specified in some versions of the DHCP-DNS
Interaction draft, that hostname is recorded using the
cclliieenntt--hhoossttnnaammee statement.
cccclllliiiieeeennnntttt----hhhhoooossssttttnnnnaaaammmmeeee statement.
cclliieenntt--hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";;
If the client sends its hostname using the _H_o_s_t_n_a_m_e
option, as Windows 95 does, it is recorded using the
2
cccclllliiiieeeennnntttt----hhhhoooossssttttnnnnaaaammmmeeee """"_h_o_s_t_n_a_m_e"""";;;;
dhcpd.leases(5) dhcpd.leases(5)
SunOS 5.6 Last change: 2
hhoossttnnaammee statement.
hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";;
The DHCP server may determine that a lease has been mis<69>
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;;
Headers, Environments, and Macros dhcpd.leases(5)
If the client sends its hostname using the _H_o_s_t_n_a_m_e option,
as Windows 95 does, it is recorded using the hhhhoooossssttttnnnnaaaammmmeeee state-
ment.
hhhhoooossssttttnnnnaaaammmmeeee """"_h_o_s_t_n_a_m_e"""";;;;
The DHCP server may determine that a lease has been misused
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 aaaabbbbaaaannnn----
ddddoooonnnneeeedddd statement will be used to indicate that the lease
should not be reassigned.
aaaabbbbaaaannnnddddoooonnnneeeedddd;;;;
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.
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 rreeqquueessttss an abandoned address, the server
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 immedi<EFBFBD>
ately assigned to the client.
machine that responded when the lease was probed, causing it
to be abandoned. In that case, the address is immediately
assigned to the client.
FFIILLEESS
//vvaarr//ddbb//ddhhccppdd..lleeaasseess
FFFFIIIILLLLEEEESSSS
////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss
SSEEEE AALLSSOO
dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132,
RFC2131.
SSSSEEEEEEEE AAAALLLLSSSSOOOO
dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
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. Informa<EFBFBD>
tion about the Internet Software Consortium can be found
at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
provided by the Internet Software Corporation. Information
about the Internet Software Consortium can be found at
hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc....
@@ -190,9 +192,7 @@ AAUUTTHHOORR
SunOS 5.6 Last change: 3
3