ISC DHCP 3.0.4b1 has been released.
David W. Hankins
David_Hankins at isc.org
Fri Oct 21 21:55:31 UTC 2005
*** From dhcp-announce -- To unsubscribe, see the end of this message. ***
ISC DHCP 3.0.4b1 is now available. This BETA release fixes several bugs
in the release versions 3.0.3 and prior.
The major bugs fixed in this release are failover related; reducing the
probability of lease free/backup misbalance, and enhancing corner cases
where lease state inconsistencies may ocurr.
NOTE: This adds a new value to leases important to the failover state
engine, the 'atsfp' value. The contents of this field are used to
determine wether or not the lease is a candidate to be retransmitted
to the peer upon recovery from communications-interrupted or similar
disconnects. The value is zeroed upon changes that are to propogate
to the peer, signaling with certainty that this must come to pass.
Since your dhcpd.leases file will not have this value, the server will
choose to retransmit all leases once upon upgrading. You may wish to
manufacture 'atsfp' values from 'tsfp' lines in your existing
dhcpd.leases database as part of upgrading to avoid this.
For a complete list of changes from any previous release, please
consult the RELNOTES file within the source distribution, or on our
This release, and its OpenPGP-signature is available now from:
ISC's Release Signing Key can be obtained at:
Changes since 3.0.3
- A DDNS update handling function was misusing the DNS error codes, rather
than the internal generic result enumeration. The result is a confusing
syslog line, logging the wrong condition.
- The DHCP Server was not checking pool balance in the case where it brought
a non-ACTIVE lease out of storage for a client that was returning to use
a lease it once had long ago, and had since expired.
- Failover peers no longer bother to look for free leases to allocate when
they already found the client's ACTIVE lease. DISCOVERs are load balanced
wether freely-allocated or not, unless the server doubts the peer has
leases to allocate.
- Fixed a bug in dhcrelay agent addition code that suppressed trailing
PAD options - it was suppressing only one trailng PAD option, rather
than the entire block of them.
- Fixed some unlikely overlapping-region memcpy() bugs in dhcrelay agent
option addition and stripping code. Added a few sanity checks.
- Added some sanity checks to OMAPI connection/authentication code.
- dmalloc() memset()'s the non-debug (data) portion of the allocated
memory to zero. Code that memset()'s the result returned by dmalloc() to
zero is redundant. These redundancies were removed.
- Some type declaration corrections to u_int16_t were made in common/tr.c
(Token Ring support) thanks to a patch from Jason Vas Dias at RedHat.
- A failover bug that was allowing leases that EXPIRED or were RELEASED
where tsfp and tstp are identical timestamps to languish in these
transitional states has been repaired. As a side effect, lease
databases should be kept more consistent overall, not just for these
- If the lease db is deleted out from under the daemon, and it moves to rewrite
the db, it will go ahead with the operation and move the new db into place
once it detects the old db does not exist.
- dhclient now ignores IRDA, SIT, and IEEE1394 network interfaces, as it
is either nonsensical or (in the case of IEEE1394) is not known to support
these interfaces. Thanks to Marius Gedminas and Andrew Pollock of Debian.
- Some previously undocumented reasons for dhclient-script invoking has
been doucmented in the dhclient-script.8 manpage.
- Failover potential expiry calculations (TSTP) have been corrected. Results
should be substantially more consistent, and proper given the constraints.
- Adjusted lease state validation checks in potential-conflict, to
account for possible clock skew similarly to normal state, and several
previously illegal transitions were made legal (ex: active->released).
- An impossible sanity check was removed from omapi/buffer.c, thanks to a
patch from 'infamous42md'.
- An OMAPI host/network byte order problem in lease time values has been
- Several minor bugs, largely relating to treating 8-byte time values as
4-byte entities, have been repaired after careful review of the FreeBSD
ports collection's patch set. Thanks to the nameless entities who have
contributed to the FreeBSD ports.
- When writing a trace file, the file is now created with permissions 0600,
to help administrators avoid accidentally publicising sensitive config
- The calculation of the maximum size of DHCP packets no longer includes
Ethernet framing overhead. The result is that the 'Maximum Message
Size' option advertised by clients, or the default value 576, is no
longer reduced by 14 bytes, and instead directly reflects the IP level
MTU (and the default, minimum allowed IP MTU of 576).
- The special status of RELEASED/EXPIRED/RESET leases when a server
is operating in partner-down was fixed. It no longer requires a
lease be twice the MCLT beyond STOS to 'reallocate', and the expiry
event to turn these into FREE leases without peer acknowledgement
(after STOS+MCLT) has been repaired.
- Compilation on older Solaris systems (lacking /usr/include/sys/int_types.h)
has been repaired.
- "append"ing a string onto the end of a "t" type option (such as the
domain-name field) that had been improperly NULL-terminated by the
DHCP server will no longer result in a truncated string containing
only the option from the server, and not the expected appended value.
Thanks to a patch from Jason Vas Dias at RedHat.
- File handlers on configuration state (config files and lease dbs) should
be treated consistently, regardless of wether TRACING is defined or not.
- The linux build environment has had some minor improvements - better
sensing of 64-bit pointer sizes (only used for establishing an icmp_id),
and corrections to #if operators regarding LINUX_MAJOR should it ever
move to 3..x.
- The server now tries harder to survive the condition where it is unable
to open a new lease file to rewrite the lease state database.
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
To unsubscribe from this list, visit http://www.isc.org/dhcp-lists.html
or send mail to dhcp-announce-request at isc.org with the subject line of
More information about the dhcp-announce