]>
Commit | Line | Data |
---|---|---|
0e7affc7 TL |
1 | .\" dhclient.conf.5 |
2 | .\" | |
f39b6e00 TL |
3 | .\" Copyright (c) 1996-1999 Internet Software Consortium. |
4 | .\" Use is subject to license terms which appear in the file named | |
5 | .\" ISC-LICENSE that should have accompanied this file when you | |
6 | .\" received it. If a file named ISC-LICENSE did not accompany this | |
7 | .\" file, or you are not sure the one you have is correct, you may | |
8 | .\" obtain an applicable copy of the license at: | |
0e7affc7 | 9 | .\" |
f39b6e00 | 10 | .\" http://www.isc.org/isc-license-1.0.html. |
0e7affc7 | 11 | .\" |
f39b6e00 TL |
12 | .\" This file is part of the ISC DHCP distribution. The documentation |
13 | .\" associated with this file is listed in the file DOCUMENTATION, | |
14 | .\" included in the top-level directory of this release. | |
0e7affc7 | 15 | .\" |
f39b6e00 TL |
16 | .\" Support and other services are available for ISC products - see |
17 | .\" http://www.isc.org for more information. | |
e7ec0fa1 | 18 | .TH dhclient.conf 5 |
0e7affc7 TL |
19 | .SH NAME |
20 | dhclient.conf - DHCP client configuration file | |
21 | .SH DESCRIPTION | |
22 | The dhclient.conf file contains configuration information for | |
23 | .IR dhclient, | |
24 | the Internet Software Consortium DHCP Client. | |
25 | .PP | |
26 | The dhclient.conf file is a free-form ASCII text file. It is parsed by | |
27 | the recursive-descent parser built into dhclient. The file may contain | |
28 | extra tabs and newlines for formatting purposes. Keywords in the file | |
29 | are case-insensitive. Comments may be placed anywhere within the | |
30 | file (except within quotes). Comments begin with the # character and | |
31 | end at the end of the line. | |
32 | .PP | |
e7ec0fa1 TL |
33 | The dhclient.conf file can be used to configure the behaviour of the |
34 | client in a wide variety of ways: protocol timing, information | |
35 | requested from the server, information required of the server, | |
36 | defaults to use if the server does not provide certain information, | |
37 | values with which to override information provided by the server, or | |
38 | values to prepend or append to information provided by the server. | |
39 | The configuration file can also be preinitialized with addresses to | |
40 | use on networks that don't have DHCP servers. | |
41 | .SH PROTOCOL TIMING | |
42 | The timing behaviour of the client need not be configured by the user. | |
43 | If no timing configuration is provided by the user, a fairly | |
44 | reasonable timing behaviour will be used by default - one which | |
45 | results in fairly timely updates without placing an inordinate load on | |
46 | the server. | |
47 | .PP | |
48 | The following statements can be used to adjust the timing behaviour of | |
49 | the DHCP client if required, however: | |
50 | .PP | |
51 | .I The | |
52 | .B timeout | |
53 | .I statement | |
54 | .PP | |
55 | .B timeout | |
56 | .I time | |
57 | .B ; | |
58 | .PP | |
59 | The | |
60 | .I timeout | |
61 | statement determines the amount of time that must pass between the | |
62 | time that the client begins to try to determine its address and the | |
63 | time that it decides that it's not going to be able to contact a | |
64 | server. By default, this timeout is sixty seconds. After the | |
65 | timeout has passed, if there are any static leases defined in the | |
66 | configuration file, or any leases remaining in the lease database that | |
67 | have not yet expired, the client will loop through these leases | |
68 | attempting to validate them, and if it finds one that appears to be | |
69 | valid, it will use that lease's address. If there are no valid | |
70 | static leases or unexpired leases in the lease database, the client | |
71 | will restart the protocol after the defined retry interval. | |
72 | .PP | |
73 | .I The | |
74 | .B retry | |
75 | .I statement | |
76 | .PP | |
77 | \fBretry \fItime\fR\fB;\fR | |
78 | .PP | |
79 | The | |
80 | .I retry | |
81 | statement determines the time that must pass after the client has | |
82 | determined that there is no DHCP server present before it tries again | |
83 | to contact a DHCP server. By default, this is five minutes. | |
84 | .PP | |
85 | .I The | |
86 | .B select-timeout | |
87 | .I statement | |
88 | .PP | |
89 | \fBselect-timeout \fItime\fR\fB;\fR | |
90 | .PP | |
91 | It is possible (some might say desirable) for there to be more than | |
e97b2a17 | 92 | one DHCP server serving any given network. In this case, it is |
e7ec0fa1 TL |
93 | possible that a client may be sent more than one offer in response to |
94 | its initial lease discovery message. It may be that one of these | |
95 | offers is preferable to the other (e.g., one offer may have the | |
96 | address the client previously used, and the other may not). | |
97 | .PP | |
98 | The | |
99 | .I select-timeout | |
100 | is the time after the client sends its first lease discovery request | |
101 | at which it stops waiting for offers from servers, assuming that it | |
102 | has received at least one such offer. If no offers have been | |
103 | received by the time the | |
104 | .I select-timeout | |
105 | has expired, the client will accept the first offer that arrives. | |
106 | .PP | |
e97b2a17 TL |
107 | By default, the select-timeout is zero seconds - that is, the client |
108 | will take the first offer it sees. | |
109 | .PP | |
e7ec0fa1 TL |
110 | .I The |
111 | .B reboot | |
112 | .I statement | |
113 | .PP | |
114 | \fBreboot \fItime\fR\fB;\fR | |
115 | .PP | |
116 | When the client is restarted, it first tries to reacquire the last | |
117 | address it had. This is called the INIT-REBOOT state. If it is | |
118 | still attached to the same network it was attached to when it last | |
119 | ran, this is the quickest way to get started. The | |
120 | .I reboot | |
121 | statement sets the time that must elapse after the client first tries | |
122 | to reacquire its old address before it gives up and tries to discover | |
e97b2a17 | 123 | a new address. By default, the reboot timeout is ten seconds. |
e7ec0fa1 TL |
124 | .PP |
125 | .I The | |
126 | .B backoff-cutoff | |
127 | .I statement | |
128 | .PP | |
129 | \fBbackoff-cutoff \fItime\fR\fB;\fR | |
130 | .PP | |
131 | The client uses an exponential backoff algorithm with some randomness, | |
132 | so that if many clients try to configure themselves at the same time, | |
133 | they will not make their requests in lockstep. The | |
134 | .I backoff-cutoff | |
135 | statement determines the maximum amount of time that the client is | |
136 | allowed to back off. It defaults to two minutes. | |
137 | .PP | |
138 | .I The | |
139 | .B initial-interval | |
140 | .I statement | |
141 | .PP | |
142 | \fBinitial-interval \fItime\fR\fB;\fR | |
143 | .PP | |
144 | The | |
145 | .I initial-interval | |
146 | statement sets the amount of time between the first attempt to reach a | |
e97b2a17 TL |
147 | server and the second attempt to reach a server. Each time a message |
148 | is sent, the interval between messages is incremented by twice the | |
149 | current interval multiplied by a random number between zero and one. | |
150 | If it is greater than the backoff-cutoff amount, it is set to that | |
151 | amount. It defaults to ten seconds. | |
e7ec0fa1 TL |
152 | .SH LEASE REQUIREMENTS AND REQUESTS |
153 | The DHCP protocol allows the client to request that the server send it | |
154 | specific information, and not send it other information that it is not | |
155 | prepared to accept. The protocol also allows the client to reject | |
156 | offers from servers if they don't contain information the client | |
157 | needs, or if the information provided is not satisfactory. | |
158 | .PP | |
159 | There is a variety of data contained in offers that DHCP servers send | |
160 | to DHCP clients. The data that can be specifically requested is what | |
161 | are called \fIDHCP Options\fR. DHCP Options are defined in | |
162 | \fBdhcp-options(5)\fR. | |
163 | .PP | |
164 | .I The | |
165 | .B request | |
166 | .I statement | |
167 | .PP | |
e97b2a17 | 168 | \fBrequest [ \fIoption\fR ] [\fB,\fI ... \fIoption\fR ]\fB;\fR |
e7ec0fa1 TL |
169 | .PP |
170 | The request statement causes the client to request that any server | |
171 | responding to the client send the client its values for the specified | |
172 | options. Only the option names should be specified in the request | |
afa9d40b TL |
173 | statement - not option parameters. By default, the DHCP server |
174 | requests the subnet-mask, broadcast-address, time-offset, routers, | |
175 | domain-name, domain-name-servers and host-name options. | |
176 | .PP | |
177 | In some cases, it may be desirable to send no parameter request list | |
178 | at all. To do this, simply write the request statement but specify | |
179 | no parameters: | |
180 | .PP | |
181 | .nf | |
182 | request; | |
183 | .fi | |
e7ec0fa1 TL |
184 | .PP |
185 | .I The | |
186 | .B require | |
187 | .I statement | |
188 | .PP | |
e97b2a17 | 189 | \fBrequire [ \fIoption\fR ] [\fB,\fI ... \fIoption ]\fB;\fR |
e7ec0fa1 | 190 | .PP |
e97b2a17 TL |
191 | The require statement lists options that must be sent in order for an |
192 | offer to be accepted. Offers that do not contain all the listed | |
193 | options will be ignored. | |
e7ec0fa1 TL |
194 | .PP |
195 | .I The | |
196 | .B send | |
197 | .I statement | |
198 | .PP | |
199 | \fBsend { [ \fIoption declaration\fR ] | |
200 | [\fB,\fI ... \fIoption declaration\fR ]\fB}\fR | |
201 | .PP | |
202 | The send statement causes the client to send the specified options to | |
e97b2a17 TL |
203 | the server with the specified values. These are full option |
204 | declarations as described in \fBdhcp-options(5)\fR. Options that are | |
205 | always sent in the DHCP protocol should not be specified here, except | |
206 | that the client can specify a \fBrequested-lease-time\fR option other | |
207 | than the default requested lease time, which is two hours. The other | |
e7ec0fa1 TL |
208 | obvious use for this statement is to send information to the server |
209 | that will allow it to differentiate between this client and other | |
210 | clients or kinds of clients. | |
211 | .SH OPTION MODIFIERS | |
212 | In some cases, a client may receive option data from the server which | |
213 | is not really appropriate for that client, or may not receive | |
214 | information that it needs, and for which a useful default value | |
215 | exists. It may also receive information which is useful, but which | |
216 | needs to be supplemented with local information. To handle these | |
217 | needs, several option modifiers are available. | |
218 | .PP | |
219 | .I The | |
220 | .B default | |
221 | .I statement | |
222 | .PP | |
d4b26e01 | 223 | \fBdefault [ \fIoption declaration\fR ] \fB;\fR |
e7ec0fa1 | 224 | .PP |
d4b26e01 | 225 | If for some option the client should use the value supplied by |
e7ec0fa1 TL |
226 | the server, but needs to use some default value if no value was supplied |
227 | by the server, these values can be defined in the | |
228 | .B default | |
229 | statement. | |
230 | .PP | |
231 | .I The | |
232 | .B supersede | |
233 | .I statement | |
234 | .PP | |
d4b26e01 | 235 | \fBsupersede [ \fIoption declaration\fR ] \fB;\fR |
e7ec0fa1 | 236 | .PP |
d4b26e01 TL |
237 | If for some option the client should always use a locally-configured |
238 | value or values rather than whatever is supplied by the server, these | |
239 | values can be defined in the | |
e7ec0fa1 TL |
240 | .B supersede |
241 | statement. | |
242 | .PP | |
243 | .I The | |
244 | .B prepend | |
245 | .I statement | |
246 | .PP | |
d4b26e01 | 247 | \fBprepend [ \fIoption declaration\fR ] \fB;\fR |
e7ec0fa1 | 248 | .PP |
ea2ee1fd TL |
249 | If for some set of options the client should use a value you |
250 | supply, and then use the values supplied by | |
251 | the server, if any, these values can be defined in the | |
e7ec0fa1 TL |
252 | .B prepend |
253 | statement. The | |
254 | .B prepend | |
255 | statement can only be used for options which | |
ea2ee1fd TL |
256 | allow more than one value to be given. This restriction is not |
257 | enforced - if you ignore it, the behaviour will be unpredictable. | |
e7ec0fa1 TL |
258 | .PP |
259 | .I The | |
260 | .B append | |
261 | .I statement | |
262 | .PP | |
d4b26e01 | 263 | \fBappend [ \fIoption declaration\fR ] \fB;\fR |
e7ec0fa1 | 264 | .PP |
ea2ee1fd TL |
265 | If for some set of options the client should first use the values |
266 | supplied by the server, if any, and then use values you supply, these | |
267 | values can be defined in the | |
e7ec0fa1 TL |
268 | .B append |
269 | statement. The | |
270 | .B append | |
271 | statement can only be used for options which | |
ea2ee1fd TL |
272 | allow more than one value to be given. This restriction is not |
273 | enforced - if you ignore it, the behaviour will be unpredictable. | |
e7ec0fa1 TL |
274 | .SH LEASE DECLARATIONS |
275 | .PP | |
276 | .I The | |
277 | .B lease | |
278 | .I declaration | |
279 | .PP | |
280 | \fBlease {\fR \fIlease-declaration\fR [ ... \fIlease-declaration ] \fB}\fR | |
281 | .PP | |
282 | The DHCP client may decide after some period of time (see \fBPROTOCOL | |
283 | TIMING\fR) decide that it is not going to succeed in contacting a | |
284 | server. At that time, it consults its own database of old leases and | |
285 | tests each one that has not yet timed out by pinging the listed router | |
286 | for that lease to see if that lease could work. It is possible to | |
287 | define one or more \fIfixed\fR leases in the client configuration file | |
288 | for networks where there is no DHCP or BOOTP service, so that the | |
289 | client can still automatically configure its address. This is done | |
290 | with the | |
291 | .B lease | |
292 | statement. | |
293 | .PP | |
294 | NOTE: the lease statement is also used in the dhclient.leases file in | |
295 | order to record leases that have been received from DHCP servers. | |
296 | Some of the syntax for leases as described below is only needed in the | |
297 | dhclient.leases file. Such syntax is documented here for | |
298 | completeness. | |
299 | .PP | |
300 | A lease statement consists of the lease keyword, followed by a left | |
301 | curly brace, followed by one or more lease declaration statements, | |
302 | followed by a right curly brace. The following lease declarations | |
303 | are possible: | |
304 | .PP | |
305 | \fBbootp;\fR | |
306 | .PP | |
307 | The | |
308 | .B bootp | |
309 | statement is used to indicate that the lease was acquired using the | |
310 | BOOTP protocol rather than the DHCP protocol. It is never necessary | |
311 | to specify this in the client configuration file. The client uses | |
312 | this syntax in its lease database file. | |
313 | .PP | |
314 | \fBinterface\fR \fB"\fR\fIstring\fR\fB";\fR | |
315 | .PP | |
316 | The | |
317 | .B interface | |
318 | lease statement is used to indicate the interface on which the lease | |
319 | is valid. If set, this lease will only be tried on a particular | |
320 | interface. When the client receives a lease from a server, it always | |
321 | records the interface number on which it received that lease. | |
322 | If predefined leases are specified in the dhclient.conf file, the | |
323 | interface should also be specified, although this is not required. | |
324 | .PP | |
325 | \fBfixed-address\fR \fIip-address\fR\fB;\fR | |
326 | .PP | |
327 | The | |
328 | .B fixed-address | |
329 | statement is used to set the ip address of a particular lease. This | |
330 | is required for all lease statements. The IP address must be | |
331 | specified as a dotted quad (e.g., 12.34.56.78). | |
332 | .PP | |
333 | \fBfilename "\fR\fIstring\fR\fB";\fR | |
334 | .PP | |
335 | The | |
336 | .B filename | |
337 | statement specifies the name of the boot filename to use. This is | |
338 | not used by the standard client configuration script, but is included | |
339 | for completeness. | |
340 | .PP | |
341 | \fBserver-name "\fR\fIstring\fR\fB";\fR | |
342 | .PP | |
343 | The | |
344 | .B server-name | |
345 | statement specifies the name of the boot server name to use. This is | |
346 | also not used by the standard client configuration script. | |
347 | .PP | |
348 | \fBoption\fR \fIoption-declaration\fR\fB;\fR | |
349 | .PP | |
350 | The | |
351 | .B option | |
352 | statement is used to specify the value of an option supplied by the | |
353 | server, or, in the case of predefined leases declared in | |
354 | dhclient.conf, the value that the user wishes the client configuration | |
355 | script to use if the predefined lease is used. | |
356 | .PP | |
357 | \fBscript "\fIscript-name\fB";\fR | |
358 | .PP | |
359 | The | |
360 | .B script | |
361 | statement is used to specify the pathname of the dhcp client | |
362 | configuration script. This script is used by the dhcp client to set | |
363 | each interface's initial configuration prior to requesting an address, | |
364 | to test the address once it has been offered, and to set the | |
365 | interface's final configuration once a lease has been acquired. If | |
366 | no lease is acquired, the script is used to test predefined leases, if | |
367 | any, and also called once if no valid lease can be identified. For | |
368 | more information, see | |
4bd8800e | 369 | .B dhclient-script(8). |
e7ec0fa1 TL |
370 | .PP |
371 | \fBmedium "\fImedia setup\fB";\fR | |
372 | .PP | |
373 | The | |
374 | .B medium | |
375 | statement can be used on systems where network interfaces cannot | |
376 | automatically determine the type of network to which they are | |
377 | connected. The media setup string is a system-dependent parameter | |
378 | which is passed to the dhcp client configuration script when | |
379 | initializing the interface. On Unix and Unix-like systems, the | |
380 | argument is passed on the ifconfig command line when configuring te | |
381 | interface. | |
382 | .PP | |
383 | The dhcp client automatically declares this parameter if it used a | |
384 | media type (see the | |
385 | .B media | |
386 | statement) when configuring the interface in order to obtain a lease. | |
387 | This statement should be used in predefined leases only if the network | |
388 | interface requires media type configuration. | |
389 | .PP | |
390 | \fBrenew\fR \fIdate\fB;\fR | |
391 | .PP | |
392 | \fBrebind\fR \fIdate\fB;\fR | |
393 | .PP | |
394 | \fBexpire\fR \fIdate\fB;\fR | |
395 | .PP | |
396 | The \fBrenew\fR statement defines the time at which the dhcp client | |
397 | should begin trying to contact its server to renew a lease that it is | |
398 | using. The \fBrebind\fR statement defines the time at which the dhcp | |
399 | client should begin to try to contact \fIany\fR dhcp server in order | |
400 | to renew its lease. The \fBexpire\fR statement defines the time at | |
401 | which the dhcp client must stop using a lease if it has not been able | |
402 | to contact a server in order to renew it. | |
403 | .PP | |
404 | These declarations are automatically set in leases acquired by the | |
405 | DHCP client, but must also be configured in predefined leases - a | |
406 | predefined lease whose expiry time has passed will not be used by the | |
407 | DHCP client. | |
408 | .PP | |
409 | Dates are specified as follows: | |
410 | .PP | |
411 | \fI<weekday> <year>\fB/\fI<month>\fB/\fI<day> | |
412 | <hour>\fB:\fI<minute>\fB:\fI<second>\fR | |
413 | .PP | |
414 | The weekday is present to make it easy for a human to tell when a | |
415 | lease expires - it's specified as a number from zero to six, with zero | |
416 | being Sunday. When declaring a predefined lease, it can always be | |
417 | specified as zero. The year is specified with the century, so it | |
418 | should generally be four digits except for really long leases. The | |
419 | month is specified as a number starting with 1 for January. The day | |
420 | of the month is likewise specified starting with 1. The hour is a | |
4f138ec5 TL |
421 | number between 0 and 23, the minute a number between 0 and 59, and the |
422 | second also a number between 0 and 59. | |
e7ec0fa1 TL |
423 | .SH ALIAS DECLARATIONS |
424 | \fBalias { \fI declarations ... \fB}\fR | |
425 | .PP | |
426 | Some DHCP clients running TCP/IP roaming protocols may require that in | |
427 | addition to the lease they may acquire via DHCP, their interface also | |
428 | be configured with a predefined IP alias so that they can have a | |
429 | permanent IP address even while roaming. The Internet Software | |
430 | Consortium DHCP client doesn't support roaming with fixed addresses | |
431 | directly, but in order to facilitate such experimentation, the dhcp | |
432 | client can be set up to configure an IP alias using the | |
433 | .B alias | |
434 | declaration. | |
435 | .PP | |
436 | The alias declaration resembles a lease declaration, except that | |
437 | options other than the subnet-mask option are ignored by the standard | |
438 | client configuration script, and expiry times are ignored. A typical | |
439 | alias declaration includes an interface declaration, a fixed-address | |
440 | declaration for the IP alias address, and a subnet-mask option | |
441 | declaration. A medium statement should never be included in an alias | |
442 | declaration. | |
443 | .SH OTHER DECLARATIONS | |
444 | \fBreject \fIip-address\fB;\fR | |
445 | .PP | |
446 | The reject statement causes the DHCP client to reject offers from | |
447 | servers who use the specified address as a server identifier. This | |
448 | can be used to avoid being configured by rogue or misconfigured dhcp | |
449 | servers, although it should be a last resort - better to track down | |
450 | the bad DHCP server and fix it. | |
451 | .PP | |
452 | \fBinterface "\fIname\fB" { \fIdeclarations ... \fB } | |
453 | .PP | |
454 | A client with more than one network interface may require different | |
455 | behaviour depending on which interface is being configured. All | |
456 | timing parameters and declarations other than lease and alias | |
457 | declarations can be enclosed in an interface declaration, and those | |
458 | parameters will then be used only for the interface that matches the | |
459 | specified name. Interfaces for which there is no interface | |
460 | declaration will use the parameters declared outside of any interface | |
461 | declaration, or the default settings. | |
a645ee2d TL |
462 | .PP |
463 | \fBpseudo "\fIname\fR" "\fIreal-name\fB" { \fIdeclarations ... \fB } | |
464 | .PP | |
465 | Under some circumstances it can be useful to declare a pseudo-interface | |
466 | and have the DHCP client acquire a configuration for that interface. | |
467 | Each interface that the DHCP client is supporting normally has a DHCP | |
468 | client state machine running on it to acquire and maintain its lease. | |
469 | A pseudo-interface is just another state machine running on the | |
470 | interface named \fIreal-name\fR, with its own lease and its own | |
471 | state. If you use this feature, you must provide a client identifier | |
472 | for both the pseudo-interface and the actual interface, and the two | |
473 | identifiers must be different. You must also provide a seperate | |
474 | client script for the pseudo-interface to do what you want with the IP | |
475 | address. For example: | |
476 | .PP | |
477 | .nf | |
478 | interface "ep0" { | |
479 | send dhcp-client-identifier "my-client-ep0"; | |
480 | } | |
481 | pseudo "secondary" "ep0" { | |
482 | send dhcp-client-identifier "my-client-ep0-secondary"; | |
483 | script "/etc/dhclient-secondary"; | |
484 | } | |
485 | .fi | |
486 | .PP | |
487 | The client script for the pseudo-interface should not configure the | |
488 | interface up or down - essentially, all it needs to handle are the | |
489 | states where a lease has been acquired or renewed, and the states | |
490 | where a lease has expired. See \fBdhclient-script(8)\fR for more | |
491 | information. | |
e7ec0fa1 TL |
492 | .PP |
493 | \fBmedia "\fImedia setup\fB"\fI [ \fB, "\fImedia setup\fB", \fI... ]\fB;\fR | |
494 | .PP | |
495 | The | |
496 | .B media | |
497 | statement defines one or more media configuration parameters which may | |
498 | be tried while attempting to acquire an IP address. The dhcp client | |
499 | will cycle through each media setup string on the list, configuring | |
500 | the interface using that setup and attempting to boot, and then trying | |
501 | the next one. This can be used for network interfaces which aren't | |
502 | capable of sensing the media type unaided - whichever media type | |
503 | succeeds in getting a request to the server and hearing the reply is | |
504 | probably right (no guarantees). | |
505 | .PP | |
506 | The media setup is only used for the initial phase of address | |
507 | acquisition (the DHCPDISCOVER and DHCPOFFER packtes). Once an | |
508 | address has been acquired, the dhcp client will record it in its lease | |
509 | database and will record the media type used to acquire the address. | |
510 | Whenever the client tries to renew the lease, it will use that same | |
511 | media type. The lease must expire before the client will go back to | |
512 | cycling through media types. | |
513 | .SH SAMPLE | |
514 | The following configuration file is used on a laptop running NetBSD | |
515 | 1.3. The laptop has an IP alias of 192.5.5.213, and has one | |
516 | interface, ep0 (a 3com 3C589C). Booting intervals have been | |
517 | shortened somewhat from the default, because the client is known to | |
518 | spend most of its time on networks with little DHCP activity. The | |
519 | laptop does roam to multiple networks. | |
520 | ||
521 | .nf | |
522 | ||
523 | timeout 60; | |
524 | retry 60; | |
525 | reboot 10; | |
526 | select-timeout 5; | |
527 | initial-interval 2; | |
528 | reject 192.33.137.209; | |
529 | ||
530 | interface "ep0" { | |
531 | send host-name "andare.fugue.com"; | |
532 | send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; | |
533 | send dhcp-lease-time 3600; | |
534 | supersede domain-name "fugue.com rc.vix.com home.vix.com"; | |
535 | prepend domain-name-servers 127.0.0.1; | |
536 | request subnet-mask, broadcast-address, time-offset, routers, | |
537 | domain-name, domain-name-servers, host-name; | |
538 | require subnet-mask, domain-name-servers; | |
539 | script "/etc/dhclient-script"; | |
540 | media "media 10baseT/UTP", "media 10base2/BNC"; | |
541 | } | |
542 | ||
543 | alias { | |
544 | interface "ep0"; | |
545 | fixed-address 192.5.5.213; | |
546 | option subnet-mask 255.255.255.255; | |
547 | } | |
548 | .fi | |
549 | This is a very complicated dhclient.conf file - in general, yours | |
550 | should be much simpler. In many cases, it's sufficient to just | |
551 | create an empty dhclient.conf file - the defaults are usually fine. | |
0e7affc7 | 552 | .SH SEE ALSO |
e97b2a17 | 553 | dhcp-options(5), dhclient.leases(5), dhcpd(8), dhcpd.conf(5), RFC2132, |
e7ec0fa1 | 554 | RFC2131. |
0e7affc7 TL |
555 | .SH AUTHOR |
556 | .B dhclient(8) | |
557 | was written by Ted Lemon <mellon@vix.com> | |
558 | under a contract with Vixie Labs. Funding | |
f39b6e00 | 559 | for this project was provided by the Internet Software Consortium. |
0e7affc7 TL |
560 | Information about the Internet Software Consortium can be found at |
561 | .B http://www.isc.org/isc. |