Internet Software Consortium
Dynamic Host Configuration Protocol Distribution
- Development Snapshot
- November 22, 1997
-
-This is a development snapshot of work in progress on version 2.0 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. The engineering snapshot has become a lot
-more stable since the last snapshot, and will soon go into beta.
-However, DHCP server users running a production environment should
-probably still use the latest version on the 1.0 release branch, which
-is more stable, having been in a feature freeze since November of
-1996.
+ Version 3, Alpha Snapshot
+ February 13, 1998
+
+This is the first Alpha snapshot of Version 3 of the Internet Software
+Consortium DHCP Distribution. In version 3, this distribution
+includes a DHCP server, a DHCP client, and a BOOTP/DHCP relay agent.
+This alpha is believed to be relatively stable, but it is definitely
+not something you should be running in a production environment where
+stability is your highest priority.
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
+NetBSD, Linux, FreeBSD, BSD/OS, Ultrix, Digital Alpha OSF/1, and SunOS
+4.1.4. They can also be run usefully on Solaris as long as only one
+broadcast network interface is configured. They also runs on QNX 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.
+address. If you are running a Linux 2.0.30 or previous kernel, the
+DHCP daemons will only be able to operate on machines with a single
+network interface.
The DHCP client currently only knows how to configure the network on
NetBSD, FreeBSD, BSD/os, Linux, Solaris and NextStep. The client
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
+Linux-specific notes later in this document. If you wish to run on an
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
To build the DHCP Distribution, unpack the compressed tar file using
the tar utility and the gzip command - type something like:
- zcat dhcp-2.0b1pl6.tar.gz |tar xvf -
+ zcat dhcp-2.0b1pl12.tar.gz |tar xvf -
-Now, cd to the dhcp-2.0b1pl6 subdirectory that you've just created and
+Now, cd to the dhcp-2.0b1pl12 subdirectory that you've just created and
configure the source tree by typing:
./configure
can install it by typing ``make install''. If you already have an old
version of the DHCP Distribution installed, you may want to save it
before typing ``make install''.
-
+
LINUX
There are three big LINUX issues: the all-ones broadcast address,
Linux 2.1 ip_bootp_agent enabling, and operations with more than one
-network interface.
+network interface. There are also two potential compilation/runtime
+problems for Linux 2.1/2.2: the "SO_ATTACH_FILTER undeclared" problem
+and the "protocol not configured" problem.
+
+ LINUX: SO_ATTACH_FILTER UNDECLARED
+
+In addition, there is a minor issue that we will mention here because
+this release is so close on the heels of the Linux 2.2 release: there
+is a symlink in /usr/include that points at the linux asm headers. It
+appears to be not uncommon that this link won't be updated correctly,
+in which case you'll get the following error when you try to build:
+
+ lpf.c: In function `if_register_receive':
+ lpf.c:152: `SO_ATTACH_FILTER' undeclared (first use this function)
+ lpf.c:152: (Each undeclared identifier is reported only once
+ lpf.c:152: for each function it appears in.)
+
+The line numbers may be different, of course. If you see this
+header, your linux asm header link is probably bad, and you should
+make sure it's pointing to correct linux source directory.
+
+ LINUX: PROTOCOL NOT CONFIGURED
+
+One additional Linux 2.1/2.2 issue: if you get the following message,
+it's because your kernel doesn't have the linux packetfilter
+configured:
+
+ Can't install packet filter program: Protocol not available
+ exiting.
+
+If this happens, you need to edit your linux kernel .config file, set
+CONFIG_FILTER=y, and rebuild your kernel. If the preceding sentence
+made no sense to you, ask your Linux vendor/guru for help - please
+don't ask us.
- BROADCAST
+ LINUX: BROADCAST
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
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
+ LINUX: 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
+ LINUX: 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
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
-soon.
-
-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.
+2.0.31 or greater kernel, and you must have 2.0.31 or later system
+headers installed *before* you build the DHCP Distribution.
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.
LANCONFIG_ARGS[0]="ether"
DHCP_ENABLE[0]=0
-The above hack supposedly does not work on HP-UX version 9.x.
-However, another hack which supposedly _does_ work on 9.x is to add
-the following entry to your /etc/hosts or DNS database:
-
-255.255.255.255 all-ones
-
-Then modify the broadcast as follows (change to suit your
-configuration, of course):
-
-ifconfig lan0 [your ip addr] netmask [your netmask] broadcast all-ones
-
-I would appreciate any reports as to how well this works for you.
-
ULTRIX
Now that we have Ultrix packet filter support, the DHCP Distribution
extension, which is not included in the base NextStep system. You
must install this extension in order to get dhcpd or dhclient to work.
+ SOLARIS
+
+One problem which has been observed and is not fixed in this patchlevel
+has to do with using DLPI on Solaris 2.6 machines, probably only on Intel,
+but possibly also on SPARC. The symptom of this problem is that you never
+receive any DHCP packets. If you are running Solaris 2.6, and you
+encounter this symptom, and you are running the DHCP server on a machine
+with a single broadcast network interface, you may wish to edit the
+includes/site.h file and uncomment the #define USE_SOCKETS line. Then
+type ``make clean; make''.
+
SUPPORT
The Internet Software Consortium DHCP server is not a commercial
most users.
Vendor tags and User tags are not currently supported.
-
-
Internet Software Consortium
Dynamic Host Configuration Protocol Distribution
- Development Snapshot
+ Version 3, Alpha Snapshot
December 2, 1997
Release Notes
Version 1 of the ISC DHCP Distribution includes just a DHCP Server.
Version 1 has been in feature freeze since late 1996, and is quite
-stable. This is the release that we would expect most sites to run in
-production.
+stable. This is the release that we would expect very conservative
+sites to run in production, but it is no longer recommended.
Version 2 of the ISC DHCP Distribution adds a DHCP Client and a
DHCP/BOOTP Relay Agent to the DHCP Server that was offered in version
addresses other than the one the server knows they should be
using are disciplined quickly.
-This version is now in Beta testing, and is planned for release in
-mid-1998. It has a number of new features, and is the release that we
-would expect sites that want some stability but need the new lease
-testing feature, better NAKing, or need a client or relay agent. Note
-that it is possible to run the Version 1 server with the Version 2
-client.
+This version has been in a near feature freeze since January of 1998,
+has been in Beta test since then, and is planned for final release in
+mid-1999. It has a number of important features, and is the release
+that we would expect most sites to run. It is possible to run the
+Version 1 server with the Version 2 client at sites that want to be
+really conservative.
-Version 3 of the ISC DHCP Distribution will add Dynamic DNS Support,
+Version 3 of the ISC DHCP Distribution will add conditional behaviour,
+client classing, Dynamic DNS Support, DHCPv4 16-bit option codes,
asynchronous DNS query resolution, DHCP Authentication, and possibly
support for a DHCP Interserver Protocol and live querying of the DHCP
-database. This release is not expected to be stable in the near
-future, and is intended for sites that are in a position to
+database. Currently, only client classing and conditional behaviour
+have been implemented - the DNS code is waiting for an enhanced DNS
+resolver. The code has gone through a major internal restructuring
+which will help to support wider option codes, and possibly IPv6, as
+well as a more sensible memory allocation strategy. This release is
+running in producion at the ISC, but is not expected to be stable in
+the near future, and is intended for sites that are in a position to
experiment, or for sites that desperately need the new features.
- CHANGES
-
-- Use %ld to print pid_t and cast pid_t values to long to avoid
- inconsistent declarations between different POSIX flavours.
-
-- Add support for ARPHRD_IEEE802 (token ring) hardware type.
-
-- If we own an address and a client requests it, but we can't assign
- it to that client, we now NAK it so that the client doesn't try to
- reuse it.
-
- CHANGES FROM THE JUNE SNAPSHOT
-
-- Support for NeXTstep 3.x and 4.x
-
-- Added man pages for dhcpd.leases, dhclient-script, dhclient.leases
- and dhclient.conf. Move general documentation of DHCP options into
- a seperate man page which is referred to by the dhclient.conf and
- dhcpd.conf man pages.
-
-- Updated README to answer some frequently asked questions.
-
-- Fixed a bug in command-line interface specification in dhclient - it
- was formerly not possible to specify that only certain interfaces be
- configured.
-
-- Do not leave client scripts lying around in /tmp after they've been
- used unless the -D flag is specified.
-
-- Add a new, non-standard, not-guaranteed-to-stay-the-same system
- configuration status message server which can be used to trigger the
- client to recheck its address, e.g., after a laptop has been put to
- sleep and then awakened (this has yet to be documented).
-
-- Fix handling of media selection in the REBOOT phase - previously the
- media type would not be remembered, which could cause severe delays
- in reacquiring an address if the default media type was wrong.
-
-- Allocate space for a NUL terminator on the end of client options -
- this was previously overlooked, and could cause garbage characters
- to be written to the temporary client script files.
-
-- Use mkstemp if it's available.
-
-- Supply network number and broadcast address to the client script so
- that on systems that need these values, they don't need to be
- computed with an awk script.
-
-- Keep a PID file for the client and the relay agent, and have the
- relay agent background itself by default.
-
-- Add client script for bsd/os, fix many niggling bugs in existing
- client scripts and add support for static routing tables to all bsd
- scripts.
-
-- Add a -q option to the client, server and relay agent so that they
- can be started from /etc/rc scripts without spewing a bunch of
- garbage on the console. By default, all three daemons still print
- startup messages, since these are helpful in bug reporting.
-
-- Don't print anything to stderr or stdout after going into
- background.
-
-- Fix bug where hostname keyword was not being recognized in
- dhcpd.leases file, resulting in the loss of lease database entries.
-
-- Fix problem on some operating systems where zero-length ifreq
- structures were being offset incorrectly when scanning the interface
- list on startup.
-
-- Unless a BOOTP client requests it, never send more than 64 bytes of
- options.
-
-- Don't ping static leases, since we don't have a lease structure on
- the heap to work with later.
-
-- Fixed a compile problem on Solaris 2.6.
-
-- Support interface aliases on Solaris.
-
-- Print day and month with leading zero in lease files if less than
- ten, for easier parsing by perl/sed/awk scripts.
-
-- Never make the lease database world writable, even if dhcpd is
- invoked with a bogus umask.
-
-- Fix DHCPRELEASE handling (before, addressed would never be
- released.)
-
-- If there is more than one lease for a particular client on a
- particular network, find the lease the client is asking for so as to
- avoid a cycle of NAKs.
-
-- If a BOOTP request is received from a particular client and that
- client has previously received a DHCP address, make sure that we
- still find a valid BOOTP lease so that we don't cycle through
- addresses.
-
-- Remove server-identifier option from documentation, other than to
- document that it has been deprecated.
-
-- Don't give up if we get an EINTR or EAGAIN while polling or
- selecting - these return statuses can occur spuriously without
- indicating a fatal problem.
-
-- Do not select for exceptions, since we don't handle them. This was
- causing massive CPU consumption on some systems.
-
-- When a DHCP client has been assigned a fixed address but had
- previously had a lease, it will request the old leased address. In
- such an event, send a DHCPNAK so that it will discover its new
- static binding.
+ CHANGES SINCE VERSION 2.0
+
+- Support for conditional behaviour - i.e., what the client sends can
+ be used to determine what response the client gets, in a very
+ general way.
+
+- Support for client classing - that is, clients can be assigned to
+ classes based on what they send, and then address assignments can be
+ made based on the client's class. A per-class limit on the number
+ of addresses assignable can be made. It is possible to create new
+ classes on the fly based on a template, so that address limitations
+ can be done on a per-customer basis - e.g., when using relay agent
+ options, a particular customer's circuit ID can be used to classify
+ all hosts at the customer site as part of a class which is generated
+ on the fly the first time the circuit ID is seen. The class
+ template from which this class is created can specify a limit of,
+ say, four leases. This would have the effect of limiting all
+ customer sites behind relay agents that attach circuit IDs to the
+ packets they forward to a maximum of four leases each.
+
+- Support for DHCP authentication. This is based on code contributed
+ by the University of Pennsylvania, written by XXX
+
+- Memory allocation behaviour has been completely redone.
+
+- Support for more than one pool of addresses per network segment.
+ This permits different address
\ No newline at end of file
- Token ring support for bpf/nit interfaces
-- FDDI support for bpf/nit interfaces
+- FDDI support for bpf/nit interfaces (mostly done)
- Other network hardware support for low-level interfaces?
projects / thirdparty / dhcp.git / commitdiff
