Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

NetBSD 6.1.5 - man page for dhclient.conf (netbsd section 5)

dhclient.conf(5)								 dhclient.conf(5)

       dhclient.conf - DHCP client configuration file

       The  dhclient.conf file contains configuration information for dhclient, the Internet Sys-
       tems Consortium DHCP Client.

       The dhclient.conf file is a free-form ASCII text file.	It is parsed  by  the  recursive-
       descent	parser	built  into  dhclient.	 The file may contain extra tabs and newlines for
       formatting purposes.  Keywords in the file are case-insensitive.   Comments may be  placed
       anywhere within the file (except within quotes).   Comments begin with the # character and
       end at the end of the line.

       The dhclient.conf file can be used to configure the behavior of the client in a wide vari-
       ety  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 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  timing  behavior of the client need not be configured by the user.	If no timing con-
       figuration is provided by the user, a fairly reasonable timing behavior will  be  used  by
       default - one which results in fairly timely updates without placing an inordinate load on
       the server.

       The following statements can be used to adjust the timing behavior of the DHCP  client  if
       required, however:

       The timeout statement

       timeout time ;

       The  timeout  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.

       The retry statement

	retry time;

       The  retry  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 select-timeout statement

	select-timeout time;

       It  is possible (some might say desirable) for there to be more than one DHCP server serv-
       ing 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).

       The select-timeout 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 select-timeout has expired,
       the client will accept the first offer that arrives.

       By default, the select-timeout is zero seconds - that is, the client will take  the  first
       offer it sees.

       The reboot statement

	reboot time;

       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 reboot state-
       ment 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.

       The backoff-cutoff statement

	backoff-cutoff time;

       The client uses an exponential backoff algorithm with some randomness,  so  that  if  many
       clients try to configure themselves at the same time, they will not make their requests in
       lock-step.   The backoff-cutoff statement determines the maximum amount of time	that  the
       client  is allowed to back off, the actual value will be evaluated randomly between 1/2 to
       1 1/2 times the time specified.	 It defaults to two minutes.

       The initial-interval statement

	initial-interval time;

       The initial-interval 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.

       The DHCP protocol allows the client to request that the server send it  specific  informa-
       tion,  and not send it other information that it is not prepared to accept.   The protocol
       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 DHCP Options.  DHCP Options
       are defined in

       The request statement

	request [ option ] [, ... option ];

       The  request  statement	causes	the  client  to request that any server responding to the
       client send the client its values for the  specified  options.	 Only  the  option  names
       should  be  specified  in the request statement - not option parameters.   By default, the
       DHCP client requests the subnet-mask,  broadcast-address,  time-offset,	routers,  domain-
       name, domain-name-servers and host-name options.

       In some cases, it may be desirable to send no parameter request list at all.   To do this,
       simply write the request statement but specify no parameters:


       The require statement

	require [ option ] [, ... option ];

       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.

       The send statement

	send { [ option declaration ] [, ... option declaration ]}

       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  dhcp-options(5).
       Options	that  are  always  sent in the DHCP protocol should not be specified here, except
       that the client can specify a requested-lease-time 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.

       The  client  now  has  some  very  limited  support  for doing DNS updates when a lease is
       acquired.   This is prototypical, and probably doesn't do what you want.    It  also  only
       works if you happen to have control over your DNS server, which isn't very likely.

       To  make  it  work,  you  have  to  declare  a  key  and  zone  as in the DHCP server (see
       dhcpd.conf(5) for details).   You also need to configure the fqdn option on the client, as

	 send fqdn.fqdn "grosse.fugue.com.";
	 send fqdn.encoded on;
	 send fqdn.server-update off;

       The  fqdn.fqdn  option  MUST  be  a  fully-qualified domain name.   You MUST define a zone
       statement for the zone to be updated.   The fqdn.encoded option may need to be set  to  on
       or off, depending on the DHCP server you are using.

       The do-forward-updates statement

	do-forward-updates [ flag ] ;

       If  you	want  to do DNS updates in the DHCP client script (see dhclient-script(8)) rather
       than having the DHCP client do the update directly (for example, if you want to use SIG(0)
       authentication,	which  is not supported directly by the DHCP client, you can instruct the
       client not to do the update using the do-forward-updates statement.   Flag should be  true
       if  you want the DHCP client to do the update, and false if you don't want the DHCP client
       to do the update.   By default, the DHCP client will do the DNS update.

       The omapi port statement

	omapi port [ port ] ;

       The omapi port statement causes the DHCP client to set up an OMAPI listener on the  speci-
       fied port.   Only one such port should be specified.  The OMAPI listener will be sensitive
       to connections from any IP address, so it is important to also set up an OMAPI key to pro-
       tect the client from unauthorized changes.

       The omapi key statement

	omapi key [  key-id  ] ;

       The  omapi  key	statement  causes the DHCP client to check any incoming OMAPI messages to
       make sure that they are signed by the specified key.   If a message is not signed by  this
       key, it is rejected with an "invalid key" error.

       In some cases, a client may receive option data from the server which is not really appro-
       priate for that client, or may not receive information that it needs, and for which a use-
       ful  default  value  exists.    It may also receive information which is useful, but which
       needs to be supplemented with local information.   To handle these needs,  several  option
       modifiers are available.

       The default statement

	default [ option declaration ] ;

       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 default statement.

       The supersede statement

	supersede [ option declaration ] ;

       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  super-
       sede statement.

       The prepend statement

	prepend [ option declaration ] ;

       If for some set of options the client should use a value you supply, and then use the val-
       ues supplied by the server, if any, these values can be defined in the prepend  statement.
       The  prepend  statement can only be used for options which allow more than one value to be
       given.	This restriction is not enforced - if you ignore it, the behavior will be  unpre-

       The append statement

	append [ option declaration ] ;

       If  for some set of options the client should first use the values supplied by the server,
       if any, and then use values you supply, these values can be defined in the  append  state-
       ment.	The append statement can only be used for options which allow more than one value
       to be given.   This restriction is not enforced - if you ignore it, the behavior  will  be

       The lease declaration

	lease { lease-declaration [ ... lease-declaration ] }

       The  DHCP client may decide after some period of time (see PROTOCOL TIMING) 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  fixed
       leases  in the client configuration file for networks where there is no DHCP or BOOTP ser-
       vice, so that the client can still automatically configure its  address.    This  is  done
       with the lease 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 declaration statements, followed by a right curly brace.	 The fol-
       lowing lease declarations are possible:


       The bootp statement is used to indicate that the lease was acquired using the BOOTP proto-
       col  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.

	interface "string";

       The interface 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 specified, although this is not required.

	fixed-address ip-address;

       The fixed-address 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

	filename "string";

       The filename 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.

	server-name "string";

       The  server-name  statement  specifies  the name of the boot server name to use.   This is
       also not used by the standard client configuration script.

	option option-declaration;

       The option 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 predefined lease is used.

	script "script-name";

       The script 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 identified.	For more information, see dhclient-script(8).

	vendor option space "name";

       The vendor option space statement is used to specify which option space should be used for
       decoding the vendor-encapsulate-options option if one is received.  The	dhcp-vendor-iden-
       tifier  can  be	used to request a specific class of vendor options from the server.   See
       dhcp-options(5) for details.

	medium "media setup";

       The medium statement can be used on systems where network interfaces cannot  automatically
       determine  the  type  of network 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 the interface.

       The dhcp client automatically declares this parameter if it uses a  media  type	(see  the
       media  statement)  when configuring the interface in order to obtain a lease.  This state-
       ment should be used in predefined leases only if the network interface requires media type

	renew date;

	rebind date;

	expire date;

       The  renew statement defines the time at which the dhcp client should begin trying to con-
       tact its server to renew a lease that it is using.   The rebind statement defines the time
       at  which the dhcp client should begin to try to contact any dhcp server in order to renew
       its lease.   The expire 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:

	<weekday> <year>/<month>/<day> <hour>:<minute>:<second>

       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  prede-
       fined  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.

	alias {  declarations ... }

       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 Sys-
       tems 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 alias 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  declaration for the IP alias address, and a subnet-mask option declaration.
       A medium statement should never be included in an alias declaration.

	reject ip-address;

       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 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 "name" { declarations ...  }

       A  client with more than one network interface may require different behavior 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 param-
       eters will then be used only for the interface that matches the specified  name.    Inter-
       faces for which there is no interface declaration will use the parameters declared outside
       of any interface declaration, or the default settings.

       Note well: ISC dhclient only maintains one list of interfaces, which is either  determined
       at startup from command line arguments, or otherwise is autodetected.  If you supplied the
       list of interfaces on the command line, this  configuration  clause  will  add  the  named
       interface  to  the  list in such a way that will cause it to be configured by DHCP.  Which
       may not be the result you had intended.	This is an undesirable side effect that  will  be
       addressed in a future release.

	pseudo "name" "real-name" { declarations ...  }

       Under  some circumstances it can be useful to declare a pseudo-interface and have the DHCP
       client acquire a configuration for that interface.  Each interface that the DHCP client is
       supporting  normally has a DHCP client state machine running on it to acquire and maintain
       its lease.  A pseudo-interface is just another state  machine  running  on  the	interface
       named real-name, with its own lease and its own state.	If you use this feature, you must
       provide a client identifier for both the pseudo-interface and the  actual  interface,  and
       the  two  identifiers  must be different.   You must also provide a separate client script
       for the pseudo-interface to do what you want with the IP address.   For example:

	    interface "ep0" {
		 send dhcp-client-identifier "my-client-ep0";
	    pseudo "secondary" "ep0" {
		 send dhcp-client-identifier "my-client-ep0-secondary";
		 script "/etc/dhclient-secondary";

       The client script for the pseudo-interface should not configure the interface up or down -
       essentially,  all  it  needs  to  handle are the states where a lease has been acquired or
       renewed, and the states where a lease  has  expired.    See  dhclient-script(8)	for  more

	media "media setup" [ , "media setup", ... ];

       The  media 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  DHCPDIS-
       COVER  and  DHCPOFFER  packets).   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.

       The following configuration file is used on a laptop running NetBSD 1.3.   The laptop  has
       an  IP  alias of, and has one interface, ep0 (a 3Com 3C589C).   Booting inter-
       vals 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

       timeout 60;
       retry 60;
       reboot 10;
       select-timeout 5;
       initial-interval 2;

       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;
	   request subnet-mask, broadcast-address, time-offset, routers,
		domain-name, domain-name-servers, host-name;
	   require subnet-mask, domain-name-servers;
	   script "CLIENTBINDIR/dhclient-script";
	   media "media 10baseT/UTP", "media 10base2/BNC";

       alias {
	 interface "ep0";
	 option subnet-mask;
       This is a very complicated dhclient.conf file - in general, yours should be much  simpler.
       In  many  cases, it's sufficient to just create an empty dhclient.conf file - the defaults
       are usually fine.

       dhcp-options(5), dhclient.leases(5), dhcpd(8), dhcpd.conf(5), RFC2132, RFC2131.

       dhclient(8) was written by Ted Lemon under a contract with Vixie Labs.	Funding for  this
       project	was  provided by Internet Systems Consortium.  Information about Internet Systems
       Consortium can be found at http://www.isc.org.


All times are GMT -4. The time now is 08:45 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password

Not a Forum Member?
Forgot Password?