<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">Thank you very much!</div> <br> <div id="bloop_sign_1469458511589318144" class="bloop_sign"></div> <br><p class="airmail_on">On July 25, 2016 at 7:54:44 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 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 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>,
<br>remote_adress=<a href="http://192.168.56.1:67">192.168.56.1:67</a>, 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> 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>
<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>>",
<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>
<br>> <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></div></div></span></blockquote></body></html>