dhcp4_messages.mes 45.5 KB
Newer Older
1
# Copyright (C) 2012-2019 Internet Systems Consortium, Inc. ("ISC")
2
#
3 4 5
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
6 7 8

$NAMESPACE isc::dhcp

9 10 11 12 13
% DHCP4_ACTIVATE_INTERFACE activating interface %1
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.

14 15 16 17 18 19 20 21
% DHCP4_ALREADY_RUNNING %1 already running? %2
This is an error message that occurs when the DHCPv4 server encounters
a pre-existing PID file which contains the PID of a running process.
This most likely indicates an attempt to start a second instance of
the server using the same configuration file.  It is possible, though
unlikely that the PID file is a remnant left behind by a server crash or
power failure and the PID it contains refers to a process other than
the server.  In such an event, it would be necessary to manually remove
22
the PID file.  The first argument is the DHCPv4 process name, the
23
second contains the PID and PID file.
24

25
% DHCP4_BUFFER_RECEIVED received buffer from %1:%2 to %3:%4 over interface %5
26
This debug message is logged when the server has received a packet
27 28
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
29
interface and the source and destination IPv4 addresses/ports.
30

31 32 33 34 35
% DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: %1
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.

36
% DHCP4_BUFFER_UNPACK parsing buffer received from %1 to %2 over interface %3
37
This debug message is issued when the server starts parsing the received
38
buffer holding the DHCPv4 message. The arguments specify the source and
39
destination IPv4 addresses as well as the interface over which the buffer has
40
been received.
41 42

% DHCP4_BUFFER_WAIT_SIGNAL signal received while waiting for next packet, next waiting signal is %1
43 44 45 46 47
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.
48

49
% DHCP4_CB_FETCH_UPDATES_FAIL error on attempt to fetch configuration updates from the configuration backend(s): %1
50 51
This error message is issued when the server attempted to fetch
configuration updates from the database and this attempt failed.
52 53 54
The server will re-try according to the configured value of the
config-fetch-wait-time parameter. The sole argument contains the
reason for failure.
55

56 57 58 59 60 61 62
% DHCP4_CB_FETCH_UPDATES_RETRIES_EXHAUSTED maximum number of configuration fetch attempts: 10, has been exhausted without success
This error indicates that the server has made a number of unsuccessful
attempts to fetch configuration updates from a configuration backend.
The server will continue to operate but won't make any further attempts
to fetch configuration updates. The administrator must fix the configuration
in the database and reload (or restart) the server.

63 64 65 66 67 68
% DHCP4_CB_PULL_FAIL error on pull configuration updates from the configuration backend(s): %1
This error message is issued when the server attempted to pull
configuration updates from the database and this attempt failed.
The sole argument which is returned to the config-backend-pull command
caller too contains the reason for failure.

69
% DHCP4_CLASS_ASSIGNED %1: client packet has been assigned to the following class(es): %2
70
This debug message informs that incoming packet has been assigned to specified
Francis Dupont's avatar
Francis Dupont committed
71
class or classes. This is a normal behavior and indicates successful operation.
72 73 74
The first argument specifies the client and transaction identification
information. The second argument includes all classes to which the
packet has been assigned.
75

Shawn Routhier's avatar
Shawn Routhier committed
76
% DHCP4_CLASS_UNCONFIGURED %1: client packet belongs to an unconfigured class: %2
77 78 79 80
This debug message informs that incoming packet belongs to a class
which cannot be found in the configuration. Either a hook written
before the classification was added to Kea is used, or class naming is
inconsistent.
81

82 83
% DHCP4_CLASS_UNDEFINED required class %1 has no definition
This debug message informs that a class is listed for required evaluation but
Francis Dupont's avatar
Francis Dupont committed
84 85
has no definition.

86 87
% DHCP4_CLASS_UNTESTABLE required class %1 has no test expression
This debug message informs that a class was listed for required evaluation but
Francis Dupont's avatar
Francis Dupont committed
88 89
its definition does not include a test expression to evaluate.

90 91 92 93 94 95 96
% 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
97 98 99 100
stage booting. 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.
101

102
% DHCP4_CLIENT_FQDN_DATA %1: Client sent FQDN option: %2
103 104
This debug message includes the detailed information extracted from the
Client FQDN option sent in the query. The first argument includes the
105 106 107
client and transaction identification information. The second argument
specifies the detailed information about the FQDN option received
by the server.
108

109 110 111 112
% 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.
113

114
% DHCP4_CLIENT_HOSTNAME_DATA %1: client sent Hostname option: %2
115 116
This debug message includes the detailed information extracted from the
Hostname option sent in the query. The first argument includes the
117 118 119
client and transaction identification information. The second argument
specifies the hostname carried in the Hostname option sent by the
client.
120

121 122 123 124
% DHCP4_CLIENT_HOSTNAME_MALFORMED %1: client hostname option malformed: %2
This debug message is issued when the DHCP server was unable to process the
the hostname option sent by the client because the content is malformed.
The first argument includes the client and transaction identification
125
information. The second argument contains a description of the data error.
126

127 128 129 130 131
% 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.

132
% DHCP4_CLIENT_NAME_PROC_FAIL %1: failed to process the fqdn or hostname sent by a client: %2
133 134
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
135 136 137
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.
138

139
% DHCP4_COMMAND_RECEIVED received command %1, arguments: %2
140
A debug message listing the command (and possible arguments) received
141
from the Kea control system by the DHCPv4 server.
142

143 144 145 146 147 148
% DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: %1
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.

149 150 151 152
% DHCP4_CONFIG_FETCH Fetching configuration data from config backends.
This is an informational message emitted when the DHCPv4 server about to begin
retrieving configuration data from one or more configuration backends.

153 154 155 156 157
% DHCP4_CONFIG_LOAD_FAIL configuration error using file: %1, reason: %2
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.
158

159
% DHCP4_CONFIG_NEW_SUBNET a new subnet has been added to configuration: %1
Jeremy C. Reed's avatar
Jeremy C. Reed committed
160 161
This is an informational message reporting that the configuration has
been extended to include the specified IPv4 subnet.
162

163 164 165 166
% DHCP4_CONFIG_OPTION_DUPLICATE multiple options with the code %1 added to the subnet %2
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.
167

168
% DHCP4_CONFIG_PACKET_QUEUE DHCPv4 packet queue info after configuration: %1
169 170 171
This informational message is emitted during DHCPv4 server configuration,
immediately after configuring the DHCPv4 packet queue.  The information
shown depends upon the packet queue type selected.
172

173 174 175 176
% DHCP4_CONFIG_RECEIVED received configuration %1
A debug message listing the configuration received by the DHCPv4 server.
The source of that configuration depends on used configuration backend.

177 178
% DHCP4_CONFIG_START DHCPv4 server is processing the following configuration: %1
This is a debug message that is issued every time the server receives a
179
configuration. That happens at start up and also when a server configuration
180 181
change is committed by the administrator.

182 183
% DHCP4_CONFIG_UNSUPPORTED_OBJECT DHCPv4 server configuration includes an unsupported object: %1
This error message is issued when the configuration includes an unsupported
184 185
object (i.e. a top level element).

186
% DHCP4_CONFIG_UPDATE updated configuration received: %1
187
A debug message indicating that the DHCPv4 server has received an
188
updated configuration from the Kea configuration system.
189

190 191 192 193 194
% DHCP4_DB_RECONNECT_ATTEMPT_FAILED database reconnect failed: %1
An error message indicating that an attempt to reconnect to the lease and/or
host data bases has failed.  This occurs after connectivity to either one
has been lost and an automatic attempt to reconnect has failed.

195
% DHCP4_DB_RECONNECT_ATTEMPT_SCHEDULE scheduling attempt %1 of %2 in %3 milliseconds
196 197
An informational message indicating that the server is scheduling the next
attempt to reconnect to its lease and/or host databases.  This occurs when the
198
server has lost databse connectivity and is attempting to reconnect
199 200
automatically.

201 202 203
% DHCP4_DB_RECONNECT_DISABLED database reconnect is disabled: max-reconnect-tries %1, reconnect-wait-time %2
This is an informational message indicating that connectivity to either the
lease or host database or both and that automatic reconnect is not enabled.
204 205 206 207 208

% DHCP4_DB_RECONNECT_NO_DB_CTL unexpected error in database reconnect
This is an error message indicating a programmatic error that should not
occur. It will prohibit the server from attempting to reconnect to its
databases if connectivy is lost, and the server will exit. This error
209
should be reported.
210

211 212
% DHCP4_DB_RECONNECT_RETRIES_EXHAUSTED maximum number of database reconnect attempts: %1, has been exhausted without success, server is shutting down!
This error indicates that the server is shutting down after failing to reconnect to
213
the lease and/or host database(s) after making the maximum configured number
214 215 216
of reconnect attempts.  Loss of connectivity is typically a network or database
server issue.

217
% DHCP4_DDNS_REQUEST_SEND_FAILED failed sending a request to kea-dhcp-ddns, error: %1,  ncr: %2
218
This error message indicates that DHCP4 server attempted to send a DDNS
Francis Dupont's avatar
Francis Dupont committed
219
update request to the DHCP-DDNS server.  This is most likely a configuration or
220 221
networking error.

222 223 224 225 226
% DHCP4_DEACTIVATE_INTERFACE deactivate interface %1
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.

Tomek Mrugalski's avatar
Tomek Mrugalski committed
227
% DHCP4_DECLINE_LEASE Received DHCPDECLINE for addr %1 from client %2. The lease will be unavailable for %3 seconds.
228
This informational message is printed when a client received an address, but
229 230 231
discovered that it is being used by some other device and notified the server by
sending a DHCPDECLINE message. The server checked that this address really was
leased to the client and marked this address as unusable for a certain
232 233 234
amount of time. This message may indicate a misconfiguration in a network,
as there is either a buggy client or more likely a device that is using an
address that it is not supposed to. The server will fully recover from this
235
situation, but if the underlying problem of a misconfigured or rogue device
236 237
is not solved, this address may be declined again in the future.

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

244 245 246 247 248 249
% DHCP4_DECLINE_LEASE_NOT_FOUND Received DHCPDECLINE for addr %1 from client %2, but no such lease found.
This warning message indicates that a client reported that his address was
detected as a duplicate (i.e. another device in the network is using this address).
However, the server does not have a record for this address. This may indicate
a client's error or a server's purged database.

250 251 252
% DHCP4_DHCP4O6_BAD_PACKET received malformed DHCPv4o6 packet: %1
A malformed DHCPv4o6 packet was received.

Andrei Pavel's avatar
Andrei Pavel committed
253 254 255 256
% DHCP4_DHCP4O6_PACKET_RECEIVED received DHCPv4o6 packet from DHCPv4 server (type %1) for %2 on interface %3
This debug message is printed when the server is receiving a DHCPv4o6
from the DHCPv4 server over inter-process communication.

Francis Dupont's avatar
Francis Dupont committed
257
% DHCP4_DHCP4O6_PACKET_SEND %1: trying to send packet %2 (type %3) to %4 port %5 on interface %6 encapsulating %7: %8 (type %9)
258
The arguments specify the client identification information (HW address
Francis Dupont's avatar
Francis Dupont committed
259
and client identifier), DHCPv6 message name and type, source IPv6
Francis Dupont's avatar
Francis Dupont committed
260 261
address and port, and interface name, DHCPv4 client identification,
message name and type.
262 263 264 265 266 267 268 269 270 271 272 273 274

% DHCP4_DHCP4O6_PACKET_SEND_FAIL %1: failed to send DHCPv4o6 packet: %2
This error is output if the IPv4 DHCP server fails to send an
DHCPv4o6 message to the IPv6 DHCP server. The reason for the
error is included in the message.

% DHCP4_DHCP4O6_RECEIVE_FAIL failed to receive DHCPv4o6: %1
This debug message indicates the inter-process communication with the
DHCPv6 server failed. The reason for the error is included in
the message.

% DHCP4_DHCP4O6_RECEIVING receiving DHCPv4o6 packet from DHCPv6 server
This debug message is printed when the server is receiving a DHCPv4o6
275
from the DHCPv6 server over inter-process communication socket.
276 277 278 279 280 281 282 283 284

% DHCP4_DHCP4O6_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 DHCPv6 server to be forwarded 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.

285
% DHCP4_DYNAMIC_RECONFIGURATION initiate server reconfiguration using file: %1, after receiving SIGHUP signal or config-reload command
286
This is the info message logged when the DHCPv4 server starts reconfiguration
287
as a result of receiving SIGHUP signal or config-reload command.
288 289 290 291 292

% DHCP4_DYNAMIC_RECONFIGURATION_FAIL dynamic server reconfiguration failed with file: %1
This is an error message logged when the dynamic reconfiguration of the
DHCP server failed.

293
% DHCP4_EMPTY_HOSTNAME %1: received empty hostname from the client, skipping processing of this option
294 295
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
296 297
option is skipped. The argument holds the client and transaction identification
information.
298

299 300 301
% DHCP4_FLEX_ID flexible identifier generated for incoming packet: %1
This debug message is printed when host reservation type is set to flexible identifier
and the expression specified in its configuration generated (was evaluated to)
Francis Dupont's avatar
Francis Dupont committed
302
an identifier for incoming packet. This debug message is mainly intended as a
303 304
debugging assistance for flexible identifier.

305 306 307 308 309
% DHCP4_GENERATE_FQDN %1: client did not send a FQDN or hostname; FQDN will be be generated for the client
This debug message is issued when the server did not receive a Hostname option
from the client and hostname generation is enabled.  This provides a means to
create DNS entries for unsophisticated clients.

Tomek Mrugalski's avatar
Tomek Mrugalski committed
310 311
% DHCP4_HANDLE_SIGNAL_EXCEPTION An exception was thrown while handing signal: %1
This error message is printed when an ISC or standard exception was raised during signal
312 313
processing. This likely indicates a coding error and should be reported to ISC.

314 315 316 317 318
% DHCP4_HOOKS_LIBS_RELOAD_FAIL reload of hooks libraries failed
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.

319
% DHCP4_HOOK_BUFFER_RCVD_DROP received buffer from %1 to %2 over interface %3 was dropped because a callout set the drop flag
320
This debug message is printed when a callout installed on buffer4_receive
321
hook point set the drop flag. For this particular hook point, the
322
setting of the flag by a callout instructs the server to drop the packet.
323
The arguments specify the source and destination IPv4 address as well as
324
the name of the interface over which the buffer has been received.
325

326
% DHCP4_HOOK_BUFFER_RCVD_SKIP received buffer from %1 to %2 over interface %3 is not parsed because a callout set the next step to SKIP.
327
This debug message is printed when a callout installed on
328 329
buffer4_receive hook point set the next step to SKIP. For this particular hook
point, this value set by a callout instructs the server to
330 331 332 333
not parse the buffer because it was already parsed by the hook. The
arguments specify the source and destination IPv4 address as well as
the name of the interface over which the buffer has been received.

334
% DHCP4_HOOK_BUFFER_SEND_SKIP %1: prepared response is dropped because a callout set the next step to SKIP.
335
This debug message is printed when a callout installed on buffer4_send
336 337
hook point set the next step to SKIP. For this particular hook point, the
SKIP value set by a callout instructs the server to drop the packet.
338 339 340
Server completed all the processing (e.g. may have assigned, updated
or released leases), but the response will not be send to the client.

341 342 343 344 345 346 347
% DHCP4_HOOK_DECLINE_SKIP Decline4 hook callouts set status to DROP, ignoring packet.
This message indicates that the server received DHCPDECLINE message, it was verified
to be correct and matching server's lease information. The server called hooks
for decline4 hook point and one of the callouts set next step status to DROP.
The server will now abort processing of the packet as if it was never
received. The lease will continue to be assigned to this client.

348
% DHCP4_HOOK_LEASE4_RELEASE_SKIP %1: lease was not released because a callout set the next step to SKIP
349
This debug message is printed when a callout installed on lease4_release
350 351
hook point set the next step status to SKIP. For this particular hook point, the
value set by a callout instructs the server to not release a lease.
352

353
% DHCP4_HOOK_LEASES4_COMMITTED_DROP %1: packet is dropped, because a callout set the next step to DROP
354 355 356
This debug message is printed when a callout installed on the leases4_committed
hook point sets the next step to DROP.

357 358 359 360
% DHCP4_HOOK_LEASES4_COMMITTED_PARK %1: packet is parked, because a callout set the next step to PARK
This debug message is printed when a callout installed on the lease4_committed
hook point sets the next step to PARK.

361
% DHCP4_HOOK_PACKET_RCVD_SKIP %1: packet is dropped, because a callout set the next step to SKIP
362
This debug message is printed when a callout installed on the pkt4_receive
363 364
hook point sets the next step to SKIP. For this particular hook point, the
value setting of the flag instructs the server to drop the packet.
365

366
% DHCP4_HOOK_PACKET_SEND_SKIP %1: prepared response is not sent, because a callout set the next stp to SKIP
367
This debug message is printed when a callout installed on the pkt4_send
368 369
hook point sets the next step to SKIP. For this particular hook point, this
setting instructs the server to drop the packet. This means that
370 371 372
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).

373
% DHCP4_HOOK_SUBNET4_SELECT_DROP %1: packet was dropped, because a callout set the next step to 'drop'
374
This debug message is printed when a callout installed on the
375 376
subnet4_select hook point sets the next step to 'drop' value. For this particular hook
point, the setting to that value instructs the server to drop the received
377 378 379
packet. The argument specifies the client and transaction identification
information.

380
% DHCP4_HOOK_SUBNET4_SELECT_SKIP %1: no subnet was selected, because a callout set the next skip flag
381
This debug message is printed when a callout installed on the
382
subnet4_select hook point sets the next step to SKIP value. For this particular hook
383 384 385
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.
386 387
The argument specifies the client and transaction identification
information.
388

389
% DHCP4_INFORM_DIRECT_REPLY %1: DHCPACK in reply to the DHCPINFORM will be sent directly to %2 over %3
390 391 392
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
393 394
the client's IPv4 address to which the response will be sent. The third
argument contains the local interface name.
395

396 397 398 399 400
% DHCP4_INIT_FAIL failed to initialize Kea server: %1
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.

401
% DHCP4_INIT_REBOOT %1: client is in INIT-REBOOT state and requests address %2
402 403 404 405
This informational message is issued when the client is in the INIT-REBOOT
state and is requesting an IPv4 address it is using to be allocated for it.
The first argument includes the client and transaction identification
information. The second argument specifies the requested IPv4 address.
406

407
% DHCP4_LEASE_ADVERT %1: lease %2 will be advertised
408
This informational message indicates that the server has found the lease to be
409
offered to the client. It is up to the client to choose one server out of
410 411
those which offered leases and continue allocation with that server.
The first argument specifies the client and the transaction identification
412
information. The second argument specifies the IPv4 address to be offered.
413

414
% DHCP4_LEASE_ALLOC %1: lease %2 has been allocated for %3 seconds
415 416 417 418
This informational 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
419 420
contains the allocated IPv4 address. The third argument is the validity
lifetime.
421

422
% DHCP4_NCR_CREATE %1: DDNS updates enabled, therefore sending name change requests
423
This debug message is issued when the server is starting to send
424 425
name change requests to the D2 module to update records for the client
in the DNS. This includes removal of old records and addition of the
426 427 428
new records as required. Details of the name change requests will be
logged in additional log entries. The argument includes the client
and the transaction identification information.
429 430

% DHCP4_NCR_CREATION_FAILED %1: failed to generate name change requests for DNS: %2
431
This message indicates that server was unable to generate NameChangeRequests
432
which should be sent to the kea-dhcp_ddns module to create
433
new DNS records for the lease being acquired or to update existing records
434 435
for the renewed lease. The first argument contains the client and transaction
identification information. The second argument includes the reason for the
436
failure.
437

438 439 440 441
% DHCP4_NOT_RUNNING DHCPv4 server is not running
A warning message is issued when an attempt is made to shut down the
DHCPv4 server but it is not running.

442
% DHCP4_NO_LEASE_INIT_REBOOT %1: no lease for address %2 requested by INIT-REBOOT client
443
This debug message is issued when the client being in the INIT-REBOOT state
444 445 446 447
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.
448

449 450 451 452 453
% DHCP4_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
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.

454 455 456 457 458
% DHCP4_OPEN_CONFIG_DB Opening configuration database: %1
This message is printed when the DHCPv4 server is attempting to open a
configuration database.  The database access string with password redacted
is logged.

459
% DHCP4_OPEN_SOCKET opening service sockets on port %1
460
A debug message issued during startup, this indicates that the DHCPv4
461
server is about to open sockets on the specified port.
462

463
% DHCP4_OPEN_SOCKET_FAIL failed to open socket: %1
464 465 466
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.

Vincent Legout's avatar
Vincent Legout committed
467
% DHCP4_PACKET_DROP_0001 failed to parse packet from %1 to %2, received over interface %3, reason: %4
468 469 470
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.

471
% DHCP4_PACKET_DROP_0002 %1, from interface %2: no suitable subnet configured for a direct client
472 473 474 475 476
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.
477

478
% DHCP4_PACKET_DROP_0003 %1, from interface %2: it contains a foreign server identifier
479 480
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
481 482 483
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.
484

485
% DHCP4_PACKET_DROP_0004 %1, from interface %2: missing msg-type option
486
This is a debug message informing that incoming DHCPv4 packet did not
487 488 489
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.
490

491
% DHCP4_PACKET_DROP_0005 %1: unrecognized type %2 in option 53
492 493 494
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.
495 496 497
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.
498

499
% DHCP4_PACKET_DROP_0006 %1: unsupported DHCPv4 message type %2
500 501
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
502 503 504
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.
505

506
% DHCP4_PACKET_DROP_0007 %1: failed to process packet: %2
507 508
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
509 510 511
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.
512

513 514 515 516 517 518
% DHCP4_PACKET_DROP_0008 %1: DHCP service is globally disabled
This debug message is issued when a packet is dropped because the DHCP service
has been temporarily disabled. This affects all received DHCP packets. The
service may be enabled by the "dhcp-enable" control command or automatically
after a specified amount of time since receiving "dhcp-disable" command.

519 520 521 522 523
% DHCP4_PACKET_DROP_0009 %1: Option 53 missing (no DHCP message type), is this a BOOTP packet?
This debug message is issued when a packet is dropped because it did contain
option 53 and thus has no DHCP message type. The most likely explanation is
that it was BOOTP packet.

524 525 526
% DHCP4_PACKET_DROP_0010 dropped as member of the special class 'DROP': %1
This debug message is emitted when an incoming packet was classified
into the special class 'DROP' and dropped. The packet details are displayed.
527

528
% DHCP4_PACKET_NAK_0001 %1: failed to select a subnet for incoming packet, src %2, type %3
529
This error message is output when a packet was received from a subnet
530
for which the DHCPv4 server has not been configured. The most probable
531 532
cause is a misconfiguration of the server. The first argument contains
the client and transaction identification information. The second argument
533
contains the source IPv4 address of the packet. The third argument contains
534
the name of the received packet.
535

536
% DHCP4_PACKET_NAK_0002 %1: invalid address %2 requested by INIT-REBOOT
537
This debug message is issued when the client being in the INIT-REBOOT state
538
requested an IPv4 address which is not assigned to him. The server will respond
539 540
to this client with DHCPNAK. The first argument contains the client and
the transaction identification information. The second arguments holds the
541
IPv4 address requested by the client.
542

543
% DHCP4_PACKET_NAK_0003 %1: failed to advertise a lease, client sent ciaddr %2, requested-ip-address %3
544 545
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
546 547
many possible reasons for such a failure. The first argument contains
the client and the transaction identification information. The second
548 549
argument contains the IPv4 address in the ciaddr field. The third
argument contains the IPv4 address in the requested-ip-address option
550
(if present).
551

552
% DHCP4_PACKET_NAK_0004 %1: failed to grant a lease, client sent ciaddr %2, requested-ip-address %3
553 554 555
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
556
reason. The first argument contains the client and the transaction
557 558
identification information. The second argument contains the IPv4 address
in the ciaddr field. The third argument contains the IPv4 address in the
559
requested-ip-address option (if present).
560

561 562 563 564 565
% DHCP4_PACKET_OPTIONS_SKIPPED An error upacking an option, caused subsequent options to be skipped: %1
A debug message issued when an option failed to unpack correctly, making it
impossible to unpack the remaining options in the packet.  The server will
server will still attempt to service the packet.

566 567 568
% 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
569
the client and the transaction identification information.
570 571 572 573 574 575

% 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
has failed. The first argument identifies the client and the DHCP transaction.
The second argument includes the error string.

576 577 578 579 580 581 582 583 584 585 586
% DHCP4_PACKET_PROCESS_EXCEPTION exception occurred during packet processing
This error message indicates that a non-standard exception was raised
during packet processing that was not caught by other, more specific
exception handlers. This packet will be dropped and the server will
continue operation.

% DHCP4_PACKET_PROCESS_STD_EXCEPTION exception occurred during packet processing: %1
This error message indicates that a standard exception was raised
during packet processing that was not caught by other, more specific
exception handlers. This packet will be dropped and the server will
continue operation.
587

588
% DHCP4_PACKET_RECEIVED %1: %2 (type %3) received from %4 to %5 on interface %6
589
A debug message noting that the server has received the specified type of
590 591 592
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
593 594
respectively. The remaining arguments specify the source IPv4 address,
destination IPv4 address and the name of the interface on which the
595
message has been received.
596

597
% DHCP4_PACKET_SEND %1: trying to send packet %2 (type %3) from %4:%5 to %6:%7 on interface %8
598 599 600 601 602
The arguments specify the client identification information (HW address
and client identifier), DHCP message name and type, source IPv4
address and port, destination IPv4 address and port and the
interface name.

603
This debug message is issued when the server is trying to send the
Shawn Routhier's avatar
Shawn Routhier committed
604
response to the client. When the server is using an UDP socket
605
to send the packet there are cases when this operation may be
Shawn Routhier's avatar
Shawn Routhier committed
606 607 608
unsuccessful and no error message will be displayed. One such situation
occurs when the server is unicasting the response to the 'ciaddr' of
a DHCPINFORM message. This often requires broadcasting an ARP
609 610
message to obtain the link layer address of the unicast destination.
If broadcast ARP messages are blocked in the network, according to
Shawn Routhier's avatar
Shawn Routhier committed
611 612
the firewall policy, the ARP message will not cause a response.
Consequently, the response to the DHCPINFORM will not be sent.
613 614
Since the ARP communication is under the OS control, Kea is not
notified about the drop of the packet which it is trying to send
Shawn Routhier's avatar
Shawn Routhier committed
615
and it has no means to display an error message.
616

617
% DHCP4_PACKET_SEND_FAIL %1: failed to send DHCPv4 packet: %2
618
This error is output if the DHCPv4 server fails to send an assembled
619 620 621
DHCP message to a client. The first argument includes the client and
the transaction identification information. The second argument includes
the reason for failure.
622

623
% DHCP4_PARSER_COMMIT_EXCEPTION parser failed to commit changes
624
On receipt of message containing details to a change of the DHCPv4
625 626 627 628 629
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.

% DHCP4_PARSER_COMMIT_FAIL parser failed to commit changes: %1
630
On receipt of message containing details to a change of the DHCPv4
631 632 633 634
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.

635
% DHCP4_PARSER_EXCEPTION failed to create or run parser for configuration element %1
636
On receipt of message containing details to a change of its configuration,
637
the DHCPv4 server failed to create a parser to decode the contents of
638 639
the named configuration element, or the creation succeeded but the parsing
actions and committal of changes failed.  The message has been output in
640
response to a non-Kea exception being raised.  Additional messages
641 642
may give further information.

643 644
% DHCP4_PARSER_FAIL failed to create or run parser for configuration element %1: %2
On receipt of message containing details to a change of its configuration,
645
the DHCPv4 server failed to create a parser to decode the contents
646 647 648 649
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.

650 651 652 653 654 655 656
% DHCP4_POST_ALLOCATION_NAME_UPDATE_FAIL %1: failed to update hostname %2 in a lease after address allocation: %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
or reserved for the client belonging to a shared network. The latter is
the case when the server dynamically switches to another subnet (than
initially selected for allocation) from the same shared network.

657 658 659 660
% 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.
661

662
% DHCP4_RELEASE %1: address %2 was released properly.
663
This informational message indicates that an address was released properly. It
664 665
is a normal operation during client shutdown. The first argument includes
the client and transaction identification information. The second argument
666
includes the released IPv4 address.
667

Jeremy C. Reed's avatar
Jeremy C. Reed committed
668
% DHCP4_RELEASE_EXCEPTION %1: while trying to release address %2 an exception occurred: %3
669
This message is output when an error was encountered during an attempt
670 671
to process a DHCPRELEASE message. The error will not affect the client,
which does not expect any response from the server for DHCPRELEASE
672
messages. Depending on the nature of problem, it may affect future
673 674
server operation. The first argument includes the client and the
transaction identification information. The second argument
675
includes the IPv4 address which release was attempted. The last
676
argument includes the detailed error description.
677

678
% DHCP4_RELEASE_FAIL %1: failed to remove lease for address %2
679 680 681 682 683
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
684 685
removed from the database during RELEASE message processing. The
first argument includes the client and the transaction identification
686
information. The second argument holds the IPv4 address which release
687
was attempted.
688

689 690 691 692
% 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
693 694
argument contains the IPv4 address which the client is trying to
release.
695

696 697 698 699 700 701 702
% 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.
703

704
% DHCP4_RESERVED_HOSTNAME_ASSIGNED %1: server assigned reserved hostname %2
705
This debug message is issued when the server found a hostname reservation
706 707 708 709
for a client and uses this reservation in a hostname option sent back
to this client. The reserved hostname is qualified with a value
of 'qualifying-suffix' parameter, if this parameter is specified.

710 711 712 713 714 715 716
% 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.

717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740
% 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_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.

741
% DHCP4_SERVER_FAILED server failed: %1
742
The DHCPv4 server has encountered a fatal error and is terminating.
743 744
The reason for the failure is included in the message.

745
% DHCP4_SHUTDOWN server shutdown
746
The DHCPv4 server has terminated normally.
747 748

% DHCP4_SHUTDOWN_REQUEST shutdown of server requested
749
This debug message indicates that a shutdown of the DHCPv4 server has
750 751
been requested via a call to the 'shutdown' method of the core Dhcpv4Srv
object.
752 753

% DHCP4_SRV_CONSTRUCT_ERROR error creating Dhcpv4Srv object, reason: %1
754
This error message indicates that during startup, the construction of a
755
core component within the DHCPv4 server (the Dhcpv4 server object)
756 757
has failed.  As a result, the server will exit.  The reason for the
failure is given within the message.
758

759
% DHCP4_SRV_D2STOP_ERROR error stopping IO with DHCP_DDNS during shutdown: %1
Jeremy C. Reed's avatar
Jeremy C. Reed committed
760
This error message indicates that during shutdown, an error occurred while
761 762 763 764
stopping IO between the DHCPv4 server and the DHCP_DDNS server.  This is
probably due to a programmatic error is not likely to impact either server
upon restart.  The reason for the failure is given within the message.

765 766 767 768 769 770
% DHCP4_SRV_DHCP4O6_ERROR error stopping IO with DHCPv4o6 during shutdown: %1
This error message indicates that during shutdown, an error occurred while
stopping IO between the DHCPv4 server and the DHCPv6o6 server.  This is
probably due to a programmatic error is not likely to impact either server
upon restart.  The reason for the failure is given within the message.

771 772 773 774 775
% DHCP4_STARTED Kea DHCPv4 server version %1 started
This informational message indicates that the DHCPv4 server has
processed all configuration information and is ready to process
DHCPv4 packets.  The version is also printed.

776
% DHCP4_STARTING Kea DHCPv4 server version %1 starting
777
This informational message indicates that the DHCPv4 server has
778 779
processed any command-line switches and is starting. The version
is also printed.
780

781
% DHCP4_START_INFO pid: %1, server port: %2, client port: %3, verbose: %4
782
This is a debug message issued during the DHCPv4 server startup.
783 784
It lists some information about the parameters with which the server
is running.
785

786
% DHCP4_SUBNET_DATA %1: the selected subnet details: %2
787
This debug message includes the details of the subnet selected for
788 789 790 791
the client. The first argument includes the client and the
transaction identification information. The second arguments
includes the subnet details.

792 793 794 795 796 797 798 799
% DHCP4_SUBNET_DYNAMICALLY_CHANGED %1: changed selected subnet %2 to subnet %3 from shared network %4 for client assignments
This debug message indicates that the server is using another subnet
than initially selected for client assignments. This newly selected
subnet belongs to the same shared network as the original subnet.
Some reasons why the new subnet was selected include: address pool
exhaustion in the original subnet or the fact that the new subnet
includes some static reservations for this client.

800
% DHCP4_SUBNET_SELECTED %1: the subnet with ID %2 was selected for client assignments
801
This is a debug message noting the selection of a subnet to be used for
802 803 804 805 806 807 808 809 810 811 812 813 814
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.
815

Francis Dupont's avatar
Francis Dupont committed
816
% DHCP6_DHCP4O6_PACKET_RECEIVED received DHCPv4o6 packet from DHCPv6 server (type %1) for %2 port %3 on interface %4
817 818
This debug message is printed when the server is receiving a DHCPv4o6
from the DHCPv6 server over inter-process communication.