Annotation of embedaddon/dhcp/client/dhclient.conf.5, revision 1.1
1.1 ! misho 1: .\" $Id: dhclient.conf.5,v 1.22.64.7.6.1 2011-04-21 15:01:23 tomasz Exp $
! 2: .\"
! 3: .\" Copyright (c) 2009-2011 by Internet Systems Consortium, Inc. ("ISC")
! 4: .\" Copyright (c) 2004,2007 by Internet Systems Consortium, Inc. ("ISC")
! 5: .\" Copyright (c) 1996-2003 by Internet Software Consortium
! 6: .\"
! 7: .\" Permission to use, copy, modify, and distribute this software for any
! 8: .\" purpose with or without fee is hereby granted, provided that the above
! 9: .\" copyright notice and this permission notice appear in all copies.
! 10: .\"
! 11: .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
! 12: .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
! 13: .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
! 14: .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
! 15: .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
! 16: .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
! 17: .\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
! 18: .\"
! 19: .\" Internet Systems Consortium, Inc.
! 20: .\" 950 Charter Street
! 21: .\" Redwood City, CA 94063
! 22: .\" <info@isc.org>
! 23: .\" https://www.isc.org/
! 24: .\"
! 25: .\" This software has been written for Internet Software Consortium
! 26: .\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
! 27: .\"
! 28: .\" Support and other services are available for ISC products - see
! 29: .\" https://www.isc.org for more information or to learn more about ISC.
! 30: .\"
! 31: .TH dhclient.conf 5
! 32: .SH NAME
! 33: dhclient.conf - DHCP client configuration file
! 34: .SH DESCRIPTION
! 35: The dhclient.conf file contains configuration information for
! 36: .IR dhclient,
! 37: the Internet Systems Consortium DHCP Client.
! 38: .PP
! 39: The dhclient.conf file is a free-form ASCII text file. It is parsed by
! 40: the recursive-descent parser built into dhclient. The file may contain
! 41: extra tabs and newlines for formatting purposes. Keywords in the file
! 42: are case-insensitive. Comments may be placed anywhere within the
! 43: file (except within quotes). Comments begin with the # character and
! 44: end at the end of the line.
! 45: .PP
! 46: The dhclient.conf file can be used to configure the behaviour of the
! 47: client in a wide variety of ways: protocol timing, information
! 48: requested from the server, information required of the server,
! 49: defaults to use if the server does not provide certain information,
! 50: values with which to override information provided by the server, or
! 51: values to prepend or append to information provided by the server.
! 52: The configuration file can also be preinitialized with addresses to
! 53: use on networks that don't have DHCP servers.
! 54: .SH PROTOCOL TIMING
! 55: The timing behaviour of the client need not be configured by the user.
! 56: If no timing configuration is provided by the user, a fairly
! 57: reasonable timing behaviour will be used by default - one which
! 58: results in fairly timely updates without placing an inordinate load on
! 59: the server.
! 60: .PP
! 61: The following statements can be used to adjust the timing behaviour of
! 62: the DHCP client if required, however:
! 63: .PP
! 64: .I The
! 65: .B timeout
! 66: .I statement
! 67: .PP
! 68: .B timeout
! 69: .I time
! 70: .B ;
! 71: .PP
! 72: The
! 73: .I timeout
! 74: statement determines the amount of time that must pass between the
! 75: time that the client begins to try to determine its address and the
! 76: time that it decides that it's not going to be able to contact a
! 77: server. By default, this timeout is sixty seconds. After the
! 78: timeout has passed, if there are any static leases defined in the
! 79: configuration file, or any leases remaining in the lease database that
! 80: have not yet expired, the client will loop through these leases
! 81: attempting to validate them, and if it finds one that appears to be
! 82: valid, it will use that lease's address. If there are no valid
! 83: static leases or unexpired leases in the lease database, the client
! 84: will restart the protocol after the defined retry interval.
! 85: .PP
! 86: .I The
! 87: .B retry
! 88: .I statement
! 89: .PP
! 90: \fBretry \fItime\fR\fB;\fR
! 91: .PP
! 92: The
! 93: .I retry
! 94: statement determines the time that must pass after the client has
! 95: determined that there is no DHCP server present before it tries again
! 96: to contact a DHCP server. By default, this is five minutes.
! 97: .PP
! 98: .I The
! 99: .B select-timeout
! 100: .I statement
! 101: .PP
! 102: \fBselect-timeout \fItime\fR\fB;\fR
! 103: .PP
! 104: It is possible (some might say desirable) for there to be more than
! 105: one DHCP server serving any given network. In this case, it is
! 106: possible that a client may be sent more than one offer in response to
! 107: its initial lease discovery message. It may be that one of these
! 108: offers is preferable to the other (e.g., one offer may have the
! 109: address the client previously used, and the other may not).
! 110: .PP
! 111: The
! 112: .I select-timeout
! 113: is the time after the client sends its first lease discovery request
! 114: at which it stops waiting for offers from servers, assuming that it
! 115: has received at least one such offer. If no offers have been
! 116: received by the time the
! 117: .I select-timeout
! 118: has expired, the client will accept the first offer that arrives.
! 119: .PP
! 120: By default, the select-timeout is zero seconds - that is, the client
! 121: will take the first offer it sees.
! 122: .PP
! 123: .I The
! 124: .B reboot
! 125: .I statement
! 126: .PP
! 127: \fBreboot \fItime\fR\fB;\fR
! 128: .PP
! 129: When the client is restarted, it first tries to reacquire the last
! 130: address it had. This is called the INIT-REBOOT state. If it is
! 131: still attached to the same network it was attached to when it last
! 132: ran, this is the quickest way to get started. The
! 133: .I reboot
! 134: statement sets the time that must elapse after the client first tries
! 135: to reacquire its old address before it gives up and tries to discover
! 136: a new address. By default, the reboot timeout is ten seconds.
! 137: .PP
! 138: .I The
! 139: .B backoff-cutoff
! 140: .I statement
! 141: .PP
! 142: \fBbackoff-cutoff \fItime\fR\fB;\fR
! 143: .PP
! 144: The client uses an exponential backoff algorithm with some randomness,
! 145: so that if many clients try to configure themselves at the same time,
! 146: they will not make their requests in lockstep. The
! 147: .I backoff-cutoff
! 148: statement determines the maximum amount of time that the client is
! 149: allowed to back off, the actual value will be evaluated randomly between
! 150: 1/2 to 1 1/2 times the \fItime\fR specified. It defaults to two minutes.
! 151: .PP
! 152: .I The
! 153: .B initial-interval
! 154: .I statement
! 155: .PP
! 156: \fBinitial-interval \fItime\fR\fB;\fR
! 157: .PP
! 158: The
! 159: .I initial-interval
! 160: statement sets the amount of time between the first attempt to reach a
! 161: server and the second attempt to reach a server. Each time a message
! 162: is sent, the interval between messages is incremented by twice the
! 163: current interval multiplied by a random number between zero and one.
! 164: If it is greater than the backoff-cutoff amount, it is set to that
! 165: amount. It defaults to ten seconds.
! 166: .PP
! 167: .I The initial-delay
! 168: .I statement
! 169: .PP
! 170: \fBinitial-delay \fItime\fR\fB;\fR
! 171: .PP
! 172: .I initial-delay
! 173: parameter sets the maximum time client can wait after start before
! 174: commencing first transmission.
! 175: According to RFC2131 Section 4.4.1, client should wait a random time between
! 176: startup and the actual first transmission. Previous versions of ISC DHCP
! 177: client used to wait random time up to 5 seconds, but that was unwanted
! 178: due to impact on startup time. As such, new versions have the default
! 179: initial delay set to 0. To restore old behavior, please set initial-delay
! 180: to 5.
! 181: .SH LEASE REQUIREMENTS AND REQUESTS
! 182: The DHCP protocol allows the client to request that the server send it
! 183: specific information, and not send it other information that it is not
! 184: prepared to accept. The protocol also allows the client to reject
! 185: offers from servers if they don't contain information the client
! 186: needs, or if the information provided is not satisfactory.
! 187: .PP
! 188: There is a variety of data contained in offers that DHCP servers send
! 189: to DHCP clients. The data that can be specifically requested is what
! 190: are called \fIDHCP Options\fR. DHCP Options are defined in
! 191: \fBdhcp-options(5)\fR.
! 192: .PP
! 193: .I The
! 194: .B request
! 195: .I statement
! 196: .PP
! 197: \fB[ also ] request [ [ \fIoption-space\fR . ] \fIoption\fR ] [\fB,\fI ... ]\fB;\fR
! 198: .PP
! 199: The request statement causes the client to request that any server
! 200: responding to the client send the client its values for the specified
! 201: options. Only the option names should be specified in the request
! 202: statement - not option parameters. By default, the DHCPv4 client
! 203: requests the subnet-mask, broadcast-address, time-offset, routers,
! 204: domain-name, domain-name-servers and host-name options while the DHCPv6
! 205: client requests the dhcp6 name-servers and domain-search options. Note
! 206: that if you enter a \'request\' statement, you over-ride these defaults
! 207: and these options will not be requested.
! 208: .PP
! 209: In some cases, it may be desirable to send no parameter request list
! 210: at all. To do this, simply write the request statement but specify
! 211: no parameters:
! 212: .PP
! 213: .nf
! 214: request;
! 215: .fi
! 216: .PP
! 217: In most cases, it is desirable to simply add one option to the request
! 218: list which is of interest to the client in question. In this case, it
! 219: is best to \'also request\' the additional options:
! 220: .PP
! 221: .nf
! 222: also request domain-search, dhcp6.sip-servers-addresses;
! 223: .fi
! 224: .PP
! 225: .I The
! 226: .B require
! 227: .I statement
! 228: .PP
! 229: \fB[ also ] require [ [ \fIoption-space\fR . ] \fIoption\fR ] [\fB,\fI ... ]\fB;\fR
! 230: .PP
! 231: The require statement lists options that must be sent in order for an
! 232: offer to be accepted. Offers that do not contain all the listed
! 233: options will be ignored. There is no default require list.
! 234: .PP
! 235: .nf
! 236: require name-servers;
! 237:
! 238: interface eth0 {
! 239: also require domain-search;
! 240: }
! 241: .PP
! 242: .I The
! 243: .B send
! 244: .I statement
! 245: .PP
! 246: \fBsend { [ \fIoption declaration\fR ]
! 247: [\fB,\fI ... \fIoption declaration\fR ]\fB}\fR
! 248: .PP
! 249: The send statement causes the client to send the specified options to
! 250: the server with the specified values. These are full option
! 251: declarations as described in \fBdhcp-options(5)\fR. Options that are
! 252: always sent in the DHCP protocol should not be specified here, except
! 253: that the client can specify a requested \fBdhcp-lease-time\fR option other
! 254: than the default requested lease time, which is two hours. The other
! 255: obvious use for this statement is to send information to the server
! 256: that will allow it to differentiate between this client and other
! 257: clients or kinds of clients.
! 258: .SH DYNAMIC DNS
! 259: The client now has some very limited support for doing DNS updates
! 260: when a lease is acquired. This is prototypical, and probably doesn't
! 261: do what you want. It also only works if you happen to have control
! 262: over your DNS server, which isn't very likely.
! 263: .PP
! 264: Note that everything in this section is true whether you are using DHCPv4
! 265: or DHCPv6. The exact same syntax is used for both.
! 266: .PP
! 267: To make it work, you have to declare a key and zone as in the DHCP
! 268: server (see \fBdhcpd.conf\fR(5) for details). You also need to
! 269: configure the fqdn option on the client, as follows:
! 270: .PP
! 271: .nf
! 272: send fqdn.fqdn "grosse.fugue.com.";
! 273: send fqdn.encoded on;
! 274: send fqdn.server-update off;
! 275: also request fqdn, dhcp6.fqdn;
! 276: .fi
! 277: .PP
! 278: The \fIfqdn.fqdn\fR option \fBMUST\fR be a fully-qualified domain
! 279: name. You \fBMUST\fR define a zone statement for the zone to be
! 280: updated. The \fIfqdn.encoded\fR option may need to be set to
! 281: \fIon\fR or \fIoff\fR, depending on the DHCP server you are using.
! 282: .PP
! 283: .I The
! 284: .B do-forward-updates
! 285: .I statement
! 286: .PP
! 287: \fBdo-forward-updates [ \fIflag\fR ] \fB;\fR
! 288: .PP
! 289: If you want to do DNS updates in the DHCP client
! 290: script (see \fBdhclient-script(8)\fR) rather than having the
! 291: DHCP client do the update directly (for example, if you want to
! 292: use SIG(0) authentication, which is not supported directly by the
! 293: DHCP client, you can instruct the client not to do the update using
! 294: the \fBdo-forward-updates\fR statement. \fIFlag\fR should be \fBtrue\fR
! 295: if you want the DHCP client to do the update, and \fBfalse\fR if
! 296: you don't want the DHCP client to do the update. By default, the DHCP
! 297: client will do the DNS update.
! 298: .SH OPTION MODIFIERS
! 299: In some cases, a client may receive option data from the server which
! 300: is not really appropriate for that client, or may not receive
! 301: information that it needs, and for which a useful default value
! 302: exists. It may also receive information which is useful, but which
! 303: needs to be supplemented with local information. To handle these
! 304: needs, several option modifiers are available.
! 305: .PP
! 306: .I The
! 307: .B default
! 308: .I statement
! 309: .PP
! 310: \fBdefault [ \fIoption declaration\fR ] \fB;\fR
! 311: .PP
! 312: If for some option the client should use the value supplied by
! 313: the server, but needs to use some default value if no value was supplied
! 314: by the server, these values can be defined in the
! 315: .B default
! 316: statement.
! 317: .PP
! 318: .I The
! 319: .B supersede
! 320: .I statement
! 321: .PP
! 322: \fBsupersede [ \fIoption declaration\fR ] \fB;\fR
! 323: .PP
! 324: If for some option the client should always use a locally-configured
! 325: value or values rather than whatever is supplied by the server, these
! 326: values can be defined in the
! 327: .B supersede
! 328: statement.
! 329: .PP
! 330: .I The
! 331: .B prepend
! 332: .I statement
! 333: .PP
! 334: \fBprepend [ \fIoption declaration\fR ] \fB;\fR
! 335: .PP
! 336: If for some set of options the client should use a value you
! 337: supply, and then use the values supplied by
! 338: the server, if any, these values can be defined in the
! 339: .B prepend
! 340: statement. The
! 341: .B prepend
! 342: statement can only be used for options which
! 343: allow more than one value to be given. This restriction is not
! 344: enforced - if you ignore it, the behaviour will be unpredictable.
! 345: .PP
! 346: .I The
! 347: .B append
! 348: .I statement
! 349: .PP
! 350: \fBappend [ \fIoption declaration\fR ] \fB;\fR
! 351: .PP
! 352: If for some set of options the client should first use the values
! 353: supplied by the server, if any, and then use values you supply, these
! 354: values can be defined in the
! 355: .B append
! 356: statement. The
! 357: .B append
! 358: statement can only be used for options which
! 359: allow more than one value to be given. This restriction is not
! 360: enforced - if you ignore it, the behaviour will be unpredictable.
! 361: .SH LEASE DECLARATIONS
! 362: .PP
! 363: .I The
! 364: .B lease
! 365: .I declaration
! 366: .PP
! 367: \fBlease {\fR \fIlease-declaration\fR [ ... \fIlease-declaration ] \fB}\fR
! 368: .PP
! 369: The DHCP client may decide after some period of time (see \fBPROTOCOL
! 370: TIMING\fR) that it is not going to succeed in contacting a
! 371: server. At that time, it consults its own database of old leases and
! 372: tests each one that has not yet timed out by pinging the listed router
! 373: for that lease to see if that lease could work. It is possible to
! 374: define one or more \fIfixed\fR leases in the client configuration file
! 375: for networks where there is no DHCP or BOOTP service, so that the
! 376: client can still automatically configure its address. This is done
! 377: with the
! 378: .B lease
! 379: statement.
! 380: .PP
! 381: NOTE: the lease statement is also used in the dhclient.leases file in
! 382: order to record leases that have been received from DHCP servers.
! 383: Some of the syntax for leases as described below is only needed in the
! 384: dhclient.leases file. Such syntax is documented here for
! 385: completeness.
! 386: .PP
! 387: A lease statement consists of the lease keyword, followed by a left
! 388: curly brace, followed by one or more lease declaration statements,
! 389: followed by a right curly brace. The following lease declarations
! 390: are possible:
! 391: .PP
! 392: \fBbootp;\fR
! 393: .PP
! 394: The
! 395: .B bootp
! 396: statement is used to indicate that the lease was acquired using the
! 397: BOOTP protocol rather than the DHCP protocol. It is never necessary
! 398: to specify this in the client configuration file. The client uses
! 399: this syntax in its lease database file.
! 400: .PP
! 401: \fBinterface\fR \fB"\fR\fIstring\fR\fB";\fR
! 402: .PP
! 403: The
! 404: .B interface
! 405: lease statement is used to indicate the interface on which the lease
! 406: is valid. If set, this lease will only be tried on a particular
! 407: interface. When the client receives a lease from a server, it always
! 408: records the interface number on which it received that lease.
! 409: If predefined leases are specified in the dhclient.conf file, the
! 410: interface should also be specified, although this is not required.
! 411: .PP
! 412: \fBfixed-address\fR \fIip-address\fR\fB;\fR
! 413: .PP
! 414: The
! 415: .B fixed-address
! 416: statement is used to set the ip address of a particular lease. This
! 417: is required for all lease statements. The IP address must be
! 418: specified as a dotted quad (e.g., 12.34.56.78).
! 419: .PP
! 420: \fBfilename "\fR\fIstring\fR\fB";\fR
! 421: .PP
! 422: The
! 423: .B filename
! 424: statement specifies the name of the boot filename to use. This is
! 425: not used by the standard client configuration script, but is included
! 426: for completeness.
! 427: .PP
! 428: \fBserver-name "\fR\fIstring\fR\fB";\fR
! 429: .PP
! 430: The
! 431: .B server-name
! 432: statement specifies the name of the boot server name to use. This is
! 433: also not used by the standard client configuration script.
! 434: .PP
! 435: \fBoption\fR \fIoption-declaration\fR\fB;\fR
! 436: .PP
! 437: The
! 438: .B option
! 439: statement is used to specify the value of an option supplied by the
! 440: server, or, in the case of predefined leases declared in
! 441: dhclient.conf, the value that the user wishes the client configuration
! 442: script to use if the predefined lease is used.
! 443: .PP
! 444: \fBscript "\fIscript-name\fB";\fR
! 445: .PP
! 446: The
! 447: .B script
! 448: statement is used to specify the pathname of the dhcp client
! 449: configuration script. This script is used by the dhcp client to set
! 450: each interface's initial configuration prior to requesting an address,
! 451: to test the address once it has been offered, and to set the
! 452: interface's final configuration once a lease has been acquired. If
! 453: no lease is acquired, the script is used to test predefined leases, if
! 454: any, and also called once if no valid lease can be identified. For
! 455: more information, see
! 456: .B dhclient-script(8).
! 457: .PP
! 458: \fBvendor option space "\fIname\fB";\fR
! 459: .PP
! 460: The
! 461: .B vendor option space
! 462: statement is used to specify which option space should be used for
! 463: decoding the vendor-encapsulate-options option if one is received.
! 464: The \fIdhcp-vendor-identifier\fR can be used to request a specific
! 465: class of vendor options from the server. See
! 466: .B dhcp-options(5)
! 467: for details.
! 468: .PP
! 469: \fBmedium "\fImedia setup\fB";\fR
! 470: .PP
! 471: The
! 472: .B medium
! 473: statement can be used on systems where network interfaces cannot
! 474: automatically determine the type of network to which they are
! 475: connected. The media setup string is a system-dependent parameter
! 476: which is passed to the dhcp client configuration script when
! 477: initializing the interface. On Unix and Unix-like systems, the
! 478: argument is passed on the ifconfig command line when configuring the
! 479: interface.
! 480: .PP
! 481: The dhcp client automatically declares this parameter if it uses a
! 482: media type (see the
! 483: .B media
! 484: statement) when configuring the interface in order to obtain a lease.
! 485: This statement should be used in predefined leases only if the network
! 486: interface requires media type configuration.
! 487: .PP
! 488: \fBrenew\fR \fIdate\fB;\fR
! 489: .PP
! 490: \fBrebind\fR \fIdate\fB;\fR
! 491: .PP
! 492: \fBexpire\fR \fIdate\fB;\fR
! 493: .PP
! 494: The \fBrenew\fR statement defines the time at which the dhcp client
! 495: should begin trying to contact its server to renew a lease that it is
! 496: using. The \fBrebind\fR statement defines the time at which the dhcp
! 497: client should begin to try to contact \fIany\fR dhcp server in order
! 498: to renew its lease. The \fBexpire\fR statement defines the time at
! 499: which the dhcp client must stop using a lease if it has not been able
! 500: to contact a server in order to renew it.
! 501: .PP
! 502: These declarations are automatically set in leases acquired by the
! 503: DHCP client, but must also be configured in predefined leases - a
! 504: predefined lease whose expiry time has passed will not be used by the
! 505: DHCP client.
! 506: .PP
! 507: Dates are specified in one of two ways. The software will output times in
! 508: these two formats depending on if the \fBdb-time-format\fR configuration
! 509: parameter has been set to \fIdefault\fR or \fIlocal\fR.
! 510: .PP
! 511: If it is set to \fIdefault\fR, then \fIdate\fR values appear as follows:
! 512: .PP
! 513: \fI<weekday> <year>\fB/\fI<month>\fB/\fI<day>
! 514: <hour>\fB:\fI<minute>\fB:\fI<second>\fR
! 515: .PP
! 516: The weekday is present to make it easy for a human to tell when a
! 517: lease expires - it's specified as a number from zero to six, with zero
! 518: being Sunday. When declaring a predefined lease, it can always be
! 519: specified as zero. The year is specified with the century, so it
! 520: should generally be four digits except for really long leases. The
! 521: month is specified as a number starting with 1 for January. The day
! 522: of the month is likewise specified starting with 1. The hour is a
! 523: number between 0 and 23, the minute a number between 0 and 59, and the
! 524: second also a number between 0 and 59.
! 525: .PP
! 526: If the \fBdb-time-format\fR configuration was set to \fIlocal\fR, then
! 527: the \fIdate\fR values appear as follows:
! 528: .PP
! 529: \fBepoch\fR \fI<seconds-since-epoch>\fR\fB; #\fR \fI<day-name> <month-name>
! 530: <day-number> <hours>\fR\fB:\fR\fI<minutes>\fR\fB:\fR\fI<seconds> <year>\fR
! 531: .PP
! 532: The \fIseconds-since-epoch\fR is as according to the system's local clock (often
! 533: referred to as "unix time"). The \fB#\fR symbol supplies a comment that
! 534: describes what actual time this is as according to the system's configured
! 535: timezone, at the time the value was written. It is provided only for human
! 536: inspection, the epoch time is the only recommended value for machine
! 537: inspection.
! 538: .PP
! 539: Note that when defining a static lease, one may use either time format one
! 540: wishes, and need not include the comment or values after it.
! 541: .PP
! 542: If the time is infinite in duration, then the \fIdate\fR is \fBnever\fR
! 543: instead of an actual date.
! 544: .SH ALIAS DECLARATIONS
! 545: \fBalias { \fI declarations ... \fB}\fR
! 546: .PP
! 547: Some DHCP clients running TCP/IP roaming protocols may require that in
! 548: addition to the lease they may acquire via DHCP, their interface also
! 549: be configured with a predefined IP alias so that they can have a
! 550: permanent IP address even while roaming. The Internet Systems
! 551: Consortium DHCP client doesn't support roaming with fixed addresses
! 552: directly, but in order to facilitate such experimentation, the dhcp
! 553: client can be set up to configure an IP alias using the
! 554: .B alias
! 555: declaration.
! 556: .PP
! 557: The alias declaration resembles a lease declaration, except that
! 558: options other than the subnet-mask option are ignored by the standard
! 559: client configuration script, and expiry times are ignored. A typical
! 560: alias declaration includes an interface declaration, a fixed-address
! 561: declaration for the IP alias address, and a subnet-mask option
! 562: declaration. A medium statement should never be included in an alias
! 563: declaration.
! 564: .SH OTHER DECLARATIONS
! 565: \fBdb-time-format\fR [ \fIdefault\fR | \fIlocal\fR ] \fB;\fR
! 566: .PP
! 567: The \fBdb-time-format\fR option determines which of two output methods are
! 568: used for printing times in leases files. The \fIdefault\fR format provides
! 569: day-and-time in UTC, whereas \fIlocal\fR uses a seconds-since-epoch to store
! 570: the time value, and helpfully places a local timezone time in a comment on
! 571: the same line. The formats are described in detail in this manpage, whithin
! 572: the LEASE DECLARATIONS section.
! 573: .PP
! 574: \fBreject \fIcidr-ip-address\fR [\fB,\fR \fI...\fB \fIcidr-ip-address\fR ] \fB;\fR
! 575: .PP
! 576: The
! 577: .B reject
! 578: statement causes the DHCP client to reject offers from
! 579: servers whose server identifier matches any of the specified hosts or
! 580: subnets. This can be used to avoid being configured by rogue or
! 581: misconfigured dhcp servers, although it should be a last resort -
! 582: better to track down the bad DHCP server and fix it.
! 583: .PP
! 584: The \fIcidr-ip-address\fR configuration type is of the
! 585: form \fIip-address\fR[\fB/\fIprefixlen\fR], where \fIip-address\fR is a
! 586: dotted quad IP address, and \fRprefixlen\fR is the CIDR prefix length of
! 587: the subnet, counting the number of significant bits in the netmask starting
! 588: from the leftmost end. Example configuration syntax:
! 589: .PP
! 590: .I \fIreject\fR 192.168.0.0\fB/\fR16\fB,\fR 10.0.0.5\fB;\fR
! 591: .RE
! 592: .PP
! 593: The above example would cause offers from any server identifier in the
! 594: entire RFC 1918 "Class C" network 192.168.0.0/16, or the specific
! 595: single address 10.0.0.5, to be rejected.
! 596: .PP
! 597: \fBinterface "\fIname\fB" { \fIdeclarations ... \fB }
! 598: .PP
! 599: A client with more than one network interface may require different
! 600: behaviour depending on which interface is being configured. All
! 601: timing parameters and declarations other than lease and alias
! 602: declarations can be enclosed in an interface declaration, and those
! 603: parameters will then be used only for the interface that matches the
! 604: specified name. Interfaces for which there is no interface
! 605: declaration will use the parameters declared outside of any interface
! 606: declaration, or the default settings.
! 607: .PP
! 608: .B Note well:
! 609: ISC dhclient only maintains one list of interfaces, which is either
! 610: determined at startup from command line arguments, or otherwise is
! 611: autodetected. If you supplied the list of interfaces on the command
! 612: line, this configuration clause will add the named interface to the
! 613: list in such a way that will cause it to be configured by DHCP. Which
! 614: may not be the result you had intended. This is an undesirable side
! 615: effect that will be addressed in a future release.
! 616: .PP
! 617: \fBpseudo "\fIname\fR" "\fIreal-name\fB" { \fIdeclarations ... \fB }
! 618: .PP
! 619: Under some circumstances it can be useful to declare a pseudo-interface
! 620: and have the DHCP client acquire a configuration for that interface.
! 621: Each interface that the DHCP client is supporting normally has a DHCP
! 622: client state machine running on it to acquire and maintain its lease.
! 623: A pseudo-interface is just another state machine running on the
! 624: interface named \fIreal-name\fR, with its own lease and its own
! 625: state. If you use this feature, you must provide a client identifier
! 626: for both the pseudo-interface and the actual interface, and the two
! 627: identifiers must be different. You must also provide a separate
! 628: client script for the pseudo-interface to do what you want with the IP
! 629: address. For example:
! 630: .PP
! 631: .nf
! 632: interface "ep0" {
! 633: send dhcp-client-identifier "my-client-ep0";
! 634: }
! 635: pseudo "secondary" "ep0" {
! 636: send dhcp-client-identifier "my-client-ep0-secondary";
! 637: script "/etc/dhclient-secondary";
! 638: }
! 639: .fi
! 640: .PP
! 641: The client script for the pseudo-interface should not configure the
! 642: interface up or down - essentially, all it needs to handle are the
! 643: states where a lease has been acquired or renewed, and the states
! 644: where a lease has expired. See \fBdhclient-script(8)\fR for more
! 645: information.
! 646: .PP
! 647: \fBmedia "\fImedia setup\fB"\fI [ \fB, "\fImedia setup\fB", \fI... ]\fB;\fR
! 648: .PP
! 649: The
! 650: .B media
! 651: statement defines one or more media configuration parameters which may
! 652: be tried while attempting to acquire an IP address. The dhcp client
! 653: will cycle through each media setup string on the list, configuring
! 654: the interface using that setup and attempting to boot, and then trying
! 655: the next one. This can be used for network interfaces which aren't
! 656: capable of sensing the media type unaided - whichever media type
! 657: succeeds in getting a request to the server and hearing the reply is
! 658: probably right (no guarantees).
! 659: .PP
! 660: The media setup is only used for the initial phase of address
! 661: acquisition (the DHCPDISCOVER and DHCPOFFER packets). Once an
! 662: address has been acquired, the dhcp client will record it in its lease
! 663: database and will record the media type used to acquire the address.
! 664: Whenever the client tries to renew the lease, it will use that same
! 665: media type. The lease must expire before the client will go back to
! 666: cycling through media types.
! 667: .SH SAMPLE
! 668: The following configuration file is used on a laptop running NetBSD
! 669: 1.3. The laptop has an IP alias of 192.5.5.213, and has one
! 670: interface, ep0 (a 3com 3C589C). Booting intervals have been
! 671: shortened somewhat from the default, because the client is known to
! 672: spend most of its time on networks with little DHCP activity. The
! 673: laptop does roam to multiple networks.
! 674:
! 675: .nf
! 676:
! 677: timeout 60;
! 678: retry 60;
! 679: reboot 10;
! 680: select-timeout 5;
! 681: initial-interval 2;
! 682: reject 192.33.137.209;
! 683:
! 684: interface "ep0" {
! 685: send host-name "andare.fugue.com";
! 686: send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
! 687: send dhcp-lease-time 3600;
! 688: supersede domain-search "fugue.com", "rc.vix.com", "home.vix.com";
! 689: prepend domain-name-servers 127.0.0.1;
! 690: request subnet-mask, broadcast-address, time-offset, routers,
! 691: domain-name, domain-name-servers, host-name;
! 692: require subnet-mask, domain-name-servers;
! 693: script "CLIENTBINDIR/dhclient-script";
! 694: media "media 10baseT/UTP", "media 10base2/BNC";
! 695: }
! 696:
! 697: alias {
! 698: interface "ep0";
! 699: fixed-address 192.5.5.213;
! 700: option subnet-mask 255.255.255.255;
! 701: }
! 702: .fi
! 703: This is a very complicated dhclient.conf file - in general, yours
! 704: should be much simpler. In many cases, it's sufficient to just
! 705: create an empty dhclient.conf file - the defaults are usually fine.
! 706: .SH SEE ALSO
! 707: dhcp-options(5), dhcp-eval(5), dhclient.leases(5), dhcpd(8), dhcpd.conf(5),
! 708: RFC2132, RFC2131.
! 709: .SH AUTHOR
! 710: .B dhclient(8)
! 711: was written by Ted Lemon
! 712: under a contract with Vixie Labs. Funding
! 713: for this project was provided by Internet Systems Consortium.
! 714: Information about Internet Systems Consortium can be found at
! 715: .B https://www.isc.org.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to dhclient.conf.5 CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / dhcp / client