Commit 7751e60d authored by Ted Lemon's avatar Ted Lemon
Browse files

Bring README into 20th century

parent 971170f7
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 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.
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.
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 ( to go out onto the
network unchanged. Other systems insist on changing
into the local subnet broadcast address (here, that's 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 On most systems, you do this with:
route add <your-interface-address> 0
route add -host <your-interface-address>
Some Linux systems work better with:
route add -host 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! :')
......@@ -41,53 +82,46 @@ dhcpd is doing. To get the most logging, put the following in your
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
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.
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 <>.
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 mailing list.
In addition, there are two mailing lists for dhcpd - dhcpd-announce and
dhcpd-users. To subscribe, see If you
don't have WWW access, you can send mail to 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 If you don't have WorldWide Web
access, you can send mail to 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.
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.
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
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
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment