A debug message informing about installing a file descriptor as a server. The file descriptor number is noted.

A debug message informing about installing a file descriptor as a server. The file descriptor number is noted.

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.

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.

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.

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.

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.

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.

This is the same to ASIODNS_UDP_CLOSE_FAIL but happens on the "synchronous UDP server", mainly used for the authoritative DNS server daemon.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This is the same to ASIODNS_UDP_RECEIVE_FAIL but happens on the "synchronous UDP server", mainly used for the authoritative DNS server daemon.

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.

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.

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.

This marks a low level error, we tried to read data from the message queue daemon asynchronously, but the ASIO library returned an error.

It is impossible to reach the message queue daemon for the reason given. It is unlikely there'll be reason for whatever program this currently is to continue running, as the communication with the rest of Kea is vital for the components.

The library is disconnecting from the message queue daemon. This debug message indicates that the program is trying to shut down gracefully.

This debug message indicates that the command channel library is about to connect to the message queue daemon, which should be listening on the UNIX-domain socket listed in the output.

This debug message indicates that the connection was successfully made, this should follow CC_ESTABLISH.

Debug message, noting that a message is expected to come over the command channel.

Debug message, noting that we successfully received a message (its envelope and payload listed). This follows CC_GROUP_RECEIVE, but might happen some time later, depending if we waited for it or just polled.

Debug message, we're about to send a message over the command channel.

This happens when garbage comes over the command channel or some kind of confusion happens in the program. The data received from the socket make no sense if we interpret it as lengths of message. The first one is total length of the message; the second is the length of the header. The header and its length (2 bytes) is counted in the total length.

There should be data representing the length of message on the socket, but it is not there.

Debug message: the local module received its unique identifier (name) from msgq on completion of establishing the session with msgq.

The program polled for incoming messages, but there was no message waiting. This is a debug message which may happen only after CC_GROUP_RECEIVE.

It isn't possible to connect to the message queue daemon, for reason listed. It is unlikely any program will be able continue without the communication.

A low level error happened when the library tried to read data from the command channel socket. The reason is listed.

We received an exception while trying to read data from the command channel socket. The reason is listed.

Debug message, noting we're sending a response to the original message with the given envelope.

Debug message. A timeout for which the program is willing to wait for a reply is being set.

Debug message. From now on, when a message (or command) comes, it'll wake the program and the library will automatically pass it over to correct place.

Debug message. The program wants to receive messages addressed to this group.

The program waited too long for data from the command channel (usually when it sent a query to different program and it didn't answer for whatever reason).

Debug message. The program no longer wants to receive messages addressed to this group.

A low level error happened when the library tried to write data to the command channel socket.

The library received a message length being zero, which makes no sense, since all messages must contain at least the envelope.

There was a problem with an incoming message on the command and control channel. The message does not appear to be a valid command, and is missing a required element or contains an unknown data format. This most likely means that another Kea module is sending a bad message. The message itself is ignored by this module.

There was an internal problem handling an incoming message on the command and control channel. An unexpected exception was thrown, details of which are appended to the message. The module will continue to run, but will not send back an answer.

The most likely cause of this error is a programming error. Please raise a bug report.

There was a problem when sending a message signaling that the module using this CCSession is stopping. This message is sent so that the rest of the system is aware that the module is no longer running. Apart from logging this message, the error itself is ignored, and the ModuleCCSession is still stopped. The specific exception message is printed.

Similar to CONFIG_CCSESSION_STOPPING, but in this case the exception that is seen is not a standard exception, and further information is unknown. This is a bug.

The configuration manager returned an error when this module requested the configuration. The full error message answer from the configuration manager is appended to the log error. The most likely cause is that the module is of a different (command specification) version than the running configuration manager.

There was an error parsing the JSON file. The given file does not appear to be in valid JSON format. Please verify that the filename is correct and that the contents are valid JSON.

This is a debug message. When processing the "loggers" part of the configuration file, the configuration library found an entry for the named logger that matches the logger specification for the program. The logging configuration for the program will be updated with the information.

This is a debug message. When processing the "loggers" part of the configuration file, the configuration library found an entry for the named logger. As this does not match the logger specification for the program, it has been ignored.

This is a debug message. When processing the "loggers" part of the configuration file, the configuration library found the named wildcard entry (one containing the "*" character) that matched a logger already matched by an explicitly named entry. The configuration is ignored.

This is a debug message. When processing the "loggers" part of the configuration file, the configuration library found the named wildcard entry (one containing the "*" character) that matches a logger specification in the program. The logging configuration for the program will be updated with the information.

The given file does not appear to be a valid specification file: details are included in the message. Please verify that the filename is correct and that its contents are a valid Kea module specification.

The specification file for this module was rejected by the configuration manager. The full error message answer from the configuration manager is appended to the log error. The most likely cause is that the module is of a different (specification file) version than the running configuration manager.

There was an error opening the given file. The reason for the failure is included in the message.

Debug message, saying there's a RPC call of given command to given module. It has internal sequence number as listed in the message.

This debug message is issued just before the controller attempts to disconnect from its session with the Kea control channel.

This debug message is issued just before the controller attempts to establish a session with the Kea control channel.

A debug message listing the command (and possible arguments) received from the Kea control system by the controller.

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.

This fatal error message indicates that the application attempted to load its initial configuration from file and has failed. The service will exit.

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.

A debug message indicating that the application process has received an updated configuration and has passed it to its configuration manager for parsing.

This debug message is issued when the dummy handler for configuration events is called. This only happens during initial startup.

A debug message indicating that the controller has received an updated configuration from the Kea configuration system.

This message indicates that while shutting down, the DHCP-DDNS controller encountered an error terminating communication with the Bundy configuration system. The service will still exit. While theoretically possible, this situation is rather unlikely.

This debug message is issued just before the controller attempts to create and initialize its application instance.

This error message is issued if the controller could not initialize the application and will exit.

A warning message is issued when an attempt is made to shut down the application when it is not running.

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.

The controller has encountered a fatal error while running the application and is terminating. The reason for the failure is included in the message.

This debug message is issued just before the controller invokes the application run method.

The controller has failed to establish communication with the rest of Kea and will exit.

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.

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.

A debug message issued during startup after the DHCPv4 server has successfully established a session with the Kea control channel.

This debug message is issued just before the DHCPv4 server attempts to establish a session with the Kea control channel.

This debug message informs that incoming packet has been assigned to specified class or classes. This is a normal behavior and indicates successful operation.

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.

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.

A debug message listing the command (and possible arguments) received from the Kea control system by the DHCPv4 server.

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.

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.

This is an informational message reporting that the configuration has been extended to include the specified IPv4 subnet.

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.

A debug message listing the configuration received by the DHCPv4 server. The source of that configuration depends on used configuration backend.

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.

A debug message indicating that the DHCPv4 server has received an updated configuration from the Kea configuration system.

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.

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.

This error message is logged when the attempt to compute DHCID for a specified lease has failed. The lease details and reason for failure is logged in the message.

This is the info message logged when the DHCPv4 server starts reconfiguration as a result of receiving SIGHUP signal.

This is an error message logged when the dynamic reconfiguration of the DHCP server failed.

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.

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.

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.

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.

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.

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.

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).

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 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.

This debug message is issued when the client being in the INIT-REBOOT state requested an address which is not assigned to him. The server will respond to this client with DHCPNAK.

This message is logged when the client sends invalid combination of values in the giaddr and hops fields. If the packet is relayed it should contain non-zero values in both fields. If the packet is sent from the directly connected client, both values should be set to zero. All other combinations are invalid and trigger packet drop.

This debug message indicates that the server successfully advertised a lease. It is up to the client to choose one server out of other advertised and continue allocation with that server. This is a normal behavior and indicates successful operation.

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.

This debug message indicates that the server successfully granted a lease in response to client's REQUEST message. This is a normal behavior and indicates successful operation.

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.

A warning message executed when a server process is unable to execute the periodic actions for the lease database. An example of the periodic action is a Lease File Cleanup. One of the reasons for the failure is a misconfiguration of the lease database, whereby the lease database hasn't been selected.

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 message argument indicates the reason for the failure.

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 reason for the failure is printed in the logged message.

A warning message is issued when an attempt is made to shut down the DHCPv4 server but it is not running.

This debug message is issued when the client being in the INIT-REBOOT state requested an address but this client is unknown. The server will not respond.

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.

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.

A debug message issued during startup, this indicates that the DHCPv4 server is about to open sockets on the specified port.

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.

This is a debug message informing that incoming DHCPv4 packet did not have mandatory DHCP message type option and thus was dropped.

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.

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.

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.

A debug message noting that the server has received the specified type of packet on the specified interface. Note that a packet marked as UNKNOWN may well be a valid DHCP packet, just a type not expected by the server (e.g. it will report a received OFFER packet as UNKNOWN).

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.

This error is output if the DHCPv4 server fails to send an assembled DHCP message to a client. The reason for the error is included in the message.

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.

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.

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.

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.

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.

A debug message listing the data received from the client.

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 parameter of this log message indicates whether the DNS entry is to be added or removed. The second parameter carries the details of the NameChangeRequest.

This debug message indicates that an address was released properly. It is a normal operation during client shutdown.

This message is output when an error was encountered during an attempt to process a RELEASE message. The error will not affect the client, which does not expect any response from the server for RELEASE messages. Depending on the nature of problem, it may affect future server operation.

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.

This warning message is printed when client attempts to release a lease, but no such lease is known to the server.

This warning message indicates that 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.

This warning message indicates that client tried to release an address that does belong to it, but the lease information was associated with a different hardware address. One possible reason for using different hardware address is that a cloned virtual machine was not updated and both clones use the same client-id.

A debug message listing the data returned to the client.

The DHCPv4 server has encountered a fatal error and is terminating. The reason for the failure is included in the message.

The DHCPv4 server has terminated normally.

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.

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.

This informational message indicates that the DHCPv4 server has processed any command-line switches and is starting. The version is also printed.

This is a debug message issued during the DHCPv4 server startup. It lists some information about the parameters with which the server is running.

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.

This warning 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.

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.

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 Offer, ACK, NAK etc.

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.

A debug message issued during startup after the IPv6 DHCP server has successfully established a session with the Kea control channel.

This debug message is issued just before the IPv6 DHCP server attempts to establish a session with the Kea control channel.

This debug message informs that incoming packet has been assigned to specified class or classes. This is a norma

This error message indicates that the received message is being dropped because it does not include the mandatory client-id option necessary for address assignment. The most likely cause is a problem with the client.

A debug message listing the command (and possible arguments) received from the Kea control system by the IPv6 DHCP server.

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.

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.

This is an informational message reporting that the configuration has been extended to include the specified subnet.

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.

A debug message listing the configuration received by the DHCPv6 server. The source of that configuration depends on used configuration backend.

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.

A debug message indicating that the IPv6 DHCP server has received an updated configuration from the Kea configuration system.

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.

This debug message is logged when the new Name Change Request has been created to perform the DNS Update, which adds new RRs.

This debug message is logged when the new Name Change Request has been created to perform the DNS Update, which removes RRs from the DNS.

This debug message is logged when FQDN mapping for a particular lease has been changed by the recent Request message. This mapping will be changed in DNS.

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.

This debug message is logged when server has found the DHCPv6 Client FQDN Option sent by a client and started processing it.

This error message is issued when a lease being deleted contains an indication that the DNS Update has been performed for it, but the FQDN held in the lease database has invalid format and can't be transformed to the canonical on-wire format.

This error message indicates that IPv6 DHCP server failed to send a DDNS update reqeust to the DHCP-DDNS server. This is most likely a configuration or networking error.

This debug message is logged when server includes an DHCPv6 Client FQDN Option in its response to the client.

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.

This is the info message logged when the DHCPv6 server starts reconfiguration as a result of receiving SIGHUP signal.

This is an error message logged when the dynamic reconfiguration of the DHCP server failed.

This is a debug message informing that a given subnet was selected. It will be used for extending lifetime of the lease. This is one of the early steps in the processing of incoming client message.

This warning message is output when a Renew or Rebind was received from a subnet for which the DHCPv6 server has not been configured. The cause is most likely due to a misconfiguration of the server. The packet processing will continue, but the response will only contain generic configuration parameters and no addresses or prefixes.

This warning message is printed when client attempts to extend the lease for the address (in the IA_NA option) but no such lease is known by the server. It typically means that client has attempted to use its lease past its lifetime: causes of this include a adjustment of the client's date/time setting or poor support on the client for sleep/recovery. A properly implemented client will recover from such a situation by restarting the lease allocation process after receiving a negative reply from the server.

An alternative cause could be that the server has lost its database recently and does not recognize its well-behaving clients. This is more probable if you see many such messages. Clients will recover from this, but they will most likely get a different IP addresses and experience a brief service interruption.

A warning message indicating that a client is attempting to extend lease lifetime for the address, but the server does not have any information about the subnet this client belongs to. This may mean that faulty the mobile client changed its location and is trying to renew its old address (client is supposed to send confirm, not renew in such cases, according to RFC3315) or the server configuration has changed and information about existing subnet was removed. Note that in a sense this is worse case of DHCP6_EXTEND_NA_UNKNOWN, as not only the lease is unknown, but also the subnet is. Depending on the reasons of this condition, it may or may not correct on its own.

This warning message is logged when a client attempts to extend the lifetime of the prefix it is using, but the server was unable to find the binding to which this lease belongs. This error condition has different implications for the Renew and Rebind messages. For the former, the server will respond with NoBinding status code. For the latter, the server will discard the message.

A warning message indicating that a client is attempting to extend lease lifetime for the prefix, but the server doesn't have any information about the subnet this client belongs to.

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.

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.

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.

or 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 client requested renewal of multiples 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.

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.

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.

This debug message is printed when a callout installed on lease6_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. If client requested renewal of multiples 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.

This debug message is printed when a callout installed on the pkt6_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.

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).

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 server has failed to establish communication with the rest of Kea, failed to read JSON configuration file or excountered any other critical issue that prevents it from starting up properly. Attached error message provides more details about the issue.

This debug message indicates that the server successfully advertised an address lease. It is up to the client to choose one server out of the advertised servers and continue allocation with that server. This is a normal behavior and indicates successful operation.

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.

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.

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.

A warning message executed when a server process is unable to execute the periodic actions for the lease database. An example of the periodic action is a Lease File Cleanup. One of the reasons for the failure is a misconfiguration of the lease database, whereby the lease database hasn't been selected.

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.

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.

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.

A warning message is issued when an attempt is made to shut down the IPv6 DHCP server but it is not running.

During startup the IPv6 DHCP server failed to detect any network interfaces and is therefore shutting down.

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.

A debug message issued during startup, this indicates that the IPv6 DHCP server is about to open sockets on the specified port.

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.

A debug message noting that server has received message with server identifier option that not matching server identifier that server is using.

The DHCPv6 server has received a packet that it is unable to interpret. There may be many causes: truncated header, truncated or malformed option, trailing padding that contains garbage etc. More information is specified as a parameter.

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.

A debug message noting that the server has received the specified type of packet. Note that a packet marked as UNKNOWN may well be a valid DHCP packet, just a type not expected by the server (e.g. it will report a received OFFER packet as UNKNOWN).

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.

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.

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.

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.

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.

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.

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.

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.

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.

This debug message indicates that the server successfully advertised a prefix lease. It is up to the client to choose one server out of the advertised servers and continue allocation with that server. This is a normal behavior and indicates successful operation.

This message indicates that in response to a received SOLICIT, the server failed to advertise a prefix lease for the client. There may be many reasons for such failure. Each failure is logged in a separate log entry.

This debug message indicates that in response to a client's REQUEST message, the server successfully granted a prefix delegation lease. This is a normal behavior and indicates successful operation.

This message indicates that the server failed to grant (in response to received REQUEST) a prefix lease for a given client. There may be many reasons for such failure. Each failure is logged in a separate log entry.

This is a debug message that indicates the processing of a received IA_NA option. It may optionally contain an address that may be used by the server as a hint for possible requested address.

This is a debug message that indicates a processing of received IA_PD option. It may optionally contain an prefix that may be used by the server as a hint for possible requested prefix.

A debug message listing the data received from the client or relay.

This warning message indicates that client sent RELEASE message without mandatory client-id option. This is most likely caused by a buggy client (or a relay that malformed forwarded message). This request will not be processed and a response with error status code will be sent back.

This debug message indicates that an address was released properly. It is a normal operation during client shutdown.

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.

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.

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.

This debug message indicates that a prefix was released properly. It is a normal operation during client shutdown.

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.

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.

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.

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.

A debug message listing the data returned to the client.

This informational messages indicates that the server was not able to read its server identifier (DUID) and has generated a new one. This server-id will be stored in a file and will be read and used during next restart. It is normal behavior when the server is started for the first time. If this message is printed every start, please check that the server have sufficient permission to write its server-id file and that the file is not corrupt.

Changing the server identifier in a production environment is not recommended as existing clients will not recognize the server and may go through a rebind phase. However, they should be able to recover without losing their leases.

This debug message indicates that the server loaded its server identifier. That value is sent in all server responses and clients use it to discriminate between servers. This is a part of normal startup or reconfiguration procedure.

This warning message indicates that server was not able to write its server identifier (DUID) to a file. This likely indicates lack of write permission to a given file or directory. This is not critical and the server will continue to operate, but server will generate different DUID during every start and clients will need to go through a rebind phase to recover.

The IPv6 DHCP server has encountered a fatal error and is terminating. The reason for the failure is included in the message.

The IPv6 DHCP server has terminated normally.

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.

This is a debug message that inform that a unicast socket will be opened.

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.

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.

This informational message indicates that the IPv6 DHCP server has processed any command-line switches and is starting. The version is also printed.

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.

This is a debug message informing that a given subnet was selected. It will be used for address and option assignment. This is one of the early steps in the processing of incoming client message.

This warning message is output when a packet was received from a subnet for which the DHCPv6 server has not been configured. The cause is most likely due to a misconfiguration of the server. The packet processing will continue, but the response will only contain generic configuration parameters and no addresses or prefixes.

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.

This warning message is printed when client attempts to release an address lease, but no such lease is known by the server. See the explanation of the status code DHCP6_UNKNOWN_RENEW_NA for possible reasons for such behavior.

This warning message is printed when client attempts to release an prefix lease, but no such lease is known by the server. See the explanation of the status code DHCP6_UNKNOWN_RENEW_PD for possible reasons for such behavior.

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 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.

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.

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 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.

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.

An info message issued when a new interface is being added to the collection of interfaces on which the server listens to DHCP messages.

A debug message reported when the DHCP configuration manager is adding the specified IPv4 subnet to its database.

A debug message reported when the DHCP configuration manager is adding the specified IPv6 subnet to its database.

A debug message issued when the server is being configured to listen on all interfaces.

A debug message issued when the server's DHCP-DDNS settings are changed.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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).

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.

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.

A message issued when the server is configured to listen on the explicitly specified IP address on the given interface.

An info message issued when configuring the DHCP server to listen on the unicast address on the specific interface.

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.

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.

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.

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.

A debug message issued when a NameChangeRequest has been successfully sent to kea-dhcp-ddns.

A informational message issued when a communications with kea-dhcp-ddns has been successfully started.

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.

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.

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.

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.

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.

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.

This informational message signals that the specified client was assigned the address reserved for it.

This informational message signals that the specified client was assigned the prefix reserved for it.

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.

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.

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.

A debug message issued when the server is about to add an IPv4 lease with the specified address to the memory file backend database.

A debug message issued when the server is about to add an IPv6 lease with the specified address to the memory file backend database.

The code has issued a commit call. For the memory file database, this is a no-op.

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.

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.

A debug message issued when the server is attempting to obtain an IPv4 lease from the memory file database for the specified address.

A debug message issued when the server is attempting to obtain an IPv6 lease from the memory file database for the specified address.

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.

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.

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.

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).

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).

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.

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.

A debug message issued when the server is about to obtain schema version information from the memory file database.

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.

A debug message issued when DHCP lease is being loaded from the file to memory.

An informational message issued when the Memfile lease database backend starts a new process to perform Lease File Cleanup.

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.

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.

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.

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.

An informational message issued when the Memfile lease database backend starts the periodic Lease File Cleanup.

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.

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.

The code has issued a rollback call. For the memory file database, this is a no-op.

A debug message issued when the server is attempting to update IPv4 lease from the memory file database for the specified address.

A debug message issued when the server is attempting to update IPv6 lease from the memory file database for the specified address.

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.

A debug message issued when the server is about to add an IPv4 lease with the specified address to the MySQL backend database.

A debug message issued when the server is about to add an IPv6 lease with the specified address to the MySQL backend database.

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.

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.

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.

A debug message issued when the server is attempting to obtain an IPv4 lease from the MySQL database for the specified address.

A debug message issued when the server is attempting to obtain an IPv6 lease from the MySQL database for the specified address.

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.

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.

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).

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).

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.

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.

A debug message issued when the server is about to obtain schema version information from the MySQL database.

The code has issued a rollback call. All outstanding transaction will be rolled back and not committed to the database.

A debug message issued when the server is attempting to update IPv4 lease from the MySQL database for the specified address.

A debug message issued when the server is attempting to update IPv6 lease from the MySQL database for the specified address.

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.

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.

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.

A debug message issued when the server is about to add an IPv4 lease with the specified address to the PostgreSQL backend database.

A debug message issued when the server is about to add an IPv6 lease with the specified address to the PostgreSQL backend database.

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.

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.

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.

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.

A debug message issued when the server is attempting to obtain an IPv4 lease from the PostgreSQL database for the specified address.

A debug message issued when the server is attempting to obtain an IPv6 lease from the PostgreSQL database for the specified address.

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.

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.

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).

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).

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.

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.

A debug message issued when the server is about to obtain schema version information from the PostgreSQL database.

The code has issued a rollback call. All outstanding transaction will be rolled back and not committed to the database.

A debug message issued when the server is attempting to update IPv4 lease from the PostgreSQL database for the specified address.

A debug message issued when the server is attempting to update IPv6 lease from the PostgreSQL database for the specified address.

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 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.

The database access string specified a database type (given in the message) that is unknown to the software. This is a configuration error.

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.

This is an informational message issued after DHCP_DDNS has submitted DNS mapping additions which were received and accepted by an appropriate DNS server.

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.

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.

This is an informational message indicating the application has received a signal instructing it to reload its configuration from file.

This is a debug message issued when the application has been instructed to shutdown and has met the required criteria to exit.

This is a debug message issued when the DHCP-DDNS application command method has been invoked.

This is a debug message issued when the DHCP-DDNS application configure method has been invoked.

This is a debug message issued when the DHCP-DDNS application encounters an unrecoverable error from within the event loop.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This is a debug message issued when the DHCP-DDNS application enters its initialization method.

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.

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.

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.

This is an error message indicating that the NameChangeRequest listener used by DHCP-DDNS to receive requests encountered a 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.

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.

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.

This is a debug message indicating that DHCP_DDNS's Queue Manager has successfully started and is now listening for NameChangeRequests.

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.

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.

This is an informational message indicating that DHCP_DDNS is stopping the queue manager either to reconfigure it or as part of application shutdown.

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.

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.

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.

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.

This is an informational message issued after DHCP_DDNS has submitted DNS mapping removals which were received and accepted by an appropriate DNS server.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This is a debug message issued when the DHCP-DDNS application enters its run method.

This is a debug message issued when the DHCP-DDNS server exits its event lo

This is an informational message indicating that the DHCP-DDNS service has shut down.

This is a debug message issued when the application has been instructed to shut down by the controller.

This is a debug message indicating the application has received a signal instructing it to shutdown.

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.

This is an informational message issued when controller for the service first starts. Version is also reported.

This is a debug message issued when DHCP-DDNS has begun a transaction for a given request.

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.

This is error message issued when the application is able to construct an update message but the attempt to send it suffered a 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.

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.

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.

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.

This is a debug message issued when DHCP_DDNS sends a DNS request to a DNS server.

This is a debug message issued when DHCP_DDNS receives sends a DNS update response from a DNS server.

This is an error message that indicates the application was unable to close the inbound side of a NCR sender's watch socket. While technically possible this error is highly unlikely to occur and should not impair the application's ability to process requests.

This is an error message that indicates the application was unable to close the outbound side of a NCR sender's watch socket. While technically possible this error is highly unlikely to occur and should not impair the application's ability to process requests.

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.

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.

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

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.

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.

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.

This is a debug message, output when a library (whose index in the list of libraries (being) loaded is given) registers a callout.

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.

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.

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.

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.

This information message is issued when a user-supplied hooks library has been successfully loaded.

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.

This information message is issued when a user-supplied hooks library has been successfully unloaded.

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.

A debug message issued when the version check on the hooks library has succeeded.

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.

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.

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.

This is a debug message issued when the "load" function has been found in a hook library and has been successfully called.

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.

This is a debug message issued when the library is being unloaded. It merely states that the library did not contain an "unload" function.

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.

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.

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.

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.

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.

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.

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.

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.

This message is issued if LFC detected a failure when trying to create the PID file. It includes a more specifc error string.

This message is issued if LFC detected a failure when trying to delete the PID file. It includes a more specifc error string.

This message is issued if LFC detected a failure when trying to process the files. It includes a more specifc error string.

This message is issued if LFC detected a failure when trying to rotate the files. It includes a more specifc error string.

This message is issued just before LFC starts processing the lease files.

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.

This message is issued just before LFC starts rotating the lease files - removing the old and replacing them with the new.

This message is issued if LFC detects that a previous copy of LFC may still be running via the PID check.

This message is issued as the LFC process starts.

This message is issued when the LFC process completes. It does not indicate that the process was successful only that it has finished.

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.

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.

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.

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.

A logger destination value was given that was not recognized. The destination should be one of "console", "file", or "syslog".

A logger severity value was given that was not recognized. The severity should be one of "DEBUG", "INFO", "WARN", "ERROR", "FATAL" or "NONE".

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 recognised. Allowed values are "stdout" and "stderr".

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.

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.

The program was not able to open the specified input message file for the reason given.

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.

This is a log message used in testing.

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.

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.

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.

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.

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.

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.

There may be several reasons why this message may appear:

- The message ID has been mis-spelled in the local message file.

- The program outputting the message may not use that particular message (e.g. it originates in a module not used by the program).

- The local file was written for an earlier version of the Kea software and the later version no longer generates that message.

Whatever the reason, there is no impact on the operation of Kea.

Originating within the logging code, the program was not able to open the specified output file for the reason given.

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.

Note: the $PREFIX directive is deprecated and will be removed in a future version of Kea.

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.

Note: the $PREFIX directive is deprecated and will be removed in a future version of Kea.

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.)

The specified error was encountered reading from the named message file.

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 recognised.

The specified error was encountered by the message compiler when writing to the named output file.

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.

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.

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.

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.

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.

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.