Internet Software Consortium Dynamic Host Configuration Protocol Server Beta Release 5 August 29, 1996 This is the fifth Beta release of the Internet Software Consortium DHCP Server (ISC dhcpd). In this Beta release, support for the core 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. 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. 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 0 or route add -host 255.255.255.255 Some Linux systems work better with: route add -host 255.255.255.255 dev 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 dhcpd logs to LOG_DAEMON. Depending on the logging level that you choose with syslog, you can get quite a bit of information about what dhcpd is doing. To get the most logging, put the following in your /etc/syslog.conf file and restart syslog: daemon.debug: /var/log/daemon.log 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. 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. 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, 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. 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 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 protocol, so this probably won't be a major problem for most users. The man page for dhcpd.leases is not yet ready. The system is painful to configure. I will try to get GNU configure going in the next release.