packet hasn't been parsed yet. The only available information is the
interface and the source and destination addresses/ports.
-% DHCP4_BUFFER_UNPACK parsing received buffer from %1 to %2 over interface %3
+% DHCP4_BUFFER_UNPACK parsing buffer received from %1 to %2 over interface %3
This debug message is issued when the server starts parsing the received
-buffer holding the DHCPv4 message.
+buffer holding the DHCPv4 message. The arguments specify the source and
+destination addresses as well as the interface over which the buffer has
+been received.
% DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout %1 ms
This debug message is issued when the server enters the state when it
waits for new packets. The argument specifies the timeout for the server
to wait for the packet. When this time elapses the server will pass
through its main loop to perform handling of any pending signals
-and timers. After that it will enter the wait state again.
+and timers. After that, it will enter the wait state again.
% DHCP4_BUFFER_WAIT_SIGNAL signal received while waiting for next packet, next waiting signal is %1
-This debug message is issued when the server's waiting for the packet
-is interrupted by the signal received by the process. The signal
-will be handled before the server starts waiting for next packets.
+This debug message is issued when the server was waiting for the
+packet, but the wait has been interrupted by the signal received
+by the process. The signal will be handled before the server starts
+waiting for next packets. The argument specifies the next signal to
+be handled by the server.
% DHCP4_BUFFER_WAIT_TIMEOUT timeout %1 ms reached while waiting for the next packet
-This debug message is issued when the timeout has occured while
+This debug message is issued when the timeout has occurred while
waiting for the next packet. The server will now handle signals
received and ready timers before waiting for next packets again.
+The argument specifies the timeout value in milliseconds.
% DHCP4_CCSESSION_STARTED control channel session started on socket %1
A debug message issued during startup after the DHCPv4 server has
This debug message is issued just before the DHCPv4 server attempts
to establish a session with the Kea control channel.
-% DHCP4_CLASS_ASSIGNED client packet has been assigned to the following class(es): %1
+% DHCP4_CLASS_ASSIGNED %1: client packet has been assigned to the following class(es): %2
This debug message informs that incoming packet has been assigned to specified
class or classes. This is a normal behavior and indicates successful operation.
+The first argument specifies the client and transaction identification
+information. The second argument includes all classes to which the
+packet has been assigned.
% DHCP4_CLIENT_FQDN_PROCESS %1: processing Client FQDN option
This debug message is issued when the server starts to process the Client
FQDN option sent in the client's query. The argument includes the
client and transaction identification information.
-% DHCP4_CLIENT_FQDN_DATA %1: client FQDN option information: %2
+% DHCP4_CLIENT_FQDN_DATA %1: Client FQDN option information: %2
This debug message includes the detailed information extracted from the
Client FQDN option sent in the query. The first argument includes the
-client and transaction identification information.
+client and transaction identification information. The second argument
+specifies the detailed information about the FQDN option received
+by the server.
% DHCP4_CLIENT_HOSTNAME_PROCESS %1: processing client's Hostname option
This debug message is issued when the server starts to process the Hostname
% DHCP4_CLIENT_HOSTNAME_DATA %1: client Hostname option information: %2
This debug message includes the detailed information extracted from the
Hostname option sent in the query. The first argument includes the
-client and transaction identification information.
+client and transaction identification information. The second argument
+specifies the hostname carried in the Hostname option sent by the
+client.
-% DHCP4_CLIENT_NAME_PROC_FAIL failed to process the fqdn or hostname sent by a client: %1
+% DHCP4_CLIENT_NAME_PROC_FAIL %1: failed to process the fqdn or hostname sent by a client: %2
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.
+name was malformed or due to internal server error. The first argument
+contains the client and transaction identification information. The
+second argument holds the detailed description of the error.
% DHCP4_COMMAND_RECEIVED received command %1, arguments: %2
A debug message listing the command (and possible arguments) received
lease has failed. The lease details and reason for failure is logged in the
message.
-% DHCP4_DISCOVER_CLASS_PROCESSING_FAILED client class specific processing failed for DHCPDISCOVER
+% DHCP4_DISCOVER_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPDISCOVER
This debug message means that the server processing that is unique for each
client class has reported a failure. The response packet will not be sent.
+The argument holds the client and transaction identification information.
% DHCP4_DYNAMIC_RECONFIGURATION initiate server reconfiguration using file: %1, after receiving SIGHUP signal
This is the info message logged when the DHCPv4 server starts reconfiguration
This is an error message logged when the dynamic reconfiguration of the
DHCP server failed.
-% DHCP4_EMPTY_HOSTNAME received empty hostname from the client, skipping processing of this option
+% DHCP4_EMPTY_HOSTNAME %1: received empty hostname from the client, skipping processing of this option
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.
+option is skipped. The argument holds the client and transaction identification
+information.
% DHCP4_HOOKS_LIBS_RELOAD_FAIL reload of hooks libraries failed
A "libreload" command was issued to reload the hooks libraries but for
This debug message is printed when a callout installed on buffer4_receive
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
+The arguments specify the source and destination address as well as
+the name of the interface over which the buffer has been received.
% DHCP4_HOOK_BUFFER_SEND_SKIP %1: prepared response is dropped because a callout set the skip flag.
This debug message is printed when a callout installed on buffer4_send
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).
-% DHCP4_HOOK_SUBNET4_SELECT_SKIP no subnet was selected, because a callout set skip flag.
+% DHCP4_HOOK_SUBNET4_SELECT_SKIP %1: no subnet was selected, because a callout set skip flag.
This debug message is printed when a callout installed on the
subnet4_select hook point sets the skip flag. For this particular hook
point, the setting of the flag instructs the server not to choose a
subnet, an action that severely limits further processing; the server
will be only able to offer global options - no addresses will be assigned.
+The argument specifies the client and transaction identification
+information.
-% DHCP4_INFORM_CLASS_PROCESSING_FAILED client class specific processing failed for DHCPINFORM
+% DHCP4_INFORM_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPINFORM
This debug message means that the server processing that is unique for each
client class has reported a failure. The response packet will not be sent.
+The argument specifies the client and the transaction identification
+information.
% DHCP4_INFORM_DIRECT_REPLY %1: DHCPACK in reply to the DHCPINFORM will be sent directly to %2
This debug message is issued when the DHCPACK will be sent directly to the
% DHCP4_LEASE_ADVERT %1: lease %2 will be advertised
This debug message indicates that the server has found the lease to be
offered to the client. It is up to the client to choose one server out of
-those which offered leases and continue allocation with that server. This
+those which offered leases and continue allocation with that server.
+The first argument specifies the client and the transaction identification
+information. The second argument specifies the address to be offered.
% DHCP4_LEASE_ALLOC %1: lease %2 has been allocated
This debug message indicates that the server successfully granted a lease
in response to client's DHCPREQUEST message. The lease information will
-be sent to the client in the DHCPACK message.
+be sent to the client in the DHCPACK message. The first argument
+contains the client and the transaction identification information. The
+second argument contains the allocated address.
% DHCP4_LEASE_DATABASE_TIMERS_EXEC_FAIL failed to execute timer-based functions for lease database: %1
A warning message executed when a server process is unable to execute
a misconfiguration of the lease database, whereby the lease database
hasn't been selected.
-% DHCP4_NAME_GEN_UPDATE_FAIL failed to update the lease after generating name for a client: %1
+% DHCP4_NAME_GEN_UPDATE_FAIL %1: failed to update the lease after generating name %2 for a client: %3
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.
+failure. The first argument includes the client and the transaction
+identification information. The second argument specifies the hostname.
+The third argument contains the error details.
% DHCP4_NCR_CREATE %1: DDNS updates enabled, therefore sending name change requests
This debug message message is issued when the server is starting to send
% DHCP4_NO_LEASE_INIT_REBOOT %1: no lease for address %2 requested by INIT-REBOOT client
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.
+The first argument includes the client and the transaction id identification
+information. The second argument includes the IP address requested by the
+client.
% DHCP4_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
This warning message is issued when current server configuration specifies
% DHCP4_PACKET_DROP_0004 %1, from interface %2: missing msg-type option
This is a debug message informing that incoming DHCPv4 packet did not
-have mandatory DHCP message type option and thus was dropped.
+have mandatory DHCP message type option and thus was dropped. The
+arguments specify the client and transaction identification information,
+as well as the interface on which the message has been received.
% DHCP4_PACKET_DROP_0005 %1: unrecognized type %2 in option 53
This debug message indicates that the message type carried in DHCPv4 option
53 is unrecognized by the server. The valid message types are listed
on the IANA website: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#message-type-53.
-The message will not be processed by the server.
+The message will not be processed by the server. The arguments specify
+the client and transaction identification information, as well as the
+received message type.
% DHCP4_PACKET_DROP_0006 %1: unsupported DHCPv4 message type %2
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.
+messages being normally sent by the server to the client, such as DHCPOFFER,
+DHCPACK, DHCPNAK etc. The first argument specifies the client and transaction
+identification information. The second argument specifies the message type.
-% DHCP4_PACKET_DROP_0007 %1: failed to process packet - %2
+% DHCP4_PACKET_DROP_0007 %1: failed to process packet: %2
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.
+will not send a response but will instead ignore the packet. The first
+argument contains the client and transaction identification information.
+The second argument includes the details of the error.
% DHCP4_PACKET_NAK_0001 %1: failed to select a subnet for incoming packet, src %2, type %3
This error message is output when a packet was received from a subnet
for which the DHCPv4 server has not been configured. The most probable
-cause is a misconfiguration of the server.
+cause is a misconfiguration of the server. The first argument contains
+the client and transaction identification information. The second argument
+contains the source address of the packet. The third argument contains
+the name of the received packet.
% DHCP4_PACKET_NAK_0002 %1: invalid address %2 requested by INIT-REBOOT
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.
+to this client with DHCPNAK. The first argument contains the client and
+the transaction identification information. The second arguments holds the
+address requested by the client.
% DHCP4_PACKET_NAK_0003 %1: failed to advertise a lease, client sent ciaddr %2, requested-ip-address %3
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.
+many possible reasons for such a failure. The first argument contains
+the client and the transaction identification information. The second
+argument contains the address in the ciaddr field. The third
+argument contains the IP address in the requested-ip-address option
+(if present).
% DHCP4_PACKET_NAK_0004 %1: failed to grant a lease, client sent ciaddr %2, requested-ip-address %3
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.
+reason. The first argument contains the client and the transaction
+identification information. The second argument contains the address in
+the ciaddr field. The third argument contains the IP address in the
+requested-ip-address option (if present).
% DHCP4_PACKET_PACK %1: preparing on-wire format of the packet to be sent
This debug message is issued when the server starts preparing the on-wire
format of the packet to be sent back to the client. The argument specifies
-the identifiers of the client: HW address and client identifier.
+the client and the transaction identification information.
% DHCP4_PACKET_PACK_FAIL %1: preparing on-wire-format of the packet to be sent failed %2
This error message is issued when preparing an on-wire format of the packet
% DHCP4_PACKET_SEND_FAIL %1: failed to send DHCPv4 packet: %2
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.
+DHCP message to a client. The first argument includes the client and
+the transaction identification information. The second argument includes
+the reason for failure.
% DHCP4_PARSER_COMMIT_EXCEPTION parser failed to commit changes
On receipt of message containing details to a change of the DHCPv4
parsing actions and committal of changes failed. The reason for the
failure is given in the message.
-% DHCP4_QUERY_DATA %1, packet details: [%2]
-A debug message listing the details of the received from the client.
+% DHCP4_QUERY_DATA %1, packet details: %2
+A debug message printing the details of the received packet. The first
+argument includes the client and the transaction identification
+information.
% DHCP4_QUEUE_NCR name change request to %1 DNS entry queued: %2
A debug message which is logged when the NameChangeRequest to add or remove
% DHCP4_RELEASE %1: address %2 was released properly.
This debug message indicates that an address was released properly. It
-is a normal operation during client shutdown.
+is a normal operation during client shutdown. The first argument includes
+the client and transaction identification information. The second argument
+includes the released IP address.
% DHCP4_RELEASE_EXCEPTION %1: while trying to release address %2 an exception occured: %3
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
+to process a DHCPRELEASE message. The error will not affect the client,
+which does not expect any response from the server for DHCPRELEASE
messages. Depending on the nature of problem, it may affect future
-server operation.
+server operation. The first argument includes the client and the
+transaction identification information. The second argument
+includes the IP address which release was attempted. The last
+argument includes the detailed error description.
% DHCP4_RELEASE_FAIL %1: failed to remove lease for address %2
This error message indicates that the software failed to remove 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.
+removed from the database during RELEASE message processing. The
+first argument includes the client and the transaction identification
+information. The second argument holds the IP address which release
+was attempted.
% DHCP4_RELEASE_FAIL_NO_LEASE %1: client is trying to release non-existing lease %2
This debug message is printed when client attempts to release a lease,
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.
+both clones use the same client-id. The first argument includes the
+client and the transaction identification information. The second
+argument includes the address which release was attempted. The
+third argumnet includes the HW address of the lease owner.
% DHCP4_RESPONSE_FQDN_DATA %1: including FQDN option in the server's response: %2
This debug message is issued when the server is adding the Client FQDN
% DHCP4_RESPONSE_DATA %1: responding with packet %2 (type %3), packet details: "%4"
A debug message including the detailed data about the packet being sent
-to the client.
+to the client. The first argument contains the client and the transaction
+identification information. The second and third argument contains the
+packet name and type respectively. The fourth argument contains detailed
+packet information.
% DHCP4_SERVER_FAILED server failed: %1
The DHCPv4 server has encountered a fatal error and is terminating.
It lists some information about the parameters with which the server
is running.
-% DHCP4_SUBNET_SELECTED the %1 subnet was selected for client assignment
+% DHCP4_SUBNET_DATA %1: the selected subnet details: %2
+This debug message includes the details of the subnet selected fot
+the client. The first argument includes the client and the
+transaction identification information. The second arguments
+includes the subnet details.
+
+% DHCP4_SUBNET_SELECTED %1: the subnet with ID %2 was selected for client assignments
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.
+address and option assignment. Subnet selection is one of the early
+steps in the processing of incoming client message. The first
+argument includes the client and the transaction identification
+information. The second argument holds the selected subnet id.
+
+% DHCP4_SUBNET_SELECTION_FAILED %1: failed to select subnet for the client
+This debug message indicates that the server failed to select the
+subnet for the client which has sent a message to the server.
+The server will not be able to offer any lease to the client and
+will drop its message if the received message was DHCPDISCOVER,
+and will send DHCPNAK if the received message was DHCPREQUEST.
+The argument includes the client and the transaction identification
+information.
// will be selected. Packet processing will continue, but it will
// be severely limited (i.e. only global options will be assigned)
if (callout_handle->getSkip()) {
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_HOOKS,
- DHCP4_HOOK_SUBNET4_SELECT_SKIP);
+ LOG_DEBUG(srv_hooks_logger, DBG_DHCP4_HOOKS,
+ DHCP4_HOOK_SUBNET4_SELECT_SKIP)
+ .arg(query->getLabel());
return (Subnet4Ptr());
}
callout_handle->getArgument("subnet4", subnet);
}
+ if (subnet) {
+ // Log at higher debug level that subnet has been found.
+ LOG_DEBUG(packet_logger, DBG_DHCP4_DETAIL, DHCP4_SUBNET_SELECTED)
+ .arg(query->getLabel())
+ .arg(subnet->getID());
+ // Log detailed information about the selected subnet at the
+ // lower debug level.
+ LOG_DEBUG(packet_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_SUBNET_DATA)
+ .arg(query->getLabel())
+ .arg(subnet->toText());
+
+ } else {
+ LOG_DEBUG(packet_logger, DBG_DHCP4_DETAIL,
+ DHCP4_SUBNET_SELECTION_FAILED)
+ .arg(query->getLabel());
+ }
+
return (subnet);
}
// (The problem is logged as a debug message because debug is
// disabled by default - it prevents a DDOS attack based on the
// sending of problem packets.)
- if (dhcp4_logger.isDebugEnabled(DBG_DHCP4_BASIC)) {
- std::string source = "unknown";
- HWAddrPtr hwptr = query->getHWAddr();
- if (hwptr) {
- source = hwptr->toText();
- }
- LOG_DEBUG(bad_packet_logger, DBG_DHCP4_BASIC,
- DHCP4_PACKET_DROP_0007)
- .arg(query->getLabel())
- .arg(e.what());
- }
+ LOG_DEBUG(bad_packet_logger, DBG_DHCP4_BASIC,
+ DHCP4_PACKET_DROP_0007)
+ .arg(query->getLabel())
+ .arg(e.what());
}
if (!rsp) {
processHostnameOption(ex);
}
}
- } catch (const Exception& ex) {
+ } catch (const Exception& e) {
// In some rare cases it is possible that the client's name processing
// fails. For example, the Hostname option may be malformed, or there
// may be an error in the server's logic which would cause multiple
// from the log. We don't want to throw an exception here because,
// it will impact the processing of the whole packet. We rather want
// the processing to continue, even if the client's name is wrong.
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_CLIENT_NAME_PROC_FAIL)
- .arg(ex.what());
+ LOG_DEBUG(hostname_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_CLIENT_NAME_PROC_FAIL)
+ .arg(ex.getQuery()->getLabel())
+ .arg(e.what());
}
}
/// @todo It would be more liberal to accept this and let it fall into
/// the case of replace or less than two below.
if (label_count == 0) {
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_EMPTY_HOSTNAME);
+ LOG_DEBUG(hostname_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_EMPTY_HOSTNAME)
+ .arg(ex.getQuery()->getLabel());
return;
}
// Copy construct the hostname provided by the client. It is entirely
try {
dhcid = computeDhcid(lease);
} catch (const DhcidComputeError& ex) {
- LOG_ERROR(dhcp4_logger, DHCP4_DHCID_COMPUTE_ERROR)
+ LOG_ERROR(hostname_logger, DHCP4_DHCID_COMPUTE_ERROR)
.arg(lease->toText())
.arg(ex.what());
return;
lease->valid_lft_),
lease->valid_lft_));
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_QUEUE_NCR)
+ LOG_DEBUG(hostname_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_QUEUE_NCR)
.arg(chg_type == CHG_ADD ? "add" : "remove")
.arg(ncr->toText());
/// @todo: move subnet selection to a common code
resp->setSiaddr(subnet->getSiaddr());
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_SUBNET_SELECTED)
- .arg(subnet->toText());
-
// Get client-id. It is not mandatory in DHCPv4.
ClientIdPtr client_id = ex.getContext()->clientid_;
}
} catch (const Exception& ex) {
- LOG_ERROR(dhcp4_logger, DHCP4_NAME_GEN_UPDATE_FAIL)
+ LOG_ERROR(hostname_logger, DHCP4_NAME_GEN_UPDATE_FAIL)
+ .arg(query->getLabel())
+ .arg(lease->hostname_)
.arg(ex.what());
}
}
/// doing class specific processing.
if (!classSpecificProcessing(ex)) {
/// @todo add more verbosity here
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_DISCOVER_CLASS_PROCESSING_FAILED);
+ LOG_DEBUG(options_logger, DBG_DHCP4_DETAIL, DHCP4_DISCOVER_CLASS_PROCESSING_FAILED)
+ .arg(discover->getLabel());
}
return (ex.getResponse());
/// doing class specific processing.
if (!classSpecificProcessing(ex)) {
/// @todo add more verbosity here
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_REQUEST_CLASS_PROCESSING_FAILED);
+ LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_REQUEST_CLASS_PROCESSING_FAILED)
+ .arg(ex.getQuery()->getLabel());
}
return (ex.getResponse());
/// @todo: decide whether we want to add a new hook point for
/// doing class specific processing.
if (!classSpecificProcessing(ex)) {
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_INFORM_CLASS_PROCESSING_FAILED)
+ LOG_DEBUG(options_logger, DBG_DHCP4_DETAIL,
+ DHCP4_INFORM_CLASS_PROCESSING_FAILED)
.arg(inform->getLabel());
}
}
if (!classes.empty()) {
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_BASIC, DHCP4_CLASS_ASSIGNED)
+ LOG_DEBUG(options_logger, DBG_DHCP4_BASIC, DHCP4_CLASS_ASSIGNED)
+ .arg(pkt->getLabel())
.arg(classes);
}
}
Dhcpv4Srv::d2ClientErrorHandler(const
dhcp_ddns::NameChangeSender::Result result,
dhcp_ddns::NameChangeRequestPtr& ncr) {
- LOG_ERROR(dhcp4_logger, DHCP4_DDNS_REQUEST_SEND_FAILED).
+ LOG_ERROR(hostname_logger, DHCP4_DDNS_REQUEST_SEND_FAILED).
arg(result).arg((ncr ? ncr->toText() : " NULL "));
// We cannot communicate with kea-dhcp-ddns, suspend further updates.
/// @todo We may wish to revisit this, but for now we will simply turn
projects / thirdparty / kea.git / commitdiff
