1: .\" $Id: dhclient.conf.5,v 1.1.1.1 2012/10/09 09:06:54 misho Exp $
2: .\"
3: .\" Copyright (c) 2009-2012 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 fifteen
151: seconds.
152: .PP
153: .I The
154: .B initial-interval
155: .I statement
156: .PP
157: \fBinitial-interval \fItime\fR\fB;\fR
158: .PP
159: The
160: .I initial-interval
161: statement sets the amount of time between the first attempt to reach a
162: server and the second attempt to reach a server. Each time a message
163: is sent, the interval between messages is incremented by twice the
164: current interval multiplied by a random number between zero and one.
165: If it is greater than the backoff-cutoff amount, it is set to that
166: amount. It defaults to ten seconds.
167: .PP
168: .I The initial-delay
169: .I statement
170: .PP
171: \fBinitial-delay \fItime\fR\fB;\fR
172: .PP
173: .I initial-delay
174: parameter sets the maximum time client can wait after start before
175: commencing first transmission.
176: According to RFC2131 Section 4.4.1, client should wait a random time between
177: startup and the actual first transmission. Previous versions of ISC DHCP
178: client used to wait random time up to 5 seconds, but that was unwanted
179: due to impact on startup time. As such, new versions have the default
180: initial delay set to 0. To restore old behavior, please set initial-delay
181: to 5.
182: .SH LEASE REQUIREMENTS AND REQUESTS
183: The DHCP protocol allows the client to request that the server send it
184: specific information, and not send it other information that it is not
185: prepared to accept. The protocol also allows the client to reject
186: offers from servers if they don't contain information the client
187: needs, or if the information provided is not satisfactory.
188: .PP
189: There is a variety of data contained in offers that DHCP servers send
190: to DHCP clients. The data that can be specifically requested is what
191: are called \fIDHCP Options\fR. DHCP Options are defined in
192: \fBdhcp-options(5)\fR.
193: .PP
194: .I The
195: .B request
196: .I statement
197: .PP
198: \fB[ also ] request [ [ \fIoption-space\fR . ] \fIoption\fR ] [\fB,\fI ... ]\fB;\fR
199: .PP
200: The request statement causes the client to request that any server
201: responding to the client send the client its values for the specified
202: options. Only the option names should be specified in the request
203: statement - not option parameters. By default, the DHCPv4 client
204: requests the subnet-mask, broadcast-address, time-offset, routers,
205: domain-name, domain-name-servers and host-name options while the DHCPv6
206: client requests the dhcp6 name-servers and domain-search options. Note
207: that if you enter a \'request\' statement, you over-ride these defaults
208: and these options will not be requested.
209: .PP
210: In some cases, it may be desirable to send no parameter request list
211: at all. To do this, simply write the request statement but specify
212: no parameters:
213: .PP
214: .nf
215: request;
216: .fi
217: .PP
218: In most cases, it is desirable to simply add one option to the request
219: list which is of interest to the client in question. In this case, it
220: is best to \'also request\' the additional options:
221: .PP
222: .nf
223: also request domain-search, dhcp6.sip-servers-addresses;
224: .fi
225: .PP
226: .I The
227: .B require
228: .I statement
229: .PP
230: \fB[ also ] require [ [ \fIoption-space\fR . ] \fIoption\fR ] [\fB,\fI ... ]\fB;\fR
231: .PP
232: The require statement lists options that must be sent in order for an
233: offer to be accepted. Offers that do not contain all the listed
234: options will be ignored. There is no default require list.
235: .PP
236: .nf
237: require name-servers;
238:
239: interface eth0 {
240: also require domain-search;
241: }
242: .PP
243: .I The
244: .B send
245: .I statement
246: .PP
247: \fBsend { [ \fIoption declaration\fR ]
248: [\fB,\fI ... \fIoption declaration\fR ]\fB}\fR
249: .PP
250: The send statement causes the client to send the specified options to
251: the server with the specified values. These are full option
252: declarations as described in \fBdhcp-options(5)\fR. Options that are
253: always sent in the DHCP protocol should not be specified here, except
254: that the client can specify a requested \fBdhcp-lease-time\fR option other
255: than the default requested lease time, which is two hours. The other
256: obvious use for this statement is to send information to the server
257: that will allow it to differentiate between this client and other
258: clients or kinds of clients.
259: .SH DYNAMIC DNS
260: The client now has some very limited support for doing DNS updates
261: when a lease is acquired. This is prototypical, and probably doesn't
262: do what you want. It also only works if you happen to have control
263: over your DNS server, which isn't very likely.
264: .PP
265: Note that everything in this section is true whether you are using DHCPv4
266: or DHCPv6. The exact same syntax is used for both.
267: .PP
268: To make it work, you have to declare a key and zone as in the DHCP
269: server (see \fBdhcpd.conf\fR(5) for details). You also need to
270: configure the fqdn option on the client, as follows:
271: .PP
272: .nf
273: send fqdn.fqdn "grosse.fugue.com.";
274: send fqdn.encoded on;
275: send fqdn.server-update off;
276: also request fqdn, dhcp6.fqdn;
277: .fi
278: .PP
279: The \fIfqdn.fqdn\fR option \fBMUST\fR be a fully-qualified domain
280: name. You \fBMUST\fR define a zone statement for the zone to be
281: updated. The \fIfqdn.encoded\fR option may need to be set to
282: \fIon\fR or \fIoff\fR, depending on the DHCP server you are using.
283: .PP
284: .I The
285: .B do-forward-updates
286: .I statement
287: .PP
288: \fBdo-forward-updates [ \fIflag\fR ] \fB;\fR
289: .PP
290: If you want to do DNS updates in the DHCP client
291: script (see \fBdhclient-script(8)\fR) rather than having the
292: DHCP client do the update directly (for example, if you want to
293: use SIG(0) authentication, which is not supported directly by the
294: DHCP client, you can instruct the client not to do the update using
295: the \fBdo-forward-updates\fR statement. \fIFlag\fR should be \fBtrue\fR
296: if you want the DHCP client to do the update, and \fBfalse\fR if
297: you don't want the DHCP client to do the update. By default, the DHCP
298: client will do the DNS update.
299: .SH OPTION MODIFIERS
300: In some cases, a client may receive option data from the server which
301: is not really appropriate for that client, or may not receive
302: information that it needs, and for which a useful default value
303: exists. It may also receive information which is useful, but which
304: needs to be supplemented with local information. To handle these
305: needs, several option modifiers are available.
306: .PP
307: .I The
308: .B default
309: .I statement
310: .PP
311: \fBdefault [ \fIoption declaration\fR ] \fB;\fR
312: .PP
313: If for some option the client should use the value supplied by
314: the server, but needs to use some default value if no value was supplied
315: by the server, these values can be defined in the
316: .B default
317: statement.
318: .PP
319: .I The
320: .B supersede
321: .I statement
322: .PP
323: \fBsupersede [ \fIoption declaration\fR ] \fB;\fR
324: .PP
325: If for some option the client should always use a locally-configured
326: value or values rather than whatever is supplied by the server, these
327: values can be defined in the
328: .B supersede
329: statement.
330: .PP
331: .I The
332: .B prepend
333: .I statement
334: .PP
335: \fBprepend [ \fIoption declaration\fR ] \fB;\fR
336: .PP
337: If for some set of options the client should use a value you
338: supply, and then use the values supplied by
339: the server, if any, these values can be defined in the
340: .B prepend
341: statement. The
342: .B prepend
343: statement can only be used for options which
344: allow more than one value to be given. This restriction is not
345: enforced - if you ignore it, the behaviour will be unpredictable.
346: .PP
347: .I The
348: .B append
349: .I statement
350: .PP
351: \fBappend [ \fIoption declaration\fR ] \fB;\fR
352: .PP
353: If for some set of options the client should first use the values
354: supplied by the server, if any, and then use values you supply, these
355: values can be defined in the
356: .B append
357: statement. The
358: .B append
359: statement can only be used for options which
360: allow more than one value to be given. This restriction is not
361: enforced - if you ignore it, the behaviour will be unpredictable.
362: .SH LEASE DECLARATIONS
363: .PP
364: .I The
365: .B lease
366: .I declaration
367: .PP
368: \fBlease {\fR \fIlease-declaration\fR [ ... \fIlease-declaration ] \fB}\fR
369: .PP
370: The DHCP client may decide after some period of time (see \fBPROTOCOL
371: TIMING\fR) that it is not going to succeed in contacting a
372: server. At that time, it consults its own database of old leases and
373: tests each one that has not yet timed out by pinging the listed router
374: for that lease to see if that lease could work. It is possible to
375: define one or more \fIfixed\fR leases in the client configuration file
376: for networks where there is no DHCP or BOOTP service, so that the
377: client can still automatically configure its address. This is done
378: with the
379: .B lease
380: statement.
381: .PP
382: NOTE: the lease statement is also used in the dhclient.leases file in
383: order to record leases that have been received from DHCP servers.
384: Some of the syntax for leases as described below is only needed in the
385: dhclient.leases file. Such syntax is documented here for
386: completeness.
387: .PP
388: A lease statement consists of the lease keyword, followed by a left
389: curly brace, followed by one or more lease declaration statements,
390: followed by a right curly brace. The following lease declarations
391: are possible:
392: .PP
393: \fBbootp;\fR
394: .PP
395: The
396: .B bootp
397: statement is used to indicate that the lease was acquired using the
398: BOOTP protocol rather than the DHCP protocol. It is never necessary
399: to specify this in the client configuration file. The client uses
400: this syntax in its lease database file.
401: .PP
402: \fBinterface\fR \fB"\fR\fIstring\fR\fB";\fR
403: .PP
404: The
405: .B interface
406: lease statement is used to indicate the interface on which the lease
407: is valid. If set, this lease will only be tried on a particular
408: interface. When the client receives a lease from a server, it always
409: records the interface number on which it received that lease.
410: If predefined leases are specified in the dhclient.conf file, the
411: interface should also be specified, although this is not required.
412: .PP
413: \fBfixed-address\fR \fIip-address\fR\fB;\fR
414: .PP
415: The
416: .B fixed-address
417: statement is used to set the ip address of a particular lease. This
418: is required for all lease statements. The IP address must be
419: specified as a dotted quad (e.g., 12.34.56.78).
420: .PP
421: \fBfilename "\fR\fIstring\fR\fB";\fR
422: .PP
423: The
424: .B filename
425: statement specifies the name of the boot filename to use. This is
426: not used by the standard client configuration script, but is included
427: for completeness.
428: .PP
429: \fBserver-name "\fR\fIstring\fR\fB";\fR
430: .PP
431: The
432: .B server-name
433: statement specifies the name of the boot server name to use. This is
434: also not used by the standard client configuration script.
435: .PP
436: \fBoption\fR \fIoption-declaration\fR\fB;\fR
437: .PP
438: The
439: .B option
440: statement is used to specify the value of an option supplied by the
441: server, or, in the case of predefined leases declared in
442: dhclient.conf, the value that the user wishes the client configuration
443: script to use if the predefined lease is used.
444: .PP
445: \fBscript "\fIscript-name\fB";\fR
446: .PP
447: The
448: .B script
449: statement is used to specify the pathname of the dhcp client
450: configuration script. This script is used by the dhcp client to set
451: each interface's initial configuration prior to requesting an address,
452: to test the address once it has been offered, and to set the
453: interface's final configuration once a lease has been acquired. If
454: no lease is acquired, the script is used to test predefined leases, if
455: any, and also called once if no valid lease can be identified. For
456: more information, see
457: .B dhclient-script(8).
458: .PP
459: \fBvendor option space "\fIname\fB";\fR
460: .PP
461: The
462: .B vendor option space
463: statement is used to specify which option space should be used for
464: decoding the vendor-encapsulate-options option if one is received.
465: The \fIdhcp-vendor-identifier\fR can be used to request a specific
466: class of vendor options from the server. See
467: .B dhcp-options(5)
468: for details.
469: .PP
470: \fBmedium "\fImedia setup\fB";\fR
471: .PP
472: The
473: .B medium
474: statement can be used on systems where network interfaces cannot
475: automatically determine the type of network to which they are
476: connected. The media setup string is a system-dependent parameter
477: which is passed to the dhcp client configuration script when
478: initializing the interface. On Unix and Unix-like systems, the
479: argument is passed on the ifconfig command line when configuring the
480: interface.
481: .PP
482: The dhcp client automatically declares this parameter if it uses a
483: media type (see the
484: .B media
485: statement) when configuring the interface in order to obtain a lease.
486: This statement should be used in predefined leases only if the network
487: interface requires media type configuration.
488: .PP
489: \fBrenew\fR \fIdate\fB;\fR
490: .PP
491: \fBrebind\fR \fIdate\fB;\fR
492: .PP
493: \fBexpire\fR \fIdate\fB;\fR
494: .PP
495: The \fBrenew\fR statement defines the time at which the dhcp client
496: should begin trying to contact its server to renew a lease that it is
497: using. The \fBrebind\fR statement defines the time at which the dhcp
498: client should begin to try to contact \fIany\fR dhcp server in order
499: to renew its lease. The \fBexpire\fR statement defines the time at
500: which the dhcp client must stop using a lease if it has not been able
501: to contact a server in order to renew it.
502: .PP
503: These declarations are automatically set in leases acquired by the
504: DHCP client, but must also be configured in predefined leases - a
505: predefined lease whose expiry time has passed will not be used by the
506: DHCP client.
507: .PP
508: Dates are specified in one of two ways. The software will output times in
509: these two formats depending on if the \fBdb-time-format\fR configuration
510: parameter has been set to \fIdefault\fR or \fIlocal\fR.
511: .PP
512: If it is set to \fIdefault\fR, then \fIdate\fR values appear as follows:
513: .PP
514: \fI<weekday> <year>\fB/\fI<month>\fB/\fI<day>
515: <hour>\fB:\fI<minute>\fB:\fI<second>\fR
516: .PP
517: The weekday is present to make it easy for a human to tell when a
518: lease expires - it's specified as a number from zero to six, with zero
519: being Sunday. When declaring a predefined lease, it can always be
520: specified as zero. The year is specified with the century, so it
521: should generally be four digits except for really long leases. The
522: month is specified as a number starting with 1 for January. The day
523: of the month is likewise specified starting with 1. The hour is a
524: number between 0 and 23, the minute a number between 0 and 59, and the
525: second also a number between 0 and 59.
526: .PP
527: If the \fBdb-time-format\fR configuration was set to \fIlocal\fR, then
528: the \fIdate\fR values appear as follows:
529: .PP
530: \fBepoch\fR \fI<seconds-since-epoch>\fR\fB; #\fR \fI<day-name> <month-name>
531: <day-number> <hours>\fR\fB:\fR\fI<minutes>\fR\fB:\fR\fI<seconds> <year>\fR
532: .PP
533: The \fIseconds-since-epoch\fR is as according to the system's local clock (often
534: referred to as "unix time"). The \fB#\fR symbol supplies a comment that
535: describes what actual time this is as according to the system's configured
536: timezone, at the time the value was written. It is provided only for human
537: inspection, the epoch time is the only recommended value for machine
538: inspection.
539: .PP
540: Note that when defining a static lease, one may use either time format one
541: wishes, and need not include the comment or values after it.
542: .PP
543: If the time is infinite in duration, then the \fIdate\fR is \fBnever\fR
544: instead of an actual date.
545: .SH ALIAS DECLARATIONS
546: \fBalias { \fI declarations ... \fB}\fR
547: .PP
548: Some DHCP clients running TCP/IP roaming protocols may require that in
549: addition to the lease they may acquire via DHCP, their interface also
550: be configured with a predefined IP alias so that they can have a
551: permanent IP address even while roaming. The Internet Systems
552: Consortium DHCP client doesn't support roaming with fixed addresses
553: directly, but in order to facilitate such experimentation, the dhcp
554: client can be set up to configure an IP alias using the
555: .B alias
556: declaration.
557: .PP
558: The alias declaration resembles a lease declaration, except that
559: options other than the subnet-mask option are ignored by the standard
560: client configuration script, and expiry times are ignored. A typical
561: alias declaration includes an interface declaration, a fixed-address
562: declaration for the IP alias address, and a subnet-mask option
563: declaration. A medium statement should never be included in an alias
564: declaration.
565: .SH OTHER DECLARATIONS
566: \fBdb-time-format\fR [ \fIdefault\fR | \fIlocal\fR ] \fB;\fR
567: .PP
568: The \fBdb-time-format\fR option determines which of two output methods are
569: used for printing times in leases files. The \fIdefault\fR format provides
570: day-and-time in UTC, whereas \fIlocal\fR uses a seconds-since-epoch to store
571: the time value, and helpfully places a local timezone time in a comment on
572: the same line. The formats are described in detail in this manpage, whithin
573: the LEASE DECLARATIONS section.
574: .PP
575: \fBreject \fIcidr-ip-address\fR [\fB,\fR \fI...\fB \fIcidr-ip-address\fR ] \fB;\fR
576: .PP
577: The
578: .B reject
579: statement causes the DHCP client to reject offers from
580: servers whose server identifier matches any of the specified hosts or
581: subnets. This can be used to avoid being configured by rogue or
582: misconfigured dhcp servers, although it should be a last resort -
583: better to track down the bad DHCP server and fix it.
584: .PP
585: The \fIcidr-ip-address\fR configuration type is of the
586: form \fIip-address\fR[\fB/\fIprefixlen\fR], where \fIip-address\fR is a
587: dotted quad IP address, and \fRprefixlen\fR is the CIDR prefix length of
588: the subnet, counting the number of significant bits in the netmask starting
589: from the leftmost end. Example configuration syntax:
590: .PP
591: .I \fIreject\fR 192.168.0.0\fB/\fR16\fB,\fR 10.0.0.5\fB;\fR
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