From: Ted Lemon <source@isc.org>
Date: Thu, 25 Jun 1998 21:56:33 +0000 (+0000)
Subject: Pull up 1.2
X-Git-Tag: V2-BETA-1-PATCH-3~6
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9f25306216f459359f0d3b4465d1fec7d5f020b1;p=thirdparty%2Fdhcp.git

Pull up 1.2
---

diff --git a/server/dhcpd.leases.5 b/server/dhcpd.leases.5
index 17231b9eb..291407c63 100644
--- a/server/dhcpd.leases.5
+++ b/server/dhcpd.leases.5
@@ -68,7 +68,81 @@ DBDIR/dhcpd.leases~ to DBDIR/dhcpd.leases, restoring the old, valid
 lease file, and then start dhcpd.   This guarantees that a valid lease
 file will be restored.
 .SH FORMAT
-The format of the lease declarations is not currently documented.
+Lease descriptions are stored in a format that is parsed by the same
+recursive descent parser used to read the
+.B dhcpd.conf(5)
+and
+.B dhclient.conf(5)
+files.   Currently, the only declaration that is
+used in the dhcpd.leases file is the 
+.B lease
+declaration.
+.PP
+ \fBlease \fIip-address\fB { \fIstatements...\fB }
+.PP
+Each lease declaration include the single IP address that has been
+leased to the client.   The statements within the braces define the
+duration of the lease and to whom it is assigned.
+.PP
+The start and end time of a lease are recorded using the ``starts''
+and ``ends'' statements:
+.PP
+ \fB starts \fIdate\fB;\fR
+ \fB ends \fIdate\fB;\fR
+.PP
+Dates are specified as follows:
+.PP
+ \fIweekday year\fB/\fImonth\fB/\fIday
+hour\fB:\fIminute\fB:\fIsecond\fR
+.PP
+The weekday is present to make it easy for a human to tell when a
+lease expires - it's specified as a number from zero to six, with zero
+being Sunday.  When declaring a predefined lease, it can always be
+specified as zero.  The year is specified with the century, so it
+should generally be four digits except for really long leases.  The
+month is specified as a number starting with 1 for January.  The day
+of the month is likewise specified starting with 1.  The hour is a
+number between 0 and 23, the minute a number between 0 and 59, and the
+second also a number between 0 and 59.
+.PP
+The MAC address of the network interface that was used to acquire the
+lease is recorded with the \fBhardware\fR statement:
+.PP
+ \fBhardware \fIhardware-type mac-address\fB;\fR
+.PP
+The MAC address is specified as a series of hexadecimal octets,
+seperated by colons.
+.PP
+If the client used a client identifier to acquire its address, the
+client identifier is recorded using the \fBuid\fR statement:
+.PP
+ \fBuid \fIclient-identifier\fB;\fR
+.PP
+The client identifier is recorded as a series of hexadecimal octets,
+regardless of whether the client specifies an ASCII string or uses the
+newer hardware type/MAC address format.
+.PP
+If the client sends a hostname using the \fIClient Hostname\fR option,
+as specified in some versions of the DHCP-DNS Interaction draft, that
+hostname is recorded using the \fBclient-hostname\fR statement.
+.PP
+ \fBclient-hostname "\fIhostname\fB";\fR
+.PP
+If the client sends its hostname using the \fIHostname\fR option, as
+Windows 95 does, it is recorded using the \fBhostname\fR statement.
+.PP
+ \fBhostname "\fIhostname\fB";\fR
+.PP
+The DHCP server may determine that a lease has been misused in some
+way, either because a client that has been assigned a lease NAKs it,
+or because the server's own attempt to see if an address is in use
+prior to reusing it reveals that the address is in fact already in
+use.   In that case, the \fBabandoned\fR statement will be used to
+indicate that the lease should never again be assigned.   Abandoned
+leases must currently be reclaimed by stopping the server, editing the
+abandoned lease out of the lease file, and restarting the server.
+.PP
+ \fBabandoned;\fR
 .SH FILES
 .B DBDIR/dhcpd.leases
 .SH SEE ALSO