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_NAME_PROC_FAIL failed to process the fqdn or hostname sent by a client: %1
+ % DHCP4_CLIENTID_IGNORED_FOR_LEASES %1: not using client identifier for lease allocation for subnet %2
+ This debug message is issued when the server is processing the DHCPv4 message
+ for which client identifier will not be used when allocating new lease or
+ renewing existing lease. The server is explicitly configured to not use
+ client identifier to lookup existing leases for the client and will not
+ record client identifier in the lease database. This mode of operation
+ is useful when clients don't use stable client identifiers, e.g. multi
+ stage booting. Note that the client identifier may be used for other
+ operations than lease allocation, e.g. identifying host reservations
+ for the client using client identifier. The first argument includes the
+ client and transaction identification information. The second argument
+ specifies the identifier of the subnet where the client is connected
+ and for which this mode of operation is configured on the server.
+
+% DHCP4_CLIENT_FQDN_PROCESS %1: processing Client FQDN option
+This debug message is issued when the server starts processing the Client
+FQDN option sent in the client's query. The argument includes the
+client and transaction identification information.
+
+% DHCP4_CLIENT_FQDN_DATA %1: Client sent FQDN option: %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. 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 processing the Hostname
+option sent in the client's query. The argument includes the client and
+transaction identification information.
+
+% DHCP4_CLIENT_HOSTNAME_DATA %1: client sent Hostname option: %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. The second argument
+specifies the hostname carried in the Hostname option sent by the
+client.
+
+% 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
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.
-
-% DHCP4_RELEASE_FAIL_NO_LEASE client (client-id %1, hwaddr %2) tried to release address, %3, but there is no such lease.
-This warning message is printed when client attempts to release a lease,
-but no such lease is known to the server.
+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,
+but no such lease is known to the server. The first argument contains
+the client and transaction identification information. The second
+argument contains the address which the client is trying to release.
+
- % DHCP4_RELEASE_FAIL_WRONG_CLIENT_ID %1: client tried to release address %2, but this address is leased to different client using client id %3
- 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.
-
- % DHCP4_RELEASE_FAIL_WRONG_HWADDR %1: client tried to release address %2, but this address is leased to different client using HW address %3
- 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. 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_RELEASE_FAIL_WRONG_CLIENT %1: client is trying to release the lease %2 which belongs to a different client
++This debug message is issued when a client is trying to release the
++lease for the address which is currently used by another client, i.e.
++the 'client identifier' or 'chaddr' doesn't match between the client
++and the lease. The first argument includes the client and the
++transaction identification information. The second argument specifies
++the leased address.
+
+% 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
+option in its response to the client. The first argument includes the
+client and transaction identification information. The second argument
+includes the details of the FQDN option being included. Note that the
+name carried in the FQDN option may be modified by the server when
+the lease is acquired for the client.
-% DHCP4_REQUEST_CLASS_PROCESSING_FAILED client class specific processing failed for DHCPREQUEST
+% DHCP4_RESPONSE_HOSTNAME_DATA %1: including Hostname option in the server's response: %2
+This debug message is issued when the server is adding the Hostname
+option in its response to the client. The first argument includes the
+client and transaction identification information. The second argument
+includes the details of the FQDN option being included. Note that the
+name carried in the Hostname option may be modified by the server when
+the lease is acquired for the client.
+
+% DHCP4_RESPONSE_HOSTNAME_GENERATE %1: server has generated hostname %2 for the client
+This debug message includes the auto-generated hostname which will be used
+for the client which message is processed. Hostnames may need to be generated
+when required by the server's configuration or when the client hasn't
+supplied its hostname. The first argument includes the client and the
+transaction identification information. The second argument holds the
+generated hostname.
+
+% DHCP4_REQUEST_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPREQUEST
This debug message means that the server processing that is unique for each
client class has reported a failure. The response packet will not be sent.
+The argument contains the client and transaction identification
+information.
-% DHCP4_RESPONSE_DATA responding with packet type %1, data is <%2>
-A debug message listing the data returned to the client.
+% 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. 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.
/// @todo: move subnet selection to a common code
resp->setSiaddr(subnet->getSiaddr());
- // Get client-id. It is not mandatory in DHCPv4.
- ClientIdPtr client_id = ex.getContext()->clientid_;
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_SUBNET_SELECTED)
- .arg(subnet->toText());
--
// Get the server identifier. It will be used to determine the state
// of the client.
OptionCustomPtr opt_serverid = boost::dynamic_pointer_cast<
// determine whether the client's notion of the address is correct
// and whether the client is known, i.e., has a lease.
if (!fake_allocation && !opt_serverid && opt_requested_address) {
+
+ LOG_DEBUG(lease_logger, DBG_DHCP4_DETAIL, DHCP4_INIT_REBOOT)
+ .arg(query->getLabel())
+ .arg(hint.toText());
+
Lease4Ptr lease;
- if (hwaddr) {
- lease = LeaseMgrFactory::instance().getLease4(*hwaddr,
- subnet->getID());
+ if (client_id) {
+ lease = LeaseMgrFactory::instance().getLease4(*client_id, subnet->getID());
}
- if (!lease && client_id) {
- lease = LeaseMgrFactory::instance().getLease4(*client_id,
- subnet->getID());
+
+ if (!lease && hwaddr) {
+ lease = LeaseMgrFactory::instance().getLease4(*hwaddr, subnet->getID());
}
- // Got a lease so we can check the address.
- if (lease && (lease->addr_ != hint)) {
+
+ // Check the first error case: unknown client. We check this before
+ // validating the address sent because we don't want to respond if
+ // we don't know this client.
- /// @todo The client_id logged here should be the client_id from the message
- /// rather than effective client id which is null when the
- /// match-client-id is set to false. This is addressed by the #3806
- /// which is under review.
+ if (!lease || !lease->belongsToClient(hwaddr, client_id)) {
- LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL,
+ LOG_DEBUG(bad_packet_logger, DBG_DHCP4_DETAIL,
- DHCP4_PACKET_NAK_0002)
+ DHCP4_NO_LEASE_INIT_REBOOT)
- .arg(hint.toText())
- .arg(client_id ? client_id->toText():"(no client-id)")
- .arg(hwaddr ? hwaddr->toText():"(no hwaddr info)");
+ .arg(query->getLabel())
+ .arg(hint.toText());
- resp->setType(DHCPNAK);
- resp->setYiaddr(IOAddress::IPV4_ZERO_ADDRESS());
+ ex.deleteResponse();
return;
}
- // Now check the second error case: unknown client.
- if (!lease) {
+
+ // We know this client so we can now check if his notion of the
+ // IP address is correct.
+ if (lease && (lease->addr_ != hint)) {
LOG_DEBUG(bad_packet_logger, DBG_DHCP4_DETAIL,
- DHCP4_NO_LEASE_INIT_REBOOT)
+ DHCP4_PACKET_NAK_0002)
.arg(query->getLabel())
.arg(hint.toText());
return;
}
- // Does the hardware address match? We don't want one client releasing
- // another client's leases. Note that we're comparing the hardware
- // addresses only, not hardware types or sources of the hardware
- // addresses. Thus we don't use HWAddr::equals().
- if (lease->hwaddr_->hwaddr_ != release->getHWAddr()->hwaddr_) {
- LOG_DEBUG(lease_logger, DBG_DHCP4_DETAIL, DHCP4_RELEASE_FAIL_WRONG_HWADDR)
+ if (!lease->belongsToClient(release->getHWAddr(), client_id)) {
- /// @todo add debug message here when we merge the code with the
- /// changes from #3806.
++ LOG_DEBUG(lease_logger, DBG_DHCP4_DETAIL, DHCP4_RELEASE_FAIL_WRONG_CLIENT)
+ .arg(release->getLabel())
- .arg(release->getCiaddr().toText())
- .arg(lease->hwaddr_->toText(false));
- return;
- }
-
- // Does the lease have client-id info? If it has, then check it with what
- // the client sent us.
- if (lease->client_id_ && client_id && *lease->client_id_ != *client_id) {
- LOG_DEBUG(lease_logger, DBG_DHCP4_DETAIL, DHCP4_RELEASE_FAIL_WRONG_CLIENT_ID)
- .arg(release->getLabel())
- .arg(release->getCiaddr().toText())
- .arg(lease->client_id_->toText());
++ .arg(release->getCiaddr().toText());
return;
}
projects / thirdparty / kea.git / commitdiff
