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