function of the same name and presents the results as a data expression.
This function can be used to incorporate the system level hostname of
the system the DHCP software is operating on in responses or queries (such
as including a failover partner's hostname in a dhcp message or binding
scope, or having a DHCP client send any system hostname in the host-name or
FQDN options by default). [ISC-Bugs #17351]
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]
been repaired. Other USE_ overrides should work better. [ISC-Bugs #19434]
- A check for the local flavor of IFNAMSIZ had a broken 'else' condition,
that probably still resulted in the correct behaviour (but wouldn't use
a larger defined value provided by the host OS). [ISC-Bugs #19434]
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]
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]
no matter how many interfaces are involved, differentiating the
interfaces the packets were received on by the interface index supplied
by the OS.
- The relay agent no longer listens to the All DHCP Servers Multicast
address.
- A bug was fixed in data_string_sprintfa() where va_start was only called
once for two invocations of vsprintf() variants.
[ISC-Bugs #17610b]
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]
