|author||David E. O'Brien <obrien@FreeBSD.org>||1999-02-10 09:10:13 +0000|
|committer||David E. O'Brien <obrien@FreeBSD.org>||1999-02-10 09:10:13 +0000|
Virgin import of ISC-DHCP v2.0b1pl6vendor/isc-dhcp/2.0b1-pl.6
Notes: svn path=/vendor/isc-dhcp/dist/; revision=43829 svn path=/vendor/isc-dhcp/2.0b1-pl.6/; revision=43831; tag=vendor/isc-dhcp/2.0b1-pl.6
Diffstat (limited to 'contrib/isc-dhcp/README')
1 files changed, 236 insertions, 0 deletions
diff --git a/contrib/isc-dhcp/README b/contrib/isc-dhcp/README
new file mode 100644
@@ -0,0 +1,236 @@
+ Internet Software Consortium
+ Dynamic Host Configuration Protocol Distribution
+ Version 2, Beta 1, Patchlevel 0
+ December 6, 1997
+This is the first Beta release of Version 2 of the Internet Software
+Consortium DHCP Distribution. In version 2.0, this distribution
+includes a DHCP server, a DHCP client, and a BOOTP/DHCP relay agent.
+This beta is believed to be fairly stable. However, DHCP server users
+running a production environment should probably still use version
+1.0, which is more stable, having been in a feature freeze since
+November of 1996.
+In this release, the server and relay agent currently work well on
+Digital Alpha OSF/1, SunOS 4.1.4, NetBSD, FreeBSD, BSD/OS and Ultrix.
+They can also be run usefully on Solaris as long as only one broadcast
+network interface is configured. They also runs on QNX and Linux as
+long as only one broadcast network interface is configured and a host
+route is added from that interface to the 255.255.255.255 broadcast
+address. If you are running a Linux 2.0.31 kernel, the DHCP daemons
+may be able to operate on more than one interface.
+The DHCP client currently only knows how to configure the network on
+NetBSD, FreeBSD, BSD/os, Linux, Solaris and NextStep. The client
+depends on a system-dependent shell script to do network
+configuration - support for other operating systems is simply a matter
+of porting this shell script to the new platform.
+If you wish to run the DHCP Distribution on Linux, please see the
+Linux-specific notes later in this document. If you wish to run on a
+SCO release, please see the SCO-specific notes later in this document.
+You particularly need to read these notes if you intend to support
+Windows 95 clients. If you are running a version of FreeBSD prior to
+2.2, please read the note on FreeBSD. If you are running HP-UX or
+Ultrix, please read the notes for those operating systems below.
+If you are running NeXTSTEP, please see the notes on NeXTSTEP below.
+If you start dhcpd and get a message, "no free bpf", that means you
+need to configure the Berkeley Packet Filter into your operating
+system kernel. On NetBSD, FreeBSD and BSD/os, type ``man bpf'' for
+information. On Digital Unix, type ``man pfilt''.
+ BUILDING THE DHCP DISTRIBUTION
+To build the DHCP Distribution, type ``configure''. If configure can
+figure out what sort of system you're running on, it will create a
+custom Makefile for you for that system; otherwise, it will complain.
+If it can't figure out what system you are using, that system is not
+supported - you are on your own.
+Once you've run configure, just type ``make'', and after a while you
+should have a dhcp server. If you get compile errors on one of the
+supported systems mentioned earlier, please let us know. If you get
+errors on a system not mentioned above, you will need to do some
+programming or debugging on your own to get the DHCP Distribution working.
+There are three big LINUX issues: the all-ones broadcast address,
+Linux 2.1 ip_bootp_agent enabling, and operations with more than one
+In order for dhcpd to work correctly with picky DHCP clients (e.g.,
+Windows 95), it must be able to send packets with an IP destination
+address of 255.255.255.255. Unfortunately, Linux insists on changing
+255.255.255.255 into the local subnet broadcast address (here, that's
+188.8.131.52). This results in a DHCP protocol violation, and while
+many DHCP clients don't notice the problem, some (e.g., all Microsoft
+DHCP clients) do. Clients that have this problem will appear not to
+see DHCPOFFER messages from the server.
+It is possible to work around this problem on some versions of Linux
+by creating a host route from your network interface address to
+255.255.255.255. The command you need to use to do this on Linux
+varies from version to version. The easiest version is:
+ route add -host 255.255.255.255 dev eth0
+On some older Linux systems, you will get an error if you try to do
+this. On those systems, try adding the following entry to your
+ route add -host all-ones dev eth0
+Another route that has worked for some users is:
+ route add -net 255.255.255.0 dev eth0
+If you are not using eth0 as your network interface, you should
+specify the network interface you *are* using in your route command.
+ IP BOOTP AGENT
+Some versions of the Linux 2.1 kernel apparently prevent dhcpd from
+working unless you enable it by doing the following:
+ echo 1 >/proc/sys/net/ipv4/ip_bootp_agent
+ MULTIPLE INTERFACES
+Most older versions of the Linux kernel do not provide a networking
+API that allows dhcpd to operate correctly if the system has more than
+one broadcast network interface. However, Linux 2.0 kernels with
+version numbers greater than or equal to 2.0.31 add an API feature:
+the SO_BINDTODEVICE socket option. If SO_BINDTODEVICE is present, it
+is possible for dhcpd to operate on Linux with more than one network
+interface. In order to take advantage of this, you must be running a
+2.0.31 or greater kernel, and you must have 2.0.31 system headers
+installed *before* you build dhcpd.
+NOTE: People have been having problems finding the 2.0.31 kernel
+because it was only available as a prerelease patch. As of October
+17, Linux 2.0.31 is the stable Linux kernel, and is available as a
+kernel distribution rather than as a test patch. With any luck, it
+will be in the latest version of your favourite Linux distribution
+If you are running a Linux 2.1 kernel, this does not guarantee that you
+have SO_BINDTODEVICE. Linux 2.0.31 was released quite a while after 2.1
+kernel development began. The earliest Linux kernel in the 2.1
+development stream with SO_BINDTODEVICE is version 2.1.68.
+We have heard reports that you must still add routes to 255.255.255.255
+in order for the all-ones broadcast to work, even on 2.0.31 kernels.
+In fact, you now need to add a route for each interface. Hopefully
+the Linux kernel gurus will get this straight eventually.
+SCO has the same problem as Linux (described earlier). The thing is,
+SCO *really* doesn't want to let you add a host route to the all-ones
+broadcast address. One technique that has been successful on some
+versions of SCO is the very bizarre command:
+ ifconfig net0 alias 10.1.1.1 netmask 184.108.40.206
+Apparently this works because of an interaction between SCO's support
+for network classes and the weird netmask. The 10.* network is just a
+dummy that can generally be assumed to be safe. Don't ask why this
+works. Just try it. If it works for you, great. If not, SCO is
+supposedly adding hooks to support real DHCP service in a future
+release - I have this on good authority from the people at SCO who do
+*their* DHCP server and client.
+HP-UX has the same problem with the all-ones broadcast address that
+SCO and Linux have. One user reported that adding the following to
+/etc/rc.config.d/netconf helped (you may have to modify this to suit
+your local configuration):
+Now that we have Ultrix packet filter support, the DHCP Distribution
+on Ultrix should be pretty trouble-free. However, one thing you do
+need to be aware of is that it now requires that the pfilt device be
+configured into your kernel and present in /dev. If you type ``man
+packetfilter'', you will get some information on how to configure your
+kernel for the packet filter (if it isn't already) and how to make an
+entry for it in /dev.
+Versions of FreeBSD prior to 2.2 have a bug in BPF support in that the
+ethernet driver swaps the ethertype field in the ethernet header
+downstream from BPF, which corrupts the output packet. If you are
+running a version of FreeBSD prior to 2.2, and you find that dhcpd
+can't communicate with its clients, you should #define BROKEN_FREEBSD_BPF
+in site.h and recompile.
+The NeXTSTEP support uses the NeXTSTEP Berkeley Packet Filter
+extension, which is not included in the base NextStep system. You
+must install this extension in order to get dhcpd or dhclient to work.
+The Internet Software Consortium DHCP server is not a commercial
+product, and is not supported in that sense. However, it has
+attracted a fairly sizable following on the Internet, which means that
+there are a lot of knowledgable users who may be able to help you if
+you get stuck. These people generally read the firstname.lastname@example.org
+If you are going to use dhcpd, you should probably subscribe to the
+dhcp-server and dhcp-announce mailing lists. If you will be using
+dhclient, you should subscribe to the dhcp-client mailing list.
+PLEASE DO NOT send queries about non-isc clients to the dhcp-client
+mailing list. If you're asking about them on an ISC mailing list,
+it's probably because you're using the ISC DHCP server, so ask there.
+Please see http://www.fugue.com/dhcp/lists for details on how to
+subscribe. If you don't have WorldWide Web access, you can send mail
+to email@example.com and tell me which lists you want to
+subscribe to, but please use the web interface if you can, since I
+have to handle the -request mailing list manually, and I will give you
+the third degree if you make me do your subscription manually.
+PLEASE DO NOT SEND REQUESTS FOR SUPPORT DIRECTLY TO ME! The number of
+people using the DHCP Distribution is sufficiently large that if I
+take an interrupt every time any one of those people runs into
+trouble, I will never get any more coding done.
+PLEASE DO NOT CALL ME ON THE PHONE FOR SUPPORT! Answering the phone
+takes a lot more of my time and attention than answering email. If you
+do call me on the phone, I will tell you to send email to the mailing
+list, and I won't answer your question, so there's no point in doing
+This release of the DHCP Distribution does not yet contain support for
+DHCPINFORM. Support for DHCPINFORM will be present in the release at
+a later time. DHCPINFORM is somewhat tangential to the main purpose
+of the DHCP protocol, so this probably won't be a major problem for
+Vendor tags and User tags are not currently supported.