#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"
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;
-dhclient(8) dhclient(8)
-
-
-N\bNA\bAM\bME\bE
- dhclient-script - DHCP client network configuration script
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- The DHCP client network configuration script is invoked
- from time to time by d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b). 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
- identified.
-
- 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 /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf script.
- If you find that you can't make such a customization with
- out customizing dhclient.conf, please submit a bug report.
-
-O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
- When dhclient needs to invoke the client configuration
- script, it writes a shell script into /tmp which defines a
- variety of variables. In all cases, $reason is set to the
- name of the reason why the script has been invoked. The
- following reasons are currently defined: MEDIUM, PREINIT,
- BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL and TIMEOUT.
+Maintenance Procedures dhclient(8)
+
+
+
+N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
+ dhclient-script - DHCP client network configuration script
+
+D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ The DHCP client network configuration script is invoked from
+ time to time by d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b). 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 /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf script. If you
+ find that you can't make such a customization without cus-
+ tomizing dhclient.conf, please submit a bug report.
+
+O\bO\bO\bOP\bP\bP\bPE\bE\bE\bER\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ When dhclient needs to invoke the client configuration
+ script, it writes a shell script into /tmp which defines a
+ variety of variables. In all cases, $reason is set to the
+ name of the reason why the script has been invoked. The
+ following reasons are currently defined: MEDIUM, PREINIT,
+ BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL and TIMEOUT.
+M\bM\bM\bME\bE\bE\bED\bD\bD\bDI\bI\bI\bIU\bU\bU\bUM\bM\bM\bM
+ 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.
-M\bME\bED\bDI\bIU\bUM\bM
- 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.
+P\bP\bP\bPR\bR\bR\bRE\bE\bE\bEI\bI\bI\bIN\bN\bN\bNI\bI\bI\bIT\bT\bT\bT
+ 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.
-P\bPR\bRE\bEI\bIN\bNI\bIT\bT
- The DHCP client is requesting that an interface be config
- ured as required in order to send packets prior to receiv
- 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
- ing it an IP address at all. The interface name is
- passed in $interface, and the media type in $medium.
-
- If an IP alias has been declared in dhclient.conf, its
- address will be passed in $alias_ip_address, and that ip
- alias should be deleted from the interface, along with any
- routes to it.
-
-
-
-
- 1
-
-
-
-
-
-dhclient(8) dhclient(8)
-
-
-B\bBO\bOU\bUN\bND\bD
- 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 d\bdh\bhc\bcp\bp-\b-o\bop\bpt\bti\bio\bon\bns\bs, except that dashes
- ('-') are replaced by underscores ('_') in order to make
- valid shell variables, and the variable names start with
- new_. So for example, the new subnet mask would be
- passed in $new_subnet_mask.
-
- Before actually configuring the address, dhclient-script
- should somehow ARP for it and exit with a nonzero status
- if it receives a reply. In this case, the client will
- send a DHCPDECLINE message to the server and acquire a
- different address. This may also be done in the RENEW,
- REBIND, or REBOOT states, but is not required, and indeed
- may not be desirable.
-
- When a binding has been completed, a lot of network param
- eters are likely to need to be set up. A new
- /etc/resolv.conf needs to be created, using the values of
- $new_domain_name and $new_domain_name_servers (which may
- list more than one server, seperated by spaces). A
- default route should be set using $new_routers, and static
- routes may need to be set up using $new_static_routes.
-
- If an IP alias has been declared, it must be set up here.
- The alias IP address will be written as $alias_ip_address,
- and other DHCP options that are set for the alias (e.g.,
- subnet mask) will be passed in variables named as
- described previously except starting with $alias_ instead
- of $new_. Care should be taken that the alias IP address
- not be used if it is identical to the bound IP address
- ($new_ip_address), since the other alias parameters may be
- incorrect in this case.
-
-R\bRE\bEN\bNE\bEW\bW
- 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.
+ If an IP alias has been declared in dhclient.conf, its
+ address will be passed in $alias_ip_address, and that ip
+ alias should be deleted from the interface, along with any
+ routes to it.
-R\bRE\bEB\bBI\bIN\bND\bD
- The DHCP client has rebound to a new DHCP server. This
- can be handled as with RENEW, except that if the IP
- address has changed, the ARP table should be cleared.
+SunOS 5.6 Last change: 1
- 2
-dhclient(8) dhclient(8)
+Maintenance Procedures dhclient(8)
-R\bRE\bEB\bBO\bOO\bOT\bT
- The DHCP client has successfully reacquired its old
- address after a reboot. This can be processed as with
- BOUND.
-E\bEX\bXP\bPI\bIR\bRE\bE
- 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.
+B\bB\bB\bBO\bO\bO\bOU\bU\bU\bUN\bN\bN\bND\bD\bD\bD
+ 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 d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-
+ o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs, 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.
-F\bFA\bAI\bIL\bL
- 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.
+ Before actually configuring the address, dhclient-script
+ should somehow ARP for it and exit with a nonzero status if
+ it receives a reply. In this case, the client will send a
+ DHCPDECLINE message to the server and acquire a different
+ address. This may also be done in the RENEW, REBIND, or
+ REBOOT states, but is not required, and indeed may not be
+ desirable.
+
+ When a binding has been completed, a lot of network 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.
-T\bTI\bIM\bME\bEO\bOU\bUT\bT
- 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.
+ If an IP alias has been declared, it must be set up here.
+ The alias IP address will be written as $alias_ip_address,
+ and other DHCP options that are set for the alias (e.g.,
+ subnet mask) will be passed in variables named as described
+ previously except starting with $alias_ instead of $new_.
+ Care should be taken that the alias IP address not be used
+ if it is identical to the bound IP address
+ ($new_ip_address), since the other alias parameters may be
+ incorrect in this case.
- 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.
+R\bR\bR\bRE\bE\bE\bEN\bN\bN\bNE\bE\bE\bEW\bW\bW\bW
+ 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.
-F\bFI\bIL\bLE\bES\bS
- Each operating system should generally have its own script
- file, although the script files for similar operating sys
- tems may be similar or even identical. The script files
- included in the Internet Software Consortium DHCP distri
- bution appear in the distribution tree under
- client/scripts, and bear the names of the operating sys
- tems on which they are intended to work.
+R\bR\bR\bRE\bE\bE\bEB\bB\bB\bBI\bI\bI\bIN\bN\bN\bND\bD\bD\bD
+ The DHCP client has rebound to a new DHCP server. This can
+ be handled as with RENEW, except that if the IP address has
-B\bBU\bUG\bGS\bS
- If more than one interface is being used, there's no obvi
- ous way to avoid clashes between server-supplied configu
- 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
- tialized to the values provided by one server, and then
- the other. Assuming the information provided by both
+SunOS 5.6 Last change: 2
- 3
-dhclient(8) dhclient(8)
+Maintenance Procedures dhclient(8)
- servers is valid, this shouldn't cause any real problems,
- but it could be confusing.
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and
- dhclient.leases(5).
+ changed, the ARP table should be cleared.
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcl\bli\bie\ben\bnt\bt-\b-s\bsc\bcr\bri\bip\bpt\bt(\b(8\b8)\b) has been written for the Internet Soft
- ware Consortium by Ted Lemon <mellon@fugue.com> in cooper
- ation with Vixie Enterprises. To learn more about the
- Internet Software Consortium, see h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm/\b/i\bis\bsc\bc.\b.
- To learn more about Vixie Enterprises, see
- h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm.\b.
+R\bR\bR\bRE\bE\bE\bEB\bB\bB\bBO\bO\bO\bOO\bO\bO\bOT\bT\bT\bT
+ The DHCP client has successfully reacquired its old address
+ after a reboot. This can be processed as with BOUND.
+E\bE\bE\bEX\bX\bX\bXP\bP\bP\bPI\bI\bI\bIR\bR\bR\bRE\bE\bE\bE
+ 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.
+F\bF\bF\bFA\bA\bA\bAI\bI\bI\bIL\bL\bL\bL
+ 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.
+T\bT\bT\bTI\bI\bI\bIM\bM\bM\bME\bE\bE\bEO\bO\bO\bOU\bU\bU\bUT\bT\bT\bT
+ 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.
+F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
+ Each operating system should generally have its own script
+ file, although the script files for similar operating sys-
+ tems may be similar or even identical. The script files
+ included in the Internet Software Consortium DHCP distribu-
+ tion appear in the distribution tree under client/scripts,
+ and bear the names of the operating systems on which they
+ are intended to work.
+B\bB\bB\bBU\bU\bU\bUG\bG\bG\bGS\bS\bS\bS
+ If more than one interface is being used, there's no obvious
+ way to avoid clashes between server-supplied configuration
+ parameters - for example, the stock dhclient-script rewrites
+ /etc/resolv.conf. If more than one interface is being con-
+ figured, /etc/resolv.conf will be repeatedly initialized to
+ the values provided by one server, and then the other.
+SunOS 5.6 Last change: 3
+Maintenance Procedures dhclient(8)
+ Assuming the information provided by both servers is valid,
+ this shouldn't cause any real problems, but it could be
+ confusing.
+S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
+ dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and
+ dhclient.leases(5).
+A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt-\b-\b-\b-s\bs\bs\bsc\bc\bc\bcr\br\br\bri\bi\bi\bip\bp\bp\bpt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) 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 h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b. To
+ learn more about Vixie Enterprises, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm.\b.\b.\b.
- 4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+SunOS 5.6 Last change: 4
+
-dhclient(8) dhclient(8)
-
+Maintenance Procedures dhclient(8)
-N\bNA\bAM\bME\bE
- dhclient - Dynamic Host Configuration Protocol Client
-S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
- d\bdh\bhc\bcl\bli\bie\ben\bnt\bt [ -\b-p\bp _\bp_\bo_\br_\bt ] [ -\b-d\bd ] [ _\bi_\bf_\b0 [ _\b._\b._\b._\bi_\bf_\bN ] ]
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- 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.
+N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
+ dhclient - Dynamic Host Configuration Protocol Client
-O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
- 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.
+S\bS\bS\bSY\bY\bY\bYN\bN\bN\bNO\bO\bO\bOP\bP\bP\bPS\bS\bS\bSI\bI\bI\bIS\bS\bS\bS
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt [ -\b-\b-\b-p\bp\bp\bp _\bp_\bo_\br_\bt ] [ -\b-\b-\b-d\bd\bd\bd ] [ _\bi_\bf_\b0 [ ..._\bi_\bf_\bN ] ]
- On startup, dhclient reads the _\bd_\bh_\bc_\bl_\bi_\be_\bn_\bt_\b._\bc_\bo_\bn_\bf for configu
- ration instructions. It then gets a list of all the net
- work interfaces that are configured in the current system.
- For each interface, it attempts to configure the interface
- using the DHCP protocol.
+D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ 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.
- 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.
+O\bO\bO\bOP\bP\bP\bPE\bE\bE\bER\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ 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.
- 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
- _\bd_\bh_\bc_\bp_\bd_\b._\bl_\be_\ba_\bs_\be_\bs_\b~ until the next time dhclient rewrites the
- database.
+ On startup, dhclient reads the _\bd_\bh_\bc_\bl_\bi_\be_\bn_\bt._\bc_\bo_\bn_\bf 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.
- Old leases are kept around in case the DHCP server is
- unavailable when dhclient is first invoked (generally dur
- ing the initial system boot process). In that event, old
- leases from the dhclient.leases file which have not yet
- expired are tested, and if they are determined to be
- valid, they are used until either they expire or the DHCP
- server becomes available.
+ In order to keep track of leases across system reboots and
+ server restarts, dhclient keeps a list of leases it has been
+ assigned in the dhclient.leases(5) file. On startup, after
+ reading the dhclient.conf file, dhclient reads the
+ dhclient.leases file to refresh its memory about what leases
+ it has been assigned.
+ When a new lease is acquired, it is appended to the end of
+ the dhclient.leases file. In order to prevent the file
+ from becoming arbitrarily large, from time to time dhclient
+ creates a new dhclient.leases file from its in-core lease
+ database. The old version of the dhclient.leases file is
+ retained under the name _\bd_\bh_\bc_\bp_\bd._\bl_\be_\ba_\bs_\be_\bs~ until the next time
+ dhclient rewrites the database.
+ Old leases are kept around in case the DHCP server is una-
+ vailable when dhclient is first invoked (generally during
+ the initial system boot process). In that event, old
+ leases from the dhclient.leases file which have not yet
+ expired are tested, and if they are determined to be valid,
+ they are used until either they expire or the DHCP server
+ becomes available.
- 1
+SunOS 5.6 Last change: 1
-dhclient(8) dhclient(8)
- A mobile host which may sometimes need to access a network
- 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.
+Maintenance Procedures dhclient(8)
- 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.
-C\bCO\bOM\bMM\bMA\bAN\bND\bD L\bLI\bIN\bNE\bE
- 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
- ing non-broadcast interfaces if possible, and attempt to
- configure each interface.
- If dhclient should listen and transmit on a port other
- than the standard (port 68), the -\b-p\bp flag may used. It
- should be followed by the udp port number that dhclient
- should use. This is mostly useful for debugging purposes.
+ 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.
- 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 -\b-d\bd flag should be specified.
- This is useful when running dhclient under a debugger, or
- when running it out of inittab on System V systems.
+ 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.
+C\bC\bC\bCO\bO\bO\bOM\bM\bM\bMM\bM\bM\bMA\bA\bA\bAN\bN\bN\bND\bD\bD\bD L\bL\bL\bLI\bI\bI\bIN\bN\bN\bNE\bE\bE\bE
+ The names of the network interfaces that dhclient should
+ attempt to configure may be specified on the command line.
+ If no interface names are specified on the command line
+ dhclient will identify all network interfaces, elimininating
+ non-broadcast interfaces if possible, and attempt to config-
+ ure each interface.
-C\bCO\bON\bNF\bFI\bIG\bGU\bUR\bRA\bAT\bTI\bIO\bON\bN
- The syntax of the dhclient.conf(8) file is discussed
- seperately.
+ If dhclient should listen and transmit on a port other than
+ the standard (port 68), the -\b-\b-\b-p\bp\bp\bp flag may used. It should be
+ followed by the udp port number that dhclient should use.
+ This is mostly useful for debugging purposes.
-F\bFI\bIL\bLE\bES\bS
- /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf,\b, /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.l\ble\bea\bas\bse\bes\bs,\b,
- /\b/v\bva\bar\br/\b/r\bru\bun\bn/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.p\bpi\bid\bd,\b, /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.l\ble\bea\bas\bse\bes\bs~\b~.\b.
+ 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 -\b-\b-\b-d\bd\bd\bd flag should be specified. This
+ is useful when running dhclient under a debugger, or when
+ running it out of inittab on System V systems.
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd(8), dhcrelay(8), dhclient.conf(5),
- dhclient.leases(5)
+C\bC\bC\bCO\bO\bO\bON\bN\bN\bNF\bF\bF\bFI\bI\bI\bIG\bG\bG\bGU\bU\bU\bUR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ The syntax of the dhclient.conf(8) file is discussed
+ seperately.
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b) 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 h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm/\b/i\bis\bsc\bc.\b. To learn
- more about Vixie Enterprises, see h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm.\b.
+F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
+ /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf,\b,\b,\b, /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs,\b,\b,\b, /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.p\bp\bp\bpi\bi\bi\bid\bd\bd\bd,\b,\b,\b,
+ /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs~\b~\b~\b~.\b.\b.\b.
+S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
+ dhcpd(8), dhcrelay(8), dhclient.conf(5), dhclient.leases(5)
+A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) 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 h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b. To learn
+ more about Vixie Enterprises, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm.\b.\b.\b.
- 2
+SunOS 5.6 Last change: 2
-dhclient(8) dhclient(8)
- This client was substantially modified and enhanced by
- Elliot Poger for use on Linux while he was working on the
- MosquitoNet project at Stanford.
- The current version owes much to Elliot's Linux enhance
- 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.
+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-
+ ments, but was substantially reorganized and partially
+ rewritten by Ted Lemon so as to use the same networking
+ framework that the Internet Software Consortium DHCP server
+ uses. Much system-specific configuration code was moved
+ into a shell script so that as support for more operating
+ systems is added, it will not be necessary to port and main-
+ tain system-specific configuration code to these operating
+ systems - instead, the shell script can invoke the native
+ tools to accomplish the same purpose.
+
+
+
+SunOS 5.6 Last change: 3
- 3
-dhclient.conf(5) dhclient.conf(5)
+Headers, Environments, and Macros dhclient.conf(5)
-N\bNA\bAM\bME\bE
- dhclient.conf - DHCP client configuration file
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- The dhclient.conf file contains configuration information
- for _\bd_\bh_\bc_\bl_\bi_\be_\bn_\bt_\b, the Internet Software Consortium DHCP
- Client.
+N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
+ dhclient.conf - DHCP client configuration file
- 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.
+D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ The dhclient.conf file contains configuration information
+ for _\bd_\bh_\bc_\bl_\bi_\be_\bn_\bt, the Internet Software Consortium DHCP Client.
- The dhclient.conf file can be used to configure the
- behaviour of the client in a wide variety of ways: proto
- col timing, information requested from the server, infor
- 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.
+ 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.
-P\bPR\bRO\bOT\bTO\bOC\bCO\bOL\bL T\bTI\bIM\bMI\bIN\bNG\bG
- 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 dhclient.conf file can be used to configure the
+ 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.
- The following statements can be used to adjust the timing
- behaviour of the DHCP client if required, however:
+P\bP\bP\bPR\bR\bR\bRO\bO\bO\bOT\bT\bT\bTO\bO\bO\bOC\bC\bC\bCO\bO\bO\bOL\bL\bL\bL T\bT\bT\bTI\bI\bI\bIM\bM\bM\bMI\bI\bI\bIN\bN\bN\bNG\bG\bG\bG
+ 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.
- _\bT_\bh_\be t\bti\bim\bme\beo\bou\but\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ The following statements can be used to adjust the timing
+ behaviour of the DHCP client if required, however:
- t\bti\bim\bme\beo\bou\but\bt _\bt_\bi_\bm_\be ;\b;
+ _\bT_\bh_\be t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\beo\bo\bo\bou\bu\bu\but\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- The _\bt_\bi_\bm_\be_\bo_\bu_\bt 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
- 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.
+ t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\beo\bo\bo\bou\bu\bu\but\bt\bt\bt _\bt_\bi_\bm_\be ;\b;\b;\b;
+ The _\bt_\bi_\bm_\be_\bo_\bu_\bt statement determines the amount of time that
+ must pass between the time that the client begins to try to
+ determine its address and the time that it decides that it's
+ not going to be able to contact a server. By default, this
+ timeout is sixty seconds. After the timeout has passed, if
+ there are any static leases defined in the configuration
+ file, or any leases remaining in the lease database that
+ have not yet expired, the client will loop through these
+ leases attempting to validate them, and if it finds one that
+ appears to be valid, it will use that lease's address. If
+ there are no valid static leases or unexpired leases in the
+ lease database, the client will restart the protocol after
+ the defined retry interval.
- 1
+SunOS 5.6 Last change: 1
-dhclient.conf(5) dhclient.conf(5)
- _\bT_\bh_\be r\bre\bet\btr\bry\by _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+Headers, Environments, and Macros dhclient.conf(5)
- r\bre\bet\btr\bry\by _\bt_\bi_\bm_\be;\b;
- The _\br_\be_\bt_\br_\by 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.
- _\bT_\bh_\be s\bse\bel\ble\bec\bct\bt-\b-t\bti\bim\bme\beo\bou\but\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ _\bT_\bh_\be r\br\br\bre\be\be\bet\bt\bt\btr\br\br\bry\by\by\by _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- s\bse\bel\ble\bec\bct\bt-\b-t\bti\bim\bme\beo\bou\but\bt _\bt_\bi_\bm_\be;\b;
+ r\br\br\bre\be\be\bet\bt\bt\btr\br\br\bry\by\by\by _\bt_\bi_\bm_\be;\b;\b;\b;
- 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
- able to the other (e.g., one offer may have the address
- the client previously used, and the other may not).
+ The _\br_\be_\bt_\br_\by 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.
- The _\bs_\be_\bl_\be_\bc_\bt_\b-_\bt_\bi_\bm_\be_\bo_\bu_\bt 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 _\bs_\be_\bl_\be_\bc_\bt_\b-_\bt_\bi_\bm_\be_\bo_\bu_\bt has expired, the client will
- accept the first offer that arrives.
+ _\bT_\bh_\be s\bs\bs\bse\be\be\bel\bl\bl\ble\be\be\bec\bc\bc\bct\bt\bt\bt-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\beo\bo\bo\bou\bu\bu\but\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- By default, the select-timeout is zero seconds - that is,
- the client will take the first offer it sees.
+ s\bs\bs\bse\be\be\bel\bl\bl\ble\be\be\bec\bc\bc\bct\bt\bt\bt-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\beo\bo\bo\bou\bu\bu\but\bt\bt\bt _\bt_\bi_\bm_\be;\b;\b;\b;
- _\bT_\bh_\be r\bre\beb\bbo\boo\bot\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ It is possible (some might say desirable) for there to be
+ more than one DHCP server serving any given network. In
+ this case, it is possible that a client may be sent more
+ than one offer in response to its initial lease discovery
+ message. It may be that one of these offers is preferable
+ to the other (e.g., one offer may have the address the
+ client previously used, and the other may not).
- r\bre\beb\bbo\boo\bot\bt _\bt_\bi_\bm_\be;\b;
+ The _\bs_\be_\bl_\be_\bc_\bt-_\bt_\bi_\bm_\be_\bo_\bu_\bt 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 _\bs_\be_\bl_\be_\bc_\bt-_\bt_\bi_\bm_\be_\bo_\bu_\bt has expired, the client will accept
+ the first offer that arrives.
- 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 _\br_\be_\bb_\bo_\bo_\bt 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.
+ By default, the select-timeout is zero seconds - that is,
+ the client will take the first offer it sees.
- _\bT_\bh_\be b\bba\bac\bck\bko\bof\bff\bf-\b-c\bcu\but\bto\bof\bff\bf _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ _\bT_\bh_\be r\br\br\bre\be\be\beb\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- b\bba\bac\bck\bko\bof\bff\bf-\b-c\bcu\but\bto\bof\bff\bf _\bt_\bi_\bm_\be;\b;
+ r\br\br\bre\be\be\beb\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bt _\bt_\bi_\bm_\be;\b;\b;\b;
- The client uses an exponential backoff algorithm with some
- randomness, so that if many clients try to configure them
- selves at the same time, they will not make their requests
- in lockstep. The _\bb_\ba_\bc_\bk_\bo_\bf_\bf_\b-_\bc_\bu_\bt_\bo_\bf_\bf statement determines the
- maximum amount of time that the client is allowed to back
- off. It defaults to two minutes.
+ 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 _\br_\be_\bb_\bo_\bo_\bt 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.
+ _\bT_\bh_\be b\bb\bb\bba\ba\ba\bac\bc\bc\bck\bk\bk\bko\bo\bo\bof\bf\bf\bff\bf\bf\bf-\b-\b-\b-c\bc\bc\bcu\bu\bu\but\bt\bt\bto\bo\bo\bof\bf\bf\bff\bf\bf\bf _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ b\bb\bb\bba\ba\ba\bac\bc\bc\bck\bk\bk\bko\bo\bo\bof\bf\bf\bff\bf\bf\bf-\b-\b-\b-c\bc\bc\bcu\bu\bu\but\bt\bt\bto\bo\bo\bof\bf\bf\bff\bf\bf\bf _\bt_\bi_\bm_\be;\b;\b;\b;
- 2
+ The client uses an exponential backoff algorithm with some
+ randomness, so that if many clients try to configure them-
+ selves at the same time, they will not make their requests
+ in lockstep. The _\bb_\ba_\bc_\bk_\bo_\bf_\bf-_\bc_\bu_\bt_\bo_\bf_\bf statement determines the
+SunOS 5.6 Last change: 2
-dhclient.conf(5) dhclient.conf(5)
- _\bT_\bh_\be i\bin\bni\bit\bti\bia\bal\bl-\b-i\bin\bnt\bte\ber\brv\bva\bal\bl _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- i\bin\bni\bit\bti\bia\bal\bl-\b-i\bin\bnt\bte\ber\brv\bva\bal\bl _\bt_\bi_\bm_\be;\b;
- The _\bi_\bn_\bi_\bt_\bi_\ba_\bl_\b-_\bi_\bn_\bt_\be_\br_\bv_\ba_\bl 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
- onds.
+Headers, Environments, and Macros dhclient.conf(5)
-L\bLE\bEA\bAS\bSE\bE R\bRE\bEQ\bQU\bUI\bIR\bRE\bEM\bME\bEN\bNT\bTS\bS A\bAN\bND\bD R\bRE\bEQ\bQU\bUE\bES\bST\bTS\bS
- 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
- tocol also allows the client to reject offers from servers
- if they don't contain information the client needs, or if
- the information provided is not satisfactory.
- There is a variety of data contained in offers that DHCP
- servers send to DHCP clients. The data that can be
- specifically requested is what are called _\bD_\bH_\bC_\bP _\bO_\bp_\bt_\bi_\bo_\bn_\bs.
- DHCP Options are defined in
- d\bdh\bhc\bcp\bp-\b-o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b).
- _\bT_\bh_\be r\bre\beq\bqu\bue\bes\bst\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ maximum amount of time that the client is allowed to back
+ off. It defaults to two minutes.
- r\bre\beq\bqu\bue\bes\bst\bt [\b[ _\bo_\bp_\bt_\bi_\bo_\bn ] [,\b, _\b._\b._\b. _\bo_\bp_\bt_\bi_\bo_\bn ];\b;
+ _\bT_\bh_\be i\bi\bi\bin\bn\bn\bni\bi\bi\bit\bt\bt\bti\bi\bi\bia\ba\ba\bal\bl\bl\bl-\b-\b-\b-i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brv\bv\bv\bva\ba\ba\bal\bl\bl\bl _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- 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.
+ i\bi\bi\bin\bn\bn\bni\bi\bi\bit\bt\bt\bti\bi\bi\bia\ba\ba\bal\bl\bl\bl-\b-\b-\b-i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brv\bv\bv\bva\ba\ba\bal\bl\bl\bl _\bt_\bi_\bm_\be;\b;\b;\b;
- _\bT_\bh_\be r\bre\beq\bqu\bui\bir\bre\be _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ The _\bi_\bn_\bi_\bt_\bi_\ba_\bl-_\bi_\bn_\bt_\be_\br_\bv_\ba_\bl statement sets the amount of time
+ between the first attempt to reach a server and the second
+ attempt to reach a server. Each time a message is sent, the
+ interval between messages is incremented by twice the
+ current interval multiplied by a random number between zero
+ and one. If it is greater than the backoff-cutoff amount,
+ it is set to that amount. It defaults to ten seconds.
- r\bre\beq\bqu\bui\bir\bre\be [\b[ _\bo_\bp_\bt_\bi_\bo_\bn ] [,\b, _\b._\b._\b. _\bo_\bp_\bt_\bi_\bo_\bn _\b];\b;
+L\bL\bL\bLE\bE\bE\bEA\bA\bA\bAS\bS\bS\bSE\bE\bE\bE R\bR\bR\bRE\bE\bE\bEQ\bQ\bQ\bQU\bU\bU\bUI\bI\bI\bIR\bR\bR\bRE\bE\bE\bEM\bM\bM\bME\bE\bE\bEN\bN\bN\bNT\bT\bT\bTS\bS\bS\bS A\bA\bA\bAN\bN\bN\bND\bD\bD\bD R\bR\bR\bRE\bE\bE\bEQ\bQ\bQ\bQU\bU\bU\bUE\bE\bE\bES\bS\bS\bST\bT\bT\bTS\bS\bS\bS
+ The DHCP protocol allows the client to request that the
+ server send it specific information, and not send it other
+ information that it is not prepared to accept. The proto-
+ col also allows the client to reject offers from servers if
+ they don't contain information the client needs, or if the
+ information provided is not satisfactory.
- The require statement lists options that must be sent in
- order for an offer to be accepted. Offers that do not
- contain all the listed options will be ignored.
+ There is a variety of data contained in offers that DHCP
+ servers send to DHCP clients. The data that can be specifi-
+ cally requested is what are called _\bD_\bH_\bC_\bP _\bO_\bp_\bt_\bi_\bo_\bn_\bs. DHCP
+ Options are defined in
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs(\b(\b(\b(5\b5\b5\b5)\b)\b)\b).
- _\bT_\bh_\be s\bse\ben\bnd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ _\bT_\bh_\be r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bue\be\be\bes\bs\bs\bst\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- s\bse\ben\bnd\bd {\b{ [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] [,\b, _\b._\b._\b. _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn
- ]}\b}
+ r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bue\be\be\bes\bs\bs\bst\bt\bt\bt [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn ] [,\b,\b,\b, ... _\bo_\bp_\bt_\bi_\bo_\bn ];\b;\b;\b;
- 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 d\bdh\bhc\bcp\bp-\b-
- o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b). Options that are always sent in the DHCP
+ 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.
+ _\bT_\bh_\be r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bui\bi\bi\bir\br\br\bre\be\be\be _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bui\bi\bi\bir\br\br\bre\be\be\be [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn ] [,\b,\b,\b, ... _\bo_\bp_\bt_\bi_\bo_\bn ];\b;\b;\b;
- 3
+ The require statement lists options that must be sent in
+ order for an offer to be accepted. Offers that do not con-
+ tain all the listed options will be ignored.
+ _\bT_\bh_\be s\bs\bs\bse\be\be\ben\bn\bn\bnd\bd\bd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ s\bs\bs\bse\be\be\ben\bn\bn\bnd\bd\bd\bd {\b{\b{\b{ [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] [,\b,\b,\b, ... _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ]}\b}\b}\b}
+ The send statement causes the client to send the specified
+ options to the server with the specified values. These are
-dhclient.conf(5) dhclient.conf(5)
+SunOS 5.6 Last change: 3
- protocol should not be specified here, except that the
- client can specify a r\bre\beq\bqu\bue\bes\bst\bte\bed\bd-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be option other
- than the default requested lease time, which is two hours.
- The other obvious use for this statement is to send infor
- mation to the server that will allow it to differentiate
- between this client and other clients or kinds of clients.
-O\bOP\bPT\bTI\bIO\bON\bN M\bMO\bOD\bDI\bIF\bFI\bIE\bER\bRS\bS
- 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
- mation which is useful, but which needs to be supplemented
- with local information. To handle these needs, several
- option modifiers are available.
- _\bT_\bh_\be d\bde\bef\bfa\bau\bul\blt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- d\bde\bef\bfa\bau\bul\blt\bt [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;
- If for some option the client should use the value sup
- 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 d\bde\bef\bfa\bau\bul\blt\bt statement.
- _\bT_\bh_\be s\bsu\bup\bpe\ber\brs\bse\bed\bde\be _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+Headers, Environments, and Macros dhclient.conf(5)
- s\bsu\bup\bpe\ber\brs\bse\bed\bde\be [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;
- If for some option the client should always use a locally-
- configured value or values rather than whatever is sup
- plied by the server, these values can be defined in the
- s\bsu\bup\bpe\ber\brs\bse\bed\bde\be statement.
- _\bT_\bh_\be p\bpr\bre\bep\bpe\ben\bnd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ full option declarations as described in d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs(\b(\b(\b(5\b5\b5\b5)\b)\b)\b).
+ Options that are always sent in the DHCP protocol should not
+ be specified here, except that the client can specify a
+ r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bue\be\be\bes\bs\bs\bst\bt\bt\bte\be\be\bed\bd\bd\bd-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\be 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.
- p\bpr\bre\bep\bpe\ben\bnd\bd [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;
+O\bO\bO\bOP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN M\bM\bM\bMO\bO\bO\bOD\bD\bD\bDI\bI\bI\bIF\bF\bF\bFI\bI\bI\bIE\bE\bE\bER\bR\bR\bRS\bS\bS\bS
+ In some cases, a client may receive option data from the
+ server which is not really appropriate for that client, or
+ may not receive information that it needs, and for which a
+ useful default value exists. It may also receive informa-
+ tion which is useful, but which needs to be supplemented
+ with local information. To handle these needs, several
+ option modifiers are available.
- If for some option the client should use both a value it
- supplies, and then any values supplied by the server,
- these values can be defined in the p\bpr\bre\bep\bpe\ben\bnd\bd statement.
- The p\bpr\bre\bep\bpe\ben\bnd\bd statement can only be used for options which
- allow more than one value to be given.
+ _\bT_\bh_\be d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- _\bT_\bh_\be a\bap\bpp\bpe\ben\bnd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;\b;\b;
- a\bap\bpp\bpe\ben\bnd\bd [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;
+ 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 d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt statement.
- If for some option the client should first any values sup
- plied to it by the server, and then some values it sup
- plies, those values should be defined in the a\bap\bpp\bpe\ben\bnd\bd state
- ment. The a\bap\bpp\bpe\ben\bnd\bd statement can only be used for options
- which allow more than one value to be given.
+ _\bT_\bh_\be s\bs\bs\bsu\bu\bu\bup\bp\bp\bpe\be\be\ber\br\br\brs\bs\bs\bse\be\be\bed\bd\bd\bde\be\be\be _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ s\bs\bs\bsu\bu\bu\bup\bp\bp\bpe\be\be\ber\br\br\brs\bs\bs\bse\be\be\bed\bd\bd\bde\be\be\be [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;\b;\b;
+ If for some option the client should always use a locally-
+ configured value or values rather than whatever is supplied
+ by the server, these values can be defined in the s\bs\bs\bsu\bu\bu\bup\bp\bp\bpe\be\be\ber\br\br\brs\bs\bs\bse\be\be\bed\bd\bd\bde\be\be\be
+ statement.
+ _\bT_\bh_\be p\bp\bp\bpr\br\br\bre\be\be\bep\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- 4
+ p\bp\bp\bpr\br\br\bre\be\be\bep\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;\b;\b;
+ 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 p\bp\bp\bpr\br\br\bre\be\be\bep\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd statement. The
+ p\bp\bp\bpr\br\br\bre\be\be\bep\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd statement can only be used for options which allow
+ more than one value to be given.
+ _\bT_\bh_\be a\ba\ba\bap\bp\bp\bpp\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ a\ba\ba\bap\bp\bp\bpp\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;\b;\b;
+ If for some option the client should first any values sup-
+ plied to it by the server, and then some values it supplies,
-dhclient.conf(5) dhclient.conf(5)
-L\bLE\bEA\bAS\bSE\bE D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
- _\bT_\bh_\be l\ble\bea\bas\bse\be _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn
+SunOS 5.6 Last change: 4
- l\ble\bea\bas\bse\be {\b{ _\bl_\be_\ba_\bs_\be_\b-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn [ ... _\bl_\be_\ba_\bs_\be_\b-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn _\b] }\b}
- The DHCP client may decide after some period of time (see
- P\bPR\bRO\bOT\bTO\bOC\bCO\bOL\bL T\bTI\bIM\bMI\bIN\bNG\bG) 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 _\bf_\bi_\bx_\be_\bd 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 l\ble\bea\bas\bse\be statement.
- NOTE: the lease statement is also used in the
- dhclient.leases file in order to record leases that have
- been received from DHCP servers. Some of the syntax for
- leases as described below is only needed in the
- dhclient.leases file. Such syntax is documented here for
- completeness.
- A lease statement consists of the lease keyword, followed
- by a left curly brace, followed by one or more lease dec
- laration statements, followed by a right curly brace.
- The following lease declarations are possible:
- b\bbo\boo\bot\btp\bp;\b;
- The b\bbo\boo\bot\btp\bp 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.
+Headers, Environments, and Macros dhclient.conf(5)
- i\bin\bnt\bte\ber\brf\bfa\bac\bce\be "\b"_\bs_\bt_\br_\bi_\bn_\bg"\b";\b;
- The i\bin\bnt\bte\ber\brf\bfa\bac\bce\be 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
- fied, although this is not required.
- f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
+ those values should be defined in the a\ba\ba\bap\bp\bp\bpp\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd statement.
+ The a\ba\ba\bap\bp\bp\bpp\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd statement can only be used for options which
+ allow more than one value to be given.
- The f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs 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).
+L\bL\bL\bLE\bE\bE\bEA\bA\bA\bAS\bS\bS\bSE\bE\bE\bE D\bD\bD\bDE\bE\bE\bEC\bC\bC\bCL\bL\bL\bLA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
+ _\bT_\bh_\be l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn
+ l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be {\b{\b{\b{ _\bl_\be_\ba_\bs_\be-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn [ ... _\bl_\be_\ba_\bs_\be-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] }\b}\b}\b}
+ The DHCP client may decide after some period of time (see
+ P\bP\bP\bPR\bR\bR\bRO\bO\bO\bOT\bT\bT\bTO\bO\bO\bOC\bC\bC\bCO\bO\bO\bOL\bL\bL\bL T\bT\bT\bTI\bI\bI\bIM\bM\bM\bMI\bI\bI\bIN\bN\bN\bNG\bG\bG\bG) 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 _\bf_\bi_\bx_\be_\bd 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 l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be statement.
+ NOTE: the lease statement is also used in the
+ dhclient.leases file in order to record leases that have
+ been received from DHCP servers. Some of the syntax for
+ leases as described below is only needed in the
+ dhclient.leases file. Such syntax is documented here for
+ completeness.
- 5
+ A lease statement consists of the lease keyword, followed by
+ a left curly brace, followed by one or more lease declara-
+ tion statements, followed by a right curly brace. The fol-
+ lowing lease declarations are possible:
+ b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp;\b;\b;\b;
+ The b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp 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.
+ i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brf\bf\bf\bfa\ba\ba\bac\bc\bc\bce\be\be\be "\b"\b"\b"_\bs_\bt_\br_\bi_\bn_\bg"\b"\b"\b";\b;\b;\b;
+ The i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brf\bf\bf\bfa\ba\ba\bac\bc\bc\bce\be\be\be 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)
- f\bfi\bil\ble\ben\bna\bam\bme\be "\b"_\bs_\bt_\br_\bi_\bn_\bg"\b";\b;
- The f\bfi\bil\ble\ben\bna\bam\bme\be 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.
- s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be "\b"_\bs_\bt_\br_\bi_\bn_\bg"\b";\b;
+SunOS 5.6 Last change: 5
- The s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be statement specifies the name of the boot
- server name to use. This is also not used by the stan
- dard client configuration script.
- o\bop\bpt\bti\bio\bon\bn _\bo_\bp_\bt_\bi_\bo_\bn_\b-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn;\b;
- The o\bop\bpt\bti\bio\bon\bn statement is used to specify the value of an
- option supplied by the server, or, in the case of prede
- fined leases declared in dhclient.conf, the value that the
- user wishes the client configuration script to use if the
- predefined lease is used.
- s\bsc\bcr\bri\bip\bpt\bt "\b"_\bs_\bc_\br_\bi_\bp_\bt_\b-_\bn_\ba_\bm_\be"\b";\b;
- The s\bsc\bcr\bri\bip\bpt\bt 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
- uration prior to requesting an address, to test the
- address once it has been offered, and to set the inter
- face's final configuration once a lease has been acquired.
- If no lease is acquired, the script is used to test prede
- fined leases, if any, and also called once if no valid
- lease can be identified. For more information, see
- d\bdh\bhc\bcl\bli\bie\ben\bnt\bt-\b-l\ble\bea\bas\bse\be(\b(8\b8)\b).\b.
- m\bme\bed\bdi\biu\bum\bm "\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b";\b;
+Headers, Environments, and Macros dhclient.conf(5)
- The m\bme\bed\bdi\biu\bum\bm 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 m\bme\bed\bdi\bia\ba statement) when con
- 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.
- r\bre\ben\bne\bew\bw _\bd_\ba_\bt_\be;\b;
+ f\bf\bf\bfi\bi\bi\bix\bx\bx\bxe\be\be\bed\bd\bd\bd-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\bre\be\be\bes\bs\bs\bss\bs\bs\bs _\bi_\bp-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;\b;\b;
- r\bre\beb\bbi\bin\bnd\bd _\bd_\ba_\bt_\be;\b;
+ The f\bf\bf\bfi\bi\bi\bix\bx\bx\bxe\be\be\bed\bd\bd\bd-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\bre\be\be\bes\bs\bs\bss\bs\bs\bs 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).
+ f\bf\bf\bfi\bi\bi\bil\bl\bl\ble\be\be\ben\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bs_\bt_\br_\bi_\bn_\bg"\b"\b"\b";\b;\b;\b;
+ The f\bf\bf\bfi\bi\bi\bil\bl\bl\ble\be\be\ben\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be 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.
+ s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br-\b-\b-\b-n\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bs_\bt_\br_\bi_\bn_\bg"\b"\b"\b";\b;\b;\b;
- 6
+ The s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br-\b-\b-\b-n\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be statement specifies the name of the boot
+ server name to use. This is also not used by the standard
+ client configuration script.
+ o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bn _\bo_\bp_\bt_\bi_\bo_\bn-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn;\b;\b;\b;
+ The o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bn 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.
+ s\bs\bs\bsc\bc\bc\bcr\br\br\bri\bi\bi\bip\bp\bp\bpt\bt\bt\bt "\b"\b"\b"_\bs_\bc_\br_\bi_\bp_\bt-_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
+ The s\bs\bs\bsc\bc\bc\bcr\br\br\bri\bi\bi\bip\bp\bp\bpt\bt\bt\bt 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 d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be(\b(\b(\b(8\b8\b8\b8)\b)\b)\b).\b.\b.\b.
-dhclient.conf(5) dhclient.conf(5)
+ m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\biu\bu\bu\bum\bm\bm\bm "\b"\b"\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b"\b"\b";\b;\b;\b;
+ The m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\biu\bu\bu\bum\bm\bm\bm 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.
- e\bex\bxp\bpi\bir\bre\be _\bd_\ba_\bt_\be;\b;
+ The dhcp client automatically declares this parameter if it
+ used a media type (see the m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\bia\ba\ba\ba statement) when configuring
+ the interface in order to obtain a lease. This statement
- The r\bre\ben\bne\bew\bw 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 r\bre\beb\bbi\bin\bnd\bd statement defines
- the time at which the dhcp client should begin to try to
- contact _\ba_\bn_\by dhcp server in order to renew its lease. The
- e\bex\bxp\bpi\bir\bre\be statement defines the time at which the dhcp client
- must stop using a lease if it has not been able to contact
- a server in order to renew it.
- These declarations are automatically set in leases
- acquired by the DHCP client, but must also be configured
- in predefined leases - a predefined lease whose expiry
- time has passed will not be used by the DHCP client.
- Dates are specified as follows:
+SunOS 5.6 Last change: 6
- _\b<_\bw_\be_\be_\bk_\bd_\ba_\by_\b> _\b<_\by_\be_\ba_\br_\b>/\b/_\b<_\bm_\bo_\bn_\bt_\bh_\b>/\b/_\b<_\bd_\ba_\by_\b> _\b<_\bh_\bo_\bu_\br_\b>:\b:_\b<_\bm_\bi_\bn_\bu_\bt_\be_\b>:\b:_\b<_\bs_\be_\bc_\bo_\bn_\bd_\b>
- 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.
-A\bAL\bLI\bIA\bAS\bS D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
- a\bal\bli\bia\bas\bs {\b{ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs _\b._\b._\b. }\b}
- Some DHCP clients running TCP/IP roaming protocols may
- require that in addition to the lease they may acquire via
- DHCP, their interface also be configured with a predefined
- IP alias so that they can have a permanent IP address even
- while roaming. The Internet Software Consortium DHCP
- client doesn't support roaming with fixed addresses
- directly, but in order to facilitate such experimentation,
- the dhcp client can be set up to configure an IP alias
- using the a\bal\bli\bia\bas\bs 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
- ration for the IP alias address, and a subnet-mask option
- declaration. A medium statement should never be included
- in an alias declaration.
+Headers, Environments, and Macros dhclient.conf(5)
- 7
+ should be used in predefined leases only if the network
+ interface requires media type configuration.
+ r\br\br\bre\be\be\ben\bn\bn\bne\be\be\bew\bw\bw\bw _\bd_\ba_\bt_\be;\b;\b;\b;
+ r\br\br\bre\be\be\beb\bb\bb\bbi\bi\bi\bin\bn\bn\bnd\bd\bd\bd _\bd_\ba_\bt_\be;\b;\b;\b;
+ e\be\be\bex\bx\bx\bxp\bp\bp\bpi\bi\bi\bir\br\br\bre\be\be\be _\bd_\ba_\bt_\be;\b;\b;\b;
+ The r\br\br\bre\be\be\ben\bn\bn\bne\be\be\bew\bw\bw\bw 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 r\br\br\bre\be\be\beb\bb\bb\bbi\bi\bi\bin\bn\bn\bnd\bd\bd\bd statement defines the
+ time at which the dhcp client should begin to try to contact
+ _\ba_\bn_\by dhcp server in order to renew its lease. The e\be\be\bex\bx\bx\bxp\bp\bp\bpi\bi\bi\bir\br\br\bre\be\be\be
+ statement defines the time at which the dhcp client must
+ stop using a lease if it has not been able to contact a
+ server in order to renew it.
-dhclient.conf(5) dhclient.conf(5)
+ These declarations are automatically set in leases acquired
+ by the DHCP client, but must also be configured in prede-
+ fined leases - a predefined lease whose expiry time has
+ passed will not be used by the DHCP client.
+ Dates are specified as follows:
-O\bOT\bTH\bHE\bER\bR D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
- r\bre\bej\bje\bec\bct\bt _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
+ <_\bw_\be_\be_\bk_\bd_\ba_\by> <_\by_\be_\ba_\br>/\b/\b/\b/<_\bm_\bo_\bn_\bt_\bh>/\b/\b/\b/<_\bd_\ba_\by> <_\bh_\bo_\bu_\br>:\b:\b:\b:<_\bm_\bi_\bn_\bu_\bt_\be>:\b:\b:\b:<_\bs_\be_\bc_\bo_\bn_\bd>
- 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
- 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.
+ 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 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.
- i\bin\bnt\bte\ber\brf\bfa\bac\bce\be "\b"_\bn_\ba_\bm_\be"\b" {\b{ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs _\b._\b._\b. }\b}
+A\bA\bA\bAL\bL\bL\bLI\bI\bI\bIA\bA\bA\bAS\bS\bS\bS D\bD\bD\bDE\bE\bE\bEC\bC\bC\bCL\bL\bL\bLA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
+ a\ba\ba\bal\bl\bl\bli\bi\bi\bia\ba\ba\bas\bs\bs\bs {\b{\b{\b{ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ... }\b}\b}\b}
- 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
- ration will use the parameters declared outside of any
- interface declaration, or the default settings.
+ Some DHCP clients running TCP/IP roaming protocols may
+ require that in addition to the lease they may acquire via
+ DHCP, their interface also be configured with a predefined
+ IP alias so that they can have a permanent IP address even
+ while roaming. The Internet Software Consortium DHCP
+ client doesn't support roaming with fixed addresses
+ directly, but in order to facilitate such experimentation,
+ the dhcp client can be set up to configure an IP alias using
+ the a\ba\ba\bal\bl\bl\bli\bi\bi\bia\ba\ba\bas\bs\bs\bs declaration.
- m\bme\bed\bdi\bia\ba "\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b" _\b[ ,\b, "\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b",\b, _\b._\b._\b. _\b];\b;
- The m\bme\bed\bdi\bia\ba statement defines one or more media configura
- tion parameters which may be tried while attempting to
- acquire an IP address. The dhcp client will cycle
- through each media setup string on the list, configuring
- the interface using that setup and attempting to boot, and
- then trying the next one. This can be used for network
- interfaces which aren't capable of sensing the media type
- unaided - whichever media type succeeds in getting a
- request to the server and hearing the reply is probably
- right (no guarantees).
- The media setup is only used for the initial phase of
- address acquisition (the DHCPDISCOVER and DHCPOFFER pack
- 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.
-S\bSA\bAM\bMP\bPL\bLE\bE
- The following configuration file is used on a laptop run
- ning NetBSD 1.3. The laptop has an IP alias of
- 192.5.5.213, and has one interface, ep0 (a 3com 3C589C).
- Booting intervals have been shortened somewhat from the
- default, because the client is known to spend most of its
- time on networks with little DHCP activity. The laptop
- does roam to multiple networks.
+SunOS 5.6 Last change: 7
- 8
+Headers, Environments, and Macros dhclient.conf(5)
-dhclient.conf(5) dhclient.conf(5)
+ The alias declaration resembles a lease declaration, except
+ that options other than the subnet-mask option are ignored
+ by the standard client configuration script, and expiry
+ times are ignored. A typical alias declaration includes an
+ interface declaration, a fixed-address declaration for the
+ IP alias address, and a subnet-mask option declaration. A
+ medium statement should never be included in an alias
+ declaration.
+O\bO\bO\bOT\bT\bT\bTH\bH\bH\bHE\bE\bE\bER\bR\bR\bR D\bD\bD\bDE\bE\bE\bEC\bC\bC\bCL\bL\bL\bLA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
+ r\br\br\bre\be\be\bej\bj\bj\bje\be\be\bec\bc\bc\bct\bt\bt\bt _\bi_\bp-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;\b;\b;
- timeout 60;
- retry 60;
- reboot 10;
- select-timeout 5;
- initial-interval 2;
- reject 192.33.137.209;
+ 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.
- interface "ep0" {
- send host-name "andare.fugue.com";
- send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
- send dhcp-lease-time 3600;
- supersede domain-name "fugue.com rc.vix.com home.vix.com";
- prepend domain-name-servers 127.0.0.1;
- request subnet-mask, broadcast-address, time-offset, routers,
- domain-name, domain-name-servers, host-name;
- require subnet-mask, domain-name-servers;
- script "/etc/dhclient-script";
- media "media 10baseT/UTP", "media 10base2/BNC";
- }
+ i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brf\bf\bf\bfa\ba\ba\bac\bc\bc\bce\be\be\be "\b"\b"\b"_\bn_\ba_\bm_\be"\b"\b"\b" {\b{\b{\b{ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ... }\b}\b}\b}
- alias {
- interface "ep0";
- fixed-address 192.5.5.213;
- option subnet-mask 255.255.255.255;
- }
- This is a very complicated dhclient.conf file - in gen
- 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.
+ 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 declaration will
+ use the parameters declared outside of any interface
+ declaration, or the default settings.
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcp-options(5), dhclient.leases(5), dhcpd(8),
- dhcpd.conf(5), RFC2132, RFC2131.
+ m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\bia\ba\ba\ba "\b"\b"\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b"\b"\b" [ ,\b,\b,\b, "\b"\b"\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b"\b"\b",\b,\b,\b, ... ];\b;\b;\b;
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com>
- under a contract with Vixie Labs. Funding for this pro
- ject was provided by the Internet Software Consortium.
- Information about the Internet Software Consortium can be
- found at h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
+ The m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\bia\ba\ba\ba 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
+ packtes). Once an address has been acquired, the dhcp
+ client will record it in its lease database and will record
+ the media type used to acquire the address. Whenever the
+ client tries to renew the lease, it will use that same media
+ type. The lease must expire before the client will go back
+ to cycling through media types.
+SunOS 5.6 Last change: 8
+Headers, Environments, and Macros dhclient.conf(5)
+S\bS\bS\bSA\bA\bA\bAM\bM\bM\bMP\bP\bP\bPL\bL\bL\bLE\bE\bE\bE
+ The following configuration file is used on a laptop running
+ NetBSD 1.3. The laptop has an IP alias of 192.5.5.213, and
+ has one interface, ep0 (a 3com 3C589C). Booting intervals
+ have been shortened somewhat from the default, because the
+ client is known to spend most of its time on networks with
+ little DHCP activity. The laptop does roam to multiple
+ networks.
+ timeout 60;
+ retry 60;
+ reboot 10;
+ select-timeout 5;
+ initial-interval 2;
+ reject 192.33.137.209;
+
+ interface "ep0" {
+ send host-name "andare.fugue.com";
+ send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
+ send dhcp-lease-time 3600;
+ supersede domain-name "fugue.com rc.vix.com home.vix.com";
+ prepend domain-name-servers 127.0.0.1;
+ request subnet-mask, broadcast-address, time-offset, routers,
+ domain-name, domain-name-servers, host-name;
+ require subnet-mask, domain-name-servers;
+ script "/etc/dhclient-script";
+ media "media 10baseT/UTP", "media 10base2/BNC";
+ }
+
+ alias {
+ interface "ep0";
+ fixed-address 192.5.5.213;
+ option subnet-mask 255.255.255.255;
+ }
+ This is a very complicated dhclient.conf file - in general,
+ yours should be much simpler. In many cases, it's suffi-
+ cient to just create an empty dhclient.conf file - the
+ defaults are usually fine.
+
+S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
+ dhcp-options(5), dhclient.leases(5), dhcpd(8),
+ dhcpd.conf(5), RFC2132, RFC2131.
+
+A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) 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
+ h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
+
+
+
+
+
+SunOS 5.6 Last change: 9
- 9
-dhclient.leases(5) dhclient.leases(5)
+Headers, Environments, and Macros dhclient.leases(5)
-N\bNA\bAM\bME\bE
- dhclient.leases - DHCP client lease database
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- The Internet Software Consortium DHCP client keeps a per
- sistent database of leases that it has acquired that are
- still valid. The database is a free-form ASCII file con
- taining one valid declaration per lease. If more than
- one declaration appears for a given lease, the last one in
- the file is used. The file is written as a log, so this
- is not an unusual occurrance.
+N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
+ dhclient.leases - DHCP client lease database
- The format of the lease declarations is described in
- d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf(\b(5\b5)\b).\b.
+D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ The Internet Software Consortium DHCP client keeps a per-
+ sistent database of leases that it has acquired that are
+ still valid. The database is a free-form ASCII file con-
+ taining one valid declaration per lease. If more than one
+ declaration appears for a given lease, the last one in the
+ file is used. The file is written as a log, so this is not
+ an unusual occurrance.
-F\bFI\bIL\bLE\bES\bS
- /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.l\ble\bea\bas\bse\bes\bs
+ The format of the lease declarations is described in
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf(\b(\b(\b(5\b5\b5\b5)\b)\b)\b).\b.\b.\b.
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8),
- dhcpd.conf(5), RFC2132, RFC2131.
+F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
+ /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com>
- under a contract with Vixie Labs. Funding for this pro
- ject was provided by the Internet Software Consortium.
- Information about the Internet Software Consortium can be
- found at h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
+S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
+ dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8),
+ dhcpd.conf(5), RFC2132, RFC2131.
+A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) 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
+ h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
+SunOS 5.6 Last change: 1
- 1
#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"
result = writev(interface -> wfdesc, iov, 2);
if (result < 0)
- warn ("send_packet: %m");
+ log_error ("send_packet: %m");
return result;
}
#endif /* USE_BPF_SEND */
#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));
0, 0, dbuf, dbuflen);
#endif
if (result < 0)
- warn ("send_packet: %m");
+ log_error ("send_packet: %m");
return result;
}
#endif /* USE_DLPI_SEND */
#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"
*/
int
inet_aton(cp, addr)
- char *cp;
+ const char *cp;
struct in_addr *addr;
{
register u_long val;
#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"
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 */
#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"
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 */
#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"
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;
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;
#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"
result = writev(interface -> wfdesc, iov, 2);
if (result < 0)
- warn ("send_packet: %m");
+ log_error ("send_packet: %m");
return result;
}
#endif /* USE_SOCKET_SEND */
#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"
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",
- "regarding broadcast address.");
+ log_error ("send_packet: please consult README file %s",
+ "regarding broadcast address.");
}
return result;
}
#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"
result = writev(interface -> wfdesc, iov, 2);
if (result < 0)
- warn ("send_packet: %m");
+ log_error ("send_packet: %m");
return result;
}
#endif /* USE_UPF_SEND */
#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
/* 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
struct packet; /* forward */
struct option_state; /* forward */
struct decoded_option_state; /* forward */
-enum statement_op; /* forward */
struct universe {
char *name;
-dhcrelay(8) dhcrelay(8)
+Maintenance Procedures dhcrelay(8)
-N\bNA\bAM\bME\bE
- dhcrelay - Dynamic Host Configuration Protocol Relay Agent
-
-S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
- d\bdh\bhc\bcr\bre\bel\bla\bay\by [ -\b-p\bp _\bp_\bo_\br_\bt ] [ -\b-d\bd ] [ -\b-q\bq ] [ -\b-i\bi _\bi_\bf_\b0 [ .\b..\b..\b. -\b-i\bi _\bi_\bf_\bN
- ] ] [ -\b-a\ba ] [ -\b-A\bA _\bl_\be_\bn_\bg_\bt_\bh ] [ -\b-D\bD ] [ -\b-m\bm _\ba_\bp_\bp_\be_\bn_\bd | _\br_\be_\bp_\bl_\ba_\bc_\be |
- _\bf_\bo_\br_\bw_\ba_\br_\bd | _\bd_\bi_\bs_\bc_\ba_\br_\bd ] _\bs_\be_\br_\bv_\be_\br_\b0 [ _\b._\b._\b._\bs_\be_\br_\bv_\be_\br_\bN ]
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- The Internet Software Consortium DHCP Relay Agent, dhcre
- 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.
-
-O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
- 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.
-C\bCO\bOM\bMM\bMA\bAN\bND\bD L\bLI\bIN\bNE\bE
- The names of the network interfaces that dhcrelay should
- attempt to configure may be specified on the command line
- using the -\b-i\bi option. If no interface names are specified
- on the command line dhcrelay will identify all network
- interfaces, elimininating non-broadcast interfaces if pos
- sible, and attempt to configure each interface.
+N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
+ dhcrelay - Dynamic Host Configuration Protocol Relay Agent
- If a relay agent is running on a system that is connected
- to one or more networks on which no DHCP servers are pre
- sent, and is also connected to one or more networks on
- which DHCP servers _\ba_\br_\be 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 -\b-i\bi flag.
+S\bS\bS\bSY\bY\bY\bYN\bN\bN\bNO\bO\bO\bOP\bP\bP\bPS\bS\bS\bSI\bI\bI\bIS\bS\bS\bS
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcr\br\br\bre\be\be\bel\bl\bl\bla\ba\ba\bay\by\by\by [ -\b-\b-\b-p\bp\bp\bp _\bp_\bo_\br_\bt ] [ -\b-\b-\b-d\bd\bd\bd ] [ -\b-\b-\b-q\bq\bq\bq ] [ -\b-\b-\b-i\bi\bi\bi _\bi_\bf_\b0 [ .\b.\b.\b..\b.\b.\b..\b.\b.\b. -\b-\b-\b-i\bi\bi\bi _\bi_\bf_\bN ] ]
+ [ -\b-\b-\b-a\ba\ba\ba ] [ -\b-\b-\b-A\bA\bA\bA _\bl_\be_\bn_\bg_\bt_\bh ] [ -\b-\b-\b-D\bD\bD\bD ] [ -\b-\b-\b-m\bm\bm\bm _\ba_\bp_\bp_\be_\bn_\bd | _\br_\be_\bp_\bl_\ba_\bc_\be | _\bf_\bo_\br_\bw_\ba_\br_\bd
+ | _\bd_\bi_\bs_\bc_\ba_\br_\bd ] _\bs_\be_\br_\bv_\be_\br_\b0 [ ..._\bs_\be_\br_\bv_\be_\br_\bN ]
- Note that in some cases it _\bi_\bs 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.
+D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ 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.
- If dhcrelay should listen and transmit on a port other
- than the standard (port 67), the -\b-p\bp flag may used. It
- should be followed by the udp port number that dhcrelay
- should use. This is mostly useful for debugging purposes.
+O\bO\bO\bOP\bP\bP\bPE\bE\bE\bER\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ 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.
- 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
+C\bC\bC\bCO\bO\bO\bOM\bM\bM\bMM\bM\bM\bMA\bA\bA\bAN\bN\bN\bND\bD\bD\bD L\bL\bL\bLI\bI\bI\bIN\bN\bN\bNE\bE\bE\bE
+ The names of the network interfaces that dhcrelay should
+ attempt to configure may be specified on the command line
+ using the -\b-\b-\b-i\bi\bi\bi option. If no interface names are specified on
+ the command line dhcrelay will identify all network inter-
+ faces, elimininating non-broadcast interfaces if possible,
+ and attempt to configure each interface.
+ If a relay agent is running on a system that is connected to
+ one or more networks on which no DHCP servers are present,
+ and is also connected to one or more networks on which DHCP
+ servers _\ba_\br_\be 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 -\b-\b-\b-i\bi\bi\bi flag.
+ Note that in some cases it _\bi_\bs helpful for the relay agent to
+ forward requests from networks on which a DHCP server is
+ running to other DHCP servers. This would be the case if
+ two DHCP servers on different networks were being used to
+ provide backup service for each other's networks.
- 1
+ If dhcrelay should listen and transmit on a port other than
+ the standard (port 67), the -\b-\b-\b-p\bp\bp\bp flag may used. It should be
+ followed by the udp port number that dhcrelay should use.
+ This is mostly useful for debugging purposes.
-dhcrelay(8) dhcrelay(8)
+SunOS 5.6 Last change: 1
- a foreground process, the -\b-d\bd 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 -\b-q\bq flag.
-R\bRE\bEL\bLA\bAY\bY A\bAG\bGE\bEN\bNT\bT I\bIN\bNF\bFO\bOR\bRM\bMA\bAT\bTI\bIO\bON\bN O\bOP\bPT\bTI\bIO\bON\bNS\bS
- If the -\b-a\ba flag is set the relay agent will append an agent
- option field to each request before forwarding it to the
- server. Agent option fields in responses sent from
- servers to clients will be stripped before forwarding such
- responses back to the client.
- The agent option field will contain two agent options: the
- Circuit ID suboption and the Agent ID suboption. Cur
- 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.
- _\bN_\bo_\bt_\be_\b: 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.
+Maintenance Procedures dhcrelay(8)
- Relay Agent options are added to a DHCP packet without the
- knowledge of the DHCP client. The client may have filled
- the DHCP packet option buffer completely, in which case
- there theoretically isn't any space to add Agent options.
- However, the DHCP server may be able to handle a much
- larger packet than most DHCP clients would send. The
- current Agent Options draft requires that the relay agent
- use a maximum packet size of 576 bytes.
- It is recommended that with the Internet Software Consor
- 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
- ing the -\b-A\bA 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
- 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.
+ 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 a
+ foreground process, the -\b-\b-\b-d\bd\bd\bd 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 -\b-\b-\b-q\bq\bq\bq flag.
+R\bR\bR\bRE\bE\bE\bEL\bL\bL\bLA\bA\bA\bAY\bY\bY\bY A\bA\bA\bAG\bG\bG\bGE\bE\bE\bEN\bN\bN\bNT\bT\bT\bT I\bI\bI\bIN\bN\bN\bNF\bF\bF\bFO\bO\bO\bOR\bR\bR\bRM\bM\bM\bMA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN O\bO\bO\bOP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
+ If the -\b-\b-\b-a\ba\ba\ba flag is set the relay agent will append an agent
+ option field to each request before forwarding it to the
+ server. Agent option fields in responses sent from servers
+ to clients will be stripped before forwarding such responses
+ back to the client.
+ The agent option field will contain two agent options: the
+ Circuit ID suboption and the Agent ID suboption. Currently,
+ the Circuit ID will be the printable name of the interface
+ on which the client request was received. The Agent ID
+ will be the value that the relay agent stores in the DHCP
+ packet's giaddr field. The client supports inclusion of a
+ Remote ID suboption as well, but this is not used by
+ default.
- 2
+ _\bN_\bo_\bt_\be: The Agent ID suboption is not defined in the current
+ Relay Agent Information Option draft (draft-ietf-dhc-agent-
+ options-03.txt), but has been proposed for inclusion in the
+ next draft.
+ Relay Agent options are added to a DHCP packet without the
+ knowledge of the DHCP client. The client may have filled
+ the DHCP packet option buffer completely, in which case
+ there theoretically isn't any space to add Agent options.
+ However, the DHCP server may be able to handle a much larger
+ packet than most DHCP clients would send. The current
+ Agent Options draft requires that the relay agent use a max-
+ imum packet size of 576 bytes.
+ It is recommended that with the Internet Software Consortium
+ DHCP server, the maximum packet size be set to about 1400,
+ allowing plenty of extra space in which the relay agent can
+ put the agent option field, while still fitting into the
+ Ethernet MTU size. This can be done by specifying the -\b-\b-\b-A\bA\bA\bA
+ flag, followed by the desired maximum packet size (e.g.,
+ 1400).
+ Note that this is reasonably safe to do even if the MTU
+ between the server and the client is less than 1500, as long
+ as the hosts on which the server and client are running
-dhcrelay(8) dhcrelay(8)
+SunOS 5.6 Last change: 2
- It is possible for a relay agent to receive a packet which
- already contains an agent option field. If this packet
- does not have a giaddr set, the standard requires that the
- packet be discarded.
- If giaddr is set, the server may handle the situation in
- one of four ways: it may _\ba_\bp_\bp_\be_\bn_\bd its own set of relay
- options to the packet, leaving the supplied option field
- intact. It may _\br_\be_\bp_\bl_\ba_\bc_\be the existing agent option field.
- It may _\bf_\bo_\br_\bw_\ba_\br_\bd the packet unchanged. Or, it may _\bd_\bi_\bs_\bc_\ba_\br_\bd
- it.
- Which of these behaviours is followed by the Internet
- Software Consortium DHCP Relay Agent may be configured
- with the -\b-m\bm flag, followed by one of the four keywords
- specified in _\bi_\bt_\ba_\bl_\bi_\bc_\bs 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
- 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 -\b-D\bD option is specified, all packets that
- don't contain a match will be dropped.
-S\bSP\bPE\bEC\bCI\bIF\bFY\bYI\bIN\bNG\bG D\bDH\bHC\bCP\bP S\bSE\bER\bRV\bVE\bER\bRS\bS
- 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.
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc-
- agent-options-03.txt.
+Maintenance Procedures dhcrelay(8)
-B\bBU\bUG\bGS\bS
- 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
- work - if they do, the server will receive duplicate pack
- 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.
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcr\bre\bel\bla\bay\by(\b(8\b8)\b) 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 h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm/\b/i\bis\bsc\bc.\b. To learn
+ 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.
+ If giaddr is set, the server may handle the situation in one
+ of four ways: it may _\ba_\bp_\bp_\be_\bn_\bd its own set of relay options to
+ the packet, leaving the supplied option field intact. It
+ may _\br_\be_\bp_\bl_\ba_\bc_\be the existing agent option field. It may _\bf_\bo_\br_\bw_\ba_\br_\bd
+ the packet unchanged. Or, it may _\bd_\bi_\bs_\bc_\ba_\br_\bd it.
- 3
+ Which of these behaviours is followed by the Internet
+ Software Consortium DHCP Relay Agent may be configured with
+ the -\b-\b-\b-m\bm\bm\bm flag, followed by one of the four keywords specified
+ in _\bi_\bt_\ba_\bl_\bi_\bc_\bs above.
+ When the relay agent receives a reply from a server that
+ it's supposed to forward to a client, and Relay Agent Infor-
+ mation option processing is enabled, the relay agent scans
+ the packet for Relay Agent Information options and removes
+ them. As it's scanning, if it finds a Relay Agent Informa-
+ tion option field containing an Agent ID suboption that
+ matches one of its IP addresses, that option is recognized
+ as its own. If no such option is found, the relay agent
+ can either drop the packet, or relay it anyway. If the -\b-\b-\b-D\bD\bD\bD
+ option is specified, all packets that don't contain a match
+ will be dropped.
+S\bS\bS\bSP\bP\bP\bPE\bE\bE\bEC\bC\bC\bCI\bI\bI\bIF\bF\bF\bFY\bY\bY\bYI\bI\bI\bIN\bN\bN\bNG\bG\bG\bG D\bD\bD\bDH\bH\bH\bHC\bC\bC\bCP\bP\bP\bP S\bS\bS\bSE\bE\bE\bER\bR\bR\bRV\bV\bV\bVE\bE\bE\bER\bR\bR\bRS\bS\bS\bS
+ 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.
+S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
+ dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc-
+ agent-options-03.txt.
+B\bB\bB\bBU\bU\bU\bUG\bG\bG\bGS\bS\bS\bS
+ It should be possible for the user to define the Circuit ID
+ and Remote ID values on a per-interface basis.
-dhcrelay(8) dhcrelay(8)
+ The relay agent should not relay packets received on a phy-
+ sical network to DHCP servers on the same physical network -
+ if they do, the server will receive duplicate packets. In
+ order to fix this, however, the relay agent needs to be able
+ to learn about the network topology, which requires that it
+ have a configuration file.
- more about Vixie Enterprises, see h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm.\b.
+SunOS 5.6 Last change: 3
+Maintenance Procedures dhcrelay(8)
+A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcr\br\br\bre\be\be\bel\bl\bl\bla\ba\ba\bay\by\by\by(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) 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 h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b. To learn
+ more about Vixie Enterprises, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm.\b.\b.\b.
- 4
+
+
+
+SunOS 5.6 Last change: 4
+
#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"
{
enum dhcp_token token;
char *val;
- char rf = flag;
+ unsigned char rf = flag;
struct expression *data = (struct expression *)0;
int status;
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))
#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"
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;
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];
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 =
if (packet -> packet_type == DHCPREQUEST && fixed_lease) {
fixed_lease = (struct lease *)0;
db_conflict:
- warn ("Both dynamic and static leases present for %s.",
- piaddr (cip));
- warn ("Either remove host declaration %s or remove %s",
- (fixed_lease && fixed_lease -> host
- ? (fixed_lease -> host -> name
- ? 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 ("Dynamic and static leases present for %s.",
+ piaddr (cip));
+ log_error ("Remove host declaration %s or remove %s",
+ (fixed_lease && fixed_lease -> host
+ ? (fixed_lease -> host -> name
+ ? fixed_lease -> host -> name
+ : piaddr (cip))
+ : piaddr (cip)),
+ piaddr (cip));
+ 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,
-dhcpd(8) dhcpd(8)
-
-
-N\bNA\bAM\bME\bE
- dhcpd - Dynamic Host Configuration Protocol Server
-
-S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
- d\bdh\bhc\bcp\bpd\bd [ -\b-p\bp _\bp_\bo_\br_\bt ] [ -\b-f\bf ] [ -\b-d\bd ] [ -\b-q\bq ] [ -\b-c\bcf\bf _\bc_\bo_\bn_\bf_\bi_\bg_\b-_\bf_\bi_\bl_\be ]
- [ -\b-l\blf\bf _\bl_\be_\ba_\bs_\be_\b-_\bf_\bi_\bl_\be ] [ _\bi_\bf_\b0 [ _\b._\b._\b._\bi_\bf_\bN ] ]
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- 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
- work to which they are attached. BOOTP provides similar
- functionality, with certain restrictions.
-
-C\bCO\bON\bNT\bTR\bRI\bIB\bBU\bUT\bTI\bIO\bON\bNS\bS
- Development of this software is funded through contribu
- tions and support contracts. Please see d\bdh\bhc\bcp\bp-\b-c\bco\bon\bnt\btr\bri\bib\bb(\b(5\b5)\b)
- for information on how you can contribute.
-
-O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
- 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
- cates address pools in each subnet and enters them into
- the dhcpd.conf(5) file.
+Maintenance Procedures dhcpd(8)
- On startup, dhcpd reads the _\bd_\bh_\bc_\bp_\bd_\b._\bc_\bo_\bn_\bf 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
-
-
-
- 1
-
-
-
-
-
-dhcpd(8) dhcpd(8)
-
-
- arbitrarily large, from time to time dhcpd creates a new
- dhcpd.leases file from its in-core lease database. Once
- this file has been written to disk, the old file is
- renamed _\bd_\bh_\bc_\bp_\bd_\b._\bl_\be_\ba_\bs_\be_\bs_\b~, 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
- ity, although the network administrator may set an earlier
- cutoff date or a shorter lease length for BOOTP leases if
- that makes sense.
-
- BOOTP clients may also be served in the old standard way,
- which is to simply provide a declaration in the dhcpd.conf
- file for each BOOTP client, permanently assigning an
- address to each client.
+N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
+ dhcpd - Dynamic Host Configuration Protocol Server
- 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
- _\b/_\bv_\ba_\br_\b/_\br_\bu_\bn_\b/_\bd_\bh_\bc_\bp_\bd_\b._\bp_\bi_\bd, 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.
+S\bS\bS\bSY\bY\bY\bYN\bN\bN\bNO\bO\bO\bOP\bP\bP\bPS\bS\bS\bSI\bI\bI\bIS\bS\bS\bS
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd [ -\b-\b-\b-p\bp\bp\bp _\bp_\bo_\br_\bt ] [ -\b-\b-\b-f\bf\bf\bf ] [ -\b-\b-\b-d\bd\bd\bd ] [ -\b-\b-\b-q\bq\bq\bq ] [ -\b-\b-\b-c\bc\bc\bcf\bf\bf\bf _\bc_\bo_\bn_\bf_\bi_\bg-_\bf_\bi_\bl_\be ] [
+ -\b-\b-\b-l\bl\bl\blf\bf\bf\bf _\bl_\be_\ba_\bs_\be-_\bf_\bi_\bl_\be ] [ _\bi_\bf_\b0 [ ..._\bi_\bf_\bN ] ]
+
+D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ 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.
+
+C\bC\bC\bCO\bO\bO\bON\bN\bN\bNT\bT\bT\bTR\bR\bR\bRI\bI\bI\bIB\bB\bB\bBU\bU\bU\bUT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
+ Development of this software is funded through contributions
+ and support contracts. Please see d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-c\bc\bc\bco\bo\bo\bon\bn\bn\bnt\bt\bt\btr\br\br\bri\bi\bi\bib\bb\bb\bb(\b(\b(\b(5\b5\b5\b5)\b)\b)\b) for
+ information on how you can contribute.
+
+O\bO\bO\bOP\bP\bP\bPE\bE\bE\bER\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ The DHCP protocol allows a host which is unknown to the net-
+ work administrator to be automatically assigned a new IP
+ address out of a pool of IP addresses for its network. In
+ order for this to work, the network administrator allocates
+ address pools in each subnet and enters them into the
+ dhcpd.conf(5) file.
- Note: We get a lot of complaints about this. We realize
- 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.
+ On startup, dhcpd reads the _\bd_\bh_\bc_\bp_\bd._\bc_\bo_\bn_\bf 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.
-C\bCO\bOM\bMM\bMA\bAN\bND\bD L\bLI\bIN\bNE\bE
- 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
- cast interfaces if possible, and listen for DHCP broad
- casts on each interface.
+ 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.
- 2
+SunOS 5.6 Last change: 1
-dhcpd(8) dhcpd(8)
+Maintenance Procedures dhcpd(8)
- If dhcpd should listen on a port other than the standard
- (port 67), the -\b-p\bp 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 -\b-f\bf flag
- should be specified. This is useful when running dhcpd
- under a debugger, or when running it out of inittab on
- System V systems.
- To have dhcpd log to the standard error descriptor, spec
- ify the -\b-d\bd 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
- not be used. Normally, dhcpd will log all output using
- the syslog(3) function with the log facility set to
- LOG_DAEMON.
+ 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 _\bd_\bh_\bc_\bp_\bd._\bl_\be_\ba_\bs_\be_\bs~,
+ 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.
- Dhcpd can be made to use an alternate configuration file
- with the -\b-c\bcf\bf flag, or an alternate lease file with the -\b-l\blf\bf
- flag. Because of the importance of using the same lease
- database at all times when running dhcpd in production,
- these options should be used o\bon\bnl\bly\by for testing lease files
- or database files in a non-production environment.
+ 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.
- 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 -\b-q\bq flag may be specified.
+ 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.
-C\bCO\bON\bNF\bFI\bIG\bGU\bUR\bRA\bAT\bTI\bIO\bON\bN
- The syntax of the dhcpd.conf(5) file is discussed seper
- 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.
+ 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 /_\be_\bt_\bc/_\bd_\bh_\bc_\bp_\bd._\bp_\bi_\bd, 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 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.
-S\bSu\bub\bbn\bne\bet\bts\bs
- dhcpd needs to know the subnet numbers and netmasks of all
- 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:
+C\bC\bC\bCO\bO\bO\bOM\bM\bM\bMM\bM\bM\bMA\bA\bA\bAN\bN\bN\bND\bD\bD\bD L\bL\bL\bLI\bI\bI\bIN\bN\bN\bNE\bE\bE\bE
+ 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 speci-
+ fied on the command line dhcpd will identify all network
+ interfaces which are up, elimininating non-broadcast
- subnet 239.252.197.0 netmask 255.255.255.0 {
- range 239.252.197.10 239.252.197.250;
- }
- Multiple address ranges may be specified like this:
- subnet 239.252.197.0 netmask 255.255.255.0 {
+SunOS 5.6 Last change: 2
- 3
+Maintenance Procedures dhcpd(8)
-dhcpd(8) dhcpd(8)
+ interfaces if possible, and listen for DHCP broadcasts on
+ each interface.
- range 239.252.197.10 239.252.197.107;
- range 239.252.197.113 239.252.197.250;
- }
+ If dhcpd should listen on a port other than the standard
+ (port 67), the -\b-\b-\b-p\bp\bp\bp flag may used. It should be followed by
+ the udp port number on which dhcpd should listen. This is
+ mostly useful for debugging purposes.
- If a subnet will only be provided with BOOTP service and
- no dynamic address assignment, the range clause can be
- left out entirely, but the subnet statement must appear.
+ To run dhcpd as a foreground process, rather than allowing
+ it to run as a daemon in the background, the -\b-\b-\b-f\bf\bf\bf 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, specify
+ the -\b-\b-\b-d\bd\bd\bd 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.
-L\bLe\bea\bas\bse\be L\bLe\ben\bng\bgt\bth\bhs\bs
- 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
- depending on the kinds of hosts being served.
+ Dhcpd can be made to use an alternate configuration file
+ with the -\b-\b-\b-c\bc\bc\bcf\bf\bf\bf flag, or an alternate lease file with the -\b-\b-\b-l\bl\bl\blf\bf\bf\bf
+ flag. Because of the importance of using the same lease
+ database at all times when running dhcpd in production,
+ these options should be used o\bo\bo\bon\bn\bn\bnl\bl\bl\bly\by\by\by for testing lease files or
+ database files in a non-production environment.
- 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
- 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
- ance before packaging it up for delivery.
+ 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 mes-
+ sage, the -\b-\b-\b-q\bq\bq\bq flag may be specified.
- 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:
+C\bC\bC\bCO\bO\bO\bON\bN\bN\bNF\bF\bF\bFI\bI\bI\bIG\bG\bG\bGU\bU\bU\bUR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ 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.
- subnet 239.252.197.0 netmask 255.255.255.0 {
- range 239.252.197.10 239.252.197.107;
- default-lease-time 600;
- max-lease-time 7200;
- |
+S\bS\bS\bSu\bu\bu\bub\bb\bb\bbn\bn\bn\bne\be\be\bet\bt\bt\bts\bs\bs\bs
+ dhcpd needs to know the subnet numbers and netmasks of all
+ 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:
- 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).
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.250;
+ }
- 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.
-B\bBO\bOO\bOT\bTP\bP S\bSu\bup\bpp\bpo\bor\brt\bt
- Each BOOTP client must be explicitly declared in the
- dhcpd.conf file. A very basic client declaration will
- specify the client network interface's hardware address
- and the IP address to assign to that client. If the
- client needs to be able to load a boot file from the
- server, that file's name must be specified. A simple
+SunOS 5.6 Last change: 3
- 4
-dhcpd(8) dhcpd(8)
+Maintenance Procedures dhcpd(8)
- bootp client declaration might look like this:
- host haagen {
- hardware ethernet 08:00:2b:4c:59:23;
- fixed-address 239.252.197.9;
- filename "/tftpboot/haagen.boot";
- }
+ Multiple address ranges may be specified like this:
-O\bOp\bpt\bti\bio\bon\bns\bs
- 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).
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
+ range 239.252.197.113 239.252.197.250;
+ }
- 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
- dence. An reasonably complete DHCP configuration might
- look something like this:
+ 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.
- subnet 239.252.197.0 netmask 255.255.255.0 {
- range 239.252.197.10 239.252.197.250;
- default-lease-time 600 max-lease-time 7200;
- option subnet-mask 255.255.255.0;
- option broadcast-address 239.252.197.255;
- option routers 239.252.197.1;
- option domain-name-servers 239.252.197.2, 239.252.197.3;
- option domain-name "isc.org";
- }
+L\bL\bL\bLe\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be L\bL\bL\bLe\be\be\ben\bn\bn\bng\bg\bg\bgt\bt\bt\bth\bh\bh\bhs\bs\bs\bs
+ 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
+ depending on the kinds of hosts being served.
- A bootp host on that subnet that needs to be in a differ
- ent domain and use a different name server might be
- declared as follows:
+ 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-
+ ment on a manufacturing floor, it may make more sense to
+ assign a maximum lease length of 30 minutes - enough time to
+ go through a simple test procedure on a network appliance
+ before packaging it up for delivery.
- host haagen {
- hardware ethernet 08:00:2b:4c:59:23;
- fixed-address 239.252.197.9;
- filename "/tftpboot/haagen.boot";
- option domain-name-servers 192.5.5.1;
- option domain-name "vix.com";
- }
+ 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:
- A more complete description of the dhcpd.conf file syntax
- is provided in dhcpd.conf(5).
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
+ default-lease-time 600;
+ max-lease-time 7200;
+ |
-F\bFI\bIL\bLE\bES\bS
- /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcp\bpd\bd.\b.c\bco\bon\bnf\bf,\b, /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs,\b, /\b/v\bva\bar\br/\b/r\bru\bun\bn/\b/d\bdh\bhc\bcp\bpd\bd.\b.p\bpi\bid\bd,\b,
- /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs~\b~.\b.
+ 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.
+B\bB\bB\bBO\bO\bO\bOO\bO\bO\bOT\bT\bT\bTP\bP\bP\bP S\bS\bS\bSu\bu\bu\bup\bp\bp\bpp\bp\bp\bpo\bo\bo\bor\br\br\brt\bt\bt\bt
+ Each BOOTP client must be explicitly declared in the
+ dhcpd.conf file. A very basic client declaration will
+ specify the client network interface's hardware address and
- 5
+SunOS 5.6 Last change: 4
-dhcpd(8) dhcpd(8)
+Maintenance Procedures dhcpd(8)
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) 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
- h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
+ the IP address to assign to that client. If the client
+ needs to be able to load a boot file from the server, that
+ file's name must be specified. A simple bootp client
+ declaration might look like this:
+ host haagen {
+ hardware ethernet 08:00:2b:4c:59:23;
+ fixed-address 239.252.197.9;
+ filename "/tftpboot/haagen.boot";
+ }
+O\bO\bO\bOp\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs
+ DHCP (and also BOOTP with Vendor Extensions) provide a
+ mechanism whereby the server can provide the client with
+ information about how to configure its network interface
+ (e.g., subnet mask), and also how the client can access
+ various network services (e.g., DNS, IP routers, and so on).
+ These options can be specified on a per-subnet basis, and,
+ for BOOTP clients, also on a per-client basis. In the
+ event that a BOOTP client declaration specifies options that
+ are also specified in its subnet declaration, the options
+ specified in the client declaration take precedence. An
+ reasonably complete DHCP configuration might look something
+ like this:
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.250;
+ default-lease-time 600 max-lease-time 7200;
+ option subnet-mask 255.255.255.0;
+ option broadcast-address 239.252.197.255;
+ option routers 239.252.197.1;
+ option domain-name-servers 239.252.197.2, 239.252.197.3;
+ option domain-name "isc.org";
+ }
+ A bootp host on that subnet that needs to be in a different
+ domain and use a different name server might be declared as
+ follows:
+ host haagen {
+ hardware ethernet 08:00:2b:4c:59:23;
+ fixed-address 239.252.197.9;
+ filename "/tftpboot/haagen.boot";
+ option domain-name-servers 192.5.5.1;
+ option domain-name "vix.com";
+ }
+ A more complete description of the dhcpd.conf file syntax is
+ provided in dhcpd.conf(5).
+SunOS 5.6 Last change: 5
+Maintenance Procedures dhcpd(8)
+F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
+ /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf,\b,\b,\b, /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs,\b,\b,\b, /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.p\bp\bp\bpi\bi\bi\bid\bd\bd\bd,\b,\b,\b,
+ /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs~\b~\b~\b~.\b.\b.\b.
+S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
+ dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)
+A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) 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
+ h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
- 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+SunOS 5.6 Last change: 6
+
-dhcpd.conf(5) dhcpd.conf(5)
-
-
-N\bNA\bAM\bME\bE
- dhcpd.conf - dhcpd configuration file
-
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- The dhcpd.conf file contains configuration information for
- _\bd_\bh_\bc_\bp_\bd_\b, the Internet Software Consortium DHCP Server.
-
- The dhcpd.conf file is a free-form ASCII text file. It
- is parsed by the recursive-descent parser built into
- dhcpd. The file may contain extra tabs and newlines for
- formatting purposes. Keywords in the file are case-insen
- sitive. Comments may be placed anywhere within the file
- (except within quotes). Comments begin with the # char
- acter and end at the end of the line.
-
- The file essentially consists of a list of statements.
- Statements fall into two broad categories - parameters and
- declarations.
-
- Parameter statements either say how to do something (e.g.,
- how long a lease to offer), whether to do something (e.g.,
- should dhcpd provide addresses to unknown clients), or
- what parameters to provide to the client (e.g., use gate
- way 220.177.244.7).
-
- Declarations are used to describe the topology of the net
- work, to describe clients on the network, to provide
- addresses that can be assigned to clients, or to apply a
- group of parameters to a group of declarations. In any
- group of parameters and declarations, all parameters must
- be specified before any declarations which depend on those
- parameters may be specified.
-
- Declarations about network topology include the
- _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk and the _\bs_\bu_\bb_\bn_\be_\bt declarations. If clients
- on a subnet are to be assigned addresses dynamically, a
- _\br_\ba_\bn_\bg_\be declaration must appear within the _\bs_\bu_\bb_\bn_\be_\bt declara
- tion. For clients with statically assigned addresses, or
- for installations where only known clients will be served,
- each such client must have a _\bh_\bo_\bs_\bt declaration. If param
- eters are to be applied to a group of declarations which
- are not related strictly on a per-subnet basis, the _\bg_\br_\bo_\bu_\bp
- declaration can be used.
-
- For every subnet which will be served, and for every sub
- net to which the dhcp server is connected, there must be
- one _\bs_\bu_\bb_\bn_\be_\bt declaration, which tells dhcpd how to recognize
- that an address is on that subnet. A _\bs_\bu_\bb_\bn_\be_\bt declaration
- is required for each subnet even if no addresses will be
- dynamically allocated on that subnet.
-
- Some installations have physical networks on which more
- than one IP subnet operates. For example, if there is a
- site-wide requirement that 8-bit subnet masks be used, but
-
-
-
- 1
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- a department with a single physical ethernet network
- expands to the point where it has more than 254 nodes, it
- may be necessary to run two 8-bit subnets on the same eth
- ernet until such time as a new physical network can be
- added. In this case, the _\bs_\bu_\bb_\bn_\be_\bt declarations for these
- two networks may be enclosed in a _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk declara
- tion.
-
- Some sites may have departments which have clients on more
- than one subnet, but it may be desirable to offer those
- clients a uniform set of parameters which are different
- than what would be offered to clients from other depart
- ments on the same subnet. For clients which will be
- declared explicitly with _\bh_\bo_\bs_\bt declarations, these declara
- tions can be enclosed in a _\bg_\br_\bo_\bu_\bp declaration along with
- the parameters which are common to that department. For
- clients whose addresses will be dynamically assigned,
- there is currently no way to group parameter assignments
- other than by network topology.
-
- When a client is to be booted, its boot parameters are
- determined by first consulting that client's _\bh_\bo_\bs_\bt declara
- tion (if any), then consulting the _\bg_\br_\bo_\bu_\bp declaration (if
- any) which enclosed that _\bh_\bo_\bs_\bt declaration, then consulting
- the _\bs_\bu_\bb_\bn_\be_\bt declaration for the subnet on which the client
- is booting, then consulting the _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk declaration
- (if any) containing that subnet, and finally consulting
- the top-level parameters which may be specified outside of
- any declaration.
-
- When dhcpd tries to find a _\bh_\bo_\bs_\bt declaration for a client,
- it first looks for a _\bh_\bo_\bs_\bt declaration which has a _\bf_\bi_\bx_\be_\bd_\b-
- _\ba_\bd_\bd_\br_\be_\bs_\bs parameter which matches the subnet or shared net
- work on which the client is booting. If it doesn't find
- any such entry, it then tries to find an entry which has
- no _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs parameter. If no such entry is found,
- then dhcpd acts as if there is no entry in the dhcpd.conf
- file for that client, even if there is an entry for that
- client on a different subnet or shared network.
-
-E\bEX\bXA\bAM\bMP\bPL\bLE\bES\bS
- A typical dhcpd.conf file will look something like this:
-
- _\bg_\bl_\bo_\bb_\ba_\bl _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
-
- subnet 204.254.239.0 netmask 255.255.255.224 {
- _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- range 204.254.239.10 204.254.239.30;
- }
+Headers, Environments, and Macros dhcpd.conf(5)
- subnet 204.254.239.32 netmask 255.255.255.224 {
- _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- range 204.254.239.42 204.254.239.62;
- }
+N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
+ dhcpd.conf - dhcpd configuration file
- 2
+D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ The dhcpd.conf file contains configuration information for
+ _\bd_\bh_\bc_\bp_\bd, the Internet Software Consortium DHCP Server.
+ The dhcpd.conf file is a free-form ASCII text file. It is
+ parsed by the recursive-descent parser built into dhcpd.
+ The file may contain extra tabs and newlines for formatting
+ purposes. Keywords in the file are case-insensitive. Com-
+ ments may be placed anywhere within the file (except within
+ quotes). Comments begin with the # character and end at
+ the end of the line.
+ The file essentially consists of a list of statements.
+ Statements fall into two broad categories - parameters and
+ declarations.
+ Parameter statements either say how to do something (e.g.,
+ how long a lease to offer), whether to do something (e.g.,
+ should dhcpd provide addresses to unknown clients), or what
+ parameters to provide to the client (e.g., use gateway
+ 220.177.244.7).
+ Declarations are used to describe the topology of the net-
+ work, to describe clients on the network, to provide
+ addresses that can be assigned to clients, or to apply a
+ group of parameters to a group of declarations. In any
+ group of parameters and declarations, all parameters must be
+ specified before any declarations which depend on those
+ parameters may be specified.
+
+ Declarations about network topology include the
+ _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk and the _\bs_\bu_\bb_\bn_\be_\bt declarations. If clients on
+ a subnet are to be assigned addresses dynamically, a _\br_\ba_\bn_\bg_\be
+ declaration must appear within the _\bs_\bu_\bb_\bn_\be_\bt declaration. For
+ clients with statically assigned addresses, or for installa-
+ tions where only known clients will be served, each such
+ client must have a _\bh_\bo_\bs_\bt declaration. If parameters are to
+ be applied to a group of declarations which are not related
+ strictly on a per-subnet basis, the _\bg_\br_\bo_\bu_\bp declaration can be
+ used.
+
+ For every subnet which will be served, and for every subnet
+ to which the dhcp server is connected, there must be one
+ _\bs_\bu_\bb_\bn_\be_\bt declaration, which tells dhcpd how to recognize that
+ an address is on that subnet. A _\bs_\bu_\bb_\bn_\be_\bt declaration is
+ required for each subnet even if no addresses will be dynam-
+ ically allocated on that subnet.
-dhcpd.conf(5) dhcpd.conf(5)
- subnet 204.254.239.64 netmask 255.255.255.224 {
- _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- range 204.254.239.74 204.254.239.94;
- }
- group {
- _\bg_\br_\bo_\bu_\bp_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- host zappo.test.isc.org {
- _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- }
- host beppo.test.isc.org {
- _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- }
- host harpo.test.isc.org {
- _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
- }
- }
- Figure 1
+SunOS 5.6 Last change: 1
- Notice that at the beginning of the file, there's a place
- for global parameters. These might be things like the
- organization's domain name, the addresses of the name
- servers (if they are common to the entire organization),
- and so on. So, for example:
- option domain-name "isc.org";
- option domain-name-servers ns1.isc.org, ns2.isc.org;
- Figure 2
- As you can see in Figure 2, you can specify host addresses
- in parameters using their domain names rather than their
- numeric IP addresses. If a given hostname resolves to
- more than one IP address (for example, if that host has
- two ethernet interfaces), then where possible, both
- addresses are supplied to the client.
- The most obvious reason for having subnet-specific parame
- ters as shown in Figure 1 is that each subnet, of neces
- sity, has its own router. So for the first subnet, for
- example, there should be something like:
+Headers, Environments, and Macros dhcpd.conf(5)
- option routers 204.254.239.1;
- Note that the address here is specified numerically.
- This is not required - if you have a different domain name
- for each interface on your router, it's perfectly legiti
- mate to use the domain name for that interface instead of
- the numeric address. However, in many cases there may be
- only one domain name for all of a router's IP addresses,
- and it would not be appropriate to use that name here.
+ Some installations have physical networks on which more than
+ one IP subnet operates. For example, if there is a site-
+ wide requirement that 8-bit subnet masks be used, but a
+ department with a single physical ethernet network expands
+ to the point where it has more than 254 nodes, it may be
+ necessary to run two 8-bit subnets on the same ethernet
+ until such time as a new physical network can be added. In
+ this case, the _\bs_\bu_\bb_\bn_\be_\bt declarations for these two networks
+ may be enclosed in a _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk declaration.
+ Some sites may have departments which have clients on more
+ than one subnet, but it may be desirable to offer those
+ clients a uniform set of parameters which are different than
+ what would be offered to clients from other departments on
+ the same subnet. For clients which will be declared expli-
+ citly with _\bh_\bo_\bs_\bt declarations, these declarations can be
+ enclosed in a _\bg_\br_\bo_\bu_\bp declaration along with the parameters
+ which are common to that department. For clients whose
+ addresses will be dynamically assigned, there is currently
+ no way to group parameter assignments other than by network
+ topology.
+ When a client is to be booted, its boot parameters are
+ determined by first consulting that client's _\bh_\bo_\bs_\bt declara-
+ tion (if any), then consulting the _\bg_\br_\bo_\bu_\bp declaration (if
+ any) which enclosed that _\bh_\bo_\bs_\bt declaration, then consulting
+ the _\bs_\bu_\bb_\bn_\be_\bt declaration for the subnet on which the client is
+ booting, then consulting the _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk declaration (if
+ any) containing that subnet, and finally consulting the
+ top-level parameters which may be specified outside of any
+ declaration.
- 3
+ When dhcpd tries to find a _\bh_\bo_\bs_\bt declaration for a client, it
+ first looks for a _\bh_\bo_\bs_\bt declaration which has a _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs
+ parameter which matches the subnet or shared network on
+ which the client is booting. If it doesn't find any such
+ entry, it then tries to find an entry which has no _\bf_\bi_\bx_\be_\bd-
+ _\ba_\bd_\bd_\br_\be_\bs_\bs parameter. If no such entry is found, then dhcpd
+ acts as if there is no entry in the dhcpd.conf file for that
+ client, even if there is an entry for that client on a dif-
+ ferent subnet or shared network.
+E\bE\bE\bEX\bX\bX\bXA\bA\bA\bAM\bM\bM\bMP\bP\bP\bPL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
+ A typical dhcpd.conf file will look something like this:
+ _\bg_\bl_\bo_\bb_\ba_\bl _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+ subnet 204.254.239.0 netmask 255.255.255.224 {
+ _\bs_\bu_\bb_\bn_\be_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+ range 204.254.239.10 204.254.239.30;
+ }
-dhcpd.conf(5) dhcpd.conf(5)
- In Figure 1 there is also a _\bg_\br_\bo_\bu_\bp statement, which pro
- vides common parameters for a set of three hosts - zappo,
- beppo and harpo. As you can see, these hosts are all in
- the test.isc.org domain, so it might make sense for a
- group-specific parameter to override the domain name sup
- plied to these hosts:
+SunOS 5.6 Last change: 2
- option domain-name "test.isc.org";
- Also, given the domain they're in, these are probably test
- machines. If we wanted to test the DHCP leasing mecha
- nism, we might set the lease timeout somewhat shorter than
- the default:
- max-lease-time 120;
- default-lease-time 120;
- You may have noticed that while some parameters start with
- the _\bo_\bp_\bt_\bi_\bo_\bn keyword, some do not. Parameters starting
- with the _\bo_\bp_\bt_\bi_\bo_\bn keyword correspond to actual DHCP options,
- while parameters that do not start with the option keyword
- either control the behaviour of the DHCP server (e.g., how
- long a lease dhcpd will give out), or specify client
- parameters that are not optional in the DHCP protocol (for
- example, server-name and filename).
- In Figure 1, each host had _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs.
- These could include such things as the _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option,
- the name of a file to upload (the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\b) _\ba_\bn_\bd
- _\bt_\bh_\be _\ba_\bd_\bd_\br_\be_\bs_\bs _\bo_\bf _\bt_\bh_\be _\bs_\be_\br_\bv_\be_\br _\bf_\br_\bo_\bm _\bw_\bh_\bi_\bc_\bh _\bt_\bo _\bu_\bp_\bl_\bo_\ba_\bd _\bt_\bh_\be _\bf_\bi_\bl_\be
- _\b(_\bt_\bh_\be _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br parameter). In general, any parameter
- can appear anywhere that parameters are allowed, and will
- be applied according to the scope in which the parameter
- appears.
- Imagine that you have a site with a lot of NCD X-Termi
- nals. These terminals come in a variety of models, and
- you want to specify the boot files for each models. One
- way to do this would be to have host declarations for each
- server and group them by model:
+Headers, Environments, and Macros dhcpd.conf(5)
- group {
- filename "Xncd19r";
- next-server ncd-booter;
- host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
- host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
- host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
+
+ subnet 204.254.239.32 netmask 255.255.255.224 {
+ _\bs_\bu_\bb_\bn_\be_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+ range 204.254.239.42 204.254.239.62;
+ }
+
+ subnet 204.254.239.64 netmask 255.255.255.224 {
+ _\bs_\bu_\bb_\bn_\be_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+ range 204.254.239.74 204.254.239.94;
+ }
+
+ group {
+ _\bg_\br_\bo_\bu_\bp-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+ host zappo.test.isc.org {
+ _\bh_\bo_\bs_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+ }
+ host beppo.test.isc.org {
+ _\bh_\bo_\bs_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
}
+ host harpo.test.isc.org {
+ _\bh_\bo_\bs_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+ }
+ }
- group {
- filename "Xncd19c";
- next-server ncd-booter;
+ Figure 1
+ Notice that at the beginning of the file, there's a place
+ for global parameters. These might be things like the
+ organization's domain name, the addresses of the name
+ servers (if they are common to the entire organization), and
+ so on. So, for example:
+ option domain-name "isc.org";
+ option domain-name-servers ns1.isc.org, ns2.isc.org;
- 4
+ Figure 2
+ As you can see in Figure 2, you can specify host addresses
+ in parameters using their domain names rather than their
+ numeric IP addresses. If a given hostname resolves to more
+ than one IP address (for example, if that host has two eth-
+ ernet interfaces), then where possible, both addresses are
+ supplied to the client.
+ The most obvious reason for having subnet-specific parame-
+ ters as shown in Figure 1 is that each subnet, of necessity,
+ has its own router. So for the first subnet, for example,
+ there should be something like:
+ option routers 204.254.239.1;
-dhcpd.conf(5) dhcpd.conf(5)
- host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
- host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
- }
- group {
- filename "XncdHMX";
- next-server ncd-booter;
+SunOS 5.6 Last change: 3
- host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
- host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
- host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
- }
-A\bAD\bDD\bDR\bRE\bES\bSS\bS P\bPO\bOO\bOL\bLS\bS
- The p\bpo\boo\bol\bl declaration can be used to specify a pool of
- addresses that will be treated differently than another
- pool of addresses, even on the same network segment or
- subnet. For example, you may want to provide a large set
- of addresses that can be assigned to DHCP clients that are
- registered to your DHCP server, while providing a smaller
- set of addresses, possibly with short lease times, that
- are available for unknown clients. If you have a fire
- wall, you may be able to arrange for addresses from one
- pool to be allowed access to the Internet, while addresses
- in another pool are not, thus encouraging users to regis
- ter their DHCP clients. To do this, you would set up a
- pair of pool declarations:
-
- subnet 10.0.0.0 netmask 255.255.255.0 {
- option routers 10.0.0.254;
-
- # Unknown clients get this pool.
- pool {
- option domain-name-servers bogus.example.com;
- max-lease-time 300;
- range 10.0.0.200 10.0.0.253;
- allow unknown clients;
- }
- # Known clients get this pool.
- pool {
- option domain-name-servers ns1.example.com, ns2.example.com;
- max-lease-time 28800;
- range 10.0.0.5 10.0.0.199;
- deny unknown clients;
- }
- }
- It is also possible to set up entirely different subnets
- for known and unknown clients - address pools exist at the
- level of shared networks, so address ranges within pool
- declarations can be on different subnets.
+Headers, Environments, and Macros dhcpd.conf(5)
- 5
+ Note that the address here is specified numerically. This
+ is not required - if you have a different domain name for
+ each interface on your router, it's perfectly legitimate to
+ use the domain name for that interface instead of the
+ numeric address. However, in many cases there may be only
+ one domain name for all of a router's IP addresses, and it
+ would not be appropriate to use that name here.
+ In Figure 1 there is also a _\bg_\br_\bo_\bu_\bp statement, which provides
+ common parameters for a set of three hosts - zappo, beppo
+ and harpo. As you can see, these hosts are all in the
+ test.isc.org domain, so it might make sense for a group-
+ specific parameter to override the domain name supplied to
+ these hosts:
+ option domain-name "test.isc.org";
+ Also, given the domain they're in, these are probably test
+ machines. If we wanted to test the DHCP leasing mechanism,
+ we might set the lease timeout somewhat shorter than the
+ default:
+ max-lease-time 120;
+ default-lease-time 120;
-dhcpd.conf(5) dhcpd.conf(5)
+ You may have noticed that while some parameters start with
+ the _\bo_\bp_\bt_\bi_\bo_\bn keyword, some do not. Parameters starting with
+ the _\bo_\bp_\bt_\bi_\bo_\bn keyword correspond to actual DHCP options, while
+ parameters that do not start with the option keyword either
+ control the behaviour of the DHCP server (e.g., how long a
+ lease dhcpd will give out), or specify client parameters
+ that are not optional in the DHCP protocol (for example,
+ server-name and filename).
+ In Figure 1, each host had _\bh_\bo_\bs_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs. These
+ could include such things as the _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option, the name
+ of a file to upload (the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br) _\ba_\bn_\bd _\bt_\bh_\be _\ba_\bd_\bd_\br_\be_\bs_\bs
+ _\bo_\bf _\bt_\bh_\be _\bs_\be_\br_\bv_\be_\br _\bf_\br_\bo_\bm _\bw_\bh_\bi_\bc_\bh _\bt_\bo _\bu_\bp_\bl_\bo_\ba_\bd _\bt_\bh_\be _\bf_\bi_\bl_\be (_\bt_\bh_\be _\bn_\be_\bx_\bt-_\bs_\be_\br_\bv_\be_\br
+ parameter). In general, any parameter can appear anywhere
+ that parameters are allowed, and will be applied according
+ to the scope in which the parameter appears.
-C\bCL\bLI\bIE\bEN\bNT\bT C\bCL\bLA\bAS\bSS\bSI\bIN\bNG\bG
- Clients can be seperated into classes, and treated differ
- ently depending on what class they are in. This sepera
- tion can be done either with a conditional statement, or
- with a match statement within the class declaration. It
- is possible to specify a limit on the total number of
- clients within a particular class or subclass that may
- hold leases at one time, and it is possible to specify
- automatic subclassing based on the contents of the client
- packet.
+ Imagine that you have a site with a lot of NCD X-Terminals.
+ These terminals come in a variety of models, and you want to
+ specify the boot files for each models. One way to do this
+ would be to have host declarations for each server and group
+ them by model:
- To add clients to classes based on conditional evaluation,
- you would write an conditional statement to match the
- clients you wanted in the class, and then put an a\bad\bdd\bd
- statement in the conditional's list of statements:
+ group {
+ filename "Xncd19r";
+ next-server ncd-booter;
- if substring (option dhcp-client-identifier, 0, 3) = "RAS" {
- add ras-clients;
- }
- An equivalent way to do this is to simply specify the con
- ditional expression as a matching expression in the class
- statement:
- class ras-clients {
- match if substring (option dhcp-client-identifier, 0, 3) = "RAS";
- }
- In addition to classes, it is possible to declare sub
- classes. A subclass is a class with the same name as a
- regular class, but with a specific submatch expression
- which is hashed for quick matching. This is essentially a
- speed hack - the main difference between five classes with
- match expressions and one class with five subclasses is
- that it will be quicker to find the subclasses. Sub
- classes work as follows:
-
- class vendor-classes {
- match option vendor-class-identifier;
- }
+SunOS 5.6 Last change: 4
+
- subclass vendor-classes "SUNW.Ultra-5_10" {
- option vendor-encapsulated-options
- 2:AC:11:41:1:
- 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
- 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:73:70:61:72:63;
- }
- subclass vendor-classes "SUNW.i86pc" {
- option vendor-encapsulated-options
- 2:4:AC:11:41:1:
- 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
- 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;
- }
- 6
+Headers, Environments, and Macros dhcpd.conf(5)
+ host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
+ host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
+ host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
+ }
+ group {
+ filename "Xncd19c";
+ next-server ncd-booter;
-dhcpd.conf(5) dhcpd.conf(5)
+ host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
+ host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
+ }
+ group {
+ filename "XncdHMX";
+ next-server ncd-booter;
- The string following the class name for the subclasses
- specifies the string that is expected to match the expres
- sion in the class declaration for the vendor-classes
- class.
+ host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
+ host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
+ host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
+ }
- You may specify a limit to the number of clients in a
- class that can be assigned leases. The effect of this
- will be to make it difficult for a new client in a class
- to get an address. Once a class with such a limit has
- reached its limit, the only way a new client in that class
- can get a lease is for an existing client to relinquish
- its lease, either by letting it expire, or by sending a
- DHCPRELEASE packet. Classes with lease limits are speci
- fied as follows:
+A\bA\bA\bAD\bD\bD\bDD\bD\bD\bDR\bR\bR\bRE\bE\bE\bES\bS\bS\bSS\bS\bS\bS P\bP\bP\bPO\bO\bO\bOO\bO\bO\bOL\bL\bL\bLS\bS\bS\bS
+ The p\bp\bp\bpo\bo\bo\boo\bo\bo\bol\bl\bl\bl declaration can be used to specify a pool of
+ addresses that will be treated differently than another pool
+ of addresses, even on the same network segment or subnet.
+ For example, you may want to provide a large set of
+ addresses that can be assigned to DHCP clients that are
+ registered to your DHCP server, while providing a smaller
+ set of addresses, possibly with short lease times, that are
+ available for unknown clients. If you have a firewall, you
+ may be able to arrange for addresses from one pool to be
+ allowed access to the Internet, while addresses in another
+ pool are not, thus encouraging users to register their DHCP
+ clients. To do this, you would set up a pair of pool
+ declarations:
- class limited-1 {
- lease limit 4;
+ subnet 10.0.0.0 netmask 255.255.255.0 {
+ option routers 10.0.0.254;
+
+ # Unknown clients get this pool.
+ pool {
+ option domain-name-servers bogus.example.com;
+ max-lease-time 300;
+ range 10.0.0.200 10.0.0.253;
+ allow unknown clients;
}
- This will produce a class in which a maximum of four mem
- bers may hold a lease at one time.
-
- It is possible to declare a _\bs_\bp_\ba_\bw_\bn_\bi_\bn_\bg _\bc_\bl_\ba_\bs_\bs. A spawning
- class is a class that automatically produces subclasses
- based on what the client sends. The reason that spawning
- classes were created was to make it possible to create
- lease-limited classes on the fly. The envisioned appli
- cation is a cable-modem environment where the ISP wishes
- to provide clients at a particular site with more than one
- IP address, but does not wish to provide such clients with
- their own subnet, nor give them an unlimited number of IP
- addresses from the network segment to which they are con
- nected.
-
- Many cable modem head-end systems can be configured to add
- a Relay Agent Information option to DHCP packets when
- relaying them to the DHCP server. These systems typi
- cally add a circuit ID or remote ID option that uniquely
- identifies the customer site. To take advantage of this,
- you can write a class declaration as follows:
- class customer {
- match if exists agent.circuit-id;
- spawn with agent.circuit-id;
- lease limit 4;
+ # Known clients get this pool.
+ pool {
+ option domain-name-servers ns1.example.com, ns2.example.com;
+ max-lease-time 28800;
+
+
+
+SunOS 5.6 Last change: 5
+
+
+
+
+
+
+Headers, Environments, and Macros dhcpd.conf(5)
+
+
+
+ range 10.0.0.5 10.0.0.199;
+ deny unknown clients;
}
+ }
- Now whenever a request comes in from a customer site, the
- circuit ID option will be checked against the class's hash
- table. If a subclass is found that matches the circuit
- ID, the client will be classified in that subclass and
- treated accordingly. If no subclass is found matching
- the circuit ID, a new one will be created and logged in
- the d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs file, and the client will be classified
- in this new class. Once the client has been classified,
+ It is also possible to set up entirely different subnets for
+ known and unknown clients - address pools exist at the level
+ of shared networks, so address ranges within pool declara-
+ tions can be on different subnets.
+C\bC\bC\bCL\bL\bL\bLI\bI\bI\bIE\bE\bE\bEN\bN\bN\bNT\bT\bT\bT C\bC\bC\bCL\bL\bL\bLA\bA\bA\bAS\bS\bS\bSS\bS\bS\bSI\bI\bI\bIN\bN\bN\bNG\bG\bG\bG
+ Clients can be seperated into classes, and treated dif-
+ ferently depending on what class they are in. This sepera-
+ tion can be done either with a conditional statement, or
+ with a match statement within the class declaration. It is
+ possible to specify a limit on the total number of clients
+ within a particular class or subclass that may hold leases
+ at one time, and it is possible to specify automatic sub-
+ classing based on the contents of the client packet.
+ To add clients to classes based on conditional evaluation,
+ you would write an conditional statement to match the
+ clients you wanted in the class, and then put an a\ba\ba\bad\bd\bd\bdd\bd\bd\bd state-
+ ment in the conditional's list of statements:
- 7
+ if substring (option dhcp-client-identifier, 0, 3) = "RAS" {
+ add ras-clients;
+ }
+ An equivalent way to do this is to simply specify the condi-
+ tional expression as a matching expression in the class
+ statement:
+ class ras-clients {
+ match if substring (option dhcp-client-identifier, 0, 3) = "RAS";
+ }
+ In addition to classes, it is possible to declare subc-
+ lasses. A subclass is a class with the same name as a reg-
+ ular class, but with a specific submatch expression which is
+ hashed for quick matching. This is essentially a speed hack
+ - the main difference between five classes with match
+ expressions and one class with five subclasses is that it
+ will be quicker to find the subclasses. Subclasses work as
+ follows:
+ class vendor-classes {
+ match option vendor-class-identifier;
+ }
-dhcpd.conf(5) dhcpd.conf(5)
+ subclass vendor-classes "SUNW.Ultra-5_10" {
+ option vendor-encapsulated-options
- it will be treated according to the rules of the class,
- including, in this case, being subject to the per-site
- limit of four leases.
- The use of the subclass spawning mechanism is not
- restricted to relay agent options - this particular exam
- ple is given only because it is a fairly straightforward
- one.
+SunOS 5.6 Last change: 6
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
- T\bTh\bhe\be _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- s\bsh\bha\bar\bre\bed\bd-\b-n\bne\bet\btw\bwo\bor\brk\bk _\bn_\ba_\bm_\be {\b{
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}
- The _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk statement is used to inform the DHCP
- server that some IP subnets actually share the same physi
- cal network. Any subnets in a shared network should be
- declared within a _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk statement. Parameters
- specified in the _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk statement will be used
- when booting clients on those subnets unless parameters
- provided at the subnet or host level override them. If
- any subnet in a shared network has addresses available for
- dynamic allocation, those addresses are collected into a
- common pool for that shared network and assigned to
- clients as needed. There is no way to distinguish on
- which subnet of a shared network a client should boot.
- _\bN_\ba_\bm_\be should be the name of the shared network. This name
- is used when printing debugging messages, so it should be
- descriptive for the shared network. The name may have
- the syntax of a valid domain name (although it will never
- be used as such), or it may be any arbitrary name,
- enclosed in quotes.
- T\bTh\bhe\be _\bs_\bu_\bb_\bn_\be_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- s\bsu\bub\bbn\bne\bet\bt _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bn_\bu_\bm_\bb_\be_\br n\bne\bet\btm\bma\bas\bsk\bk _\bn_\be_\bt_\bm_\ba_\bs_\bk {\b{
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}
+Headers, Environments, and Macros dhcpd.conf(5)
- The _\bs_\bu_\bb_\bn_\be_\bt statement is used to provide dhcpd with enough
- information to tell whether or not an IP address is on
- that subnet. It may also be used to provide subnet-spe
- cific parameters and to specify what addresses may be
- dynamically allocated to clients booting on that subnet.
- Such addresses are specified using the _\br_\ba_\bn_\bg_\be declaration.
- The _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bn_\bu_\bm_\bb_\be_\br should be an IP address or domain name
- which resolves to the subnet number of the subnet being
- described. The _\bn_\be_\bt_\bm_\ba_\bs_\bk should be an IP address or domain
+ 2:AC:11:41:1:
+ 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
+ 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:73:70:61:72:63;
+ }
+ subclass vendor-classes "SUNW.i86pc" {
+ option vendor-encapsulated-options
+ 2:4:AC:11:41:1:
+ 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
+ 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;
+ }
- 8
+ The string following the class name for the subclasses
+ specifies the string that is expected to match the expres-
+ sion in the class declaration for the vendor-classes class.
+ You may specify a limit to the number of clients in a class
+ that can be assigned leases. The effect of this will be to
+ make it difficult for a new client in a class to get an
+ address. Once a class with such a limit has reached its
+ limit, the only way a new client in that class can get a
+ lease is for an existing client to relinquish its lease,
+ either by letting it expire, or by sending a DHCPRELEASE
+ packet. Classes with lease limits are specified as fol-
+ lows:
+ class limited-1 {
+ lease limit 4;
+ }
+ This will produce a class in which a maximum of four members
+ may hold a lease at one time.
+ It is possible to declare a _\bs_\bp_\ba_\bw_\bn_\bi_\bn_\bg _\bc_\bl_\ba_\bs_\bs. A spawning class
+ is a class that automatically produces subclasses based on
+ what the client sends. The reason that spawning classes
+ were created was to make it possible to create lease-limited
+ classes on the fly. The envisioned application is a
+ cable-modem environment where the ISP wishes to provide
+ clients at a particular site with more than one IP address,
+ but does not wish to provide such clients with their own
+ subnet, nor give them an unlimited number of IP addresses
+ from the network segment to which they are connected.
-dhcpd.conf(5) dhcpd.conf(5)
+ Many cable modem head-end systems can be configured to add a
+ Relay Agent Information option to DHCP packets when relaying
+ them to the DHCP server. These systems typically add a
+ circuit ID or remote ID option that uniquely identifies the
+ customer site. To take advantage of this, you can write a
+ class declaration as follows:
+ class customer {
+ match if exists agent.circuit-id;
- name which resolves to the subnet mask of the subnet being
- described. The subnet number, together with the netmask,
- are sufficient to determine whether any given IP address
- is on the specified subnet.
- Although a netmask must be given with every subnet decla
- ration, it is recommended that if there is any variance in
- subnet masks at a site, a subnet-mask option statement be
- used in each subnet declaration to set the desired subnet
- mask, since any subnet-mask option statement will override
- the subnet mask declared in the subnet statement.
+SunOS 5.6 Last change: 7
- T\bTh\bhe\be _\br_\ba_\bn_\bg_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- r\bra\ban\bng\bge\be [ d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp ] _\bl_\bo_\bw_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [ _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs];\b;
- For any subnet on which addresses will be assigned dynami
- cally, there must be at least one _\br_\ba_\bn_\bg_\be statement. The
- range statement gives the lowest and highest IP addresses
- in a range. All IP addresses in the range should be in
- the subnet in which the _\br_\ba_\bn_\bg_\be statement is declared. The
- _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp flag may be specified if addresses in the
- specified range may be dynamically assigned to BOOTP
- clients as well as DHCP clients. When specifying a sin
- gle address, _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs can be omitted.
- T\bTh\bhe\be _\bh_\bo_\bs_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- h\bho\bos\bst\bt _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be {
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}
- There must be at least one h\bho\bos\bst\bt statement for every BOOTP
- client that is to be served. h\bho\bos\bst\bt statements may also be
- specified for DHCP clients, although this is not required
- unless booting is only enabled for known hosts.
+Headers, Environments, and Macros dhcpd.conf(5)
- If it is desirable to be able to boot a DHCP or BOOTP
- client on more than one subnet with fixed addresses, more
- than one address may be specified in the _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- parameter, or more than one h\bho\bos\bst\bt statement may be speci
- fied.
- If client-specific boot parameters must change based on
- the network to which the client is attached, then multiple
- h\bho\bos\bst\bt statements should be used.
- If a client is to be booted using a fixed address if it's
- possible, but should be allocated a dynamic address other
- wise, then a h\bho\bos\bst\bt statement must be specified without a
- f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs clause. _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be should be a name identify
- ing the host. If a _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option is not specified for
- the host, _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be is used.
+ spawn with agent.circuit-id;
+ lease limit 4;
+ }
+ Now whenever a request comes in from a customer site, the
+ circuit ID option will be checked against the class's hash
+ table. If a subclass is found that matches the circuit ID,
+ the client will be classified in that subclass and treated
+ accordingly. If no subclass is found matching the circuit
+ ID, a new one will be created and logged in the d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs
+ file, and the client will be classified in this new class.
+ Once the client has been classified, it will be treated
+ according to the rules of the class, including, in this
+ case, being subject to the per-site limit of four leases.
+ The use of the subclass spawning mechanism is not restricted
+ to relay agent options - this particular example is given
+ only because it is a fairly straightforward one.
- 9
+R\bR\bR\bRE\bE\bE\bEF\bF\bF\bFE\bE\bE\bER\bR\bR\bRE\bE\bE\bEN\bN\bN\bNC\bC\bC\bCE\bE\bE\bE:\b:\b:\b: D\bD\bD\bDE\bE\bE\bEC\bC\bC\bCL\bL\bL\bLA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ s\bs\bs\bsh\bh\bh\bha\ba\ba\bar\br\br\bre\be\be\bed\bd\bd\bd-\b-\b-\b-n\bn\bn\bne\be\be\bet\bt\bt\btw\bw\bw\bwo\bo\bo\bor\br\br\brk\bk\bk\bk _\bn_\ba_\bm_\be {\b{\b{\b{
+ [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
+ [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
+ }\b}\b}\b}
+ The _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk statement is used to inform the DHCP
+ server that some IP subnets actually share the same physical
+ network. Any subnets in a shared network should be declared
+ within a _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk statement. Parameters specified in
+ the _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk statement will be used when booting
+ clients on those subnets unless parameters provided at the
+ subnet or host level override them. If any subnet in a
+ shared network has addresses available for dynamic alloca-
+ tion, those addresses are collected into a common pool for
+ that shared network and assigned to clients as needed.
+ There is no way to distinguish on which subnet of a shared
+ network a client should boot.
+ _\bN_\ba_\bm_\be should be the name of the shared network. This name
+ is used when printing debugging messages, so it should be
+ descriptive for the shared network. The name may have the
+ syntax of a valid domain name (although it will never be
+ used as such), or it may be any arbitrary name, enclosed in
+ quotes.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bs_\bu_\bb_\bn_\be_\bt s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
-dhcpd.conf(5) dhcpd.conf(5)
+ s\bs\bs\bsu\bu\bu\bub\bb\bb\bbn\bn\bn\bne\be\be\bet\bt\bt\bt _\bs_\bu_\bb_\bn_\be_\bt-_\bn_\bu_\bm_\bb_\be_\br n\bn\bn\bne\be\be\bet\bt\bt\btm\bm\bm\bma\ba\ba\bas\bs\bs\bsk\bk\bk\bk _\bn_\be_\bt_\bm_\ba_\bs_\bk {\b{\b{\b{
+ [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
+ [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- _\bH_\bo_\bs_\bt declarations are matched to actual DHCP or BOOTP
- clients by matching the dhcp-client-identifier option
- specified in the _\bh_\bo_\bs_\bt declaration to the one supplied by
- the client, or, if the _\bh_\bo_\bs_\bt declaration or the client does
- not provide a dhcp-client-identifier option, by matching
- the _\bh_\ba_\br_\bd_\bw_\ba_\br_\be parameter in the _\bh_\bo_\bs_\bt declaration to the net
- work hardware address supplied by the client. BOOTP
- clients do not normally provide a _\bd_\bh_\bc_\bp_\b-_\bc_\bl_\bi_\be_\bn_\bt_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br,
- so the hardware address must be used for all clients that
- may boot using the BOOTP protocol.
- T\bTh\bhe\be _\bg_\br_\bo_\bu_\bp s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+SunOS 5.6 Last change: 8
- g\bgr\bro\bou\bup\bp {
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}
- The group statement is used simply to apply one or more
- parameters to a group of declarations. It can be used to
- group hosts, shared networks, subnets, or even other
- groups.
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: A\bAL\bLL\bLO\bOW\bW a\ban\bnd\bd D\bDE\bEN\bNY\bY
- The _\ba_\bl_\bl_\bo_\bw and _\bd_\be_\bn_\by statements can be used to control the
- behaviour of dhcpd to various sorts of requests.
- T\bTh\bhe\be _\bu_\bn_\bk_\bn_\bo_\bw_\bn_\b-_\bc_\bl_\bi_\be_\bn_\bt_\bs k\bke\bey\byw\bwo\bor\brd\bd
- a\bal\bll\blo\bow\bw u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;
- d\bde\ben\bny\by u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;
+Headers, Environments, and Macros dhcpd.conf(5)
- The u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs flag is used to tell dhcpd whether or
- not to dynamically assign addresses to unknown clients.
- Dynamic address assignment to unknown clients is a\bal\bll\blo\bow\bwed
- by default.
- T\bTh\bhe\be _\bb_\bo_\bo_\bt_\bp k\bke\bey\byw\bwo\bor\brd\bd
- a\bal\bll\blo\bow\bw b\bbo\boo\bot\btp\bp;\b;
- d\bde\ben\bny\by b\bbo\boo\bot\btp\bp;\b;
+ }\b}\b}\b}
- The b\bbo\boo\bot\btp\bp flag is used to tell dhcpd whether or not to
- respond to bootp queries. Bootp queries are a\bal\bll\blo\bow\bwed by
- default.
+ The _\bs_\bu_\bb_\bn_\be_\bt statement is used to provide dhcpd with enough
+ information to tell whether or not an IP address is on that
+ subnet. It may also be used to provide subnet-specific
+ parameters and to specify what addresses may be dynamically
+ allocated to clients booting on that subnet. Such
+ addresses are specified using the _\br_\ba_\bn_\bg_\be declaration.
- T\bTh\bhe\be _\bb_\bo_\bo_\bt_\bi_\bn_\bg k\bke\bey\byw\bwo\bor\brd\bd
+ The _\bs_\bu_\bb_\bn_\be_\bt-_\bn_\bu_\bm_\bb_\be_\br should be an IP address or domain name
+ which resolves to the subnet number of the subnet being
+ described. The _\bn_\be_\bt_\bm_\ba_\bs_\bk should be an IP address or domain
+ name which resolves to the subnet mask of the subnet being
+ described. The subnet number, together with the netmask,
+ are sufficient to determine whether any given IP address is
+ on the specified subnet.
- a\bal\bll\blo\bow\bw b\bbo\boo\bot\bti\bin\bng\bg;\b;
- d\bde\ben\bny\by b\bbo\boo\bot\bti\bin\bng\bg;\b;
+ Although a netmask must be given with every subnet declara-
+ tion, it is recommended that if there is any variance in
+ subnet masks at a site, a subnet-mask option statement be
+ used in each subnet declaration to set the desired subnet
+ mask, since any subnet-mask option statement will override
+ the subnet mask declared in the subnet statement.
- The b\bbo\boo\bot\bti\bin\bng\bg flag is used to tell dhcpd whether or not to
- respond to queries from a particular client. This keyword
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\br_\ba_\bn_\bg_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ r\br\br\bra\ba\ba\ban\bn\bn\bng\bg\bg\bge\be\be\be [ d\bd\bd\bdy\by\by\byn\bn\bn\bna\ba\ba\bam\bm\bm\bmi\bi\bi\bic\bc\bc\bc-\b-\b-\b-b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp ] _\bl_\bo_\bw-_\ba_\bd_\bd_\br_\be_\bs_\bs [
+ For any subnet on which addresses will be assigned dynami-
+ cally, there must be at least one _\br_\ba_\bn_\bg_\be statement. The
+ range statement gives the lowest and highest IP addresses in
+ a range. All IP addresses in the range should be in the
+ subnet in which the _\br_\ba_\bn_\bg_\be statement is declared. The
+ _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp flag may be specified if addresses in the
+ specified range may be dynamically assigned to BOOTP clients
+ as well as DHCP clients. When specifying a single address,
+ _\bh_\bi_\bg_\bh-_\ba_\bd_\bd_\br_\be_\bs_\bs can be omitted.
- 10
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bh_\bo_\bs_\bt s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be {
+ [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
+ [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
+ }\b}\b}\b}
+ There must be at least one h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt statement for every BOOTP
+ client that is to be served. h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt statements may also be
+ specified for DHCP clients, although this is not required
+ unless booting is only enabled for known hosts.
+ If it is desirable to be able to boot a DHCP or BOOTP client
+ on more than one subnet with fixed addresses, more than one
-dhcpd.conf(5) dhcpd.conf(5)
+SunOS 5.6 Last change: 9
- only has meaning when it appears in a host declaration.
- By default, booting is a\bal\bll\blo\bow\bwed, but if it is disabled for
- a particular client, then that client will not be able to
- get and address from the DHCP server.
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: P\bPA\bAR\bRA\bAM\bME\bET\bTE\bER\bRS\bS
- T\bTh\bhe\be _\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- d\bde\bef\bfa\bau\bul\blt\bt-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
- _\bT_\bi_\bm_\be should be the length in seconds that will be assigned
- to a lease if the client requesting the lease does not ask
- for a specific expiration time.
- T\bTh\bhe\be _\bm_\ba_\bx_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- m\bma\bax\bx-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
+Headers, Environments, and Macros dhcpd.conf(5)
- _\bT_\bi_\bm_\be should be the maximum length in seconds that will be
- assigned to a lease. The only exception to this is that
- Dynamic BOOTP lease lengths, which are not specified by
- the client, are not limited by this maximum.
- T\bTh\bhe\be _\bm_\bi_\bn_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- m\bmi\bin\bn-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
+ address may be specified in the _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs parameter, or
+ more than one h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt statement may be specified.
- _\bT_\bi_\bm_\be should be the minimum length in seconds that will be
- assigned to a lease.
+ If client-specific boot parameters must change based on the
+ network to which the client is attached, then multiple h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt
+ statements should be used.
- T\bTh\bhe\be _\bm_\bi_\bn_\b-_\bs_\be_\bc_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ If a client is to be booted using a fixed address if it's
+ possible, but should be allocated a dynamic address other-
+ wise, then a h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt statement must be specified without a
+ f\bf\bf\bfi\bi\bi\bix\bx\bx\bxe\be\be\bed\bd\bd\bd-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\bre\be\be\bes\bs\bs\bss\bs\bs\bs clause. _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be should be a name identifying
+ the host. If a _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option is not specified for the
+ host, _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be is used.
- m\bmi\bin\bn-\b-s\bse\bec\bcs\bs _\bs_\be_\bc_\bo_\bn_\bd_\bs;\b;
+ _\bH_\bo_\bs_\bt declarations are matched to actual DHCP or BOOTP
+ clients by matching the dhcp-client-identifier option speci-
+ fied in the _\bh_\bo_\bs_\bt declaration to the one supplied by the
+ client, or, if the _\bh_\bo_\bs_\bt declaration or the client does not
+ provide a dhcp-client-identifier option, by matching the
+ _\bh_\ba_\br_\bd_\bw_\ba_\br_\be parameter in the _\bh_\bo_\bs_\bt declaration to the network
+ hardware address supplied by the client. BOOTP clients do
+ not normally provide a _\bd_\bh_\bc_\bp-_\bc_\bl_\bi_\be_\bn_\bt-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br, so the
+ hardware address must be used for all clients that may boot
+ using the BOOTP protocol.
- _\bS_\be_\bc_\bo_\bn_\bd_\bs should be the minimum number of seconds since a
- client began trying to acquire a new lease before the DHCP
- server will respond to its request. The number of seconds
- is based on what the client reports, and the maximum value
- that the client can report is 255 seconds. Generally,
- setting this to one will result in the DHCP server not
- responding to the client's first request, but always
- responding to its second request.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bg_\br_\bo_\bu_\bp s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- This can be used to set up a secondary DHCP server which
- never offers an address to a client until the primary
- server has been given a chance to do so. If the primary
- server is down, the client will bind to the secondary
- server, but otherwise clients should always bind to the
- primary. Note that this does not, by itself, permit a
- primary server and a secondary server to share a pool of
- dynamically-allocatable addresses.
+ g\bg\bg\bgr\br\br\bro\bo\bo\bou\bu\bu\bup\bp\bp\bp {
+ [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
+ [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
+ }\b}\b}\b}
- T\bTh\bhe\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ The group statement is used simply to apply one or more
+ parameters to a group of declarations. It can be used to
+ group hosts, shared networks, subnets, or even other groups.
+R\bR\bR\bRE\bE\bE\bEF\bF\bF\bFE\bE\bE\bER\bR\bR\bRE\bE\bE\bEN\bN\bN\bNC\bC\bC\bCE\bE\bE\bE:\b:\b:\b: A\bA\bA\bAL\bL\bL\bLL\bL\bL\bLO\bO\bO\bOW\bW\bW\bW a\ba\ba\ban\bn\bn\bnd\bd\bd\bd D\bD\bD\bDE\bE\bE\bEN\bN\bN\bNY\bY\bY\bY
+ The _\ba_\bl_\bl_\bo_\bw and _\bd_\be_\bn_\by statements can be used to control the
+ behaviour of dhcpd to various sorts of requests.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bu_\bn_\bk_\bn_\bo_\bw_\bn-_\bc_\bl_\bi_\be_\bn_\bt_\bs k\bk\bk\bke\be\be\bey\by\by\byw\bw\bw\bwo\bo\bo\bor\br\br\brd\bd\bd\bd
+ a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bw u\bu\bu\bun\bn\bn\bnk\bk\bk\bkn\bn\bn\bno\bo\bo\bow\bw\bw\bwn\bn\bn\bn-\b-\b-\b-c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bts\bs\bs\bs;\b;\b;\b;
+ d\bd\bd\bde\be\be\ben\bn\bn\bny\by\by\by u\bu\bu\bun\bn\bn\bnk\bk\bk\bkn\bn\bn\bno\bo\bo\bow\bw\bw\bwn\bn\bn\bn-\b-\b-\b-c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bts\bs\bs\bs;\b;\b;\b;
- 11
+ The u\bu\bu\bun\bn\bn\bnk\bk\bk\bkn\bn\bn\bno\bo\bo\bow\bw\bw\bwn\bn\bn\bn-\b-\b-\b-c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bts\bs\bs\bs flag is used to tell dhcpd whether or
+ not to dynamically assign addresses to unknown clients.
+ Dynamic address assignment to unknown clients is a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bwed by
+ default.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bb_\bo_\bo_\bt_\bp k\bk\bk\bke\be\be\bey\by\by\byw\bw\bw\bwo\bo\bo\bor\br\br\brd\bd\bd\bd
-dhcpd.conf(5) dhcpd.conf(5)
+SunOS 5.6 Last change: 10
- h\bha\bar\brd\bdw\bwa\bar\bre\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
- In order for a BOOTP client to be recognized, its network
- hardware address must be declared using a _\bh_\ba_\br_\bd_\bw_\ba_\br_\be clause
- in the _\bh_\bo_\bs_\bt statement. _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be must be the name of
- a physical hardware interface type. Currently, only the
- e\bet\bth\bhe\ber\brn\bne\bet\bt and t\bto\bok\bke\ben\bn-\b-r\bri\bin\bng\bg types are recognized, although
- support for a f\bfd\bdd\bdi\bi hardware type (and others) would also
- be desirable. The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs should be a set of
- hexadecimal octets (numbers from 0 through ff) seperated
- by colons. The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\bf_\bR _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt _\bm_\ba_\by _\ba_\bl_\bs_\bo _\bb_\be _\bu_\bs_\be_\bd _\bf_\bo_\br
- _\bD_\bH_\bC_\bP _\bc_\bl_\bi_\be_\bn_\bt_\bs_\b.
- T\bTh\bhe\be _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- f\bfi\bil\ble\ben\bna\bam\bme\be "\b"_\bf_\bi_\bl_\be_\bn_\ba_\bm_\be"\b";\b;
- The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement can be used to specify the name of
- the initial boot file which is to be loaded by a client.
- The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be should be a filename recognizable to whatever
- file transfer protocol the client can be expected to use
- to load the file.
+Headers, Environments, and Macros dhcpd.conf(5)
- T\bTh\bhe\be _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be "\b"_\bn_\ba_\bm_\be"\b";\b;
- The _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be statement can be used to inform the client
- of the name of the server from which it is booting. _\bN_\ba_\bm_\be
- should be the name that will be provided to the client.
+ a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bw b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp;\b;\b;\b;
+ d\bd\bd\bde\be\be\ben\bn\bn\bny\by\by\by b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp;\b;\b;\b;
- T\bTh\bhe\be _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ The b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp flag is used to tell dhcpd whether or not to
+ respond to bootp queries. Bootp queries are a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bwed by
+ default.
- n\bne\bex\bxt\bt-\b-s\bse\ber\brv\bve\ber\br _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be;\b;
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bb_\bo_\bo_\bt_\bi_\bn_\bg k\bk\bk\bke\be\be\bey\by\by\byw\bw\bw\bwo\bo\bo\bor\br\br\brd\bd\bd\bd
- The _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br statement is used to specify the host
- address of the server from which the initial boot file
- (specified in the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement) is to be loaded.
- _\bS_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be should be a numeric IP address or a domain
- name. If no _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br parameter applies to a given
- client, the DHCP server's IP address is used.
+ a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bw b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bti\bi\bi\bin\bn\bn\bng\bg\bg\bg;\b;\b;\b;
+ d\bd\bd\bde\be\be\ben\bn\bn\bny\by\by\by b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bti\bi\bi\bin\bn\bn\bng\bg\bg\bg;\b;\b;\b;
- T\bTh\bhe\be _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ The b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bti\bi\bi\bin\bn\bn\bng\bg\bg\bg flag is used to tell dhcpd whether or not to
+ respond to queries from a particular client. This keyword
+ only has meaning when it appears in a host declaration. By
+ default, booting is a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bwed, but if it is disabled for a
+ particular client, then that client will not be able to get
+ and address from the DHCP server.
- f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\ba_\bd_\bd_\br_\be_\bs_\bs ... ];\b;
+R\bR\bR\bRE\bE\bE\bEF\bF\bF\bFE\bE\bE\bER\bR\bR\bRE\bE\bE\bEN\bN\bN\bNC\bC\bC\bCE\bE\bE\bE:\b:\b:\b: P\bP\bP\bPA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAM\bM\bM\bME\bE\bE\bET\bT\bT\bTE\bE\bE\bER\bR\bR\bRS\bS\bS\bS
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bd_\be_\bf_\ba_\bu_\bl_\bt-_\bl_\be_\ba_\bs_\be-_\bt_\bi_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- The _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs statement is used to assign one or more
- fixed IP addresses to a client. It should only appear in
- a _\bh_\bo_\bs_\bt declaration. If more than one address is supplied,
- then when the client boots, it will be assigned the
- address which corresponds to the network on which it is
- booting. If none of the addresses in the _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
- statement are on the network on which the client is boot
- ing, that client will not match the _\bh_\bo_\bs_\bt declaration
+ d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\be _\bt_\bi_\bm_\be;\b;\b;\b;
+ _\bT_\bi_\bm_\be should be the length in seconds that will be assigned
+ to a lease if the client requesting the lease does not ask
+ for a specific expiration time.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bm_\ba_\bx-_\bl_\be_\ba_\bs_\be-_\bt_\bi_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- 12
+ m\bm\bm\bma\ba\ba\bax\bx\bx\bx-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\be _\bt_\bi_\bm_\be;\b;\b;\b;
+ _\bT_\bi_\bm_\be should be the maximum length in seconds that will be
+ assigned to a lease. The only exception to this is that
+ Dynamic BOOTP lease lengths, which are not specified by the
+ client, are not limited by this maximum.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bm_\bi_\bn-_\bl_\be_\ba_\bs_\be-_\bt_\bi_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ m\bm\bm\bmi\bi\bi\bin\bn\bn\bn-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\be _\bt_\bi_\bm_\be;\b;\b;\b;
+ _\bT_\bi_\bm_\be should be the minimum length in seconds that will be
+ assigned to a lease.
-dhcpd.conf(5) dhcpd.conf(5)
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bm_\bi_\bn-_\bs_\be_\bc_\bs s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ m\bm\bm\bmi\bi\bi\bin\bn\bn\bn-\b-\b-\b-s\bs\bs\bse\be\be\bec\bc\bc\bcs\bs\bs\bs _\bs_\be_\bc_\bo_\bn_\bd_\bs;\b;\b;\b;
- containing that _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs statement. Each _\ba_\bd_\bd_\br_\be_\bs_\bs
- should be either an IP address or a domain name which
- resolves to one or more IP addresses.
+ _\bS_\be_\bc_\bo_\bn_\bd_\bs should be the minimum number of seconds since a
+ client began trying to acquire a new lease before the DHCP
+ server will respond to its request. The number of seconds
+ is based on what the client reports, and the maximum value
- T\bTh\bhe\be _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bc_\bu_\bt_\bo_\bf_\bf s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp-\b-l\ble\bea\bas\bse\be-\b-c\bcu\but\bto\bof\bff\bf _\bd_\ba_\bt_\be;\b;
- The _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bc_\bu_\bt_\bo_\bf_\bf statement sets the ending
- time for all leases assigned dynamically to BOOTP clients.
- Because BOOTP clients do not have any way of renewing
- leases, and don't know that their leases could expire, by
- default dhcpd assignes infinite leases to all BOOTP
- clients. However, it may make sense in some situations to
- set a cutoff date for all BOOTP leases - for example, the
- end of a school term, or the time at night when a facility
- is closed and all machines are required to be powered off.
+SunOS 5.6 Last change: 11
- _\bD_\ba_\bt_\be should be the date on which all assigned BOOTP leases
- will end. The date is specified in the form:
- W YYYY/MM/DD HH:MM:SS
- W is the day of the week expressed as a number from zero
- (Sunday) to six (Saturday). YYYY is the year, including
- the century. MM is the month expressed as a number from 1
- to 12. DD is the day of the month, counting from 1. HH
- is the hour, from zero to 23. MM is the minute and SS is
- the second. The time is always in Greenwich Mean Time
- (GMT), not local time.
- T\bTh\bhe\be _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bl_\be_\bn_\bg_\bt_\bh s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp-\b-l\ble\bea\bas\bse\be-\b-l\ble\ben\bng\bgt\bth\bh _\bl_\be_\bn_\bg_\bt_\bh;\b;
- The _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bl_\be_\bn_\bg_\bt_\bh statement is used to set
- the length of leases dynamically assigned to BOOTP
- clients. At some sites, it may be possible to assume
- that a lease is no longer in use if its holder has not
- used BOOTP or DHCP to get its address within a certain
- time period. The period is specified in _\bl_\be_\bn_\bg_\bt_\bh as a num
- ber of seconds. If a client reboots using BOOTP during
- the timeout period, the lease duration is reset to _\bl_\be_\bn_\bg_\bt_\bh,
- so a BOOTP client that boots frequently enough will never
- lose its lease. Needless to say, this parameter should be
- adjusted with extreme caution.
+Headers, Environments, and Macros dhcpd.conf(5)
- T\bTh\bhe\be _\bg_\be_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- g\bge\bet\bt-\b-l\ble\bea\bas\bse\be-\b-h\bho\bos\bst\btn\bna\bam\bme\bes\bs _\bf_\bl_\ba_\bg;\b;
- The _\bg_\be_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs statement is used to tell dhcpd
- whether or not to look up the domain name corresponding to
- the IP address of each address in the lease pool and use
+ that the client can report is 255 seconds. Generally, set-
+ ting this to one will result in the DHCP server not respond-
+ ing to the client's first request, but always responding to
+ its second request.
+ This can be used to set up a secondary DHCP server which
+ never offers an address to a client until the primary server
+ has been given a chance to do so. If the primary server is
+ down, the client will bind to the secondary server, but oth-
+ erwise clients should always bind to the primary. Note
+ that this does not, by itself, permit a primary server and a
+ secondary server to share a pool of dynamically-allocatable
+ addresses.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- 13
+ h\bh\bh\bha\ba\ba\bar\br\br\brd\bd\bd\bdw\bw\bw\bwa\ba\ba\bar\br\br\bre\be\be\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\bt_\by_\bp_\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;\b;\b;
+ In order for a BOOTP client to be recognized, its network
+ hardware address must be declared using a _\bh_\ba_\br_\bd_\bw_\ba_\br_\be clause in
+ the _\bh_\bo_\bs_\bt statement. _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\bt_\by_\bp_\be must be the name of a
+ physical hardware interface type. Currently, only the e\be\be\bet\bt\bt\bth\bh\bh\bh-\b-\b-\b-
+ e\be\be\ber\br\br\brn\bn\bn\bne\be\be\bet\bt\bt\bt and t\bt\bt\bto\bo\bo\bok\bk\bk\bke\be\be\ben\bn\bn\bn-\b-\b-\b-r\br\br\bri\bi\bi\bin\bn\bn\bng\bg\bg\bg types are recognized, although support
+ for a f\bf\bf\bfd\bd\bd\bdd\bd\bd\bdi\bi\bi\bi hardware type (and others) would also be desir-
+ able. The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\ba_\bd_\bd_\br_\be_\bs_\bs should be a set of hexadecimal
+ octets (numbers from 0 through ff) seperated by colons.
+ The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\bf_\bR _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt _\bm_\ba_\by _\ba_\bl_\bs_\bo _\bb_\be _\bu_\bs_\be_\bd _\bf_\bo_\br _\bD_\bH_\bC_\bP _\bc_\bl_\bi_\be_\bn_\bt_\bs.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ f\bf\bf\bfi\bi\bi\bil\bl\bl\ble\be\be\ben\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bf_\bi_\bl_\be_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
+ The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement can be used to specify the name of
+ the initial boot file which is to be loaded by a client.
+ The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be should be a filename recognizable to whatever
+ file transfer protocol the client can be expected to use to
+ load the file.
-dhcpd.conf(5) dhcpd.conf(5)
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bs_\be_\br_\bv_\be_\br-_\bn_\ba_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br-\b-\b-\b-n\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
- that address for the DHCP _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option. If _\bf_\bl_\ba_\bg is
- true, then this lookup is done for all addresses in the
- current scope. By default, or if _\bf_\bl_\ba_\bg is false, no
- lookups are done.
+ The _\bs_\be_\br_\bv_\be_\br-_\bn_\ba_\bm_\be statement can be used to inform the client
+ of the name of the server from which it is booting. _\bN_\ba_\bm_\be
+ should be the name that will be provided to the client.
- T\bTh\bhe\be _\bu_\bs_\be_\b-_\bh_\bo_\bs_\bt_\b-_\bd_\be_\bc_\bl_\b-_\bn_\ba_\bm_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bn_\be_\bx_\bt-_\bs_\be_\br_\bv_\be_\br s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- u\bus\bse\be-\b-h\bho\bos\bst\bt-\b-d\bde\bec\bcl\bl-\b-n\bna\bam\bme\bes\bs _\bf_\bl_\ba_\bg;\b;
+ n\bn\bn\bne\be\be\bex\bx\bx\bxt\bt\bt\bt-\b-\b-\b-s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br _\bs_\be_\br_\bv_\be_\br-_\bn_\ba_\bm_\be;\b;\b;\b;
- If the _\bu_\bs_\be_\b-_\bh_\bo_\bs_\bt_\b-_\bd_\be_\bc_\bl_\b-_\bn_\ba_\bm_\be_\bs parameter is true in a given
- scope, then for every host declaration within that scope,
- the name provided for the host declaration will be sup
- plied to the client as its hostname. So, for example,
+ The _\bn_\be_\bx_\bt-_\bs_\be_\br_\bv_\be_\br statement is used to specify the host
+ address of the server from which the initial boot file
- group {
- use-host-decl-names on;
- host joe {
- hardware ethernet 08:00:2b:4c:29:32;
- fixed-address joe.fugue.com;
- }
- }
- is equivalent to
+SunOS 5.6 Last change: 12
+
+
+
+
+
+
+Headers, Environments, and Macros dhcpd.conf(5)
+
+
+
+ (specified in the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement) is to be loaded.
+ _\bS_\be_\br_\bv_\be_\br-_\bn_\ba_\bm_\be should be a numeric IP address or a domain name.
+ If no _\bn_\be_\bx_\bt-_\bs_\be_\br_\bv_\be_\br parameter applies to a given client, the
+ DHCP server's IP address is used.
+
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+
+ f\bf\bf\bfi\bi\bi\bix\bx\bx\bxe\be\be\bed\bd\bd\bd-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\bre\be\be\bes\bs\bs\bss\bs\bs\bs _\ba_\bd_\bd_\br_\be_\bs_\bs [,\b,\b,\b, _\ba_\bd_\bd_\br_\be_\bs_\bs ... ];\b;\b;\b;
- host joe {
- hardware ethernet 08:00:2b:4c:29:32;
- fixed-address joe.fugue.com;
- option host-name "joe";
- }
+ The _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs statement is used to assign one or more
+ fixed IP addresses to a client. It should only appear in a
+ _\bh_\bo_\bs_\bt declaration. If more than one address is supplied,
+ then when the client boots, it will be assigned the address
+ which corresponds to the network on which it is booting. If
+ none of the addresses in the _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs statement are on
+ the network on which the client is booting, that client will
+ not match the _\bh_\bo_\bs_\bt declaration containing that _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs
+ statement. Each _\ba_\bd_\bd_\br_\be_\bs_\bs should be either an IP address or a
+ domain name which resolves to one or more IP addresses.
- An _\bo_\bp_\bt_\bi_\bo_\bn _\bh_\bo_\bs_\bt_\b-_\bn_\ba_\bm_\be statement within a host declaration
- will override the use of the name in the host declaration.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp-_\bl_\be_\ba_\bs_\be-_\bc_\bu_\bt_\bo_\bf_\bf s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- T\bTh\bhe\be _\ba_\bu_\bt_\bh_\bo_\br_\bi_\bt_\ba_\bt_\bi_\bv_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ d\bd\bd\bdy\by\by\byn\bn\bn\bna\ba\ba\bam\bm\bm\bmi\bi\bi\bic\bc\bc\bc-\b-\b-\b-b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-c\bc\bc\bcu\bu\bu\but\bt\bt\bto\bo\bo\bof\bf\bf\bff\bf\bf\bf _\bd_\ba_\bt_\be;\b;\b;\b;
- a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b;
+ The _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp-_\bl_\be_\ba_\bs_\be-_\bc_\bu_\bt_\bo_\bf_\bf statement sets the ending
+ time for all leases assigned dynamically to BOOTP clients.
+ Because BOOTP clients do not have any way of renewing
+ leases, and don't know that their leases could expire, by
+ default dhcpd assignes infinite leases to all BOOTP clients.
+ However, it may make sense in some situations to set a cut-
+ off date for all BOOTP leases - for example, the end of a
+ school term, or the time at night when a facility is closed
+ and all machines are required to be powered off.
- n\bno\bot\bt a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b;
+ _\bD_\ba_\bt_\be should be the date on which all assigned BOOTP leases
+ will end. The date is specified in the form:
- The DHCP server will normally assume that the configura
- tion information about a given network segment is known to
- be correct and is authoritative. So if a client requests
- an IP address on a given network segment that the server
- knows is not valid for that segment, the server will
- respond with a DHCPNAK message, causing the client to for
- get its IP address and try to get a new one.
+ W YYYY/MM/DD HH:MM:SS
- If a DHCP server is being configured by somebody who is
- not the network administrator and who therefore does not
- wish to assert this level of authority, then the statement
- "not authoritative" should be written in the appropriate
- scope in the configuration file.
+ W is the day of the week expressed as a number from zero
+ (Sunday) to six (Saturday). YYYY is the year, including the
+ century. MM is the month expressed as a number from 1 to
+ 12. DD is the day of the month, counting from 1. HH is the
+ hour, from zero to 23. MM is the minute and SS is the
+ second. The time is always in Greenwich Mean Time (GMT),
+ not local time.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp-_\bl_\be_\ba_\bs_\be-_\bl_\be_\bn_\bg_\bt_\bh s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ d\bd\bd\bdy\by\by\byn\bn\bn\bna\ba\ba\bam\bm\bm\bmi\bi\bi\bic\bc\bc\bc-\b-\b-\b-b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-l\bl\bl\ble\be\be\ben\bn\bn\bng\bg\bg\bgt\bt\bt\bth\bh\bh\bh _\bl_\be_\bn_\bg_\bt_\bh;\b;\b;\b;
- 14
+SunOS 5.6 Last change: 13
-dhcpd.conf(5) dhcpd.conf(5)
- Usually, writing n\bno\bot\bt a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b; at the top level of
- the file should be sufficient. However, if a DHCP server
- is to be set up so that it is aware of some networks for
- which it is authoritative and some networks for which it
- is not, it may be more appropriate to declare authority on
- a per-network-segment basis.
- Note that the most specific scope for which the concept of
- authority makes any sense is the physical network segment
- - either a shared-network statement or a subnet statement
- that is not contained within a shared-network statement.
- It is not meaningful to specify that the server is author
- itative for some subnets within a shared network, but not
- authoritative for others, nor is it meaningful to specify
- that the server is authoritative for some host declara
- tions and not others.
- T\bTh\bhe\be _\bu_\bs_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\ba_\bd_\bd_\br_\b-_\bf_\bo_\br_\b-_\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\br_\bo_\bu_\bt_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+Headers, Environments, and Macros dhcpd.conf(5)
+
+
+
+ The _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp-_\bl_\be_\ba_\bs_\be-_\bl_\be_\bn_\bg_\bt_\bh statement is used to set the
+ length of leases dynamically assigned to BOOTP clients. At
+ some sites, it may be possible to assume that a lease is no
+ longer in use if its holder has not used BOOTP or DHCP to
+ get its address within a certain time period. The period
+ is specified in _\bl_\be_\bn_\bg_\bt_\bh as a number of seconds. If a client
+ reboots using BOOTP during the timeout period, the lease
+ duration is reset to _\bl_\be_\bn_\bg_\bt_\bh, so a BOOTP client that boots
+ frequently enough will never lose its lease. Needless to
+ say, this parameter should be adjusted with extreme caution.
+
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bg_\be_\bt-_\bl_\be_\ba_\bs_\be-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+
+ g\bg\bg\bge\be\be\bet\bt\bt\bt-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\bes\bs\bs\bs _\bf_\bl_\ba_\bg;\b;\b;\b;
+
+ The _\bg_\be_\bt-_\bl_\be_\ba_\bs_\be-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs statement is used to tell dhcpd
+ whether or not to look up the domain name corresponding to
+ the IP address of each address in the lease pool and use
+ that address for the DHCP _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option. If _\bf_\bl_\ba_\bg is true,
+ then this lookup is done for all addresses in the current
+ scope. By default, or if _\bf_\bl_\ba_\bg is false, no lookups are
+ done.
+
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bu_\bs_\be-_\bh_\bo_\bs_\bt-_\bd_\be_\bc_\bl-_\bn_\ba_\bm_\be_\bs s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+
+ u\bu\bu\bus\bs\bs\bse\be\be\be-\b-\b-\b-h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt-\b-\b-\b-d\bd\bd\bde\be\be\bec\bc\bc\bcl\bl\bl\bl-\b-\b-\b-n\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\bes\bs\bs\bs _\bf_\bl_\ba_\bg;\b;\b;\b;
+
+ If the _\bu_\bs_\be-_\bh_\bo_\bs_\bt-_\bd_\be_\bc_\bl-_\bn_\ba_\bm_\be_\bs parameter is true in a given
+ scope, then for every host declaration within that scope,
+ the name provided for the host declaration will be supplied
+ to the client as its hostname. So, for example,
+
+ group {
+ use-host-decl-names on;
+
+ host joe {
+ hardware ethernet 08:00:2b:4c:29:32;
+ fixed-address joe.fugue.com;
+ }
+ }
+
+ is equivalent to
+
+ host joe {
+ hardware ethernet 08:00:2b:4c:29:32;
+ fixed-address joe.fugue.com;
+ option host-name "joe";
+ }
- u\bus\bse\be-\b-l\ble\bea\bas\bse\be-\b-a\bad\bdd\bdr\br-\b-f\bfo\bor\br-\b-d\bde\bef\bfa\bau\bul\blt\bt-\b-r\bro\bou\but\bte\be _\bf_\bl_\ba_\bg;\b;
+ An _\bo_\bp_\bt_\bi_\bo_\bn _\bh_\bo_\bs_\bt-_\bn_\ba_\bm_\be statement within a host declaration will
+ override the use of the name in the host declaration.
- If the _\bu_\bs_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\ba_\bd_\bd_\br_\b-_\bf_\bo_\br_\b-_\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\br_\bo_\bu_\bt_\be parameter is true
- in a given scope, then instead of sending the value speci
- fied in the routers option (or sending no value at all),
- the IP address of the lease being assigned is sent to the
- client. This supposedly causes Win95 machines to ARP for
- all IP addresses, which can be helpful if your router is
- configured for proxy ARP.
- T\bTh\bhe\be _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- s\bse\ber\brv\bve\ber\br-\b-i\bid\bde\ben\bnt\bti\bif\bfi\bie\ber\br _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be;\b;
- The server-identifier statement can be used to define the
- value that is sent in the DHCP Server Identifier option
- for a given scope. The value specified m\bmu\bus\bst\bt be an IP
- address for the DHCP server, and must be reachable by all
- clients served by a particular scope.
+SunOS 5.6 Last change: 14
- The use of the server-identifier statement is not recom
- mended - the only reason to use it is to force a value
- other than the default value to be sent on occasions where
- the default value would be incorrect. The default value
- is the first IP address associated with the physical net
- work interface on which the request arrived.
- The usual case where the _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br statement needs
- to be sent is when a physical interface has more than one
- IP address, and the one being sent by default isn't appro
- priate for some or all clients served by that interface.
- Another common case is when an alias is defined for the
- purpose of having a consistent IP address for the DHCP
- server, and it is desired that the clients use this IP
- address when contacting the server.
- 15
+Headers, Environments, and Macros dhcpd.conf(5)
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\ba_\bu_\bt_\bh_\bo_\br_\bi_\bt_\ba_\bt_\bi_\bv_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
-dhcpd.conf(5) dhcpd.conf(5)
+ a\ba\ba\bau\bu\bu\but\bt\bt\bth\bh\bh\bho\bo\bo\bor\br\br\bri\bi\bi\bit\bt\bt\bta\ba\ba\bat\bt\bt\bti\bi\bi\biv\bv\bv\bve\be\be\be;\b;\b;\b;
+ n\bn\bn\bno\bo\bo\bot\bt\bt\bt a\ba\ba\bau\bu\bu\but\bt\bt\bth\bh\bh\bho\bo\bo\bor\br\br\bri\bi\bi\bit\bt\bt\bta\ba\ba\bat\bt\bt\bti\bi\bi\biv\bv\bv\bve\be\be\be;\b;\b;\b;
- Supplying a value for the dhcp-server-identifier option is
- equivalent to using the server-identifier statement.
+ The DHCP server will normally assume that the configuration
+ information about a given network segment is known to be
+ correct and is authoritative. So if a client requests an
+ IP address on a given network segment that the server knows
+ is not valid for that segment, the server will respond with
+ a DHCPNAK message, causing the client to forget its IP
+ address and try to get a new one.
-R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: O\bOP\bPT\bTI\bIO\bON\bN S\bST\bTA\bAT\bTE\bEM\bME\bEN\bNT\bTS\bS
- DHCP option statements are documented in the d\bdh\bhc\bcp\bp-\b-
- o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b) manual page.
+ If a DHCP server is being configured by somebody who is not
+ the network administrator and who therefore does not wish to
+ assert this level of authority, then the statement "not
+ authoritative" should be written in the appropriate scope in
+ the configuration file.
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
+ Usually, writing n\bn\bn\bno\bo\bo\bot\bt\bt\bt a\ba\ba\bau\bu\bu\but\bt\bt\bth\bh\bh\bho\bo\bo\bor\br\br\bri\bi\bi\bit\bt\bt\bta\ba\ba\bat\bt\bt\bti\bi\bi\biv\bv\bv\bve\be\be\be;\b;\b;\b; at the top level of the
+ file should be sufficient. However, if a DHCP server is to
+ be set up so that it is aware of some networks for which it
+ is authoritative and some networks for which it is not, it
+ may be more appropriate to declare authority on a per-
+ network-segment basis.
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) 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
- h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
+ Note that the most specific scope for which the concept of
+ authority makes any sense is the physical network segment -
+ either a shared-network statement or a subnet statement that
+ is not contained within a shared-network statement. It is
+ not meaningful to specify that the server is authoritative
+ for some subnets within a shared network, but not authorita-
+ tive for others, nor is it meaningful to specify that the
+ server is authoritative for some host declarations and not
+ others.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bu_\bs_\be-_\bl_\be_\ba_\bs_\be-_\ba_\bd_\bd_\br-_\bf_\bo_\br-_\bd_\be_\bf_\ba_\bu_\bl_\bt-_\br_\bo_\bu_\bt_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ u\bu\bu\bus\bs\bs\bse\be\be\be-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\br-\b-\b-\b-f\bf\bf\bfo\bo\bo\bor\br\br\br-\b-\b-\b-d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt-\b-\b-\b-r\br\br\bro\bo\bo\bou\bu\bu\but\bt\bt\bte\be\be\be _\bf_\bl_\ba_\bg;\b;\b;\b;
+ If the _\bu_\bs_\be-_\bl_\be_\ba_\bs_\be-_\ba_\bd_\bd_\br-_\bf_\bo_\br-_\bd_\be_\bf_\ba_\bu_\bl_\bt-_\br_\bo_\bu_\bt_\be parameter is true in
+ a given scope, then instead of sending the value specified
+ in the routers option (or sending no value at all), the IP
+ address of the lease being assigned is sent to the client.
+ This supposedly causes Win95 machines to ARP for all IP
+ addresses, which can be helpful if your router is configured
+ for proxy ARP.
+ T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bs_\be_\br_\bv_\be_\br-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+SunOS 5.6 Last change: 15
+Headers, Environments, and Macros dhcpd.conf(5)
+ s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br-\b-\b-\b-i\bi\bi\bid\bd\bd\bde\be\be\ben\bn\bn\bnt\bt\bt\bti\bi\bi\bif\bf\bf\bfi\bi\bi\bie\be\be\ber\br\br\br _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be;\b;\b;\b;
+ The server-identifier statement can be used to define the
+ value that is sent in the DHCP Server Identifier option for
+ a given scope. The value specified m\bm\bm\bmu\bu\bu\bus\bs\bs\bst\bt\bt\bt be an IP address
+ for the DHCP server, and must be reachable by all clients
+ served by a particular scope.
+ The use of the server-identifier statement is not recom-
+ mended - the only reason to use it is to force a value other
+ than the default value to be sent on occasions where the
+ default value would be incorrect. The default value is the
+ first IP address associated with the physical network inter-
+ face on which the request arrived.
+ The usual case where the _\bs_\be_\br_\bv_\be_\br-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br statement needs
+ to be sent is when a physical interface has more than one IP
+ address, and the one being sent by default isn't appropriate
+ for some or all clients served by that interface. Another
+ common case is when an alias is defined for the purpose of
+ having a consistent IP address for the DHCP server, and it
+ is desired that the clients use this IP address when con-
+ tacting the server.
+ Supplying a value for the dhcp-server-identifier option is
+ equivalent to using the server-identifier statement.
+R\bR\bR\bRE\bE\bE\bEF\bF\bF\bFE\bE\bE\bER\bR\bR\bRE\bE\bE\bEN\bN\bN\bNC\bC\bC\bCE\bE\bE\bE:\b:\b:\b: O\bO\bO\bOP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN S\bS\bS\bST\bT\bT\bTA\bA\bA\bAT\bT\bT\bTE\bE\bE\bEM\bM\bM\bME\bE\bE\bEN\bN\bN\bNT\bT\bT\bTS\bS\bS\bS
+ DHCP option statements are documented in the d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs(\b(\b(\b(5\b5\b5\b5)\b)\b)\b)
+ manual page.
+S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
+ dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
+A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) 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
+ h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
+SunOS 5.6 Last change: 16
- 16
-dhcpd.leases(5) dhcpd.leases(5)
+Headers, Environments, and Macros dhcpd.leases(5)
-N\bNA\bAM\bME\bE
- dhcpd.leases - DHCP client lease database
-D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
- The Internet Software Consortium DHCP Server keeps a per
- 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.
+N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
+ dhcpd.leases - DHCP client lease database
- 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.
+D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
+ 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.
- In order to prevent the lease database from growing with
- 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
- ten lease database is moved into place.
+ 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 /etc/dhcpd.leases.
- 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. D\bDO\bO N\bNO\bOT\bT 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.
+ 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.
-F\bFO\bOR\bRM\bMA\bAT\bT
- Lease descriptions are stored in a format that is parsed
- by the same recursive descent parser used to read the
- d\bdh\bhc\bcp\bpd\bd.\b.c\bco\bon\bnf\bf(\b(5\b5)\b) and d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf(\b(5\b5)\b) files. Currently, the
- only declaration that is used in the dhcpd.leases file is
- the l\ble\bea\bas\bse\be declaration.
+ 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 /etc/dhcpd.leases. In
+ this case, dhcpd will refuse to start, and will require
+ manual intervention. D\bD\bD\bDO\bO\bO\bO N\bN\bN\bNO\bO\bO\bOT\bT\bT\bT 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.
- l\ble\bea\bas\bse\be _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs {\b{ _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt_\bs_\b._\b._\b. }\b}
+F\bF\bF\bFO\bO\bO\bOR\bR\bR\bRM\bM\bM\bMA\bA\bA\bAT\bT\bT\bT
+ Lease descriptions are stored in a format that is parsed by
+ the same recursive descent parser used to read the
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf(\b(\b(\b(5\b5\b5\b5)\b)\b)\b) and d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf(\b(\b(\b(5\b5\b5\b5)\b)\b)\b) files. Currently, the
+ only declaration that is used in the dhcpd.leases file is
+ the l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be declaration.
- Each lease declaration include the single IP address that
- has been leased to the client. The statements within the
- braces define the duration of the lease and to whom it is
- assigned.
+ l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be _\bi_\bp-_\ba_\bd_\bd_\br_\be_\bs_\bs {\b{\b{\b{ _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt_\bs... }\b}\b}\b}
- The start and end time of a lease are recorded using the
- ``starts'' and ``ends'' statements:
+ Each lease declaration include the single IP address that
+ has been leased to the client. The statements within the
+ braces define the duration of the lease and to whom it is
+ assigned.
+ The start and end time of a lease are recorded using the
+ ``starts'' and ``ends'' statements:
- 1
+SunOS 5.6 Last change: 1
-dhcpd.leases(5) dhcpd.leases(5)
+Headers, Environments, and Macros dhcpd.leases(5)
- s\bst\bta\bar\brt\bts\bs _\bd_\ba_\bt_\be;\b;
- e\ben\bnd\bds\bs _\bd_\ba_\bt_\be;\b;
- Dates are specified as follows:
- _\bw_\be_\be_\bk_\bd_\ba_\by _\by_\be_\ba_\br/\b/_\bm_\bo_\bn_\bt_\bh/\b/_\bd_\ba_\by _\bh_\bo_\bu_\br:\b:_\bm_\bi_\bn_\bu_\bt_\be:\b:_\bs_\be_\bc_\bo_\bn_\bd
+ s\bs\bs\bst\bt\bt\bta\ba\ba\bar\br\br\brt\bt\bt\bts\bs\bs\bs _\bd_\ba_\bt_\be;\b;\b;\b;
+ e\be\be\ben\bn\bn\bnd\bd\bd\bds\bs\bs\bs _\bd_\ba_\bt_\be;\b;\b;\b;
- 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
- ond also a number between 0 and 59.
+ Dates are specified as follows:
- 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
- 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 d\bda\bat\bte\be -\b-u\bu.
+ _\bw_\be_\be_\bk_\bd_\ba_\by _\by_\be_\ba_\br/\b/\b/\b/_\bm_\bo_\bn_\bt_\bh/\b/\b/\b/_\bd_\ba_\by _\bh_\bo_\bu_\br:\b:\b:\b:_\bm_\bi_\bn_\bu_\bt_\be:\b:\b:\b:_\bs_\be_\bc_\bo_\bn_\bd
- The MAC address of the network interface that was used to
- acquire the lease is recorded with the h\bha\bar\brd\bdw\bwa\bar\bre\be statement:
+ 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 second also a
+ number between 0 and 59.
- h\bha\bar\brd\bdw\bwa\bar\bre\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be _\bm_\ba_\bc_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
+ 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 d\bd\bd\bda\ba\ba\bat\bt\bt\bte\be\be\be
+ -\b-\b-\b-u\bu\bu\bu.
- The MAC address is specified as a series of hexadecimal
- octets, seperated by colons.
+ The MAC address of the network interface that was used to
+ acquire the lease is recorded with the h\bh\bh\bha\ba\ba\bar\br\br\brd\bd\bd\bdw\bw\bw\bwa\ba\ba\bar\br\br\bre\be\be\be statement:
- If the client used a client identifier to acquire its
- address, the client identifier is recorded using the u\bui\bid\bd
- statement:
+ h\bh\bh\bha\ba\ba\bar\br\br\brd\bd\bd\bdw\bw\bw\bwa\ba\ba\bar\br\br\bre\be\be\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\bt_\by_\bp_\be _\bm_\ba_\bc-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;\b;\b;
- u\bui\bid\bd _\bc_\bl_\bi_\be_\bn_\bt_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br;\b;
+ The MAC address is specified as a series of hexadecimal
+ octets, seperated by colons.
- The client identifier is recorded as a series of hexadeci
- mal octets, regardless of whether the client specifies an
- ASCII string or uses the newer hardware type/MAC address
- format.
+ If the client used a client identifier to acquire its
+ address, the client identifier is recorded using the u\bu\bu\bui\bi\bi\bid\bd\bd\bd
+ statement:
- If the client sends a hostname using the _\bC_\bl_\bi_\be_\bn_\bt _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be
- option, as specified in some versions of the DHCP-DNS
- Interaction draft, that hostname is recorded using the
- c\bcl\bli\bie\ben\bnt\bt-\b-h\bho\bos\bst\btn\bna\bam\bme\be statement.
+ u\bu\bu\bui\bi\bi\bid\bd\bd\bd _\bc_\bl_\bi_\be_\bn_\bt-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br;\b;\b;\b;
- c\bcl\bli\bie\ben\bnt\bt-\b-h\bho\bos\bst\btn\bna\bam\bme\be "\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b";\b;
+ The client identifier is recorded as a series of hexadecimal
+ octets, regardless of whether the client specifies an ASCII
+ string or uses the newer hardware type/MAC address format.
- If the client sends its hostname using the _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be
- option, as Windows 95 does, it is recorded using the
+ If the client sends a hostname using the _\bC_\bl_\bi_\be_\bn_\bt _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be
+ option, as specified in some versions of the DHCP-DNS
+ Interaction draft, that hostname is recorded using the
+ c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt-\b-\b-\b-h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be statement.
+ c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt-\b-\b-\b-h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
- 2
+SunOS 5.6 Last change: 2
-dhcpd.leases(5) dhcpd.leases(5)
- h\bho\bos\bst\btn\bna\bam\bme\be statement.
- h\bho\bos\bst\btn\bna\bam\bme\be "\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b";\b;
- The DHCP server may determine that a lease has been mis
- 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 a\bab\bba\ban\bnd\bdo\bon\bne\bed\bd statement will be used to indi
- cate that the lease should not be reassigned.
+Headers, Environments, and Macros dhcpd.leases(5)
- a\bab\bba\ban\bnd\bdo\bon\bne\bed\bd;\b;
- Abandoned leases are reclaimed automatically. When a
- client asks for a new address, and the server finds that
- there are no new addresses, it checks to see if there are
- any abandoned leases, and allocates the least recently
- abandoned lease. The standard mechanisms for checking
- for lease address conflicts are still followed, so if the
- abandoned lease's IP address is still in use, it will be
- reabandoned.
- If a client r\bre\beq\bqu\bue\bes\bst\bts\bs 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
- ately assigned to the client.
+ If the client sends its hostname using the _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be option,
+ as Windows 95 does, it is recorded using the h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be state-
+ ment.
-F\bFI\bIL\bLE\bES\bS
- /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs
+ h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
-S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132,
- RFC2131.
+ 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 a\ba\ba\bab\bb\bb\bba\ba\ba\ban\bn\bn\bn-\b-\b-\b-
+ d\bd\bd\bdo\bo\bo\bon\bn\bn\bne\be\be\bed\bd\bd\bd statement will be used to indicate that the lease
+ should not be reassigned.
-A\bAU\bUT\bTH\bHO\bOR\bR
- d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) 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
- tion about the Internet Software Consortium can be found
- at h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
+ a\ba\ba\bab\bb\bb\bba\ba\ba\ban\bn\bn\bnd\bd\bd\bdo\bo\bo\bon\bn\bn\bne\be\be\bed\bd\bd\bd;\b;\b;\b;
+ Abandoned leases are reclaimed automatically. When a
+ client asks for a new address, and the server finds that
+ there are no new addresses, it checks to see if there are
+ any abandoned leases, and allocates the least recently aban-
+ doned lease. The standard mechanisms for checking for
+ lease address conflicts are still followed, so if the aban-
+ doned lease's IP address is still in use, it will be reaban-
+ doned.
+ If a client r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bue\be\be\bes\bs\bs\bst\bt\bt\bts\bs\bs\bs an abandoned address, the server
+ assumes that the reason the address was abandoned was that
+ the lease file was corrupted, and that the client is the
+ machine that responded when the lease was probed, causing it
+ to be abandoned. In that case, the address is immediately
+ assigned to the client.
+F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
+ /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs
+S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
+ dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, RFC2131.
+A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
+ d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) was written by Ted Lemon <mellon@vix.com> under a
+ contract with Vixie Labs. Funding for this project was
+ provided by the Internet Software Corporation. Information
+ about the Internet Software Consortium can be found at
+ h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
- 3
+
+
+SunOS 5.6 Last change: 3
+
projects / thirdparty / dhcp.git / commitdiff
