Commit 7f6c9d05 authored by Stephen Morris's avatar Stephen Morris
Browse files

[2325] Rephrased a couple of debug messages

parent a40fac07
......@@ -23,9 +23,9 @@ This debug message is issued just before the IPv6 DHCP server attempts
to establish a session with the BIND 10 control channel.
% DHCP6_CLIENTID_MISSING mandatory client-id option is missing, message from %1 dropped
This error message indicates that received message does not include
mandatory client-id option that is necessary for address assignment,
so the message is being dropped. This likely indicates a buggy client.
This error message indicates that the received message is being dropped
because it does not include the mandatory client-id option necessary for
address assignment. The most likely cause is a problem with the client.
% DHCP6_COMMAND_RECEIVED received command %1, arguments: %2
A debug message listing the command (and possible arguments) received
......@@ -203,13 +203,16 @@ the response will only contain generic configuration parameters and no
addresses or prefixes.
% DHCP6_UNKNOWN_RENEW received RENEW from client (duid=%1, iaid=%2) in subnet %3
This warning message is printed when client attempts to renew a lease, but no
such lease is known by the server. This typically means that client attempts to
use its lease past its lifetime, e.g. due to time adjustment or poor support
for sleep/recovery. Properly implemented client will recover from such case
(it should restart lease allocation process after receiving a negative reply
from the server). Alternatively, it may mean that the server lost its
database recently and does not recognize its well behaving clients. This
is likely the case if you see many such messages. Clients will recover from
this, but they will likely get another IP addresses and experience brief
service interruption.
This warning message is printed when client attempts to renew a lease,
but no such lease is known by the server. It typically means that
client has attempted to use its lease past its lifetime: causes of this
include a adjustment of the clients date/time setting or poor support
for sleep/recovery. A properly implemented client will recover from such
a situation by restarting the lease allocation process after receiving
a negative reply from the server.
An alternative cause could be that the server has lost its database
recently and does not recognize its well-behaving clients. This is more
probable if you see many such messages. Clients will recover from this,
but they will most likely get a different IP addresses and experience
a brief service interruption.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment