Internet Software Consortium
Dynamic Host Configuration Protocol Server
- Beta Release 1
- March 16, 1996
+ Beta Release 5
+ August 29, 1996
-This is the first Beta release of the Internet Software Consortium
+This is the fifth Beta release of the Internet Software Consortium
DHCP Server (ISC dhcpd). In this Beta release, support for the core
-DHCP protocol is provided. BOOTP support is also provided for
-backwards compatibility. The beta release currently runs on NetBSD
-and BSD/OS, and may run on Ultrix. It should port fairly easily to a
-variety of UNIX-like systems.
+DHCP and BOOTP protocols are provided. This release currently works
+well on Digital Alpha OSF/1, SunOS 4.1.4, NetBSD, FreeBSD and BSD/OS.
+It can also be run usefully on Solaris as long as only one network
+interface is being used. It also runs on Ultrix, QNX and Linux as
+long as only one network interface is present and a host route is
+added from that interface to the 255.255.255.255 broadcast address.
-The default Makefile is a 4.4BSD-style makefile. If you do not have
-access to a 4.4BSD-style make, use Makefile.std. This is an
-old-style makefile and should work on most systems.
+ BUILDING DHCPD
+
+To build dhcpd, 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. 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 systems
+mentioned above, please let us know. If you get errors on a system
+not mentioned above, you probably need to think about doing a port.
+
+ PORTING
If you want to attempt a port, the first thing to do is to make a copy
of one of the header files in cf/ for your system and hack the
variables you find there as needed. Hack osdep.h to conditionally
-include your header file when compiling on your system. This process
-is by no means self-explanatory at this point - it will get better as
-dhcpd matures. If you are building on BSD/os or NetBSD, just type
-make - it should build with no problem.
-
-In February, I brought ISC dhcpd to Connectathon and worked out
-many bugs. ISC dhcpd was able to boot all of the DHCP clients at
-Connectathon by the time I left. Many thanks to Audrey Van Belleghem
-for getting me in to Connectathon even though we weren't able to
-budget for it, to Mike Carney for running the DHCP testing in
-general and helping me out in particular, and to all the other DHCP
-Bakeoff participants at Connectathon who tried their clients against
-dhcpd and told me where it was busted, or, later on, that it wasn't
-busted anymore.
+include your header file when compiling on your system.
+
+DHCP servers require more of their network stack than most network
+servers do. A DHCP server must be able to tell which network
+interface a packet arrived on. If you have only one interface, this
+is easy, which is why dhcpd works on a lot of systems if you only have
+one network interface. If you have several network interfaces, dhcpd
+only works on systems for which some kind of low-level network
+interface support is present. Currently there are low-level network
+drivers for the Berkeley Packet Filter (BPF) and Sun's STREAMS Network
+Interface Tap (NIT). If you want to make dhcpd work really well on
+your favourite system, and it doesn't support NIT or BPF, you're going
+to need to implement a new low-level driver program along the lines of
+bpf.c or nit.c in order to make this happen.
+
+Even if you only need dhcpd to work on systems with a single
+interface, there can still be problems. Of all the systems dhcpd
+currently works on, only one (Solaris) has an IP stack that allows the
+all-ones broadcast address (255.255.255.255) to go out onto the
+network unchanged. Other systems insist on changing 255.255.255.255
+into the local subnet broadcast address (here, that's
+204.254.239.255). This results in a 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 DHCOPFFER responses from the server.
+
+It is possible to work around this problem on most such systems by
+creating a host route from your network interface address to
+255.255.255.255. On most systems, you do this with:
+
+ route add 255.255.255.255 <your-interface-address> 0
+
+or
+
+ route add -host 255.255.255.255 <your-interface-address>
+
+Some Linux systems work better with:
+
+ route add -host 255.255.255.255 dev <your-interface-name>
+
+On some systems, you will get error messages if you use the route
+command, but may succeed if you write a small program to do the system
+calls. It would be nice if dhcpd were to do this automatically.
+If you have a patch to do this, send it in! :')
+
DEBUGGING
daemon.debug: /var/log/daemon.log
-(obviously, change the filename to suit your taste).
+You may, of course, change the filename to suit your taste. Be sure
+that the log file actually exists before restarting syslogd. In
+addition to dhcp logging, you may also capture a lot of information
+from other daemons that you aren't interested in. If this is a
+problem, you may want to edit site.h and redefine the
+DHCPD_LOG_FACILITY macro to, for example, LOG_LOCAL7, and then use
+local7.debug instead of daemon.debug. You need to recompile and
+reinstall if you make this change.
-This change may have the unfortunate side effect of capturing a lot of
-information from daemons other than dhcpd that you don't want to look
-at.
+You can also specify the -d flag on the command line to have dhcpd log
+all of its output to standard error as well as to syslog. To run
+dhcpd under the debugger, supply the -f flag.
-You can also compile dhcpd with ``make DEBUG="-g -DDEBUG"''. If you
-do this, dhcpd will run in the foreground rather than as a daemon, and
-will print its log messages to standard error. It will also dump the
-contents of all packets it receives and sends.
+More verbose debugging information can be obtained by defining
+DEBUG_PACKET in site.h and recompiling. This will give you hex dumps
+and symbolic dumps of all DHCP packets that are successfully processed
+or are generated by dhcpd.
SUPPORT
-ISC DHCPD is not a commercial product, and is not supported in that sense.
-However, I am continuing to work on this server with the support of the
-Internet Software Consortium, so if you have trouble or want help, please
-free free to contact me, Ted Lemon <mellon@fugue.com>.
+ISC DHCPD 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 dhcpd-users@fugue.com mailing list.
-In addition, there are two mailing lists for dhcpd - dhcpd-announce and
-dhcpd-users. To subscribe, see http://www.fugue.com/dhcp/lists. If you
-don't have WWW access, you can send mail to dhcpd-request@fugue.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.
+If you are going to use dhcpd, you should probably subscribe to
+dhcpd-users, as well as dhcpd-announce. For details, please see
+http://www.fugue.com/dhcp/lists. If you don't have WorldWide Web
+access, you can send mail to dhcpd-request@fugue.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.
+PLEASE DO NOT SEND REQUESTS FOR SUPPORT DIRECTLY TO ME! The number
+of people using dhcpd 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.
BUGS
-Currently, ISC dhcpd supports the DHCP protocol with just the standard
-Berkeley socket interface to UDP/IP. This makes it very portable, but
-has several drawbacks. First of all, it is impossible to identify the
-interface on which a DHCP request was received. As a consequence,
-dhcpd currently exits if it discovers that it's running on a machine
-with more than one network address.
-
-Secondly, it is difficult to send a broadcast to the all-ones IP
-broadcast address as required by the DHCP protocol. I have had some
-luck on 4.4BSD-based systems declaring a route to 255.255.255.255
-through the local IP address, and have also found that some clients
-will accept broadcasts from the local subnet broadcast address. I
-would be interested in hearing about your experiences with this.
-
-A socket interface abstraction which can be layered atop sun's NIT or
-the Berkeley Packet Filter will be included in the next beta release,
-but probably won't work on as many systems. On those systems where
-it works, though, it will solve both the multiple interface problem
-and the all-ones broadcast problem.
-
This release of dhcpd does not contain support for DHCPINFORM.
Support for DHCPINFORM will be present in the next release.
DHCPINFORM is somewhat tangential to the main purpose of the DHCP
projects / thirdparty / dhcp.git / commitdiff
