Annotation of embedaddon/dhcp/README, revision 1.1.1.1
1.1 misho 1: Internet Systems Consortium DHCP Distribution
1.1.1.1 ! misho 2: Version 4.1-ESV-R7
! 3: 10 September 2012
1.1 misho 4:
5: README FILE
6:
7: You should read this file carefully before trying to install or use
8: the ISC DHCP Distribution.
9:
10: TABLE OF CONTENTS
11:
12: 1 WHERE TO FIND DOCUMENTATION
13: 2 RELEASE STATUS
14: 3 BUILDING THE DHCP DISTRIBUTION
15: 3.1 UNPACKING IT
16: 3.2 CONFIGURING IT
17: 3.2.1 DYNAMIC DNS UPDATES
18: 3.2.2 LOCALLY DEFINED OPTIONS
19: 3.3 BUILDING IT
20: 4 INSTALLING THE DHCP DISTRIBUTION
21: 5 USING THE DHCP DISTRIBUTION
22: 5.1 FIREWALL RULES
23: 5.2 LINUX
24: 5.2.1 IF_TR.H NOT FOUND
25: 5.2.2 SO_ATTACH_FILTER UNDECLARED
26: 5.2.3 PROTOCOL NOT CONFIGURED
27: 5.2.4 BROADCAST
28: 5.2.6 IP BOOTP AGENT
29: 5.2.7 MULTIPLE INTERFACES
30: 5.3 SCO
31: 5.4 HP-UX
32: 5.5 ULTRIX
33: 5.6 FreeBSD
34: 5.7 NeXTSTEP
35: 5.8 SOLARIS
36: 5.8.1 Solaris 11
37: 5.8.2 Other Solaris Items
38: 5.9 AIX
39: 5.10 MacOS X
40: 6 SUPPORT
41: 6.1 HOW TO REPORT BUGS
42:
43: WHERE TO FIND DOCUMENTATION
44:
45: Documentation for this software includes this README file, the
46: RELNOTES file, and the manual pages, which are in the server, common,
47: client and relay subdirectories. The README file (this file) includes
48: late-breaking operational and system-specific information that you
49: should read even if you don't want to read the manual pages, and that
50: you should *certainly* read if you run into trouble. Internet
51: standards relating to the DHCP protocol are stored in the doc
52: subdirectory. You will have the best luck reading the manual pages if
53: you build this software and then install it, although you can read
54: them directly out of the distribution if you need to.
55:
56: DHCP server documentation is in the dhcpd man page. Information about
57: the DHCP server lease database is in the dhcpd.leases man page.
58: Server configuration documentation is in the dhcpd.conf man page as
59: well as the dhcp-options man page. A sample DHCP server
60: configuration is in the file server/dhcpd.conf. The source for the
61: dhcpd, dhcpd.leases and dhcpd.conf man pages is in the server/ sub-
62: directory in the distribution. The source for the dhcp-options.5
63: man page is in the common/ subdirectory.
64:
65: DHCP Client documentation is in the dhclient man page. DHCP client
66: configuration documentation is in the dhclient.conf man page and the
67: dhcp-options man page. The DHCP client configuration script is
68: documented in the dhclient-script man page. The format of the DHCP
69: client lease database is documented in the dhclient.leases man page.
70: The source for all these man pages is in the client/ subdirectory in
71: the distribution. In addition, the dhcp-options man page should be
72: referred to for information about DHCP options.
73:
74: DHCP relay agent documentation is in the dhcrelay man page, the source
75: for which is distributed in the relay/ subdirectory.
76:
77: To read installed manual pages, use the man command. Type "man page"
78: where page is the name of the manual page. This will only work if
79: you have installed the ISC DHCP distribution using the ``make install''
80: command (described later).
81:
82: If you want to read manual pages that aren't installed, you can type
83: ``nroff -man page |more'' where page is the filename of the
84: unformatted manual page. The filename of an unformatted manual page
85: is the name of the manual page, followed by '.', followed by some
86: number - 5 for documentation about files, and 8 for documentation
87: about programs. For example, to read the dhcp-options man page,
88: you would type ``nroff -man common/dhcp-options.5 |more'', assuming
89: your current working directory is the top level directory of the ISC
90: DHCP Distribution.
91:
92: Please note that the pathnames of files to which our manpages refer
93: will not be correct for your operating system until after you iterate
94: 'make install' (so if you're reading a manpage out of the source
95: directory, it may not have up-to-date information).
96:
97: RELEASE STATUS
98:
1.1.1.1 ! misho 99: This is ISC DHCP 4.1-ESV-R7, an extended support (ESV) release that
! 100: provides patches for some security issues and several bugs.
1.1 misho 101:
102: ESVs are intended for users who have longer upgrade constraints
103: Please see our web page http://www.isc.org/downloads/extended-support
104: for more information on ESVs
105:
106: In this release, the DHCPv6 server should be fully functional on Linux,
107: Solaris, or any BSD. The DHCPv6 client should be similarly functional
108: except on Solaris.
109:
110: The DHCPv4 server, relay, and client, should be fully functional
111: on Linux, Solaris, any BSD, HPUX, SCO, NextSTEP, and Irix.
112:
113: If you are running the DHCP distribution on a machine which is a
114: firewall, or if there is a firewall between your DHCP server(s) and
115: DHCP clients, please read the section on firewalls which appears later
116: in this document.
117:
118: If you wish to run the DHCP Distribution on Linux, please see the
119: Linux-specific notes later in this document. If you wish to run on an
120: SCO release, please see the SCO-specific notes later in this document.
121: You particularly need to read these notes if you intend to support
122: Windows 95 clients. If you are running a version of FreeBSD prior to
123: 2.2, please read the note on FreeBSD. If you are running HP-UX or
124: Ultrix, please read the notes for those operating systems below. If
125: you are running NeXTSTEP, please see the notes on NeXTSTEP below.
126:
127: If you start dhcpd and get a message, "no free bpf", that means you
128: need to configure the Berkeley Packet Filter into your operating
129: system kernel. On NetBSD, FreeBSD and BSD/os, type ``man bpf'' for
130: information. On Digital Unix, type ``man pfilt''.
131:
132:
133: BUILDING THE DHCP DISTRIBUTION
134:
135: UNPACKING IT
136:
137: To build the DHCP Distribution, unpack the compressed tar file using
138: the tar utility and the gzip command - type something like:
139:
1.1.1.1 ! misho 140: gunzip dhcp-4.1-ESV-R7.tar.gz
! 141: tar xvf dhcp-4.1-ESV-R7.tar
1.1 misho 142:
143: CONFIGURING IT
144:
1.1.1.1 ! misho 145: Now, cd to the dhcp-4.1-ESV-R7 subdirectory that you've just created and
1.1 misho 146: configure the source tree by typing:
147:
148: ./configure
149:
150: If the configure utility can figure out what sort of system you're
151: running on, it will create a custom Makefile for you for that
152: system; otherwise, it will complain. If it can't figure out what
153: system you are using, that system is not supported - you are on
154: your own.
155:
156: DYNAMIC DNS UPDATES
157:
158: A fully-featured implementation of dynamic DNS updates is included in
159: this release. There are no build dependencies with any BIND version
160: - this version can and should just use the resolver in your C library.
161:
162: There is documentation for the DDNS support in the dhcpd.conf manual
163: page - see the beginning of this document for information on finding
164: manual pages.
165:
166: LOCALLY DEFINED OPTIONS
167:
168: In previous versions of the DHCP server there was a mechanism whereby
169: options that were not known by the server could be configured using
170: a name made up of the option code number and an identifier:
171: "option-nnn" This is no longer supported, because it is not future-
172: proof. Instead, if you want to use an option that the server doesn't
173: know about, you must explicitly define it using the method described
174: in the dhcp-options man page under the DEFINING NEW OPTIONS heading.
175:
176: BUILDING IT
177:
178: Once you've run configure, just type ``make'', and after a while
179: you should have a dhcp server. If you get compile errors on one
180: of the supported systems mentioned earlier, please let us know.
181: If you get warnings, it's not likely to be a problem - the DHCP
182: server compiles completely warning-free on as many architectures
183: as we can manage, but there are a few for which this is difficult.
184: If you get errors on a system not mentioned above, you will need
185: to do some programming or debugging on your own to get the DHCP
186: Distribution working.
187:
188: INSTALLING THE DHCP DISTRIBUTION
189:
190: Once you have successfully gotten the DHCP Distribution to build, you
191: can install it by typing ``make install''. If you already have an old
192: version of the DHCP Distribution installed, you may want to save it
193: before typing ``make install''.
194:
195: USING THE DHCP DISTRIBUTION
196:
197: FIREWALL RULES
198:
199: If you are running the DHCP server or client on a computer that's also
200: acting as a firewall, you must be sure to allow DHCP packets through
201: the firewall. In particular, your firewall rules _must_ allow packets
202: from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP port 68
203: to UDP port 67 through. They must also allow packets from your local
204: firewall's IP address and UDP port 67 through to any address your DHCP
205: server might serve on UDP port 68. Finally, packets from relay agents
206: on port 67 to the DHCP server on port 67, and vice versa, must be
207: permitted.
208:
209: We have noticed that on some systems where we are using a packet
210: filter, if you set up a firewall that blocks UDP port 67 and 68
211: entirely, packets sent through the packet filter will not be blocked.
212: However, unicast packets will be blocked. This can result in strange
213: behaviour, particularly on DHCP clients, where the initial packet
214: exchange is broadcast, but renewals are unicast - the client will
215: appear to be unable to renew until it starts broadcasting its
216: renewals, and then suddenly it'll work. The fix is to fix the
217: firewall rules as described above.
218:
219: PARTIAL SERVERS
220:
221: If you have a server that is connected to two networks, and you only
222: want to provide DHCP service on one of those networks (e.g., you are
223: using a cable modem and have set up a NAT router), if you don't write
224: any subnet declaration for the network you aren't supporting, the DHCP
225: server will ignore input on that network interface if it can. If it
226: can't, it will refuse to run - some operating systems do not have the
227: capability of supporting DHCP on machines with more than one
228: interface, and ironically this is the case even if you don't want to
229: provide DHCP service on one of those interfaces.
230:
231: LINUX
232:
233: There are three big LINUX issues: the all-ones broadcast address,
234: Linux 2.1 ip_bootp_agent enabling, and operations with more than one
235: network interface. There are also two potential compilation/runtime
236: problems for Linux 2.1/2.2: the "SO_ATTACH_FILTER undeclared" problem
237: and the "protocol not configured" problem.
238:
239: LINUX: PROTOCOL NOT CONFIGURED
240:
241: If you get the following message, it's because your kernel doesn't
242: have the linux packetfilter or raw packet socket configured:
243:
244: Make sure CONFIG_PACKET (Packet socket) and CONFIG_FILTER (Socket
245: Filtering) are enabled in your kernel configuration
246:
247: If this happens, you need to configure your Linux kernel to support
248: Socket Filtering and the Packet socket, or to select a kernel provided
249: by your Linux distribution that has these enabled (virtually all modern
250: ones do by default).
251:
252: LINUX: BROADCAST
253:
254: If you are running a recent version of Linux, this won't be a problem,
255: but on older versions of Linux (kernel versions prior to 2.2), there
256: is a potential problem with the broadcast address being sent
257: incorrectly.
258:
259: In order for dhcpd to work correctly with picky DHCP clients (e.g.,
260: Windows 95), it must be able to send packets with an IP destination
261: address of 255.255.255.255. Unfortunately, Linux changes an IP
262: destination of 255.255.255.255 into the local subnet broadcast address
263: (here, that's 192.5.5.223).
264:
265: This isn't generally a problem on Linux 2.2 and later kernels, since
266: we completely bypass the Linux IP stack, but on old versions of Linux
267: 2.1 and all versions of Linux prior to 2.1, it is a problem - pickier
268: DHCP clients connected to the same network as the ISC DHCP server or
269: ISC relay agent will not see messages from the DHCP server. It *is*
270: possible to run into trouble with this on Linux 2.2 and later if you
271: are running a verson of the DHCP server that was compiled on a Linux
272: 2.0 system, though.
273:
274: It is possible to work around this problem on some versions of Linux
275: by creating a host route from your network interface address to
276: 255.255.255.255. The command you need to use to do this on Linux
277: varies from version to version. The easiest version is:
278:
279: route add -host 255.255.255.255 dev eth0
280:
281: On some older Linux systems, you will get an error if you try to do
282: this. On those systems, try adding the following entry to your
283: /etc/hosts file:
284:
285: 255.255.255.255 all-ones
286:
287: Then, try:
288:
289: route add -host all-ones dev eth0
290:
291: Another route that has worked for some users is:
292:
293: route add -net 255.255.255.0 dev eth0
294:
295: If you are not using eth0 as your network interface, you should
296: specify the network interface you *are* using in your route command.
297:
298: LINUX: IP BOOTP AGENT
299:
300: Some versions of the Linux 2.1 kernel apparently prevent dhcpd from
301: working unless you enable it by doing the following:
302:
303: echo 1 >/proc/sys/net/ipv4/ip_bootp_agent
304:
305:
306: LINUX: MULTIPLE INTERFACES
307:
308: Very old versions of the Linux kernel do not provide a networking API
309: that allows dhcpd to operate correctly if the system has more than one
310: broadcast network interface. However, Linux 2.0 kernels with version
311: numbers greater than or equal to 2.0.31 add an API feature: the
312: SO_BINDTODEVICE socket option. If SO_BINDTODEVICE is present, it is
313: possible for dhcpd to operate on Linux with more than one network
314: interface. In order to take advantage of this, you must be running a
315: 2.0.31 or greater kernel, and you must have 2.0.31 or later system
316: headers installed *before* you build the DHCP Distribution.
317:
318: We have heard reports that you must still add routes to 255.255.255.255
319: in order for the all-ones broadcast to work, even on 2.0.31 kernels.
320: In fact, you now need to add a route for each interface. Hopefully
321: the Linux kernel gurus will get this straight eventually.
322:
323: Linux 2.1 and later kernels do not use SO_BINDTODEVICE or require the
324: broadcast address hack, but do support multiple interfaces, using the
325: Linux Packet Filter.
326:
327: LINUX: OpenWrt
328:
329: DHCP 4.1 has been tested on OpenWrt 7.09 and 8.09. In keeping with
330: standard practice, client/scripts now includes a dhclient-script file
331: for OpenWrt. However, this is not sufficient by itself to run dhcp on
332: OpenWrt; a full OpenWrt package for DHCP is available at
333: ftp://ftp.isc.org/isc/dhcp/dhcp-4.1.0-openwrt.tar.gz
334:
335: LINUX: 802.1q VLAN INTERFACES
336:
337: If you're using 802.1q vlan interfaces on Linux, it is necessary to
338: vconfig the subinterface(s) to rewrite the 802.1q information out of
339: packets received by the dhcpd daemon via LPF:
340:
341: vconfig set_flag eth1.523 1 1
342:
343: Note that this may affect the performance of your system, since the
344: Linux kernel must rewrite packets received via this interface. For
345: more information, consult the vconfig man pages.
346:
347: SCO
348:
349: ISC DHCP will now work correctly on newer versions of SCO out of the
350: box (tested on OpenServer 5.05b, assumed to work on UnixWare 7).
351:
352: Older versions of SCO have the same problem as Linux (described earlier).
353: The thing is, SCO *really* doesn't want to let you add a host route to
354: the all-ones broadcast address.
355:
356: You can try the following:
357:
358: ifconfig net0 xxx.xxx.xxx.xxx netmask 0xNNNNNNNN broadcast 255.255.255.255
359:
360: If this doesn't work, you can also try the following strange hack:
361:
362: ifconfig net0 alias 10.1.1.1 netmask 8.0.0.0
363:
364: Apparently this works because of an interaction between SCO's support
365: for network classes and the weird netmask. The 10.* network is just a
366: dummy that can generally be assumed to be safe. Don't ask why this
367: works. Just try it. If it works for you, great.
368:
369: HP-UX
370:
371: HP-UX has the same problem with the all-ones broadcast address that
372: SCO and Linux have. One user reported that adding the following to
373: /etc/rc.config.d/netconf helped (you may have to modify this to suit
374: your local configuration):
375:
376: INTERFACE_NAME[0]=lan0
377: IP_ADDRESS[0]=1.1.1.1
378: SUBNET_MASK[0]=255.255.255.0
379: BROADCAST_ADDRESS[0]="255.255.255.255"
380: LANCONFIG_ARGS[0]="ether"
381: DHCP_ENABLE[0]=0
382:
383: ULTRIX
384:
385: Now that we have Ultrix packet filter support, the DHCP Distribution
386: on Ultrix should be pretty trouble-free. However, one thing you do
387: need to be aware of is that it now requires that the pfilt device be
388: configured into your kernel and present in /dev. If you type ``man
389: packetfilter'', you will get some information on how to configure your
390: kernel for the packet filter (if it isn't already) and how to make an
391: entry for it in /dev.
392:
393: FreeBSD
394:
395: Versions of FreeBSD prior to 2.2 have a bug in BPF support in that the
396: ethernet driver swaps the ethertype field in the ethernet header
397: downstream from BPF, which corrupts the output packet. If you are
398: running a version of FreeBSD prior to 2.2, and you find that dhcpd
399: can't communicate with its clients, you should #define BROKEN_FREEBSD_BPF
400: in site.h and recompile.
401:
402: Modern versions of FreeBSD include the ISC DHCP 3.0 client as part of
403: the base system, and the full distribution (for the DHCP server and
404: relay agent) is available from the Ports Collection in
405: /usr/ports/net/isc-dhcp3, or as a package on FreeBSD installation
406: CDROMs.
407:
408: NeXTSTEP
409:
410: The NeXTSTEP support uses the NeXTSTEP Berkeley Packet Filter
411: extension, which is not included in the base NextStep system. You
412: must install this extension in order to get dhcpd or dhclient to work.
413:
414: SOLARIS
415:
416: Solaris 11
417:
418: We have integrated a patch from Oracle to use sockets instead of
419: DLPI on Solaris 11. This functionality was written for use with
420: Solaris Studio 12.2 and requires the system/header package.
421:
422: By default this code is disabled in order to minimize disruptions
423: for current users. In order to enable this code you will need to
424: enable both USE_SOCKETS and USE_V4_PKTINFO as part of the
425: configuration step. The command line would be something like:
426:
427: ./configure --enable-use-sockets --enable-ipv4-pktinfo
428:
429: Other Solaris Items
430:
431: One problem which has been observed and is not fixed in this
432: patchlevel has to do with using DLPI on Solaris machines. The symptom
433: of this problem is that the DHCP server never receives any requests.
434: This has been observed with Solaris 2.6 and Solaris 7 on Intel x86
435: systems, although it may occur with other systems as well. If you
436: encounter this symptom, and you are running the DHCP server on a
437: machine with a single broadcast network interface, you may wish to
438: edit the includes/site.h file and uncomment the #define USE_SOCKETS
439: line. Then type ``make clean; make''. As an alternative workaround,
440: it has been reported that running 'snoop' will cause the dhcp server
441: to start receiving packets. So the practice reported to us is to run
442: snoop at dhcpd startup time, with arguments to cause it to receive one
443: packet and exit.
444:
445: snoop -c 1 udp port 67 > /dev/null &
446:
447: The DHCP client on Solaris will only work with DLPI. If you run it
448: and it just keeps saying it's sending DHCPREQUEST packets, but never
449: gets a response, you may be having DLPI trouble as described above.
450: If so, we have no solution to offer at this time, aside from the above
451: workaround which should also work here. Also, because Solaris requires
452: you to "plumb" an interface before it can be detected by the DHCP client,
453: you must either specify the name(s) of the interface(s) you want to
454: configure on the command line, or must plumb the interfaces prior to
455: invoking the DHCP client. This can be done with ``ifconfig iface plumb'',
456: where iface is the name of the interface (e.g., ``ifconfig hme0 plumb'').
457:
458: It should be noted that Solaris versions from 2.6 onward include a
459: DHCP client that you can run with ``/sbin/ifconfig iface dhcp start''
460: rather than using the ISC DHCP client, including DHCPv6. Consequently,
461: we don't believe there is a need for the client to run on Solaris, and
462: have not engineered the needed DHCPv6 modifications for the dhclient-script.
463: If you feel this is in error, or have a need, please contact us.
464:
465: AIX
466:
467: The AIX support uses the BSD socket API, which cannot differentiate on
468: which network interface a broadcast packet was received; thus the DHCP
469: server and relay will work only on a single interface. (They do work
470: on multi-interface machines if configured to listen on only one of the
471: interfaces.)
472:
473: We have reports of Windows XP clients having difficutly retrieving
474: addresses from a server running on an AIX machine. This issue
475: was traced to the client requiring messages be sent to the all ones
476: broadcast address (255.255.255.255) while the AIX server was sending
477: to 192.168.0.255.
478:
479: You may be able to solve this by including a relay between the client
480: and server with the relay configured to use a broadcast of all-ones.
481:
482: A second option that worked for AIX 5.1 but doesn't seem to work for
483: AIX 5.3 was to:
484: create a host file entry for all-ones (255.255.255.255)
485: and then add a route:
486: route add -host all-ones -interface <local-ip-address>
487:
488: The ISC DHCP distribution does not include a dhclient-script for AIX--
489: AIX comes with a DHCP client. Contribution of a working dhclient-script
490: for AIX would be welcome.
491:
492:
493: MacOS X
494:
495: The MacOS X system uses a TCP/IP stack derived from FreeBSD with a
496: user-friendly interface named the System Configuration Framework.
497: As it includes a builtin DHCPv4 client (you are better just using that),
498: this text is only about the DHCPv6 client (``dhclient -6 ...''). The DNS
499: configuration (domain search list and name servers' addresses) is managed
500: by a System Configuration agent, not by /etc/resolv.conf (which is a link
501: to /var/run/resolv.conf, which itself only reflects the internal state;
502: the System Configuration framework's Dynamic Store).
503:
504: This means that modifying resolv.conf directly doesn't have the
505: intended effect, instead the macos script sample creates its own
506: resolv.conf.dhclient6 in /var/run, and inserts the contents of this
507: file into the Dynamic Store.
508:
509: When updating the address configuration the System Configuration
510: framework expects the prefix and a default router along with the
511: configured address. As this extra information is not available via
512: the DHCPv6 protocol the System Configuration framework isn't usable
513: for address configuration, instead ifconfig is used directly.
514:
515: Note the Dynamic Store (from which /var/run/resolv.conf is built) is
516: recomputed from scratch when the current location/set is changed.
517: Running the dhclient-script reinstalls the resolv.conf.dhclient6
518: configuration.
519:
520: SUPPORT
521:
522: The Internet Systems Consortium DHCP server is developed and distributed
523: by ISC in the public trust, thanks to the generous donations of its
524: sponsors. ISC now also offers commercial quality support contracts for
525: ISC DHCP, more information about ISC Support Contracts can be found at
526: the following URL:
527:
528: https://www.isc.org/services/support/
529:
530: Please understand that we may not respond to support inquiries unless
531: you have a support contract. ISC will continue its practice of always
532: responding to critical items that effect the entire community, and
533: responding to all other requests for support upon ISC's mailing lists
534: on a best-effort basis.
535:
536: However, ISC DHCP has attracted a fairly sizable following on the
537: Internet, which means that there are a lot of knowledgeable users who
538: may be able to help you if you get stuck. These people generally
539: read the dhcp-users@isc.org mailing list. Be sure to provide as much
540: detail in your query as possible.
541:
542: If you are going to use ISC DHCP, you should probably subscribe to
543: the dhcp-users or dhcp-announce mailing lists.
544:
545: WHERE TO SEND FEATURE REQUESTS: We like to hear your feedback. We may
546: not respond to it all the time, but we do read it. If ISC DHCP doesn't
547: work well for you, or you have an idea that would improve it for your
548: use, please send your suggestion to dhcp-suggest@isc.org. This is also
549: an excellent place to send patches that add new features.
550:
551: WHERE TO REPORT BUGS: If you want the act of sending in a bug report
552: to result in you getting help in the form of a fixed piece of
553: software, you are asking for help. Your bug report is helpful to us,
554: but fundamentally you are making a support request, so please use the
555: addresses described in the previous paragraphs. If you are _sure_ that
556: your problem is a bug, and not user error, or if your bug report
557: includes a patch, you can send it to our ticketing system at
558: dhcp-bugs@isc.org. If you have not received a notice that the ticket
559: has been resolved, then we're still working on it.
560:
561: PLEASE DO NOT REPORT BUGS IN OLD SOFTWARE RELEASES! Fetch the latest
562: release and see if the bug is still in that version of the software,
563: and if it's not, _then_ report it. ISC release versions always have
564: three numbers, for example: 1.2.3. The 'major release' is 1 here,
565: the 'minor release' is 2, and the 'maintenance release' is 3. ISC
566: will accept bug reports against the most recent two major.minor
567: releases: for example, 1.0.0 and 0.9.0, but not 0.8.* or prior.
568:
569: PLEASE take a moment to determine where the ISC DHCP distribution
570: that you're using came from. ISC DHCP is sometimes heavily modified
571: by integrators in various operating systems - it's not that we
572: feel that our software is perfect and incapable of having bugs, but
573: rather that it is very frustrating to find out after many days trying
574: to help someone that the sources you're looking at aren't what they're
575: running. When in doubt, please retrieve the source distribution from
576: ISC's web page and install it.
577:
578: HOW TO REPORT BUGS OR REQUEST HELP
579:
580: When you report bugs or ask for help, please provide us complete
581: information. A list of information we need follows. Please read it
582: carefully, and put all the information you can into your initial bug
583: report. This will save us a great deal of time and more informative
584: bug reports are more likely to get handled more quickly overall.
585:
586: 1. The specific operating system name and version of the
587: machine on which the DHCP server or client is running.
588: 2. The specific operating system name and version of the
589: machine on which the client is running, if you are having
590: trouble getting a client working with the server.
591: 3. If you're running Linux, the version number we care about is
592: the kernel version and maybe the library version, not the
593: distribution version - e.g., while we don't mind knowing
594: that you're running Redhat version mumble.foo, we must know
595: what kernel version you're running, and it helps if you can
596: tell us what version of the C library you're running,
597: although if you don't know that off the top of your head it
598: may be hard for you to figure it out, so don't go crazy
599: trying.
600: 4. The specific version of the DHCP distribution you're
601: running, as reported by dhcpd -t.
602: 5. Please explain the problem carefully, thinking through what
603: you're saying to ensure that you don't assume we know
604: something about your situation that we don't know.
605: 6. Include your dhcpd.conf and dhcpd.leases file as MIME attachments
606: if they're not over 100 kilobytes in size each. If they are
607: this large, please make them available to us eg via a hidden
608: http:// URL or FTP site. If you're not comfortable releasing
609: this information due to sensitive contents, you may encrypt
610: the file to our release signing key, available on our website.
611: 7. Include a log of your server or client running until it
612: encounters the problem - for example, if you are having
613: trouble getting some client to get an address, restart the
614: server with the -d flag and then restart the client, and
615: send us what the server prints. Likewise, with the client,
616: include the output of the client as it fails to get an
617: address or otherwise does the wrong thing. Do not leave
618: out parts of the output that you think aren't interesting.
619: 8. If the client or server is dumping core, please run the
620: debugger and get a stack trace, and include that in your
621: bug report. For example, if your debugger is gdb, do the
622: following:
623:
624: gdb dhcpd dhcpd.core
625: (gdb) where
626: [...]
627: (gdb) quit
628:
629: This assumes that it's the dhcp server you're debugging, and
630: that the core file is in dhcpd.core.
631:
632: Please see https://www.isc.org/software/dhcp/ for details on how to subscribe
633: to the ISC DHCP mailing lists.
634:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to README CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / dhcp