1: .\" $Id: dhclient.conf.5,v 1.1 2012/02/21 22:30:18 misho 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