[3807] Addressed review comments.

Mostly fixing typos and issues in comments and log messages.

diff --git a/src/bin/dhcp4/dhcp4_messages.mes b/src/bin/dhcp4/dhcp4_messages.mes
index 3eb05325a8ecd5ed05b3ffa05ffcfc8d360f77b0..c3942d1416ec94028830002df7ec83f4b959a97e 100644 (file)
--- a/src/bin/dhcp4/dhcp4_messages.mes
+++ b/src/bin/dhcp4/dhcp4_messages.mes
@@ -28,12 +28,12 @@ the message.
 This debug message is logged when the server has received a packet
 over the socket. When the message is logged the contents of the received
 packet hasn't been parsed yet. The only available information is the
-interface and the source and destination addresses/ports.
+interface and the source and destination IPv4 addresses/ports.
 
 % 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. The arguments specify the source and
-destination addresses as well as the interface over which the buffer has
+destination IPv4 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
@@ -43,6 +43,14 @@ 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.
 
+% DHCP4_BUFFER_WAIT_INTERRUPTED interrupted wait for the next packet due to timeout, signal or external socket callback (timeout value is %1)
+This debug message is issued when the server intrrupts waiting
+for reception of the next DHCPv6 message due to timeout, signal
+or reception of the data over socket other than used for DHCPv4
+message transmission. The server will now handle signals
+received and ready timers before waiting for next packets again.
+The argument specifies the timeout value in milliseconds.
+
 % DHCP4_BUFFER_WAIT_SIGNAL signal received while waiting for next packet, next waiting signal is %1
 This debug message is issued when the server was waiting for the
 packet, but the wait has been interrupted by the signal received
@@ -50,12 +58,6 @@ 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 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
 successfully established a session with the Kea control channel.
@@ -183,7 +185,7 @@ 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.
-The arguments specify the source and destination address as well as
+The arguments specify the source and destination IPv4 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.
@@ -230,8 +232,8 @@ information.
 This debug message is issued when the DHCPACK will be sent directly to the
 client, rather than via a relay. The first argument contains the client
 and transaction identification information. The second argument contains
-the client's address to which the response will be sent. The third argument
-contains the local interface name.
+the client's IPv4 address to which the response will be sent. The third
+argument contains the local interface name.
 
 % DHCP4_INIT_FAIL failed to initialize Kea server: %1
 The server has failed to initialize. This may be because the configuration
@@ -240,23 +242,23 @@ Attached error message provides more details about the issue.
 
 % DHCP4_INIT_REBOOT %1: client is in INIT-REBOOT state and requests address %2
 This debug message is issued when the client is in the INIT-REBOOT state and
-is requesting an address it is using to be allocated for it. The first argument
-includes the client and transaction identification information. The second
-argument specifies the requested IP address.
+is requesting an IPv4 address it is using to be allocated for it. The first
+argument includes the client and transaction identification information. The
+second argument specifies the requested IPv4 address.
 
 % 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.
 The first argument specifies the client and the transaction identification
-information. The second argument specifies the address to be offered.
+information. The second argument specifies the IPv4 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. The first argument
 contains the client and the transaction identification information. The
-second argument contains the allocated address.
+second argument contains the allocated IPv4 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
@@ -268,8 +270,8 @@ hasn't been selected.
 % 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. The first argument includes the client and the transaction
+from the acquired IPv4 address. The message argument indicates the reason
+for the failure. The first argument includes the client and the transaction
 identification information. The second argument specifies the hostname.
 The third argument contains the error details.
 
@@ -295,10 +297,10 @@ DHCPv4 server but it is not running.
 
 % 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.
+requested an IPv4 address but this client is unknown. The server will not
+respond. The first argument includes the client and the transaction id
+identification information. The second argument includes the IPv4 address
+requested by the client.
 
 % DHCP4_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
 This warning message is issued when current server configuration specifies
@@ -364,23 +366,23 @@ This error message is output when a packet was received from a subnet
 for which the DHCPv4 server has not been configured. The most probable
 cause is a misconfiguration of the server. The first argument contains
 the client and transaction identification information. The second argument
-contains the source address of the packet. The third argument contains
+contains the source IPv4 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
+requested an IPv4 address which is not assigned to him. The server will respond
 to this client with DHCPNAK. The first argument contains the client and
 the transaction identification information. The second arguments holds the
-address requested by the client.
+IPv4 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. 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
+argument contains the IPv4 address in the ciaddr field. The third
+argument contains the IPv4 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
@@ -388,8 +390,8 @@ This message indicates that the server failed to grant a lease to the
 specified client after receiving a REQUEST message from it.  There are many
 possible reasons for such a failure. Additional messages will indicate the
 reason. The first argument contains the client and the transaction
-identification information. The second argument contains the address in
-the ciaddr field. The third argument contains the IP address in the
+identification information. The second argument contains the IPv4 address
+in the ciaddr field. The third argument contains the IPv4 address in the
 requested-ip-address option (if present).
 
 % DHCP4_PACKET_PACK %1: preparing on-wire format of the packet to be sent
@@ -407,15 +409,16 @@ A debug message noting that the server has received the specified type of
 packet on the specified interface. The first argument specifies the
 client and transaction identification information. The second and third
 argument specify the name of the DHCPv4 message and its numeric type
-respectively. The remaining arguments specify the source address,
-destination IP address and the name of the interface on which the
+respectively. The remaining arguments specify the source IPv4 address,
+destination IPv4 address and the name of the interface on which the
 message has been received.
 
 % DHCP4_PACKET_SEND %1: sending packet %2 (type %3) from %4:%5 to %6:%7 on interface %8
 This debug message is issued when the server is sending the response to
 the client. The arguments specify the client identification information
 (HW address and client identifier), DHCP message name and type, source
-address and port, destination address and port and the interface name.
+IPv4 address and port, destination IPv4 address and port and the
+interface name.
 
 % DHCP4_PACKET_SEND_FAIL %1: failed to send DHCPv4 packet: %2
 This error is output if the DHCPv4 server fails to send an assembled
@@ -470,7 +473,7 @@ 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. The first argument includes
 the client and transaction identification information. The second argument
-includes the released IP address.
+includes the released IPv4 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
@@ -479,7 +482,7 @@ which does not expect any response from the server for DHCPRELEASE
 messages. Depending on the nature of problem, it may affect future
 server operation. The first argument includes the client and the
 transaction identification information. The second argument
-includes the IP address which release was attempted. The last
+includes the IPv4 address which release was attempted. The last
 argument includes the detailed error description.
 
 % DHCP4_RELEASE_FAIL %1: failed to remove lease for address %2
@@ -490,14 +493,15 @@ intervention (e.g. check if DHCP process has sufficient privileges to
 update the database). It may also be triggered if a lease was manually
 removed from the database during RELEASE message processing. The
 first argument includes the client and the transaction identification
-information. The second argument holds the IP address which release
+information. The second argument holds the IPv4 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.
+argument contains the IPv4 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
@@ -513,7 +517,7 @@ 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
+argument includes the IPv4 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

diff --git a/src/bin/dhcp4/dhcp4_srv.cc b/src/bin/dhcp4/dhcp4_srv.cc
index fb0a20cdb32f502b6f8231e00057c40fb223f385..688229b7fd47a2f9d8973f65a033b522f95252a1 100644 (file)
--- a/src/bin/dhcp4/dhcp4_srv.cc
+++ b/src/bin/dhcp4/dhcp4_srv.cc
@@ -355,7 +355,7 @@ Dhcpv4Srv::run() {
                     .arg(query->getIface());
 
             } else {
-                LOG_DEBUG(packet_logger, DBG_DHCP4_DETAIL, DHCP4_BUFFER_WAIT_TIMEOUT)
+                LOG_DEBUG(packet_logger, DBG_DHCP4_DETAIL, DHCP4_BUFFER_WAIT_INTERRUPTED)
                     .arg(timeout);
             }
 

diff --git a/src/bin/dhcp6/dhcp6_messages.mes b/src/bin/dhcp6/dhcp6_messages.mes
index 8ca0dd10adca5c995f0c9054abe7a56a61106884..9f9de5626f50b900f8d81c68f1024f5ffece8b68 100644 (file)
--- a/src/bin/dhcp6/dhcp6_messages.mes
+++ b/src/bin/dhcp6/dhcp6_messages.mes
@@ -50,6 +50,14 @@ 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.
 
+% DHCP6_BUFFER_WAIT_INTERRUPTED interrupted wait for the next packet due to timeout, signal or external socket callback (timeout value is %1)
+This debug message is issued when the server intrrupts waiting
+for reception of the next DHCPv6 message due to timeout, signal
+or reception of the data over socket other than used for DHCPv6
+message transmission. The server will now handle signals
+received and ready timers before waiting for next packets again.
+The argument specifies the timeout value in milliseconds.
+
 % DHCP6_BUFFER_WAIT_SIGNAL signal received while waiting for next packet, next waiting signal is %1
 This debug message is issued when the server was waiting for the
 packet, but the wait has been interrupted by the signal received
@@ -57,12 +65,6 @@ 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.
 
-% DHCP6_BUFFER_WAIT_TIMEOUT timeout %1 ms reached while waiting for the next packet
-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.
-
 % DHCP6_CCSESSION_STARTED control channel session started on socket %1
 A debug message issued during startup after the IPv6 DHCP server has
 successfully established a session with the Kea control channel.
@@ -190,7 +192,7 @@ the lease is acquired for the client.
 This debug message is logged when server includes an DHCPv6 Client FQDN Option
 in its response to the client.
 
-% DHCP6_DDNS_SKIP_REMOVE_NAME_CHANGE_REQUEST %1: skip creating name change request for lease: %2
+% DHCP6_DDNS_SKIP_REMOVE_NAME_CHANGE_REQUEST %1: name change request creation skipped for lease: %2
 This debug message is logged when the server determines that removal
 name change request should not be sent to the DNS, because the DNS
 updates are disabled on the DHCP server, or no DNS update has been
@@ -564,7 +566,7 @@ support for multiple addresses is flawed.
 This debug message indicates that a prefix was released properly. It
 is a normal operation during client shutdown. The first argument holds
 the client and transaction identification information. The second and
-third argument define the prefix and its length. The forth argument
+third argument define the prefix and its length. The fourth argument
 holds IAID.
 
 % DHCP6_RELEASE_PD_FAIL %1: failed to release prefix %2/%3 for iaid=%4
@@ -576,7 +578,7 @@ update the database). It may also be triggered if a lease was manually
 removed from the database during RELEASE message processing. The
 first argument hold the client and transaction identification
 information. The second and third argument define the prefix and
-its length. The forth argument holds the IAID.
+its length. The fourth argument holds the IAID.
 
 % DHCP6_RELEASE_PD_FAIL_WRONG_DUID %1: client tried to release prefix %2/%3, but it belongs to another client (duid=%4)
 This warning message indicates that client tried to release a prefix
@@ -595,7 +597,7 @@ that does belong to it, but the address was expected to be in a different
 IA (identity association) container. This probably means that the client's
 support for multiple prefixes is flawed. The first argument includes the
 client and transaction identification information. The second and third
-argument identify the prefix. The forth and fifth argument hold the
+argument identify the prefix. The fourth and fifth argument hold the
 expected IAID and IAID found respectively.
 
 % DHCP6_REQUIRED_OPTIONS_CHECK_FAIL %1 message received from %2 failed the following check: %3
@@ -681,7 +683,7 @@ is running.
 % DHCP6_SUBNET_DATA %1: the selected subnet details: %2
 This debug message includes the details of the subnet selected for
 the client. The first argument includes the client and the
-transaction identification information. The second arguments
+transaction identification information. The second argument
 includes the subnet details.
 
 % DHCP6_SUBNET_SELECTED %1: the subnet with ID %2 was selected for client assignments

diff --git a/src/bin/dhcp6/dhcp6_srv.cc b/src/bin/dhcp6/dhcp6_srv.cc
index 806c1a34a9b4dbea6df2426636f8603da1598f16..9adda172d2f59586bea4611c0628799884a09473 100644 (file)
--- a/src/bin/dhcp6/dhcp6_srv.cc
+++ b/src/bin/dhcp6/dhcp6_srv.cc
@@ -99,7 +99,7 @@ struct Dhcp6Hooks {
 // module is called.
 Dhcp6Hooks Hooks;
 
-/// @brief Creates instanace of the Status Code option.
+/// @brief Creates instance of the Status Code option.
 ///
 /// This variant of the function is used when the Status Code option
 /// is added as a top-level option. It logs the debug message and
@@ -121,7 +121,7 @@ createStatusCode(const Pkt6& pkt, const uint16_t status_code,
     return (option_status);
 }
 
-/// @brief Creates instanace of the Status Code option.
+/// @brief Creates instance of the Status Code option.
 ///
 /// This variant of the function is used when the Status Code option
 /// is added to one of the IA options. It logs the debug message and
@@ -325,7 +325,7 @@ bool Dhcpv6Srv::run() {
                     .arg(query->getIface());
 
             } else {
-                LOG_DEBUG(packet_logger, DBG_DHCP6_DETAIL, DHCP6_BUFFER_WAIT_TIMEOUT)
+                LOG_DEBUG(packet_logger, DBG_DHCP6_DETAIL, DHCP6_BUFFER_WAIT_INTERRUPTED)
                     .arg(timeout);
             }
 
@@ -1506,8 +1506,9 @@ Dhcpv6Srv::assignIA_PD(const Pkt6Ptr& query,
                        boost::shared_ptr<Option6IA> ia) {
 
     // Check if the client sent us a hint in his IA_PD. Clients may send an
-    // address in their IA_NA options as a suggestion (e.g. the last address
-    // they used before).
+    // address in their IA_PD options as a suggestion (e.g. the last address
+    // they used before). While the hint consists of a full prefix (prefix +
+    // length), getting just the prefix is sufficient to identify a lease.
     Option6IAPrefixPtr hint_opt =
         boost::dynamic_pointer_cast<Option6IAPrefix>(ia->getOption(D6O_IAPREFIX));
     IOAddress hint = IOAddress::IPV6_ZERO_ADDRESS();
@@ -1851,7 +1852,7 @@ Dhcpv6Srv::extendIA_PD(const Pkt6Ptr& query,
         if (!prf) {
             // That's weird. Option code was ok, but the object type was not.
             // As we use Dhcpv6Srv::unpackOptions() that is guaranteed to use
-            // Option6IAAddr for D6O_IAPREFIX, this should never happen. The only
+            // Option6IAPrefix for D6O_IAPREFIX, this should never happen. The only
             // case would be with badly mis-implemented hook libraries that
             // insert invalid option objects. There's no way to protect against
             // this.