dhcp4_messages.mes 37.1 KB
Newer Older
1
# Copyright (C) 2012-2015 Internet Systems Consortium, Inc. ("ISC")
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.

$NAMESPACE isc::dhcp

17
18
19
20
21
% 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.

22
23
24
25
26
27
28
29
% 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
30
the PID file.  The first argument is the DHCPv4 process name, the
31
second contains the PID and PID file.
32

33
% DHCP4_BUFFER_RECEIVED received buffer from %1:%2 to %3:%4 over interface %5
34
This debug message is logged when the server has received a packet
35
36
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
37
interface and the source and destination IPv4 addresses/ports.
38

39
40
41
42
43
% 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.

44
% DHCP4_BUFFER_UNPACK parsing buffer received from %1 to %2 over interface %3
45
This debug message is issued when the server starts parsing the received
46
buffer holding the DHCPv4 message. The arguments specify the source and
47
destination IPv4 addresses as well as the interface over which the buffer has
48
been received.
49
50
51
52
53
54

% 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
55
and timers. After that, it will enter the wait state again.
56

57
58
59
60
61
62
63
64
% 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.

65
% DHCP4_BUFFER_WAIT_SIGNAL signal received while waiting for next packet, next waiting signal is %1
66
67
68
69
70
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.
71

72
% DHCP4_CCSESSION_STARTED control channel session started on socket %1
73
A debug message issued during startup after the DHCPv4 server has
74
successfully established a session with the Kea control channel.
75
76

% DHCP4_CCSESSION_STARTING starting control channel session, specfile: %1
77
This debug message is issued just before the DHCPv4 server attempts
78
to establish a session with the Kea control channel.
79

80
% DHCP4_CLASS_ASSIGNED %1: client packet has been assigned to the following class(es): %2
81
This debug message informs that incoming packet has been assigned to specified
Francis Dupont's avatar
Francis Dupont committed
82
class or classes. This is a normal behavior and indicates successful operation.
83
84
85
The first argument specifies the client and transaction identification
information. The second argument includes all classes to which the
packet has been assigned.
86

87
88
89
% DHCP4_CLASS_UNCONFIGURED %1: client packet belongs an unconfigured class: %2
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.

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

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

111
112
113
114
% 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.
115

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

123
124
125
126
127
% 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.

128
% DHCP4_CLIENT_NAME_PROC_FAIL %1: failed to process the fqdn or hostname sent by a client: %2
129
130
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
131
132
133
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.
134

135
% DHCP4_COMMAND_RECEIVED received command %1, arguments: %2
136
A debug message listing the command (and possible arguments) received
137
from the Kea control system by the DHCPv4 server.
138

139
140
141
142
143
144
% 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.

145
146
147
148
149
% 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.
150

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

155
156
157
158
% 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.
159

160
161
162
163
% 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.

164
165
% 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
166
configuration. That happens at start up and also when a server configuration
167
168
change is committed by the administrator.

169
% DHCP4_CONFIG_UPDATE updated configuration received: %1
170
A debug message indicating that the DHCPv4 server has received an
171
updated configuration from the Kea configuration system.
172

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

178
179
180
181
182
% 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
183
% DHCP4_DECLINE_LEASE Received DHCPDECLINE for addr %1 from client %2. The lease will be unavailable for %3 seconds.
184
This informational message is printed when a client received an address, but
185
186
187
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
188
189
190
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
191
situation, but if the underlying problem of a misconfigured or rogue device
192
193
is not solved, this address may be declined again in the future.

194
% DHCP4_DECLINE_LEASE_NOT_FOUND Received DHCPDECLINE for addr %1 from client %2, but no such lease found.
195
This warning message indicates that a client reported that his address was
196
197
198
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.
199

200
% 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
201
This informational message means that a client attempted to report his address
202
203
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
204
does not match the server's stored information. The client's request will be ignored.
205

206
% DHCP4_DISCOVER_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPDISCOVER
207
208
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.
209
The argument holds the client and transaction identification information.
210

Francis Dupont's avatar
Francis Dupont committed
211
% DHCP4_DYNAMIC_RECONFIGURATION initiate server reconfiguration using file: %1, after receiving SIGHUP signal
212
213
214
215
216
217
218
This is the info message logged when the DHCPv4 server starts reconfiguration
as a result of receiving SIGHUP signal.

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

219
% DHCP4_EMPTY_HOSTNAME %1: received empty hostname from the client, skipping processing of this option
220
221
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
222
223
option is skipped. The argument holds the client and transaction identification
information.
224

Tomek Mrugalski's avatar
Tomek Mrugalski committed
225
226
% 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
227
228
processing. This likely indicates a coding error and should be reported to ISC.

229
230
231
232
233
% 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.

234
% DHCP4_HOOK_BUFFER_RCVD_SKIP received buffer from %1 to %2 over interface %3 was dropped because a callout set the skip flag
235
236
237
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.
238
The arguments specify the source and destination IPv4 address as well as
239
the name of the interface over which the buffer has been received.
240

241
% DHCP4_HOOK_BUFFER_SEND_SKIP %1: prepared response is dropped because a callout set the skip flag.
242
243
244
245
246
247
This debug message is printed when a callout installed on buffer4_send
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
Server completed all the processing (e.g. may have assigned, updated
or released leases), but the response will not be send to the client.

248
249
250
251
252
253
254
% 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.

255
% DHCP4_HOOK_LEASE4_RELEASE_SKIP %1: lease was not released because a callout set the skip flag.
256
257
258
This debug message is printed when a callout installed on lease4_release
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to not release
Tomek Mrugalski's avatar
Tomek Mrugalski committed
259
a lease.
260

261
% DHCP4_HOOK_PACKET_RCVD_SKIP %1: packet is dropped, because a callout set the skip flag.
262
263
264
265
This debug message is printed when a callout installed on the pkt4_receive
hook point sets the skip flag. For this particular hook point, the
setting of the flag instructs the server to drop the packet.

266
% DHCP4_HOOK_PACKET_SEND_SKIP %1: prepared response is not sent, because a callout set skip flag.
267
268
269
270
271
272
This debug message is printed when a callout installed on the pkt4_send
hook point sets the skip flag. For this particular hook point, the setting
of the flag instructs the server to drop the packet. This means that
the client will not get any response, even though the server processed
client's request and acted on it (e.g. possibly allocated a lease).

273
% DHCP4_HOOK_SUBNET4_SELECT_SKIP %1: no subnet was selected, because a callout set skip flag.
274
275
276
277
278
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.
279
280
The argument specifies the client and transaction identification
information.
281

282
% DHCP4_INFORM_CLASS_PROCESSING_FAILED %1: client class specific processing failed for DHCPINFORM
283
284
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.
285
286
The argument specifies the client and the transaction identification
information.
287

288
% DHCP4_INFORM_DIRECT_REPLY %1: DHCPACK in reply to the DHCPINFORM will be sent directly to %2 over %3
289
290
291
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
292
293
the client's IPv4 address to which the response will be sent. The third
argument contains the local interface name.
294

295
296
297
298
299
% 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.

300
301
% 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
302
303
304
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.
305

306
307
308
% 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
309
310
those which offered leases and continue allocation with that server.
The first argument specifies the client and the transaction identification
311
information. The second argument specifies the IPv4 address to be offered.
312
313

% DHCP4_LEASE_ALLOC %1: lease %2 has been allocated
314
This debug message indicates that the server successfully granted a lease
315
in response to client's DHCPREQUEST message. The lease information will
316
317
be sent to the client in the DHCPACK message. The first argument
contains the client and the transaction identification information. The
318
second argument contains the allocated IPv4 address.
319

320
% DHCP4_NAME_GEN_UPDATE_FAIL %1: failed to update the lease after generating name %2 for a client: %3
321
322
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
323
324
from the acquired IPv4 address. The message argument indicates the reason
for the failure. The first argument includes the client and the transaction
325
326
identification information. The second argument specifies the hostname.
The third argument contains the error details.
327

328
329
330
331
% 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
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
332
333
334
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.
335
336

% DHCP4_NCR_CREATION_FAILED %1: failed to generate name change requests for DNS: %2
337
This message indicates that server was unable to generate NameChangeRequests
338
which should be sent to the kea-dhcp_ddns module to create
339
new DNS records for the lease being acquired or to update existing records
340
341
for the renewed lease. The first argument contains the client and transaction
identification information. The second argument includes the reason for the
342
failure.
343

344
345
346
347
% 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.

348
% DHCP4_NO_LEASE_INIT_REBOOT %1: no lease for address %2 requested by INIT-REBOOT client
349
This debug message is issued when the client being in the INIT-REBOOT state
350
351
352
353
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.
354

355
356
357
358
359
% 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.

360
% DHCP4_OPEN_SOCKET opening sockets on port %1
361
A debug message issued during startup, this indicates that the DHCPv4
362
server is about to open sockets on the specified port.
363

364
% DHCP4_OPEN_SOCKET_FAIL failed to open socket: %1
365
366
367
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.

368
% DHCP4_PACKET_DROP_0001 failed to parse packet from %1 to %2, received over interace %3, reason: %4
369
370
371
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.

372
% DHCP4_PACKET_DROP_0002 %1, from interface %2: no suitable subnet configured for a direct client
373
374
375
376
377
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.
378

379
% DHCP4_PACKET_DROP_0003 %1, from interface %2: it contains a foreign server identifier
380
381
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
382
383
384
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.
385

386
% DHCP4_PACKET_DROP_0004 %1, from interface %2: missing msg-type option
387
This is a debug message informing that incoming DHCPv4 packet did not
388
389
390
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.
391

392
% DHCP4_PACKET_DROP_0005 %1: unrecognized type %2 in option 53
393
394
395
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.
396
397
398
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.
399

400
% DHCP4_PACKET_DROP_0006 %1: unsupported DHCPv4 message type %2
401
402
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
403
404
405
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.
406

407
% DHCP4_PACKET_DROP_0007 %1: failed to process packet: %2
408
409
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
410
411
412
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.
413

414
% DHCP4_PACKET_NAK_0001 %1: failed to select a subnet for incoming packet, src %2, type %3
415
This error message is output when a packet was received from a subnet
416
for which the DHCPv4 server has not been configured. The most probable
417
418
cause is a misconfiguration of the server. The first argument contains
the client and transaction identification information. The second argument
419
contains the source IPv4 address of the packet. The third argument contains
420
the name of the received packet.
421

422
% DHCP4_PACKET_NAK_0002 %1: invalid address %2 requested by INIT-REBOOT
423
This debug message is issued when the client being in the INIT-REBOOT state
424
requested an IPv4 address which is not assigned to him. The server will respond
425
426
to this client with DHCPNAK. The first argument contains the client and
the transaction identification information. The second arguments holds the
427
IPv4 address requested by the client.
428

429
% DHCP4_PACKET_NAK_0003 %1: failed to advertise a lease, client sent ciaddr %2, requested-ip-address %3
430
431
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
432
433
many possible reasons for such a failure. The first argument contains
the client and the transaction identification information. The second
434
435
argument contains the IPv4 address in the ciaddr field. The third
argument contains the IPv4 address in the requested-ip-address option
436
(if present).
437

438
% DHCP4_PACKET_NAK_0004 %1: failed to grant a lease, client sent ciaddr %2, requested-ip-address %3
439
440
441
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
442
reason. The first argument contains the client and the transaction
443
444
identification information. The second argument contains the IPv4 address
in the ciaddr field. The third argument contains the IPv4 address in the
445
requested-ip-address option (if present).
446

447
448
449
% 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
450
the client and the transaction identification information.
451
452
453
454
455
456
457

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

% DHCP4_PACKET_RECEIVED %1: %2 (type %3) received from %4 to %5 on interface %6
458
A debug message noting that the server has received the specified type of
459
460
461
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
462
463
respectively. The remaining arguments specify the source IPv4 address,
destination IPv4 address and the name of the interface on which the
464
message has been received.
465

466
% DHCP4_PACKET_SEND %1: trying to send packet %2 (type %3) from %4:%5 to %6:%7 on interface %8
467
468
469
470
471
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.

472
This debug message is issued when the server is trying to send the
Shawn Routhier's avatar
Shawn Routhier committed
473
response to the client. When the server is using an UDP socket
474
to send the packet there are cases when this operation may be
Shawn Routhier's avatar
Shawn Routhier committed
475
476
477
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
478
479
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
480
481
the firewall policy, the ARP message will not cause a response.
Consequently, the response to the DHCPINFORM will not be sent.
482
483
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
484
and it has no means to display an error message.
485

486
% DHCP4_PACKET_SEND_FAIL %1: failed to send DHCPv4 packet: %2
487
This error is output if the DHCPv4 server fails to send an assembled
488
489
490
DHCP message to a client. The first argument includes the client and
the transaction identification information. The second argument includes
the reason for failure.
491

492
% DHCP4_PARSER_COMMIT_EXCEPTION parser failed to commit changes
493
On receipt of message containing details to a change of the DHCPv4
494
495
496
497
498
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
499
On receipt of message containing details to a change of the DHCPv4
500
501
502
503
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.

504
% DHCP4_PARSER_CREATED created parser for configuration element %1
505
A debug message output during a configuration update of the DHCPv4
506
server, notifying that the parser for the specified configuration element
507
has been successfully created.
508

509
% DHCP4_PARSER_EXCEPTION failed to create or run parser for configuration element %1
510
On receipt of message containing details to a change of its configuration,
511
the DHCPv4 server failed to create a parser to decode the contents of
512
513
the named configuration element, or the creation succeeded but the parsing
actions and committal of changes failed.  The message has been output in
514
response to a non-Kea exception being raised.  Additional messages
515
516
may give further information.

517
518
% 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,
519
the DHCPv4 server failed to create a parser to decode the contents
520
521
522
523
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.

524
525
526
527
% 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.
528

529

530
% DHCP4_RELEASE %1: address %2 was released properly.
531
This debug message indicates that an address was released properly. It
532
533
is a normal operation during client shutdown. The first argument includes
the client and transaction identification information. The second argument
534
includes the released IPv4 address.
535

536
% DHCP4_RELEASE_EXCEPTION %1: while trying to release address %2 an exception occured: %3
537
This message is output when an error was encountered during an attempt
538
539
to process a DHCPRELEASE message. The error will not affect the client,
which does not expect any response from the server for DHCPRELEASE
540
messages. Depending on the nature of problem, it may affect future
541
542
server operation. The first argument includes the client and the
transaction identification information. The second argument
543
includes the IPv4 address which release was attempted. The last
544
argument includes the detailed error description.
545

546
% DHCP4_RELEASE_FAIL %1: failed to remove lease for address %2
547
548
549
550
551
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
552
553
removed from the database during RELEASE message processing. The
first argument includes the client and the transaction identification
554
information. The second argument holds the IPv4 address which release
555
was attempted.
556

557
558
559
560
% 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
561
562
argument contains the IPv4 address which the client is trying to
release.
563

564
565
566
567
568
569
570
% 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.
571

572
573
574
575
576
577
578
579
580
581
582
583
584
% 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 %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.

585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
% 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.

609
% DHCP4_SERVER_FAILED server failed: %1
610
The DHCPv4 server has encountered a fatal error and is terminating.
611
612
The reason for the failure is included in the message.

613
% DHCP4_SHUTDOWN server shutdown
614
The DHCPv4 server has terminated normally.
615
616

% DHCP4_SHUTDOWN_REQUEST shutdown of server requested
617
This debug message indicates that a shutdown of the DHCPv4 server has
618
619
been requested via a call to the 'shutdown' method of the core Dhcpv4Srv
object.
620
621

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

627
628
629
630
631
632
% DHCP4_SRV_D2STOP_ERROR error stopping IO with DHCP_DDNS during shutdown: %1
This error message indicates that during shutdown, an erro occurred while
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.

633
634
635
636
637
% 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.

638
% DHCP4_STARTING Kea DHCPv4 server version %1 starting
639
This informational message indicates that the DHCPv4 server has
640
641
processed any command-line switches and is starting. The version
is also printed.
642

Tomek Mrugalski's avatar
Tomek Mrugalski committed
643
% DHCP4_START_INFO pid: %1, port: %2, verbose: %3
644
This is a debug message issued during the DHCPv4 server startup.
645
646
It lists some information about the parameters with which the server
is running.
647

648
% DHCP4_SUBNET_DATA %1: the selected subnet details: %2
649
This debug message includes the details of the subnet selected for
650
651
652
653
654
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
655
This is a debug message noting the selection of a subnet to be used for
656
657
658
659
660
661
662
663
664
665
666
667
668
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.