diff --git a/client/clparse.c b/client/clparse.c index 07f6191a..0e82370a 100644 --- a/client/clparse.c +++ b/client/clparse.c @@ -22,7 +22,7 @@ #ifndef lint static char copyright[] = -"$Id: clparse.c,v 1.27 1999/03/16 05:50:29 mellon Exp $ Copyright (c) 1997 The Internet Software Consortium. All rights reserved.\n"; +"$Id: clparse.c,v 1.28 1999/03/16 06:37:47 mellon Exp $ Copyright (c) 1997 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -73,7 +73,7 @@ int read_client_conf () top_level_config.retry_interval = 300; top_level_config.backoff_cutoff = 120; top_level_config.initial_interval = 10; - top_level_config.bootp_policy = ACCEPT; + top_level_config.bootp_policy = P_ACCEPT; top_level_config.script_name = "/etc/dhclient-script"; top_level_config.requested_options = default_requested_options; top_level_config.requested_lease = 7200; diff --git a/client/dhclient-script.cat8 b/client/dhclient-script.cat8 index 91043250..c7a4c93d 100644 --- a/client/dhclient-script.cat8 +++ b/client/dhclient-script.cat8 @@ -1,241 +1,222 @@ -dhclient(8) dhclient(8) - - -NNAAMMEE - dhclient-script - DHCP client network configuration script - -DDEESSCCRRIIPPTTIIOONN - The DHCP client network configuration script is invoked - from time to time by ddhhcclliieenntt((88)). This script is used by - the dhcp client to set each interface's initial configura­ - 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 //eettcc//ddhhcclliieenntt..ccoonnff script. - If you find that you can't make such a customization with­ - out customizing dhclient.conf, please submit a bug report. - -OOPPEERRAATTIIOONN - When dhclient needs to invoke the client configuration - script, it writes a shell script into /tmp which defines a - variety of variables. In all cases, $reason is set to the - name of the reason why the script has been invoked. The - following reasons are currently defined: MEDIUM, PREINIT, - BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL and TIMEOUT. +Maintenance Procedures dhclient(8) + + + +NNNNAAAAMMMMEEEE + dhclient-script - DHCP client network configuration script + +DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN + The DHCP client network configuration script is invoked from + time to time by ddddhhhhcccclllliiiieeeennnntttt((((8888)))). This script is used by the + dhcp client to set each interface's initial configuration + prior to requesting an address, to test the address once it + has been offered, and to set the interface's final confi- + guration once a lease has been acquired. If no lease is + acquired, the script is used to test predefined leases, if + any, and also called once if no valid lease can be identi- + fied. + + This script is not meant to be customized by the end user. + However, the script may not work on particular versions of + particular operating systems (indeed, no standard script + exists for some operating systems), so a pioneering user may + well need to create a new script or modify an existing one. + In general, customizations specific to a particular computer + should be done in the ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff script. If you + find that you can't make such a customization without cus- + tomizing dhclient.conf, please submit a bug report. + +OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN + When dhclient needs to invoke the client configuration + script, it writes a shell script into /tmp which defines a + variety of variables. In all cases, $reason is set to the + 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. +MMMMEEEEDDDDIIIIUUUUMMMM + The DHCP client is requesting that an interface's media type + be set. The interface name is passed in $interface, and the + media type is passed in $medium. -MMEEDDIIUUMM - The DHCP client is requesting that an interface's media - type be set. The interface name is passed in $interface, - and the media type is passed in $medium. +PPPPRRRREEEEIIIINNNNIIIITTTT + The DHCP client is requesting that an interface be config- + ured as required in order to send packets prior to receiving + an actual address. For clients which use the BSD socket + library, this means configuring the interface with an IP + address of 0.0.0.0 and a broadcast address of + 255.255.255.255. For other clients, it may be possible to + simply configure the interface up without actually giving it + an IP address at all. The interface name is passed in + $interface, and the media type in $medium. -PPRREEIINNIITT - 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) - - -BBOOUUNNDD - The DHCP client has done an initial binding to a new - address. The new ip address is passed in - $new_ip_address, and the interface name is passed in - $interface. The media type is passed in $medium. Any - options acquired from the server are passed using the - option name described in ddhhccpp--ooppttiioonnss, except that dashes - ('-') are replaced by underscores ('_') in order to make - valid shell variables, and the variable names start with - new_. So for example, the new subnet mask would be - passed in $new_subnet_mask. - - Before actually configuring the address, dhclient-script - should somehow ARP for it and exit with a nonzero status - if it receives a reply. In this case, the client will - send a DHCPDECLINE message to the server and acquire a - different address. This may also be done in the RENEW, - REBIND, or REBOOT states, but is not required, and indeed - may not be desirable. - - When a binding has been completed, a lot of network param­ - eters are likely to need to be set up. A new - /etc/resolv.conf needs to be created, using the values of - $new_domain_name and $new_domain_name_servers (which may - list more than one server, seperated by spaces). A - default route should be set using $new_routers, and static - routes may need to be set up using $new_static_routes. - - If an IP alias has been declared, it must be set up here. - The alias IP address will be written as $alias_ip_address, - and other DHCP options that are set for the alias (e.g., - subnet mask) will be passed in variables named as - described previously except starting with $alias_ instead - of $new_. Care should be taken that the alias IP address - not be used if it is identical to the bound IP address - ($new_ip_address), since the other alias parameters may be - incorrect in this case. - -RREENNEEWW - When a binding has been renewed, the script is called as - in BOUND, except that in addition to all the variables - starting with $new_, there is another set of variables - starting with $old_. Persistent settings that may have - changed need to be deleted - for example, if a local route - to the bound address is being configured, the old local - route should be deleted. If the default route has - changed, the old default route should be deleted. If the - static routes have changed, the old ones should be - deleted. Otherwise, processing can be done as with BOUND. + 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. -RREEBBIINNDD - The DHCP client has rebound to a new DHCP server. This - can be handled as with RENEW, except that if the IP - address has changed, the ARP table should be cleared. +SunOS 5.6 Last change: 1 - 2 -dhclient(8) dhclient(8) +Maintenance Procedures dhclient(8) -RREEBBOOOOTT - The DHCP client has successfully reacquired its old - address after a reboot. This can be processed as with - BOUND. -EEXXPPIIRREE - 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. +BBBBOOOOUUUUNNNNDDDD + The DHCP client has done an initial binding to a new + address. The new ip address is passed in $new_ip_address, + and the interface name is passed in $interface. The media + type is passed in $medium. Any options acquired from the + server are passed using the option name described in ddddhhhhccccpppp---- + ooooppppttttiiiioooonnnnssss, except that dashes ('-') are replaced by under- + scores ('_') in order to make valid shell variables, and the + variable names start with new_. So for example, the new + subnet mask would be passed in $new_subnet_mask. -FFAAIILL - 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. -TTIIMMEEOOUUTT - The DHCP client has been unable to contact any DHCP - servers. However, an old lease has been identified, and - its parameters have been passed in as with BOUND. The - client configuration script should test these parameters - and, if it has reason to believe they are valid, should - exit with a value of zero. If not, it should exit with a - nonzero value. + 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. +RRRREEEENNNNEEEEWWWW + When a binding has been renewed, the script is called as in + BOUND, except that in addition to all the variables starting + with $new_, there is another set of variables starting with + $old_. Persistent settings that may have changed need to be + deleted - for example, if a local route to the bound address + is being configured, the old local route should be deleted. + If the default route has changed, the old default route + should be deleted. If the static routes have changed, the + old ones should be deleted. Otherwise, processing can be + done as with BOUND. -FFIILLEESS - 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. +RRRREEEEBBBBIIIINNNNDDDD + The DHCP client has rebound to a new DHCP server. This can + be handled as with RENEW, except that if the IP address has -BBUUGGSS - 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. -SSEEEE AALLSSOO - dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and - dhclient.leases(5). + changed, the ARP table should be cleared. -AAUUTTHHOORR - ddhhcclliieenntt--ssccrriipptt((88)) has been written for the Internet Soft­ - ware Consortium by Ted Lemon in cooper­ - ation with Vixie Enterprises. To learn more about the - Internet Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. - To learn more about Vixie Enterprises, see - hhttttpp::////wwwwww..vviixx..ccoomm.. +RRRREEEEBBBBOOOOOOOOTTTT + The DHCP client has successfully reacquired its old address + after a reboot. This can be processed as with BOUND. +EEEEXXXXPPPPIIIIRRRREEEE + The DHCP client has failed to renew its lease or acquire a + new one, and the lease has expired. The IP address must be + relinquished, and all related parameters should be deleted, + as in RENEW and REBIND. +FFFFAAAAIIIILLLL + The DHCP client has been unable to contact any DHCP servers, + and any leases that have been tested have not proved to be + valid. The parameters from the last lease tested should be + deconfigured. This can be handled in the same way as + EXPIRE. +TTTTIIIIMMMMEEEEOOOOUUUUTTTT + The DHCP client has been unable to contact any DHCP servers. + However, an old lease has been identified, and its parame- + ters have been passed in as with BOUND. The client confi- + guration script should test these parameters and, if it has + reason to believe they are valid, should exit with a value + of zero. If not, it should exit with a nonzero value. + The usual way to test a lease is to set up the network as + with REBIND (since this may be called to test more than one + lease) and then ping the first router defined in $routers. + If a response is received, the lease must be valid for the + network to which the interface is currently connected. It + would be more complete to try to ping all of the routers + listed in $new_routers, as well as those listed in + $new_static_routes, but current scripts do not do this. +FFFFIIIILLLLEEEESSSS + Each operating system should generally have its own script + file, although the script files for similar operating sys- + tems may be similar or even identical. The script files + included in the Internet Software Consortium DHCP distribu- + tion appear in the distribution tree under client/scripts, + and bear the names of the operating systems on which they + are intended to work. +BBBBUUUUGGGGSSSS + If more than one interface is being used, there's no obvious + way to avoid clashes between server-supplied configuration + parameters - for example, the stock dhclient-script rewrites + /etc/resolv.conf. If more than one interface is being con- + figured, /etc/resolv.conf will be repeatedly initialized to + the values provided by one server, and then the other. +SunOS 5.6 Last change: 3 +Maintenance Procedures dhclient(8) + Assuming the information provided by both servers is valid, + this shouldn't cause any real problems, but it could be + confusing. +SSSSEEEEEEEE AAAALLLLSSSSOOOO + dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and + dhclient.leases(5). +AAAAUUUUTTTTHHHHOOOORRRR + ddddhhhhcccclllliiiieeeennnntttt----ssssccccrrrriiiipppptttt((((8888)))) has been written for the Internet + Software Consortium by Ted Lemon in + cooperation with Vixie Enterprises. To learn more about the + Internet Software Consortium, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To + learn more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm.... @@ -259,6 +240,25 @@ AAUUTTHHOORR - 4 + + + + + + + + + + + + + + + + + + +SunOS 5.6 Last change: 4 + diff --git a/client/dhclient.cat8 b/client/dhclient.cat8 index a9287f08..5dfee449 100644 --- a/client/dhclient.cat8 +++ b/client/dhclient.cat8 @@ -1,159 +1,156 @@ -dhclient(8) dhclient(8) - +Maintenance Procedures dhclient(8) -NNAAMMEE - dhclient - Dynamic Host Configuration Protocol Client -SSYYNNOOPPSSIISS - ddhhcclliieenntt [ --pp _p_o_r_t ] [ --dd ] [ _i_f_0 [ _._._._i_f_N ] ] -DDEESSCCRRIIPPTTIIOONN - 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. +NNNNAAAAMMMMEEEE + dhclient - Dynamic Host Configuration Protocol Client -OOPPEERRAATTIIOONN - The DHCP protocol allows a host to contact a central - server which maintains a list of IP addresses which may be - assigned on one or more subnets. A DHCP client may - request an address from this pool, and then use it on a - temporary basis for communication on network. The DHCP - protocol also provides a mechanism whereby a client can - learn important details about the network to which it is - attached, such as the location of a default router, the - location of a name server, and so on. +SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS + ddddhhhhcccclllliiiieeeennnntttt [ ----pppp _p_o_r_t ] [ ----dddd ] [ _i_f_0 [ ..._i_f_N ] ] - On startup, dhclient reads the _d_h_c_l_i_e_n_t_._c_o_n_f 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. +DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN + The Internet Software Consortium DHCP Client, dhclient, pro- + vides a means for configuring one or more network interfaces + using the Dynamic Host Configuration Protocol, BOOTP proto- + col, or if these protocols fail, by statically assigning an + address. - 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. +OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN + The DHCP protocol allows a host to contact a central server + which maintains a list of IP addresses which may be assigned + on one or more subnets. A DHCP client may request an + address from this pool, and then use it on a temporary basis + for communication on network. The DHCP protocol also pro- + vides a mechanism whereby a client can learn important + details about the network to which it is attached, such as + the location of a default router, the location of a name + server, and so on. - When a new lease is acquired, it is appended to the end of - the dhclient.leases file. In order to prevent the file - from becoming arbitrarily large, from time to time - dhclient creates a new dhclient.leases file from its in- - core lease database. The old version of the - dhclient.leases file is retained under the name - _d_h_c_p_d_._l_e_a_s_e_s_~ until the next time dhclient rewrites the - database. + On startup, dhclient reads the _d_h_c_l_i_e_n_t._c_o_n_f for configura- + tion instructions. It then gets a list of all the network + interfaces that are configured in the current system. For + each interface, it attempts to configure the interface using + the DHCP protocol. - 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 _d_h_c_p_d._l_e_a_s_e_s~ until the next time + dhclient rewrites the database. + Old leases are kept around in case the DHCP server is una- + vailable when dhclient is first invoked (generally during + the initial system boot process). In that event, old + leases from the dhclient.leases file which have not yet + expired are tested, and if they are determined to be valid, + they are used until either they expire or the DHCP server + becomes available. - 1 +SunOS 5.6 Last change: 1 -dhclient(8) dhclient(8) - A mobile host which may sometimes need to access a network - 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. -CCOOMMMMAANNDD LLIINNEE - The names of the network interfaces that dhclient should - attempt to configure may be specified on the command line. - If no interface names are specified on the command line - dhclient will identify all network interfaces, elimininat­ - 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 --pp 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 --dd flag should be specified. - This is useful when running dhclient under a debugger, or - when running it out of inittab on System V systems. + 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. +CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE + The names of the network interfaces that dhclient should + attempt to configure may be specified on the command line. + If no interface names are specified on the command line + dhclient will identify all network interfaces, elimininating + non-broadcast interfaces if possible, and attempt to config- + ure each interface. -CCOONNFFIIGGUURRAATTIIOONN - 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 ----pppp flag may used. It should be + followed by the udp port number that dhclient should use. + This is mostly useful for debugging purposes. -FFIILLEESS - //eettcc//ddhhcclliieenntt..ccoonnff,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess,, - //vvaarr//rruunn//ddhhcclliieenntt..ppiidd,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess~~.. + 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 ----dddd flag should be specified. This + is useful when running dhclient under a debugger, or when + running it out of inittab on System V systems. -SSEEEE AALLSSOO - dhcpd(8), dhcrelay(8), dhclient.conf(5), - dhclient.leases(5) +CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN + The syntax of the dhclient.conf(8) file is discussed + seperately. -AAUUTTHHOORR - ddhhcclliieenntt((88)) has been written for the Internet Software - Consortium by Ted Lemon in cooperation - with Vixie Enterprises. To learn more about the Internet - Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn - more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm.. +FFFFIIIILLLLEEEESSSS + ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff,,,, ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss,,,, ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ppppiiiidddd,,,, + ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss~~~~.... +SSSSEEEEEEEE AAAALLLLSSSSOOOO + dhcpd(8), dhcrelay(8), dhclient.conf(5), dhclient.leases(5) +AAAAUUUUTTTTHHHHOOOORRRR + ddddhhhhcccclllliiiieeeennnntttt((((8888)))) has been written for the Internet Software Con- + sortium by Ted Lemon in cooperation with + Vixie Enterprises. To learn more about the Internet + Software Consortium, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To learn + more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm.... - 2 +SunOS 5.6 Last change: 2 -dhclient(8) dhclient(8) - This client was substantially modified and enhanced by - Elliot Poger for use on Linux while he was working on the - MosquitoNet project at Stanford. - The current version owes much to Elliot's Linux enhance­ - 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. @@ -189,10 +186,13 @@ dhclient(8) dhclient(8) + + + +SunOS 5.6 Last change: 3 - 3 diff --git a/client/dhclient.conf.cat5 b/client/dhclient.conf.cat5 index bb34e524..8471f0ae 100644 --- a/client/dhclient.conf.cat5 +++ b/client/dhclient.conf.cat5 @@ -1,594 +1,594 @@ -dhclient.conf(5) dhclient.conf(5) +Headers, Environments, and Macros dhclient.conf(5) -NNAAMMEE - dhclient.conf - DHCP client configuration file -DDEESSCCRRIIPPTTIIOONN - The dhclient.conf file contains configuration information - for _d_h_c_l_i_e_n_t_, the Internet Software Consortium DHCP - Client. +NNNNAAAAMMMMEEEE + 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. +DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN + The dhclient.conf file contains configuration information + for _d_h_c_l_i_e_n_t, the Internet Software Consortium DHCP Client. - The dhclient.conf file 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. -PPRROOTTOOCCOOLL TTIIMMIINNGG - The timing behaviour of the client need not be configured - by the user. If no timing configuration is provided by - the user, a fairly reasonable timing behaviour will be - used by default - one which results in fairly timely - updates without placing an inordinate load on the server. + The 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: +PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTIIIIMMMMIIIINNNNGGGG + The timing behaviour of the client need not be configured by + the user. If no timing configuration is provided by the + user, a fairly reasonable timing behaviour will be used by + default - one which results in fairly timely updates without + placing an inordinate load on the server. - _T_h_e ttiimmeeoouutt _s_t_a_t_e_m_e_n_t + The following statements can be used to adjust the timing + behaviour of the DHCP client if required, however: - ttiimmeeoouutt _t_i_m_e ;; + _T_h_e ttttiiiimmmmeeeeoooouuuutttt _s_t_a_t_e_m_e_n_t - The _t_i_m_e_o_u_t statement determines the amount of time that - 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. + ttttiiiimmmmeeeeoooouuuutttt _t_i_m_e ;;;; + The _t_i_m_e_o_u_t statement determines the amount of time that + must pass between the time that the client begins to try to + determine its address and the time that it decides that it's + not going to be able to contact a server. By default, this + timeout is sixty seconds. After the timeout has passed, if + there are any static leases defined in the configuration + file, or any leases remaining in the lease database that + have not yet expired, the client will loop through these + leases attempting to validate them, and if it finds one that + appears to be valid, it will use that lease's address. If + there are no valid static leases or unexpired leases in the + lease database, the client will restart the protocol after + the defined retry interval. - 1 +SunOS 5.6 Last change: 1 -dhclient.conf(5) dhclient.conf(5) - _T_h_e rreettrryy _s_t_a_t_e_m_e_n_t +Headers, Environments, and Macros dhclient.conf(5) - rreettrryy _t_i_m_e;; - The _r_e_t_r_y statement determines the time that must pass - after the client has determined that there is no DHCP - server present before it tries again to contact a DHCP - server. By default, this is five minutes. - _T_h_e sseelleecctt--ttiimmeeoouutt _s_t_a_t_e_m_e_n_t + _T_h_e rrrreeeettttrrrryyyy _s_t_a_t_e_m_e_n_t - sseelleecctt--ttiimmeeoouutt _t_i_m_e;; + rrrreeeettttrrrryyyy _t_i_m_e;;;; - It is possible (some might say desirable) for there to be - 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 _r_e_t_r_y statement determines the time that must pass after + the client has determined that there is no DHCP server + present before it tries again to contact a DHCP server. By + default, this is five minutes. - The _s_e_l_e_c_t_-_t_i_m_e_o_u_t is the time after the client sends its - first lease discovery request at which it stops waiting - for offers from servers, assuming that it has received at - least one such offer. If no offers have been received by - the time the _s_e_l_e_c_t_-_t_i_m_e_o_u_t has expired, the client will - accept the first offer that arrives. + _T_h_e sssseeeelllleeeecccctttt----ttttiiiimmmmeeeeoooouuuutttt _s_t_a_t_e_m_e_n_t - By default, the select-timeout is zero seconds - that is, - the client will take the first offer it sees. + sssseeeelllleeeecccctttt----ttttiiiimmmmeeeeoooouuuutttt _t_i_m_e;;;; - _T_h_e rreebboooott _s_t_a_t_e_m_e_n_t + It is possible (some might say desirable) for there to be + more than one DHCP server serving any given network. In + this case, it is possible that a client may be sent more + than one offer in response to its initial lease discovery + message. It may be that one of these offers is preferable + to the other (e.g., one offer may have the address the + client previously used, and the other may not). - rreebboooott _t_i_m_e;; + The _s_e_l_e_c_t-_t_i_m_e_o_u_t is the time after the client sends its + first lease discovery request at which it stops waiting for + offers from servers, assuming that it has received at least + one such offer. If no offers have been received by the + time the _s_e_l_e_c_t-_t_i_m_e_o_u_t has expired, the client will accept + the first offer that arrives. - When the client is restarted, it first tries to reacquire - the last address it had. This is called the INIT-REBOOT - state. If it is still attached to the same network it - was attached to when it last ran, this is the quickest way - to get started. The _r_e_b_o_o_t statement sets the time that - must elapse after the client first tries to reacquire its - old address before it gives up and tries to discover a new - address. By default, the reboot timeout is ten seconds. + By default, the select-timeout is zero seconds - that is, + the client will take the first offer it sees. - _T_h_e bbaacckkooffff--ccuuttooffff _s_t_a_t_e_m_e_n_t + _T_h_e rrrreeeebbbbooooooootttt _s_t_a_t_e_m_e_n_t - bbaacckkooffff--ccuuttooffff _t_i_m_e;; + rrrreeeebbbbooooooootttt _t_i_m_e;;;; - The client uses an exponential backoff algorithm with some - randomness, so that if many clients try to configure them­ - selves at the same time, they will not make their requests - in lockstep. The _b_a_c_k_o_f_f_-_c_u_t_o_f_f statement determines the - 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 _r_e_b_o_o_t statement sets the time that must + elapse after the client first tries to reacquire its old + address before it gives up and tries to discover a new + address. By default, the reboot timeout is ten seconds. + _T_h_e bbbbaaaacccckkkkooooffffffff----ccccuuuuttttooooffffffff _s_t_a_t_e_m_e_n_t + bbbbaaaacccckkkkooooffffffff----ccccuuuuttttooooffffffff _t_i_m_e;;;; - 2 + The client uses an exponential backoff algorithm with some + randomness, so that if many clients try to configure them- + selves at the same time, they will not make their requests + in lockstep. The _b_a_c_k_o_f_f-_c_u_t_o_f_f statement determines the +SunOS 5.6 Last change: 2 -dhclient.conf(5) dhclient.conf(5) - _T_h_e iinniittiiaall--iinntteerrvvaall _s_t_a_t_e_m_e_n_t - iinniittiiaall--iinntteerrvvaall _t_i_m_e;; - The _i_n_i_t_i_a_l_-_i_n_t_e_r_v_a_l statement sets the amount of time - 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) -LLEEAASSEE RREEQQUUIIRREEMMEENNTTSS AANNDD RREEQQUUEESSTTSS - The DHCP protocol allows the client to request that the - server send it specific information, and not send it other - information that it is not prepared to accept. The pro­ - tocol also allows the client to reject offers from servers - if they don't contain information the client needs, or if - the information provided is not satisfactory. - There is a variety of data contained in offers that DHCP - servers send to DHCP clients. The data that can be - specifically requested is what are called _D_H_C_P _O_p_t_i_o_n_s. - DHCP Options are defined in - ddhhccpp--ooppttiioonnss((55)). - _T_h_e rreeqquueesstt _s_t_a_t_e_m_e_n_t + maximum amount of time that the client is allowed to back + off. It defaults to two minutes. - rreeqquueesstt [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n ];; + _T_h_e iiiinnnniiiittttiiiiaaaallll----iiiinnnntttteeeerrrrvvvvaaaallll _s_t_a_t_e_m_e_n_t - The request statement causes the client to request that - 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. + iiiinnnniiiittttiiiiaaaallll----iiiinnnntttteeeerrrrvvvvaaaallll _t_i_m_e;;;; - _T_h_e rreeqquuiirree _s_t_a_t_e_m_e_n_t + The _i_n_i_t_i_a_l-_i_n_t_e_r_v_a_l statement sets the amount of time + between the first attempt to reach a server and the second + attempt to reach a server. Each time a message is sent, the + interval between messages is incremented by twice the + current interval multiplied by a random number between zero + and one. If it is greater than the backoff-cutoff amount, + it is set to that amount. It defaults to ten seconds. - rreeqquuiirree [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _];; +LLLLEEEEAAAASSSSEEEE RRRREEEEQQQQUUUUIIIIRRRREEEEMMMMEEEENNNNTTTTSSSS AAAANNNNDDDD RRRREEEEQQQQUUUUEEEESSSSTTTTSSSS + The DHCP protocol allows the client to request that the + server send it specific information, and not send it other + information that it is not prepared to accept. The proto- + col also allows the client to reject offers from servers if + they don't contain information the client needs, or if the + information provided is not satisfactory. - The require statement lists options that must be sent in - 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 _D_H_C_P _O_p_t_i_o_n_s. DHCP + Options are defined in + ddddhhhhccccpppp----ooooppppttttiiiioooonnnnssss((((5555)))). - _T_h_e sseenndd _s_t_a_t_e_m_e_n_t + _T_h_e rrrreeeeqqqquuuueeeesssstttt _s_t_a_t_e_m_e_n_t - sseenndd {{ [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n - ]}} + rrrreeeeqqqquuuueeeesssstttt [[[[ _o_p_t_i_o_n ] [,,,, ... _o_p_t_i_o_n ];;;; - The send statement causes the client to send the specified - options to the server with the specified values. These - are full option declarations as described in ddhhccpp-- - ooppttiioonnss((55)). Options that are always sent in the DHCP + The request statement causes the client to request that any + server responding to the client send the client its values + for the specified options. Only the option names should be + specified in the request statement - not option parameters. + _T_h_e rrrreeeeqqqquuuuiiiirrrreeee _s_t_a_t_e_m_e_n_t + rrrreeeeqqqquuuuiiiirrrreeee [[[[ _o_p_t_i_o_n ] [,,,, ... _o_p_t_i_o_n ];;;; - 3 + The require statement lists options that must be sent in + order for an offer to be accepted. Offers that do not con- + tain all the listed options will be ignored. + _T_h_e sssseeeennnndddd _s_t_a_t_e_m_e_n_t + sssseeeennnndddd {{{{ [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,,,, ... _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ]}}}} + The send statement causes the client to send the specified + options to the server with the specified values. These are -dhclient.conf(5) dhclient.conf(5) +SunOS 5.6 Last change: 3 - protocol should not be specified here, except that the - client can specify a rreeqquueesstteedd--lleeaassee--ttiimmee option other - than the default requested lease time, which is two hours. - The other obvious use for this statement is to send infor­ - mation to the server that will allow it to differentiate - between this client and other clients or kinds of clients. -OOPPTTIIOONN MMOODDIIFFIIEERRSS - In some cases, a client may receive option data from the - server which is not really appropriate for that client, or - may not receive information that it needs, and for which a - useful default value exists. It may also receive infor­ - mation which is useful, but which needs to be supplemented - with local information. To handle these needs, several - option modifiers are available. - _T_h_e ddeeffaauulltt _s_t_a_t_e_m_e_n_t - ddeeffaauulltt [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; - If for some option the client should use the value sup­ - plied by the server, but needs to use some default value - if no value was supplied by the server, these values can - be defined in the ddeeffaauulltt statement. - _T_h_e ssuuppeerrsseeddee _s_t_a_t_e_m_e_n_t +Headers, Environments, and Macros dhclient.conf(5) - ssuuppeerrsseeddee [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; - If for some option the client should always use a locally- - configured value or values rather than whatever is sup­ - plied by the server, these values can be defined in the - ssuuppeerrsseeddee statement. - _T_h_e pprreeppeenndd _s_t_a_t_e_m_e_n_t + full option declarations as described in ddddhhhhccccpppp----ooooppppttttiiiioooonnnnssss((((5555)))). + Options that are always sent in the DHCP protocol should not + be specified here, except that the client can specify a + rrrreeeeqqqquuuueeeesssstttteeeedddd----lllleeeeaaaasssseeee----ttttiiiimmmmeeee option other than the default requested + lease time, which is two hours. The other obvious use for + this statement is to send information to the server that + will allow it to differentiate between this client and other + clients or kinds of clients. - pprreeppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; +OOOOPPPPTTTTIIIIOOOONNNN MMMMOOOODDDDIIIIFFFFIIIIEEEERRRRSSSS + In some cases, a client may receive option data from the + server which is not really appropriate for that client, or + may not receive information that it needs, and for which a + useful default value exists. It may also receive informa- + tion which is useful, but which needs to be supplemented + with local information. To handle these needs, several + option modifiers are available. - If for some option the client should use both a value it - supplies, and then any values supplied by the server, - these values can be defined in the pprreeppeenndd statement. - The pprreeppeenndd statement can only be used for options which - allow more than one value to be given. + _T_h_e ddddeeeeffffaaaauuuulllltttt _s_t_a_t_e_m_e_n_t - _T_h_e aappppeenndd _s_t_a_t_e_m_e_n_t + ddddeeeeffffaaaauuuulllltttt [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;;; - aappppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; + If for some option the client should use the value supplied + by the server, but needs to use some default value if no + value was supplied by the server, these values can be + defined in the ddddeeeeffffaaaauuuulllltttt statement. - If for some option the client should first any values sup­ - plied to it by the server, and then some values it sup­ - plies, those values should be defined in the aappppeenndd state­ - ment. The aappppeenndd statement can only be used for options - which allow more than one value to be given. + _T_h_e ssssuuuuppppeeeerrrrsssseeeeddddeeee _s_t_a_t_e_m_e_n_t + ssssuuuuppppeeeerrrrsssseeeeddddeeee [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;;; + If for some option the client should always use a locally- + configured value or values rather than whatever is supplied + by the server, these values can be defined in the ssssuuuuppppeeeerrrrsssseeeeddddeeee + statement. + _T_h_e pppprrrreeeeppppeeeennnndddd _s_t_a_t_e_m_e_n_t - 4 + pppprrrreeeeppppeeeennnndddd [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;;; + If for some option the client should use both a value it + supplies, and then any values supplied by the server, these + values can be defined in the pppprrrreeeeppppeeeennnndddd statement. The + pppprrrreeeeppppeeeennnndddd statement can only be used for options which allow + more than one value to be given. + _T_h_e aaaappppppppeeeennnndddd _s_t_a_t_e_m_e_n_t + aaaappppppppeeeennnndddd [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;;; + If for some option the client should first any values sup- + plied to it by the server, and then some values it supplies, -dhclient.conf(5) dhclient.conf(5) -LLEEAASSEE DDEECCLLAARRAATTIIOONNSS - _T_h_e lleeaassee _d_e_c_l_a_r_a_t_i_o_n +SunOS 5.6 Last change: 4 - lleeaassee {{ _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n [ ... _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n _] }} - The DHCP client may decide after some period of time (see - PPRROOTTOOCCOOLL TTIIMMIINNGG) decide that it is not going to succeed in - contacting a server. At that time, it consults its own - database of old leases and tests each one that has not yet - timed out by pinging the listed router for that lease to - see if that lease could work. It is possible to define - one or more _f_i_x_e_d leases in the client configuration file - for networks where there is no DHCP or BOOTP service, so - that the client can still automatically configure its - address. This is done with the lleeaassee statement. - NOTE: the lease statement is also used in the - dhclient.leases file in order to record leases that have - been received from DHCP servers. Some of the syntax for - leases as described below is only needed in the - dhclient.leases file. Such syntax is documented here for - completeness. - A lease statement consists of the lease keyword, followed - by a left curly brace, followed by one or more lease dec­ - laration statements, followed by a right curly brace. - The following lease declarations are possible: - bboooottpp;; - The bboooottpp statement is used to indicate that the lease was - acquired using the BOOTP protocol rather than the DHCP - protocol. It is never necessary to specify this in the - client configuration file. The client uses this syntax - in its lease database file. +Headers, Environments, and Macros dhclient.conf(5) - iinntteerrffaaccee ""_s_t_r_i_n_g"";; - The iinntteerrffaaccee lease statement is used to indicate the - interface on which the lease is valid. If set, this - lease will only be tried on a particular interface. When - the client receives a lease from a server, it always - records the interface number on which it received that - lease. If predefined leases are specified in the - dhclient.conf file, the interface should also be speci­ - fied, although this is not required. - ffiixxeedd--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; + those values should be defined in the aaaappppppppeeeennnndddd statement. + The aaaappppppppeeeennnndddd statement can only be used for options which + allow more than one value to be given. - The ffiixxeedd--aaddddrreessss statement is used to set the ip address - 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). +LLLLEEEEAAAASSSSEEEE DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS + _T_h_e lllleeeeaaaasssseeee _d_e_c_l_a_r_a_t_i_o_n + lllleeeeaaaasssseeee {{{{ _l_e_a_s_e-_d_e_c_l_a_r_a_t_i_o_n [ ... _l_e_a_s_e-_d_e_c_l_a_r_a_t_i_o_n ] }}}} + The DHCP client may decide after some period of time (see + PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTIIIIMMMMIIIINNNNGGGG) decide that it is not going to succeed in + contacting a server. At that time, it consults its own + database of old leases and tests each one that has not yet + timed out by pinging the listed router for that lease to see + if that lease could work. It is possible to define one or + more _f_i_x_e_d leases in the client configuration file for net- + works where there is no DHCP or BOOTP service, so that the + client can still automatically configure its address. This + is done with the lllleeeeaaaasssseeee statement. + NOTE: the lease statement is also used in the + dhclient.leases file in order to record leases that have + been received from DHCP servers. Some of the syntax for + leases as described below is only needed in the + dhclient.leases file. Such syntax is documented here for + completeness. - 5 + A lease statement consists of the lease keyword, followed by + a left curly brace, followed by one or more lease declara- + tion statements, followed by a right curly brace. The fol- + lowing lease declarations are possible: + bbbboooooooottttpppp;;;; + The bbbboooooooottttpppp statement is used to indicate that the lease was + acquired using the BOOTP protocol rather than the DHCP pro- + tocol. It is never necessary to specify this in the client + configuration file. The client uses this syntax in its + lease database file. + iiiinnnntttteeeerrrrffffaaaacccceeee """"_s_t_r_i_n_g"""";;;; + The iiiinnnntttteeeerrrrffffaaaacccceeee lease statement is used to indicate the inter- + face on which the lease is valid. If set, this lease will + only be tried on a particular interface. When the client + receives a lease from a server, it always records the inter- + face number on which it received that lease. If predefined + leases are specified in the dhclient.conf file, the inter- + face should also be specified, although this is not + required. -dhclient.conf(5) dhclient.conf(5) - ffiilleennaammee ""_s_t_r_i_n_g"";; - The ffiilleennaammee statement specifies the name of the boot - filename to use. This is not used by the standard client - configuration script, but is included for completeness. - sseerrvveerr--nnaammee ""_s_t_r_i_n_g"";; +SunOS 5.6 Last change: 5 - The sseerrvveerr--nnaammee statement specifies the name of the boot - server name to use. This is also not used by the stan­ - dard client configuration script. - ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n;; - The ooppttiioonn statement is used to specify the value of an - option supplied by the server, or, in the case of prede­ - fined leases declared in dhclient.conf, the value that the - user wishes the client configuration script to use if the - predefined lease is used. - ssccrriipptt ""_s_c_r_i_p_t_-_n_a_m_e"";; - The ssccrriipptt statement is used to specify the pathname of - the dhcp client configuration script. This script is used - by the dhcp client to set each interface's initial config­ - 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 - ddhhcclliieenntt--lleeaassee((88)).. - mmeeddiiuumm ""_m_e_d_i_a _s_e_t_u_p"";; +Headers, Environments, and Macros dhclient.conf(5) - The mmeeddiiuumm statement can be used on systems where network - interfaces cannot automatically determine the type of net­ - work to which they are connected. The media setup string - is a system-dependent parameter which is passed to the - dhcp client configuration script when initializing the - interface. On Unix and Unix-like systems, the argument is - passed on the ifconfig command line when configuring te - interface. - The dhcp client automatically declares this parameter if - it used a media type (see the mmeeddiiaa statement) when con­ - figuring the interface in order to obtain a lease. This - statement should be used in predefined leases only if the - network interface requires media type configuration. - rreenneeww _d_a_t_e;; + ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss _i_p-_a_d_d_r_e_s_s;;;; - rreebbiinndd _d_a_t_e;; + The ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss statement is used to set the ip address of + a particular lease. This is required for all lease state- + ments. The IP address must be specified as a dotted quad + (e.g., 12.34.56.78). + ffffiiiilllleeeennnnaaaammmmeeee """"_s_t_r_i_n_g"""";;;; + The ffffiiiilllleeeennnnaaaammmmeeee statement specifies the name of the boot + filename to use. This is not used by the standard client + configuration script, but is included for completeness. + sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee """"_s_t_r_i_n_g"""";;;; - 6 + The sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee statement specifies the name of the boot + server name to use. This is also not used by the standard + client configuration script. + ooooppppttttiiiioooonnnn _o_p_t_i_o_n-_d_e_c_l_a_r_a_t_i_o_n;;;; + The ooooppppttttiiiioooonnnn statement is used to specify the value of an + option supplied by the server, or, in the case of predefined + leases declared in dhclient.conf, the value that the user + wishes the client configuration script to use if the prede- + fined lease is used. + ssssccccrrrriiiipppptttt """"_s_c_r_i_p_t-_n_a_m_e"""";;;; + The ssssccccrrrriiiipppptttt statement is used to specify the pathname of the + dhcp client configuration script. This script is used by + the dhcp client to set each interface's initial configura- + tion prior to requesting an address, to test the address + once it has been offered, and to set the interface's final + configuration once a lease has been acquired. If no lease + is acquired, the script is used to test predefined leases, + if any, and also called once if no valid lease can be iden- + tified. For more information, see ddddhhhhcccclllliiiieeeennnntttt----lllleeeeaaaasssseeee((((8888)))).... -dhclient.conf(5) dhclient.conf(5) + mmmmeeeeddddiiiiuuuummmm """"_m_e_d_i_a _s_e_t_u_p"""";;;; + The mmmmeeeeddddiiiiuuuummmm statement can be used on systems where network + interfaces cannot automatically determine the type of net- + work to which they are connected. The media setup string is + a system-dependent parameter which is passed to the dhcp + client configuration script when initializing the interface. + On Unix and Unix-like systems, the argument is passed on the + ifconfig command line when configuring te interface. - eexxppiirree _d_a_t_e;; + The dhcp client automatically declares this parameter if it + used a media type (see the mmmmeeeeddddiiiiaaaa statement) when configuring + the interface in order to obtain a lease. This statement - The rreenneeww statement defines the time at which the dhcp - client should begin trying to contact its server to renew - a lease that it is using. The rreebbiinndd statement defines - the time at which the dhcp client should begin to try to - contact _a_n_y dhcp server in order to renew its lease. The - eexxppiirree statement defines the time at which the dhcp client - must stop using a lease if it has not been able to contact - a server in order to renew it. - These declarations are automatically set in leases - acquired by the DHCP client, but must also be configured - in predefined leases - a predefined lease whose expiry - time has passed will not be used by the DHCP client. - Dates are specified as follows: +SunOS 5.6 Last change: 6 - _<_w_e_e_k_d_a_y_> _<_y_e_a_r_>//_<_m_o_n_t_h_>//_<_d_a_y_> _<_h_o_u_r_>::_<_m_i_n_u_t_e_>::_<_s_e_c_o_n_d_> - The weekday is present to make it easy for a human to tell - when a lease expires - it's specified as a number from - zero to six, with zero being Sunday. When declaring a - predefined lease, it can always be specified as zero. The - year is specified with the century, so it should generally - be four digits except for really long leases. The month - is specified as a number starting with 1 for January. The - day of the month is likewise specified starting with 1. - The hour is a number between 0 and 23, the minute a number - between 0 and 59, and the second also a number between 0 - and 59. -AALLIIAASS DDEECCLLAARRAATTIIOONNSS - aalliiaass {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }} - Some DHCP clients running TCP/IP roaming protocols may - require that in addition to the lease they may acquire via - DHCP, their interface also be configured with a predefined - IP alias so that they can have a permanent IP address even - while roaming. The Internet Software Consortium DHCP - client doesn't support roaming with fixed addresses - directly, but in order to facilitate such experimentation, - the dhcp client can be set up to configure an IP alias - using the aalliiaass declaration. - The alias declaration resembles a lease declaration, - except that options other than the subnet-mask option are - ignored by the standard client configuration script, and - expiry times are ignored. A typical alias declaration - includes an interface declaration, a fixed-address decla­ - ration for the IP alias address, and a subnet-mask option - declaration. A medium statement should never be included - in an alias declaration. +Headers, Environments, and Macros dhclient.conf(5) - 7 + should be used in predefined leases only if the network + interface requires media type configuration. + rrrreeeennnneeeewwww _d_a_t_e;;;; + rrrreeeebbbbiiiinnnndddd _d_a_t_e;;;; + eeeexxxxppppiiiirrrreeee _d_a_t_e;;;; + The rrrreeeennnneeeewwww statement defines the time at which the dhcp + client should begin trying to contact its server to renew a + lease that it is using. The rrrreeeebbbbiiiinnnndddd statement defines the + time at which the dhcp client should begin to try to contact + _a_n_y dhcp server in order to renew its lease. The eeeexxxxppppiiiirrrreeee + statement defines the time at which the dhcp client must + stop using a lease if it has not been able to contact a + server in order to renew it. -dhclient.conf(5) dhclient.conf(5) + These declarations are automatically set in leases acquired + by the DHCP client, but must also be configured in prede- + fined leases - a predefined lease whose expiry time has + passed will not be used by the DHCP client. + Dates are specified as follows: -OOTTHHEERR DDEECCLLAARRAATTIIOONNSS - rreejjeecctt _i_p_-_a_d_d_r_e_s_s;; + <_w_e_e_k_d_a_y> <_y_e_a_r>////<_m_o_n_t_h>////<_d_a_y> <_h_o_u_r>::::<_m_i_n_u_t_e>::::<_s_e_c_o_n_d> - The 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. - iinntteerrffaaccee ""_n_a_m_e"" {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }} +AAAALLLLIIIIAAAASSSS DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS + aaaalllliiiiaaaassss {{{{ _d_e_c_l_a_r_a_t_i_o_n_s ... }}}} - A client with more than one network interface may require - 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 aaaalllliiiiaaaassss declaration. - mmeeddiiaa ""_m_e_d_i_a _s_e_t_u_p"" _[ ,, ""_m_e_d_i_a _s_e_t_u_p"",, _._._. _];; - The mmeeddiiaa statement defines one or more media configura­ - 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. -SSAAMMPPLLEE - 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. +OOOOTTTTHHHHEEEERRRR DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS + rrrreeeejjjjeeeecccctttt _i_p-_a_d_d_r_e_s_s;;;; - 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"; - } + iiiinnnntttteeeerrrrffffaaaacccceeee """"_n_a_m_e"""" {{{{ _d_e_c_l_a_r_a_t_i_o_n_s ... }}}} - 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. -SSEEEE AALLSSOO - dhcp-options(5), dhclient.leases(5), dhcpd(8), - dhcpd.conf(5), RFC2132, RFC2131. + mmmmeeeeddddiiiiaaaa """"_m_e_d_i_a _s_e_t_u_p"""" [ ,,,, """"_m_e_d_i_a _s_e_t_u_p"""",,,, ... ];;;; -AAUUTTHHOORR - ddhhcclliieenntt((88)) was written by Ted Lemon - 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 hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. + The mmmmeeeeddddiiiiaaaa statement defines one or more media configuration + parameters which may be tried while attempting to acquire an + IP address. The dhcp client will cycle through each media + setup string on the list, configuring the interface using + that setup and attempting to boot, and then trying the next + one. This can be used for network interfaces which aren't + capable of sensing the media type unaided - whichever media + type succeeds in getting a request to the server and hearing + the reply is probably right (no guarantees). + The media setup is only used for the initial phase of + address acquisition (the DHCPDISCOVER and DHCPOFFER + packtes). Once an address has been acquired, the dhcp + client will record it in its lease database and will record + the media type used to acquire the address. Whenever the + client tries to renew the lease, it will use that same media + type. The lease must expire before the client will go back + to cycling through media types. +SunOS 5.6 Last change: 8 +Headers, Environments, and Macros dhclient.conf(5) +SSSSAAAAMMMMPPPPLLLLEEEE + The following configuration file is used on a laptop running + NetBSD 1.3. The laptop has an IP alias of 192.5.5.213, and + has one interface, ep0 (a 3com 3C589C). Booting intervals + have been shortened somewhat from the default, because the + client is known to spend most of its time on networks with + little DHCP activity. The laptop does roam to multiple + networks. + timeout 60; + retry 60; + reboot 10; + select-timeout 5; + initial-interval 2; + reject 192.33.137.209; + + interface "ep0" { + send host-name "andare.fugue.com"; + send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; + send dhcp-lease-time 3600; + supersede domain-name "fugue.com rc.vix.com home.vix.com"; + prepend domain-name-servers 127.0.0.1; + request subnet-mask, broadcast-address, time-offset, routers, + domain-name, domain-name-servers, host-name; + require subnet-mask, domain-name-servers; + script "/etc/dhclient-script"; + media "media 10baseT/UTP", "media 10base2/BNC"; + } + + alias { + interface "ep0"; + fixed-address 192.5.5.213; + option subnet-mask 255.255.255.255; + } + This is a very complicated dhclient.conf file - in general, + yours should be much simpler. In many cases, it's suffi- + cient to just create an empty dhclient.conf file - the + defaults are usually fine. + +SSSSEEEEEEEE AAAALLLLSSSSOOOO + dhcp-options(5), dhclient.leases(5), dhcpd(8), + dhcpd.conf(5), RFC2132, RFC2131. + +AAAAUUUUTTTTHHHHOOOORRRR + ddddhhhhcccclllliiiieeeennnntttt((((8888)))) was written by Ted Lemon under + a contract with Vixie Labs. Funding for this project was + provided by the Internet Software Consortium. Information + about the Internet Software Consortium can be found at + hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... + + + + + +SunOS 5.6 Last change: 9 - 9 diff --git a/client/dhclient.leases.cat5 b/client/dhclient.leases.cat5 index 1add3996..1aa044c2 100644 --- a/client/dhclient.leases.cat5 +++ b/client/dhclient.leases.cat5 @@ -1,37 +1,38 @@ -dhclient.leases(5) dhclient.leases(5) +Headers, Environments, and Macros dhclient.leases(5) -NNAAMMEE - dhclient.leases - DHCP client lease database -DDEESSCCRRIIPPTTIIOONN - 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. +NNNNAAAAMMMMEEEE + dhclient.leases - DHCP client lease database - The format of the lease declarations is described in - ddhhcclliieenntt..ccoonnff((55)).. +DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN + The Internet Software Consortium DHCP client keeps a per- + sistent database of leases that it has acquired that are + still valid. The database is a free-form ASCII file con- + taining one valid declaration per lease. If more than one + declaration appears for a given lease, the last one in the + file is used. The file is written as a log, so this is not + an unusual occurrance. -FFIILLEESS - //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess + The format of the lease declarations is described in + ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff((((5555)))).... -SSEEEE AALLSSOO - dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8), - dhcpd.conf(5), RFC2132, RFC2131. +FFFFIIIILLLLEEEESSSS + ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss -AAUUTTHHOORR - ddhhcclliieenntt((88)) was written by Ted Lemon - 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 hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. +SSSSEEEEEEEE AAAALLLLSSSSOOOO + dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8), + dhcpd.conf(5), RFC2132, RFC2131. + +AAAAUUUUTTTTHHHHOOOORRRR + ddddhhhhcccclllliiiieeeennnntttt((((8888)))) was written by Ted Lemon under + a contract with Vixie Labs. Funding for this project was + provided by the Internet Software Consortium. Information + about the Internet Software Consortium can be found at + hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... @@ -59,8 +60,7 @@ AAUUTTHHOORR +SunOS 5.6 Last change: 1 - - 1 diff --git a/common/bpf.c b/common/bpf.c index d67a852e..7b9a29fe 100644 --- a/common/bpf.c +++ b/common/bpf.c @@ -22,7 +22,7 @@ #ifndef lint static char copyright[] = -"$Id: bpf.c,v 1.25 1999/03/16 05:50:31 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: bpf.c,v 1.26 1999/03/16 06:37:48 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -274,7 +274,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) result = writev(interface -> wfdesc, iov, 2); if (result < 0) - warn ("send_packet: %m"); + log_error ("send_packet: %m"); return result; } #endif /* USE_BPF_SEND */ diff --git a/common/dlpi.c b/common/dlpi.c index d86bfdaa..f59bb0ea 100644 --- a/common/dlpi.c +++ b/common/dlpi.c @@ -108,7 +108,7 @@ #ifndef lint static char copyright[] = -"$Id: dlpi.c,v 1.8 1999/03/16 05:50:33 mellon Exp $ Copyright (c) 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: dlpi.c,v 1.9 1999/03/16 06:37:48 mellon Exp $ Copyright (c) 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ static int strioctl PROTO ((int fd, int cmd, int timeout, int len, char *dp)); @@ -504,7 +504,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) 0, 0, dbuf, dbuflen); #endif if (result < 0) - warn ("send_packet: %m"); + log_error ("send_packet: %m"); return result; } #endif /* USE_DLPI_SEND */ diff --git a/common/inet_addr.c b/common/inet_addr.c index 97667bd2..98267b79 100644 --- a/common/inet_addr.c +++ b/common/inet_addr.c @@ -43,7 +43,7 @@ static char rcsid[] = "$NetBSD: inet_addr.c,v 1.6 1996/02/02 15:22:23 mrg Exp $" #ifndef lint static char copyright[] = -"$Id: inet_addr.c,v 1.2 1997/03/29 10:37:51 mellon Exp $ Copyright (c) 1983, 1990, 1993 The Regents of the University of California. All rights reserved.\n"; +"$Id: inet_addr.c,v 1.3 1999/03/16 06:37:49 mellon Exp $ Copyright (c) 1983, 1990, 1993 The Regents of the University of California. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -58,7 +58,7 @@ static char copyright[] = */ int inet_aton(cp, addr) - char *cp; + const char *cp; struct in_addr *addr; { register u_long val; diff --git a/common/lpf.c b/common/lpf.c index d7289a55..b43db1b6 100644 --- a/common/lpf.c +++ b/common/lpf.c @@ -23,7 +23,7 @@ #ifndef lint static char copyright[] = -"$Id: lpf.c,v 1.7 1999/03/16 05:50:34 mellon Exp $ Copyright (c) 1995, 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: lpf.c,v 1.8 1999/03/16 06:37:49 mellon Exp $ Copyright (c) 1995, 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -202,7 +202,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) result = sendto (interface -> wfdesc, buf, bufp + len, 0, &sa, sizeof sa); if (result < 0) - warn ("send_packet: %m"); + log_error ("send_packet: %m"); return result; } #endif /* USE_LPF_SEND */ diff --git a/common/nit.c b/common/nit.c index 19859a30..ce9b79a7 100644 --- a/common/nit.c +++ b/common/nit.c @@ -23,7 +23,7 @@ #ifndef lint static char copyright[] = -"$Id: nit.c,v 1.21 1999/03/16 05:50:35 mellon Exp $ Copyright (c) 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: nit.c,v 1.22 1999/03/16 06:37:49 mellon Exp $ Copyright (c) 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -284,7 +284,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) result = putmsg (interface -> wfdesc, &ctl, &data, 0); if (result < 0) - warn ("send_packet: %m"); + log_error ("send_packet: %m"); return result; } #endif /* USE_NIT_SEND */ diff --git a/common/parse.c b/common/parse.c index 140478be..6bf7030b 100644 --- a/common/parse.c +++ b/common/parse.c @@ -22,7 +22,7 @@ #ifndef lint static char copyright[] = -"$Id: parse.c,v 1.16 1999/03/16 05:50:36 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: parse.c,v 1.17 1999/03/16 06:37:49 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -782,7 +782,7 @@ int parse_cshl (data, cfile) struct data_string *data; FILE *cfile; { - char ibuf [128]; + u_int8_t ibuf [128]; int ilen = 0; int tlen = 0; struct option_tag *sl = (struct option_tag *)0; @@ -1381,7 +1381,8 @@ int parse_non_binary (expr, cfile, lose, context) case STRING: token = next_token (&val, cfile); - if (!make_const_data (expr, val, strlen (val), 1, 1)) + if (!make_const_data (expr, (unsigned char *)val, + strlen (val), 1, 1)) log_fatal ("can't make constant string expression."); break; diff --git a/common/raw.c b/common/raw.c index cf8e584f..fd2c0632 100644 --- a/common/raw.c +++ b/common/raw.c @@ -35,7 +35,7 @@ #ifndef lint static char copyright[] = -"$Id: raw.c,v 1.14 1999/03/16 05:50:36 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: raw.c,v 1.15 1999/03/16 06:37:50 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -112,7 +112,7 @@ size_t send_packet (interface, packet, raw, len, from, to, hto) result = writev(interface -> wfdesc, iov, 2); if (result < 0) - warn ("send_packet: %m"); + log_error ("send_packet: %m"); return result; } #endif /* USE_SOCKET_SEND */ diff --git a/common/socket.c b/common/socket.c index b24544ef..0588cdd5 100644 --- a/common/socket.c +++ b/common/socket.c @@ -30,7 +30,7 @@ #ifndef lint static char copyright[] = -"$Id: socket.c,v 1.34 1999/03/16 05:50:37 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: socket.c,v 1.35 1999/03/16 06:37:50 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -188,10 +188,10 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) retry++ < 10); #endif if (result < 0) { - warn ("send_packet: %m"); + log_error ("send_packet: %m"); if (errno == ENETUNREACH) - warn ("send_packet: please consult README file %s", - "regarding broadcast address."); + log_error ("send_packet: please consult README file %s", + "regarding broadcast address."); } return result; } diff --git a/common/upf.c b/common/upf.c index 554dac4d..65d2d554 100644 --- a/common/upf.c +++ b/common/upf.c @@ -22,7 +22,7 @@ #ifndef lint static char copyright[] = -"$Id: upf.c,v 1.9 1999/03/16 05:50:38 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: upf.c,v 1.10 1999/03/16 06:37:50 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -233,7 +233,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) result = writev(interface -> wfdesc, iov, 2); if (result < 0) - warn ("send_packet: %m"); + log_error ("send_packet: %m"); return result; } #endif /* USE_UPF_SEND */ diff --git a/includes/dhcpd.h b/includes/dhcpd.h index 521142d7..0ce46480 100644 --- a/includes/dhcpd.h +++ b/includes/dhcpd.h @@ -300,7 +300,7 @@ struct lease_state { #endif #ifndef CL_DEFAULT_BOOTP_POLICY -# define CL_DEFAULT_BOOTP_POLICY ACCEPT +# define CL_DEFAULT_BOOTP_POLICY P_ACCEPT #endif #ifndef CL_DEFAULT_SCRIPT_NAME diff --git a/includes/tree.h b/includes/tree.h index 6b280b03..14f94092 100644 --- a/includes/tree.h +++ b/includes/tree.h @@ -36,7 +36,7 @@ typedef struct _pair { /* A data buffer with a reference count. */ struct buffer { int refcnt; - char data [1]; + unsigned char data [1]; }; /* XXX The mechanism by which data strings are returned is currently @@ -125,7 +125,6 @@ struct data_string; /* forward */ struct packet; /* forward */ struct option_state; /* forward */ struct decoded_option_state; /* forward */ -enum statement_op; /* forward */ struct universe { char *name; diff --git a/relay/dhcrelay.cat8 b/relay/dhcrelay.cat8 index 7dea2a27..4254a341 100644 --- a/relay/dhcrelay.cat8 +++ b/relay/dhcrelay.cat8 @@ -1,218 +1,214 @@ -dhcrelay(8) dhcrelay(8) +Maintenance Procedures dhcrelay(8) -NNAAMMEE - dhcrelay - Dynamic Host Configuration Protocol Relay Agent - -SSYYNNOOPPSSIISS - ddhhccrreellaayy [ --pp _p_o_r_t ] [ --dd ] [ --qq ] [ --ii _i_f_0 [ ...... --ii _i_f_N - ] ] [ --aa ] [ --AA _l_e_n_g_t_h ] [ --DD ] [ --mm _a_p_p_e_n_d | _r_e_p_l_a_c_e | - _f_o_r_w_a_r_d | _d_i_s_c_a_r_d ] _s_e_r_v_e_r_0 [ _._._._s_e_r_v_e_r_N ] - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP Relay Agent, dhcre­ - lay, provides a means for relaying DHCP and BOOTP requests - from a subnet to which no DHCP server is directly to one - or more DHCP servers on other subnets. - -OOPPEERRAATTIIOONN - The DHCP Relay Agent listens for DHCP and BOOTP queries - and responses. When a query is received from a client, - dhcrelay forwards it to the list of DHCP servers specified - on the command line. When a reply is received from a - server, it is broadcast or unicast (according to the relay - agent's ability or the client's request) on the network - from which the original request came. -CCOOMMMMAANNDD LLIINNEE - The names of the network interfaces that dhcrelay should - attempt to configure may be specified on the command line - using the --ii option. If no interface names are specified - on the command line dhcrelay will identify all network - interfaces, elimininating non-broadcast interfaces if pos­ - sible, and attempt to configure each interface. +NNNNAAAAMMMMEEEE + 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 _a_r_e connected, it is may not be helpful - for the relay agent to relay requests from those networks - on which a DHCP server already exists. To avoid such a - situation, the interfaces on which the relay agent should - listen should be specified with the --ii flag. +SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS + ddddhhhhccccrrrreeeellllaaaayyyy [ ----pppp _p_o_r_t ] [ ----dddd ] [ ----qqqq ] [ ----iiii _i_f_0 [ ............ ----iiii _i_f_N ] ] + [ ----aaaa ] [ ----AAAA _l_e_n_g_t_h ] [ ----DDDD ] [ ----mmmm _a_p_p_e_n_d | _r_e_p_l_a_c_e | _f_o_r_w_a_r_d + | _d_i_s_c_a_r_d ] _s_e_r_v_e_r_0 [ ..._s_e_r_v_e_r_N ] - Note that in some cases it _i_s helpful for the relay agent - to forward requests from networks on which a DHCP server - is running to other DHCP servers. This would be the case - if two DHCP servers on different networks were being used - to provide backup service for each other's networks. +DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN + The Internet Software Consortium DHCP Relay Agent, dhcrelay, + provides a means for relaying DHCP and BOOTP requests from a + subnet to which no DHCP server is directly to one or more + DHCP servers on other subnets. - If dhcrelay should listen and transmit on a port other - than the standard (port 67), the --pp flag may used. It - should be followed by the udp port number that dhcrelay - should use. This is mostly useful for debugging purposes. +OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN + The DHCP Relay Agent listens for DHCP and BOOTP queries and + responses. When a query is received from a client, dhcrelay + forwards it to the list of DHCP servers specified on the + command line. When a reply is received from a server, it is + broadcast or unicast (according to the relay agent's ability + or the client's request) on the network from which the ori- + ginal request came. - 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 +CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE + The names of the network interfaces that dhcrelay should + attempt to configure may be specified on the command line + using the ----iiii option. If no interface names are specified on + the command line dhcrelay will identify all network inter- + faces, elimininating non-broadcast interfaces if possible, + and attempt to configure each interface. + If a relay agent is running on a system that is connected to + one or more networks on which no DHCP servers are present, + and is also connected to one or more networks on which DHCP + servers _a_r_e connected, it is may not be helpful for the + relay agent to relay requests from those networks on which a + DHCP server already exists. To avoid such a situation, the + interfaces on which the relay agent should listen should be + specified with the ----iiii flag. + Note that in some cases it _i_s helpful for the relay agent to + forward requests from networks on which a DHCP server is + running to other DHCP servers. This would be the case if + two DHCP servers on different networks were being used to + provide backup service for each other's networks. - 1 + If dhcrelay should listen and transmit on a port other than + the standard (port 67), the ----pppp flag may used. It should be + followed by the udp port number that dhcrelay should use. + This is mostly useful for debugging purposes. -dhcrelay(8) dhcrelay(8) +SunOS 5.6 Last change: 1 - a foreground process, the --dd flag should be specified. - This is useful when running dhcrelay under a debugger, or - when running it out of inittab on System V systems. - Dhcrelay will normally print its network configuration on - startup. This can be annoying in a system startup script - - to disable this behaviour, specify the --qq flag. -RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIOONNSS - If the --aa flag is set the relay agent will append an agent - option field to each request before forwarding it to the - server. Agent option fields in responses sent from - servers to clients will be stripped before forwarding such - responses back to the client. - The agent option field will contain two agent options: the - Circuit ID suboption and the Agent ID suboption. Cur­ - rently, the Circuit ID will be the printable name of the - interface on which the client request was received. The - Agent ID will be the value that the relay agent stores in - the DHCP packet's giaddr field. The client supports - inclusion of a Remote ID suboption as well, but this is - not used by default. - _N_o_t_e_: The Agent ID suboption is not defined in the current - 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 --AA 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 ----dddd flag should be specified. This + is useful when running dhcrelay under a debugger, or when + running it out of inittab on System V systems. + Dhcrelay will normally print its network configuration on + startup. This can be annoying in a system startup script - + to disable this behaviour, specify the ----qqqq flag. +RRRREEEELLLLAAAAYYYY AAAAGGGGEEEENNNNTTTT IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN OOOOPPPPTTTTIIIIOOOONNNNSSSS + If the ----aaaa flag is set the relay agent will append an agent + option field to each request before forwarding it to the + server. Agent option fields in responses sent from servers + to clients will be stripped before forwarding such responses + back to the client. + The agent option field will contain two agent options: the + Circuit ID suboption and the Agent ID suboption. Currently, + the Circuit ID will be the printable name of the interface + on which the client request was received. The Agent ID + will be the value that the relay agent stores in the DHCP + packet's giaddr field. The client supports inclusion of a + Remote ID suboption as well, but this is not used by + default. - 2 + _N_o_t_e: The Agent ID suboption is not defined in the current + Relay Agent Information Option draft (draft-ietf-dhc-agent- + options-03.txt), but has been proposed for inclusion in the + next draft. + Relay Agent options are added to a DHCP packet without the + knowledge of the DHCP client. The client may have filled + the DHCP packet option buffer completely, in which case + there theoretically isn't any space to add Agent options. + However, the DHCP server may be able to handle a much larger + packet than most DHCP clients would send. The current + Agent Options draft requires that the relay agent use a max- + imum packet size of 576 bytes. + It is recommended that with the Internet Software Consortium + DHCP server, the maximum packet size be set to about 1400, + allowing plenty of extra space in which the relay agent can + put the agent option field, while still fitting into the + Ethernet MTU size. This can be done by specifying the ----AAAA + flag, followed by the desired maximum packet size (e.g., + 1400). + Note that this is reasonably safe to do even if the MTU + between the server and the client is less than 1500, as long + as the hosts on which the server and client are running -dhcrelay(8) dhcrelay(8) +SunOS 5.6 Last change: 2 - It is possible for a relay agent to receive a packet which - already contains an agent option field. If this packet - does not have a giaddr set, the standard requires that the - packet be discarded. - If giaddr is set, the server may handle the situation in - one of four ways: it may _a_p_p_e_n_d its own set of relay - options to the packet, leaving the supplied option field - intact. It may _r_e_p_l_a_c_e the existing agent option field. - It may _f_o_r_w_a_r_d the packet unchanged. Or, it may _d_i_s_c_a_r_d - it. - Which of these behaviours is followed by the Internet - Software Consortium DHCP Relay Agent may be configured - with the --mm flag, followed by one of the four keywords - specified in _i_t_a_l_i_c_s above. - When the relay agent receives a reply from a server that - it's supposed to forward to a client, and Relay Agent - Information option processing is enabled, the relay agent - scans the packet for Relay Agent Information options and - removes them. As it's scanning, if it finds a Relay - Agent Information option field containing an Agent ID sub­ - option that matches one of its IP addresses, that option - is recognized as its own. If no such option is found, - the relay agent can either drop the packet, or relay it - anyway. If the --DD option is specified, all packets that - don't contain a match will be dropped. -SSPPEECCIIFFYYIINNGG DDHHCCPP SSEERRVVEERRSS - The name or IP address of at least one DHCP server to - which DHCP and BOOTP requests should be relayed must be - specified on the command line. -SSEEEE AALLSSOO - dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc- - agent-options-03.txt. +Maintenance Procedures dhcrelay(8) -BBUUGGSS - It should be possible for the user to define the Circuit - ID and Remote ID values on a per-interface basis. - The relay agent should not relay packets received on a - physical network to DHCP servers on the same physical net­ - 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. -AAUUTTHHOORR - ddhhccrreellaayy((88)) has been written for the Internet Software - Consortium by Ted Lemon in cooperation - with Vixie Enterprises. To learn more about the Internet - Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. 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 _a_p_p_e_n_d its own set of relay options to + the packet, leaving the supplied option field intact. It + may _r_e_p_l_a_c_e the existing agent option field. It may _f_o_r_w_a_r_d + the packet unchanged. Or, it may _d_i_s_c_a_r_d it. - 3 + Which of these behaviours is followed by the Internet + Software Consortium DHCP Relay Agent may be configured with + the ----mmmm flag, followed by one of the four keywords specified + in _i_t_a_l_i_c_s above. + When the relay agent receives a reply from a server that + it's supposed to forward to a client, and Relay Agent Infor- + mation option processing is enabled, the relay agent scans + the packet for Relay Agent Information options and removes + them. As it's scanning, if it finds a Relay Agent Informa- + tion option field containing an Agent ID suboption that + matches one of its IP addresses, that option is recognized + as its own. If no such option is found, the relay agent + can either drop the packet, or relay it anyway. If the ----DDDD + option is specified, all packets that don't contain a match + will be dropped. +SSSSPPPPEEEECCCCIIIIFFFFYYYYIIIINNNNGGGG DDDDHHHHCCCCPPPP SSSSEEEERRRRVVVVEEEERRRRSSSS + The name or IP address of at least one DHCP server to which + DHCP and BOOTP requests should be relayed must be specified + on the command line. +SSSSEEEEEEEE AAAALLLLSSSSOOOO + dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc- + agent-options-03.txt. +BBBBUUUUGGGGSSSS + It should be possible for the user to define the Circuit ID + and Remote ID values on a per-interface basis. -dhcrelay(8) dhcrelay(8) + The relay agent should not relay packets received on a phy- + sical network to DHCP servers on the same physical network - + if they do, the server will receive duplicate packets. In + order to fix this, however, the relay agent needs to be able + to learn about the network topology, which requires that it + have a configuration file. - more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm.. +SunOS 5.6 Last change: 3 +Maintenance Procedures dhcrelay(8) +AAAAUUUUTTTTHHHHOOOORRRR + ddddhhhhccccrrrreeeellllaaaayyyy((((8888)))) has been written for the Internet Software Con- + sortium by Ted Lemon in cooperation with + Vixie Enterprises. To learn more about the Internet + Software Consortium, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To learn + more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm.... @@ -259,6 +255,10 @@ dhcrelay(8) dhcrelay(8) - 4 + + + +SunOS 5.6 Last change: 4 + diff --git a/server/confpars.c b/server/confpars.c index 2ced42c8..74f7f701 100644 --- a/server/confpars.c +++ b/server/confpars.c @@ -22,7 +22,7 @@ #ifndef lint static char copyright[] = -"$Id: confpars.c,v 1.64 1999/03/16 05:50:42 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: confpars.c,v 1.65 1999/03/16 06:37:51 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -782,7 +782,7 @@ int parse_allow_deny (oc, cfile, flag) { enum dhcp_token token; char *val; - char rf = flag; + unsigned char rf = flag; struct expression *data = (struct expression *)0; int status; @@ -998,7 +998,7 @@ struct class *parse_class_declaration (cfile, group, type) return (struct class *)0; data.terminated = 1; data.data = &data.buffer -> data [0]; - strcpy (data.data, val); + strcpy ((char *)data.data, val); } else if (token == NUMBER_OR_NAME || token == NUMBER) { memset (&data, 0, sizeof data); if (!parse_cshl (&data, cfile)) diff --git a/server/dhcp.c b/server/dhcp.c index eca1024a..6203256e 100644 --- a/server/dhcp.c +++ b/server/dhcp.c @@ -22,7 +22,7 @@ #ifndef lint static char copyright[] = -"$Id: dhcp.c,v 1.82 1999/03/16 05:50:43 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: dhcp.c,v 1.83 1999/03/16 06:37:52 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -384,7 +384,8 @@ void nak_lease (packet, cip) return; } if (!make_const_data (&oc -> expression, - dhcp_message, strlen (dhcp_message), 1, 0)) { + (unsigned char *)dhcp_message, + strlen (dhcp_message), 1, 0)) { log_error ("No memory for expr_const expression."); option_cache_dereference (&oc, "nak_lease"); return; @@ -1072,7 +1073,8 @@ void ack_lease (packet, lease, offer, when, msg) oc = (struct option_cache *)0; if (option_cache_allocate (&oc, "ack_lease")) { if (make_const_data (&oc -> expression, - lease -> host -> name, + ((unsigned char *) + lease -> host -> name), strlen (lease -> host -> name), 1, 0)) { oc -> option = dhcp_universe.options [i]; @@ -1101,7 +1103,8 @@ void ack_lease (packet, lease, offer, when, msg) oc = (struct option_cache *)0; if (option_cache_allocate (&oc, "ack_lease")) { if (make_const_data (&oc -> expression, - h -> h_name, + ((unsigned char *) + h -> h_name), strlen (h -> h_name) + 1, 1, 1)) { oc -> option = @@ -1680,16 +1683,18 @@ struct lease *find_lease (packet, share, ours) if (packet -> packet_type == DHCPREQUEST && fixed_lease) { fixed_lease = (struct lease *)0; db_conflict: - warn ("Both dynamic and static leases present for %s.", - 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, diff --git a/server/dhcpd.cat8 b/server/dhcpd.cat8 index 8d3381d5..781b42dc 100644 --- a/server/dhcpd.cat8 +++ b/server/dhcpd.cat8 @@ -1,372 +1,353 @@ -dhcpd(8) dhcpd(8) - - -NNAAMMEE - dhcpd - Dynamic Host Configuration Protocol Server - -SSYYNNOOPPSSIISS - ddhhccppdd [ --pp _p_o_r_t ] [ --ff ] [ --dd ] [ --qq ] [ --ccff _c_o_n_f_i_g_-_f_i_l_e ] - [ --llff _l_e_a_s_e_-_f_i_l_e ] [ _i_f_0 [ _._._._i_f_N ] ] - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP Server, dhcpd, - implements the Dynamic Host Configuration Protocol (DHCP) - and the Internet Bootstrap Protocol (BOOTP). DHCP allows - hosts on a TCP/IP network to request and be assigned IP - addresses, and also to discover information about the net­ - work to which they are attached. BOOTP provides similar - functionality, with certain restrictions. - -CCOONNTTRRIIBBUUTTIIOONNSS - Development of this software is funded through contribu­ - tions and support contracts. Please see ddhhccpp--ccoonnttrriibb((55)) - for information on how you can contribute. - -OOPPEERRAATTIIOONN - The DHCP protocol allows a host which is unknown to the - network administrator to be automatically assigned a new - IP address out of a pool of IP addresses for its network. - In order for this to work, the network administrator allo­ - cates address pools in each subnet and enters them into - the dhcpd.conf(5) file. +Maintenance Procedures dhcpd(8) - On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and stores a - list of available addresses on each subnet in memory. - When a client requests an address using the DHCP protocol, - dhcpd allocates an address for it. Each client is - assigned a lease, which expires after an amount of time - chosen by the administrator (by default, one day). Before - leases expire, the clients to which leases are assigned - are expected to renew them in order to continue to use the - addresses. Once a lease has expired, the client to which - that lease was assigned is no longer permitted to use the - leased IP address. - In order to keep track of leases across system reboots and - server restarts, dhcpd keeps a list of leases it has - assigned in the dhcpd.leases(5) file. Before dhcpd - grants a lease to a host, it records the lease in this - file and makes sure that the contents of the file are - flushed to disk. This ensures that even in the event of - a system crash, dhcpd will not forget about a lease that - it has assigned. On startup, after reading the - dhcpd.conf file, dhcpd reads the dhcpd.leases file to - refresh its memory about what leases have been assigned. - New leases are appended to the end of the dhcpd.leases - file. In order to prevent the file from becoming - - - - 1 - - - - - -dhcpd(8) dhcpd(8) - - - arbitrarily large, from time to time dhcpd creates a new - dhcpd.leases file from its in-core lease database. Once - this file has been written to disk, the old file is - renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed - dhcpd.leases. If the system crashes in the middle of - this process, whichever dhcpd.leases file remains will - contain all the lease information, so there is no need for - a special crash recovery process. - - BOOTP support is also provided by this server. Unlike - DHCP, the BOOTP protocol does not provide a protocol for - recovering dynamically-assigned addresses once they are no - longer needed. It is still possible to dynamically - assign addresses to BOOTP clients, but some administrative - process for reclaiming addresses is required. By - default, leases are granted to BOOTP clients in perpetu­ - 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. +NNNNAAAAMMMMEEEE + 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 - _/_v_a_r_/_r_u_n_/_d_h_c_p_d_._p_i_d, and then re-invoke dhcpd. Because the - DHCP server database is not as lightweight as a BOOTP - database, dhcpd does not automatically restart itself when - it sees a change to the dhcpd.conf file. +SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS + ddddhhhhccccppppdddd [ ----pppp _p_o_r_t ] [ ----ffff ] [ ----dddd ] [ ----qqqq ] [ ----ccccffff _c_o_n_f_i_g-_f_i_l_e ] [ + ----llllffff _l_e_a_s_e-_f_i_l_e ] [ _i_f_0 [ ..._i_f_N ] ] + +DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN + The Internet Software Consortium DHCP Server, dhcpd, imple- + ments the Dynamic Host Configuration Protocol (DHCP) and the + Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a + TCP/IP network to request and be assigned IP addresses, and + also to discover information about the network to which they + are attached. BOOTP provides similar functionality, with + certain restrictions. + +CCCCOOOONNNNTTTTRRRRIIIIBBBBUUUUTTTTIIIIOOOONNNNSSSS + Development of this software is funded through contributions + and support contracts. Please see ddddhhhhccccpppp----ccccoooonnnnttttrrrriiiibbbb((((5555)))) for + information on how you can contribute. + +OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN + The DHCP protocol allows a host which is unknown to the net- + work administrator to be automatically assigned a new IP + address out of a pool of IP addresses for its network. In + order for this to work, the network administrator allocates + address pools in each subnet and enters them into the + dhcpd.conf(5) file. - Note: We get a lot of complaints about this. We realize - 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 _d_h_c_p_d._c_o_n_f file and stores a + list of available addresses on each subnet in memory. When + a client requests an address using the DHCP protocol, dhcpd + allocates an address for it. Each client is assigned a + lease, which expires after an amount of time chosen by the + administrator (by default, one day). Before leases expire, + the clients to which leases are assigned are expected to + renew them in order to continue to use the addresses. Once + a lease has expired, the client to which that lease was + assigned is no longer permitted to use the leased IP + address. -CCOOMMMMAANNDD LLIINNEE - 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 --pp flag may used. It should be followed by - the udp port number on which dhcpd should listen. This is - mostly useful for debugging purposes. - To run dhcpd as a foreground process, rather than allowing - it to run as a daemon in the background, the --ff flag - should be specified. This is useful when running dhcpd - under a debugger, or when running it out of inittab on - System V systems. - To have dhcpd log to the standard error descriptor, spec­ - ify the --dd flag. This can be useful for debugging, and - also at sites where a complete log of all dhcp activity - must be kept but syslogd is not reliable or otherwise can­ - 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 _d_h_c_p_d._l_e_a_s_e_s~, + and the new file is renamed dhcpd.leases. If the system + crashes in the middle of this process, whichever + dhcpd.leases file remains will contain all the lease infor- + mation, so there is no need for a special crash recovery + process. - Dhcpd can be made to use an alternate configuration file - with the --ccff flag, or an alternate lease file with the --llff - flag. Because of the importance of using the same lease - database at all times when running dhcpd in production, - these options should be used oonnllyy for testing lease files - or database files in a non-production environment. + 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 --qq 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. -CCOONNFFIIGGUURRAATTIIOONN - 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 /_e_t_c/_d_h_c_p_d._p_i_d, and then re- + invoke dhcpd. Because the DHCP server database is not as + lightweight as a BOOTP database, dhcpd does not automati- + cally restart itself when it sees a change to the dhcpd.conf + file. + Note: We get a lot of complaints about this. We realize + that it would be nice if one could send a SIGHUP to the + server and have it reload the database. This is not techn- + ically impossible, but it would require a great deal of + work, our resources are extremely limited, and they can be + better spent elsewhere. So please don't complain about + this on the mailing list unless you're prepared to fund a + project to implement this feature, or prepared to do it + yourself. -SSuubbnneettss - 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: +CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE + The names of the network interfaces on which dhcpd should + listen for broadcasts may be specified on the command line. + This should be done on systems where dhcpd is unable to + identify non-broadcast interfaces, but should not be + required on other systems. If no interface names are 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 ----pppp flag may used. It should be followed by + the udp port number on which dhcpd should listen. This is + mostly useful for debugging purposes. - If a subnet will only be provided with BOOTP service and - 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 ----ffff flag should + be specified. This is useful when running dhcpd under a + debugger, or when running it out of inittab on System V sys- + tems. + To have dhcpd log to the standard error descriptor, specify + the ----dddd flag. This can be useful for debugging, and also at + sites where a complete log of all dhcp activity must be kept + but syslogd is not reliable or otherwise cannot be used. + Normally, dhcpd will log all output using the syslog(3) + function with the log facility set to LOG_DAEMON. -LLeeaassee LLeennggtthhss - 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 ----ccccffff flag, or an alternate lease file with the ----llllffff + flag. Because of the importance of using the same lease + database at all times when running dhcpd in production, + these options should be used oooonnnnllllyyyy 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 ----qqqq 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: +CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN + The syntax of the dhcpd.conf(5) file is discussed + seperately. This section should be used as an overview of + the configuration process, and the dhcpd.conf(5) documenta- + tion should be consulted for detailed reference information. - 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; - | +SSSSuuuubbbbnnnneeeettttssss + 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. -BBOOOOTTPP SSuuppppoorrtt - Each BOOTP client must be explicitly declared in the - dhcpd.conf file. A very basic client declaration will - specify the client network interface's hardware address - and the IP address to assign to that client. If the - client needs to be able to load a boot file from the - server, that file's name must be specified. A simple +SunOS 5.6 Last change: 3 - 4 -dhcpd(8) dhcpd(8) +Maintenance Procedures dhcpd(8) - bootp client declaration might look like this: - host haagen { - 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: -OOppttiioonnss - 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"; - } +LLLLeeeeaaaasssseeee LLLLeeeennnnggggtttthhhhssss + DHCP leases can be assigned almost any length from zero + seconds to infinity. What lease length makes sense for any + given subnet, or for any given installation, will vary + 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; + | -FFIILLEESS - //eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,, - //vvaarr//ddbb//ddhhccppdd..lleeaasseess~~.. + 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. +BBBBOOOOOOOOTTTTPPPP SSSSuuuuppppppppoooorrrrtttt + Each BOOTP client must be explicitly declared in the + dhcpd.conf file. A very basic client declaration will + specify the client network interface's hardware address and - 5 +SunOS 5.6 Last change: 4 -dhcpd(8) dhcpd(8) +Maintenance Procedures dhcpd(8) -SSEEEE AALLSSOO - dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5) -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. + the IP address to assign to that client. If the client + needs to be able to load a boot file from the server, that + file's name must be specified. A simple bootp client + declaration might look like this: + host haagen { + hardware ethernet 08:00:2b:4c:59:23; + fixed-address 239.252.197.9; + filename "/tftpboot/haagen.boot"; + } +OOOOppppttttiiiioooonnnnssss + DHCP (and also BOOTP with Vendor Extensions) provide a + mechanism whereby the server can provide the client with + information about how to configure its network interface + (e.g., subnet mask), and also how the client can access + various network services (e.g., DNS, IP routers, and so on). + These options can be specified on a per-subnet basis, and, + for BOOTP clients, also on a per-client basis. In the + event that a BOOTP client declaration specifies options that + are also specified in its subnet declaration, the options + specified in the client declaration take precedence. An + reasonably complete DHCP configuration might look something + like this: + subnet 239.252.197.0 netmask 255.255.255.0 { + range 239.252.197.10 239.252.197.250; + default-lease-time 600 max-lease-time 7200; + option subnet-mask 255.255.255.0; + option broadcast-address 239.252.197.255; + option routers 239.252.197.1; + option domain-name-servers 239.252.197.2, 239.252.197.3; + option domain-name "isc.org"; + } + A bootp host on that subnet that needs to be in a different + domain and use a different name server might be declared as + follows: + host haagen { + hardware ethernet 08:00:2b:4c:59:23; + fixed-address 239.252.197.9; + filename "/tftpboot/haagen.boot"; + option domain-name-servers 192.5.5.1; + option domain-name "vix.com"; + } + A more complete description of the dhcpd.conf file syntax is + provided in dhcpd.conf(5). +SunOS 5.6 Last change: 5 +Maintenance Procedures dhcpd(8) +FFFFIIIILLLLEEEESSSS + ////eeeettttcccc////ddddhhhhccccppppdddd....ccccoooonnnnffff,,,, ////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss,,,, ////eeeettttcccc////ddddhhhhccccppppdddd....ppppiiiidddd,,,, + ////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss~~~~.... +SSSSEEEEEEEE AAAALLLLSSSSOOOO + dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5) +AAAAUUUUTTTTHHHHOOOORRRR + ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon under a + contract with Vixie Labs. Funding for this project was + provided by the Internet Software Consortium. Information + about the Internet Software Consortium can be found at + hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... @@ -391,6 +372,25 @@ AAUUTTHHOORR - 6 + + + + + + + + + + + + + + + + + + +SunOS 5.6 Last change: 6 + diff --git a/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5 index bffedf32..cfd018fb 100644 --- a/server/dhcpd.conf.cat5 +++ b/server/dhcpd.conf.cat5 @@ -1,1019 +1,1040 @@ -dhcpd.conf(5) dhcpd.conf(5) - - -NNAAMMEE - dhcpd.conf - dhcpd configuration file - -DDEESSCCRRIIPPTTIIOONN - The dhcpd.conf file contains configuration information for - _d_h_c_p_d_, 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 - _s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declarations. If clients - on a subnet are to be assigned addresses dynamically, a - _r_a_n_g_e declaration must appear within the _s_u_b_n_e_t declara­ - tion. For clients with statically assigned addresses, or - for installations where only known clients will be served, - each such client must have a _h_o_s_t declaration. If param­ - eters are to be applied to a group of declarations which - are not related strictly on a per-subnet basis, the _g_r_o_u_p - 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 _s_u_b_n_e_t declaration, which tells dhcpd how to recognize - that an address is on that subnet. A _s_u_b_n_e_t 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 +Headers, Environments, and Macros dhcpd.conf(5) - 1 +NNNNAAAAMMMMEEEE + dhcpd.conf - dhcpd configuration file + +DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN + The dhcpd.conf file contains configuration information for + _d_h_c_p_d, 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 + _s_h_a_r_e_d-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declarations. If clients on + a subnet are to be assigned addresses dynamically, a _r_a_n_g_e + declaration must appear within the _s_u_b_n_e_t declaration. For + clients with statically assigned addresses, or for installa- + tions where only known clients will be served, each such + client must have a _h_o_s_t declaration. If parameters are to + be applied to a group of declarations which are not related + strictly on a per-subnet basis, the _g_r_o_u_p 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 + _s_u_b_n_e_t declaration, which tells dhcpd how to recognize that + an address is on that subnet. A _s_u_b_n_e_t declaration is + required for each subnet even if no addresses will be dynam- + ically allocated on that subnet. -dhcpd.conf(5) dhcpd.conf(5) +SunOS 5.6 Last change: 1 - 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 _s_u_b_n_e_t declarations for these - two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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 _h_o_s_t declarations, these declara­ - tions can be enclosed in a _g_r_o_u_p 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 _h_o_s_t declara­ - tion (if any), then consulting the _g_r_o_u_p declaration (if - any) which enclosed that _h_o_s_t declaration, then consulting - the _s_u_b_n_e_t declaration for the subnet on which the client - is booting, then consulting the _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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 _h_o_s_t declaration for a client, - it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_- - _a_d_d_r_e_s_s 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 _f_i_x_e_d_-_a_d_d_r_e_s_s 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. -EEXXAAMMPPLLEESS - A typical dhcpd.conf file will look something like this: +Headers, Environments, and Macros dhcpd.conf(5) - _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._. - subnet 204.254.239.0 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.10 204.254.239.30; + + 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 _s_u_b_n_e_t declarations for these two networks + may be enclosed in a _s_h_a_r_e_d-_n_e_t_w_o_r_k 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 _h_o_s_t declarations, these declarations can be + enclosed in a _g_r_o_u_p 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 _h_o_s_t declara- + tion (if any), then consulting the _g_r_o_u_p declaration (if + any) which enclosed that _h_o_s_t declaration, then consulting + the _s_u_b_n_e_t declaration for the subnet on which the client is + booting, then consulting the _s_h_a_r_e_d-_n_e_t_w_o_r_k 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 _h_o_s_t declaration for a client, it + first looks for a _h_o_s_t declaration which has a _f_i_x_e_d-_a_d_d_r_e_s_s + 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 _f_i_x_e_d- + _a_d_d_r_e_s_s 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. + +EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS + A typical dhcpd.conf file will look something like this: + + _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s... + + subnet 204.254.239.0 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.10 204.254.239.30; + } + + + + +SunOS 5.6 Last change: 2 + + + + + + +Headers, Environments, and Macros dhcpd.conf(5) + + + + subnet 204.254.239.32 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.42 204.254.239.62; + } + + subnet 204.254.239.64 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.74 204.254.239.94; + } + + group { + _g_r_o_u_p-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + host zappo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + host beppo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + host harpo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + } + + 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; + + 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; + + + + + +SunOS 5.6 Last change: 3 + + + + + + +Headers, Environments, and Macros dhcpd.conf(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 _g_r_o_u_p 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; + + You may have noticed that while some parameters start with + the _o_p_t_i_o_n keyword, some do not. Parameters starting with + the _o_p_t_i_o_n 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 _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. These + could include such things as the _h_o_s_t_n_a_m_e option, the name + of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r) _a_n_d _t_h_e _a_d_d_r_e_s_s + _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e (_t_h_e _n_e_x_t-_s_e_r_v_e_r + 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-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: + + group { + filename "Xncd19r"; + next-server ncd-booter; + + + + +SunOS 5.6 Last change: 4 + + + + + + +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; + + 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; + + 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; } + } + +AAAADDDDDDDDRRRREEEESSSSSSSS PPPPOOOOOOOOLLLLSSSS + The ppppoooooooollll 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: + + 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; } - subnet 204.254.239.32 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.42 204.254.239.62; + # 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; } + } + + 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. + +CCCCLLLLIIIIEEEENNNNTTTT CCCCLLLLAAAASSSSSSSSIIIINNNNGGGG + 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 aaaadddddddd state- + ment in the conditional's list of statements: + + 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; + } + + subclass vendor-classes "SUNW.Ultra-5_10" { + option vendor-encapsulated-options - 2 +SunOS 5.6 Last change: 6 -dhcpd.conf(5) dhcpd.conf(5) - - subnet 204.254.239.64 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.74 204.254.239.94; - } - - group { - _g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - host zappo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host beppo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host harpo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - } - - 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; - - 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: - - 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. +Headers, Environments, and Macros dhcpd.conf(5) + 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; + } - 3 + 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; + } + + 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 _s_p_a_w_n_i_n_g _c_l_a_s_s. 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. + + 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; + + + +SunOS 5.6 Last change: 7 -dhcpd.conf(5) dhcpd.conf(5) - - In Figure 1 there is also a _g_r_o_u_p 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: - - 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 _o_p_t_i_o_n keyword, some do not. Parameters starting - with the _o_p_t_i_o_n 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 _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. - These could include such things as the _h_o_s_t_n_a_m_e option, - the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d - _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e - _(_t_h_e _n_e_x_t_-_s_e_r_v_e_r 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: - - 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; } - } - - group { - filename "Xncd19c"; - next-server ncd-booter; +Headers, Environments, and Macros dhcpd.conf(5) + spawn with agent.circuit-id; + lease limit 4; + } - 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 ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss + 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. + +RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS + TTTThhhheeee _s_h_a_r_e_d-_n_e_t_w_o_r_k ssssttttaaaatttteeeemmmmeeeennnntttt + + sssshhhhaaaarrrreeeedddd----nnnneeeettttwwwwoooorrrrkkkk _n_a_m_e {{{{ + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }}}} + + The _s_h_a_r_e_d-_n_e_t_w_o_r_k 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 _s_h_a_r_e_d-_n_e_t_w_o_r_k statement. Parameters specified in + the _s_h_a_r_e_d-_n_e_t_w_o_r_k 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. + + _N_a_m_e 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. + + TTTThhhheeee _s_u_b_n_e_t ssssttttaaaatttteeeemmmmeeeennnntttt + + ssssuuuubbbbnnnneeeetttt _s_u_b_n_e_t-_n_u_m_b_e_r nnnneeeettttmmmmaaaasssskkkk _n_e_t_m_a_s_k {{{{ + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + + + +SunOS 5.6 Last change: 8 -dhcpd.conf(5) dhcpd.conf(5) + +Headers, Environments, and Macros 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; + }}}} - 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; } - } + The _s_u_b_n_e_t 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 _r_a_n_g_e declaration. -AADDDDRREESSSS PPOOOOLLSS - The ppooooll 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: + The _s_u_b_n_e_t-_n_u_m_b_e_r should be an IP address or domain name + which resolves to the subnet number of the subnet being + described. The _n_e_t_m_a_s_k 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. - subnet 10.0.0.0 netmask 255.255.255.0 { - option routers 10.0.0.254; + 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. - # 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; + TTTThhhheeee _r_a_n_g_e ssssttttaaaatttteeeemmmmeeeennnntttt + + rrrraaaannnnggggeeee [ ddddyyyynnnnaaaammmmiiiicccc----bbbboooooooottttpppp ] _l_o_w-_a_d_d_r_e_s_s [ + + For any subnet on which addresses will be assigned dynami- + cally, there must be at least one _r_a_n_g_e 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 _r_a_n_g_e statement is declared. The + _d_y_n_a_m_i_c-_b_o_o_t_p 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, + _h_i_g_h-_a_d_d_r_e_s_s can be omitted. + + TTTThhhheeee _h_o_s_t ssssttttaaaatttteeeemmmmeeeennnntttt + + hhhhoooosssstttt _h_o_s_t_n_a_m_e { + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }}}} + + There must be at least one hhhhoooosssstttt statement for every BOOTP + client that is to be served. hhhhoooosssstttt 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 + + + +SunOS 5.6 Last change: 9 + + + + + + +Headers, Environments, and Macros dhcpd.conf(5) + + + + address may be specified in the _f_i_x_e_d-_a_d_d_r_e_s_s parameter, or + more than one hhhhoooosssstttt statement may be specified. + + If client-specific boot parameters must change based on the + network to which the client is attached, then multiple hhhhoooosssstttt + 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 hhhhoooosssstttt statement must be specified without a + ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss clause. _h_o_s_t_n_a_m_e should be a name identifying + the host. If a _h_o_s_t_n_a_m_e option is not specified for the + host, _h_o_s_t_n_a_m_e is used. + + _H_o_s_t declarations are matched to actual DHCP or BOOTP + clients by matching the dhcp-client-identifier option speci- + fied in the _h_o_s_t declaration to the one supplied by the + client, or, if the _h_o_s_t declaration or the client does not + provide a dhcp-client-identifier option, by matching the + _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the network + hardware address supplied by the client. BOOTP clients do + not normally provide a _d_h_c_p-_c_l_i_e_n_t-_i_d_e_n_t_i_f_i_e_r, so the + hardware address must be used for all clients that may boot + using the BOOTP protocol. + + TTTThhhheeee _g_r_o_u_p ssssttttaaaatttteeeemmmmeeeennnntttt + + ggggrrrroooouuuupppp { + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }}}} + + 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. + +RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: AAAALLLLLLLLOOOOWWWW aaaannnndddd DDDDEEEENNNNYYYY + The _a_l_l_o_w and _d_e_n_y statements can be used to control the + behaviour of dhcpd to various sorts of requests. + + TTTThhhheeee _u_n_k_n_o_w_n-_c_l_i_e_n_t_s kkkkeeeeyyyywwwwoooorrrrdddd + + aaaalllllllloooowwww uuuunnnnkkkknnnnoooowwwwnnnn----cccclllliiiieeeennnnttttssss;;;; + ddddeeeennnnyyyy uuuunnnnkkkknnnnoooowwwwnnnn----cccclllliiiieeeennnnttttssss;;;; + + The uuuunnnnkkkknnnnoooowwwwnnnn----cccclllliiiieeeennnnttttssss flag is used to tell dhcpd whether or + not to dynamically assign addresses to unknown clients. + Dynamic address assignment to unknown clients is aaaalllllllloooowwwwed by + default. + + TTTThhhheeee _b_o_o_t_p kkkkeeeeyyyywwwwoooorrrrdddd + + + + +SunOS 5.6 Last change: 10 + + + + + + +Headers, Environments, and Macros dhcpd.conf(5) + + + + aaaalllllllloooowwww bbbboooooooottttpppp;;;; + ddddeeeennnnyyyy bbbboooooooottttpppp;;;; + + The bbbboooooooottttpppp flag is used to tell dhcpd whether or not to + respond to bootp queries. Bootp queries are aaaalllllllloooowwwwed by + default. + + TTTThhhheeee _b_o_o_t_i_n_g kkkkeeeeyyyywwwwoooorrrrdddd + + aaaalllllllloooowwww bbbboooooooottttiiiinnnngggg;;;; + ddddeeeennnnyyyy bbbboooooooottttiiiinnnngggg;;;; + + The bbbboooooooottttiiiinnnngggg 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 aaaalllllllloooowwwwed, but if it is disabled for a + particular client, then that client will not be able to get + and address from the DHCP server. + +RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: PPPPAAAARRRRAAAAMMMMEEEETTTTEEEERRRRSSSS + TTTThhhheeee _d_e_f_a_u_l_t-_l_e_a_s_e-_t_i_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + + ddddeeeeffffaaaauuuulllltttt----lllleeeeaaaasssseeee----ttttiiiimmmmeeee _t_i_m_e;;;; + + _T_i_m_e 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. + + TTTThhhheeee _m_a_x-_l_e_a_s_e-_t_i_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + + mmmmaaaaxxxx----lllleeeeaaaasssseeee----ttttiiiimmmmeeee _t_i_m_e;;;; + + _T_i_m_e 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. + + TTTThhhheeee _m_i_n-_l_e_a_s_e-_t_i_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + + mmmmiiiinnnn----lllleeeeaaaasssseeee----ttttiiiimmmmeeee _t_i_m_e;;;; + + _T_i_m_e should be the minimum length in seconds that will be + assigned to a lease. + + TTTThhhheeee _m_i_n-_s_e_c_s ssssttttaaaatttteeeemmmmeeeennnntttt + + mmmmiiiinnnn----sssseeeeccccssss _s_e_c_o_n_d_s;;;; + + _S_e_c_o_n_d_s 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 + + + +SunOS 5.6 Last change: 11 + + + + + + +Headers, Environments, and Macros dhcpd.conf(5) + + + + 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. + + TTTThhhheeee _h_a_r_d_w_a_r_e ssssttttaaaatttteeeemmmmeeeennnntttt + + hhhhaaaarrrrddddwwwwaaaarrrreeee _h_a_r_d_w_a_r_e-_t_y_p_e _h_a_r_d_w_a_r_e-_a_d_d_r_e_s_s;;;; + + In order for a BOOTP client to be recognized, its network + hardware address must be declared using a _h_a_r_d_w_a_r_e clause in + the _h_o_s_t statement. _h_a_r_d_w_a_r_e-_t_y_p_e must be the name of a + physical hardware interface type. Currently, only the eeeetttthhhh---- + eeeerrrrnnnneeeetttt and ttttooookkkkeeeennnn----rrrriiiinnnngggg types are recognized, although support + for a ffffddddddddiiii hardware type (and others) would also be desir- + able. The _h_a_r_d_w_a_r_e-_a_d_d_r_e_s_s should be a set of hexadecimal + octets (numbers from 0 through ff) seperated by colons. + The _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r _D_H_C_P _c_l_i_e_n_t_s. + + TTTThhhheeee _f_i_l_e_n_a_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + + ffffiiiilllleeeennnnaaaammmmeeee """"_f_i_l_e_n_a_m_e"""";;;; + + The _f_i_l_e_n_a_m_e statement can be used to specify the name of + the initial boot file which is to be loaded by a client. + The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever + file transfer protocol the client can be expected to use to + load the file. + + TTTThhhheeee _s_e_r_v_e_r-_n_a_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + + sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee """"_n_a_m_e"""";;;; + + The _s_e_r_v_e_r-_n_a_m_e statement can be used to inform the client + of the name of the server from which it is booting. _N_a_m_e + should be the name that will be provided to the client. + + TTTThhhheeee _n_e_x_t-_s_e_r_v_e_r ssssttttaaaatttteeeemmmmeeeennnntttt + + nnnneeeexxxxtttt----sssseeeerrrrvvvveeeerrrr _s_e_r_v_e_r-_n_a_m_e;;;; + + The _n_e_x_t-_s_e_r_v_e_r statement is used to specify the host + address of the server from which the initial boot file + + + +SunOS 5.6 Last change: 12 + + + + + + +Headers, Environments, and Macros dhcpd.conf(5) + + + + (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded. + _S_e_r_v_e_r-_n_a_m_e should be a numeric IP address or a domain name. + If no _n_e_x_t-_s_e_r_v_e_r parameter applies to a given client, the + DHCP server's IP address is used. + + TTTThhhheeee _f_i_x_e_d-_a_d_d_r_e_s_s ssssttttaaaatttteeeemmmmeeeennnntttt + + ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss _a_d_d_r_e_s_s [,,,, _a_d_d_r_e_s_s ... ];;;; + + The _f_i_x_e_d-_a_d_d_r_e_s_s statement is used to assign one or more + fixed IP addresses to a client. It should only appear in a + _h_o_s_t 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 _f_i_x_e_d-_a_d_d_r_e_s_s statement are on + the network on which the client is booting, that client will + not match the _h_o_s_t declaration containing that _f_i_x_e_d-_a_d_d_r_e_s_s + statement. Each _a_d_d_r_e_s_s should be either an IP address or a + domain name which resolves to one or more IP addresses. + + TTTThhhheeee _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_c_u_t_o_f_f ssssttttaaaatttteeeemmmmeeeennnntttt + + ddddyyyynnnnaaaammmmiiiicccc----bbbboooooooottttpppp----lllleeeeaaaasssseeee----ccccuuuuttttooooffffffff _d_a_t_e;;;; + + The _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_c_u_t_o_f_f 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. + + _D_a_t_e 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. + + TTTThhhheeee _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_l_e_n_g_t_h ssssttttaaaatttteeeemmmmeeeennnntttt + + ddddyyyynnnnaaaammmmiiiicccc----bbbboooooooottttpppp----lllleeeeaaaasssseeee----lllleeeennnnggggtttthhhh _l_e_n_g_t_h;;;; + + + + + +SunOS 5.6 Last change: 13 + + + + + + +Headers, Environments, and Macros dhcpd.conf(5) + + + + The _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_l_e_n_g_t_h 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 _l_e_n_g_t_h as a number of seconds. If a client + reboots using BOOTP during the timeout period, the lease + duration is reset to _l_e_n_g_t_h, so a BOOTP client that boots + frequently enough will never lose its lease. Needless to + say, this parameter should be adjusted with extreme caution. + + TTTThhhheeee _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s ssssttttaaaatttteeeemmmmeeeennnntttt + + ggggeeeetttt----lllleeeeaaaasssseeee----hhhhoooossssttttnnnnaaaammmmeeeessss _f_l_a_g;;;; + + The _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s 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 _h_o_s_t_n_a_m_e option. If _f_l_a_g is true, + then this lookup is done for all addresses in the current + scope. By default, or if _f_l_a_g is false, no lookups are + done. + + TTTThhhheeee _u_s_e-_h_o_s_t-_d_e_c_l-_n_a_m_e_s ssssttttaaaatttteeeemmmmeeeennnntttt + + uuuusssseeee----hhhhoooosssstttt----ddddeeeeccccllll----nnnnaaaammmmeeeessss _f_l_a_g;;;; + + If the _u_s_e-_h_o_s_t-_d_e_c_l-_n_a_m_e_s 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; + } } - # 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; - } - } + is equivalent to - 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. - - - - - - 5 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - -CCLLIIEENNTT CCLLAASSSSIINNGG - 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. - - 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 aadddd - statement in the conditional's list of statements: - - 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; - } - - 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 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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 speci­ - fied as follows: - - class limited-1 { - lease limit 4; - } - - 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 _s_p_a_w_n_i_n_g _c_l_a_s_s. 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; - } - - 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 ddhhccppdd..lleeaasseess file, and the client will be classified - in this new class. Once the client has been classified, - - - - 7 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - -RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS - TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt - - sshhaarreedd--nneettwwoorrkk _n_a_m_e {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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 _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters - specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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. - - _N_a_m_e 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. - - TThhee _s_u_b_n_e_t ssttaatteemmeenntt - - ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The _s_u_b_n_e_t 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 _r_a_n_g_e declaration. - - The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name - which resolves to the subnet number of the subnet being - described. The _n_e_t_m_a_s_k should be an IP address or domain - - - - 8 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - - TThhee _r_a_n_g_e ssttaatteemmeenntt - - rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];; - - For any subnet on which addresses will be assigned dynami­ - cally, there must be at least one _r_a_n_g_e 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 _r_a_n_g_e statement is declared. The - _d_y_n_a_m_i_c_-_b_o_o_t_p 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, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted. - - TThhee _h_o_s_t ssttaatteemmeenntt - - hhoosstt _h_o_s_t_n_a_m_e { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - There must be at least one hhoosstt statement for every BOOTP - client that is to be served. hhoosstt 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 address may be specified in the _f_i_x_e_d_-_a_d_d_r_e_s_s - parameter, or more than one hhoosstt statement may be speci­ - fied. - - If client-specific boot parameters must change based on - the network to which the client is attached, then multiple - hhoosstt 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 hhoosstt statement must be specified without a - ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify­ - ing the host. If a _h_o_s_t_n_a_m_e option is not specified for - the host, _h_o_s_t_n_a_m_e is used. - - - - 9 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - _H_o_s_t declarations are matched to actual DHCP or BOOTP - clients by matching the dhcp-client-identifier option - specified in the _h_o_s_t declaration to the one supplied by - the client, or, if the _h_o_s_t declaration or the client does - not provide a dhcp-client-identifier option, by matching - the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net­ - work hardware address supplied by the client. BOOTP - clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r, - so the hardware address must be used for all clients that - may boot using the BOOTP protocol. - - TThhee _g_r_o_u_p ssttaatteemmeenntt - - ggrroouupp { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - 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. - -RREEFFEERREENNCCEE:: AALLLLOOWW aanndd DDEENNYY - The _a_l_l_o_w and _d_e_n_y statements can be used to control the - behaviour of dhcpd to various sorts of requests. - - - TThhee _u_n_k_n_o_w_n_-_c_l_i_e_n_t_s kkeeyywwoorrdd - - aallllooww uunnkknnoowwnn--cclliieennttss;; - ddeennyy uunnkknnoowwnn--cclliieennttss;; - - The uunnkknnoowwnn--cclliieennttss flag is used to tell dhcpd whether or - not to dynamically assign addresses to unknown clients. - Dynamic address assignment to unknown clients is aalllloowwed - by default. - - TThhee _b_o_o_t_p kkeeyywwoorrdd - - aallllooww bboooottpp;; - ddeennyy bboooottpp;; - - The bboooottpp flag is used to tell dhcpd whether or not to - respond to bootp queries. Bootp queries are aalllloowwed by - default. - - TThhee _b_o_o_t_i_n_g kkeeyywwoorrdd - - aallllooww bboooottiinngg;; - ddeennyy bboooottiinngg;; - - The bboooottiinngg flag is used to tell dhcpd whether or not to - respond to queries from a particular client. This keyword - - - - 10 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - only has meaning when it appears in a host declaration. - By default, booting is aalllloowwed, but if it is disabled for - a particular client, then that client will not be able to - get and address from the DHCP server. - -RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS - TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e 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. - - TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - mmaaxx--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e 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. - - TThhee _m_i_n_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - mmiinn--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the minimum length in seconds that will be - assigned to a lease. - - TThhee _m_i_n_-_s_e_c_s ssttaatteemmeenntt - - mmiinn--sseeccss _s_e_c_o_n_d_s;; - - _S_e_c_o_n_d_s 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. - - 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. - - TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt - - - - - 11 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s;; - - In order for a BOOTP client to be recognized, its network - hardware address must be declared using a _h_a_r_d_w_a_r_e clause - in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of - a physical hardware interface type. Currently, only the - eetthheerrnneett and ttookkeenn--rriinngg types are recognized, although - support for a ffddddii hardware type (and others) would also - be desirable. The _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of - hexadecimal octets (numbers from 0 through ff) seperated - by colons. The _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r - _D_H_C_P _c_l_i_e_n_t_s_. - - TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt - - ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; - - The _f_i_l_e_n_a_m_e statement can be used to specify the name of - the initial boot file which is to be loaded by a client. - The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever - file transfer protocol the client can be expected to use - to load the file. - - TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt - - sseerrvveerr--nnaammee ""_n_a_m_e"";; - - The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client - of the name of the server from which it is booting. _N_a_m_e - should be the name that will be provided to the client. - - TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt - - nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;; - - The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host - address of the server from which the initial boot file - (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded. - _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain - name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given - client, the DHCP server's IP address is used. - - TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt - - ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];; - - The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more - fixed IP addresses to a client. It should only appear in - a _h_o_s_t 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 _f_i_x_e_d_-_a_d_d_r_e_s_s - statement are on the network on which the client is boot­ - ing, that client will not match the _h_o_s_t declaration - - - - 12 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - containing that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s - should be either an IP address or a domain name which - resolves to one or more IP addresses. - - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt - - ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;; - - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f 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. - - _D_a_t_e 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. - - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt - - ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; - - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h 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 _l_e_n_g_t_h as a num­ - ber of seconds. If a client reboots using BOOTP during - the timeout period, the lease duration is reset to _l_e_n_g_t_h, - so a BOOTP client that boots frequently enough will never - lose its lease. Needless to say, this parameter should be - adjusted with extreme caution. - - TThhee _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt - - ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;; - - The _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s 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 - - - - 13 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - that address for the DHCP _h_o_s_t_n_a_m_e option. If _f_l_a_g is - true, then this lookup is done for all addresses in the - current scope. By default, or if _f_l_a_g is false, no - lookups are done. - - TThhee _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s ssttaatteemmeenntt - - uussee--hhoosstt--ddeeccll--nnaammeess _f_l_a_g;; - - If the _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s 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, - - group { - use-host-decl-names on; - - host joe { - hardware ethernet 08:00:2b:4c:29:32; - fixed-address joe.fugue.com; - } + host joe { + hardware ethernet 08:00:2b:4c:29:32; + fixed-address joe.fugue.com; + option host-name "joe"; } - is equivalent to + An _o_p_t_i_o_n _h_o_s_t-_n_a_m_e statement within a host declaration will + override the use of the name in the host declaration. - host joe { - hardware ethernet 08:00:2b:4c:29:32; - fixed-address joe.fugue.com; - option host-name "joe"; - } - An _o_p_t_i_o_n _h_o_s_t_-_n_a_m_e statement within a host declaration - will override the use of the name in the host declaration. - TThhee _a_u_t_h_o_r_i_t_a_t_i_v_e ssttaatteemmeenntt - aauutthhoorriittaattiivvee;; +SunOS 5.6 Last change: 14 - nnoott aauutthhoorriittaattiivvee;; - 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. - 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. +Headers, Environments, and Macros dhcpd.conf(5) - 14 + TTTThhhheeee _a_u_t_h_o_r_i_t_a_t_i_v_e ssssttttaaaatttteeeemmmmeeeennnntttt + aaaauuuutttthhhhoooorrrriiiittttaaaattttiiiivvvveeee;;;; + nnnnooootttt aaaauuuutttthhhhoooorrrriiiittttaaaattttiiiivvvveeee;;;; -dhcpd.conf(5) dhcpd.conf(5) + 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. + 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. - Usually, writing nnoott aauutthhoorriittaattiivvee;; 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. + Usually, writing nnnnooootttt aaaauuuutttthhhhoooorrrriiiittttaaaattttiiiivvvveeee;;;; 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. + 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. - TThhee _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e ssttaatteemmeenntt + TTTThhhheeee _u_s_e-_l_e_a_s_e-_a_d_d_r-_f_o_r-_d_e_f_a_u_l_t-_r_o_u_t_e ssssttttaaaatttteeeemmmmeeeennnntttt - uussee--lleeaassee--aaddddrr--ffoorr--ddeeffaauulltt--rroouuttee _f_l_a_g;; + uuuusssseeee----lllleeeeaaaasssseeee----aaaaddddddddrrrr----ffffoooorrrr----ddddeeeeffffaaaauuuulllltttt----rrrroooouuuutttteeee _f_l_a_g;;;; - If the _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e 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. + If the _u_s_e-_l_e_a_s_e-_a_d_d_r-_f_o_r-_d_e_f_a_u_l_t-_r_o_u_t_e 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. - TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt + TTTThhhheeee _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r ssssttttaaaatttteeeemmmmeeeennnntttt - sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;; - 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 mmuusstt 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 net­ - work interface on which the request arrived. - The usual case where the _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r 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. +SunOS 5.6 Last change: 15 - 15 +Headers, Environments, and Macros dhcpd.conf(5) -dhcpd.conf(5) dhcpd.conf(5) - Supplying a value for the dhcp-server-identifier option is - equivalent to using the server-identifier statement. + sssseeeerrrrvvvveeeerrrr----iiiiddddeeeennnnttttiiiiffffiiiieeeerrrr _h_o_s_t_n_a_m_e;;;; -RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS - DHCP option statements are documented in the ddhhccpp-- - ooppttiioonnss((55)) manual page. + 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 mmmmuuuusssstttt be an IP address + for the DHCP server, and must be reachable by all clients + served by a particular scope. -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. + 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. -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. + The usual case where the _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r 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. +RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: OOOOPPPPTTTTIIIIOOOONNNN SSSSTTTTAAAATTTTEEEEMMMMEEEENNNNTTTTSSSS + DHCP option statements are documented in the ddddhhhhccccpppp----ooooppppttttiiiioooonnnnssss((((5555)))) + manual page. +SSSSEEEEEEEE AAAALLLLSSSSOOOO + dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. +AAAAUUUUTTTTHHHHOOOORRRR + ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon under a + contract with Vixie Labs. Funding for this project was + provided by the Internet Software Consortium. Information + about the Internet Software Consortium can be found at + hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... @@ -1029,28 +1050,7 @@ AAUUTTHHOORR +SunOS 5.6 Last change: 16 - - - - - - - - - - - - - - - - - - - - - - 16 diff --git a/server/dhcpd.leases.cat5 b/server/dhcpd.leases.cat5 index f509e622..9a3b55ff 100644 --- a/server/dhcpd.leases.cat5 +++ b/server/dhcpd.leases.cat5 @@ -1,189 +1,186 @@ -dhcpd.leases(5) dhcpd.leases(5) +Headers, Environments, and Macros dhcpd.leases(5) -NNAAMMEE - dhcpd.leases - DHCP client lease database -DDEESSCCRRIIPPTTIIOONN - 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. +NNNNAAAAMMMMEEEE + 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. +DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN + The Internet Software Consortium DHCP Server keeps a per- + sistent database of leases that it has assigned. This data- + base is a free-form ASCII file containing a series of lease + declarations. Every time a lease is acquired, renewed or + released, its new value is recorded at the end of the lease + file. So if more than one declaration appears for a given + lease, the last one in the file is the current one. - 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. DDOO NNOOTT simply create a new lease - file when this happens - if you do, you will lose all your - old bindings, and chaos will ensue. Instead, rename - /var/db/dhcpd.leases~ to /var/db/dhcpd.leases, restoring - the old, valid lease file, and then start dhcpd. This - guarantees that a valid lease file will be restored. + 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. -FFOORRMMAATT - Lease descriptions are stored in a format that is parsed - by the same recursive descent parser used to read the - ddhhccppdd..ccoonnff((55)) and ddhhcclliieenntt..ccoonnff((55)) files. Currently, the - only declaration that is used in the dhcpd.leases file is - the lleeaassee 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. DDDDOOOO NNNNOOOOTTTT simply create a new lease file + when this happens - if you do, you will lose all your old + bindings, and chaos will ensue. Instead, rename + /etc/dhcpd.leases~ to /etc/dhcpd.leases, restoring the old, + valid lease file, and then start dhcpd. This guarantees + that a valid lease file will be restored. - lleeaassee _i_p_-_a_d_d_r_e_s_s {{ _s_t_a_t_e_m_e_n_t_s_._._. }} +FFFFOOOORRRRMMMMAAAATTTT + Lease descriptions are stored in a format that is parsed by + the same recursive descent parser used to read the + ddddhhhhccccppppdddd....ccccoooonnnnffff((((5555)))) and ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff((((5555)))) files. Currently, the + only declaration that is used in the dhcpd.leases file is + the lllleeeeaaaasssseeee declaration. - Each lease declaration include the single IP address that - has been leased to the client. The statements within the - braces define the duration of the lease and to whom it is - assigned. + lllleeeeaaaasssseeee _i_p-_a_d_d_r_e_s_s {{{{ _s_t_a_t_e_m_e_n_t_s... }}}} - 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) - ssttaarrttss _d_a_t_e;; - eennddss _d_a_t_e;; - Dates are specified as follows: - _w_e_e_k_d_a_y _y_e_a_r//_m_o_n_t_h//_d_a_y _h_o_u_r::_m_i_n_u_t_e::_s_e_c_o_n_d + ssssttttaaaarrrrttttssss _d_a_t_e;;;; + eeeennnnddddssss _d_a_t_e;;;; - The weekday is present to make it easy for a human to tell - 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 ddaattee --uu. + _w_e_e_k_d_a_y _y_e_a_r////_m_o_n_t_h////_d_a_y _h_o_u_r::::_m_i_n_u_t_e::::_s_e_c_o_n_d - The MAC address of the network interface that was used to - acquire the lease is recorded with the hhaarrddwwaarree 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. - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _m_a_c_-_a_d_d_r_e_s_s;; + Lease times are specified in Greenwich Mean Time (GMT), not + in the local time zone. Since Greenwich is actually on + Daylight Savings Time part of the year, there is probably + nowhere in the world where the times recorded on a lease are + always the same as wall clock times. On a unix machine, one + can often figure out the current time in GMT by typing ddddaaaatttteeee + ----uuuu. - The MAC address is specified as a series of hexadecimal - octets, seperated by colons. + The MAC address of the network interface that was used to + acquire the lease is recorded with the hhhhaaaarrrrddddwwwwaaaarrrreeee statement: - If the client used a client identifier to acquire its - address, the client identifier is recorded using the uuiidd - statement: + hhhhaaaarrrrddddwwwwaaaarrrreeee _h_a_r_d_w_a_r_e-_t_y_p_e _m_a_c-_a_d_d_r_e_s_s;;;; - uuiidd _c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r;; + The MAC address is specified as a series of hexadecimal + octets, seperated by colons. - The client identifier is recorded as a series of hexadeci­ - 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 uuuuiiiidddd + statement: - If the client sends a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e - option, as specified in some versions of the DHCP-DNS - Interaction draft, that hostname is recorded using the - cclliieenntt--hhoossttnnaammee statement. + uuuuiiiidddd _c_l_i_e_n_t-_i_d_e_n_t_i_f_i_e_r;;;; - cclliieenntt--hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; + The client identifier is recorded as a series of hexadecimal + octets, regardless of whether the client specifies an ASCII + string or uses the newer hardware type/MAC address format. - If the client sends its hostname using the _H_o_s_t_n_a_m_e - option, as Windows 95 does, it is recorded using the + If the client sends a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e + option, as specified in some versions of the DHCP-DNS + Interaction draft, that hostname is recorded using the + cccclllliiiieeeennnntttt----hhhhoooossssttttnnnnaaaammmmeeee statement. + cccclllliiiieeeennnntttt----hhhhoooossssttttnnnnaaaammmmeeee """"_h_o_s_t_n_a_m_e"""";;;; - 2 +SunOS 5.6 Last change: 2 -dhcpd.leases(5) dhcpd.leases(5) - hhoossttnnaammee statement. - hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; - The DHCP server may determine that a lease has been mis­ - used in some way, either because a client that has been - assigned a lease NAKs it, or because the server's own - attempt to see if an address is in use prior to reusing it - reveals that the address is in fact already in use. In - that case, the aabbaannddoonneedd statement will be used to indi­ - cate that the lease should not be reassigned. +Headers, Environments, and Macros dhcpd.leases(5) - aabbaannddoonneedd;; - Abandoned leases are reclaimed automatically. When a - client asks for a new address, and the server finds that - there are no new addresses, it checks to see if there are - any abandoned leases, and allocates the least recently - abandoned lease. The standard mechanisms for checking - for lease address conflicts are still followed, so if the - abandoned lease's IP address is still in use, it will be - reabandoned. - If a client rreeqquueessttss an abandoned address, the server - 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 _H_o_s_t_n_a_m_e option, + as Windows 95 does, it is recorded using the hhhhoooossssttttnnnnaaaammmmeeee state- + ment. -FFIILLEESS - //vvaarr//ddbb//ddhhccppdd..lleeaasseess + hhhhoooossssttttnnnnaaaammmmeeee """"_h_o_s_t_n_a_m_e"""";;;; -SSEEEE AALLSSOO - 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 aaaabbbbaaaannnn---- + ddddoooonnnneeeedddd statement will be used to indicate that the lease + should not be reassigned. -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon 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 hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. + aaaabbbbaaaannnnddddoooonnnneeeedddd;;;; + Abandoned leases are reclaimed automatically. When a + client asks for a new address, and the server finds that + there are no new addresses, it checks to see if there are + any abandoned leases, and allocates the least recently aban- + doned lease. The standard mechanisms for checking for + lease address conflicts are still followed, so if the aban- + doned lease's IP address is still in use, it will be reaban- + doned. + If a client rrrreeeeqqqquuuueeeessssttttssss an abandoned address, the server + assumes that the reason the address was abandoned was that + the lease file was corrupted, and that the client is the + machine that responded when the lease was probed, causing it + to be abandoned. In that case, the address is immediately + assigned to the client. +FFFFIIIILLLLEEEESSSS + ////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss +SSSSEEEEEEEE AAAALLLLSSSSOOOO + dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, RFC2131. +AAAAUUUUTTTTHHHHOOOORRRR + ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon under a + contract with Vixie Labs. Funding for this project was + provided by the Internet Software Corporation. Information + about the Internet Software Consortium can be found at + hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... @@ -193,6 +190,9 @@ AAUUTTHHOORR - 3 + + +SunOS 5.6 Last change: 3 +