environments where DHCP servers can be reasonably guaranteed to be
"down" when the failover TCP socket is severed, "auto-partner-down".
This parameter is not generally safe, and by default is disabled, so
please carefully review the documentation of this parameter in the
dhcpd.conf(5) manpage before determining to use it yourself.
[ISC-Bugs #19600]
in scheduling a failover reconnection, if the link had not negotiated a
failover connect yet (e.g.: connection refused, asynch socket connect()
timeouts). [ISC-Bugs #19684]
leak ~20-30 octets per DHCPDISCOVER packet while failover was in use
and in normal state. [ISC-Bugs #19548]
- Various compilation fixes have been included for the memory related
DEBUG #defines in includes/site.h. [ISC-Bugs #19548]
This is for my bug # 18914.
This is also documented in dhcpd.8 manual page.
(Still need to make sure dhcpd.8 is clear about the
purpose of atsfp and about any problems when upgrading.)
This feature is simply too experimental for right now, and causes
some problems to some failover installations. We will revisit this
in future releases. [ISC-Bugs #18832]
high frequency messages moved to a deeper debugging symbol.
- The CLTT parameter in failover is now only updated by client activity,
and not by failover binding updates (taking on the peer's CLTT).
- Failover BNDUPD messages are now discarded if they conflict with an
update that has been trasnmitted, but not acknowledged.
[ISC-Bugs #17577c]
not be applied to clients addressed within that network was repaired.
- When configuring a "subnet {}" or "subnet6 {}" without an explicit
shared-network enclosing it, the DHCP software would synthesize a
shared-network to contain the subnet. However, all configuration
parameters within the subnet more intuitively belong "to any client
on that interface", or rather the synthesized shared-network. So,
when a shared-network is synthesized, it is used to contain the
configuration present inside the subnet {} clause. This means that
the configuration will be valid for all clients on that network, not
just those addressed out of the stated subnet. If you intended the
opposite, the workaround is to explicitly configure an empty
shared-network.
- A bug was fixed where Information-Request processing was not sourcing
configured option values.
- A warning was added since the DHCPv6 processing software does not yet
support class statements.
[ISC-Bugs #17638b]
