Unix/Linux Go Back    

RedHat 9 (Linux i386) - man page for dhclient.conf (redhat section 5)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

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

       dhclient.conf - DHCP client configuration file

       The dhclient.conf file contains configuration information for dhclient, the Internet Soft-
       ware 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 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  informa-
       tion,  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 behaviour of the client need not be configured by the user.	If no timing con-
       figuration is provided by the user, a fairly reasonable timing behaviour will be  used  by
       default - one which results in fairly timely updates without placing an inordinate load on
       the server.

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

       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
       lockstep.   The backoff-cutoff statement determines the maximum amount of  time	that  the
       client is allowed to back off.	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  server  requests  the  subnet-mask, broadcast-address, time-offset, routers, domain-
       name, domain-name-servers, host-name, nis-domain, nis-servers, and ntp-servers 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.

       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 behaviour 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 behaviour will be

       The lease declaration

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

       The DHCP client may decide after some period of time (see PROTOCOL TIMING) decide that  it
       is  not going to succeed in contacting a server.   At that time, it consults its own data-
       base 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 service, 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 te interface.

       The  dhcp  client  automatically  declares this parameter if it used 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
       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 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 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 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.

	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 seperate 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  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.

       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 "/etc/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 the Internet Software Consortium.  Information about the Internet
       Software Consortium can be found at http://www.isc.org.

Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 02:21 AM.