<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY mdash  "&#x2014;" >
<!ENTITY % version SYSTEM "version.ent">
%version;
]>
<!--
     This XML document is generated using the system_messages tool
     based on the .mes message files.

     Do not edit this file.
-->
<book>
  <?xml-stylesheet href="kea-guide.css" type="text/css"?>

  <bookinfo>
    <title>Kea Messages Manual</title>

    <copyright>
      <year>2011-2015</year><holder>Internet Systems Consortium, Inc.</holder>
    </copyright>

    <abstract>
      <para>
        This is the messages manual for Kea version &__VERSION__;.
            The most up-to-date version of this document, along with
            other documents for Kea, can be found at
        <ulink url="http://kea.isc.org/docs"/>.
      </para>
    </abstract>

    <releaseinfo>This is the messages manual for Kea version
        &__VERSION__;.</releaseinfo>
  </bookinfo>

  <chapter id="intro">
    <title>Introduction</title>
    <para>
      This document lists each message that can be logged by the
      programs in the Kea package.  Each entry in this manual
      is of the form:
      <screen>IDENTIFICATION message-text</screen>
      ... where "IDENTIFICATION" is the message identification included
      in each message logged and "message-text" is the accompanying
      message text.  The "message-text" may include placeholders of the
      form "%1", "%2" etc.; these parameters are replaced by relevant
      values when the message is logged.
    </para>
    <para>
      Each entry is also accompanied by a description giving more
      information about the circumstances that result in the message
      being logged.
    </para>
    <para>
      For information on configuring and using Kea logging,
      refer to the <ulink url="kea-guide.html">Kea Guide</ulink>.
    </para>
  </chapter>

  <chapter id="messages">
    <title>Kea Log Messages</title>

  <section id="ALLOC">
    <title>ALLOC Module</title>
    <para>
      <variablelist>
<varlistentry id="ALLOC_ENGINE_LEASE_RECLAIMED">
<term>ALLOC_ENGINE_LEASE_RECLAIMED successfully reclaimed lease %1</term>
<listitem><para>
This debug message is logged when the allocation engine successfully
reclaims a lease. The lease is now available for assignment.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_REMOVAL_NCR_FAILED">
<term>ALLOC_ENGINE_REMOVAL_NCR_FAILED sending removal name change request failed for lease %1: %2</term>
<listitem><para>
This error message is logged when sending a removal name change request
to DHCP DDNS failed. This name change request is usually generated when
the lease reclamation routine acts upon expired leases. If a lease being
reclaimed has a corresponding DNS entry it needs to be removed.
This message indicates that removal of the DNS entry has failed.
Nevertheless the lease will be reclaimed.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_ALLOC_ERROR">
<term>ALLOC_ENGINE_V4_ALLOC_ERROR %1: error during attempt to allocate an IPv4 address: %2</term>
<listitem><para>
An error occurred during an attempt to allocate an IPv4 address, the
reason for the failure being contained in the message.  The server will
return a message to the client refusing a lease. The first argument
includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_ALLOC_FAIL">
<term>ALLOC_ENGINE_V4_ALLOC_FAIL %1: failed to allocate an IPv4 address after %2 attempt(s)</term>
<listitem><para>
The DHCP allocation engine gave up trying to allocate an IPv4 address
after the specified number of attempts.  This probably means that the
address pool from which the allocation is being attempted is either
empty, or very nearly empty.  As a result, the client will have been
refused a lease. The first argument includes the client identification
information.
</para><para>
This message may indicate that your address pool is too small for the
number of clients you are trying to service and should be expanded.
Alternatively, if the you know that the number of concurrently active
clients is less than the addresses you have available, you may want to
consider reducing the lease lifetime.  In this way, addresses allocated
to clients that are no longer active on the network will become available
sooner.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_DECLINED_RECOVERED">
<term>ALLOC_ENGINE_V4_DECLINED_RECOVERED IPv4 address %1 was recovered after %2 seconds of probation-period</term>
<listitem><para>
This informational message indicates that the specified address was reported
as duplicate (client sent DECLINE) and the server marked this address as
unvailable for a period of time. This time now has elapsed and the address
has been returned to the available pool. This step concludes decline recovery
process.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT">
<term>ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT %1: conflicting reservation for address %2 with existing lease %3</term>
<listitem><para>
This warning message is issued when the DHCP server finds that the
address reserved for the client can't be offered because this address
is currently allocated to another client. The server will try to allocate
a different address to the client to use until the conflict is resolved.
The first argument includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_DISCOVER_HR">
<term>ALLOC_ENGINE_V4_DISCOVER_HR client %1 sending DHCPDISCOVER has reservation for the address %2</term>
<listitem><para>
This message is issued when the allocation engine determines that the
client sending the DHCPDISCOVER has a reservation for the specified
address. The allocation engine will try to offer this address to
the client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE">
<term>ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed %1 leases in %2</term>
<listitem><para>
This debug message is logged when the allocation engine completes
reclamation of a set of expired leases. The maximum number of leases
to be reclaimed in a single pass of the lease reclamation routine
is configurable using 'max-reclaim-leases' parameter. However,
the number of reclaimed leases may also be limited by the timeout
value, configured with 'max-reclaim-time'. The message includes the
number of reclaimed leases and the total time.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_LEASES_RECLAMATION_SLOW">
<term>ALLOC_ENGINE_V4_LEASES_RECLAMATION_SLOW expired leases still exist after %1 reclamations</term>
<listitem><para>
This warning message is issued when the server has been unable to
reclaim all expired leases in a specified number of consecutive
attempts. This indicates that the value of "reclaim-timer-wait-time"
may be too high. However, if this is just a short burst of leases'
expirations the value does not have to be modified and the server
should deal with this in subsequent reclamation attempts. If this
is a result of a permanent increase of the server load, the value
of "reclaim-timer-wait-time" should be decreased, or the
values of "max-reclaim-leases" and "max-reclaim-time" should be
increased to allow processing more leases in a single cycle.
Alternatively, these values may be set to 0 to remove the
limitations on the number of leases and duration. However, this
may result in longer periods of server's unresponsiveness to
DHCP packets, while it processes the expired leases.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_LEASES_RECLAMATION_START">
<term>ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = %1 leases or %2 milliseconds)</term>
<listitem><para>
This debug message is issued when the allocation engine starts the
reclamation of the expired leases. The maximum number of leases to
be reclaimed and the timeout is included in the message. If any of
these values is 0, it means "unlimited".
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_LEASES_RECLAMATION_TIMEOUT">
<term>ALLOC_ENGINE_V4_LEASES_RECLAMATION_TIMEOUT timeout of %1 ms reached while reclaiming IPv4 leases</term>
<listitem><para>
This debug message is issued when the allocation engine hits the
timeout for performing reclamation of the expired leases. The
reclamation will now be interrupted and all leases which haven't
been reclaimed, because of the timeout, will be reclaimed when the
next scheduled reclamation is started. The argument is the timeout
value expressed in milliseconds.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_LEASE_RECLAIM">
<term>ALLOC_ENGINE_V4_LEASE_RECLAIM %1: reclaiming expired lease for address %2</term>
<listitem><para>
This debug message is issued when the server begins reclamation of the
expired DHCPv4 lease. The first argument specifies the client identification
information. The second argument holds the leased IPv4 address.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_LEASE_RECLAMATION_FAILED">
<term>ALLOC_ENGINE_V4_LEASE_RECLAMATION_FAILED failed to reclaim the lease %1: %2</term>
<listitem><para>
This error message is logged when the allocation engine fails to
reclaim an expired lease. The reason for the failure is included in the
message. The error may be triggered in the lease expiration hook or
while performing the operation on the lease database.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES">
<term>ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed</term>
<listitem><para>
This debug message is issued when the server reclaims all expired
DHCPv4 leases in the database.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_OFFER_EXISTING_LEASE">
<term>ALLOC_ENGINE_V4_OFFER_EXISTING_LEASE allocation engine will try to offer existing lease to the client %1</term>
<listitem><para>
This message is issued when the allocation engine determines that
the client has a lease in the lease database, it doesn't have
reservation for any other lease, and the leased address is not
reserved for any other client. The allocation engine will try
to offer the same lease to the client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_OFFER_NEW_LEASE">
<term>ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client %1</term>
<listitem><para>
This message is issued when the allocation engine will try to
offer a new lease to the client. This is the case when the
client doesn't have any existing lease, it has no reservation
or the existing or reserved address is leased to another client.
Also, the client didn't specify a hint, or the address in
the hint is in use.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_OFFER_REQUESTED_LEASE">
<term>ALLOC_ENGINE_V4_OFFER_REQUESTED_LEASE allocation engine will try to offer requested lease %1 to the client %2</term>
<listitem><para>
This message is issued when the allocation engine will try to
offer the lease specified in the hint. This situation may occur
when: (a) client doesn't have any reservations, (b) client has
reservation but the reserved address is leased to another client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE">
<term>ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than %1 seconds ago</term>
<listitem><para>
This debug message is issued when the allocation engine begins
deletion of the reclaimed leases which have expired more than
a specified number of seconds ago. This operation is triggered
periodically according to the "flush-reclaimed-timer-wait-time"
parameter. The "hold-reclaimed-time" parameter defines a number
of seconds for which the leases are stored before they are
removed.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE">
<term>ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted %1 expired-reclaimed leases</term>
<listitem><para>
This debug message is issued when the server successfully deletes
"expired-reclaimed" leases from the lease database. The number of
deleted leases is included in the log message.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED">
<term>ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: %1</term>
<listitem><para>
This error message is issued when the deletion of "expired-reclaimed"
leases from the database failed. The error message is appended to
the log message.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_ADDRESS_RESERVED">
<term>ALLOC_ENGINE_V4_REQUEST_ADDRESS_RESERVED %1: requested address %2 is reserved</term>
<listitem><para>
This message is issued when the allocation engine refused to
allocate address requested by the client because this
address is reserved for another client. The first argument
includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED">
<term>ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED %1: trying to allocate requested address %2</term>
<listitem><para>
This message is issued when the allocation engine is trying
to allocate (or reuse an expired) address which has been
requested by the client. The first argument includes the
client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE">
<term>ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE %1: extending lifetime of the lease for address %2</term>
<listitem><para>
This message is issued when the allocation engine determines
that the client already has a lease whose lifetime can be
extended, and which can be returned to the client.
The first argument includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_INVALID">
<term>ALLOC_ENGINE_V4_REQUEST_INVALID client %1 having a reservation for address %2 is requesting invalid address %3</term>
<listitem><para>
This message is logged when the client, having a reservation for
one address, is requesting a different address. The client is
only allowed to do this when the reserved address is in use by
another client. However, the allocation engine has
determined that the reserved address is available and the
client should request the reserved address.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_IN_USE">
<term>ALLOC_ENGINE_V4_REQUEST_IN_USE %1: requested address %2 is in use</term>
<listitem><para>
This message is issued when the client is requesting or has a
reservation for an address which is in use. The first argument
includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_OUT_OF_POOL">
<term>ALLOC_ENGINE_V4_REQUEST_OUT_OF_POOL client %1, which doesn't have a reservation, requested address %2 out of the dynamic pool</term>
<listitem><para>
This message is issued when the client has requested allocation
of the address which doesn't belong to any address pool from
which addresses are dynamically allocated. The client also
doesn't have reservation for this address. This address
could only be allocated if the client had reservation for it.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_PICK_ADDRESS">
<term>ALLOC_ENGINE_V4_REQUEST_PICK_ADDRESS client %1 hasn't specified an address - picking available address from the pool</term>
<listitem><para>
This message is logged when the client hasn't specified any
preferred address (the client should always do it, but Kea
tries to be forgiving). The allocation engine will try to pick an available
address from the dynamic pool and allocate it to the client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_REMOVE_LEASE">
<term>ALLOC_ENGINE_V4_REQUEST_REMOVE_LEASE %1: removing previous client's lease %2</term>
<listitem><para>
This message is logged when the allocation engine removes previous
lease for the client because the cliet has been allocated new one.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REQUEST_USE_HR">
<term>ALLOC_ENGINE_V4_REQUEST_USE_HR client %1 hasn't requested specific address, using reserved address %2</term>
<listitem><para>
This message is issued when the client is not requesting any specific
address but the allocation engine has determined that there is a
reservation for this client. The allocation engine will try to
allocate the reserved address.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V4_REUSE_EXPIRED_LEASE_DATA">
<term>ALLOC_ENGINE_V4_REUSE_EXPIRED_LEASE_DATA %1: reusing expired lease, updated lease information: %2</term>
<listitem><para>
This message is logged when the allocation engine is reusing
an existing lease. The details of the updated lease are
printed. The first argument includes the client identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_ALLOC_ERROR">
<term>ALLOC_ENGINE_V6_ALLOC_ERROR %1: error during attempt to allocate an IPv6 address: %2</term>
<listitem><para>
An error occurred during an attempt to allocate an IPv6 address, the
reason for the failure being contained in the message.  The server will
return a message to the client refusing a lease. The first argument
includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_ALLOC_FAIL">
<term>ALLOC_ENGINE_V6_ALLOC_FAIL %1: failed to allocate an IPv6 address after %2 attempt(s)</term>
<listitem><para>
The DHCP allocation engine gave up trying to allocate an IPv6 address
after the specified number of attempts.  This probably means that the
address pool from which the allocation is being attempted is either
empty, or very nearly empty.  As a result, the client will have been
refused a lease. The first argument includes the client identification
information.
</para><para>
This message may indicate that your address pool is too small for the
number of clients you are trying to service and should be expanded.
Alternatively, if the you know that the number of concurrently active
clients is less than the addresses you have available, you may want to
consider reducing the lease lifetime.  In this way, addresses allocated
to clients that are no longer active on the network will become available
available sooner.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_ALLOC_HR_LEASE_EXISTS">
<term>ALLOC_ENGINE_V6_ALLOC_HR_LEASE_EXISTS %1: lease type %2 for reserved address/prefix %3 already exists</term>
<listitem><para>
This debug message is issued when the allocation engine determines that
the lease for the IPv6 address or prefix has already been allocated
for the client and the client can continue using it. The first argument
includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_ALLOC_LEASES_HR">
<term>ALLOC_ENGINE_V6_ALLOC_LEASES_HR leases and static reservations found for client %1</term>
<listitem><para>
This message is logged when the allocation engine is in the process of
allocating leases for the client, it found existing leases and static
reservations for the client. The allocation engine will verify if
existing leases match reservations. Those leases that are reserved for
other clients and those that are not reserved for the client will
be removed. All leases matching the reservations will be renewed
and returned.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_ALLOC_LEASES_NO_HR">
<term>ALLOC_ENGINE_V6_ALLOC_LEASES_NO_HR no reservations found but leases exist for client %1</term>
<listitem><para>
This message is logged when the allocation engine is in the process if
allocating leases for the client, there are no static reservations,
but lease(s) exist for the client. The allocation engine will remove
leases which are reserved for other clients, and return all
remaning leases to the client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR">
<term>ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR no leases found but reservations exist for client %1</term>
<listitem><para>
This message is logged when the allocation engine is in the process of
allocating leases for the client. It hasn't found any existing leases
for this client, but the client appears to have static reservations.
The allocation engine will try to allocate the reserved resources for
the client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_ALLOC_NO_V6_HR">
<term>ALLOC_ENGINE_V6_ALLOC_NO_V6_HR %1: unable to allocate reserved leases - no IPv6 reservations</term>
<listitem><para>
This message is logged when the allocation engine determines that the
client has no IPv6 reservations and thus the allocation engine will have
to try to allocate allocating leases from the dynamic pool or stop
the allocation process if none can be allocated. The first argument
includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_ALLOC_UNRESERVED">
<term>ALLOC_ENGINE_V6_ALLOC_UNRESERVED no static reservations available - trying to dynamically allocate leases for client %1</term>
<listitem><para>
This debug message is issued when the allocation engine will attempt
to allocate leases from the dynamic pools.  This may be due to one of
(a) there are no reservations for this client, (b) there are
reservations for the client but they are not usable because the addresses
are in use by another client or (c) we had a reserved lease but that
has now been allocated to another client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_DECLINED_RECOVERED">
<term>ALLOC_ENGINE_V6_DECLINED_RECOVERED IPv6 address %1 was recovered after %2 seconds of probation-period</term>
<listitem><para>
This informational message indicates that the specified address was reported
as duplicate (client sent DECLINE) and the server marked this address as
unvailable for a period of time. This time now has elapsed and the address
has been returned to the available pool. This step concludes decline recovery
process.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_EXPIRED_HINT_RESERVED">
<term>ALLOC_ENGINE_V6_EXPIRED_HINT_RESERVED %1: expired lease for the client's hint %2 is reserved for another client</term>
<listitem><para>
This message is logged when the allocation engine finds that the
expired lease for the client's hint can't be reused because it
is reserved for another client. The first argument includes the
client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_EXTEND_ALLOC_UNRESERVED">
<term>ALLOC_ENGINE_V6_EXTEND_ALLOC_UNRESERVED allocate new (unreserved) leases for the renewing client %1</term>
<listitem><para>
This debug message is issued when the allocation engine is trying to
allocate new leases for the renewing client because it was unable to
renew any of the existing client's leases, e.g. because leases are
reserved for another client or for any other reason.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_EXTEND_ERROR">
<term>ALLOC_ENGINE_V6_EXTEND_ERROR %1: allocation engine experienced error with attempting to extend lease lifetime: %2</term>
<listitem><para>
This error message indicates that an error was experienced during Renew
or Rebind processing. Additional explanation is provided with this
message. Depending on its nature, manual intervention may be required to
continue processing messages from this particular client; other clients
will be unaffected. The first argument includes the client identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_EXTEND_LEASE">
<term>ALLOC_ENGINE_V6_EXTEND_LEASE %1: extending lifetime of the lease type %2, address %3</term>
<listitem><para>
This debug message is issued when the allocation engine is trying
to extend lifetime of the lease. The first argument includes the
client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_EXTEND_LEASE_DATA">
<term>ALLOC_ENGINE_V6_EXTEND_LEASE_DATA %1: detailed information about the lease being extended: %2</term>
<listitem><para>
This debug message prints detailed information about the lease which
lifetime is being extended (renew or rebind). The first argument
includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_EXTEND_NEW_LEASE_DATA">
<term>ALLOC_ENGINE_V6_EXTEND_NEW_LEASE_DATA %1: new lease information for the lease being extended: %2</term>
<listitem><para>
This debug message prints updated information about the lease to be
extended. If the lease update is successful, the information printed
by this message will be stored in the database. The first argument
includes the client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_HINT_RESERVED">
<term>ALLOC_ENGINE_V6_HINT_RESERVED %1: lease for the client's hint %2 is reserved for another client</term>
<listitem><para>
This message is logged when the allocation engine cannot allocate
the lease using the client's hint because the lease for this hint
is reserved for another client. The first argument includes the
client identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_HR_ADDR_GRANTED">
<term>ALLOC_ENGINE_V6_HR_ADDR_GRANTED reserved address %1 was was assigned to client %2</term>
<listitem><para>
This informational message signals that the specified client was assigned the address
reserved for it.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_HR_PREFIX_GRANTED">
<term>ALLOC_ENGINE_V6_HR_PREFIX_GRANTED reserved prefix %1/%2 was was assigned to client %3</term>
<listitem><para>
This informational message signals that the specified client was assigned the prefix
reserved for it.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_LEASES_RECLAMATION_COMPLETE">
<term>ALLOC_ENGINE_V6_LEASES_RECLAMATION_COMPLETE reclaimed %1 leases in %2</term>
<listitem><para>
This debug message is logged when the allocation engine completes
reclamation of a set of expired leases. The maximum number of leases
to be reclaimed in a single pass of the lease reclamation routine
is configurable using 'max-reclaim-leases' parameter. However,
the number of reclaimed leases may also be limited by the timeout
value, configured with 'max-reclaim-time'. The message includes the
number of reclaimed leases and the total time.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_LEASES_RECLAMATION_SLOW">
<term>ALLOC_ENGINE_V6_LEASES_RECLAMATION_SLOW expired leases still exist after %1 reclamations</term>
<listitem><para>
This warning message is issued when the server has been unable to
reclaim all expired leases in a specified number of consecutive
attempts. This indicates that the value of "reclaim-timer-wait-time"
may be too high. However, if this is just a short burst of leases'
expirations the value does not have to be modified and the server
should deal with this in subsequent reclamation attempts. If this
is a result of a permanent increase of the server load, the value
of "reclaim-timer-wait-time" should be decreased, or the
values of "max-reclaim-leases" and "max-reclaim-time" should be
increased to allow processing more leases in a single cycle.
Alternatively, these values may be set to 0 to remove the
limitations on the number of leases and duration. However, this
may result in longer periods of server's unresponsiveness to
DHCP packets, while it processes the expired leases.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_LEASES_RECLAMATION_START">
<term>ALLOC_ENGINE_V6_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = %1 leases or %2 milliseconds)</term>
<listitem><para>
This debug message is issued when the allocation engine starts the
reclamation of the expired leases. The maximum number of leases to
be reclaimed and the timeout is included in the message. If any of
these values is 0, it means "unlimited".
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_LEASES_RECLAMATION_TIMEOUT">
<term>ALLOC_ENGINE_V6_LEASES_RECLAMATION_TIMEOUT timeout of %1 ms reached while reclaiming IPv6 leases</term>
<listitem><para>
This debug message is issued when the allocation engine hits the
timeout for performing reclamation of the expired leases. The
reclamation will now be interrupted and all leases which haven't
been reclaimed, because of the timeout, will be reclaimed when the
next scheduled reclamation is started. The argument is the timeout
value expressed in milliseconds.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_LEASE_RECLAIM">
<term>ALLOC_ENGINE_V6_LEASE_RECLAIM %1: reclaiming expired lease for prefix %2/%3</term>
<listitem><para>
This debug message is issued when the server begins reclamation of the
expired DHCPv6 lease. The reclaimed lease may either be an address lease
or delegated prefix. The first argument provides the client identification
information. The other arguments specify the prefix and the prefix length
for the lease. The prefix length for address lease is equal to 128.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_LEASE_RECLAMATION_FAILED">
<term>ALLOC_ENGINE_V6_LEASE_RECLAMATION_FAILED failed to reclaim the lease %1: %2</term>
<listitem><para>
This error message is logged when the allocation engine fails to
reclaim an expired lease. The reason for the failure is included in the
message. The error may be triggered in the lease expiration hook or
while performing the operation on the lease database.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_NO_MORE_EXPIRED_LEASES">
<term>ALLOC_ENGINE_V6_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed</term>
<listitem><para>
This debug message is issued when the server reclaims all expired
DHCPv6 leases in the database.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE">
<term>ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than %1 seconds ago</term>
<listitem><para>
This debug message is issued when the allocation engine begins
deletion of the reclaimed leases which have expired more than
a specified number of seconds ago. This operation is triggered
periodically according to the "flush-reclaimed-timer-wait-time"
parameter. The "hold-reclaimed-time" parameter defines a number
of seconds for which the leases are stored before they are
removed.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_COMPLETE">
<term>ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted %1 expired-reclaimed leases</term>
<listitem><para>
This debug message is issued when the server successfully deletes
"expired-reclaimed" leases from the lease database. The number of
deleted leases is included in the log message.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_FAILED">
<term>ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: %1</term>
<listitem><para>
This error message is issued when the deletion of "expired-reclaimed"
leases from the database failed. The error message is appended to
the log message.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_RENEW_HR">
<term>ALLOC_ENGINE_V6_RENEW_HR allocating leases reserved for the client %1 as a result of Renew</term>
<listitem><para>
This debug message is issued when the allocation engine tries to
allocate reserved leases for the client sending a Renew message.
The server will also remove any leases that the client is trying
to renew that are not reserved for the client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_RENEW_REMOVE_RESERVED">
<term>ALLOC_ENGINE_V6_RENEW_REMOVE_RESERVED %1: checking if existing client's leases are reseved for another client</term>
<listitem><para>
This message is logged when the allocation engine finds leases for
the client and will check if these leases are reserved for another
client. If they are, they will not be renewed for the client
requesting their renewal. The first argument includes the client
identification information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_RENEW_REMOVE_UNRESERVED">
<term>ALLOC_ENGINE_V6_RENEW_REMOVE_UNRESERVED dynamically allocating leases for the renewing client %1</term>
<listitem><para>
This debug message is issued as the allocation engine is trying
to dynamically allocate new leases for the renewing client. This
is the case when the server couldn't renew any of the existing
client's leases, e.g. because leased resources are reserved for
another client.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_REUSE_EXPIRED_LEASE_DATA">
<term>ALLOC_ENGINE_V6_REUSE_EXPIRED_LEASE_DATA %1: reusing expired lease, updated lease information: %2</term>
<listitem><para>
This message is logged when the allocation engine is reusing
an existing lease. The details of the updated lease are
printed. The first argument includes the client identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_REVOKED_ADDR_LEASE">
<term>ALLOC_ENGINE_V6_REVOKED_ADDR_LEASE address %1 was revoked from client %2 as it is reserved for client %3</term>
<listitem><para>
This informational message is an indication that the specified IPv6
address was used by client A but it is now reserved for client B. Client
A has been told to stop using it so that it can be leased to client B.
This is a normal occurrence during conflict resolution, which can occur
in cases such as the system administrator adding a reservation for an
address that is currently in use by another client.  The server will fully
recover from this situation, but clients will change their addresses.
</para></listitem>
</varlistentry>

<varlistentry id="ALLOC_ENGINE_V6_REVOKED_PREFIX_LEASE">
<term>ALLOC_ENGINE_V6_REVOKED_PREFIX_LEASE Prefix %1/%2 was revoked from client %3 as it is reserved for client %4</term>
<listitem><para>
This informational message is an indication that the specified IPv6
prefix was used by client A but it is now reserved for client B. Client
A has been told to stop using it so that it can be leased to client B.
This is a normal occurrence during conflict resolution, which can occur
in cases such as the system administrator adding a reservation for an
address that is currently in use by another client.  The server will fully
recover from this situation, but clients will change their prefixes.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="ASIODNS">
    <title>ASIODNS Module</title>
    <para>
      <variablelist>
<varlistentry id="ASIODNS_FD_ADD_TCP">
<term>ASIODNS_FD_ADD_TCP adding a new TCP server by opened fd %1</term>
<listitem><para>
A debug message informing about installing a file descriptor as a server.
The file descriptor number is noted.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_FD_ADD_UDP">
<term>ASIODNS_FD_ADD_UDP adding a new UDP server by opened fd %1</term>
<listitem><para>
A debug message informing about installing a file descriptor as a server.
The file descriptor number is noted.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_FETCH_COMPLETED">
<term>ASIODNS_FETCH_COMPLETED upstream fetch to %1(%2) has now completed</term>
<listitem><para>
A debug message, this records that the upstream fetch (a query made by the
resolver on behalf of its client) to the specified address has completed.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_FETCH_STOPPED">
<term>ASIODNS_FETCH_STOPPED upstream fetch to %1(%2) has been stopped</term>
<listitem><para>
An external component has requested the halting of an upstream fetch.  This
is an allowed operation, and the message should only appear if debug is
enabled.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_OPEN_SOCKET">
<term>ASIODNS_OPEN_SOCKET error %1 opening %2 socket to %3(%4)</term>
<listitem><para>
The asynchronous I/O code encountered an error when trying to open a socket
of the specified protocol in order to send a message to the target address.
The number of the system error that caused the problem is given in the
message.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_READ_DATA">
<term>ASIODNS_READ_DATA error %1 reading %2 data from %3(%4)</term>
<listitem><para>
The asynchronous I/O code encountered an error when trying to read data from
the specified address on the given protocol.  The number of the system
error that caused the problem is given in the message.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_READ_TIMEOUT">
<term>ASIODNS_READ_TIMEOUT receive timeout while waiting for data from %1(%2)</term>
<listitem><para>
An upstream fetch from the specified address timed out.  This may happen for
any number of reasons and is most probably a problem at the remote server
or a problem on the network.  The message will only appear if debug is
enabled.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_SEND_DATA">
<term>ASIODNS_SEND_DATA error %1 sending data using %2 to %3(%4)</term>
<listitem><para>
The asynchronous I/O code encountered an error when trying to send data to
the specified address on the given protocol.  The number of the system
error that caused the problem is given in the message.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_SYNC_UDP_CLOSE_FAIL">
<term>ASIODNS_SYNC_UDP_CLOSE_FAIL failed to close a DNS/UDP socket: %1</term>
<listitem><para>
This is the same to ASIODNS_UDP_CLOSE_FAIL but happens on the
"synchronous UDP server", mainly used for the authoritative DNS server
daemon.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_ACCEPT_FAIL">
<term>ASIODNS_TCP_ACCEPT_FAIL failed to accept TCP DNS connection: %1</term>
<listitem><para>
Accepting a TCP connection from a DNS client failed due to an error
that could happen but should be rare.  The reason for the error is
included in the log message.  The server still keeps accepting new
connections, so unless it happens often it's probably okay to ignore
this error.  If the shown error indicates something like "too many
open files", it's probably because the run time environment is too
restrictive on this limitation, so consider adjusting the limit using
a tool such as ulimit.  If you see other types of errors too often,
there may be something overlooked; please file a bug report in that case.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_CLEANUP_CLOSE_FAIL">
<term>ASIODNS_TCP_CLEANUP_CLOSE_FAIL failed to close a DNS/TCP socket on port cleanup: %1</term>
<listitem><para>
A TCP DNS server tried to close a TCP socket (one created on accepting
a new connection or is already unused) as a step of cleaning up the
corresponding listening port, but it failed to do that.  This is
generally an unexpected event and so is logged as an error.
See also the description of ASIODNS_TCP_CLOSE_ACCEPTOR_FAIL.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_CLOSE_ACCEPTOR_FAIL">
<term>ASIODNS_TCP_CLOSE_ACCEPTOR_FAIL failed to close listening TCP socket: %1</term>
<listitem><para>
A TCP DNS server tried to close a listening TCP socket (for accepting
new connections) as a step of cleaning up the corresponding listening
port (e.g., on server shutdown or updating port configuration), but it
failed to do that.  This is generally an unexpected event and so is
logged as an error.  See ASIODNS_TCP_CLOSE_FAIL on the implication of
related system resources.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_CLOSE_FAIL">
<term>ASIODNS_TCP_CLOSE_FAIL failed to close DNS/TCP socket with a client: %1</term>
<listitem><para>
A TCP DNS server tried to close a TCP socket used to communicate with
a client, but it failed to do that.  While closing a socket should
normally be an error-free operation, there have been known cases where
this happened with a "connection reset by peer" error.  This might be
because of some odd client behavior, such as sending a TCP RST after
establishing the connection and before the server closes the socket,
but how exactly this could happen seems to be system dependent (i.e,
it's not part of the standard socket API), so it's difficult to
provide a general explanation.  In any case, it is believed that an
error on closing a socket doesn't mean leaking system resources (the
kernel should clean up any internal resource related to the socket,
just reporting an error detected in the close call), but, again, it
seems to be system dependent.  This message is logged at a debug level
as it's known to happen and could be triggered by a remote node and it
would be better to not be too verbose, but you might want to increase
the log level and make sure there's no resource leak or other system
level troubles when it's logged.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_CLOSE_NORESP_FAIL">
<term>ASIODNS_TCP_CLOSE_NORESP_FAIL failed to close DNS/TCP socket with a client: %1</term>
<listitem><para>
A TCP DNS server tried to close a TCP socket used to communicate with
a client without returning an answer (which normally happens for zone
transfer requests), but it failed to do that.  See ASIODNS_TCP_CLOSE_FAIL
for more details.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_GETREMOTE_FAIL">
<term>ASIODNS_TCP_GETREMOTE_FAIL failed to get remote address of a DNS TCP connection: %1</term>
<listitem><para>
A TCP DNS server tried to get the address and port of a remote client
on a connected socket but failed.  It's expected to be rare but can
still happen.  See also ASIODNS_TCP_READLEN_FAIL.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_READDATA_FAIL">
<term>ASIODNS_TCP_READDATA_FAIL failed to get DNS data on a TCP socket: %1</term>
<listitem><para>
A TCP DNS server tried to read a DNS message (that follows a 2-byte
length field) but failed.  It's expected to be rare but can still happen.
See also ASIODNS_TCP_READLEN_FAIL.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_READLEN_FAIL">
<term>ASIODNS_TCP_READLEN_FAIL failed to get DNS data length on a TCP socket: %1</term>
<listitem><para>
A TCP DNS server tried to get the length field of a DNS message (the first
2 bytes of a new chunk of data) but failed.  This is generally expected to
be rare but can still happen, e.g, due to an unexpected reset of the
connection.  A specific reason for the failure is included in the log
message.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_TCP_WRITE_FAIL">
<term>ASIODNS_TCP_WRITE_FAIL failed to send DNS message over a TCP socket: %1</term>
<listitem><para>
A TCP DNS server tried to send a DNS message to a remote client but
failed.  It's expected to be rare but can still happen.  See also
ASIODNS_TCP_READLEN_FAIL.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_UDP_ASYNC_SEND_FAIL">
<term>ASIODNS_UDP_ASYNC_SEND_FAIL Error sending UDP packet to %1: %2</term>
<listitem><para>
The low-level ASIO library reported an error when trying to send a UDP
packet in asynchronous UDP mode. This can be any error reported by
send_to(), and can indicate problems such as too high a load on the network,
or a problem in the underlying library or system.
This packet is dropped and will not be sent, but service should resume
normally.
If you see a single occurrence of this message, it probably does not
indicate any significant problem, but if it is logged often, it is probably
a good idea to inspect your network traffic.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_UDP_CLOSE_FAIL">
<term>ASIODNS_UDP_CLOSE_FAIL failed to close a DNS/UDP socket: %1</term>
<listitem><para>
A UDP DNS server tried to close its UDP socket, but failed to do that.
This is generally an unexpected event and so is logged as an error.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_UDP_RECEIVE_FAIL">
<term>ASIODNS_UDP_RECEIVE_FAIL failed to receive UDP DNS packet: %1</term>
<listitem><para>
Receiving a UDP packet from a DNS client failed due to an error that
could happen but should be very rare.  The server still keeps
receiving UDP packets on this socket.  The reason for the error is
included in the log message.  This log message is basically not
expected to appear at all in practice; if it does, there may be some
system level failure and other system logs may have to be checked.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_UDP_SYNC_RECEIVE_FAIL">
<term>ASIODNS_UDP_SYNC_RECEIVE_FAIL failed to receive UDP DNS packet: %1</term>
<listitem><para>
This is the same to ASIODNS_UDP_RECEIVE_FAIL but happens on the
"synchronous UDP server", mainly used for the authoritative DNS server
daemon.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_UDP_SYNC_SEND_FAIL">
<term>ASIODNS_UDP_SYNC_SEND_FAIL Error sending UDP packet to %1: %2</term>
<listitem><para>
The low-level ASIO library reported an error when trying to send a UDP
packet in synchronous UDP mode. See ASIODNS_UDP_ASYNC_SEND_FAIL for
more information.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_UNKNOWN_ORIGIN">
<term>ASIODNS_UNKNOWN_ORIGIN unknown origin for ASIO error code %1 (protocol: %2, address %3)</term>
<listitem><para>
An internal consistency check on the origin of a message from the
asynchronous I/O module failed. This may indicate an internal error;
please submit a bug report.
</para></listitem>
</varlistentry>

<varlistentry id="ASIODNS_UNKNOWN_RESULT">
<term>ASIODNS_UNKNOWN_RESULT unknown result (%1) when IOFetch::stop() was executed for I/O to %2(%3)</term>
<listitem><para>
An internal error indicating that the termination method of the resolver's
upstream fetch class was called with an unknown result code (which is
given in the message).  Please submit a bug report.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="COMMAND">
    <title>COMMAND Module</title>
    <para>
      <variablelist>
<varlistentry id="COMMAND_DEREGISTERED">
<term>COMMAND_DEREGISTERED Command %1 deregistered</term>
<listitem><para>
This debug message indicates that the daemon stopped supporting specified
command. This command can no longer be issued. If the command socket is
open and this command is issued, the daemon will not be able to process it.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_PROCESS_ERROR1">
<term>COMMAND_PROCESS_ERROR1 Error while processing command: %1</term>
<listitem><para>
This warning message indicates that the server encountered an error while
processing received command. Additional information will be provided, if
available. Additional log messages may provide more details.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_PROCESS_ERROR2">
<term>COMMAND_PROCESS_ERROR2 Error while processing command: %1</term>
<listitem><para>
This warning message indicates that the server encountered an error while
processing received command. The difference, compared to COMMAND_PROCESS_ERROR1
is that the initial command was well formed and the error occurred during
logic processing, not the command parsing. Additional information will be
provided, if available. Additional log messages may provide more details.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_RECEIVED">
<term>COMMAND_RECEIVED Received command '%1'</term>
<listitem><para>
This informational message indicates that a command was received over command
socket. The nature of this command and its possible results will be logged
with separate messages.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_REGISTERED">
<term>COMMAND_REGISTERED Command %1 registered</term>
<listitem><para>
This debug message indicates that the daemon started supporting specified
command. If the command socket is open, this command can now be issued.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_RESPONSE_ERROR">
<term>COMMAND_RESPONSE_ERROR Server failed to generate response for command: %1</term>
<listitem><para>
This error message indicates that the server failed to generate response for
specified command. This likely indicates a server logic error, as the server
is expected to generate valid responses for all commands, even malformed
ones.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_ACCEPT_FAIL">
<term>COMMAND_SOCKET_ACCEPT_FAIL Failed to accept incoming connection on command socket %1: %2</term>
<listitem><para>
This error indicates that the server detected incoming connection and executed
accept system call on said socket, but this call returned an error. Additional
information may be provided by the system as second parameter.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_CONNECTION_CLOSED">
<term>COMMAND_SOCKET_CONNECTION_CLOSED Closed socket %1 for existing command connection</term>
<listitem><para>
This is an informational message that the socket created for handling
client's connection is closed. This usually means that the client disconnected,
but may also mean a timeout.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_CONNECTION_OPENED">
<term>COMMAND_SOCKET_CONNECTION_OPENED Opened socket %1 for incoming command connection on socket %2</term>
<listitem><para>
This is an informational message that a new incoming command connection was
detected and a dedicated socket was opened for that connection.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_FAIL_NONBLOCK">
<term>COMMAND_SOCKET_FAIL_NONBLOCK Failed to set non-blocking mode for socket %1 created for incoming connection on socket %2: %3</term>
<listitem><para>
This error message indicates that the server failed to set non-blocking mode
on just created socket. That socket was created for accepting specific
incoming connection. Additional information may be provided as third parameter.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_READ">
<term>COMMAND_SOCKET_READ Received %1 bytes over command socket %2</term>
<listitem><para>
This debug message indicates that specified number of bytes was received
over command socket identified by specified file descriptor.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_READ_FAIL">
<term>COMMAND_SOCKET_READ_FAIL Encountered error %1 while reading from command socket %2</term>
<listitem><para>
This error message indicates that an error was encountered while
reading from command socket.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_RESPONSE_TOOLARGE">
<term>COMMAND_SOCKET_RESPONSE_TOOLARGE Server's response was larger (%1) than supported 64KB</term>
<listitem><para>
This error message indicates that the server received a command and generated
an answer for it, but that response was larger than supported 64KB. Server
will attempt to send the first 64KB of the response. Depending on the nature
of this response, this may indicate a software or configuration error. Future
Kea versions are expected to have better support for large responses.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_UNIX_CLOSE">
<term>COMMAND_SOCKET_UNIX_CLOSE Command socket closed: UNIX, fd=%1, path=%2</term>
<listitem><para>
This informational message indicates that the daemon closed a command
processing socket. This was a UNIX socket. It was opened with the file
descriptor and path specified.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_UNIX_OPEN">
<term>COMMAND_SOCKET_UNIX_OPEN Command socket opened: UNIX, fd=%1, path=%2</term>
<listitem><para>
This informational message indicates that the daemon opened a command
processing socket. This is a UNIX socket. It was opened with the file
descriptor and path specified.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_WRITE">
<term>COMMAND_SOCKET_WRITE Sent response of %1 bytes over command socket %2</term>
<listitem><para>
This debug message indicates that the specified number of bytes was sent
over command socket identifier by the specified file descriptor.
</para></listitem>
</varlistentry>

<varlistentry id="COMMAND_SOCKET_WRITE_FAIL">
<term>COMMAND_SOCKET_WRITE_FAIL Error while writing %1 bytes to command socket %2</term>
<listitem><para>
This error message indicates that an error was encountered while
attempting to send a response to the command socket.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="DCTL">
    <title>DCTL Module</title>
    <para>
      <variablelist>
<varlistentry id="DCTL_CCSESSION_ENDING">
<term>DCTL_CCSESSION_ENDING %1 ending control channel session</term>
<listitem><para>
This debug message is issued just before the controller attempts
to disconnect from its session with the Kea control channel.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_CCSESSION_STARTING">
<term>DCTL_CCSESSION_STARTING %1 starting control channel session, specfile: %2</term>
<listitem><para>
This debug message is issued just before the controller attempts
to establish a session with the Kea control channel.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_COMMAND_RECEIVED">
<term>DCTL_COMMAND_RECEIVED %1 received command: %2, arguments: %3</term>
<listitem><para>
A debug message listing the command (and possible arguments) received
from the Kea control system by the controller.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_CONFIG_COMPLETE">
<term>DCTL_CONFIG_COMPLETE server has completed configuration: %1</term>
<listitem><para>
This is an informational message announcing the successful processing of a
new configuration. It is output during server startup, and when an updated
configuration is committed by the administrator.  Additional information
may be provided.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_CONFIG_FILE_LOAD_FAIL">
<term>DCTL_CONFIG_FILE_LOAD_FAIL %1 reason: %2</term>
<listitem><para>
This fatal error message indicates that the application attempted to load its
initial configuration from file and has failed. The service will exit.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_CONFIG_LOAD_FAIL">
<term>DCTL_CONFIG_LOAD_FAIL %1 configuration failed to load: %2</term>
<listitem><para>
This critical error message indicates that the initial application
configuration has failed. The service will start, but will not
process requests until the configuration has been corrected.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_CONFIG_START">
<term>DCTL_CONFIG_START parsing new configuration: %1</term>
<listitem><para>
A debug message indicating that the application process has received an
updated configuration and has passed it to its configuration manager
for parsing.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_CONFIG_STUB">
<term>DCTL_CONFIG_STUB %1 configuration stub handler called</term>
<listitem><para>
This debug message is issued when the dummy handler for configuration
events is called.  This only happens during initial startup.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_CONFIG_UPDATE">
<term>DCTL_CONFIG_UPDATE %1 updated configuration received: %2</term>
<listitem><para>
A debug message indicating that the controller has received an
updated configuration from the Kea configuration system.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_INIT_PROCESS">
<term>DCTL_INIT_PROCESS %1 initializing the application</term>
<listitem><para>
This debug message is issued just before the controller attempts
to create and initialize its application instance.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_INIT_PROCESS_FAIL">
<term>DCTL_INIT_PROCESS_FAIL %1 application initialization failed: %2</term>
<listitem><para>
This error message is issued if the controller could not initialize the
application and will exit.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_NOT_RUNNING">
<term>DCTL_NOT_RUNNING %1 application instance is not running</term>
<listitem><para>
A warning message is issued when an attempt is made to shut down the
application when it is not running.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_PARSER_FAIL">
<term>DCTL_PARSER_FAIL : %1</term>
<listitem><para>
On receipt of a new configuration, the server failed to create a parser to
decode the contents of the named configuration element, or the creation
succeeded but the parsing actions and committal of changes failed.
The reason for the failure is given in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_PROCESS_FAILED">
<term>DCTL_PROCESS_FAILED %1 application execution failed: %2</term>
<listitem><para>
The controller has encountered a fatal error while running the
application and is terminating. The reason for the failure is
included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_RUN_PROCESS">
<term>DCTL_RUN_PROCESS %1 starting application event loop</term>
<listitem><para>
This debug message is issued just before the controller invokes
the application run method.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_SESSION_FAIL">
<term>DCTL_SESSION_FAIL %1 controller failed to establish Kea session: %1</term>
<listitem><para>
The controller has failed to establish communication with the rest of
Kea and will exit.
</para></listitem>
</varlistentry>

<varlistentry id="DCTL_STANDALONE">
<term>DCTL_STANDALONE %1 skipping message queue, running standalone</term>
<listitem><para>
This is a debug message indicating that the controller is running in the
application in standalone mode. This means it will not connected to the Kea
message queue. Standalone mode is only useful during program development,
and should not be used in a production environment.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="DHCP4">
    <title>DHCP4 Module</title>
    <para>
      <variablelist>
<varlistentry id="DHCP4_ACTIVATE_INTERFACE">
<term>DHCP4_ACTIVATE_INTERFACE activating interface %1</term>
<listitem><para>
This message is printed when DHCPv4 server enabled an interface to be used
to receive DHCPv4 traffic. IPv4 socket on this interface will be opened once
Interface Manager starts up procedure of opening sockets.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_ALREADY_RUNNING">
<term>DHCP4_ALREADY_RUNNING %1 already running? %2</term>
<listitem><para>
This is an error message that occurs when the DHCPv4 server encounters
a pre-existing PID file which contains the PID of a running process.
This most likely indicates an attempt to start a second instance of
the server using the same configuration file.  It is possible, though
unlikely that the PID file is a remnant left behind by a server crash or
power failure and the PID it contains refers to a process other than
the server.  In such an event, it would be necessary to manually remove
the PID file.  The first argument is the DHCPv4 process name, the
second contains the PID and PID file.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_BUFFER_RECEIVED">
<term>DHCP4_BUFFER_RECEIVED received buffer from %1:%2 to %3:%4 over interface %5</term>
<listitem><para>
This debug message is logged when the server has received a packet
over the socket. When the message is logged the contents of the received
packet hasn't been parsed yet. The only available information is the
interface and the source and destination IPv4 addresses/ports.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_BUFFER_RECEIVE_FAIL">
<term>DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: %1</term>
<listitem><para>
The DHCPv4 server tried to receive a packet but an error
occurred during this attempt. The reason for the error is included in
the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_BUFFER_UNPACK">
<term>DHCP4_BUFFER_UNPACK parsing buffer received from %1 to %2 over interface %3</term>
<listitem><para>
This debug message is issued when the server starts parsing the received
buffer holding the DHCPv4 message. The arguments specify the source and
destination IPv4 addresses as well as the interface over which the buffer has
been received.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_BUFFER_WAIT">
<term>DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout %1 ms</term>
<listitem><para>
This debug message is issued when the server enters the state when it
waits for new packets. The argument specifies the timeout for the server
to wait for the packet. When this time elapses the server will pass
through its main loop to perform handling of any pending signals
and timers. After that, it will enter the wait state again.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_BUFFER_WAIT_INTERRUPTED">
<term>DHCP4_BUFFER_WAIT_INTERRUPTED interrupted wait for the next packet due to timeout, signal or external socket callback (timeout value is %1)</term>
<listitem><para>
This debug message is issued when the server intrrupts waiting
for reception of the next DHCPv6 message due to timeout, signal
or reception of the data over socket other than used for DHCPv4
message transmission. The server will now handle signals
received and ready timers before waiting for next packets again.
The argument specifies the timeout value in milliseconds.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_BUFFER_WAIT_SIGNAL">
<term>DHCP4_BUFFER_WAIT_SIGNAL signal received while waiting for next packet, next waiting signal is %1</term>
<listitem><para>
This debug message is issued when the server was waiting for the
packet, but the wait has been interrupted by the signal received
by the process. The signal will be handled before the server starts
waiting for next packets. The argument specifies the next signal to
be handled by the server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CCSESSION_STARTED">
<term>DHCP4_CCSESSION_STARTED control channel session started on socket %1</term>
<listitem><para>
A debug message issued during startup after the DHCPv4 server has
successfully established a session with the Kea control channel.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CCSESSION_STARTING">
<term>DHCP4_CCSESSION_STARTING starting control channel session, specfile: %1</term>
<listitem><para>
This debug message is issued just before the DHCPv4 server attempts
to establish a session with the Kea control channel.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CLASS_ASSIGNED">
<term>DHCP4_CLASS_ASSIGNED %1: client packet has been assigned to the following class(es): %2</term>
<listitem><para>
This debug message informs that incoming packet has been assigned to specified
class or classes. This is a normal behavior and indicates successful operation.
The first argument specifies the client and transaction identification
information. The second argument includes all classes to which the
packet has been assigned.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CLASS_UNCONFIGURED">
<term>DHCP4_CLASS_UNCONFIGURED %1: client packet belongs to an unconfigured class: %2</term>
<listitem><para>
This debug message informs that incoming packet belongs to a class
which cannot be found in the configuration. Either a hook written
before the classification was added to Kea is used, or class naming is
inconsistent.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CLIENTID_IGNORED_FOR_LEASES">
<term>DHCP4_CLIENTID_IGNORED_FOR_LEASES %1: not using client identifier for lease allocation for subnet %2</term>
<listitem><para>
This debug message is issued when the server is processing the DHCPv4 message
for which client identifier will not be used when allocating new lease or
renewing existing lease. The server is explicitly configured to not use
client identifier to lookup existing leases for the client and will not
record client identifier in the lease database. This mode of operation
is useful when clients don't use stable client identifiers, e.g. multi
stage booting. Note that the client identifier may be used for other
operations than lease allocation, e.g. identifying host reservations
for the client using client identifier. The first argument includes the
client and transaction identification information. The second argument
specifies the identifier of the subnet where the client is connected
and for which this mode of operation is configured on the server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CLIENT_FQDN_DATA">
<term>DHCP4_CLIENT_FQDN_DATA %1: Client sent FQDN option: %2</term>
<listitem><para>
This debug message includes the detailed information extracted from the
Client FQDN option sent in the query. The first argument includes the
client and transaction identification information. The second argument
specifies the detailed information about the FQDN option received
by the server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CLIENT_FQDN_PROCESS">
<term>DHCP4_CLIENT_FQDN_PROCESS %1: processing Client FQDN option</term>
<listitem><para>
This debug message is issued when the server starts processing the Client
FQDN option sent in the client's query. The argument includes the
client and transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CLIENT_HOSTNAME_DATA">
<term>DHCP4_CLIENT_HOSTNAME_DATA %1: client sent Hostname option: %2</term>
<listitem><para>
This debug message includes the detailed information extracted from the
Hostname option sent in the query. The first argument includes the
client and transaction identification information. The second argument
specifies the hostname carried in the Hostname option sent by the
client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CLIENT_HOSTNAME_PROCESS">
<term>DHCP4_CLIENT_HOSTNAME_PROCESS %1: processing client's Hostname option</term>
<listitem><para>
This debug message is issued when the server starts processing the Hostname
option sent in the client's query. The argument includes the client and
transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CLIENT_NAME_PROC_FAIL">
<term>DHCP4_CLIENT_NAME_PROC_FAIL %1: failed to process the fqdn or hostname sent by a client: %2</term>
<listitem><para>
This debug message is issued when the DHCP server was unable to process the
FQDN or Hostname option sent by a client. This is likely because the client's
name was malformed or due to internal server error. The first argument
contains the client and transaction identification information. The
second argument holds the detailed description of the error.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_COMMAND_RECEIVED">
<term>DHCP4_COMMAND_RECEIVED received command %1, arguments: %2</term>
<listitem><para>
A debug message listing the command (and possible arguments) received
from the Kea control system by the DHCPv4 server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CONFIG_COMPLETE">
<term>DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: %1</term>
<listitem><para>
This is an informational message announcing the successful processing of a
new configuration. It is output during server startup, and when an updated
configuration is committed by the administrator.  Additional information
may be provided.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CONFIG_LOAD_FAIL">
<term>DHCP4_CONFIG_LOAD_FAIL configuration error using file: %1, reason: %2</term>
<listitem><para>
This error message indicates that the DHCPv4 configuration has failed.
If this is an initial configuration (during server's startup) the server
will fail to start. If this is a dynamic reconfiguration attempt the
server will continue to use an old configuration.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CONFIG_NEW_SUBNET">
<term>DHCP4_CONFIG_NEW_SUBNET a new subnet has been added to configuration: %1</term>
<listitem><para>
This is an informational message reporting that the configuration has
been extended to include the specified IPv4 subnet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CONFIG_OPTION_DUPLICATE">
<term>DHCP4_CONFIG_OPTION_DUPLICATE multiple options with the code %1 added to the subnet %2</term>
<listitem><para>
This warning message is issued on an attempt to configure multiple options
with the same option code for a particular subnet. Adding multiple options
is uncommon for DHCPv4, but is not prohibited.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CONFIG_RECEIVED">
<term>DHCP4_CONFIG_RECEIVED received configuration %1</term>
<listitem><para>
A debug message listing the configuration received by the DHCPv4 server.
The source of that configuration depends on used configuration backend.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CONFIG_START">
<term>DHCP4_CONFIG_START DHCPv4 server is processing the following configuration: %1</term>
<listitem><para>
This is a debug message that is issued every time the server receives a
configuration. That happens at start up and also when a server configuration
change is committed by the administrator.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_CONFIG_UPDATE">
<term>DHCP4_CONFIG_UPDATE updated configuration received: %1</term>
<listitem><para>
A debug message indicating that the DHCPv4 server has received an
updated configuration from the Kea configuration system.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_DDNS_REQUEST_SEND_FAILED">
<term>DHCP4_DDNS_REQUEST_SEND_FAILED failed sending a request to kea-dhcp-ddns, error: %1,  ncr: %2</term>
<listitem><para>
This error message indicates that DHCP4 server attempted to send a DDNS
update request to the DHCP-DDNS server.  This is most likely a configuration or
networking error.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_DEACTIVATE_INTERFACE">
<term>DHCP4_DEACTIVATE_INTERFACE deactivate interface %1</term>
<listitem><para>
This message is printed when DHCPv4 server disables an interface from being
used to receive DHCPv4 traffic. Sockets on this interface will not be opened
by the Interface Manager until interface is enabled.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_DECLINE_LEASE">
<term>DHCP4_DECLINE_LEASE Received DHCPDECLINE for addr %1 from client %2. The lease will be unavailable for %3 seconds.</term>
<listitem><para>
This informational message is printed when a client received an address, but
discovered that it is being used by some other device and notified the server by
sending a DHCPDECLINE message. The server checked that this address really was
leased to the client and marked this address as unusable for a certain
amount of time. This message may indicate a misconfiguration in a network,
as there is either a buggy client or more likely a device that is using an
address that it is not supposed to. The server will fully recover from this
situation, but if the underlying problem of a misconfigured or rogue device
is not solved, this address may be declined again in the future.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_DECLINE_LEASE_MISMATCH">
<term>DHCP4_DECLINE_LEASE_MISMATCH Received DHCPDECLINE for addr %1 from client %2, but the data doesn't match: received hwaddr: %3, lease hwaddr: %4, received client-id: %5, lease client-id: %6</term>
<listitem><para>
This informational message means that a client attempted to report his address
as declined (i.e. used by unknown entity). The server has information about
a lease for that address, but the client's hardware address or client identifier
does not match the server's stored information. The client's request will be ignored.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_DECLINE_LEASE_NOT_FOUND">
<term>DHCP4_DECLINE_LEASE_NOT_FOUND Received DHCPDECLINE for addr %1 from client %2, but no such lease found.</term>
<listitem><para>
This warning message indicates that a client reported that his address was
detected as a duplicate (i.e. another device in the network is using this address).
However, the server does not have a record for this address. This may indicate
a client's error or a server's purged database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_DISCOVER_CLASS_PROCESSING_FAILED">
<term>DHCP4_DISCOVER_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPDISCOVER</term>
<listitem><para>
This debug message means that the server processing that is unique for each
client class has reported a failure. The response packet will not be sent.
The argument holds the client and transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_DYNAMIC_RECONFIGURATION">
<term>DHCP4_DYNAMIC_RECONFIGURATION initiate server reconfiguration using file: %1, after receiving SIGHUP signal</term>
<listitem><para>
This is the info message logged when the DHCPv4 server starts reconfiguration
as a result of receiving SIGHUP signal.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_DYNAMIC_RECONFIGURATION_FAIL">
<term>DHCP4_DYNAMIC_RECONFIGURATION_FAIL dynamic server reconfiguration failed with file: %1</term>
<listitem><para>
This is an error message logged when the dynamic reconfiguration of the
DHCP server failed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_EMPTY_HOSTNAME">
<term>DHCP4_EMPTY_HOSTNAME %1: received empty hostname from the client, skipping processing of this option</term>
<listitem><para>
This debug message is issued when the server received an empty Hostname option
from a client. Server does not process empty Hostname options and therefore
option is skipped. The argument holds the client and transaction identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HANDLE_SIGNAL_EXCEPTION">
<term>DHCP4_HANDLE_SIGNAL_EXCEPTION An exception was thrown while handing signal: %1</term>
<listitem><para>
This error message is printed when an ISC or standard exception was raised during signal
processing. This likely indicates a coding error and should be reported to ISC.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HOOKS_LIBS_RELOAD_FAIL">
<term>DHCP4_HOOKS_LIBS_RELOAD_FAIL reload of hooks libraries failed</term>
<listitem><para>
A "libreload" command was issued to reload the hooks libraries but for
some reason the reload failed.  Other error messages issued from the
hooks framework will indicate the nature of the problem.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HOOK_BUFFER_RCVD_SKIP">
<term>DHCP4_HOOK_BUFFER_RCVD_SKIP received buffer from %1 to %2 over interface %3 was dropped because a callout set the skip flag</term>
<listitem><para>
This debug message is printed when a callout installed on buffer4_receive
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
The arguments specify the source and destination IPv4 address as well as
the name of the interface over which the buffer has been received.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HOOK_BUFFER_SEND_SKIP">
<term>DHCP4_HOOK_BUFFER_SEND_SKIP %1: prepared response is dropped because a callout set the skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on buffer4_send
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
Server completed all the processing (e.g. may have assigned, updated
or released leases), but the response will not be send to the client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HOOK_DECLINE_SKIP">
<term>DHCP4_HOOK_DECLINE_SKIP Decline4 hook callouts set status to DROP, ignoring packet.</term>
<listitem><para>
This message indicates that the server received DHCPDECLINE message, it was verified
to be correct and matching server's lease information. The server called hooks
for decline4 hook point and one of the callouts set next step status to DROP.
The server will now abort processing of the packet as if it was never
received. The lease will continue to be assigned to this client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HOOK_LEASE4_RELEASE_SKIP">
<term>DHCP4_HOOK_LEASE4_RELEASE_SKIP %1: lease was not released because a callout set the skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on lease4_release
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to not release
a lease.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HOOK_PACKET_RCVD_SKIP">
<term>DHCP4_HOOK_PACKET_RCVD_SKIP %1: packet is dropped, because a callout set the skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on the pkt4_receive
hook point sets the skip flag. For this particular hook point, the
setting of the flag instructs the server to drop the packet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HOOK_PACKET_SEND_SKIP">
<term>DHCP4_HOOK_PACKET_SEND_SKIP %1: prepared response is not sent, because a callout set skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on the pkt4_send
hook point sets the skip flag. For this particular hook point, the setting
of the flag instructs the server to drop the packet. This means that
the client will not get any response, even though the server processed
client's request and acted on it (e.g. possibly allocated a lease).
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_HOOK_SUBNET4_SELECT_SKIP">
<term>DHCP4_HOOK_SUBNET4_SELECT_SKIP %1: no subnet was selected, because a callout set skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on the
subnet4_select hook point sets the skip flag. For this particular hook
point, the setting of the flag instructs the server not to choose a
subnet, an action that severely limits further processing; the server
will be only able to offer global options - no addresses will be assigned.
The argument specifies the client and transaction identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_INFORM_CLASS_PROCESSING_FAILED">
<term>DHCP4_INFORM_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPINFORM</term>
<listitem><para>
This debug message means that the server processing that is unique for each
client class has reported a failure. The response packet will not be sent.
The argument specifies the client and the transaction identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_INFORM_DIRECT_REPLY">
<term>DHCP4_INFORM_DIRECT_REPLY %1: DHCPACK in reply to the DHCPINFORM will be sent directly to %2 over %3</term>
<listitem><para>
This debug message is issued when the DHCPACK will be sent directly to the
client, rather than via a relay. The first argument contains the client
and transaction identification information. The second argument contains
the client's IPv4 address to which the response will be sent. The third
argument contains the local interface name.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_INIT_FAIL">
<term>DHCP4_INIT_FAIL failed to initialize Kea server: %1</term>
<listitem><para>
The server has failed to initialize. This may be because the configuration
was not successful, or it encountered any other critical error on startup.
Attached error message provides more details about the issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_INIT_REBOOT">
<term>DHCP4_INIT_REBOOT %1: client is in INIT-REBOOT state and requests address %2</term>
<listitem><para>
This debug message is issued when the client is in the INIT-REBOOT state and
is requesting an IPv4 address it is using to be allocated for it. The first
argument includes the client and transaction identification information. The
second argument specifies the requested IPv4 address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_LEASE_ADVERT">
<term>DHCP4_LEASE_ADVERT %1: lease %2 will be advertised</term>
<listitem><para>
This debug message indicates that the server has found the lease to be
offered to the client. It is up to the client to choose one server out of
those which offered leases and continue allocation with that server.
The first argument specifies the client and the transaction identification
information. The second argument specifies the IPv4 address to be offered.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_LEASE_ALLOC">
<term>DHCP4_LEASE_ALLOC %1: lease %2 has been allocated</term>
<listitem><para>
This debug message indicates that the server successfully granted a lease
in response to client's DHCPREQUEST message. The lease information will
be sent to the client in the DHCPACK message. The first argument
contains the client and the transaction identification information. The
second argument contains the allocated IPv4 address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_NAME_GEN_UPDATE_FAIL">
<term>DHCP4_NAME_GEN_UPDATE_FAIL %1: failed to update the lease after generating name %2 for a client: %3</term>
<listitem><para>
This message indicates the failure when trying to update the lease and/or
options in the server's response with the hostname generated by the server
from the acquired IPv4 address. The message argument indicates the reason
for the failure. The first argument includes the client and the transaction
identification information. The second argument specifies the hostname.
The third argument contains the error details.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_NCR_CREATE">
<term>DHCP4_NCR_CREATE %1: DDNS updates enabled, therefore sending name change requests</term>
<listitem><para>
This debug message message is issued when the server is starting to send
name change requests to the D2 module to update records for the client
in the DNS. This includes removal of old records and addition of the
new records as required. Details of the name change requests will be
logged in additional log entries. The argument includes the client
and the transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_NCR_CREATION_FAILED">
<term>DHCP4_NCR_CREATION_FAILED %1: failed to generate name change requests for DNS: %2</term>
<listitem><para>
This message indicates that server was unable to generate NameChangeRequests
which should be sent to the kea-dhcp_ddns module to create
new DNS records for the lease being acquired or to update existing records
for the renewed lease. The first argument contains the client and transaction
identification information. The second argument includes the reason for the
failure.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_NOT_RUNNING">
<term>DHCP4_NOT_RUNNING DHCPv4 server is not running</term>
<listitem><para>
A warning message is issued when an attempt is made to shut down the
DHCPv4 server but it is not running.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_NO_LEASE_INIT_REBOOT">
<term>DHCP4_NO_LEASE_INIT_REBOOT %1: no lease for address %2 requested by INIT-REBOOT client</term>
<listitem><para>
This debug message is issued when the client being in the INIT-REBOOT state
requested an IPv4 address but this client is unknown. The server will not
respond. The first argument includes the client and the transaction id
identification information. The second argument includes the IPv4 address
requested by the client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_NO_SOCKETS_OPEN">
<term>DHCP4_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic</term>
<listitem><para>
This warning message is issued when current server configuration specifies
no interfaces that server should listen on, or specified interfaces are not
configured to receive the traffic.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_OPEN_SOCKET">
<term>DHCP4_OPEN_SOCKET opening sockets on port %1</term>
<listitem><para>
A debug message issued during startup, this indicates that the DHCPv4
server is about to open sockets on the specified port.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_OPEN_SOCKET_FAIL">
<term>DHCP4_OPEN_SOCKET_FAIL failed to open socket: %1</term>
<listitem><para>
A warning message issued when IfaceMgr fails to open and bind a socket. The reason
for the failure is appended as an argument of the log message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_DROP_0001">
<term>DHCP4_PACKET_DROP_0001 failed to parse packet from %1 to %2, received over interace %3, reason: %4</term>
<listitem><para>
The DHCPv4 server has received a packet that it is unable to
interpret. The reason why the packet is invalid is included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_DROP_0002">
<term>DHCP4_PACKET_DROP_0002 %1, from interface %2: no suitable subnet configured for a direct client</term>
<listitem><para>
This info message is logged when received a message from a directly connected
client but there is no suitable subnet configured for the interface on
which this message has been received. The IPv4 address assigned on this
interface must belong to one of the configured subnets. Otherwise
received message is dropped.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_DROP_0003">
<term>DHCP4_PACKET_DROP_0003 %1, from interface %2: it contains a foreign server identifier</term>
<listitem><para>
This debug message is issued when received DHCPv4 message is dropped because
it is addressed to a different server, i.e. a server identifier held by
this message doesn't match the identifier used by our server. The arguments
of this message hold the name of the transaction id and interface on which
the message has been received.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_DROP_0004">
<term>DHCP4_PACKET_DROP_0004 %1, from interface %2: missing msg-type option</term>
<listitem><para>
This is a debug message informing that incoming DHCPv4 packet did not
have mandatory DHCP message type option and thus was dropped. The
arguments specify the client and transaction identification information,
as well as the interface on which the message has been received.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_DROP_0005">
<term>DHCP4_PACKET_DROP_0005 %1: unrecognized type %2 in option 53</term>
<listitem><para>
This debug message indicates that the message type carried in DHCPv4 option
53 is unrecognized by the server. The valid message types are listed
on the IANA website: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#message-type-53.
The message will not be processed by the server. The arguments specify
the client and transaction identification information, as well as the
received message type.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_DROP_0006">
<term>DHCP4_PACKET_DROP_0006 %1: unsupported DHCPv4 message type %2</term>
<listitem><para>
This debug message indicates that the message type carried in DHCPv4 option
53 is valid but the message will not be processed by the server. This includes
messages being normally sent by the server to the client, such as DHCPOFFER,
DHCPACK, DHCPNAK etc. The first argument specifies the client and transaction
identification information. The second argument specifies the message type.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_DROP_0007">
<term>DHCP4_PACKET_DROP_0007 %1: failed to process packet: %2</term>
<listitem><para>
This is a general catch-all message indicating that the processing of a
received packet failed.  The reason is given in the message.  The server
will not send a response but will instead ignore the packet. The first
argument contains the client and transaction identification information.
The second argument includes the details of the error.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_NAK_0001">
<term>DHCP4_PACKET_NAK_0001 %1: failed to select a subnet for incoming packet, src %2, type %3</term>
<listitem><para>
This error message is output when a packet was received from a subnet
for which the DHCPv4 server has not been configured. The most probable
cause is a misconfiguration of the server. The first argument contains
the client and transaction identification information. The second argument
contains the source IPv4 address of the packet. The third argument contains
the name of the received packet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_NAK_0002">
<term>DHCP4_PACKET_NAK_0002 %1: invalid address %2 requested by INIT-REBOOT</term>
<listitem><para>
This debug message is issued when the client being in the INIT-REBOOT state
requested an IPv4 address which is not assigned to him. The server will respond
to this client with DHCPNAK. The first argument contains the client and
the transaction identification information. The second arguments holds the
IPv4 address requested by the client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_NAK_0003">
<term>DHCP4_PACKET_NAK_0003 %1: failed to advertise a lease, client sent ciaddr %2, requested-ip-address %3</term>
<listitem><para>
This message indicates that the server has failed to offer a lease to
the specified client after receiving a DISCOVER message from it. There are
many possible reasons for such a failure. The first argument contains
the client and the transaction identification information. The second
argument contains the IPv4 address in the ciaddr field. The third
argument contains the IPv4 address in the requested-ip-address option
(if present).
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_NAK_0004">
<term>DHCP4_PACKET_NAK_0004 %1: failed to grant a lease, client sent ciaddr %2, requested-ip-address %3</term>
<listitem><para>
This message indicates that the server failed to grant a lease to the
specified client after receiving a REQUEST message from it.  There are many
possible reasons for such a failure. Additional messages will indicate the
reason. The first argument contains the client and the transaction
identification information. The second argument contains the IPv4 address
in the ciaddr field. The third argument contains the IPv4 address in the
requested-ip-address option (if present).
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_PACK">
<term>DHCP4_PACKET_PACK %1: preparing on-wire format of the packet to be sent</term>
<listitem><para>
This debug message is issued when the server starts preparing the on-wire
format of the packet to be sent back to the client. The argument specifies
the client and the transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_PACK_FAIL">
<term>DHCP4_PACKET_PACK_FAIL %1: preparing on-wire-format of the packet to be sent failed %2</term>
<listitem><para>
This error message is issued when preparing an on-wire format of the packet
has failed. The first argument identifies the client and the DHCP transaction.
The second argument includes the error string.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_RECEIVED">
<term>DHCP4_PACKET_RECEIVED %1: %2 (type %3) received from %4 to %5 on interface %6</term>
<listitem><para>
A debug message noting that the server has received the specified type of
packet on the specified interface. The first argument specifies the
client and transaction identification information. The second and third
argument specify the name of the DHCPv4 message and its numeric type
respectively. The remaining arguments specify the source IPv4 address,
destination IPv4 address and the name of the interface on which the
message has been received.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_SEND">
<term>DHCP4_PACKET_SEND %1: trying to send packet %2 (type %3) from %4:%5 to %6:%7 on interface %8</term>
<listitem><para>
The arguments specify the client identification information (HW address
and client identifier), DHCP message name and type, source IPv4
address and port, destination IPv4 address and port and the
interface name.
</para><para>
This debug message is issued when the server is trying to send the
response to the client. When the server is using an UDP socket
to send the packet there are cases when this operation may be
unsuccessful and no error message will be displayed. One such situation
occurs when the server is unicasting the response to the 'ciaddr' of
a DHCPINFORM message. This often requires broadcasting an ARP
message to obtain the link layer address of the unicast destination.
If broadcast ARP messages are blocked in the network, according to
the firewall policy, the ARP message will not cause a response.
Consequently, the response to the DHCPINFORM will not be sent.
Since the ARP communication is under the OS control, Kea is not
notified about the drop of the packet which it is trying to send
and it has no means to display an error message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PACKET_SEND_FAIL">
<term>DHCP4_PACKET_SEND_FAIL %1: failed to send DHCPv4 packet: %2</term>
<listitem><para>
This error is output if the DHCPv4 server fails to send an assembled
DHCP message to a client. The first argument includes the client and
the transaction identification information. The second argument includes
the reason for failure.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PARSER_COMMIT_EXCEPTION">
<term>DHCP4_PARSER_COMMIT_EXCEPTION parser failed to commit changes</term>
<listitem><para>
On receipt of message containing details to a change of the DHCPv4
server configuration, a set of parsers were successfully created, but one
of them failed to commit its changes due to a low-level system exception
being raised.  Additional messages may be output indicating the reason.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PARSER_COMMIT_FAIL">
<term>DHCP4_PARSER_COMMIT_FAIL parser failed to commit changes: %1</term>
<listitem><para>
On receipt of message containing details to a change of the DHCPv4
server configuration, a set of parsers were successfully created, but
one of them failed to commit its changes.  The reason for the failure
is given in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PARSER_CREATED">
<term>DHCP4_PARSER_CREATED created parser for configuration element %1</term>
<listitem><para>
A debug message output during a configuration update of the DHCPv4
server, notifying that the parser for the specified configuration element
has been successfully created.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PARSER_EXCEPTION">
<term>DHCP4_PARSER_EXCEPTION failed to create or run parser for configuration element %1</term>
<listitem><para>
On receipt of message containing details to a change of its configuration,
the DHCPv4 server failed to create a parser to decode the contents of
the named configuration element, or the creation succeeded but the parsing
actions and committal of changes failed.  The message has been output in
response to a non-Kea exception being raised.  Additional messages
may give further information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_PARSER_FAIL">
<term>DHCP4_PARSER_FAIL failed to create or run parser for configuration element %1: %2</term>
<listitem><para>
On receipt of message containing details to a change of its configuration,
the DHCPv4 server failed to create a parser to decode the contents
of the named configuration element, or the creation succeeded but the
parsing actions and committal of changes failed.  The reason for the
failure is given in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_QUERY_DATA">
<term>DHCP4_QUERY_DATA %1, packet details: %2</term>
<listitem><para>
A debug message printing the details of the received packet. The first
argument includes the client and the transaction identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RELEASE">
<term>DHCP4_RELEASE %1: address %2 was released properly.</term>
<listitem><para>
This debug message indicates that an address was released properly. It
is a normal operation during client shutdown. The first argument includes
the client and transaction identification information. The second argument
includes the released IPv4 address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RELEASE_EXCEPTION">
<term>DHCP4_RELEASE_EXCEPTION %1: while trying to release address %2 an exception occured: %3</term>
<listitem><para>
This message is output when an error was encountered during an attempt
to process a DHCPRELEASE message. The error will not affect the client,
which does not expect any response from the server for DHCPRELEASE
messages. Depending on the nature of problem, it may affect future
server operation. The first argument includes the client and the
transaction identification information. The second argument
includes the IPv4 address which release was attempted. The last
argument includes the detailed error description.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RELEASE_FAIL">
<term>DHCP4_RELEASE_FAIL %1: failed to remove lease for address %2</term>
<listitem><para>
This error message indicates that the software failed to remove a
lease from the lease database. It is probably due to an error during a
database operation: resolution will most likely require administrator
intervention (e.g. check if DHCP process has sufficient privileges to
update the database). It may also be triggered if a lease was manually
removed from the database during RELEASE message processing. The
first argument includes the client and the transaction identification
information. The second argument holds the IPv4 address which release
was attempted.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RELEASE_FAIL_NO_LEASE">
<term>DHCP4_RELEASE_FAIL_NO_LEASE %1: client is trying to release non-existing lease %2</term>
<listitem><para>
This debug message is printed when client attempts to release a lease,
but no such lease is known to the server. The first argument contains
the client and transaction identification information. The second
argument contains the IPv4 address which the client is trying to
release.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RELEASE_FAIL_WRONG_CLIENT">
<term>DHCP4_RELEASE_FAIL_WRONG_CLIENT %1: client is trying to release the lease %2 which belongs to a different client</term>
<listitem><para>
This debug message is issued when a client is trying to release the
lease for the address which is currently used by another client, i.e.
the 'client identifier' or 'chaddr' doesn't match between the client
and the lease. The first argument includes the client and the
transaction identification information. The second argument specifies
the leased address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_REQUEST_CLASS_PROCESSING_FAILED">
<term>DHCP4_REQUEST_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPREQUEST</term>
<listitem><para>
This debug message means that the server processing that is unique for each
client class has reported a failure. The response packet will not be sent.
The argument contains the client and transaction identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RESPONSE_DATA">
<term>DHCP4_RESPONSE_DATA %1: responding with packet %2 (type %3), packet details: %4</term>
<listitem><para>
A debug message including the detailed data about the packet being sent
to the client. The first argument contains the client and the transaction
identification information. The second and third argument contains the
packet name and type respectively. The fourth argument contains detailed
packet information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RESPONSE_FQDN_DATA">
<term>DHCP4_RESPONSE_FQDN_DATA %1: including FQDN option in the server's response: %2</term>
<listitem><para>
This debug message is issued when the server is adding the Client FQDN
option in its response to the client. The first argument includes the
client and transaction identification information. The second argument
includes the details of the FQDN option being included. Note that the
name carried in the FQDN option may be modified by the server when
the lease is acquired for the client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RESPONSE_HOSTNAME_DATA">
<term>DHCP4_RESPONSE_HOSTNAME_DATA %1: including Hostname option in the server's response: %2</term>
<listitem><para>
This debug message is issued when the server is adding the Hostname
option in its response to the client. The first argument includes the
client and transaction identification information. The second argument
includes the details of the FQDN option being included. Note that the
name carried in the Hostname option may be modified by the server when
the lease is acquired for the client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_RESPONSE_HOSTNAME_GENERATE">
<term>DHCP4_RESPONSE_HOSTNAME_GENERATE %1: server has generated hostname %2 for the client</term>
<listitem><para>
This debug message includes the auto-generated hostname which will be used
for the client which message is processed. Hostnames may need to be generated
when required by the server's configuration or when the client hasn't
supplied its hostname. The first argument includes the client and the
transaction identification information. The second argument holds the
generated hostname.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_SERVER_FAILED">
<term>DHCP4_SERVER_FAILED server failed: %1</term>
<listitem><para>
The DHCPv4 server has encountered a fatal error and is terminating.
The reason for the failure is included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_SHUTDOWN">
<term>DHCP4_SHUTDOWN server shutdown</term>
<listitem><para>
The DHCPv4 server has terminated normally.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_SHUTDOWN_REQUEST">
<term>DHCP4_SHUTDOWN_REQUEST shutdown of server requested</term>
<listitem><para>
This debug message indicates that a shutdown of the DHCPv4 server has
been requested via a call to the 'shutdown' method of the core Dhcpv4Srv
object.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_SRV_CONSTRUCT_ERROR">
<term>DHCP4_SRV_CONSTRUCT_ERROR error creating Dhcpv4Srv object, reason: %1</term>
<listitem><para>
This error message indicates that during startup, the construction of a
core component within the DHCPv4 server (the Dhcpv4 server object)
has failed.  As a result, the server will exit.  The reason for the
failure is given within the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_SRV_D2STOP_ERROR">
<term>DHCP4_SRV_D2STOP_ERROR error stopping IO with DHCP_DDNS during shutdown: %1</term>
<listitem><para>
This error message indicates that during shutdown, an erro occurred while
stopping IO between the DHCPv4 server and the DHCP_DDNS server.  This is
probably due to a programmatic error is not likely to impact either server
upon restart.  The reason for the failure is given within the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_STARTED">
<term>DHCP4_STARTED Kea DHCPv4 server version %1 started</term>
<listitem><para>
This informational message indicates that the DHCPv4 server has
processed all configuration information and is ready to process
DHCPv4 packets.  The version is also printed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_STARTING">
<term>DHCP4_STARTING Kea DHCPv4 server version %1 starting</term>
<listitem><para>
This informational message indicates that the DHCPv4 server has
processed any command-line switches and is starting. The version
is also printed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_START_INFO">
<term>DHCP4_START_INFO pid: %1, port: %2, verbose: %3</term>
<listitem><para>
This is a debug message issued during the DHCPv4 server startup.
It lists some information about the parameters with which the server
is running.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_SUBNET_DATA">
<term>DHCP4_SUBNET_DATA %1: the selected subnet details: %2</term>
<listitem><para>
This debug message includes the details of the subnet selected for
the client. The first argument includes the client and the
transaction identification information. The second arguments
includes the subnet details.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_SUBNET_SELECTED">
<term>DHCP4_SUBNET_SELECTED %1: the subnet with ID %2 was selected for client assignments</term>
<listitem><para>
This is a debug message noting the selection of a subnet to be used for
address and option assignment. Subnet selection is one of the early
steps in the processing of incoming client message. The first
argument includes the client and the transaction identification
information. The second argument holds the selected subnet id.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP4_SUBNET_SELECTION_FAILED">
<term>DHCP4_SUBNET_SELECTION_FAILED %1: failed to select subnet for the client</term>
<listitem><para>
This debug message indicates that the server failed to select the
subnet for the client which has sent a message to the server.
The server will not be able to offer any lease to the client and
will drop its message if the received message was DHCPDISCOVER,
and will send DHCPNAK if the received message was DHCPREQUEST.
The argument includes the client and the transaction identification
information.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="DHCP6">
    <title>DHCP6 Module</title>
    <para>
      <variablelist>
<varlistentry id="DHCP6_ACTIVATE_INTERFACE">
<term>DHCP6_ACTIVATE_INTERFACE activating interface %1</term>
<listitem><para>
This message is printed when DHCPv6 server enabled an interface to be used
to receive DHCPv6 traffic. IPv6 socket on this interface will be opened once
Interface Manager starts up procedure of opening sockets.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_ADD_GLOBAL_STATUS_CODE">
<term>DHCP6_ADD_GLOBAL_STATUS_CODE %1: adding Status Code to DHCPv6 packet: %2</term>
<listitem><para>
This message is logged when the server is adding the top-level
Status Code option. The first argument includes the client and the
transaction identification information. The second argument includes
the details of the status code.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_ADD_STATUS_CODE_FOR_IA">
<term>DHCP6_ADD_STATUS_CODE_FOR_IA %1: adding Status Code to IA with iaid=%2: %3</term>
<listitem><para>
This message is logged when the server is adding the Status Code
option to an IA. The first argument includes the client and the
transaction identification information. The second argument specifies
the IAID. The third argument includes the details of the status code.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_ALREADY_RUNNING">
<term>DHCP6_ALREADY_RUNNING %1 already running? %2</term>
<listitem><para>
This is an error message that occurs when the DHCPv6 server encounters
a pre-existing PID file which contains the PID of a running process.
This most likely indicates an attempt to start a second instance of
the server using the same configuration file.  It is possible, though
unlikely that the PID file is a remnant left behind by a server crash or
power failure and the PID it contains refers to a process other than
the server.  In such an event, it would be necessary to manually remove
the PID file.  The first argument is the DHCPv6 process name, the second
contains the PID and PID file.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_BUFFER_RECEIVED">
<term>DHCP6_BUFFER_RECEIVED received buffer from %1:%2 to %3:%4 over interface %5</term>
<listitem><para>
This debug message is logged when the server has received a packet
over the socket. When the message is logged the contents of the received
packet hasn't been parsed yet. The only available information is the
interface and the source and destination addresses/ports.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_BUFFER_UNPACK">
<term>DHCP6_BUFFER_UNPACK parsing buffer received from %1 to %2 over interface %3</term>
<listitem><para>
This debug message is issued when the server starts parsing the received
buffer holding the DHCPv6 message. The arguments specify the source and
destination addresses as well as the interface over which the buffer has
been received.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_BUFFER_WAIT">
<term>DHCP6_BUFFER_WAIT waiting for next DHCPv6 packet with timeout %1 ms</term>
<listitem><para>
This debug message is issued when the server enters the state when it
waits for new packets. The argument specifies the timeout for the server
to wait for the packet. When this time elapses the server will pass
through its main loop to perform handling of any pending signals
and timers. After that, it will enter the wait state again.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_BUFFER_WAIT_INTERRUPTED">
<term>DHCP6_BUFFER_WAIT_INTERRUPTED interrupted wait for the next packet due to timeout, signal or external socket callback (timeout value is %1)</term>
<listitem><para>
This debug message is issued when the server interrupts waiting
for reception of the next DHCPv6 message due to timeout, signal
or reception of the data over socket other than used for DHCPv6
message transmission. The server will now handle signals
received and ready timers before waiting for next packets again.
The argument specifies the timeout value in milliseconds.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_BUFFER_WAIT_SIGNAL">
<term>DHCP6_BUFFER_WAIT_SIGNAL signal received while waiting for next packet, next waiting signal is %1</term>
<listitem><para>
This debug message is issued when the server was waiting for the
packet, but the wait has been interrupted by the signal received
by the process. The signal will be handled before the server starts
waiting for next packets. The argument specifies the next signal to
be handled by the server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CCSESSION_STARTED">
<term>DHCP6_CCSESSION_STARTED control channel session started on socket %1</term>
<listitem><para>
A debug message issued during startup after the IPv6 DHCP server has
successfully established a session with the Kea control channel.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CCSESSION_STARTING">
<term>DHCP6_CCSESSION_STARTING starting control channel session, specfile: %1</term>
<listitem><para>
This debug message is issued just before the IPv6 DHCP server attempts
to establish a session with the Kea control channel.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CLASS_ASSIGNED">
<term>DHCP6_CLASS_ASSIGNED %1: client packet has been assigned to the following class(es): %2</term>
<listitem><para>
This debug message informs that incoming packet has been assigned to specified
class or classes. This is a normal behavior and indicates successful operation.
The first argument specifies the client and transaction identification
information. The second argument includes all classes to which the
packet has been assigned.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CLASS_UNCONFIGURED">
<term>DHCP6_CLASS_UNCONFIGURED %1: client packet belongs to an unconfigured class: %1</term>
<listitem><para>
This debug message informs that incoming packet belongs to a class
which cannot be found in the configuration. Either a hook written
before the classification was added to Kea is used, or class naming is
inconsistent.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_COMMAND_RECEIVED">
<term>DHCP6_COMMAND_RECEIVED received command %1, arguments: %2</term>
<listitem><para>
A debug message listing the command (and possible arguments) received
from the Kea control system by the IPv6 DHCP server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CONFIG_COMPLETE">
<term>DHCP6_CONFIG_COMPLETE DHCPv6 server has completed configuration: %1</term>
<listitem><para>
This is an informational message announcing the successful processing of a
new configuration. it is output during server startup, and when an updated
configuration is committed by the administrator.  Additional information
may be provided.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CONFIG_LOAD_FAIL">
<term>DHCP6_CONFIG_LOAD_FAIL configuration error using file: %1, reason: %2</term>
<listitem><para>
This error message indicates that the DHCPv6 configuration has failed.
If this is an initial configuration (during server's startup) the server
will fail to start. If this is a dynamic reconfiguration attempt the
server will continue to use an old configuration.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CONFIG_NEW_SUBNET">
<term>DHCP6_CONFIG_NEW_SUBNET a new subnet has been added to configuration: %1</term>
<listitem><para>
This is an informational message reporting that the configuration has
been extended to include the specified subnet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CONFIG_OPTION_DUPLICATE">
<term>DHCP6_CONFIG_OPTION_DUPLICATE multiple options with the code: %1 added to the subnet: %2</term>
<listitem><para>
This warning message is issued on an attempt to configure multiple options with the
same option code for the particular subnet. Adding multiple options is uncommon
for DHCPv6, but it is not prohibited.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CONFIG_RECEIVED">
<term>DHCP6_CONFIG_RECEIVED received configuration: %1</term>
<listitem><para>
A debug message listing the configuration received by the DHCPv6 server.
The source of that configuration depends on used configuration backend.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CONFIG_START">
<term>DHCP6_CONFIG_START DHCPv6 server is processing the following configuration: %1</term>
<listitem><para>
This is a debug message that is issued every time the server receives a
configuration. That happens start up and also when a server configuration
change is committed by the administrator.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_CONFIG_UPDATE">
<term>DHCP6_CONFIG_UPDATE updated configuration received: %1</term>
<listitem><para>
A debug message indicating that the IPv6 DHCP server has received an
updated configuration from the Kea configuration system.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DB_BACKEND_STARTED">
<term>DHCP6_DB_BACKEND_STARTED lease database started (type: %1, name: %2)</term>
<listitem><para>
This informational message is printed every time the IPv6 DHCP server
is started.  It indicates what database backend type is being to store
lease and other information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DDNS_CREATE_ADD_NAME_CHANGE_REQUEST">
<term>DHCP6_DDNS_CREATE_ADD_NAME_CHANGE_REQUEST created name change request: %1</term>
<listitem><para>
This debug message is logged when the new Name Change Request has been created
to perform the DNS Update, which adds new RRs.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DDNS_FQDN_GENERATED">
<term>DHCP6_DDNS_FQDN_GENERATED %1: generated FQDN for the client: %2</term>
<listitem><para>
This debug message is logged when the server generated FQDN (name)
for the client which message is processed. The names may be
generated by the server when required by the server's policy or
when the client doesn't provide any specific FQDN in its message
to the server. The first argument includes the client and
transaction identification information. The second argument includes
the generated FQDN.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DDNS_GENERATED_FQDN_UPDATE_FAIL">
<term>DHCP6_DDNS_GENERATED_FQDN_UPDATE_FAIL %1: failed to update the lease using address %2, after generating FQDN for a client, reason: %3</term>
<listitem><para>
This message indicates the failure when trying to update the lease and/or
options in the server's response with the hostname generated by the server
from the acquired address. The first argument includes the client and the
transaction identification information. The second argument is a leased
address. The third argument includes the reason for the failure.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DDNS_LEASE_RENEW_FQDN_CHANGE">
<term>DHCP6_DDNS_LEASE_RENEW_FQDN_CHANGE FQDN %1: FQDN for the renewed lease: %2 has changed. New values: hostname = %3, reverse mapping = %4, forward mapping = %5</term>
<listitem><para>
This debug message is logged when FQDN mapping for a particular lease has been
changed by the recent Renew message. This mapping will be changed in DNS.
The first argument includes the client and the transaction identification
information. The second argument holds the details about the lease for which
the FQDN information and/or mappings have changed. The remaining arguments
hold the new FQDN information and flags for mappings.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DDNS_RECEIVE_FQDN">
<term>DHCP6_DDNS_RECEIVE_FQDN %1: received DHCPv6 Client FQDN option: %2</term>
<listitem><para>
This debug message is logged when server has found the DHCPv6 Client FQDN Option
sent by a client and started processing it. The first argument includes the
client and transaction identification information. The second argument
includes the received FQDN.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DDNS_REQUEST_SEND_FAILED">
<term>DHCP6_DDNS_REQUEST_SEND_FAILED failed sending a request to kea-dhcp-ddns, error: %1,  ncr: %2</term>
<listitem><para>
This error message indicates that IPv6 DHCP server failed to send a DDNS
update request to the DHCP-DDNS server. This is most likely a configuration or
networking error.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DDNS_RESPONSE_FQDN_DATA">
<term>DHCP6_DDNS_RESPONSE_FQDN_DATA %1: including FQDN option in the server's response: %2</term>
<listitem><para>
This debug message is issued when the server is adding the Client FQDN
option in its response to the client. The first argument includes the
client and transaction identification information. The second argument
includes the details of the FQDN option being included. Note that the
name carried in the FQDN option may be modified by the server when
the lease is acquired for the client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DDNS_SEND_FQDN">
<term>DHCP6_DDNS_SEND_FQDN sending DHCPv6 Client FQDN Option to the client: %1</term>
<listitem><para>
This debug message is logged when server includes an DHCPv6 Client FQDN Option
in its response to the client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DEACTIVATE_INTERFACE">
<term>DHCP6_DEACTIVATE_INTERFACE deactivate interface %1</term>
<listitem><para>
This message is printed when DHCPv6 server disables an interface from being
used to receive DHCPv6 traffic. Sockets on this interface will not be opened
by the Interface Manager until interface is enabled.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DECLINE_FAIL_DUID_MISMATCH">
<term>DHCP6_DECLINE_FAIL_DUID_MISMATCH Client %1 sent DECLINE for address %2, but it belongs to client with DUID %3</term>
<listitem><para>
This informational message is printed when a client attempts to decline
a lease, but that lease belongs to a different client. The decline request
will be rejected.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DECLINE_FAIL_IAID_MISMATCH">
<term>DHCP6_DECLINE_FAIL_IAID_MISMATCH Client %1 sent DECLINE for address %2, but used a wrong IAID (%3), instead of expected %4</term>
<listitem><para>
This informational message is printed when a client attempts to decline
a lease. The server has a lease for this address, it belongs to this client,
but the recorded IAID does not match what client has sent. This means
the server will reject this Decline.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DECLINE_FAIL_LEASE_WITHOUT_DUID">
<term>DHCP6_DECLINE_FAIL_LEASE_WITHOUT_DUID Client %1 sent DECLINE for address %2, but the associated lease has no DUID</term>
<listitem><para>
This error condition likely indicates database corruption, as every IPv6
lease is supposed to have a DUID, even if it is an empty one.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DECLINE_FAIL_NO_LEASE">
<term>DHCP6_DECLINE_FAIL_NO_LEASE Client %1 sent DECLINE for address %2, but there's no lease for it</term>
<listitem><para>
This informational message is printed when a client tried to decline an address,
but the server has no lease for said address. This means that the server's
and client's perception of the leases are different. The likely causes
of this could be: a confused (e.g. skewed clock) or broken client (e.g. client
moved to a different location and didn't notice) or possibly an attack
(a rogue client is trying to decline random addresses). The server will
inform the client that his decline request was rejected and client should
be able to recover from that.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DECLINE_LEASE">
<term>DHCP6_DECLINE_LEASE Client %1 sent DECLINE for address %2 and the server marked it as declined. The lease will be recovered in %3 seconds.</term>
<listitem><para>
This informational message indicates that the client leased an address, but
discovered that it is being used by some other devicea and reported this to the
server by sending a Decline message. The server marked the lease as
declined. This likely indicates a misconfiguration in the network. Either
the server is configured with an incorrect pool or there are devices that have
statically assigned addresses that are supposed to be assigned by the DHCP
server. Both client (will request a different address) and server (will recover
the lease after decline-probation-time elapses) will recover automatically.
However, if the underlying problem is not solved, the conditions leading
to this message may reappear.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DECLINE_PROCESS_IA">
<term>DHCP6_DECLINE_PROCESS_IA Processing of IA (IAID: %1) from client %2 started.</term>
<listitem><para>
This debug message is printed when the server starts processing an IA_NA option
received in Decline message. It's expected that the option will contain an
address that is being declined. Specific information will be printed in a
separate message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DYNAMIC_RECONFIGURATION">
<term>DHCP6_DYNAMIC_RECONFIGURATION initiate server reconfiguration using file: %1, after receiving SIGHUP signal</term>
<listitem><para>
This is the info message logged when the DHCPv6 server starts reconfiguration
as a result of receiving SIGHUP signal.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_DYNAMIC_RECONFIGURATION_FAIL">
<term>DHCP6_DYNAMIC_RECONFIGURATION_FAIL dynamic server reconfiguration failed with file: %1</term>
<listitem><para>
This is an error message logged when the dynamic reconfiguration of the
DHCP server failed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HANDLE_SIGNAL_EXCEPTION">
<term>DHCP6_HANDLE_SIGNAL_EXCEPTION An exception was thrown while handing signal: %1</term>
<listitem><para>
This error message is printed when an exception was raised during signal
processing. This likely indicates a coding error and should be reported to ISC.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOKS_LIBS_RELOAD_FAIL">
<term>DHCP6_HOOKS_LIBS_RELOAD_FAIL reload of hooks libraries failed</term>
<listitem><para>
A "libreload" command was issued to reload the hooks libraries but for
some reason the reload failed.  Other error messages issued from the
hooks framework will indicate the nature of the problem.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_BUFFER_RCVD_SKIP">
<term>DHCP6_HOOK_BUFFER_RCVD_SKIP received buffer from %1 to %2 over interface %3 was dropped because a callout set the skip flag</term>
<listitem><para>
This debug message is printed when a callout installed on buffer6_receive
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
The arguments specify the source and destination address as well as
the name of the interface over which the buffer has been received.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_BUFFER_SEND_SKIP">
<term>DHCP6_HOOK_BUFFER_SEND_SKIP %1: prepared DHCPv6 response was dropped because a callout set the skip flag</term>
<listitem><para>
This debug message is printed when a callout installed on buffer6_send
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
Server completed all the processing (e.g. may have assigned, updated
or released leases), but the response will not be send to the client.
The argument includes the client and transaction identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_DECLINE_DROP">
<term>DHCP6_HOOK_DECLINE_DROP During Decline processing (client=%1, interface=%2, addr=%3) hook callout set status to DROP, dropping packet.</term>
<listitem><para>
This message indicates that the server received DECLINE message, it was verified
to be correct and matching server's lease information. The server called hooks
for the lease6_decline hook point and one of the callouts set next step status to DROP.
The server will now abort processing of the packet as if it was never
received. The lease will continue to be assigned to this client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_DECLINE_SKIP">
<term>DHCP6_HOOK_DECLINE_SKIP During Decline processing (client=%1, interface=%2, addr=%3) hook callout set status to SKIP, skipping decline.</term>
<listitem><para>
This message indicates that the server received DECLINE message, it was verified
to be correct and matching server's lease information. The server called hooks
for the lease6_decline hook point and one of the callouts set next step status to SKIP.
The server will skip the operation of moving the lease to the declined state and
will continue processing the packet. In particular, it will send a REPLY message
as if the decline actually took place.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_LEASE6_RELEASE_NA_SKIP">
<term>DHCP6_HOOK_LEASE6_RELEASE_NA_SKIP %1: DHCPv6 address lease was not released because a callout set the skip flag</term>
<listitem><para>
This debug message is printed when a callout installed on the
lease6_release hook point set the skip flag. For this particular hook
point, the setting of the flag by a callout instructs the server to not
release a lease. If a client requested the release of multiples leases
(by sending multiple IA options), the server will retain this particular
lease and proceed with other releases as usual. The argument holds the
client and transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_LEASE6_RELEASE_PD_SKIP">
<term>DHCP6_HOOK_LEASE6_RELEASE_PD_SKIP %1: prefix lease was not released because a callout set the skip flag</term>
<listitem><para>
This debug message is printed when a callout installed on lease6_release
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to not release
a lease. If client requested release of multiples leases (by sending
multiple IA options), the server will retains this particular lease and
will proceed with other renewals as usual. The argument holds the
client and transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_PACKET_RCVD_SKIP">
<term>DHCP6_HOOK_PACKET_RCVD_SKIP %1: packet is dropped, because a callout set the skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on the pkt6_receive
hook point sets the skip flag. For this particular hook point, the
setting of the flag instructs the server to drop the packet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_PACKET_SEND_SKIP">
<term>DHCP6_HOOK_PACKET_SEND_SKIP %1: prepared DHCPv6 response was not sent because a callout set the skip flag</term>
<listitem><para>
This debug message is printed when a callout installed on the pkt6_send
hook point set the skip flag. For this particular hook point, the setting
of the flag by a callout instructs the server to drop the packet. This
effectively means that the client will not get any response, even though
the server processed client's request and acted on it (e.g. possibly
allocated a lease). The argument specifies the client and transaction
identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_HOOK_SUBNET6_SELECT_SKIP">
<term>DHCP6_HOOK_SUBNET6_SELECT_SKIP %1: no subnet was selected because a callout set the skip flag</term>
<listitem><para>
This debug message is printed when a callout installed on the
subnet6_select hook point set the skip flag. For this particular hook
point, the setting of the flag instructs the server not to choose a
subnet, an action that severely limits further processing; the server
will be only able to offer global options - no addresses or prefixes
will be assigned. The argument holds the client and transaction
identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_INIT_FAIL">
<term>DHCP6_INIT_FAIL failed to initialize Kea server: %1</term>
<listitem><para>
The server has failed to establish communication with the rest of Kea,
failed to read JSON configuration file or encountered any other critical
issue that prevents it from starting up properly. Attached error message
provides more details about the issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_LEASE_ADVERT">
<term>DHCP6_LEASE_ADVERT %1: lease for address %2 and iaid=%3 will be advertised</term>
<listitem><para>
This debug message indicates that the server will advertise an
address to the client in the ADVERTISE message. The client will
request allocation of this address with the REQUEST message sent
in the next message exchange. The first argument includes the client
and transaction identification information. The remaining arguments
hold the allocated address and IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_LEASE_ADVERT_FAIL">
<term>DHCP6_LEASE_ADVERT_FAIL %1: failed to advertise an address lease for iaid=%2</term>
<listitem><para>
This message indicates that in response to a received SOLICIT, the server
failed to advertise a non-temporary lease for a given client. There may
be many reasons for such failure. Each failure is logged in a separate
log entry. The first argument holds the client and transaction identification
information. The second argument holds the IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_LEASE_ALLOC">
<term>DHCP6_LEASE_ALLOC %1: lease for address %2 and iaid=%3 has been allocated</term>
<listitem><para>
This debug message indicates that in response to a client's REQUEST
message, the server successfully granted an non-temporary address
lease. This is a normal behavior and indicates successful operation.
The first argument includes the client and transaction identification
information. The remaining arguments hold the allocated address and
IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_LEASE_ALLOC_FAIL">
<term>DHCP6_LEASE_ALLOC_FAIL %1: failed to grant an address lease for iaid=%2</term>
<listitem><para>
This message indicates that in response to a received REQUEST, the server
failed to grant a non-temporary address lease for the client. There may
be many reasons for such failure. Each failure is logged in a separate
log entry. The first argument holds the client and transaction identification
information. The second argument holds the IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_LEASE_DATA">
<term>DHCP6_LEASE_DATA %1: detailed lease information for iaid=%2: %3</term>
<listitem><para>
This debug message is used to print the detailed information about the
allocated lease or a lease which will be advertised to the client.
The first argument holds the client and the transaction identification
information. The second argument holds the IAID. The third argument
holds the detailed lease information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_LEASE_NA_WITHOUT_DUID">
<term>DHCP6_LEASE_NA_WITHOUT_DUID %1: address lease for address %2 does not have a DUID</term>
<listitem><para>
This error message indicates a database consistency problem. The lease
database has an entry indicating that the given address is in use,
but the lease does not contain any client identification. This is most
likely due to a software error: please raise a bug report. As a temporary
workaround, manually remove the lease entry from the database. The first
argument includes the client and transaction identification information.
The second argument holds the address to be released.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_LEASE_PD_WITHOUT_DUID">
<term>DHCP6_LEASE_PD_WITHOUT_DUID %1: lease for prefix %2/%3 does not have a DUID</term>
<listitem><para>
This error message indicates a database consistency failure. The lease
database has an entry indicating that the given prefix is in use,
but the lease does not contain any client identification. This is most
likely due to a software error: please raise a bug report. As a temporary
workaround, manually remove the lease entry from the database. The
first argument includes client and transaction identification
information. The second and third argument hold the prefix and the
prefix length.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_NOT_RUNNING">
<term>DHCP6_NOT_RUNNING IPv6 DHCP server is not running</term>
<listitem><para>
A warning message is issued when an attempt is made to shut down the
IPv6 DHCP server but it is not running.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_NO_INTERFACES">
<term>DHCP6_NO_INTERFACES failed to detect any network interfaces</term>
<listitem><para>
During startup the IPv6 DHCP server failed to detect any network
interfaces and is therefore shutting down.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_NO_SOCKETS_OPEN">
<term>DHCP6_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic</term>
<listitem><para>
This warning message is issued when current server configuration specifies
no interfaces that server should listen on, or specified interfaces are not
configured to receive the traffic.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_OPEN_SOCKET">
<term>DHCP6_OPEN_SOCKET opening sockets on port %1</term>
<listitem><para>
A debug message issued during startup, this indicates that the IPv6 DHCP
server is about to open sockets on the specified port.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_OPEN_SOCKET_FAIL">
<term>DHCP6_OPEN_SOCKET_FAIL failed to open socket: %1</term>
<listitem><para>
A warning message issued when IfaceMgr fails to open and bind a socket. The reason
for the failure is appended as an argument of the log message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PACKET_DROP_PARSE_FAIL">
<term>DHCP6_PACKET_DROP_PARSE_FAIL failed to parse packet from %1 to %2, received over interface %3, reason: %4</term>
<listitem><para>
The DHCPv4 server has received a packet that it is unable to
interpret. The reason why the packet is invalid is included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PACKET_DROP_SERVERID_MISMATCH">
<term>DHCP6_PACKET_DROP_SERVERID_MISMATCH %1: dropping packet with server identifier: %2, server is using: %3</term>
<listitem><para>
A debug message noting that server has received message with server identifier
option that not matching server identifier that server is using.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PACKET_DROP_UNICAST">
<term>DHCP6_PACKET_DROP_UNICAST %1: dropping unicast %2 packet as this packet should be sent to multicast</term>
<listitem><para>
This debug message is issued when the server drops the unicast packet,
because packets of this type must be sent to multicast. The first argument
specifies the client and transaction identification information, the
second argument specifies packet type.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PACKET_PROCESS_FAIL">
<term>DHCP6_PACKET_PROCESS_FAIL processing of %1 message received from %2 failed: %3</term>
<listitem><para>
This is a general catch-all message indicating that the processing of the
specified packet type from the indicated address failed.  The reason is given in the
message.  The server will not send a response but will instead ignore the packet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PACKET_RECEIVED">
<term>DHCP6_PACKET_RECEIVED %1: %2 (type %3) received from %4 to %5 on interface %6</term>
<listitem><para>
A debug message noting that the server has received the specified type of
packet on the specified interface. The first argument specifies the
client and transaction identification information. The second and third
argument specify the name of the DHCPv6 message and its numeric type
respectively. The remaining arguments specify the source address,
destination IP address and the name of the interface on which the
message has been received.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PACKET_RECEIVE_FAIL">
<term>DHCP6_PACKET_RECEIVE_FAIL error on attempt to receive packet: %1</term>
<listitem><para>
The IPv6 DHCP server tried to receive a packet but an error
occurred during this attempt. The reason for the error is included in
the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PACKET_SEND_FAIL">
<term>DHCP6_PACKET_SEND_FAIL failed to send DHCPv6 packet: %1</term>
<listitem><para>
This error is output if the IPv6 DHCP server fails to send an assembled
DHCP message to a client. The reason for the error is included in the
message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PACK_FAIL">
<term>DHCP6_PACK_FAIL failed to assemble response correctly</term>
<listitem><para>
This error is output if the server failed to assemble the data to be
returned to the client into a valid packet.  The reason is most likely
to be to a programming error: please raise a bug report.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PARSER_COMMIT_EXCEPTION">
<term>DHCP6_PARSER_COMMIT_EXCEPTION parser failed to commit changes</term>
<listitem><para>
On receipt of message containing details to a change of the IPv6 DHCP
server configuration, a set of parsers were successfully created, but one
of them failed to commit its changes due to a low-level system exception
being raised.  Additional messages may be output indicating the reason.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PARSER_COMMIT_FAIL">
<term>DHCP6_PARSER_COMMIT_FAIL parser failed to commit changes: %1</term>
<listitem><para>
On receipt of message containing details to a change of the IPv6 DHCP
server configuration, a set of parsers were successfully created, but
one of them failed to commit its changes.  The reason for the failure
is given in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PARSER_CREATED">
<term>DHCP6_PARSER_CREATED created parser for configuration element %1</term>
<listitem><para>
A debug message output during a configuration update of the IPv6 DHCP
server, notifying that the parser for the specified configuration element
has been successfully created.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PARSER_EXCEPTION">
<term>DHCP6_PARSER_EXCEPTION failed to create or run parser for configuration element %1</term>
<listitem><para>
On receipt of message containing details to a change of its configuration,
the IPv6 DHCP server failed to create a parser to decode the contents of
the named configuration element, or the creation succeeded but the parsing
actions and committal of changes failed.  The message has been output in
response to a non-Kea exception being raised.  Additional messages
may give further information.
</para><para>
The most likely cause of this is that the specification file for the
server (which details the allowable contents of the configuration) is
not correct for this version of Kea.  This may be the result of an
interrupted installation of an update to Kea.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PARSER_FAIL">
<term>DHCP6_PARSER_FAIL failed to create or run parser for configuration element %1: %2</term>
<listitem><para>
On receipt of message containing details to a change of its configuration,
the IPv6 DHCP server failed to create a parser to decode the contents
of the named configuration element, or the creation succeeded but the
parsing actions and committal of changes failed.  The reason for the
failure is given in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PD_LEASE_ADVERT">
<term>DHCP6_PD_LEASE_ADVERT %1: lease for prefix %2/%3 and iaid=%4 will be advertised</term>
<listitem><para>
This debug message indicates that the server will advertise a
prefix to the client in the ADVERTISE message. The client will
request allocation of this prefix with the REQUEST message sent
in the next message exchange. The first argument includes the client
and transaction identification information. The remaining arguments
hold the allocated prefix, prefix length and IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PD_LEASE_ADVERT_FAIL">
<term>DHCP6_PD_LEASE_ADVERT_FAIL %1: failed to advertise a prefix lease for iaid=%2</term>
<listitem><para>
This message indicates that in response to a received SOLICIT, the
server failed to advertise a prefix lease for a given client. There may
be many reasons for such failure. Each failure is logged in a separate
log entry. The first argument holds the client and transaction identification
information. The second argument holds the IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PD_LEASE_ALLOC">
<term>DHCP6_PD_LEASE_ALLOC %1: lease for prefix %2/%3 and iaid=%4 has been allocated</term>
<listitem><para>
This debug message indicates that in response to a client's REQUEST
message, the server successfully granted an non-temporary address
lease. This is a normal behavior and indicates successful operation.
The first argument includes the client and transaction identification
information. The remaining arguments hold the allocated prefix,
prefix length and and IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PD_LEASE_ALLOC_FAIL">
<term>DHCP6_PD_LEASE_ALLOC_FAIL %1: failed to grant a prefix lease for iaid=%2</term>
<listitem><para>
This message indicates that in response to a received REQUEST, the server
failed to grant a prefix lease for the client. There may be many reasons
for such failure. Each failure is logged in a separate log entry. The first
argument holds the client and transaction identification information.
The second argument holds the IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PROCESS_IA_NA_EXTEND">
<term>DHCP6_PROCESS_IA_NA_EXTEND %1: extending lease lifetime for IA_NA option with iaid=%2</term>
<listitem><para>
This message is logged when the server is starting to extend the lifetime
of the address lease associated with the particular IAID. The first argument
includes the client and transaction identification information. The second
argument contains the IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PROCESS_IA_NA_RELEASE">
<term>DHCP6_PROCESS_IA_NA_RELEASE %1: releasing lease for IA_NA option with iaid=%2</term>
<listitem><para>
This message is logged when the server is trying to release the client's
as a result of receiving the RELEASE message. The first argument
includes the client and transaction identification information. The second
argument contains the IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PROCESS_IA_NA_REQUEST">
<term>DHCP6_PROCESS_IA_NA_REQUEST %1: server is processing IA_NA option with iaid=%2 and hint=%3</term>
<listitem><para>
This is a debug message that indicates the processing of a received
IA_NA option. The first argument contains the client and the transaction
identification information. The second argument holds the IAID of the
IA_NA option. The third argument may hold the hint for the server
about the address that the client would like to have allocated.
If there is no hint, the argument should provide the text indicating
that the hint hasn't been sent.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PROCESS_IA_PD_EXTEND">
<term>DHCP6_PROCESS_IA_PD_EXTEND %1: extending lease lifetime for IA_PD option with iaid=%2</term>
<listitem><para>
This message is logged when the server is starting to extend the lifetime
of the prefix lease associated with the particular IAID. The first argument
includes the client and transaction identification information. The second
argument contains the IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_PROCESS_IA_PD_REQUEST">
<term>DHCP6_PROCESS_IA_PD_REQUEST %1: server is processing IA_PD option with iaid=%2 and hint=%3</term>
<listitem><para>
This is a debug message that indicates a processing of received IA_PD
option. The first argument contains the client and the transaction
identification information. The second argument holds the IAID of the
IA_PD option. The third argument may hold the hint for the server
about the prefix that the client would like to have allocated.
If there is no hint, the argument should provide the text indicating
that the hint hasn't been sent.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_QUERY_DATA">
<term>DHCP6_QUERY_DATA %1, packet details: %2</term>
<listitem><para>
A debug message printing the details of the received packet. The first
argument includes the client and the transaction identification
information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RAPID_COMMIT">
<term>DHCP6_RAPID_COMMIT %1: Rapid Commit option received, following 2-way exchange</term>
<listitem><para>
This debug message is issued when the server found a Rapid Commit option
in the client's message and 2-way exchanges are supported by the
server for the subnet on which the client is connected. The argument
specifies the client and transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RELEASE_NA">
<term>DHCP6_RELEASE_NA %1: binding for address %2 and iaid=%3 was released properly</term>
<listitem><para>
This debug message indicates that an address was released properly. It
is a normal operation during client shutdown.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RELEASE_NA_FAIL">
<term>DHCP6_RELEASE_NA_FAIL %1: failed to remove address lease for address %2 and iaid=%3</term>
<listitem><para>
This error message indicates that the software failed to remove an address
lease from the lease database.  It probably due to an error during a
database operation: resolution will most likely require administrator
intervention (e.g. check if DHCP process has sufficient privileges to
update the database). It may also be triggered if a lease was manually
removed from the database during RELEASE message processing. The first
argument holds the client and transaction identification information.
The second and third argument hold the released address and IAID
respectively.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RELEASE_NA_FAIL_WRONG_DUID">
<term>DHCP6_RELEASE_NA_FAIL_WRONG_DUID %1: client tried to release address %2, but it belongs to another client using duid=%3</term>
<listitem><para>
This warning message indicates that a client tried to release an address
that belongs to a different client. This should not happen in normal
circumstances and may indicate a misconfiguration of the client.  However,
since the client releasing the address will stop using it anyway, there
is a good chance that the situation will correct itself.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RELEASE_NA_FAIL_WRONG_IAID">
<term>DHCP6_RELEASE_NA_FAIL_WRONG_IAID %1: client tried to release address %2, but it used wrong IAID (expected %3, but got %4)</term>
<listitem><para>
This warning message indicates that client tried to release an address
that does belong to it, but the address was expected to be in a different
IA (identity association) container. This probably means that the client's
support for multiple addresses is flawed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RELEASE_PD">
<term>DHCP6_RELEASE_PD %1: prefix %2/%3 for iaid=%4 was released properly</term>
<listitem><para>
This debug message indicates that a prefix was released properly. It
is a normal operation during client shutdown. The first argument holds
the client and transaction identification information. The second and
third argument define the prefix and its length. The fourth argument
holds IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RELEASE_PD_FAIL">
<term>DHCP6_RELEASE_PD_FAIL %1: failed to release prefix %2/%3 for iaid=%4</term>
<listitem><para>
This error message indicates that the software failed to remove a prefix
lease from the lease database.  It probably due to an error during a
database operation: resolution will most likely require administrator
intervention (e.g. check if DHCP process has sufficient privileges to
update the database). It may also be triggered if a lease was manually
removed from the database during RELEASE message processing. The
first argument hold the client and transaction identification
information. The second and third argument define the prefix and
its length. The fourth argument holds the IAID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RELEASE_PD_FAIL_WRONG_DUID">
<term>DHCP6_RELEASE_PD_FAIL_WRONG_DUID %1: client tried to release prefix %2/%3, but it belongs to another client (duid=%4)</term>
<listitem><para>
This warning message indicates that client tried to release a prefix
that belongs to a different client. This should not happen in normal
circumstances and may indicate a misconfiguration of the client.  However,
since the client releasing the prefix will stop using it anyway, there
is a good chance that the situation will correct itself. The first
argument includes the client and the transaction identification
information. The second and third argument include the prefix and
prefix length. The last argument holds the DUID of the client holding
the lease.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RELEASE_PD_FAIL_WRONG_IAID">
<term>DHCP6_RELEASE_PD_FAIL_WRONG_IAID %1: client tried to release prefix %2/%3, but it used wrong IAID (expected %4, but got %5)</term>
<listitem><para>
This warning message indicates that client tried to release a prefix
that does belong to it, but the address was expected to be in a different
IA (identity association) container. This probably means that the client's
support for multiple prefixes is flawed. The first argument includes the
client and transaction identification information. The second and third
argument identify the prefix. The fourth and fifth argument hold the
expected IAID and IAID found respectively.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_REQUIRED_OPTIONS_CHECK_FAIL">
<term>DHCP6_REQUIRED_OPTIONS_CHECK_FAIL %1 message received from %2 failed the following check: %3</term>
<listitem><para>
This message indicates that received DHCPv6 packet is invalid.  This may be due
to a number of reasons, e.g. the mandatory client-id option is missing,
the server-id forbidden in that particular type of message is present,
there is more than one instance of client-id or server-id present,
etc. The exact reason for rejecting the packet is included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_RESPONSE_DATA">
<term>DHCP6_RESPONSE_DATA responding with packet type %1 data is %2</term>
<listitem><para>
A debug message listing the data returned to the client.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SERVER_FAILED">
<term>DHCP6_SERVER_FAILED server failed: %1</term>
<listitem><para>
The IPv6 DHCP server has encountered a fatal error and is terminating.
The reason for the failure is included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SHUTDOWN">
<term>DHCP6_SHUTDOWN server shutdown</term>
<listitem><para>
The IPv6 DHCP server has terminated normally.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SHUTDOWN_REQUEST">
<term>DHCP6_SHUTDOWN_REQUEST shutdown of server requested</term>
<listitem><para>
This debug message indicates that a shutdown of the IPv6 server has
been requested via a call to the 'shutdown' method of the core Dhcpv6Srv
object.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SOCKET_UNICAST">
<term>DHCP6_SOCKET_UNICAST server is about to open socket on address %1 on interface %2</term>
<listitem><para>
This is a debug message that inform that a unicast socket will be opened.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SRV_CONSTRUCT_ERROR">
<term>DHCP6_SRV_CONSTRUCT_ERROR error creating Dhcpv6Srv object, reason: %1</term>
<listitem><para>
This error message indicates that during startup, the construction of a
core component within the IPv6 DHCP server (the Dhcpv6 server object)
has failed.  As a result, the server will exit.  The reason for the
failure is given within the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SRV_D2STOP_ERROR">
<term>DHCP6_SRV_D2STOP_ERROR error stopping IO with DHCP_DDNS during shutdown: %1</term>
<listitem><para>
This error message indicates that during shutdown, an erro occurred while
stopping IO between the DHCPv6 server and the DHCP_DDNS server.  This is
probably due to a programmatic error is not likely to impact either server
upon restart.  The reason for the failure is given within the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_STANDALONE">
<term>DHCP6_STANDALONE skipping message queue, running standalone</term>
<listitem><para>
This is a debug message indicating that the IPv6 server is running in
standalone mode, not connected to the message queue.  Standalone mode
is only useful during program development, and should not be used in a
production environment.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_STARTED">
<term>DHCP6_STARTED Kea DHCPv6 server version %1 started</term>
<listitem><para>
This informational message indicates that the IPv6 DHCP server has
processed all configuration information and is ready to process
DHCPv6 packets.  The version is also printed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_STARTING">
<term>DHCP6_STARTING Kea DHCPv6 server version %1 starting</term>
<listitem><para>
This informational message indicates that the IPv6 DHCP server has
processed any command-line switches and is starting. The version
is also printed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_START_INFO">
<term>DHCP6_START_INFO pid: %1, port: %2, verbose: %3</term>
<listitem><para>
This is a debug message issued during the IPv6 DHCP server startup.
It lists some information about the parameters with which the server
is running.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SUBNET_DATA">
<term>DHCP6_SUBNET_DATA %1: the selected subnet details: %2</term>
<listitem><para>
This debug message includes the details of the subnet selected for
the client. The first argument includes the client and the
transaction identification information. The second argument
includes the subnet details.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SUBNET_SELECTED">
<term>DHCP6_SUBNET_SELECTED %1: the subnet with ID %2 was selected for client assignments</term>
<listitem><para>
This is a debug message noting the selection of a subnet to be used for
address and option assignment. Subnet selection is one of the early
steps in the processing of incoming client message. The first
argument includes the client and the transaction identification
information. The second argument holds the selected subnet id.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_SUBNET_SELECTION_FAILED">
<term>DHCP6_SUBNET_SELECTION_FAILED %1: failed to select subnet for the client</term>
<listitem><para>
This debug message indicates that the server failed to select the
subnet for the client which has sent a message to the server.
The cause is likely due to a misconfiguration of the server. The packet
processing will continue, but the response will only contain generic
configuration and no addresses or prefixes. The argument includes
the client and the transaction identification information.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_UNKNOWN_MSG_RECEIVED">
<term>DHCP6_UNKNOWN_MSG_RECEIVED received unknown message (type %d) on interface %2</term>
<listitem><para>
This debug message is printed when server receives a message of unknown type.
That could either mean missing functionality or invalid or broken relay or client.
The list of formally defined message types is available here:
http://www.iana.org/assignments/dhcpv6-parameters.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP6_USING_SERVERID">
<term>DHCP6_USING_SERVERID server is using server-id %1 and stores in the the file %2</term>
<listitem><para>
This info message is logged when the server reads its server-id from a
file or generates it. This message is a notification to the administrator
what server-id will be used and where it is persisted. Typically, there is
no need to modify the server id. However, it is possible to do it in the
Kea configuration file. It is important to understand the implications of
such modification. The clients will remember previous server-id, and will
use it to extend their leases. As a result, they will have to go through
a rebinding phase to re-acquire their leases and associate them with a
new server id.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="DHCPRSV">
    <title>DHCPRSV Module</title>
    <para>
      <variablelist>
<varlistentry id="DHCPRSV_MEMFILE_CONVERTING_LEASE_FILES">
<term>DHCPRSV_MEMFILE_CONVERTING_LEASE_FILES running LFC now to convert lease files to the current schema: %1.%2</term>
<listitem><para>
A warning message issued when the server has detected lease files that need
to be either upgraded or downgraded to match the server's schema, and that
the server is automatically running the LFC process to perform the conversion.
This should only occur the first time the server is launched following a Kea
installation upgrade (or downgrade).
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="DHCPSRV">
    <title>DHCPSRV Module</title>
    <para>
      <variablelist>
<varlistentry id="DHCPSRV_CFGMGR_ADD_IFACE">
<term>DHCPSRV_CFGMGR_ADD_IFACE listening on interface %1</term>
<listitem><para>
An info message issued when a new interface is being added to the collection of
interfaces on which the server listens to DHCP messages.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_ADD_SUBNET4">
<term>DHCPSRV_CFGMGR_ADD_SUBNET4 adding subnet %1</term>
<listitem><para>
A debug message reported when the DHCP configuration manager is adding the
specified IPv4 subnet to its database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_ADD_SUBNET6">
<term>DHCPSRV_CFGMGR_ADD_SUBNET6 adding subnet %1</term>
<listitem><para>
A debug message reported when the DHCP configuration manager is adding the
specified IPv6 subnet to its database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_ALL_IFACES_ACTIVE">
<term>DHCPSRV_CFGMGR_ALL_IFACES_ACTIVE enabling listening on all interfaces</term>
<listitem><para>
A debug message issued when the server is being configured to listen on all
interfaces.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_CFG_DHCP_DDNS">
<term>DHCPSRV_CFGMGR_CFG_DHCP_DDNS Setting DHCP-DDNS configuration to: %1</term>
<listitem><para>
A debug message issued when the server's DHCP-DDNS settings are changed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_CLEAR_ACTIVE_IFACES">
<term>DHCPSRV_CFGMGR_CLEAR_ACTIVE_IFACES stop listening on all interfaces</term>
<listitem><para>
A debug message issued when configuration manager clears the internal list
of active interfaces. This doesn't prevent the server from listening to
the DHCP traffic through open sockets, but will rather be used by Interface
Manager to select active interfaces when sockets are re-opened.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_CONFIGURE_SERVERID">
<term>DHCPSRV_CFGMGR_CONFIGURE_SERVERID server configuration includes specification of a server identifier</term>
<listitem><para>
This warning message is issued when the server specified configuration of
a server identifier. If this new configuration overrides an existing
server identifier, this will affect existing bindings of the clients.
Clients will use old server identifier when they renew their bindings.
The server will not respond to those renews, and the clients will
eventually transition to rebinding state. The server should reassign
existing bindings and the clients will subsequently use new server
identifier. It is recommended to not modify the server identifier, unless
there is a good reason for it, to avoid increased number of renewals and
a need for rebinding (increase of multicast traffic, which may be received
by multiple servers).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_NO_SUBNET4">
<term>DHCPSRV_CFGMGR_NO_SUBNET4 no suitable subnet is defined for address hint %1</term>
<listitem><para>
This debug message is output when the DHCP configuration manager has received
a request for an IPv4 subnet for the specified address, but no such
subnet exists.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_NO_SUBNET6">
<term>DHCPSRV_CFGMGR_NO_SUBNET6 no suitable subnet is defined for address hint %1</term>
<listitem><para>
This debug message is output when the DHCP configuration manager has received
a request for an IPv6 subnet for the specified address, but no such
subnet exists.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_ONLY_SUBNET4">
<term>DHCPSRV_CFGMGR_ONLY_SUBNET4 retrieved subnet %1 for address hint %2</term>
<listitem><para>
This is a debug message reporting that the DHCP configuration manager has
returned the specified IPv4 subnet when given the address hint specified
because it is the only subnet defined.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_ONLY_SUBNET6">
<term>DHCPSRV_CFGMGR_ONLY_SUBNET6 retrieved subnet %1 for address hint %2</term>
<listitem><para>
This is a debug message reporting that the DHCP configuration manager has
returned the specified IPv6 subnet when given the address hint specified
because it is the only subnet defined.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SOCKET_RAW_UNSUPPORTED">
<term>DHCPSRV_CFGMGR_SOCKET_RAW_UNSUPPORTED use of raw sockets is unsupported on this OS, UDP sockets will be used</term>
<listitem><para>
This warning message is logged when the user specified that the
DHCPv4 server should use the raw sockets to receive the DHCP
messages and respond to the clients, but the use of raw sockets
is not supported on the particular environment. The raw sockets
are useful when the server must respond to the directly connected
clients which don't have an address yet. If the raw sockets are
not supported by Kea on the particular platform, Kea will fall
back to use of the IP/UDP sockets. The responses to
the directly connected clients will be broadcast. The responses
to relayed clients will be unicast as usual.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT">
<term>DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type %1</term>
<listitem><para>
This informational message is logged when the administrator hasn't
specified the "dhcp-socket-type" parameter in configuration for interfaces.
In such case, the default socket type will be used.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT">
<term>DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type %1</term>
<listitem><para>
This informational message is logged when the DHCPv4 server selects the
socket type to be used for all sockets that will be opened on the
interfaces. Typically, the socket type is specified by the server
administrator. If the socket type hasn't been specified, the raw
socket will be selected. If the raw socket has been selected but
Kea doesn't support the use of raw sockets on the particular
OS, it will use an UDP socket instead.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SUBNET4">
<term>DHCPSRV_CFGMGR_SUBNET4 retrieved subnet %1 for address hint %2</term>
<listitem><para>
This is a debug message reporting that the DHCP configuration manager has
returned the specified IPv4 subnet when given the address hint specified
as the address is within the subnet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SUBNET4_RELAY">
<term>DHCPSRV_CFGMGR_SUBNET4_RELAY selected subnet %1, because of matching relay addr %2</term>
<listitem><para>
This is a debug message reporting that the DHCP configuration manager has
returned the specified IPv4 subnet, because detected relay agent address
matches value specified for this subnet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SUBNET6">
<term>DHCPSRV_CFGMGR_SUBNET6 retrieved subnet %1 for address hint %2</term>
<listitem><para>
This is a debug message reporting that the DHCP configuration manager has
returned the specified IPv6 subnet when given the address hint specified
as the address is within the subnet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SUBNET6_IFACE">
<term>DHCPSRV_CFGMGR_SUBNET6_IFACE selected subnet %1 for packet received over interface %2</term>
<listitem><para>
This is a debug message reporting that the DHCP configuration manager
has returned the specified IPv6 subnet for a packet received over
given interface.  This particular subnet was selected, because it
was specified as being directly reachable over given interface. (see
'interface' parameter in the subnet6 definition).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SUBNET6_IFACE_ID">
<term>DHCPSRV_CFGMGR_SUBNET6_IFACE_ID selected subnet %1 (interface-id match) for incoming packet</term>
<listitem><para>
This is a debug message reporting that the DHCP configuration manager
has returned the specified IPv6 subnet for a received packet. This particular
subnet was selected, because value of interface-id option matched what was
configured in the server's interface-id option for that selected subnet6.
(see 'interface-id' parameter in the subnet6 definition).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_SUBNET6_RELAY">
<term>DHCPSRV_CFGMGR_SUBNET6_RELAY selected subnet %1, because of matching relay addr %2</term>
<listitem><para>
This is a debug message reporting that the DHCP configuration manager has
returned the specified IPv6 subnet, because detected relay agent address
matches value specified for this subnet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_UNICAST_LINK_LOCAL">
<term>DHCPSRV_CFGMGR_UNICAST_LINK_LOCAL specified link local address %1 for unicast traffic on interface %2</term>
<listitem><para>
This warning message is logged when user specified a link-local address to
receive unicast traffic. The warning message is issued because it is an
uncommon use.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_USE_ADDRESS">
<term>DHCPSRV_CFGMGR_USE_ADDRESS listening on address %1, on interface %2</term>
<listitem><para>
A message issued when the server is configured to listen on the explicitly specified
IP address on the given interface.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CFGMGR_USE_UNICAST">
<term>DHCPSRV_CFGMGR_USE_UNICAST listening on unicast address %1, on interface %2</term>
<listitem><para>
An info message issued when configuring the DHCP server to listen on the unicast
address on the specific interface.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_CLOSE_DB">
<term>DHCPSRV_CLOSE_DB closing currently open %1 database</term>
<listitem><para>
This is a debug message, issued when the DHCP server closes the currently
open lease database.  It is issued at program shutdown and whenever
the database access parameters are changed: in the latter case, the
server closes the currently open database, and opens a database using
the new parameters.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_DHCP_DDNS_ERROR_EXCEPTION">
<term>DHCPSRV_DHCP_DDNS_ERROR_EXCEPTION error handler for DHCP_DDNS IO generated an expected exception: %1</term>
<listitem><para>
This is an error message that occurs when an attempt to send a request to
kea-dhcp-ddns fails there registered error handler threw an uncaught exception.
This is a programmatic error which should not occur. By convention, the error
handler should not propagate exceptions. Please report this error.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_DHCP_DDNS_HANDLER_NULL">
<term>DHCPSRV_DHCP_DDNS_HANDLER_NULL error handler for DHCP_DDNS IO is not set.</term>
<listitem><para>
This is an error message that occurs when an attempt to send a request to
kea-dhcp-ddns fails and there is no registered error handler.  This is a
programmatic error which should never occur and should be reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_DHCP_DDNS_NCR_REJECTED">
<term>DHCPSRV_DHCP_DDNS_NCR_REJECTED NameChangeRequest rejected by the sender: %1, ncr: %2</term>
<listitem><para>
This is an error message indicating that NameChangeSender used to deliver DDNS
update requests to kea-dhcp-ddns rejected the request.  This most likely cause
is the sender's queue has reached maximum capacity.  This would imply that
requests are being generated faster than they can be delivered.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_DHCP_DDNS_NCR_SENT">
<term>DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: %1</term>
<listitem><para>
A debug message issued when a NameChangeRequest has been successfully sent to
kea-dhcp-ddns.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_DHCP_DDNS_SENDER_STARTED">
<term>DHCPSRV_DHCP_DDNS_SENDER_STARTED NameChangeRequest sender has been started: %1</term>
<listitem><para>
A informational message issued when a communications with kea-dhcp-ddns has
been successfully started.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_DHCP_DDNS_SENDER_STOPPED">
<term>DHCPSRV_DHCP_DDNS_SENDER_STOPPED NameChangeRequest sender has been stopped.</term>
<listitem><para>
A informational message issued when a communications with kea-dhcp-ddns has
been stopped. This normally occurs during reconfiguration and as part of normal
shutdown. It may occur if kea-dhcp-ddns communications breakdown.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_DHCP_DDNS_SUSPEND_UPDATES">
<term>DHCPSRV_DHCP_DDNS_SUSPEND_UPDATES DHCP_DDNS updates are being suspended.</term>
<listitem><para>
This is a warning message indicating the DHCP_DDNS updates have been turned
off.  This should only occur if IO errors communicating with kea-dhcp-ddns
have been experienced.  Any such errors should have preceding entries in the
log with details.  No further attempts to communicate with kea-dhcp-ddns will
be made without intervention.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_HOOK_LEASE4_RECOVER_SKIP">
<term>DHCPSRV_HOOK_LEASE4_RECOVER_SKIP DHCPv4 lease %1 was not recoverd from the declined state because a callout set the skip status.</term>
<listitem><para>
This debug message is printed when a callout installed on lease4_recover
hook point set the next step status to SKIP. For this particular hook point, this
indicates that the server should not recover the lease from declined state.
The server will leave the lease as it is, in the declined state. The
server will attempt to recover it the next time decline recovery procedure
takes place.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_HOOK_LEASE4_RENEW_SKIP">
<term>DHCPSRV_HOOK_LEASE4_RENEW_SKIP DHCPv4 lease was not renewed because a callout set the skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on lease4_renew
hook point set the skip flag. For this particular hook point, the setting
of the flag by a callout instructs the server to not renew a lease. The
server will use existing lease as it is, without extending its lifetime.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_HOOK_LEASE4_SELECT_SKIP">
<term>DHCPSRV_HOOK_LEASE4_SELECT_SKIP Lease4 creation was skipped, because of callout skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on lease4_select
hook point sets the skip flag. It means that the server was told that
no lease4 should be assigned. The server will not put that lease in its
database and the client will get a NAK packet.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_HOOK_LEASE6_EXTEND_SKIP">
<term>DHCPSRV_HOOK_LEASE6_EXTEND_SKIP DHCPv6 lease lifetime was not extended because a callout set the skip flag for message %1</term>
<listitem><para>
This debug message is printed when a callout installed on lease6_renew
or the lease6_rebind hook point set the skip flag. For this particular hook
point, the setting of the flag by a callout instructs the server to not
extend the lifetime for a lease. If the client requested renewal of multiple
leases (by sending multiple IA options), the server will skip the renewal
of the one in question and will proceed with other renewals as usual.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_HOOK_LEASE6_RECOVER_SKIP">
<term>DHCPSRV_HOOK_LEASE6_RECOVER_SKIP DHCPv6 lease %1 was not recovered from declined state because a callout set the skip status.</term>
<listitem><para>
This debug message is printed when a callout installed on lease6_recover
hook point set the next step status to SKIP. For this particular hook point, this
indicates that the server should not recover the lease from declined state.
The server will leave the lease as it is, in the declined state. The
server will attempt to recover it the next time decline recovery procedure
takes place.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_HOOK_LEASE6_SELECT_SKIP">
<term>DHCPSRV_HOOK_LEASE6_SELECT_SKIP Lease6 (non-temporary) creation was skipped, because of callout skip flag.</term>
<listitem><para>
This debug message is printed when a callout installed on lease6_select
hook point sets the skip flag. It means that the server was told that
no lease6 should be assigned. The server will not put that lease in its
database and the client will get a NoAddrsAvail for that IA_NA option.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_INVALID_ACCESS">
<term>DHCPSRV_INVALID_ACCESS invalid database access string: %1</term>
<listitem><para>
This is logged when an attempt has been made to parse a database access string
and the attempt ended in error.  The access string in question - which
should be of the form 'keyword=value keyword=value...' is included in
the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_ADD_ADDR4">
<term>DHCPSRV_MEMFILE_ADD_ADDR4 adding IPv4 lease with address %1</term>
<listitem><para>
A debug message issued when the server is about to add an IPv4 lease
with the specified address to the memory file backend database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_ADD_ADDR6">
<term>DHCPSRV_MEMFILE_ADD_ADDR6 adding IPv6 lease with address %1</term>
<listitem><para>
A debug message issued when the server is about to add an IPv6 lease
with the specified address to the memory file backend database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_COMMIT">
<term>DHCPSRV_MEMFILE_COMMIT committing to memory file database</term>
<listitem><para>
The code has issued a commit call.  For the memory file database, this is
a no-op.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_DB">
<term>DHCPSRV_MEMFILE_DB opening memory file lease database: %1</term>
<listitem><para>
This informational message is logged when a DHCP server (either V4 or
V6) is about to open a memory file lease database.  The parameters of
the connection including database name and username needed to access it
(but not the password if any) are logged.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_DELETE_ADDR">
<term>DHCPSRV_MEMFILE_DELETE_ADDR deleting lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to delete a lease
for the specified address from the memory file database for the specified
address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4">
<term>DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than %1 seconds ago</term>
<listitem><para>
A debug message issued when the server is removing reclaimed DHCPv4
leases which have expired longer than a specified period of time.
The argument is the amount of time Kea waits after a reclaimed
lease expires before considering its removal.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED6">
<term>DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED6 deleting reclaimed IPv6 leases that expired more than %1 seconds ago</term>
<listitem><para>
A debug message issued when the server is removing reclaimed DHCPv6
leases which have expired longer than a specified period of time.
The argument is the amount of time Kea waits after a reclaimed
lease expires before considering its removal.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED_START">
<term>DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED_START starting deletion of %1 expired-reclaimed leases</term>
<listitem><para>
A debug message issued wheb the server has found expired-reclaimed
leases to be removed. The number of leases to be removed is logged
in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_ADDR4">
<term>DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the memory file database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_ADDR6">
<term>DHCPSRV_MEMFILE_GET_ADDR6 obtaining IPv6 lease for address %1 and lease type %2</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv6
lease from the memory file database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_CLIENTID">
<term>DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set of
IPv4 leases from the memory file database for a client with the specified
client identification.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_CLIENTID_HWADDR_SUBID">
<term>DHCPSRV_MEMFILE_GET_CLIENTID_HWADDR_SUBID obtaining IPv4 lease for client ID %1, hardware address %2 and subnet ID %3</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the memory file database for a client with the specified
client ID, hardware address and subnet ID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_EXPIRED4">
<term>DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum %1 of expired IPv4 leases</term>
<listitem><para>
A debug message issued when the server is attempting to obtain expired
IPv4 leases to reclaim them. The maximum number of leases to be retrieved
is logged in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_EXPIRED6">
<term>DHCPSRV_MEMFILE_GET_EXPIRED6 obtaining maximum %1 of expired IPv6 leases</term>
<listitem><para>
A debug message issued when the server is attempting to obtain expired
IPv6 leases to reclaim them. The maximum number of leases to be retrieved
is logged in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_HWADDR">
<term>DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set of
IPv4 leases from the memory file database for a client with the specified
hardware address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_IAID_DUID">
<term>DHCPSRV_MEMFILE_GET_IAID_DUID obtaining IPv6 leases for IAID %1 and DUID %2 and lease type %3</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set of
IPv6 lease from the memory file database for a client with the specified
IAID (Identity Association ID) and DUID (DHCP Unique Identifier).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_IAID_SUBID_DUID">
<term>DHCPSRV_MEMFILE_GET_IAID_SUBID_DUID obtaining IPv6 leases for IAID %1, Subnet ID %2, DUID %3 and lease type %4</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv6
lease from the memory file database for a client with the specified IAID
(Identity Association ID), Subnet ID and DUID (DHCP Unique Identifier).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_SUBID_CLIENTID">
<term>DHCPSRV_MEMFILE_GET_SUBID_CLIENTID obtaining IPv4 lease for subnet ID %1 and client ID %2</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the memory file database for a client with the specified
subnet ID and client ID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_SUBID_HWADDR">
<term>DHCPSRV_MEMFILE_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID %1 and hardware address %2</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the memory file database for a client with the specified
subnet ID and hardware address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_GET_VERSION">
<term>DHCPSRV_MEMFILE_GET_VERSION obtaining schema version information</term>
<listitem><para>
A debug message issued when the server is about to obtain schema version
information from the memory file database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LEASE_FILE_LOAD">
<term>DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file %1</term>
<listitem><para>
An info message issued when the server is about to start reading DHCP leases
from the lease file. All leases currently held in the memory will be
replaced by those read from the file.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LEASE_LOAD">
<term>DHCPSRV_MEMFILE_LEASE_LOAD loading lease %1</term>
<listitem><para>
A debug message issued when DHCP lease is being loaded from the file to memory.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LFC_EXECUTE">
<term>DHCPSRV_MEMFILE_LFC_EXECUTE executing Lease File Cleanup using: %1</term>
<listitem><para>
An informational message issued when the Memfile lease database backend
starts a new process to perform Lease File Cleanup.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LFC_LEASE_FILE_RENAME_FAIL">
<term>DHCPSRV_MEMFILE_LFC_LEASE_FILE_RENAME_FAIL failed to rename the current lease file %1 to %2, reason: %3</term>
<listitem><para>
An error message logged when the Memfile lease database backend fails to
move the current lease file to a new file on which the cleanup should
be performed. This effectively means that the lease file cleanup
will not take place.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LFC_LEASE_FILE_REOPEN_FAIL">
<term>DHCPSRV_MEMFILE_LFC_LEASE_FILE_REOPEN_FAIL failed to reopen lease file %1 after preparing input file for lease file cleanup, reason: %2, new leases will not be persisted!</term>
<listitem><para>
An error message logged when the Memfile lease database backend
failed to re-open or re-create the lease file after renaming the
lease file for lease file cleanup. The server will continue to
operate but leases will not be persisted to disk.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LFC_SETUP">
<term>DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to %1 sec</term>
<listitem><para>
An informational message logged when the Memfile lease database backend
configures the LFC to be executed periodically. The argument holds the
interval in seconds in which the LFC will be executed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LFC_SPAWN_FAIL">
<term>DHCPSRV_MEMFILE_LFC_SPAWN_FAIL lease file cleanup failed to run because kea-lfc process couldn't be spawned</term>
<listitem><para>
This error message is logged when the the Kea server fails to run kea-lfc,
the program that cleans up the lease file. The server will try again the
next time a lease file cleanup is scheduled. Although this message should
not appear and the reason why it did investigated, the occasional failure
to start the lease file cleanup will not impact operations. Should the
failure persist however, the size of the lease file will increase without bound.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LFC_START">
<term>DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup</term>
<listitem><para>
An informational message issued when the Memfile lease database backend
starts the periodic Lease File Cleanup.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_LFC_UNREGISTER_TIMER_FAILED">
<term>DHCPSRV_MEMFILE_LFC_UNREGISTER_TIMER_FAILED failed to unregister timer 'memfile-lfc': %1</term>
<listitem><para>
This error message is logged when Memfile backend fails to unregister
timer used for lease file cleanup scheduling. This is highly unlikely
and indicates programming error. The message include the reason for this
error.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_NEEDS_DOWNGRADING">
<term>DHCPSRV_MEMFILE_NEEDS_DOWNGRADING version of lease file: %1 schema is later than version %2</term>
<listitem><para>
A warning message issued when the schema of the lease file loaded by the server
is newer than the memfile schema of the server.  The server converts the lease
data from newer schemas to its schema as it is read, therefore the lease
information in use by the server will be correct. Note though, that any data
data stored in newer schema fields will be dropped.  What remains is for the
file itself to be rewritten using the current schema.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_NEEDS_UPGRADING">
<term>DHCPSRV_MEMFILE_NEEDS_UPGRADING version of lease file: %1 schema is earlier than version %2</term>
<listitem><para>
A warning message issued when the schema of the lease file loaded by the server
pre-dates the memfile schema of the server.  Note that the server converts the
lease data from older schemas to the current schema as it is read, therefore
the lease information in use by the server will be correct.  What remains is
for the file itself to be rewritten using the current schema.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_NO_STORAGE">
<term>DHCPSRV_MEMFILE_NO_STORAGE running in non-persistent mode, leases will be lost after restart</term>
<listitem><para>
A warning message issued when writes of leases to disk have been disabled
in the configuration. This mode is useful for some kinds of performance
testing but should not be enabled in normal circumstances. Non-persistence
mode is enabled when 'persist4=no persist6=no' parameters are specified
in the database access string.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_READ_HWADDR_FAIL">
<term>DHCPSRV_MEMFILE_READ_HWADDR_FAIL failed to read hardware address from lease file: %1</term>
<listitem><para>
A warning message issued when read attempt of the hardware address stored in
a disk file failed. The parameter should provide the exact nature of the failure.
The database read will continue, but that particular lease will no longer
have hardware address associated with it.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_ROLLBACK">
<term>DHCPSRV_MEMFILE_ROLLBACK rolling back memory file database</term>
<listitem><para>
The code has issued a rollback call.  For the memory file database, this is
a no-op.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_UPDATE_ADDR4">
<term>DHCPSRV_MEMFILE_UPDATE_ADDR4 updating IPv4 lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to update IPv4
lease from the memory file database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MEMFILE_UPDATE_ADDR6">
<term>DHCPSRV_MEMFILE_UPDATE_ADDR6 updating IPv6 lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to update IPv6
lease from the memory file database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MULTIPLE_RAW_SOCKETS_PER_IFACE">
<term>DHCPSRV_MULTIPLE_RAW_SOCKETS_PER_IFACE current configuration will result in opening multiple brodcast capable sockets on some interfaces and some DHCP messages may be duplicated</term>
<listitem><para>
A warning message issued when the current configuration indicates that multiple
sockets, capable of receiving brodcast traffic, will be opened on some of the
interfaces. It must be noted that this may lead to receiving and processing
the same DHCP message multiple times, as it will be received by each socket
individually.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_ADD_ADDR4">
<term>DHCPSRV_MYSQL_ADD_ADDR4 adding IPv4 lease with address %1</term>
<listitem><para>
A debug message issued when the server is about to add an IPv4 lease
with the specified address to the MySQL backend database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_ADD_ADDR6">
<term>DHCPSRV_MYSQL_ADD_ADDR6 adding IPv6 lease with address %1, lease type %2</term>
<listitem><para>
A debug message issued when the server is about to add an IPv6 lease
with the specified address to the MySQL backend database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_COMMIT">
<term>DHCPSRV_MYSQL_COMMIT committing to MySQL database</term>
<listitem><para>
The code has issued a commit call.  All outstanding transactions will be
committed to the database.  Note that depending on the MySQL settings,
the committal may not include a write to disk.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_DB">
<term>DHCPSRV_MYSQL_DB opening MySQL lease database: %1</term>
<listitem><para>
This informational message is logged when a DHCP server (either V4 or
V6) is about to open a MySQL lease database.  The parameters of the
connection including database name and username needed to access it
(but not the password if any) are logged.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_DELETED_EXPIRED_RECLAIMED">
<term>DHCPSRV_MYSQL_DELETED_EXPIRED_RECLAIMED deleted %1 reclaimed leases from the database</term>
<listitem><para>
A debug message issued when the server has removed a number of reclaimed
leases from the database. The number of removed leases is included in the
message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_DELETE_ADDR">
<term>DHCPSRV_MYSQL_DELETE_ADDR deleting lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to delete a lease for
the specified address from the MySQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED4">
<term>DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than %1 seconds ago</term>
<listitem><para>
A debug message issued when the server is removing reclaimed DHCPv4
leases which have expired longer than a specified period of time.
The argument is the amount of time Kea waits after a reclaimed
lease expires before considering its removal.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED6">
<term>DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED6 deleting reclaimed IPv6 leases that expired more than %1 seconds ago</term>
<listitem><para>
A debug message issued when the server is removing reclaimed DHCPv6
leases which have expired longer than a specified period of time.
The argument is the amount of time Kea waits after a reclaimed
lease expires before considering its removal.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_FATAL_ERROR">
<term>DHCPSRV_MYSQL_FATAL_ERROR Unrecoverable MySQL error occurred: %1 for &lt;%2&gt;, reason: %3 (error code: %4). Server exiting now!</term>
<listitem><para>
An error message indicating that communication with the MySQL database server
has been lost.  When this occurs the server exits immediately with a non-zero
exit code.  This is most likely due to a network issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_ADDR4">
<term>DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the MySQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_ADDR6">
<term>DHCPSRV_MYSQL_GET_ADDR6 obtaining IPv6 lease for address %1, lease type %2</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv6
lease from the MySQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_CLIENTID">
<term>DHCPSRV_MYSQL_GET_CLIENTID obtaining IPv4 leases for client ID %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set
of IPv4 leases from the MySQL database for a client with the specified
client identification.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_EXPIRED4">
<term>DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum %1 of expired IPv4 leases</term>
<listitem><para>
A debug message issued when the server is attempting to obtain expired
IPv4 leases to reclaim them. The maximum number of leases to be retrieved
is logged in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_EXPIRED6">
<term>DHCPSRV_MYSQL_GET_EXPIRED6 obtaining maximum %1 of expired IPv6 leases</term>
<listitem><para>
A debug message issued when the server is attempting to obtain expired
IPv6 leases to reclaim them. The maximum number of leases to be retrieved
is logged in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_HWADDR">
<term>DHCPSRV_MYSQL_GET_HWADDR obtaining IPv4 leases for hardware address %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set
of IPv4 leases from the MySQL database for a client with the specified
hardware address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_IAID_DUID">
<term>DHCPSRV_MYSQL_GET_IAID_DUID obtaining IPv6 leases for IAID %1, DUID %2, lease type %3</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set of
IPv6 lease from the MySQL database for a client with the specified IAID
(Identity Association ID) and DUID (DHCP Unique Identifier).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_IAID_SUBID_DUID">
<term>DHCPSRV_MYSQL_GET_IAID_SUBID_DUID obtaining IPv6 leases for IAID %1, Subnet ID %2, DUID %3, lease type %4</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv6
lease from the MySQL database for a client with the specified IAID
(Identity Association ID), Subnet ID and DUID (DHCP Unique Identifier).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_SUBID_CLIENTID">
<term>DHCPSRV_MYSQL_GET_SUBID_CLIENTID obtaining IPv4 lease for subnet ID %1 and client ID %2</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the MySQL database for a client with the specified subnet ID
and client ID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_SUBID_HWADDR">
<term>DHCPSRV_MYSQL_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID %1 and hardware address %2</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the MySQL database for a client with the specified subnet ID
and hardware address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_GET_VERSION">
<term>DHCPSRV_MYSQL_GET_VERSION obtaining schema version information</term>
<listitem><para>
A debug message issued when the server is about to obtain schema version
information from the MySQL database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_ROLLBACK">
<term>DHCPSRV_MYSQL_ROLLBACK rolling back MySQL database</term>
<listitem><para>
The code has issued a rollback call.  All outstanding transaction will
be rolled back and not committed to the database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_UPDATE_ADDR4">
<term>DHCPSRV_MYSQL_UPDATE_ADDR4 updating IPv4 lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to update IPv4
lease from the MySQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_MYSQL_UPDATE_ADDR6">
<term>DHCPSRV_MYSQL_UPDATE_ADDR6 updating IPv6 lease for address %1, lease type %2</term>
<listitem><para>
A debug message issued when the server is attempting to update IPv6
lease from the MySQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_NOTYPE_DB">
<term>DHCPSRV_NOTYPE_DB no 'type' keyword to determine database backend: %1</term>
<listitem><para>
This is an error message, logged when an attempt has been made to access
a database backend, but where no 'type' keyword has been included in
the access string.  The access string (less any passwords) is included
in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_NO_SOCKETS_OPEN">
<term>DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic</term>
<listitem><para>
This warning message is issued when the current server configuration specifies
no interfaces that the server should listen on, or when the specified interfaces are not
configured to receive the traffic.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_OPEN_SOCKET_FAIL">
<term>DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: %1</term>
<listitem><para>
A warning message issued when IfaceMgr fails to open and bind a socket.
The reason for the failure is appended as an argument of the log message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_ADD_ADDR4">
<term>DHCPSRV_PGSQL_ADD_ADDR4 adding IPv4 lease with address %1</term>
<listitem><para>
A debug message issued when the server is about to add an IPv4 lease
with the specified address to the PostgreSQL backend database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_ADD_ADDR6">
<term>DHCPSRV_PGSQL_ADD_ADDR6 adding IPv6 lease with address %1</term>
<listitem><para>
A debug message issued when the server is about to add an IPv6 lease
with the specified address to the PostgreSQL backend database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_COMMIT">
<term>DHCPSRV_PGSQL_COMMIT committing to MySQL database</term>
<listitem><para>
The code has issued a commit call.  All outstanding transactions will be
committed to the database.  Note that depending on the PostgreSQL settings,
the committal may not include a write to disk.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_DB">
<term>DHCPSRV_PGSQL_DB opening PostgreSQL lease database: %1</term>
<listitem><para>
This informational message is logged when a DHCP server (either V4 or
V6) is about to open a PostgreSQL lease database.  The parameters of the
connection including database name and username needed to access it
(but not the password if any) are logged.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_DEALLOC_ERROR">
<term>DHCPSRV_PGSQL_DEALLOC_ERROR An error occurred deallocating SQL statements while closing the PostgreSQL lease database: %1</term>
<listitem><para>
This is an error message issued when a DHCP server (either V4 or V6) experienced
and error freeing database SQL resources as part of closing its connection to
the Postgresql database.  The connection is closed as part of normal server
shutdown.  This error is most likely a programmatic issue that is highly
unlikely to occur or negatively impact server operation.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_DELETE_ADDR">
<term>DHCPSRV_PGSQL_DELETE_ADDR deleting lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to delete a lease for
the specified address from the PostgreSQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_DELETE_EXPIRED_RECLAIMED4">
<term>DHCPSRV_PGSQL_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than %1 seconds ago</term>
<listitem><para>
A debug message issued when the server is removing reclaimed DHCPv4
leases which have expired longer than a specified period of time.
The argument is the amount of time Kea waits after a reclaimed
lease expires before considering its removal.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_DELETE_EXPIRED_RECLAIMED6">
<term>DHCPSRV_PGSQL_DELETE_EXPIRED_RECLAIMED6 deleting reclaimed IPv6 leases that expired more than %1 seconds ago</term>
<listitem><para>
A debug message issued when the server is removing reclaimed DHCPv6
leases which have expired longer than a specified period of time.
The argument is the amount of time Kea waits after a reclaimed
lease expires before considering its removal.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_FATAL_ERROR">
<term>DHCPSRV_PGSQL_FATAL_ERROR Unrecoverable PostgreSQL error occurred: Statement: &lt;%1&gt;, reason: %2 (error code: %3). Server exiting now!</term>
<listitem><para>
An error message indicating that communication with the MySQL database server
has been lost.  When this occurs the server exits immediately with a non-zero
exit code.  This is most likely due to a network issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_ADDR4">
<term>DHCPSRV_PGSQL_GET_ADDR4 obtaining IPv4 lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the PostgreSQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_ADDR6">
<term>DHCPSRV_PGSQL_GET_ADDR6 obtaining IPv6 lease for address %1 (lease type %2)</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv6
lease from the PostgreSQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_CLIENTID">
<term>DHCPSRV_PGSQL_GET_CLIENTID obtaining IPv4 leases for client ID %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set
of IPv4 leases from the PostgreSQL database for a client with the specified
client identification.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_EXPIRED4">
<term>DHCPSRV_PGSQL_GET_EXPIRED4 obtaining maximum %1 of expired IPv4 leases</term>
<listitem><para>
A debug message issued when the server is attempting to obtain expired
IPv4 leases to reclaim them. The maximum number of leases to be retrieved
is logged in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_EXPIRED6">
<term>DHCPSRV_PGSQL_GET_EXPIRED6 obtaining maximum %1 of expired IPv6 leases</term>
<listitem><para>
A debug message issued when the server is attempting to obtain expired
IPv6 leases to reclaim them. The maximum number of leases to be retrieved
is logged in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_HWADDR">
<term>DHCPSRV_PGSQL_GET_HWADDR obtaining IPv4 leases for hardware address %1</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set
of IPv4 leases from the PostgreSQL database for a client with the specified
hardware address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_IAID_DUID">
<term>DHCPSRV_PGSQL_GET_IAID_DUID obtaining IPv4 leases for IAID %1 and DUID %2, lease type %3</term>
<listitem><para>
A debug message issued when the server is attempting to obtain a set of
IPv6 lease from the PostgreSQL database for a client with the specified IAID
(Identity Association ID) and DUID (DHCP Unique Identifier).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_IAID_SUBID_DUID">
<term>DHCPSRV_PGSQL_GET_IAID_SUBID_DUID obtaining IPv4 leases for IAID %1, Subnet ID %2, DUID %3, and lease type %4</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv6
lease from the PostgreSQL database for a client with the specified IAID
(Identity Association ID), Subnet ID and DUID (DHCP Unique Identifier).
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_SUBID_CLIENTID">
<term>DHCPSRV_PGSQL_GET_SUBID_CLIENTID obtaining IPv4 lease for subnet ID %1 and client ID %2</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the PostgreSQL database for a client with the specified subnet ID
and client ID.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_SUBID_HWADDR">
<term>DHCPSRV_PGSQL_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID %1 and hardware address %2</term>
<listitem><para>
A debug message issued when the server is attempting to obtain an IPv4
lease from the PostgreSQL database for a client with the specified subnet ID
and hardware address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_GET_VERSION">
<term>DHCPSRV_PGSQL_GET_VERSION obtaining schema version information</term>
<listitem><para>
A debug message issued when the server is about to obtain schema version
information from the PostgreSQL database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_ROLLBACK">
<term>DHCPSRV_PGSQL_ROLLBACK rolling back PostgreSQL database</term>
<listitem><para>
The code has issued a rollback call.  All outstanding transaction will
be rolled back and not committed to the database.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_UPDATE_ADDR4">
<term>DHCPSRV_PGSQL_UPDATE_ADDR4 updating IPv4 lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to update IPv4
lease from the PostgreSQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_PGSQL_UPDATE_ADDR6">
<term>DHCPSRV_PGSQL_UPDATE_ADDR6 updating IPv6 lease for address %1</term>
<listitem><para>
A debug message issued when the server is attempting to update IPv6
lease from the PostgreSQL database for the specified address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_QUEUE_NCR">
<term>DHCPSRV_QUEUE_NCR %1: name change request to %2 DNS entry queued: %3</term>
<listitem><para>
A debug message which is logged when the NameChangeRequest to add or remove
a DNS entries for a particular lease has been queued. The first argument
includes the client identification information. The second argument
indicates whether the DNS entry is to be added or removed. The third
argument carries the details of the NameChangeRequest.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_QUEUE_NCR_FAILED">
<term>DHCPSRV_QUEUE_NCR_FAILED %1: queueing %2 name change request failed for lease %3: %4</term>
<listitem><para>
This error message is logged when sending a name change request
to DHCP DDNS failed. The first argument includes the client identification
information. The second argument indicates whether the DNS entry is to be
added or removed. The third argument specifies the leased address. The
last argument provides the reason for failure.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_QUEUE_NCR_SKIP">
<term>DHCPSRV_QUEUE_NCR_SKIP %1: skip queueing name change request for lease: %2</term>
<listitem><para>
This debug message is issued when the server decides to not queue the name
change request because the lease doesn't include the FQDN, the forward and
reverse update is disabled for this lease or the DNS updates are disabled
in the configuration. The first argument includes the client identification
information. The second argument includes the leased address.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_CALLBACK_FAILED">
<term>DHCPSRV_TIMERMGR_CALLBACK_FAILED running handler for timer %1 caused exception: %2</term>
<listitem><para>
This error message is emitted when the timer elapsed and the
operation associated with this timer has thrown an exception.
The timer name and the reason for exception is logged.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_REGISTER_TIMER">
<term>DHCPSRV_TIMERMGR_REGISTER_TIMER registering timer: %1, using interval: %2 ms</term>
<listitem><para>
A debug message issued when the new interval timer is registered in
the Timer Manager. This timer will have a callback function
associated with it, and this function will be executed according
to the interval specified. The unique name of the timer and the
interval at which the callback function will be executed is
included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION">
<term>DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: %1</term>
<listitem><para>
A debug message issued when the Timer Manager is about to
run a periodic operation associated with the given timer.
An example of such operation is a periodic cleanup of
expired leases. The name of the timer is included in the
message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_SOCKET_CLEAR_FAILED">
<term>DHCPSRV_TIMERMGR_SOCKET_CLEAR_FAILED clearing watch socket for timer %1 failed: %2</term>
<listitem><para>
An error message indicating that the specified timer elapsed,
the operation associated with the timer was executed but the
server was unable to signal this to the worker thread responsible
for dispatching timers. The thread will continue but it will
not be able to dispatch any operations for this timer. The
server reconfiguration or restart may solve the problem
but the situation may repeat.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_SOCKET_MARK_FAILED">
<term>DHCPSRV_TIMERMGR_SOCKET_MARK_FAILED marking watch socket for timer %1 failed: %2</term>
<listitem><para>
An error message indicating that the specified timer elapsed,
but the server was unable to flag that the handler function
should be executed for this timer. The callback will not
be executed this time and most likely the subsequent attempts
will not be successful too. This error is highly unlikely.
The name of the timer and thre reason for failure is included
in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_START_THREAD">
<term>DHCPSRV_TIMERMGR_START_THREAD starting thread for timers</term>
<listitem><para>
A debug message issued when the Timer Manager is starting a
worker thread to run started timers. The worker thread is
typically started right after all timers have been registered
and runs until timers need to be reconfigured, e.g. their
interval is changed, new timers are registered or existing
timers are unregistered.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_START_TIMER">
<term>DHCPSRV_TIMERMGR_START_TIMER starting timer: %1</term>
<listitem><para>
A debug message issued when the registered interval timer is
being started. If this operation is successful the timer will
periodically execute the operation associated with it. The
name of the started timer is included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_STOP_THREAD">
<term>DHCPSRV_TIMERMGR_STOP_THREAD stopping thread for timers</term>
<listitem><para>
A debug message issued when the Timer Manager is stopping
the worker thread which executes interval timers. When the
thread is stopped no timers will be executed. The thread is
typically stopped at the server reconfiguration or when the
server shuts down.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_STOP_TIMER">
<term>DHCPSRV_TIMERMGR_STOP_TIMER stopping timer: %1</term>
<listitem><para>
A debug message issued when the registered interval timer is
being stopped. The timer remains registered and can be restarted
if necessary. The name of the timer is included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_UNREGISTER_ALL_TIMERS">
<term>DHCPSRV_TIMERMGR_UNREGISTER_ALL_TIMERS unregistering all timers</term>
<listitem><para>
A debug message issued when all registered interval timers are
being unregistered from the Timer Manager.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_TIMERMGR_UNREGISTER_TIMER">
<term>DHCPSRV_TIMERMGR_UNREGISTER_TIMER unregistering timer: %1</term>
<listitem><para>
A debug message issued when one of the registered interval timers
is unregistered from the Timer Manager. The name of the timer is
included in the message.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_UNEXPECTED_NAME">
<term>DHCPSRV_UNEXPECTED_NAME database access parameters passed through '%1', expected 'lease-database'</term>
<listitem><para>
The parameters for access the lease database were passed to the server through
the named configuration parameter, but the code was expecting them to be
passed via the parameter named "lease-database".  If the database opens
successfully, there is no impact on server operation.  However, as this does
indicate an error in the source code, please submit a bug report.
</para></listitem>
</varlistentry>

<varlistentry id="DHCPSRV_UNKNOWN_DB">
<term>DHCPSRV_UNKNOWN_DB unknown database type: %1</term>
<listitem><para>
The database access string specified a database type (given in the
message) that is unknown to the software.  This is a configuration error.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="DHCP">
    <title>DHCP Module</title>
    <para>
      <variablelist>
<varlistentry id="DHCP_DDNS_ADD_FAILED">
<term>DHCP_DDNS_ADD_FAILED DHCP_DDNS Request ID %1: Transaction outcome %2</term>
<listitem><para>
This is an error message issued after DHCP_DDNS attempts to submit DNS mapping
entry additions have failed.  The precise reason for the failure should be
documented in preceding log entries.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_ADD_SUCCEEDED">
<term>DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID %1: successfully added the DNS mapping addition for this request: %2</term>
<listitem><para>
This is an informational message issued after DHCP_DDNS has submitted DNS
mapping additions which were received and accepted by an appropriate DNS server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_ALREADY_RUNNING">
<term>DHCP_DDNS_ALREADY_RUNNING %1 already running? %2</term>
<listitem><para>
This is an error message that occurs when DHCP_DDNS encounters a pre-existing
PID file which contains the PID of a running process.  This most likely
indicates an attempt to start a second instance of DHCP_DDNS using the
same configuration file.  It is possible, though unlikely, that the PID file
is a remnant left behind by a server crash or power failure and the PID
it contains refers to a process other than DHCP_DDNS.  In such an event,
it would be necessary to manually remove the PID file.  The first argument is
the DHCP_DDNS process name, the second contains the PID and PID file.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_AT_MAX_TRANSACTIONS">
<term>DHCP_DDNS_AT_MAX_TRANSACTIONS application has %1 queued requests but has reached maximum number of %2 concurrent transactions</term>
<listitem><para>
This is a debug message that indicates that the application has DHCP_DDNS
requests in the queue but is working as many concurrent requests as allowed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_CFG_FILE_RELOAD_ERROR">
<term>DHCP_DDNS_CFG_FILE_RELOAD_ERROR configuration reload failed: %1, reverting to current configuration.</term>
<listitem><para>
This is an error message indicating that the application attempted to reload
its configuration from file and encountered an error.  This is likely due to
invalid content in the configuration file.  The application should continue
to operate under its current configuration.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_CFG_FILE_RELOAD_SIGNAL_RECVD">
<term>DHCP_DDNS_CFG_FILE_RELOAD_SIGNAL_RECVD OS signal %1 received, reloading configuration from file: %2</term>
<listitem><para>
This is an informational message indicating the application has received a signal
instructing it to reload its configuration from file.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_CLEARED_FOR_SHUTDOWN">
<term>DHCP_DDNS_CLEARED_FOR_SHUTDOWN application has met shutdown criteria for shutdown type: %1</term>
<listitem><para>
This is a debug message issued when the application has been instructed
to shutdown and has met the required criteria to exit.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_COMMAND">
<term>DHCP_DDNS_COMMAND command directive received, command: %1 - args: %2</term>
<listitem><para>
This is a debug message issued when the DHCP-DDNS application command method
has been invoked.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_CONFIGURE">
<term>DHCP_DDNS_CONFIGURE configuration update received: %1</term>
<listitem><para>
This is a debug message issued when the DHCP-DDNS application configure method
has been invoked.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FAILED">
<term>DHCP_DDNS_FAILED application experienced a fatal error: %1</term>
<listitem><para>
This is a debug message issued when the DHCP-DDNS application encounters an
unrecoverable error from within the event loop.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_ADD_BAD_DNSCLIENT_STATUS">
<term>DHCP_DDNS_FORWARD_ADD_BAD_DNSCLIENT_STATUS DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while adding a forward address mapping for FQDN %3 to DNS server %4</term>
<listitem><para>
This is an error message issued when DNSClient returns an unrecognized status
while DHCP_DDNS was adding a forward address mapping.  The request will be
aborted.  This is most likely a programmatic issue and should be reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_ADD_BUILD_FAILURE">
<term>DHCP_DDNS_FORWARD_ADD_BUILD_FAILURE DNS Request ID %1:  udpate message to add a forward DNS entry could not be constructed for this request: %2, reason: %3</term>
<listitem><para>
This is an error message issued when an error occurs attempting to construct
the server bound packet requesting a forward address addition.  This is due
to invalid data contained in the NameChangeRequest. The request will be aborted.
This is most likely a configuration issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_ADD_IO_ERROR">
<term>DHCP_DDNS_FORWARD_ADD_IO_ERROR DHCP_DDNS Request ID %1: encountered an IO error sending a forward mapping add for FQDN %2 to DNS server %3</term>
<listitem><para>
This is an error message issued when a communication error occurs while
DHCP_DDNS is carrying out a forward address update.  The application will
retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_ADD_REJECTED">
<term>DHCP_DDNS_FORWARD_ADD_REJECTED DNS Request ID %1: Server, %2, rejected a DNS update request to add the address mapping for FQDN, %3, with an RCODE: %4</term>
<listitem><para>
This is an error message issued when an update was rejected by the DNS server
it was sent to for the reason given by the RCODE. The rcode values are defined
in RFC 2136.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_ADD_RESP_CORRUPT">
<term>DHCP_DDNS_FORWARD_ADD_RESP_CORRUPT DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while adding forward address mapping for FQDN, %3</term>
<listitem><para>
This is an error message issued when the response received by DHCP_DDNS, to a
update request to add a forward address mapping,  is mangled or malformed.
The application will retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_ADDRS_BAD_DNSCLIENT_STATUS">
<term>DHCP_DDNS_FORWARD_REMOVE_ADDRS_BAD_DNSCLIENT_STATUS DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while removing a forward address mapping for FQDN %3 to DNS server %4</term>
<listitem><para>
This is an error message issued when DNSClient returns an unrecognized status
while DHCP_DDNS was removing a forward address mapping.  The request will be
aborted.  This is most likely a programmatic issue and should be reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_ADDRS_BUILD_FAILURE">
<term>DHCP_DDNS_FORWARD_REMOVE_ADDRS_BUILD_FAILURE DNS Request ID %1: udpate message to remove a forward DNS Address entry could not be constructed for this request: %2, reason: %3</term>
<listitem><para>
This is an error message issued when an error occurs attempting to construct
the server bound packet requesting a forward address (A or AAAA) removal.  This
is due to invalid data contained in the NameChangeRequest. The request will be
aborted.  This is most likely a configuration issue.
/*sar*/
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_ADDRS_IO_ERROR">
<term>DHCP_DDNS_FORWARD_REMOVE_ADDRS_IO_ERROR DHCP_DDNS Request ID %1: encountered an IO error sending a forward mapping address removal for FQDN %2 to DNS server %3</term>
<listitem><para>
This is an error message issued when a communication error occurs while
DHCP_DDNS is carrying out a forward address remove.  The application will retry
against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_ADDRS_REJECTED">
<term>DHCP_DDNS_FORWARD_REMOVE_ADDRS_REJECTED DNS Request ID %1: Server, %2, rejected a DNS update request to remove the forward address mapping for FQDN, %3, with an RCODE: %4</term>
<listitem><para>
This is an error message issued when an update was rejected by the DNS server
it was sent to for the reason given by the RCODE. The rcode values are defined
in RFC 2136.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_ADDRS_RESP_CORRUPT">
<term>DHCP_DDNS_FORWARD_REMOVE_ADDRS_RESP_CORRUPT DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while removing forward address mapping for FQDN, %3</term>
<listitem><para>
This is an error message issued when the response received by DHCP_DDNS, to a
update request to remove a forward address mapping, is mangled or malformed.
The application will retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_RRS_BAD_DNSCLIENT_STATUS">
<term>DHCP_DDNS_FORWARD_REMOVE_RRS_BAD_DNSCLIENT_STATUS DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while removing forward RRs for FQDN %3 to DNS server %4</term>
<listitem><para>
This is an error message issued when DNSClient returns an unrecognized status
while DHCP_DDNS was removing forward RRs.  The request will be aborted. This is
most likely a programmatic issue and should be reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_RRS_BUILD_FAILURE">
<term>DHCP_DDNS_FORWARD_REMOVE_RRS_BUILD_FAILURE DNS Request ID %1: udpate message to remove forward DNS RR entries could not be constructed for this request: %2,  reason: %3</term>
<listitem><para>
This is an error message issued when an error occurs attempting to construct
the server bound packet requesting forward RR (DHCID RR) removal.  This is due
to invalid data contained in the NameChangeRequest. The request will be aborted.This is most likely a configuration issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_RRS_IO_ERROR">
<term>DHCP_DDNS_FORWARD_REMOVE_RRS_IO_ERROR DHCP_DDNS Request ID %1: encountered an IO error sending a forward RR removal for FQDN %2 to DNS server %3</term>
<listitem><para>
This is an error message issued when a communication error occurs while
DHCP_DDNS is carrying out a forward RR remove.  The application will retry
against the same server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_RRS_REJECTED">
<term>DHCP_DDNS_FORWARD_REMOVE_RRS_REJECTED DNS Request ID %1: Server, %2, rejected a DNS update request to remove forward RR entries for FQDN, %3, with an RCODE: %4</term>
<listitem><para>
This is an error message issued when an update was rejected by the DNS server
it was sent to for the reason given by the RCODE. The rcode values are defined
in RFC 2136.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REMOVE_RRS_RESP_CORRUPT">
<term>DHCP_DDNS_FORWARD_REMOVE_RRS_RESP_CORRUPT DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while removing forward RRs for FQDN, %3</term>
<listitem><para>
This is an error message issued when the response received by DHCP_DDNS, to a
update request to remove forward RRs mapping, is mangled or malformed.
The application will retry against the same server or others as appropriate.
/*sar*/
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REPLACE_BAD_DNSCLIENT_STATUS">
<term>DHCP_DDNS_FORWARD_REPLACE_BAD_DNSCLIENT_STATUS DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while replacing forward address mapping for FQDN %3 to DNS server %4</term>
<listitem><para>
This is an error message issued when DNSClient returns an unrecognized status
while DHCP_DDNS was replacing a forward address mapping.  The request will be
aborted.  This is most likely a programmatic issue and should be reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REPLACE_BUILD_FAILURE">
<term>DHCP_DDNS_FORWARD_REPLACE_BUILD_FAILURE DNS Request ID %1: update message to replace a forward DNS entry could not be constructed from this request: %2, reason: %3</term>
<listitem><para>
This is an error message issued when an error occurs attempting to construct
the server bound packet requesting a forward address replacement.  This is
due to invalid data contained in the NameChangeRequest. The request will be
aborted.  This is most likely a configuration issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REPLACE_IO_ERROR">
<term>DHCP_DDNS_FORWARD_REPLACE_IO_ERROR DHCP_DDNS Request ID %1: encountered an IO error sending a forward mapping replace for FQDN %2 to DNS server %3</term>
<listitem><para>
This is an error message issued when a communication error occurs while
DHCP_DDNS is carrying out a forward address update.  The application will
retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REPLACE_REJECTED">
<term>DHCP_DDNS_FORWARD_REPLACE_REJECTED DNS Request ID %1: Server, %2, rejected a DNS update request to replace the address mapping for FQDN, %3, with an RCODE: %4</term>
<listitem><para>
This is an error message issued when an update was rejected by the DNS server
it was sent to for the reason given by the RCODE. The rcode values are defined
in RFC 2136.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FORWARD_REPLACE_RESP_CORRUPT">
<term>DHCP_DDNS_FORWARD_REPLACE_RESP_CORRUPT DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while replacing forward address mapping for FQDN, %3</term>
<listitem><para>
This is an error message issued when the response received by DHCP_DDNS, to a
update request to replace a forward address mapping,  is mangled or malformed.
The application will retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_FWD_REQUEST_IGNORED">
<term>DHCP_DDNS_FWD_REQUEST_IGNORED Request ID %1: Forward updates are disabled, the forward portion of request will be ignored: %2</term>
<listitem><para>
This is a debug message issued when forward DNS updates are disabled and
DHCP_DDNS receives an update request containing a forward DNS update. The
forward update will not performed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_INVALID_NCR">
<term>DHCP_DDNS_INVALID_NCR application received an invalid DNS update request: %1</term>
<listitem><para>
This is an error message that indicates that an invalid request to update
a DNS entry was received by the application.  Either the format or the content
of the request is incorrect. The request will be ignored.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_INVALID_RESPONSE">
<term>DHCP_DDNS_INVALID_RESPONSE received response to DNS Update message is malformed: %1</term>
<listitem><para>
This is a debug message issued when the DHCP-DDNS application encountered an
error while decoding a response to DNS Update message. Typically, this error
will be encountered when a response message is malformed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_FLUSH_IO_ERROR">
<term>DHCP_DDNS_NCR_FLUSH_IO_ERROR DHCP-DDNS Last send before stopping did not complete successfully: %1</term>
<listitem><para>
This is an error message that indicates the DHCP-DDNS client was unable to
complete the last send prior to exiting send mode.  This is a programmatic
error, highly unlikely to occur, and should not impair the application's ability
to process requests.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_LISTEN_CLOSE_ERROR">
<term>DHCP_DDNS_NCR_LISTEN_CLOSE_ERROR application encountered an error while closing the listener used to receive NameChangeRequests : %1</term>
<listitem><para>
This is an error message that indicates the application was unable to close the
listener connection used to receive NameChangeRequests.  Closure may occur
during the course of error recovery or during normal shutdown procedure.  In
either case the error is unlikely to impair the application's ability to
process requests but it should be reported for analysis.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_RECV_NEXT_ERROR">
<term>DHCP_DDNS_NCR_RECV_NEXT_ERROR application could not initiate the next read following a request receive.</term>
<listitem><para>
This is a error message indicating that NameChangeRequest listener could not
start another read after receiving a request.  While possible, this is highly
unlikely and is probably a programmatic error.  The application should recover
on its own.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_SEND_CLOSE_ERROR">
<term>DHCP_DDNS_NCR_SEND_CLOSE_ERROR DHCP-DDNS client encountered an error while closing the sender connection used to send NameChangeRequests: %1</term>
<listitem><para>
This is an error message that indicates the DHCP-DDNS client was unable to
close the connection used to send NameChangeRequests.  Closure may occur during
the course of error recovery or during normal shutdown procedure.  In either
case the error is unlikely to impair the client's ability to send requests but
it should be reported for analysis.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_SEND_NEXT_ERROR">
<term>DHCP_DDNS_NCR_SEND_NEXT_ERROR DHCP-DDNS client could not initiate the next request send following send completion: %1</term>
<listitem><para>
This is a error message indicating that NameChangeRequest sender could not
start another send after completing the send of the previous request.  While
possible, this is highly unlikely and is probably a programmatic error.  The
application should recover on its own.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_UDP_CLEAR_READY_ERROR">
<term>DHCP_DDNS_NCR_UDP_CLEAR_READY_ERROR NCR UDP watch socket failed to clear: %1</term>
<listitem><para>
This is an error message that indicates the application was unable to reset the
UDP NCR sender ready status after completing a send.  This is programmatic error
that should be reported.  The application may or may not continue to operate
correctly.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_UDP_RECV_CANCELED">
<term>DHCP_DDNS_NCR_UDP_RECV_CANCELED UDP socket receive was canceled while listening for DNS Update requests</term>
<listitem><para>
This is a debug  message indicating that the listening on a UDP socket
for DNS update requests has been canceled.  This is a normal part of
suspending listening operations.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_UDP_RECV_ERROR">
<term>DHCP_DDNS_NCR_UDP_RECV_ERROR UDP socket receive error while listening for DNS Update requests: %1</term>
<listitem><para>
This is an error message indicating that an I/O error occurred while listening
over a UDP socket for DNS update requests. This could indicate a network
connectivity or system resource issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_UDP_SEND_CANCELED">
<term>DHCP_DDNS_NCR_UDP_SEND_CANCELED UDP socket send was canceled while sending a DNS Update request to DHCP_DDNS: %1</term>
<listitem><para>
This is an informational message indicating that sending requests via UDP
socket to DHCP_DDNS has been interrupted. This is a normal part of suspending
send operations.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NCR_UDP_SEND_ERROR">
<term>DHCP_DDNS_NCR_UDP_SEND_ERROR UDP socket send error while sending a DNS Update request: %1</term>
<listitem><para>
This is an error message indicating that an IO error occurred while sending a
DNS update request to DHCP_DDNS over a UDP socket.  This could indicate a
network connectivity or system resource issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NOT_ON_LOOPBACK">
<term>DHCP_DDNS_NOT_ON_LOOPBACK the DHCP-DDNS server has been configured to listen on %1 which is not the local loopback.  This is an insecure configuration supported for testing purposes only</term>
<listitem><para>
This is a warning message issued when the DHCP-DDNS server is configured to
listen at an address other than the loopback address (127.0.0.1 or ::1). It is
possible for a malicious attacker to send bogus NameChangeRequests to it and
change entries in the DNS. For this reason, addresses other than the IPv4 or
IPv6 loopback addresses should only be used for testing purposes. A future
version of Kea will implement authentication to guard against such attacks.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NO_ELIGIBLE_JOBS">
<term>DHCP_DDNS_NO_ELIGIBLE_JOBS although there are queued requests, there are pending transactions for each, Queue count: %1  Transaction count: %2</term>
<listitem><para>
This is a debug message issued when all of the queued requests represent clients
for which there is a an update already in progress.  This may occur under
normal operations but should be temporary situation.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NO_FWD_MATCH_ERROR">
<term>DHCP_DDNS_NO_FWD_MATCH_ERROR Request ID %1: the configured list of forward DDNS domains does not contain a match for: %2  The request has been discarded.</term>
<listitem><para>
This is an error message that indicates that DHCP_DDNS received a request to
update a the forward DNS information for the given FQDN but for which there are
no configured DDNS domains in the DHCP_DDNS configuration.  Either the DHCP_DDNS
configuration needs to be updated or the source of the FQDN itself should be
investigated.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NO_MATCH">
<term>DHCP_DDNS_NO_MATCH No DNS servers match FQDN %1</term>
<listitem><para>
This is warning message issued when there are no domains in the configuration
which match the cited fully qualified domain name (FQDN).  The DNS Update
request for the FQDN cannot be processed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_NO_REV_MATCH_ERROR">
<term>DHCP_DDNS_NO_REV_MATCH_ERROR Request ID %1: the configured list of reverse DDNS domains does not contain a match for: %2  The request has been discarded.</term>
<listitem><para>
This is an error message that indicates that DHCP_DDNS received a request to
update a the reverse DNS information for the given FQDN but for which there are
no configured DDNS domains in the DHCP_DDNS configuration.  Either the DHCP_DDNS
configuration needs to be updated or the source of the FQDN itself should be
investigated.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_PID_FILE_ERROR">
<term>DHCP_DDNS_PID_FILE_ERROR %1 could not create a PID file: %2</term>
<listitem><para>
This is an error message that occurs when DHCP_DDNS is unable to create
its PID file.  The log message should contain details sufficient to
determine the underlying cause.  The most likely culprits are that
some portion of the pathname does not exist or a permissions issue. The
default path is determined by --localstatedir configure paramter but
may be overridden by setting environment variable, KEA_PIDFILE_DIR.  The
first argument is the DHCP_DDNS process name.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_PROCESS_INIT">
<term>DHCP_DDNS_PROCESS_INIT application init invoked</term>
<listitem><para>
This is a debug message issued when the DHCP-DDNS application enters
its initialization method.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_QUEUE_FULL">
<term>DHCP_DDNS_QUEUE_MGR_QUEUE_FULL application request queue has reached maximum number of entries %1</term>
<listitem><para>
This an error message indicating that DHCP-DDNS is receiving DNS update
requests faster than they can be processed.  This may mean the maximum queue
needs to be increased, the DHCP-DDNS clients are simply generating too many
requests too quickly, or perhaps upstream DNS servers are experiencing
load issues.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE">
<term>DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID %1: received and queued a request.</term>
<listitem><para>
This is an informational message indicating that the NameChangeREquest listener used
by DHCP-DDNS to receive a request has received a request and queued it for further
processing.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_RECONFIGURING">
<term>DHCP_DDNS_QUEUE_MGR_RECONFIGURING application is reconfiguring the queue manager</term>
<listitem><para>
This is an informational message indicating that DHCP_DDNS is reconfiguring the queue manager as part of normal startup or in response to a new configuration.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_RECOVERING">
<term>DHCP_DDNS_QUEUE_MGR_RECOVERING application is attempting to recover from a queue manager IO error</term>
<listitem><para>
This is an informational message indicating that DHCP_DDNS is attempting to
restart the queue manager after it suffered an IO error while receiving
requests.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_RECV_ERROR">
<term>DHCP_DDNS_QUEUE_MGR_RECV_ERROR application's queue manager was notified of a request receive error by its listener.</term>
<listitem><para>
This is an error message indicating that the NameChangeRequest listener used by
DHCP-DDNS to receive requests encountered an IO error.  There should be
corresponding log messages from the listener layer with more details. This may
indicate a network connectivity or system resource issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_RESUME_ERROR">
<term>DHCP_DDNS_QUEUE_MGR_RESUME_ERROR application could not restart the queue manager, reason: %1</term>
<listitem><para>
This is an error message indicating that DHCP_DDNS's Queue Manager could not
be restarted after stopping due to a full receive queue.  This means that
the application cannot receive requests. This is most likely due to DHCP_DDNS
configuration parameters referring to resources such as an IP address or port,
that is no longer unavailable.  DHCP_DDNS will attempt to restart the queue
manager if given a new configuration.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_RESUMING">
<term>DHCP_DDNS_QUEUE_MGR_RESUMING application is resuming listening for requests now that the request queue size has reached %1 of a maximum %2 allowed</term>
<listitem><para>
This is an informational message indicating that DHCP_DDNS, which had stopped
accepting new requests, has processed enough entries from the receive queue to
resume accepting requests.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_STARTED">
<term>DHCP_DDNS_QUEUE_MGR_STARTED application's queue manager has begun listening for requests.</term>
<listitem><para>
This is a debug message indicating that DHCP_DDNS's Queue Manager has
successfully started and is now listening for NameChangeRequests.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_START_ERROR">
<term>DHCP_DDNS_QUEUE_MGR_START_ERROR application could not start the queue manager, reason: %1</term>
<listitem><para>
This is an error message indicating that DHCP_DDNS's Queue Manager could not
be started.  This means that the application cannot receive requests. This is
most likely due to DHCP_DDNS configuration parameters referring to resources
such as an IP address or port, that are unavailable.  DHCP_DDNS will attempt to
restart the queue manager if given a new configuration.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_STOPPED">
<term>DHCP_DDNS_QUEUE_MGR_STOPPED application's queue manager has stopped listening for requests.</term>
<listitem><para>
This is a debug message indicating that DHCP_DDNS's Queue Manager has
stopped listening for NameChangeRequests.  This may be because of normal event
such as reconfiguration or as a result of an error.  There should be log
messages preceding this one to indicate why it has stopped.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_STOPPING">
<term>DHCP_DDNS_QUEUE_MGR_STOPPING application is stopping the queue manager for %1</term>
<listitem><para>
This is an informational message indicating that DHCP_DDNS is stopping the
queue manager either to reconfigure it or as part of application shutdown.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_STOP_ERROR">
<term>DHCP_DDNS_QUEUE_MGR_STOP_ERROR application encountered an error stopping the queue manager: %1</term>
<listitem><para>
This is an error message indicating that DHCP_DDNS encountered an error while
trying to stop the queue manager.  This error is unlikely to occur or to
impair the application's ability to function but it should be reported for
analysis.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_UNEXPECTED_HANDLER_ERROR">
<term>DHCP_DDNS_QUEUE_MGR_UNEXPECTED_HANDLER_ERROR application's queue manager request receive handler experienced an unexpected exception %1:</term>
<listitem><para>
This is an error message indicating that an unexpected error occurred within the
DHCP_DDNS's Queue Manager request receive completion handler. This is most
likely a programmatic issue that should be reported.  The application may
recover on its own.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_QUEUE_MGR_UNEXPECTED_STOP">
<term>DHCP_DDNS_QUEUE_MGR_UNEXPECTED_STOP application's queue manager receive was</term>
<listitem><para>
aborted unexpectedly while queue manager state is: %1
This is an error message indicating that DHCP_DDNS's Queue Manager request
receive was unexpected interrupted.  Normally, the read is receive is only
interrupted as a normal part of stopping the queue manager.  This is most
likely a programmatic issue that should be reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REMOVE_FAILED">
<term>DHCP_DDNS_REMOVE_FAILED DHCP_DDNS Request ID %1: Transaction outcome: %2</term>
<listitem><para>
This is an error message issued after DHCP_DDNS attempts to submit DNS mapping
entry removals have failed.  The precise reason for the failure should be
documented in preceding log entries.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REMOVE_SUCCEEDED">
<term>DHCP_DDNS_REMOVE_SUCCEEDED DHCP_DDNS Request ID %1: successfully removed the DNS mapping addition for this request: %2</term>
<listitem><para>
This is an informational message issued after DHCP_DDNS has submitted DNS
mapping removals which were received and accepted by an appropriate DNS server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REQUEST_DROPPED">
<term>DHCP_DDNS_REQUEST_DROPPED Request ID %1: Request contains no enabled update requests and will be dropped: %2</term>
<listitem><para>
This is a debug message issued when DHCP_DDNS receives a request which does not
contain updates in a direction that is enabled.  In other words, if only forward
updates are enabled and request is recevied that asks only for reverse updates
then the request is dropped.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REMOVE_BAD_DNSCLIENT_STATUS">
<term>DHCP_DDNS_REVERSE_REMOVE_BAD_DNSCLIENT_STATUS DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while removing reverse address mapping for FQDN %3 to DNS server %4</term>
<listitem><para>
This is an error message issued when DNSClient returns an unrecognized status
while DHCP_DDNS was removing a reverse address mapping.  The request will be
aborted.  This is most likely a programmatic issue and should be reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REMOVE_BUILD_FAILURE">
<term>DHCP_DDNS_REVERSE_REMOVE_BUILD_FAILURE DNS Request ID %1: update message to remove a reverse DNS entry could not be constructed from this request: %2,  reason: %3</term>
<listitem><para>
This is an error message issued when an error occurs attempting to construct
the server bound packet requesting a reverse PTR removal.  This is
due to invalid data contained in the NameChangeRequest. The request will be
aborted.  This is most likely a configuration issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REMOVE_IO_ERROR">
<term>DHCP_DDNS_REVERSE_REMOVE_IO_ERROR DHCP_DDNS Request ID %1: encountered an IO error sending a reverse mapping remove for FQDN %2 to DNS server %3</term>
<listitem><para>
This is an error message issued when a communication error occurs while
DHCP_DDNS is carrying out a reverse address update.  The application will
retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REMOVE_REJECTED">
<term>DHCP_DDNS_REVERSE_REMOVE_REJECTED DNS Request ID %1: Server, %2, rejected a DNS update request to remove the reverse mapping for FQDN, %3, with an RCODE: %4</term>
<listitem><para>
This is an error message issued when an update was rejected by the DNS server
it was sent to for the reason given by the RCODE. The rcode values are defined
in RFC 2136.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REMOVE_RESP_CORRUPT">
<term>DHCP_DDNS_REVERSE_REMOVE_RESP_CORRUPT DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while removing reverse address mapping for FQDN, %3</term>
<listitem><para>
This is an error message issued when the response received by DHCP_DDNS, to a
update request to remove a reverse address,  is mangled or malformed.
The application will retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REPLACE_BAD_DNSCLIENT_STATUS">
<term>DHCP_DDNS_REVERSE_REPLACE_BAD_DNSCLIENT_STATUS DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while replacing reverse address mapping for FQDN %3 to DNS server %4</term>
<listitem><para>
This is an error message issued when DNSClient returns an unrecognized status
while DHCP_DDNS was replacing a reverse address mapping.  The request will be
aborted.  This is most likely a programmatic issue and should be reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REPLACE_BUILD_FAILURE">
<term>DHCP_DDNS_REVERSE_REPLACE_BUILD_FAILURE DNS Request ID %1: update message to replace a reverse DNS entry could not be constructed from this request: %2, reason: %3</term>
<listitem><para>
This is an error message issued when an error occurs attempting to construct
the server bound packet requesting a reverse PTR replacement.  This is
due to invalid data contained in the NameChangeRequest. The request will be
aborted.  This is most likely a configuration issue.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REPLACE_IO_ERROR">
<term>DHCP_DDNS_REVERSE_REPLACE_IO_ERROR DHCP_DDNS Request ID %1: encountered an IO error sending a reverse mapping replacement for FQDN %2 to DNS server %3</term>
<listitem><para>
This is an error message issued when a communication error occurs while
DHCP_DDNS is carrying out a reverse address update.  The application will
retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REPLACE_REJECTED">
<term>DHCP_DDNS_REVERSE_REPLACE_REJECTED DNS Request ID %1: Server, %2, rejected a DNS update request to replace the reverse mapping for FQDN, %3, with an RCODE: %4</term>
<listitem><para>
This is an error message issued when an update was rejected by the DNS server
it was sent to for the reason given by the RCODE. The rcode values are defined
in RFC 2136.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REVERSE_REPLACE_RESP_CORRUPT">
<term>DHCP_DDNS_REVERSE_REPLACE_RESP_CORRUPT DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while replacing reverse address mapping for FQDN, %3</term>
<listitem><para>
This is an error message issued when the response received by DHCP_DDNS, to a
update request to replace a reverse address,  is mangled or malformed.
The application will retry against the same server or others as appropriate.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_REV_REQUEST_IGNORED">
<term>DHCP_DDNS_REV_REQUEST_IGNORED Request ID %1: Reverse updates are disabled, the reverse portion of request will be ignored: %2</term>
<listitem><para>
This is a debug message issued when reverse DNS updates are disabled and
DHCP_DDNS receives an update request containing a reverse DNS update.  The
reverse update will not performed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_RUN_EXIT">
<term>DHCP_DDNS_RUN_EXIT application is exiting the event loop</term>
<listitem><para>
This is a debug message issued when the DHCP-DDNS server exits its
event lo
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_SHUTDOWN">
<term>DHCP_DDNS_SHUTDOWN DHCP-DDNS has shut down</term>
<listitem><para>
This is an informational message indicating that the DHCP-DDNS service
has shut down.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_SHUTDOWN_COMMAND">
<term>DHCP_DDNS_SHUTDOWN_COMMAND application received shutdown command with args: %1</term>
<listitem><para>
This is a debug message issued when the application has been instructed
to shut down by the controller.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_SHUTDOWN_SIGNAL_RECVD">
<term>DHCP_DDNS_SHUTDOWN_SIGNAL_RECVD OS signal %1 received, starting shutdown</term>
<listitem><para>
This is a debug message indicating the application has received a signal
instructing it to shutdown.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_SIGNAL_ERROR">
<term>DHCP_DDNS_SIGNAL_ERROR signal handler for signal %1, threw an unexpected exception: %2</term>
<listitem><para>
This is an error message indicating that the application encountered an unexpected
error after receiving a signal.  This is a programmatic error and should be
reported.  While The application will likely continue to operating, it may be
unable to respond correctly to signals.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_STARTED">
<term>DHCP_DDNS_STARTED Kea DHCP-DDNS server version %1 started</term>
<listitem><para>
This informational message indicates that the DHCP-DDNS server has
processed all configuration information and is ready to beging processing.
The version is also printed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_STARTING">
<term>DHCP_DDNS_STARTING DHCP-DDNS starting, pid: %1, version: %2</term>
<listitem><para>
This is an informational message issued when controller for the
service first starts. Version is also reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_STARTING_TRANSACTION">
<term>DHCP_DDNS_STARTING_TRANSACTION Request ID %1:</term>
<listitem><para>
This is a debug message issued when DHCP-DDNS has begun a transaction for
a given request.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_STATE_MODEL_UNEXPECTED_ERROR">
<term>DHCP_DDNS_STATE_MODEL_UNEXPECTED_ERROR Request ID %1: application encountered an unexpected error while carrying out a NameChangeRequest: %2</term>
<listitem><para>
This is error message issued when the application fails to process a
NameChangeRequest correctly. Some or all of the DNS updates requested as part
of this update did not succeed. This is a programmatic error and should be
reported.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_TRANS_SEND_ERROR">
<term>DHCP_DDNS_TRANS_SEND_ERROR Request ID %1: application encountered an unexpected error while attempting to send a DNS update: %2</term>
<listitem><para>
This is error message issued when the application is able to construct an update
message but the attempt to send it suffered an unexpected error. This is most
likely a programmatic error, rather than a communications issue. Some or all
of the DNS updates requested as part of this request did not succeed.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_UDP_SENDER_WATCH_SOCKET_CLOSE_ERROR">
<term>DHCP_DDNS_UDP_SENDER_WATCH_SOCKET_CLOSE_ERROR watch socket failed to close: %1</term>
<listitem><para>
This is an error message that indicates the application was unable to close
the inbound or outbound side of a NCR sender's watch socket. While technically
possible the error is highly unlikely to occur and should not impair the
application's ability to process requests.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_UNCAUGHT_NCR_RECV_HANDLER_ERROR">
<term>DHCP_DDNS_UNCAUGHT_NCR_RECV_HANDLER_ERROR unexpected exception thrown from the application receive completion handler: %1</term>
<listitem><para>
This is an error message that indicates that an exception was thrown but not
caught in the application's request receive completion handler.  This is a
programmatic error that needs to be reported.  Dependent upon the nature of
the error the application may or may not continue operating normally.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_UNCAUGHT_NCR_SEND_HANDLER_ERROR">
<term>DHCP_DDNS_UNCAUGHT_NCR_SEND_HANDLER_ERROR unexpected exception thrown from the DHCP-DDNS client send completion handler: %1</term>
<listitem><para>
This is an error message that indicates that an exception was thrown but not
caught in the application's send completion handler.  This is a programmatic
error that needs to be reported.  Dependent upon the nature of the error the
client may or may not continue operating normally.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_UNSUPPORTED_SIGNAL">
<term>DHCP_DDNS_UNSUPPORTED_SIGNAL ignoring reception of unsupported signal: %1</term>
<listitem><para>
This is a debug message indicating that the application received an
unsupported signal.  This is a programming error indicating that the
application has registered to receive the signal but no associated
processing logic has been added.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_UPDATE_REQUEST_SENT">
<term>DHCP_DDNS_UPDATE_REQUEST_SENT Request ID %1: %2 to server: %3</term>
<listitem><para>
This is a debug message issued when DHCP_DDNS sends a DNS request to a DNS
server.
</para></listitem>
</varlistentry>

<varlistentry id="DHCP_DDNS_UPDATE_RESPONSE_RECEIVED">
<term>DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID %1: to server: %2 status: %3</term>
<listitem><para>
This is a debug message issued when DHCP_DDNS receives sends a DNS update
response from a DNS server.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="EVAL">
    <title>EVAL Module</title>
    <para>
      <variablelist>
<varlistentry id="EVAL_RESULT">
<term>EVAL_RESULT Expression %1 evaluated to %2</term>
<listitem><para>
This debug message indicates that the expression has been evaluated
to said value. This message is mostly useful during debugging of the
client classification expressions.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="HOOKS">
    <title>HOOKS Module</title>
    <para>
      <variablelist>
<varlistentry id="HOOKS_ALL_CALLOUTS_DEREGISTERED">
<term>HOOKS_ALL_CALLOUTS_DEREGISTERED hook library at index %1 removed all callouts on hook %2</term>
<listitem><para>
A debug message issued when all callouts on the specified hook registered
by the library with the given index were removed.  This is similar to
the HOOKS_CALLOUTS_REMOVED message (and the two are likely to be seen
together), but is issued at a lower-level in the hook framework.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CALLOUTS_BEGIN">
<term>HOOKS_CALLOUTS_BEGIN begin all callouts for hook %1</term>
<listitem><para>
This debug message is issued when callout manager begins to invoke callouts
for the hook. The argument specifies the hook name.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CALLOUTS_COMPLETE">
<term>HOOKS_CALLOUTS_COMPLETE completed callouts for hook %1 (total callouts duration: %2)</term>
<listitem><para>
This debug message is issued when callout manager has completed execution
of all callouts for the particular hook. The arguments specify the hook
name and total execution time for all callouts in milliseconds.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CALLOUTS_REMOVED">
<term>HOOKS_CALLOUTS_REMOVED callouts removed from hook %1 for library %2</term>
<listitem><para>
This is a debug message issued during library unloading.  It notes that
one of more callouts registered by that library have been removed from
the specified hook.  This is similar to the HOOKS_DEREGISTER_ALL_CALLOUTS
message (and the two are likely to be seen together), but is issued at a
higher-level in the hook framework.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CALLOUT_CALLED">
<term>HOOKS_CALLOUT_CALLED hooks library with index %1 has called a callout on hook %2 that has address %3 (callout duration: %4)</term>
<listitem><para>
Only output at a high debugging level, this message indicates that
a callout on the named hook registered by the library with the given
index (in the list of loaded libraries) has been called and returned a
success state.  The address of the callout is given in the message.
The message includes the callout execution time in milliseconds.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CALLOUT_DEREGISTERED">
<term>HOOKS_CALLOUT_DEREGISTERED hook library at index %1 deregistered a callout on hook %2</term>
<listitem><para>
A debug message issued when all instances of a particular callouts on
the hook identified in the message that were registered by the library
with the given index have been removed.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CALLOUT_ERROR">
<term>HOOKS_CALLOUT_ERROR error returned by callout on hook %1 registered by library with index %2 (callout address %3) (callout duration %4)</term>
<listitem><para>
If a callout returns an error status when called, this error message
is issued.  It identifies the hook to which the callout is attached, the
index of the library (in the list of loaded libraries) that registered
it and the address of the callout.  The error is otherwise ignored.
The error message includes the callout execution time in milliseconds.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CALLOUT_EXCEPTION">
<term>HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook %1 registered by library with index %2 (callout address %3): %4 (callout duration: $5)</term>
<listitem><para>
If a callout throws an exception when called, this error message is
issued.  It identifies the hook to which the callout is attached, the
index of the library (in the list of loaded libraries) that registered
it and the address of the callout.  The error is otherwise ignored.
The error message includes the callout execution time in milliseconds.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CALLOUT_REGISTRATION">
<term>HOOKS_CALLOUT_REGISTRATION hooks library with index %1 registering callout for hook '%2'</term>
<listitem><para>
This is a debug message, output when a library (whose index in the list
of libraries (being) loaded is given) registers a callout.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_CLOSE_ERROR">
<term>HOOKS_CLOSE_ERROR failed to close hook library %1: %2</term>
<listitem><para>
Kea has failed to close the named hook library for the stated reason.
Although this is an error, this should not affect the running system
other than as a loss of resources.  If this error persists, you should
restart Kea.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_HOOK_LIST_RESET">
<term>HOOKS_HOOK_LIST_RESET the list of hooks has been reset</term>
<listitem><para>
This is a message indicating that the list of hooks has been reset.
While this is usual when running the Kea test suite, it should not be
seen when running Kea in a production environment.  If this appears,
please report a bug through the usual channels.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_INCORRECT_VERSION">
<term>HOOKS_INCORRECT_VERSION hook library %1 is at version %2, require version %3</term>
<listitem><para>
Kea has detected that the named hook library has been built against
a version of Kea that is incompatible with the version of Kea
running on your system.  It has not loaded the library.
</para><para>
This is most likely due to the installation of a new version of Kea
without rebuilding the hook library.  A rebuild and re-install of the
library should fix the problem in most cases.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LIBRARY_LOADED">
<term>HOOKS_LIBRARY_LOADED hooks library %1 successfully loaded</term>
<listitem><para>
This information message is issued when a user-supplied hooks library
has been successfully loaded.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LIBRARY_LOADING">
<term>HOOKS_LIBRARY_LOADING loading hooks library %1</term>
<listitem><para>
This is a debug message output just before the specified library is loaded.
If the action is successfully, it will be followed by the
HOOKS_LIBRARY_LOADED informational message.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LIBRARY_UNLOADED">
<term>HOOKS_LIBRARY_UNLOADED hooks library %1 successfully unloaded</term>
<listitem><para>
This information message is issued when a user-supplied hooks library
has been successfully unloaded.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LIBRARY_UNLOADING">
<term>HOOKS_LIBRARY_UNLOADING unloading library %1</term>
<listitem><para>
This is a debug message called when the specified library is
being unloaded.  If all is successful, it will be followed by the
HOOKS_LIBRARY_UNLOADED informational message.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LIBRARY_VERSION">
<term>HOOKS_LIBRARY_VERSION hooks library %1 reports its version as %2</term>
<listitem><para>
A debug  message issued when the version check on the hooks library
has succeeded.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LOAD_ERROR">
<term>HOOKS_LOAD_ERROR 'load' function in hook library %1 returned error %2</term>
<listitem><para>
A "load" function was found in the library named in the message and
was called.  The function returned a non-zero status (also given in
the message) which was interpreted as an error.  The library has been
unloaded and no callouts from it will be installed.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LOAD_EXCEPTION">
<term>HOOKS_LOAD_EXCEPTION 'load' function in hook library %1 threw an exception</term>
<listitem><para>
A "load" function was found in the library named in the message and
was called.  The function threw an exception (an error indication)
during execution, which is an error condition.  The library has been
unloaded and no callouts from it will be installed.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LOAD_FRAMEWORK_EXCEPTION">
<term>HOOKS_LOAD_FRAMEWORK_EXCEPTION 'load' function in hook library %1 threw an exception: reason %2</term>
<listitem><para>
A "load" function was found in the library named in the message and
was called.  Either the hooks framework or the function threw an
exception (an error indication) during execution, which is an error
condition; the cause of the exception is recorded in the message.
The library has been unloaded and no callouts from it will be
installed.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_LOAD_SUCCESS">
<term>HOOKS_LOAD_SUCCESS 'load' function in hook library %1 returned success</term>
<listitem><para>
This is a debug message issued when the "load" function has been found
in a hook library and has been successfully called.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_NO_LOAD">
<term>HOOKS_NO_LOAD no 'load' function found in hook library %1</term>
<listitem><para>
This is a debug message saying that the specified library was loaded
but no function called "load" was found in it.  Providing the library
contained some "standard" functions (i.e. functions with the names of
the hooks for the given server), this is not an issue.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_NO_UNLOAD">
<term>HOOKS_NO_UNLOAD no 'unload' function found in hook library %1</term>
<listitem><para>
This is a debug message issued when the library is being unloaded.
It merely states that the library did not contain an "unload" function.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_NO_VERSION">
<term>HOOKS_NO_VERSION no 'version' function found in hook library %1</term>
<listitem><para>
The shared library named in the message was found and successfully loaded,
but Kea did not find a function named "version" in it.  This function
is required and should return the version of Kea against which the
library was built.  The value is used to check that the library was built
against a compatible version of Kea.  The library has not been loaded.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_OPEN_ERROR">
<term>HOOKS_OPEN_ERROR failed to open hook library %1: %2</term>
<listitem><para>
Kea failed to open the specified hook library for the stated
reason. The library has not been loaded.  Kea will continue to
function, but without the services offered by the library.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_STD_CALLOUT_REGISTERED">
<term>HOOKS_STD_CALLOUT_REGISTERED hooks library %1 registered standard callout for hook %2 at address %3</term>
<listitem><para>
This is a debug message, output when the library loading function has
located a standard callout (a callout with the same name as a hook point)
and registered it.  The address of the callout is indicated.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_UNLOAD_ERROR">
<term>HOOKS_UNLOAD_ERROR 'unload' function in hook library %1 returned error %2</term>
<listitem><para>
During the unloading of a library, an "unload" function was found.
It was called, but returned an error (non-zero) status, resulting in
the issuing of this message.  The unload process continued after this
message and the library has been unloaded.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_UNLOAD_EXCEPTION">
<term>HOOKS_UNLOAD_EXCEPTION 'unload' function in hook library %1 threw an exception</term>
<listitem><para>
During the unloading of a library, an "unload" function was found.  It was
called, but in the process generated an exception (an error indication).
The unload process continued after this message and the library has
been unloaded.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_UNLOAD_FRAMEWORK_EXCEPTION">
<term>HOOKS_UNLOAD_FRAMEWORK_EXCEPTION 'unload' function in hook library %1 threw an exception, reason %2</term>
<listitem><para>
During the unloading of a library, an "unload" function was found.
It was called, but in the process either it or the hooks framework
generated an exception (an error indication); the cause of the error
is recorded in the message.  The unload process continued after
this message and the library has been unloaded.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_UNLOAD_SUCCESS">
<term>HOOKS_UNLOAD_SUCCESS 'unload' function in hook library %1 returned success</term>
<listitem><para>
This is a debug message issued when an "unload" function has been found
in a hook library during the unload process, called, and returned success.
</para></listitem>
</varlistentry>

<varlistentry id="HOOKS_VERSION_EXCEPTION">
<term>HOOKS_VERSION_EXCEPTION 'version' function in hook library %1 threw an exception</term>
<listitem><para>
This error message is issued if the version() function in the specified
hooks library was called and generated an exception.  The library is
considered unusable and will not be loaded.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="HOSTS">
    <title>HOSTS Module</title>
    <para>
      <variablelist>
<varlistentry id="HOSTS_CFG_ADD_HOST">
<term>HOSTS_CFG_ADD_HOST add the host for reservations: %1</term>
<listitem><para>
This debug message is issued when new host (with reservations) is added to
the server's configuration. The argument describes the host and its
reservations in detail.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_CLOSE_HOST_DATA_SOURCE">
<term>HOSTS_CFG_CLOSE_HOST_DATA_SOURCE Closing host data source: %1</term>
<listitem><para>
This is a normal message being printed when the server closes host data
source connection.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_ADDRESS4">
<term>HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address %1</term>
<listitem><para>
This debug message is issued when starting to retrieve all hosts, holding the
reservation for the specific IPv4 address, from the configuration. The
argument specifies the IPv4 address used to search the hosts.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_ADDRESS4_COUNT">
<term>HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address %1, found %2 host(s)</term>
<listitem><para>
This debug message logs the number of hosts found using the specified
IPv4 address. The arguments specify the IPv4 address used and the number
of hosts found respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_ADDRESS4_HOST">
<term>HOSTS_CFG_GET_ALL_ADDRESS4_HOST using address %1 found host: %2</term>
<listitem><para>
This debug message is issued when found host with the reservation
for the specified IPv4 addres. The arguments specify the IPv4 address
and the detailed description of the host found.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_ADDRESS6">
<term>HOSTS_CFG_GET_ALL_ADDRESS6 get all hosts with reservations for IPv6 address %1</term>
<listitem><para>
This debug message is issued when starting to retrieve all hosts, holding the
reservation for the specific IPv6 address, from the configuration.
The argument specifies the IPv6 address used to search the hosts.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_ADDRESS6_COUNT">
<term>HOSTS_CFG_GET_ALL_ADDRESS6_COUNT using address %1, found %2 host(s)</term>
<listitem><para>
This debug message logs the number of hosts found using the specified
IPv6 address. The arguments specify the IPv6 address used and the number
of hosts found respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_ADDRESS6_HOST">
<term>HOSTS_CFG_GET_ALL_ADDRESS6_HOST using address %1 found host: %2</term>
<listitem><para>
This debug message is issued when found host with the reservation
for the specified IPv6 address. The arguments specify the IPv6 address
and the detailed description of the host found.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_HWADDR_DUID">
<term>HOSTS_CFG_GET_ALL_HWADDR_DUID get all hosts with reservations for HWADDR %1 and DUID %2</term>
<listitem><para>
This debug message is issued when starting to retrieve reservations for all hosts
using specific HW address or DUID. The arguments specify the HW address and
DUID respectively. The argument specify the HW address and DUID respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_IDENTIFIER">
<term>HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: %1</term>
<listitem><para>
This debug message is issued when starting to retrieve reservations for all hosts
identified by HW address or DUID. The argument holds both the identifier
type and the value.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT">
<term>HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier %1, found %2 host(s)</term>
<listitem><para>
This debug message logs the number of hosts found using the specified
identifier. The arguments specify the identifier used and the number
of hosts found respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_IDENTIFIER_HOST">
<term>HOSTS_CFG_GET_ALL_IDENTIFIER_HOST using identifier: %1, found host: %2</term>
<listitem><para>
This debug message is issued when found host identified by the specific
identifier. The arguments specify the identifier and the detailed
description of the host found.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6">
<term>HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6 get all hosts with reservations for subnet id %1 and IPv6 address %2</term>
<listitem><para>
This debug message is issued when starting to retrieve all hosts connected to
the specific subnet and having the specific IPv6 address reserved.
The arguments specify subnet id and IPv6 address respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6_COUNT">
<term>HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6_COUNT using subnet id %1 and address %2, found %3 host(s)</term>
<listitem><para>
This debug message include the details of the host found using the
subnet id and address. The arguments specify subnet id, address and
found host details respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6_HOST">
<term>HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6_HOST using subnet id %1 and address %2, found host: %3</term>
<listitem><para>
This debug message include the details of the host found using the
subnet id and address. The arguments specify subnet id, address and
found host details respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id %1 and IPv4 address %2</term>
<listitem><para>
This debug message is issued when starting to retrieve a host connected to the
specific subnet and having the specific IPv4 address reserved. The
arguments specify subnet id and IPv4 address respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_HOST">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_HOST using subnet id %1 and address %2, found host: %3</term>
<listitem><para>
This debug message logs the details of the host found using the
subnet id and IPv4 address.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id %1 and address %2</term>
<listitem><para>
This debug message is issued when no host was found for the specified
subnet id and IPv4 address.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6 get one host with reservation for subnet id %1 and including IPv6 address %2</term>
<listitem><para>
This debug message is issued when starting to retrieve a host connected to the
specific subnet and having the specific IPv6 address reserved. The
arguments specify subnet id and IPv6 address respectively.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6_HOST">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6_HOST using subnet id %1 and address %2, found host: %3</term>
<listitem><para>
This debug message logs the details of the host found using the
subnet id and IPv6 address.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6_NULL">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6_NULL host not found using subnet id %1 and address %2</term>
<listitem><para>
This debug message is issued when no host was found using the specified
subnet if and IPv6 address.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID get one host with %1 reservation for subnet id %2, HWADDR %3, DUID %4</term>
<listitem><para>
This debug message is issued when starting to retrieve the host holding IPv4 or
IPv6 reservations, which is connected to the specific subnet and is
identified by the specific HW address or DUID. The first argument
identifies if the IPv4 or IPv6 reservation is desired.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID_HOST">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID_HOST using subnet id %1, HWADDR %2 and DUID %3, found host: %4</term>
<listitem><para>
This debug message includes the details of the host found using the
subnet id, HW address and/or DUID.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID_NULL">
<term>HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID_NULL host not found using subnet id %1, HW address %2 and DUID %3</term>
<listitem><para>
This debug message is issued when no host was found using the specified
subnet id, HW address and DUID.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4">
<term>HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate source for host using subnet id %1 and address %2</term>
<listitem><para>
This debug message is issued when the Host Manager doesn't find the
host connected to the specific subnet and having the reservation for
the specific IPv4 address, and it is starting to search for this host
in the alternate host data source.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_HWADDR_DUID">
<term>HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_HWADDR_DUID trying alternate source for host using subnet id %1, HWADDR %2, DUID%3</term>
<listitem><para>
This debug message is issued when the Host Manager doesn't find the
host connected to the specific subnet and identified by the HW address
or DUID, and it is starting to search for this host in the alternate
host data source.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_MGR_ALTERNATE_GET6_PREFIX">
<term>HOSTS_MGR_ALTERNATE_GET6_PREFIX trying alternate source for host using prefix %1/%2</term>
<listitem><para>
This debug message is issued when the Host Manager doesn't find the
host connected to the specific subnet and having the reservation for
the specified prefix, and it is starting to search for this host in
the alternate host data source.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_ADDRESS6">
<term>HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_ADDRESS6 trying alternate source for host using subnet id %1 and IPv6 address %2</term>
<listitem><para>
This debug message is issued when the Host Manager doesn't find the
host connected to teh specific subnet and having the reservation for
the specified IPv6 address, and it is starting to search for this
host in the alternate host data source.
</para></listitem>
</varlistentry>

<varlistentry id="HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_DUID_HWADDR">
<term>HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_DUID_HWADDR trying alternate source for host using subnet id %1, DUID %2, HWADDR %3</term>
<listitem><para>
This debug message is issued when the Host Manager doesn't find the
host connected to the specific subnet and identified by the specified
DUID or HW Address, and it is starting to search for this host in the
alternate host data source.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="LFC">
    <title>LFC Module</title>
    <para>
      <variablelist>
<varlistentry id="LFC_FAIL_PID_CREATE">
<term>LFC_FAIL_PID_CREATE : %1</term>
<listitem><para>
This message is issued if LFC detected a failure when trying
to create the PID file.  It includes a more specifc error string.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_FAIL_PID_DEL">
<term>LFC_FAIL_PID_DEL : %1</term>
<listitem><para>
This message is issued if LFC detected a failure when trying
to delete the PID file.  It includes a more specifc error string.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_FAIL_PROCESS">
<term>LFC_FAIL_PROCESS : %1</term>
<listitem><para>
This message is issued if LFC detected a failure when trying
to process the files.  It includes a more specifc error string.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_FAIL_ROTATE">
<term>LFC_FAIL_ROTATE : %1</term>
<listitem><para>
This message is issued if LFC detected a failure when trying
to rotate the files.  It includes a more specifc error string.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_PROCESSING">
<term>LFC_PROCESSING Previous file: %1, copy file: %2</term>
<listitem><para>
This message is issued just before LFC starts processing the
lease files.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_READ_STATS">
<term>LFC_READ_STATS Leases: %1, attempts: %2, errors: %3.</term>
<listitem><para>
This message prints out the number of leases that were read, the
number of attempts to read leases and the number of errors
encountered while reading.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_ROTATING">
<term>LFC_ROTATING LFC rotating files</term>
<listitem><para>
This message is issued just before LFC starts rotating the
lease files - removing the old and replacing them with the new.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_RUNNING">
<term>LFC_RUNNING LFC instance already running</term>
<listitem><para>
This message is issued if LFC detects that a previous copy of LFC
may still be running via the PID check.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_START">
<term>LFC_START Starting lease file cleanup</term>
<listitem><para>
This message is issued as the LFC process starts.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_TERMINATE">
<term>LFC_TERMINATE LFC finished processing</term>
<listitem><para>
This message is issued when the LFC process completes.  It does not
indicate that the process was successful only that it has finished.
</para></listitem>
</varlistentry>

<varlistentry id="LFC_WRITE_STATS">
<term>LFC_WRITE_STATS Leases: %1, attempts: %2, errors: %3.</term>
<listitem><para>
This message prints out the number of leases that were written, the
number of attempts to write leases and the number of errors
encountered while writing.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="LOGIMPL">
    <title>LOGIMPL Module</title>
    <para>
      <variablelist>
<varlistentry id="LOGIMPL_ABOVE_MAX_DEBUG">
<term>LOGIMPL_ABOVE_MAX_DEBUG debug level of %1 is too high and will be set to the maximum of %2</term>
<listitem><para>
A message from the interface to the underlying logger implementation reporting
that the debug level (as set by an internally-created string DEBUGn, where n
is an integer, e.g. DEBUG22) is above the maximum allowed value and has
been reduced to that value.  The appearance of this message may indicate
a programming error - please submit a bug report.
</para></listitem>
</varlistentry>

<varlistentry id="LOGIMPL_BAD_DEBUG_STRING">
<term>LOGIMPL_BAD_DEBUG_STRING debug string '%1' has invalid format</term>
<listitem><para>
A message from the interface to the underlying logger implementation
reporting that an internally-created string used to set the debug level
is not of the correct format (it should be of the form DEBUGn, where n
is an integer, e.g. DEBUG22).  The appearance of this message indicates
a programming error - please submit a bug report.
</para></listitem>
</varlistentry>

<varlistentry id="LOGIMPL_BELOW_MIN_DEBUG">
<term>LOGIMPL_BELOW_MIN_DEBUG debug level of %1 is too low and will be set to the minimum of %2</term>
<listitem><para>
A message from the interface to the underlying logger implementation reporting
that the debug level (as set by an internally-created string DEBUGn, where n
is an integer, e.g. DEBUG22) is below the minimum allowed value and has
been increased to that value.  The appearance of this message may indicate
a programming error - please submit a bug report.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="LOG">
    <title>LOG Module</title>
    <para>
      <variablelist>
<varlistentry id="LOG_BAD_DESTINATION">
<term>LOG_BAD_DESTINATION unrecognized log destination: %1</term>
<listitem><para>
A logger destination value was given that was not recognized. The
destination should be one of "console", "file", or "syslog".
</para></listitem>
</varlistentry>

<varlistentry id="LOG_BAD_SEVERITY">
<term>LOG_BAD_SEVERITY unrecognized log severity: %1</term>
<listitem><para>
A logger severity value was given that was not recognized. The severity
should be one of "DEBUG", "INFO", "WARN", "ERROR", "FATAL" or "NONE".
</para></listitem>
</varlistentry>

<varlistentry id="LOG_BAD_STREAM">
<term>LOG_BAD_STREAM bad log console output stream: %1</term>
<listitem><para>
Logging has been configured so that output is written to the terminal
(console) but the stream on which it is to be written is not recognized.
Allowed values are "stdout" and "stderr".
</para></listitem>
</varlistentry>

<varlistentry id="LOG_DUPLICATE_MESSAGE_ID">
<term>LOG_DUPLICATE_MESSAGE_ID duplicate message ID (%1) in compiled code</term>
<listitem><para>
During start-up, Kea detected that the given message identification
had been defined multiple times in the Kea code.  This indicates a
programming error; please submit a bug report.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_DUPLICATE_NAMESPACE">
<term>LOG_DUPLICATE_NAMESPACE line %1: duplicate $NAMESPACE directive found</term>
<listitem><para>
When reading a message file, more than one $NAMESPACE directive was found.
(This directive is used to set a C++ namespace when generating header
files during software development.)  Such a condition is regarded as an
error and the read will be abandoned.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_INPUT_OPEN_FAIL">
<term>LOG_INPUT_OPEN_FAIL unable to open message file %1 for input: %2</term>
<listitem><para>
The program was not able to open the specified input message file for
the reason given.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_INVALID_MESSAGE_ID">
<term>LOG_INVALID_MESSAGE_ID line %1: invalid message identification '%2'</term>
<listitem><para>
An invalid message identification (ID) has been found during the read of
a message file.  Message IDs should comprise only alphanumeric characters
and the underscore, and should not start with a digit.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_LOCK_TEST_MESSAGE">
<term>LOG_LOCK_TEST_MESSAGE this is a test message.</term>
<listitem><para>
This is a log message used in testing.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_NAMESPACE_EXTRA_ARGS">
<term>LOG_NAMESPACE_EXTRA_ARGS line %1: $NAMESPACE directive has too many arguments</term>
<listitem><para>
The $NAMESPACE directive in a message file takes a single argument, a
namespace in which all the generated symbol names are placed.  This error
is generated when the compiler finds a $NAMESPACE directive with more
than one argument.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_NAMESPACE_INVALID_ARG">
<term>LOG_NAMESPACE_INVALID_ARG line %1: $NAMESPACE directive has an invalid argument ('%2')</term>
<listitem><para>
The $NAMESPACE argument in a message file should be a valid C++ namespace.
This message is output if the simple check on the syntax of the string
carried out by the reader fails.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_NAMESPACE_NO_ARGS">
<term>LOG_NAMESPACE_NO_ARGS line %1: no arguments were given to the $NAMESPACE directive</term>
<listitem><para>
The $NAMESPACE directive in a message file takes a single argument,
a C++ namespace in which all the generated symbol names are placed.
This error is generated when the compiler finds a $NAMESPACE directive
with no arguments.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_NO_MESSAGE_ID">
<term>LOG_NO_MESSAGE_ID line %1: message definition line found without a message ID</term>
<listitem><para>
Within a message file, message are defined by lines starting with a "%".
The rest of the line should comprise the message ID and text describing
the message.  This error indicates the message compiler found a line in
the message file comprising just the "%" and nothing else.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_NO_MESSAGE_TEXT">
<term>LOG_NO_MESSAGE_TEXT line %1: line found containing a message ID ('%2') and no text</term>
<listitem><para>
Within a message file, message are defined by lines starting with a "%".
The rest of the line should comprise the message ID and text describing
the message.  This error indicates the message compiler found a line
in the message file comprising just the "%" and message identification,
but no text.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_NO_SUCH_MESSAGE">
<term>LOG_NO_SUCH_MESSAGE could not replace message text for '%1': no such message</term>
<listitem><para>
During start-up a local message file was read.  A line with the listed
message identification was found in the file, but the identification is
not one contained in the compiled-in message dictionary.  This message
may appear a number of times in the file, once for every such unknown
message identification.
</para><para>
There may be several reasons why this message may appear:
</para><para>
- The message ID has been mis-spelled in the local message file.
</para><para>
- The program outputting the message may not use that particular message
(e.g. it originates in a module not used by the program).
</para><para>
- The local file was written for an earlier version of the Kea software
and the later version no longer generates that message.
</para><para>
Whatever the reason, there is no impact on the operation of Kea.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_OPEN_OUTPUT_FAIL">
<term>LOG_OPEN_OUTPUT_FAIL unable to open %1 for output: %2</term>
<listitem><para>
Originating within the logging code, the program was not able to open
the specified output file for the reason given.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_PREFIX_EXTRA_ARGS">
<term>LOG_PREFIX_EXTRA_ARGS line %1: $PREFIX directive has too many arguments</term>
<listitem><para>
Within a message file, the $PREFIX directive takes a single argument,
a prefix to be added to the symbol names when a C++ file is created.
This error is generated when the compiler finds a $PREFIX directive with
more than one argument.
</para><para>
Note: the $PREFIX directive is deprecated and will be removed in a future
version of Kea.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_PREFIX_INVALID_ARG">
<term>LOG_PREFIX_INVALID_ARG line %1: $PREFIX directive has an invalid argument ('%2')</term>
<listitem><para>
Within a message file, the $PREFIX directive takes a single argument,
a prefix to be added to the symbol names when a C++ file is created.
As such, it must adhere to restrictions on C++ symbol names (e.g. may
only contain alphanumeric characters or underscores, and may nor start
with a digit).  A $PREFIX directive was found with an argument (given
in the message) that violates those restrictions.
</para><para>
Note: the $PREFIX directive is deprecated and will be removed in a future
version of Kea.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_READING_LOCAL_FILE">
<term>LOG_READING_LOCAL_FILE reading local message file %1</term>
<listitem><para>
This is an informational message output by Kea when it starts to read
a local message file.  (A local message file may replace the text of
one or more messages; the ID of the message will not be changed though.)
</para></listitem>
</varlistentry>

<varlistentry id="LOG_READ_ERROR">
<term>LOG_READ_ERROR error reading from message file %1: %2</term>
<listitem><para>
The specified error was encountered reading from the named message file.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_UNRECOGNIZED_DIRECTIVE">
<term>LOG_UNRECOGNIZED_DIRECTIVE line %1: unrecognized directive '%2'</term>
<listitem><para>
Within a message file, a line starting with a dollar symbol was found
(indicating the presence of a directive) but the first word on the line
(shown in the message) was not recognized.
</para></listitem>
</varlistentry>

<varlistentry id="LOG_WRITE_ERROR">
<term>LOG_WRITE_ERROR error writing to %1: %2</term>
<listitem><para>
The specified error was encountered by the message compiler when writing
to the named output file.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>

  <section id="USER">
    <title>USER Module</title>
    <para>
      <variablelist>
<varlistentry id="USER_CHK_HOOK_LOAD_ERROR">
<term>USER_CHK_HOOK_LOAD_ERROR DHCP UserCheckHook could not be loaded: %1</term>
<listitem><para>
This is an error message issued when the DHCP UserCheckHook could not be loaded.
The exact cause should be explained in the log message.  User subnet selection
will revert to default processing.
</para></listitem>
</varlistentry>

<varlistentry id="USER_CHK_HOOK_UNLOAD_ERROR">
<term>USER_CHK_HOOK_UNLOAD_ERROR DHCP UserCheckHook an error occurred unloading the library: %1</term>
<listitem><para>
This is an error message issued when an error occurs while unloading the
UserCheckHook library.  This is unlikely to occur and normal operations of the
library will likely resume when it is next loaded.
</para></listitem>
</varlistentry>

<varlistentry id="USER_CHK_SUBNET4_SELECT_ERROR">
<term>USER_CHK_SUBNET4_SELECT_ERROR DHCP UserCheckHook an unexpected error occurred in subnet4_select callout: %1</term>
<listitem><para>
This is an error message issued when the DHCP UserCheckHook subnet4_select hook
encounters an unexpected error.  The message should contain a more detailed
explanation.
</para></listitem>
</varlistentry>

<varlistentry id="USER_CHK_SUBNET4_SELECT_REGISTRY_NULL">
<term>USER_CHK_SUBNET4_SELECT_REGISTRY_NULL DHCP UserCheckHook UserRegistry has not been created.</term>
<listitem><para>
This is an error message issued when the DHCP UserCheckHook subnet4_select hook
has been invoked but the UserRegistry has not been created.  This is a
programmatic error and should not occur.
</para></listitem>
</varlistentry>

<varlistentry id="USER_CHK_SUBNET6_SELECT_ERROR">
<term>USER_CHK_SUBNET6_SELECT_ERROR DHCP UserCheckHook an unexpected error occurred in subnet6_select callout: %1</term>
<listitem><para>
This is an error message issued when the DHCP UserCheckHook subnet6_select hook
encounters an unexpected error.  The message should contain a more detailed
explanation.
</para></listitem>
</varlistentry>

<varlistentry id="USER_CHK_SUBNET6_SELECT_REGISTRY_NULL">
<term>USER_CHK_SUBNET6_SELECT_REGISTRY_NULL DHCP UserCheckHook UserRegistry has not been created.</term>
<listitem><para>
This is an error message issued when the DHCP UserCheckHook subnet6_select hook
has been invoked but the UserRegistry has not been created.  This is a
programmatic error and should not occur.
</para></listitem>
</varlistentry>
      </variablelist>
    </para>
  </section>
  </chapter>
</book>
