File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / dhcp / README
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Oct 9 09:06:54 2012 UTC (11 years, 8 months ago) by misho
Branches: dhcp, MAIN
CVS tags: v4_1_R7p0, v4_1_R7, v4_1_R4, HEAD
dhcp 4.1 r7

    1: 	      Internet Systems Consortium DHCP Distribution
    2: 		           Version 4.1-ESV-R7
    3: 			   10 September 2012
    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: 
   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.
  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: 
  140: 	gunzip dhcp-4.1-ESV-R7.tar.gz
  141: 	tar xvf dhcp-4.1-ESV-R7.tar
  142: 
  143: 			    CONFIGURING IT
  144: 
  145: Now, cd to the dhcp-4.1-ESV-R7 subdirectory that you've just created and
  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>