[kea-dev] MySQL host reservations in Github master branch?
Marcin Siodelski
marcin at isc.org
Mon Jul 25 16:33:04 UTC 2016
I attached a patch for the issue which, I believe, should resolve your problem. Can you please verify that it works?
Please do:
$ git apply 0001-master-Recreate-HostMgr-after-re-configuration.patch
and then recompile and reinstall Kea. It doesn't have to be clean rebuild.
I also created Kea ticket: http://kea.isc.org/ticket/4544 to track this problem.
Marcin
On 25.07.2016 16:55, Jeffery Harrell wrote:
> Thank you very much!
>
>
> On July 25, 2016 at 7:54:44 AM, Marcin Siodelski (marcin at isc.org
> <mailto:marcin at isc.org>) wrote:
>
> > I was able to reproduce your problem on Centos 7. The direct problem
> > we're hitting is the *unexpected* closure of the connection to the MySQL
> > database while processing the packet from the client (see the last line
> > of the pasted log below).
> >
> > Because the connection gets closed the server doesn't even look into the
> > database to check for existing reservations.
> >
> > This may be something specific to MariaDB, which I am also using to
> > reproduce the issue. I didn't see it with MySQL-community version,
> > however I may double check.
> >
> > I am planning to investigate it further, and I'll let you know what I
> > find.
> >
> > Marcin
> >
> >
> > 2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.packets/28665] DHCP4_QUERY_DATA
> > [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0,
> > packet details: local_address=192.168.56.2:67 <http://192.168.56.2:67>,
> > remote_adress=192.168.56.1:67 <http://192.168.56.1:67>,
> > msg_type=DHCPDISCOVER (1), transid=0x0,
> > options:
> > type=053, len=001: 1 (uint8)
> > type=055, len=007: 1(uint8) 28(uint8) 2(uint8) 3(uint8) 15(uint8)
> > 6(uint8) 12(uint8)
> > type=061, len=007: 01:00:0c:01:02:03:04
> > 2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.dhcpsrv/28665]
> > DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 192.168.56.0/24
> > <http://192.168.56.0/24> for packet
> > received by matching address 192.168.56.1
> > 2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.packets/28665]
> > DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:04],
> > cid=[01:00:0c:01:02:03:04], tid=0x0: the subnet with ID 1 was selected
> > for client assignments
> > 2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.packets/28665]
> > DHCP4_SUBNET_DATA [hwtype=1 00:0c:01:02:03:04],
> > cid=[01:00:0c:01:02:03:04], tid=0x0: the selected subnet details:
> > 192.168.56.0/24 <http://192.168.56.0/24>
> > 2016-07-25 16:47:27.778 DEBUG [kea-dhcp4.dhcpsrv/28665]
> > HOSTS_CFG_CLOSE_HOST_DATA_SOURCE Closing host data source: mysql
> >
> >
> > On 18.07.2016 18:26, Jeffery Harrell wrote:
> > > Fair enough! I’ll keep this on the public list so it might help others.
> > >
> > > This morning I tried to create as minimal a lab environment as I could.
> > > There’s just the DHCP server and one client, both running CentOS 7.2
> > > with the latest updates. I was able to reproduce the problem. (In fact I
> > > was unable not to.)
> > >
> > > There's a lot of information to share, so I stored most of it in gists.
> > > I hope that's okay.
> > >
> > > Here's my kea.conf file:
> > >
> > > https://gist.github.com/jefferyharrell/dcbd9cc40a533bab493ae06ddcbdb1d7
> > >
> > > This is the good part:
> > >
> > > "subnet4":
> > > [
> > >
> > > {
> > > "id": 199,
> > > "subnet": "10.14.199.0/24 <http://10.14.199.0/24> <http://10.14.199.0/24>",
> > > "valid-lifetime": 120,
> > > "option-data":
> > > [
> > > { "name": "routers", "data": "10.14.199.254" }
> > > ],
> > > "pools": [
> > > { "pool": "10.14.199.201 - 10.14.199.249" }
> > > ]
> > > }
> > >
> > > ]
> > >
> > > I tested both with and without the "pools" declaration. With "pools"
> > > kea-dhcp4 allocates a lease from the pool. Without "pools", kea-dhcp4
> > > fails to allocate a lease. Also the ludicrously short lease lifetime is
> > > a testing parameter; I’ve tried this with longer, more plausible
> > > settings and it made no difference.
> > >
> > > Here's the debug log captured during a reboot of the test client.
> > >
> > > https://gist.github.com/jefferyharrell/0dc515a2d6a9bf639a5e6f8be03e01eb
> > >
> > > This is the good part:
> > >
> > > 2016-07-18 11:03:26.980 DEBUG [kea-dhcp4.hosts/4637]
> > > HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=000C29D4074D,
> > > found 0 host(s)
> > > 2016-07-18 11:03:26.980 DEBUG [kea-dhcp4.hosts/4637]
> > > HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet
> > > id 199 and identifier hwaddr=000C29D4074D
> > >
> > > Despite the protestations in the log file, such a host reservation
> > > really does exist in the database:
> > >
> > > https://gist.github.com/jefferyharrell/17261c44930d83be858bb712a6b72a03
> > >
> > > So what it looks like to me (I AM NOT A DHCP EXPERT) is that kea-dhcp4
> > > is simply failing, for one reason or another, to query MySQL for host
> > > reservations. This is supported by the fact that during the reboot as
> > > logged above, no MySQL queries were executed by the program.
> > >
> > > https://gist.github.com/jefferyharrell/388f8cc282c15b41bfea0accbf9c9f21
> > >
> > > (Immediately after I quit kea-dhcp4, which is where the
> > > close-close-close-quit came from.)
> > >
> > > I was thinking maybe this is a build-environment bug, maybe I'm linking
> > > against a slightly incompatbile version of the MySQL library? But that
> > > library has been around for ages largely unchanged, so that seemed
> > > unlikely, plus there would've been an error reported somewhere, I can
> > > only assume.
> > >
> > > Any thoughts?
> > >
> > > Thanks so much in advance for your help.
> > >
> > >
> > > On July 18, 2016 at 12:30:24 AM, Marcin Siodelski (marcin at isc.org <mailto:marcin at isc.org>
> > > <mailto:marcin at isc.org <mailto:marcin at isc.org>>) wrote:
> > >
> > >> On 17.07.2016 21:24, Jeffery Harrell wrote:
> > >> > I feel like I’m doing something stupid, but I’ll ask anyway: Is it
> > >> > possible that MySQL host reservations are currently not working in the
> > >> > Github master branch?
> > >> >
> > >> > I discovered what I think may be a very obscure bug in 1.0.0 having to
> > >> > do with OFFER replies meant for VMs running on hosts on VLAN trunks (no
> > >> > seriously), so I wanted to check the latest version of the project to
> > >> > see if it’s already been taken care of. I set up a lab system, cloned
> > >> > the repo and made a build with –with-dhcp-mysql. I set up a new database
> > >> > with dhcpdb_create.mysql from Github and inserted a host according to
> > >> > https://kea.isc.org/wiki/HostReservationsHowTo.
> > >> >
> > >> > This test server will happily serve up pool addresses (and will stash
> > >> > the lease info in MySQL, so the database connection is for-sure working)
> > >> > but it completely and obstinately ignores the contents of the hosts
> > >> > database table. I’ve tried both same-subnet and through-a-relay clients
> > >> > and the server claims to be unable to find a host for hardware address
> > >> > such-and-whatever.
> > >> >
> > >> > Here’s the relevant part of my config file:
> > >> >
> > >> > |"interfaces-config": { "interfaces": [ "eth0" ], "dhcp-socket-type":
> > >> > "raw" }, "lease-database": { "type": "mysql", "name": "[REDACTED]",
> > >> > "host": "[REDACTED]", "user": "[REDACTED]", "password": "[REDACTED]" },
> > >> > "hosts-database": { "type": "mysql", "name": "[REDACTED]", "host":
> > >> > "[REDACTED]", "user": "[REDACTED]", "password": "[REDACTED]" },
> > >> > "expired-leases-processing": { "reclaim-timer-wait-time": 10,
> > >> > "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600,
> > >> > "max-reclaim-leases": 100, "max-reclaim-time": 250,
> > >> > "unwarned-reclaim-cycles": 5 }, "option-data": [ { "name":
> > >> > "domain-name-servers", "data": "[REDACTED]" }, { "name":
> > >> > "domain-search", "data": "[REDACTED]" } ], "valid-lifetime": 3600,
> > >> > "subnet4": [ { "id": [REDACTED], "subnet": "[REDACTED]/24",
> > >> > "valid-lifetime": 3600, "option-data": [ { "name": "routers", "data":
> > >> > "[REDACTED]" } ] } ] |
> > >> >
> > >> > And here’s the SQL statement I used to insert the host reservation:
> > >> >
> > >> > |INSERT INTO hosts (dhcp_identifier, dhcp_identifier_type,
> > >> > dhcp4_subnet_id, ipv4_address, hostname) VALUES
> > >> > (UNHEX(REPLACE('[REDACTED]', ':', '')), (SELECT type FROM
> > >> > host_identifier_type WHERE name='hw-address'), [REDACTED],
> > >> > INET_ATON('[REDACTED]'), '[REDACTED]'); |
> > >> >
> > >> > Am I doing something wrong?
> > >> >
> > >>
> > >> I don't see any obvious errors in what you're doing. But, since most of
> > >> the values are "redacted" I can't say if there are any typos in the
> > >> configuration etc.
> > >>
> > >> Host reservations in MySQL should work fine on the latest github
> > >> version. If the server is unable to find the reservation for a client,
> > >> I'd think there is some configuration error. Typically, this might be a
> > >> subnet-id mismatch between the configuration and the value stored in the
> > >> database, or mismatch in the HW address between the host reservation
> > >> entry and the client contacting the server. One more thing is that the
> > >> reserved address can be hijacked by another client at the time when the
> > >> reservation didn't exist. But, if this is a simple test with only one
> > >> client, that's rather unlikely.
> > >>
> > >> I am willing to assist you in further investigating this issue, but I
> > >> don't see much I could do without some additional data. Ideally it
> > >> would be:
> > >> - The contents of the database, e.g. SELECT * FROM hosts;
> > >> - The subnet configuration in Kea, including subnet-id
> > >> - wireshark capture including the communication of this particular
> > >> client with the server.
> > >> - Server log on debug level.
> > >>
> > >> If this is sensitive information you don't want to post to the list,
> > >> you're welcome to contact me privately.
> > >>
> > >> Thanks for trying out Kea!
> > >>
> > >> Marcin Siodeski
> > >> DHCP Software Engineer,
> > >> ISC
> > >>
> > >>
> > >>
> >
-------------- next part --------------
From 11600831c6fe96829dd8dcabddb8f2650cfb213e Mon Sep 17 00:00:00 2001
From: Marcin Siodelski <marcin at isc.org>
Date: Mon, 25 Jul 2016 18:05:33 +0200
Subject: [PATCH] [master] Recreate HostMgr after (re)configuration.
---
src/lib/dhcpsrv/cfg_db_access.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/lib/dhcpsrv/cfg_db_access.cc b/src/lib/dhcpsrv/cfg_db_access.cc
index 571ae18..4601dc9 100644
--- a/src/lib/dhcpsrv/cfg_db_access.cc
+++ b/src/lib/dhcpsrv/cfg_db_access.cc
@@ -7,6 +7,7 @@
#include <config.h>
#include <dhcpsrv/cfg_db_access.h>
#include <dhcpsrv/host_data_source_factory.h>
+#include <dhcpsrv/host_mgr.h>
#include <dhcpsrv/lease_mgr_factory.h>
#include <sstream>
@@ -39,7 +40,7 @@ CfgDbAccess::createManagers() const {
// Recreate host data source.
HostDataSourceFactory::destroy();
if (!host_db_access_.empty()) {
- HostDataSourceFactory::create(getHostDbAccessString());
+ HostMgr::create(getHostDbAccessString());
}
}
--
2.7.4 (Apple Git-66)
More information about the kea-dev
mailing list