From: Marcin Siodelski Date: Tue, 19 May 2015 12:29:18 +0000 (+0200) Subject: [master] Merge branch 'trac3747' X-Git-Tag: trac3867_base~2 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b9dc6ffd0f3396e9da8e0c83fd82164b8b8af011;p=thirdparty%2Fkea.git [master] Merge branch 'trac3747' --- b9dc6ffd0f3396e9da8e0c83fd82164b8b8af011 diff --cc src/bin/admin/scripts/mysql/.gitignore index e814b1ae3f,e814b1ae3f..e9a483d6fc --- a/src/bin/admin/scripts/mysql/.gitignore +++ b/src/bin/admin/scripts/mysql/.gitignore @@@ -1,1 -1,1 +1,2 @@@ /upgrade_1.0_to_2.0.sh ++/upgrade_2.0_to_3.0.sh diff --cc src/bin/dhcp4/dhcp4_messages.mes index a0ca287d21,9c2f175f39..4d6d27c968 --- a/src/bin/dhcp4/dhcp4_messages.mes +++ b/src/bin/dhcp4/dhcp4_messages.mes @@@ -64,43 -27,28 +64,57 @@@ successfully established a session wit This debug message is issued just before the DHCPv4 server attempts to establish a session with the Kea control channel. -% DHCP4_CLASS_ASSIGNED client packet has been assigned to the following class(es): %1 +% DHCP4_CLASS_ASSIGNED %1: client packet has been assigned to the following class(es): %2 This debug message informs that incoming packet has been assigned to specified class or classes. This is a normal behavior and indicates successful operation. +The first argument specifies the client and transaction identification +information. The second argument includes all classes to which the +packet has been assigned. + % 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. + -% DHCP4_CLIENT_NAME_PROC_FAIL failed to process the fqdn or hostname sent by a client: %1 +% 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. + +% DHCP4_CLIENT_FQDN_DATA %1: Client sent FQDN option: %2 +This debug message includes the detailed information extracted from the +Client FQDN option sent in the query. The first argument includes the +client and transaction identification information. The second argument +specifies the detailed information about the FQDN option received +by the server. + +% 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. + +% DHCP4_CLIENT_HOSTNAME_DATA %1: client sent Hostname option: %2 +This debug message includes the detailed information extracted from the +Hostname option sent in the query. The first argument includes the +client and transaction identification information. The second argument +specifies the hostname carried in the Hostname option sent by the +client. + +% DHCP4_CLIENT_NAME_PROC_FAIL %1: failed to process the fqdn or hostname sent by a client: %2 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 -name was malformed or due to internal server error. +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. % DHCP4_COMMAND_RECEIVED received command %1, arguments: %2 A debug message listing the command (and possible arguments) received @@@ -485,70 -357,18 +499,61 @@@ lease from the lease database. It is pr 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 %1, hwaddr %2) tried to release address, %3, but there is no such lease. -This warning message is printed when client attempts to release a lease, -but no such lease is known to the server. +removed from the database during RELEASE message processing. The +first argument includes the client and the transaction identification +information. The second argument holds the IP address which release +was attempted. + +% DHCP4_RELEASE_FAIL_NO_LEASE %1: client is trying to release non-existing lease %2 +This debug message is printed when client attempts to release a lease, +but no such lease is known to the server. The first argument contains +the client and transaction identification information. The second +argument contains the address which the client is trying to release. + - % DHCP4_RELEASE_FAIL_WRONG_CLIENT_ID %1: client tried to release address %2, but this address is leased to different client using client id %3 - This warning message indicates that client tried to release an address - 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 %1: client tried to release address %2, but this address is leased to different client using HW 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. The first argument includes the - client and the transaction identification information. The second - argument includes the address which release was attempted. The - third argumnet includes the HW address of the lease owner. ++% 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. + +% 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_REQUEST_CLASS_PROCESSING_FAILED client class specific processing failed for DHCPREQUEST +% 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. + +% 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 responding with packet type %1, data is <%2> -A debug message listing the data returned to the client. +% 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. % DHCP4_SERVER_FAILED server failed: %1 The DHCPv4 server has encountered a fatal error and is terminating. diff --cc src/bin/dhcp4/dhcp4_srv.cc index 207ee621f3,df45e3ac98..b9924e9f26 --- a/src/bin/dhcp4/dhcp4_srv.cc +++ b/src/bin/dhcp4/dhcp4_srv.cc @@@ -1159,9 -1082,9 +1163,6 @@@ Dhcpv4Srv::assignLease(Dhcpv4Exchange& /// @todo: move subnet selection to a common code resp->setSiaddr(subnet->getSiaddr()); - // Get client-id. It is not mandatory in DHCPv4. - ClientIdPtr client_id = ex.getContext()->clientid_; - LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL_DATA, DHCP4_SUBNET_SELECTED) - .arg(subnet->toText()); -- // Get the server identifier. It will be used to determine the state // of the client. OptionCustomPtr opt_serverid = boost::dynamic_pointer_cast< @@@ -1195,35 -1121,38 +1199,38 @@@ // determine whether the client's notion of the address is correct // and whether the client is known, i.e., has a lease. if (!fake_allocation && !opt_serverid && opt_requested_address) { + + LOG_DEBUG(lease_logger, DBG_DHCP4_DETAIL, DHCP4_INIT_REBOOT) + .arg(query->getLabel()) + .arg(hint.toText()); + Lease4Ptr lease; - if (hwaddr) { - lease = LeaseMgrFactory::instance().getLease4(*hwaddr, - subnet->getID()); + if (client_id) { + lease = LeaseMgrFactory::instance().getLease4(*client_id, subnet->getID()); } - if (!lease && client_id) { - lease = LeaseMgrFactory::instance().getLease4(*client_id, - subnet->getID()); + + if (!lease && hwaddr) { + lease = LeaseMgrFactory::instance().getLease4(*hwaddr, subnet->getID()); } - // Got a lease so we can check the address. - if (lease && (lease->addr_ != hint)) { + + // Check the first error case: unknown client. We check this before + // validating the address sent because we don't want to respond if + // we don't know this client. - /// @todo The client_id logged here should be the client_id from the message - /// rather than effective client id which is null when the - /// match-client-id is set to false. This is addressed by the #3806 - /// which is under review. + if (!lease || !lease->belongsToClient(hwaddr, client_id)) { - LOG_DEBUG(dhcp4_logger, DBG_DHCP4_DETAIL, + LOG_DEBUG(bad_packet_logger, DBG_DHCP4_DETAIL, - DHCP4_PACKET_NAK_0002) + DHCP4_NO_LEASE_INIT_REBOOT) - .arg(hint.toText()) - .arg(client_id ? client_id->toText():"(no client-id)") - .arg(hwaddr ? hwaddr->toText():"(no hwaddr info)"); + .arg(query->getLabel()) + .arg(hint.toText()); - resp->setType(DHCPNAK); - resp->setYiaddr(IOAddress::IPV4_ZERO_ADDRESS()); + ex.deleteResponse(); return; } - // Now check the second error case: unknown client. - if (!lease) { + + // We know this client so we can now check if his notion of the + // IP address is correct. + if (lease && (lease->addr_ != hint)) { LOG_DEBUG(bad_packet_logger, DBG_DHCP4_DETAIL, - DHCP4_NO_LEASE_INIT_REBOOT) + DHCP4_PACKET_NAK_0002) .arg(query->getLabel()) .arg(hint.toText()); @@@ -1680,25 -1608,9 +1697,10 @@@ Dhcpv4Srv::processRelease(Pkt4Ptr& rele return; } - // Does the hardware address match? We don't want one client releasing - // another client's leases. Note that we're comparing the hardware - // addresses only, not hardware types or sources of the hardware - // addresses. Thus we don't use HWAddr::equals(). - if (lease->hwaddr_->hwaddr_ != release->getHWAddr()->hwaddr_) { - LOG_DEBUG(lease_logger, DBG_DHCP4_DETAIL, DHCP4_RELEASE_FAIL_WRONG_HWADDR) + if (!lease->belongsToClient(release->getHWAddr(), client_id)) { - /// @todo add debug message here when we merge the code with the - /// changes from #3806. ++ LOG_DEBUG(lease_logger, DBG_DHCP4_DETAIL, DHCP4_RELEASE_FAIL_WRONG_CLIENT) + .arg(release->getLabel()) - .arg(release->getCiaddr().toText()) - .arg(lease->hwaddr_->toText(false)); - return; - } - - // Does the lease have client-id info? If it has, then check it with what - // the client sent us. - if (lease->client_id_ && client_id && *lease->client_id_ != *client_id) { - LOG_DEBUG(lease_logger, DBG_DHCP4_DETAIL, DHCP4_RELEASE_FAIL_WRONG_CLIENT_ID) - .arg(release->getLabel()) - .arg(release->getCiaddr().toText()) - .arg(lease->client_id_->toText()); ++ .arg(release->getCiaddr().toText()); return; } diff --cc src/lib/dhcpsrv/tests/lease_unittest.cc index 4cfaffb39b,67eed2e700..9292801fd9 --- a/src/lib/dhcpsrv/tests/lease_unittest.cc +++ b/src/lib/dhcpsrv/tests/lease_unittest.cc @@@ -260,11 -256,7 +256,6 @@@ TEST_F(Lease4Test, operatorEquals) // Random values for the tests const uint32_t ADDRESS = 0x01020304; -- const uint8_t HWADDR[] = {0x08, 0x00, 0x2b, 0x02, 0x3f, 0x4e}; - std::vector hwaddr(HWADDR, HWADDR + sizeof(HWADDR)); - const uint8_t CLIENTID[] = {0x17, 0x34, 0xe2, 0xff, 0x09, 0x92, 0x54}; - std::vector clientid_vec(CLIENTID, CLIENTID + sizeof(CLIENTID)); - ClientId clientid(clientid_vec); const time_t current_time = time(NULL); const uint32_t SUBNET_ID = 42; const uint32_t VALID_LIFETIME = 500;