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:

Linux 2.6 - man page for dhclient.conf (linux 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 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 300 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, 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

	[ also ] request [ [ option-space . ] 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  and	host-name  options.   Note  that if you enter a 'request'
       statement, you over-ride this default and these options will not be requested.

       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:


       In  most  cases,  it is desirable to simply add one option to the request list which is of
       interest to the client in question.  In this case, it is best to 'also request' the  addi-
       tional options:

	    also request domain-search, dhcp6.sip-servers-addresses;

       The require statement

	[ also ] require [ [ option-space . ] 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.	There  is
       no default require list.

	    require name-servers;

	    interface eth0 {
		 also require domain-search;


	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 does not yet have a default DHCPv6 Option Request Option (ORO), nor has it been
       integrated with the 'request' and 'require' syntax above.  It is neccessary  to	configure
       an ORO then.

	 send dhcp6.oro 1, 2, 7, 12, 13, 23, 24, 39;

       The  above  ORO	will  request both identifiers (server, client), the preference, unicast,
       nameservers, domain-search, and FQDN(v6) options.

       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.

       Note that everything in this section is true whether you are using DHCPv4 or DHCPv6.   The
       exact same syntax is used for both.

       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;
	 also request fqdn, dhcp6.fqdn;

       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.

       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) 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 in one of two ways.	The software will output times in these two  for-
       mats depending on if the db-time-format configuration parameter has been set to default or

       If it is set to default, then date values appear 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.

       If the db-time-format configuration was set to local, then the date values appear as  fol-

	epoch	<seconds-since-epoch>;	 #  <day-name>	<month-name>  <day-number>  <hours>:<min-
       utes>:<seconds> <year>

       The seconds-since-epoch is as according to the system's local clock (often referred to  as
       "unix  time").  The # symbol supplies a comment that describes what actual time this is as
       according to the system's configured timezone, at the time the value was written.   It  is
       provided  only  for  human  inspection,	the  epoch time is the only recommended value for
       machine inspection.

       Note that when defining a static lease, one may use either time	format	one  wishes,  and
       need not include the comment or values after it.

       If the time is infinite in duration, then the date is never instead of an actual date.

	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.

	db-time-format [ default | local ] ;

       The db-time-format option determines which of two output methods  are  used  for  printing
       times  in  leases  files.   The default format provides day-and-time in UTC, whereas local
       uses a seconds-since-epoch to store the time value, and helpfully places a local  timezone
       time  in a comment on the same line.  The formats are described in detail in this manpage,
       whithin the LEASE DECLARATIONS section.

	reject cidr-ip-address [, ... cidr-ip-address ] ;

       The reject statement causes the DHCP client to reject offers  from  servers  whose  server
       identifier matches any of the specified hosts or subnets.  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.

       The  cidr-ip-address  configuration  type is of the form ip-address[/prefixlen], where ip-
       address is a dotted quad IP address, and prefixlen is the CIDR prefix length of	the  sub-
       net,  counting  the  number  of significant bits in the netmask starting from the leftmost
       end.  Example configuration syntax:


The above example would cause offers from any server identifier in the entire RFC 1918 ";Class  C"
network, or the specific single address, to be rejected.

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

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 - essen-
tially, 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 information.

 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	DHCPDISCOVER  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 300;
       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),  dhcp-eval(5),	dhclient.leases(5),  dhcpd(8),	dhcpd.conf(5),	 RFC2132,

       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 https://www.isc.org.


All times are GMT -4. The time now is 09:03 PM.

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

Not a Forum Member?
Forgot Password?