README 6 KB
Newer Older
Ted Lemon's avatar
Ted Lemon committed
1 2
		     Internet Software Consortium
	      Dynamic Host Configuration Protocol Server
Ted Lemon's avatar
Ted Lemon committed
3 4
			    Beta Release 5
			   August 29, 1996
Ted Lemon's avatar
Ted Lemon committed
5

Ted Lemon's avatar
Ted Lemon committed
6
This is the fifth Beta release of the Internet Software Consortium
Ted Lemon's avatar
Ted Lemon committed
7
DHCP Server (ISC dhcpd).  In this Beta release, support for the core
Ted Lemon's avatar
Ted Lemon committed
8 9 10 11 12 13
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.
Ted Lemon's avatar
Ted Lemon committed
14

Ted Lemon's avatar
Ted Lemon committed
15 16 17 18 19 20 21 22 23 24 25
			    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
Ted Lemon's avatar
Ted Lemon committed
26

Ted Lemon's avatar
Ted Lemon committed
27 28 29
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
Ted Lemon's avatar
Ted Lemon committed
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
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!   :')

Ted Lemon's avatar
Ted Lemon committed
75

Ted Lemon's avatar
Ted Lemon committed
76 77 78 79 80 81 82 83 84
			      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

Ted Lemon's avatar
Ted Lemon committed
85 86 87 88 89 90 91 92
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.
Ted Lemon's avatar
Ted Lemon committed
93

Ted Lemon's avatar
Ted Lemon committed
94 95 96
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.
Ted Lemon's avatar
Ted Lemon committed
97

Ted Lemon's avatar
Ted Lemon committed
98 99 100 101
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.
Ted Lemon's avatar
Ted Lemon committed
102

Ted Lemon's avatar
Ted Lemon committed
103 104
			       SUPPORT

Ted Lemon's avatar
Ted Lemon committed
105 106 107 108 109
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.
Ted Lemon's avatar
Ted Lemon committed
110

Ted Lemon's avatar
Ted Lemon committed
111 112 113 114 115 116
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.
Ted Lemon's avatar
Ted Lemon committed
117

Ted Lemon's avatar
Ted Lemon committed
118 119 120 121
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.
Ted Lemon's avatar
Ted Lemon committed
122

Ted Lemon's avatar
Ted Lemon committed
123 124 125 126 127 128 129 130 131 132 133 134
				 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.