Commit d117d872 authored by Stephen Morris's avatar Stephen Morris
Browse files

[2559] Merge branch 'master' into trac2559

Conflicts:
	src/bin/dhcp4/config_parser.cc
	src/bin/dhcp6/config_parser.cc
	src/bin/dhcp6/dhcp6_srv.h
	src/lib/dhcpsrv/dhcpsrv_messages.mes
	src/lib/dhcpsrv/tests/Makefile.am
parents aad83b6e c4df99ea
5XX. [func] tomek
b10-dhcp4: The DHCPv4 server now generates a server identifier
the first time it is run. The identifier is preserved in a file
across server restarts.
b10-dhcp6: The server identifier is now preserved in a file across
server restarts.
(Trac #2597, git fa342a994de5dbefe32996be7eebe58f6304cff7)
549. [func] tomek
b10-dhcp6: It is now possible to specify that a configured subnet
is reachable locally over specified interface (see "interface"
parameter in Subnet6 configuration).
(Trac #2596, git a70f6172194a976b514cd7d67ce097bbca3c2798)
548. [func] vorner
The message queue daemon now appears on the bus. This has two
effects, one is it obeys logging configuration and logs to the
correct place like the rest of the modules. The other is it
appears in bindctl as module (but it doesn't have any commands or
configuration yet).
(Trac #2582, git ced31d8c5a0f2ca930b976d3caecfc24fc04634e)
547. [func]* vorner
The b10-loadzone now performs more thorough sanity check on the
loaded data. Some of the checks are now fatal and zone failing
them will be rejected.
(Trac #2436, git 48d999f1cb59f308f9f30ba2639521d2a5a85baa)
546. [func] marcin
DHCP option definitions can be now created using the
Configuration Manager. The option definition specifies
the option code, name and the types of the data being
carried by the option. The Configuration Manager
reports an error on attempt to override standard DHCP
option definition.
(Trac #2317, git 71e25eb81e58a695cf3bad465c4254b13a50696e)
545. [func] jinmei
libdns++: the SOA Rdata class now uses the generic lexer in
constructors from text. This means that the MNAME and RNAME of an
SOA RR in a zone file can now be non absolute (the origin name
in that context will be used), e.g., when loaded by b10-loadzone.
(Trac #2500, git 019ca218027a218921519f205139b96025df2bb5)
544. [func] tomek
b10-dhcp4: Allocation engine support for IPv4 added. Currently
supported operations are server selection (Discover/Offer),
address assignment (Request/Ack), address renewal (Request/Ack),
and address release (Release). Expired leases can be reused.
Some options (e.g. Router Option) are still hardcoded, so the
DHCPv4 server is not yet usable, although its address allocation
is operational.
(Trac #2320, git 60606cabb1c9584700b1f642bf2af21a35c64573)
543. [func]* jelte
When calling getFullConfig() as a module, , the configuration is now
returned as properly-structured JSON. Previously, the structure had
......
......@@ -282,7 +282,10 @@ AC_SUBST(PYTHON_LOGMSGPKG_DIR)
# This is python package paths commonly used in python tests. See
# README of log_messages for why it's included.
COMMON_PYTHON_PATH="\$(abs_top_builddir)/src/lib/python/isc/log_messages:\$(abs_top_srcdir)/src/lib/python:\$(abs_top_builddir)/src/lib/python"
# lib/dns/python/.libs is necessary because __init__.py of isc package
# automatically imports isc.datasrc, which then requires the DNS loadable
# module. #2145 should eliminate the need for it.
COMMON_PYTHON_PATH="\$(abs_top_builddir)/src/lib/python/isc/log_messages:\$(abs_top_srcdir)/src/lib/python:\$(abs_top_builddir)/src/lib/python:\$(abs_top_builddir)/src/lib/dns/python/.libs"
AC_SUBST(COMMON_PYTHON_PATH)
# Check for python development environments
......@@ -1214,6 +1217,8 @@ AC_CONFIG_FILES([Makefile
src/lib/python/isc/server_common/tests/Makefile
src/lib/python/isc/sysinfo/Makefile
src/lib/python/isc/sysinfo/tests/Makefile
src/lib/python/isc/statistics/Makefile
src/lib/python/isc/statistics/tests/Makefile
src/lib/config/Makefile
src/lib/config/tests/Makefile
src/lib/config/tests/testdata/Makefile
......
......@@ -3343,23 +3343,21 @@ then change those defaults with config set Resolver/forward_addresses[0]/address
<note>
<para>
As of November 2012, the DHCPv4 component is a
skeleton server. That means that while it is capable of
performing DHCP configuration, it is not fully functional.
In particular, it does not have a functional lease
database. This means that they will assign the same, fixed,
hardcoded addresses to any client that will ask. See <xref
linkend="dhcp4-limit"/> for a
detailed description.
As of January 2013, the DHCPv4 component is a work in progress.
That means that while it is capable of performing DHCP configuration,
it is not fully functional. The server is able to offer,
assign, renew, release and reuse expired leases, but some of the
options are not configurable yet. In particular Router option is hardcoded.
This means that the server is not really usable in actual deployments
yet. See <xref linkend="dhcp4-limit"/> for a detailed description.
</para>
</note>
<section id="dhcp4-usage">
<title>DHCPv4 Server Usage</title>
<para>BIND 10 has provided the DHCPv4 server component since December
2011. It is a skeleton server and can be described as an early
prototype that is not fully functional yet. It is mature enough
to conduct first tests in lab environment, but it has
2011. It is current experimental implementation and is not fully functional
yet. It is mature enough to conduct tests in lab environment, but it has
significant limitations. See <xref linkend="dhcp4-limit"/> for
details.
</para>
......@@ -3480,24 +3478,41 @@ Dhcp4/subnet4 [] list (default)</screen>
</para>
<para>
Note: Although configuration is now accepted, it is not internally used
by they server yet. At this stage of development, the only way to alter
server configuration is to modify its source code. To do so, please edit
Note: Although configuration is now accepted, some parts of it is not internally used
by they server yet. Address pools are used, but option definitons are not.
The only way to alter some options (e.g. Router Option or DNS servers and Domain name)
is to modify source code. To do so, please edit
src/bin/dhcp6/dhcp4_srv.cc file, modify the following parameters and
recompile:
<screen>
const std::string HARDCODED_LEASE = "192.0.2.222"; // assigned lease
const std::string HARDCODED_NETMASK = "255.255.255.0";
const uint32_t HARDCODED_LEASE_TIME = 60; // in seconds
const std::string HARDCODED_GATEWAY = "192.0.2.1";
const std::string HARDCODED_DNS_SERVER = "192.0.2.2";
const std::string HARDCODED_DOMAIN_NAME = "isc.example.com";
const std::string HARDCODED_SERVER_ID = "192.0.2.1";</screen>
const std::string HARDCODED_DOMAIN_NAME = "isc.example.com";</screen>
Lease database and configuration support is planned for end of 2012.
</para>
</section>
<section id="dhcp4-serverid">
<title>Server Identifier in DHCPv4</title>
<para>The DHCPv4 protocol uses a "server identifier" for clients to be able
to discriminate between several servers present on the same link: this
value is an IPv4 address of the server. When started for the first time,
the DHCPv4 server will choose one of its IPv4 addresses as its server-id,
and store the chosen value to a file. (The file is named b10-dhcp4-serverid and is
stored in the "local state directory". This is set during installation
when "configure" is run, and can be changed by using "--localstatedir"
on the "configure" command line.) That file will be read by the server
and the contained value used whenever the server is subsequently started.
</para>
<para>
It is unlikely that this parameter needs to be changed. If such a need
arises, please stop the server, edit the file and restart the server.
It is a text file that should contain an IPv4 address. Spaces are
ignored. No extra characters are allowed in this file.
</para>
</section>
<section id="dhcp4-std">
<title>Supported standards</title>
<para>The following standards and draft standards are currently
......@@ -3505,7 +3520,7 @@ const std::string HARDCODED_SERVER_ID = "192.0.2.1";</screen>
<itemizedlist>
<listitem>
<simpara>RFC2131: Supported messages are DISCOVER, OFFER,
REQUEST, and ACK.</simpara>
REQUEST, ACK, NAK, RELEASE.</simpara>
</listitem>
<listitem>
<simpara>RFC2132: Supported options are: PAD (0),
......@@ -3513,6 +3528,10 @@ const std::string HARDCODED_SERVER_ID = "192.0.2.1";</screen>
Domain Name (15), DNS Servers (6), IP Address Lease Time
(51), Subnet mask (1), and Routers (3).</simpara>
</listitem>
<listitem>
<simpara>RFC6842: Server responses include client-id option
if client sent it in its message.</simpara>
</listitem>
</itemizedlist>
</section>
......@@ -3532,20 +3551,6 @@ const std::string HARDCODED_SERVER_ID = "192.0.2.1";</screen>
relayed traffic only (that is, normal point to point
communication).</simpara>
</listitem>
<listitem>
<simpara><command>b10-dhcp4</command> provides a single,
fixed, hardcoded lease to any client that asks. There is
no lease manager implemented. If two clients request
addresses, they will both get the same fixed
address.</simpara>
</listitem>
<listitem>
<simpara><command>b10-dhcp4</command> does not support any
configuration mechanisms yet. The whole configuration is
currently hardcoded. The only way to tweak configuration
is to directly modify source code. See see <xref
linkend="dhcp4-config"/> for details.</simpara>
</listitem>
<listitem>
<simpara>Upon start, the server will open sockets on all
interfaces that are not loopback, are up and running and
......@@ -3574,9 +3579,9 @@ const std::string HARDCODED_SERVER_ID = "192.0.2.1";</screen>
sending ICMP echo request.</simpara>
</listitem>
<listitem>
<simpara>Address renewal (RENEW), rebinding (REBIND),
confirmation (CONFIRM), duplication report (DECLINE) and
release (RELEASE) are not supported yet.</simpara>
<simpara>Address rebinding (REQUEST/Rebinding), confirmation
(CONFIRM) and duplication report (DECLINE) are not supported
yet.</simpara>
</listitem>
<listitem>
<simpara>DNS Update is not supported yet.</simpara>
......@@ -3852,6 +3857,31 @@ Dhcp6/subnet6 [] list (default)</screen>
</note>
</section>
<section id="dhcp6-serverid">
<title>Server Identifier in DHCPv6</title>
<para>The DHCPv6 protocol uses a "server identifier" (also known
as a DUID) for clients to be able to discriminate between several
servers present on the same link. There are several types of
DUIDs defined, but RFC 3315 instructs servers to use DUID-LLT if
possible. This format consists of a link-layer (MAC) address and a
timestamp. When started for the first time, the DHCPv6 server will
automatically generate such a DUID and store the chosen value to
a file (The file is named b10-dhcp6-serverid and is stored in the
"local state directory". This is set during installation when
"configure" is run, and can be changed by using "--localstatedir"
on the "configure" command line.) That file will be read by the server
and the contained value used whenever the server is subsequently started.
</para>
<para>
It is unlikely that this parameter needs to be changed. If such a need
arises, please stop the server, edit the file and start the server
again. It is a text file that contains double digit hexadecimal values
separated by colons. This format is similar to typical MAC address
format. Spaces are ignored. No extra characters are allowed in this
file.
</para>
</section>
<section id="dhcp6-std">
<title>Supported DHCPv6 Standards</title>
<para>The following standards and draft standards are currently
......
......@@ -99,18 +99,17 @@ example_nsec3_inc.cc: $(srcdir)/testdata/example-nsec3-inc.zone
$(PYTHON) $(srcdir)/gen-query-testdata.py \
$(srcdir)/testdata/example-nsec3-inc.zone example_nsec3_inc.cc
testdata/example-base.sqlite3: testdata/example-base.zone
testdata/example-common-inc.zone: $(srcdir)/testdata/example-common-inc-template.zone
$(top_srcdir)/install-sh -c \
$(srcdir)/testdata/example-common-inc-template.zone \
testdata/example-common-inc.zone
testdata/example-base.sqlite3: testdata/example-base.zone testdata/example-common-inc.zone
$(SHELL) $(top_builddir)/src/bin/loadzone/run_loadzone.sh \
-c "{\"database_file\": \"$(builddir)/testdata/example-base.sqlite3\"}" \
example.com testdata/example-base.zone
testdata/example-nsec3.sqlite3: testdata/example-nsec3.zone
$(top_srcdir)/install-sh -c \
$(srcdir)/testdata/example-common-inc-template.zone \
testdata/example-common-inc.zone
testdata/example-nsec3.sqlite3: testdata/example-nsec3.zone testdata/example-common-inc.zone
$(SHELL) $(top_builddir)/src/bin/loadzone/run_loadzone.sh \
-c "{\"database_file\": \"$(builddir)/testdata/example-nsec3.sqlite3\"}" \
example.com testdata/example-nsec3.zone
......
......@@ -1286,12 +1286,12 @@ TEST_F(AuthSrvTest, queryCounterUnexpected) {
createRequestPacket(request_message, IPPROTO_UDP);
// Modify the message.
delete io_message;
endpoint = IOEndpoint::create(IPPROTO_UDP,
IOAddress(DEFAULT_REMOTE_ADDRESS), 53210);
io_message = new IOMessage(request_renderer.getData(),
request_renderer.getLength(),
getDummyUnknownSocket(), *endpoint);
endpoint.reset(IOEndpoint::create(IPPROTO_UDP,
IOAddress(DEFAULT_REMOTE_ADDRESS),
53210));
io_message.reset(new IOMessage(request_renderer.getData(),
request_renderer.getLength(),
getDummyUnknownSocket(), *endpoint));
EXPECT_FALSE(dnsserv.hasAnswer());
}
......@@ -1716,9 +1716,20 @@ void
checkAddrPort(const struct sockaddr& actual_sa,
const string& expected_addr, uint16_t expected_port)
{
// ASIO does not set as_len, which is not a problem on most
// systems, but it will make getnameinfo() fail on NetBSD 4
// So we make a copy and if the field is available, we set it
const socklen_t sa_len = getSALength(actual_sa);
struct sockaddr_storage ss;
memcpy(&ss, &actual_sa, sa_len);
struct sockaddr* sa = convertSockAddr(&ss);
#ifdef HAVE_SA_LEN
sa->sa_len = sa_len;
#endif
char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV];
const int error = getnameinfo(&actual_sa, getSALength(actual_sa), hbuf,
sizeof(hbuf), sbuf, sizeof(sbuf),
const int error = getnameinfo(sa, sa_len, hbuf, sizeof(hbuf),
sbuf, sizeof(sbuf),
NI_NUMERICHOST | NI_NUMERICSERV);
if (error != 0) {
isc_throw(isc::Unexpected, "getnameinfo failed: " <<
......
......@@ -208,12 +208,13 @@ WARNING: Python readline module isn't available, so the command line editor
return True
def login_to_cmdctl(self):
'''Login to cmdctl with the username and password inputted
from user. After the login is sucessful, the username and
'''Login to cmdctl with the username and password given by
the user. After the login is sucessful, the username and
password will be saved in 'default_user.csv', when run the next
time, username and password saved in 'default_user.csv' will be
used first.
'''
# Look at existing username/password combinations and try to log in
users = self._get_saved_user_info(self.csv_file_dir, CSV_FILE_NAME)
for row in users:
param = {'username': row[0], 'password' : row[1]}
......@@ -230,15 +231,18 @@ WARNING: Python readline module isn't available, so the command line editor
print(data + ' login as ' + row[0])
return True
# No valid logins were found, prompt the user for a username/password
count = 0
print("[TEMP MESSAGE]: username :root password :bind10")
print('No stored password file found, please see sections '
'"Configuration specification for b10-cmdctl" and "bindctl '
'command-line options" of the BIND 10 guide.')
while True:
count = count + 1
if count > 3:
print("Too many authentication failures")
return False
username = input("Username:")
username = input("Username: ")
passwd = getpass.getpass()
param = {'username': username, 'password' : passwd}
try:
......
......@@ -20,7 +20,10 @@ export PYTHON_EXEC
BINDCTL_PATH=@abs_top_builddir@/src/bin/bindctl
PYTHONPATH=@abs_top_srcdir@/src/bin:@abs_top_builddir@/src/lib/python/isc/log_messages:@abs_top_builddir@/src/lib/python:@abs_top_builddir@/src/bin:@abs_top_srcdir@/src/lib/python
# Note: lib/dns/python/.libs is necessary because __init__.py of isc package
# automatically imports isc.datasrc, which then requires the DNS loadable
# module. #2145 should eliminate the need for it.
PYTHONPATH=@abs_top_srcdir@/src/bin:@abs_top_builddir@/src/lib/python/isc/log_messages:@abs_top_builddir@/src/lib/python:@abs_top_builddir@/src/bin:@abs_top_srcdir@/src/lib/python:@abs_top_builddir@/src/lib/dns/python/.libs
export PYTHONPATH
# If necessary (rare cases), explicitly specify paths to dynamic libraries
......
......@@ -20,7 +20,10 @@ export PYTHON_EXEC
DBUTIL_PATH=@abs_top_builddir@/src/bin/dbutil
PYTHONPATH=@abs_top_srcdir@/src/bin:@abs_top_builddir@/src/lib/python/isc/log_messages:@abs_top_builddir@/src/lib/python:@abs_top_builddir@/src/bin:@abs_top_srcdir@/src/lib/python
# Note: lib/dns/python/.libs is necessary because __init__.py of isc package
# automatically imports isc.datasrc, which then requires the DNS loadable
# module. #2145 should eliminate the need for it.
PYTHONPATH=@abs_top_srcdir@/src/bin:@abs_top_builddir@/src/lib/python/isc/log_messages:@abs_top_builddir@/src/lib/python:@abs_top_builddir@/src/bin:@abs_top_srcdir@/src/lib/python:@abs_top_builddir@/src/lib/dns/python/.libs
export PYTHONPATH
# If necessary (rare cases), explicitly specify paths to dynamic libraries
......
This diff is collapsed.
......@@ -28,20 +28,6 @@ namespace dhcp {
class Dhcpv4Srv;
/// An exception that is thrown if an error occurs while configuring an
/// @c Dhcpv4Srv object.
class Dhcp4ConfigError : public isc::Exception {
public:
/// @brief constructor
///
/// @param file name of the file, where exception occurred
/// @param line line of the file, where exception occurred
/// @param what text description of the issue that caused exception
Dhcp4ConfigError(const char* file, size_t line, const char* what)
: isc::Exception(file, line, what) {}
};
/// @brief Configure DHCPv4 server (@c Dhcpv4Srv) with a set of configuration values.
///
/// This function parses configuration information stored in @c config_set
......
......@@ -19,6 +19,7 @@
#include <cc/session.h>
#include <config/ccsession.h>
#include <dhcp/iface_mgr.h>
#include <dhcpsrv/dhcp_config_parser.h>
#include <dhcp4/ctrl_dhcp4_srv.h>
#include <dhcp4/dhcp4_log.h>
#include <dhcp4/spec_config.h>
......@@ -121,7 +122,7 @@ void ControlledDhcpv4Srv::establishSession() {
try {
configureDhcp4Server(*this, config_session_->getFullConfig());
} catch (const Dhcp4ConfigError& ex) {
} catch (const DhcpConfigError& ex) {
LOG_ERROR(dhcp4_logger, DHCP4_CONFIG_LOAD_FAIL).arg(ex.what());
}
......
......@@ -34,6 +34,56 @@
"item_default": 4000
},
{ "item_name": "option-def",
"item_type": "list",
"item_optional": false,
"item_default": [],
"list_item_spec":
{
"item_name": "single-option-def",
"item_type": "map",
"item_optional": false,
"item_default": {},
"map_item_spec": [
{
"item_name": "name",
"item_type": "string",
"item_optional": false,
"item_default": ""
},
{ "item_name": "code",
"item_type": "integer",
"item_optional": false,
"item_default": 0,
},
{ "item_name": "type",
"item_type": "string",
"item_optional": false,
"item_default": "",
},
{ "item_name": "array",
"item_type": "boolean",
"item_optional": false,
"item_default": False
},
{ "item_name": "record_types",
"item_type": "string",
"item_optional": false,
"item_default": "",
},
{ "item_name": "space",
"item_type": "string",
"item_optional": false,
"item_default": ""
} ]
}
},
{ "item_name": "option-data",
"item_type": "list",
"item_optional": false,
......@@ -66,6 +116,11 @@
"item_type": "boolean",
"item_optional": false,
"item_default": False
},
{ "item_name": "space",
"item_type": "string",
"item_optional": false,
"item_default": "dhcp4"
} ]
}
},
......@@ -189,6 +244,11 @@
"item_type": "boolean",
"item_optional": false,
"item_default": False
},
{ "item_name": "space",
"item_type": "string",
"item_optional": false,
"item_default": "dhcp4"
} ]
}
} ]
......
......@@ -26,12 +26,6 @@ to establish a session with the BIND 10 control channel.
A debug message listing the command (and possible arguments) received
from the BIND 10 control system by the IPv4 DHCP server.
% 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.
% DHCP4_CONFIG_LOAD_FAIL failed to load configuration: %1
This critical error message indicates that the initial DHCPv4
configuration has failed. The server will start, but nothing will be
......@@ -41,19 +35,52 @@ served until the configuration has been corrected.
This is an informational message reporting that the configuration has
been extended to include the specified IPv4 subnet.
% 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.
% DHCP4_CONFIG_UPDATE updated configuration received: %1
A debug message indicating that the IPv4 DHCP server has received an
updated configuration from the BIND 10 configuration system.
% 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
configuration. That happens at start up and also when a server configuration
change is committed by the administrator.
% DHCP4_CONFIG_UPDATE updated configuration received: %1
A debug message indicating that the IPv4 DHCP server has received an
updated configuration from the BIND 10 configuration system.
% 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.
% 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 the particular subnet. Adding multiple options is uncommon
for DHCPv4, but it is not prohibited.
% DHCP4_DB_BACKEND_STARTED lease database started (type: %1, name: %2)
This informational message is printed every time DHCPv4 server is started
and gives both the type and name of the database being used to store
lease and other information.
% DHCP4_LEASE_ADVERT lease %1 advertised (client client-id %2, hwaddr %3)
This debug message indicates that the server successfully advertised
a lease. It is up to the client to choose one server out of othe advertised
and continue allocation with that server. This is a normal behavior and
indicates successful operation.
% DHCP4_LEASE_ADVERT_FAIL failed to advertise a lease for client client-id %1, hwaddr %2
This message indicates that the server has failed to offer a lease to
the specified client after receiving a DISCOVER message from it. There are
many possible reasons for such a failure.
% DHCP4_LEASE_ALLOC lease %1 has been allocated for client-id %2, hwaddr %3
This debug message indicates that the server successfully granted a lease
in response to client's REQUEST message. This is a normal behavior and
incicates successful operation.
% DHCP4_LEASE_ALLOC_FAIL failed to grant a lease for client-id %1, hwaddr %2
This message indicates that the server failed to grant a lease to the
specified client after receiving a REQUEST message from it. There are many
possible reasons for such a failure. Additional messages will indicate the
reason.
% DHCP4_NOT_RUNNING IPv4 DHCP server is not running
A warning message is issued when an attempt is made to shut down the
......@@ -100,15 +127,10 @@ 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.
% DHCP4_PARSER_CREATED1 created parser for configuration element %1
A debug message output during a configuration update of the IPv4 DHCP
server, notifying that the parser for the specified configuration element
has been successfully created in the first pass through creating parsers
% DHCP4_PARSER_CREATED2 created parser for configuration element %1
% DHCP4_PARSER_CREATED created parser for configuration element %1
A debug message output during a configuration update of the IPv4 DHCP
server, notifying that the parser for the specified configuration element
has been successfully created in the second pass through creating parsers
has been successfully created.
% DHCP4_PARSER_CREATE_FAIL failed to create parser for configuration element %1: %2
On receipt of message containing details to a change of its configuration,
......@@ -126,6 +148,43 @@ may give further information.
% DHCP4_QUERY_DATA received packet type %1, data is <%2>
A debug message listing the data received from the client.
% DHCP4_RELEASE address %1 belonging to client-id %2, hwaddr %3 was released properly.
This debug message indicates that an address was released properly. It
is a normal operation during client shutdown.
% DHCP4_RELEASE_EXCEPTION exception %1 while trying to release address %2
This message is output when an error was encountered during an attempt
to process a RELEASE message. The error will not affect the client,
which does not expect any response from the server for RELEASE
messages. Depending on the nature of problem, it may affect future
server operation.
% DHCP4_RELEASE_FAIL failed to remove lease for address %1 for duid %2, hwaddr %3
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
removed from the database during RELEASE message processing.
% DHCP4_RELEASE_FAIL_NO_LEASE client (client-id %2) tried to release address %1, but there is no lease for such address.
This warning message is printed when client attempts to release a lease,
but no such lease is known to the server.
% DHCP4_RELEASE_FAIL_WRONG_CLIENT_ID client (client-id %2) tried to release address %1, but it belongs to client (client-id %3)
This warning message indicates that client tried to release an address
that belongs to a different client. This should not happen in normal
circumstances and may indicate a misconfiguration of the client. However,
since the client releasing the address will stop using it anyway, there
is a good chance that the situation will correct itself.
% DHCP4_RELEASE_FAIL_WRONG_HWADDR client (client-id %2) tried to release address %1, but sent from a wrong hardware address (%3)
This warning message indicates that client tried to release an address
that does belong to it, but the lease information was associated with
a different hardware address. One possible reason for using different
hardware address is that a cloned virtual machine was not updated and
both clones use the same client-id.
% DHCP4_RESPONSE_DATA responding with packet type %1, data is <%2>
A debug message listing the data returned to the client.
......@@ -133,6 +192,26 @@ A debug message listing the data returned to the client.
The IPv4 DHCP server has encountered a fatal error and is terminating.