Commit 3dcbf508 authored by Ted Lemon's avatar Ted Lemon
Browse files

Modernize

parent fa93f422
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
......@@ -29,7 +27,7 @@ configuration - support for other operating systems is simply a matter
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
......@@ -48,9 +46,9 @@ information. On Digital Unix, type ``man pfilt''.
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
......@@ -75,14 +73,47 @@ Once you have successfully gotten the DHCP Distribution to build, you
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
......@@ -117,7 +148,7 @@ Another route that has worked for some users is:
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:
......@@ -125,7 +156,7 @@ 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
......@@ -134,20 +165,8 @@ version numbers greater than or equal to 2.0.31 add an API feature:
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.
......@@ -185,19 +204,6 @@ BROADCAST_ADDRESS[0]="255.255.255.255"
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
......@@ -223,6 +229,17 @@ The NeXTSTEP support uses the NeXTSTEP Berkeley Packet Filter
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
......@@ -266,5 +283,3 @@ of the DHCP protocol, so this probably won't be a major problem for
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
......@@ -12,8 +12,8 @@ Software Consortium DHCP Distribution.
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
......@@ -32,129 +32,50 @@ server:
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
......@@ -18,7 +18,7 @@ Things to do, not in any particular order...
- 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?
......
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