Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-28T16:30:50Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3283CableLabs option (RFC3495): Inconsistent "option_def" usage in client class d...2024-03-28T16:30:50ZPeter DaviesCableLabs option (RFC3495): Inconsistent "option_def" usage in client class definitionsInconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"opt...Inconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" }
],
...
```
However, if this "option-def" is defined within a client class as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
The following message is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '122' in space 'dhcp4'
```
If the "Option_122" "option-def" is changed to private option "224" as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 224, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
Then the following error is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '1' in space 'Option_122_Space'
```
[SF00001775](https://isc.lightning.force.com/lightning/r/Case/500S6000006TLtj/view)kea2.5.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3282Support option-data based on client class AND subnet2024-03-14T14:49:00ZDarren AnkneySupport option-data based on client class AND subnetScenario: A class of clients (ACME Phones) need to receive option 225 "foo" with string content. This string needs to vary depending on the subnet selected. The option-data must not be offered to clients that are NOT ACME Phones.
<det...Scenario: A class of clients (ACME Phones) need to receive option 225 "foo" with string content. This string needs to vary depending on the subnet selected. The option-data must not be offered to clients that are NOT ACME Phones.
<details><summary>Current solution:</summary>
```
{
"Dhcp4": {
"option-def": [
{
"name": "foo",
"code": 225,
"type": "string",
}
],
"client-classes": [
{
"name": "ACMEphone",
"test": "option[60].hex == 'ACME IP Phone'",
"option-data": [
{
"name": "foo",
"data": "'some string 1'"
}
],
"only-if-required": true
},
{
"name": "ACMEphone2",
"test": "option[60].hex == 'ACME IP Phone'",
"option-data": [
{
"name": "foo",
"data": "'some string 2'"
}
],
"only-if-required": true
}
],
"subnet4": [
{
"id": 1,
"subnet": "192.0.2.0/24",
"require-client-classes": [
"ACMEphone"
],
"pools": [
{
"pool": "192.0.2.2 - 192.0.2.254"
}
]
},
{
"id": 2,
"subnet": "192.0.3.0/24",
"require-client-classes": [
"ACMEphone2"
],
"pools": [
{
"pool": "192.0.3.2 - 192.0.3.254"
}
]
}
]
}
}
```
</details>
This solution works but requires adding one client-class per subnet that will need to provide differing parameters to the class of clients in question on a per subnet basis.
This scenario is quite common and was handled previously in ISC DHCP with "if" statements where an "if" statement would be dropped into a subnet as necessary for the clients that might appear there that needed some option content provided with values specific to the subnet selected.
[SF1773](https://isc.lightning.force.com/lightning/r/Case/500S6000006NkOVIA0/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3281Follow-up from "Draft: Resolve "heap-use-after-free and invalid vptr on PingC...2024-03-28T13:38:08ZRazvan BecheriuFollow-up from "Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMgr destruction""The following discussion from !2197 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2197#note_438320 'Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMg...The following discussion from !2197 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2197#note_438320 'Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMgr destruction"'): (+3 comments)
> > To keep the members alive, they can be added to a lambda function which uses a smart pointer to capture the object, but does not use it. It then must be added to the IOService queue using the post function.
>
> I would take the `shared_from_this` alternative anytime if it gets rid of the posts.
>
> If you think that it is too much work for now although it shouldn't be, we can create a ticket, but can you at least add comments to say that they are posted only for extending lifetime?
>
> Core:
>
> ```plaintext
> + getIOService()->post(std::bind(f, queue_mgr_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_, tcp_socket_, tls_socket_));
> ```
>
> Premium:
>
> ```plaintext
> + main_io_service_->post(std::bind(f, expiration_timer_, channel_));
> ```kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3279ddns[46]_update documented argument names incorrect2024-03-27T15:17:48ZPatrick Armitageddns[46]_update documented argument names incorrectsrc/bin/dhcp[46]/dhcp[46]_hooks.dox document arguments _fwd_update_, _rev_update_ and _ddns_params_. Using these parameter names causes an exception to be thrown:
```
ERROR HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook ddns...src/bin/dhcp[46]/dhcp[46]_hooks.dox document arguments _fwd_update_, _rev_update_ and _ddns_params_. Using these parameter names causes an exception to be thrown:
```
ERROR HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook ddns4_update registered by library with index 1 (callout address 0x7fff875b8ffc): unable to find argument with name fwd_update
```
The names for these arguments in the code are _fwd-update_, _rev-update_ and _ddns-param_, i.e. the _'s should be -'s.
The following patch corrects the issue:
```
commit 67063ae09d2c1f924586404eea2fa85a328bccb5 (HEAD -> master)
Author: Quentin Armitage <quentin@armitage.org.uk>
Date: Thu Feb 29 17:44:38 2024 +0000
Fix documentation for ddns[46]_update hooks
The documented argument names fwd_update, rev_update and ddns_params
should be fwd-update, rev_update and ddns-params.
Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
diff --git a/src/bin/dhcp4/dhcp4_hooks.dox b/src/bin/dhcp4/dhcp4_hooks.dox
index ae6c903ff9..ed0620e035 100644
--- a/src/bin/dhcp4/dhcp4_hooks.dox
+++ b/src/bin/dhcp4/dhcp4_hooks.dox
@@ -260,9 +260,9 @@ called before "subnet4_select".
- name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in</b>
- name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
- name: @b hostname, type: std::string, direction: <b>in/out</b>
- - name: @b fwd_update, type: bool, direction: <b>in/out</b>
- - name: @b rev_update, type: bool, direction: <b>in/out</b>
- - name: @b ddns_params, type: isc::dhcp::DdnsParamsPtr, direction: <b>in</b>
+ - name: @b fwd-update, type: bool, direction: <b>in/out</b>
+ - name: @b rev-update, type: bool, direction: <b>in/out</b>
+ - name: @b ddns-params, type: isc::dhcp::DdnsParamsPtr, direction: <b>in</b>
- @b Description: this callout is executed after the server has selected
a lease and has formed a host name to associate with the lease and/or use
@@ -272,17 +272,17 @@ called before "subnet4_select".
host name as well as whether or not forward and/or reverse updates are
enabled.
- Upon entry into the callout, the arguments <b>hostname</b>,<b>fwd_update</b>,
- and <b>rev_update</b> have been set by the server based on the client packet,
+ Upon entry into the callout, the arguments <b>hostname</b>,<b>fwd-update</b>,
+ and <b>rev-update</b> have been set by the server based on the client packet,
and various configuration values (e.g host reservations, DDNS behavioral
parameters, etc). Upon return from the callout, any changes to these
values will be applied as follows:
- If <b>hostname</b> has changed it will be used to update the outbound
host name (option 12) if it exists, the output FQDN option (option 81)
if it exists, and used as the FQDN sent in DNS updates
- - Forward DNS update(s) will be done if <b>fwd_update</b> is true (and
+ - Forward DNS update(s) will be done if <b>fwd-update</b> is true (and
<b>kea-dhcp-ddns</b> connectivity is enabled)
- - Reverse DNS update(s) will be done if <b>rev_update</b> is true (and
+ - Reverse DNS update(s) will be done if <b>rev-update</b> is true (and
<b>kea-dhcp-ddns</b> connectivity is enabled)
- <b>Next step status</b>: Not applicable, its value will be ignored.
```
There appears to be no tests for the ddns[46]_update hooks. Should some be added?kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3277Result YXRRSET for in Dual Stack Environment2024-03-21T14:51:54ZDavid SchmidtResult YXRRSET for in Dual Stack EnvironmentI have a Dual Stack environment with kea-dhcp4-server, kea-dhcp6-server and kea-dhcp-ddns-server.
I am running kea 2.2 on devuan 12, my source code check showed it's an issue in version 2.5.7 still.
DDNS is enabled with conflict resolu...I have a Dual Stack environment with kea-dhcp4-server, kea-dhcp6-server and kea-dhcp-ddns-server.
I am running kea 2.2 on devuan 12, my source code check showed it's an issue in version 2.5.7 still.
DDNS is enabled with conflict resolution for both kea-dhcp servers.
When the DHCP lease is released, DDNS trys to cleanup the regarding A/AAAA RRs and both PTR RRs.
When the cleanup of FwdRRSet is executed in Dual Stack environment, the RRSET cleanup of A resp. AAAA - whatever comes first - will fail with Rcode YXRRSET because the other Fwd RRSET is still there. In case of A removal, the AAAA will still be existing, in case of AAAA removal the A record will still exist. Therefore the prerequisit in buildRemoveFwdRRsRequest() neither A nor AAAA exists won't be fulfilled. This behaviour leads to corrupted PTR entries in DDNS.
To fix the issue I changed the function removingFwdRRsHandler() in src/bin/d2/nc_remove.cc to accept rcode == dns:Rcode::YXRRSET() in case of IO_COMPLETED_EVT also.
```
057 09:28:42.773 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:28:42.773 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:28:42.774 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Add to server: 192.168.x.x port:53
057 09:28:42.787 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:42.787 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:42.787 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Reverse Replace to server: 192.168.x.x port:53
057 09:28:42.796 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:42.796 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:42.796 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [192.168.x.x]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 20240226094842
Lease Length: 1200
Conflict Resolution: yes
057 09:28:43.317 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:28:43.317 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:28:43.318 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Add to server: 192.168.x.x port:53
057 09:28:43.319 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.320 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: YXDOMAIN
057 09:28:43.321 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward Replace to server: 192.168.x.x port:53
057 09:28:43.335 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.335 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:43.336 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Reverse Replace to server: 192.168.x.x port:53
057 09:28:43.344 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:28:43.344 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:28:43.344 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [fdxx::282]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 19700101000000
Lease Length: 2400
Conflict Resolution: yes
057 09:40:04.392 kea-dhcp-ddns.dhcp-to-d2 DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: received and queued a request.
057 09:40:04.393 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_STARTING_TRANSACTION Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5:
057 09:40:04.393 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward A/AAAA Remove to server: 192.168.x.x port:53
057 09:40:04.405 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: NOERROR
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_REQUEST_SENT Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Forward RR Remove to server: 192.168.x.x port:53
057 09:40:04.405 kea-dhcp-ddns.asiodns ASIODNS_FETCH_COMPLETED upstream fetch to 192.168.x.x(53) has now completed
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_UPDATE_RESPONSE_RECEIVED Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: to server: 192.168.x.x port:53 status: SUCCESS, rcode: **YXRRSET**
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns **DHCP_DDNS_FORWARD_REMOVE_RRS_REJECTED** DNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Server, 192.168.x.x port:53, rejected a DNS update request to remove forward RR entries for FQDN, lan-client.xxx.de., with an RCODE: 7
057 09:40:04.405 kea-dhcp-ddns.d2-to-dns DHCP_DDNS_REMOVE_FAILED DHCP_DDNS Request ID 000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5: Transaction outcome: Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse change: failed, request: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [lan-client.xxx.de.]
IP Address: [fdxx::282]
DHCID: [000201C75462DD83B490219141DCF95599F6AA2F60B0E1BB3A7140840FDE38B84301D5]
Lease Expires On: 20240226100843
Lease Length: 2400
Conflict Resolution: yes
```next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3276Kea primary server in "passive backup" freeze/crash on receiving ha-sync2024-03-28T10:34:28ZMarcin GodzinaKea primary server in "passive backup" freeze/crash on receiving ha-syncKea HA server set as `primary` freezes after receiving `ha-sync` command with proper arguments.
The backup server does NOT crash.
Freeze occurs only in `passive-backup` mode.
The problem exists in both v4 and v6. Also, in Memfile and m...Kea HA server set as `primary` freezes after receiving `ha-sync` command with proper arguments.
The backup server does NOT crash.
Freeze occurs only in `passive-backup` mode.
The problem exists in both v4 and v6. Also, in Memfile and mysql/psql lease database.
**Kea versions tested:**
- 2.5.7-git 8c1f22e3fb65225a0279606a8a65962850a5f881
- 2.4.0 release tarball
**Tested systems:**
- Fedora 38 in VM on my local setup.
- Ubuntu 22.04, Alpine 3.16, Fedora 36 on Jenkins build farm.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea HA servers in **Passive backup** configuration (tested configuration provided)
2. Wait for servers to connect.
3. Optionally add leases (crashes either way)
4. Send the `ha-sync` command with proper arguments to the primary server. (`"server-name": "server2"` for provided configuration) (Invalid arguments respond with error)
The primary server freezes after receiving a response to the `dhcp-disable` command, sent automatically to the backup server. It does not respond to kea-ctrl agent, keyboard interrupts or SIGHUP
<details><summary>Commands tested to freeze provided config:</summary>
```
{
command": "ha-sync",
"arguments": {
"server-name": "server2"
}
}
```
```
{
command": "ha-sync",
"arguments": {
"server-name": "server1"
}
}
```
```
{
command": "ha-sync",
"arguments": {
"server-name": "server2",
"max-period": 60
}
}
```
</details>
**Configuration**
<details><summary>Primary</summary>
```
{
"Dhcp4": {
"option-data": [],
"hooks-libraries": [
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"peers": [
{
"auto-failover": true,
"name": "server1",
"role": "primary",
"url": "http://192.168.56.102:8003/"
},
{
"auto-failover": true,
"name": "server2",
"role": "backup",
"url": "http://192.168.56.103:8003/"
}
],
"state-machine": {
"states": []
},
"mode": "passive-backup",
"this-server-name": "server1",
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
}
}
]
}
},
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [],
"subnet4": [
{
"subnet": "192.168.50.0/24",
"pools": [
{
"pool": "192.168.50.1-192.168.50.200"
}
],
"interface": "enp0s9"
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/home/mgodzina/installed/keadev/var/run/kea/control_socket"
},
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "/home/mgodzina/installed/keadev/var/log/kea.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"lease-database": {
"type": "memfile"
}
}
}
```
</details>
<details><summary>Backup</summary>
```
{
"Dhcp4": {
"option-data": [],
"hooks-libraries": [
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"peers": [
{
"auto-failover": true,
"name": "server1",
"role": "primary",
"url": "http://192.168.56.102:8003/"
},
{
"auto-failover": true,
"name": "server2",
"role": "backup",
"url": "http://192.168.56.103:8003/"
}
],
"state-machine": {
"states": []
},
"mode": "passive-backup",
"this-server-name": "server2",
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
}
}
]
}
},
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [],
"subnet4": [
{
"subnet": "192.168.50.0/24",
"pools": [
{
"pool": "192.168.50.1-192.168.50.200"
}
],
"interface": "enp0s9"
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/home/mgodzina/installed/keadev/var/run/kea/control_socket"
},
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "/home/mgodzina/installed/keadev/var/log/kea.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"lease-database": {
"type": "memfile"
}
}
}
```
</details>
**Logs**
<details><summary>Primary server log tail</summary>
```
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.commands/2096.139741364354944] COMMAND_SOCKET_CONNECTION_OPENED Opened socket 38 for incoming command connection
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.commands/2096.139741364354944] COMMAND_SOCKET_READ Received 127 bytes over command socket 38
2024-02-28 16:20:13.417 INFO [kea-dhcp4.commands/2096.139741364354944] COMMAND_RECEIVED Received command 'ha-sync'
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.callouts/2096.139741364354944] HOOKS_CALLOUTS_BEGIN begin all callouts for hook $ha_sync
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_CLIENT_REQUEST_SEND sending HTTP request POST / HTTP/1.1 to http://192.168.56.103:8003/
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_CLIENT_REQUEST_SEND_DETAILS detailed information about request sent to http://192.168.56.103:8003/:
POST / HTTP/1.1
Host: 192.168.56.103
Content-Length: 86
Content-Type: application/json
{ "arguments": { "origin": 2000 }, "command": "dhcp-disable", "service": [ "dhcp4" ] }
2024-02-28 16:20:13.417 INFO [kea-dhcp4.ha-hooks/2096.139741364354944] HA_SYNC_START server1: starting lease database synchronization with server2
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_SERVER_RESPONSE_RECEIVED received HTTP response from http://192.168.56.103:8003/
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_SERVER_RESPONSE_RECEIVED_DETAILS detailed information about well-formed response received from http://192.168.56.103:8003/:
HTTP/1.1 200 OK
Content-Length: 54
Content-Type: application/json
Date: Wed, 28 Feb 2024 15:20:13 GMT
[ { "result": 0, "text": "DHCPv4 service disabled" } ]
```
</details>
<details><summary>Backup server log snippet with timeout:</summary>
```
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_REQUEST_RECEIVE_START start receiving request from 192.168.56.102 with timeout 10
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_DATA_RECEIVED received 179 bytes from 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_CLIENT_REQUEST_RECEIVED received HTTP request from 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_CLIENT_REQUEST_RECEIVED_DETAILS detailed information about well-formed request received from 192.168.56.102:
POST / HTTP/1.1
Host: 192.168.56.103
Content-Length: 86
Content-Type: application/json
{ "arguments": { "origin": 2000 }, "command": "dhcp-disable", "service": [ "dhcp4" ] }
2024-02-28 16:20:13.413 INFO [kea-dhcp4.commands/20519.140151306917568] COMMAND_RECEIVED Received command 'dhcp-disable'
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUTS_BEGIN begin all callouts for hook command_processed
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook command_processed that has address 0x7f778767ffe0 (callout duration: 0.000 ms)
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUTS_COMPLETE completed callouts for hook command_processed (total callouts duration: 0.000 ms)
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_SERVER_RESPONSE_SEND sending HTTP response HTTP/1.1 200 OK to 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_SERVER_RESPONSE_SEND_DETAILS detailed information about response sent to 192.168.56.102:
HTTP/1.1 200 OK
Content-Length: 54
Content-Type: application/json
Date: Wed, 28 Feb 2024 15:20:13 GMT
[ { "result": 0, "text": "DHCPv4 service disabled" } ]
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.033 ms
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.032 ms
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:37.891 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.027 ms
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:43.433 DEBUG [kea-dhcp4.http/20519.140151315310272] HTTP_IDLE_CONNECTION_TIMEOUT_OCCURRED closing persistent connection with 192.168.56.102 as a result of a timeout
2024-02-28 16:20:43.433 DEBUG [kea-dhcp4.http/20519.140151315310272] HTTP_CONNECTION_STOP stopping HTTP connection from 192.168.56.102
```
</details>
[gdb.txt](/uploads/de79e56462885f7947eab90267f7a658/gdb.txt)kea2.5.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3275Kea DB allows to store too short identifier in the lease table2024-03-21T14:50:56ZSlawek FigielKea DB allows to store too short identifier in the lease tableWhile performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it b...While performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it blocks fetching this lease by API. I don't know if it has any other internal consequences.
Steps to reproduce:
1. Setup Kea 2.3.8 or above with PostgreSQL.
2. Configure lease database.
3. Insert a lease with too short DUID (e.g., `00`)
```
INSERT INTO lease6(address, duid, valid_lifetime, expire, subnet_id, pref_lifetime, lease_type, iaid, prefix_len, hwtype, hwaddr_source, state) VALUES('3001:db8:1::2', DECODE('00', 'hex'), 3600, NOW() + interval '1' MONTH, 1, 1800, 0, 1, 128, 0, 0, 1);
```
4. Send the `lease-get` command with the specified address (i.e., `3001:db8:1::2`).
5. Observe the error:
```
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command lease6-get received from remote address 127.0.0.1
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | ERROR LEASE_CMDS_GET6_FAILED lease6-get command failed (parameters: { "ip-address": "3001:db8:1::2", "type": "IA_NA" }, reason: Could not convert data to Lease6, reason: identifier is too short (1), at least 3 is required)
stork-agent-kea6-1 | ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $lease6_get registered by library with index 1 (callout address 0x7f12e8310e90) (callout duration 0.593 ms)
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_FORWARDED command lease6-get successfully forwarded to the service dhcp6 from remote address 127.0.0.1
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3274Synchronous run script2024-03-14T14:37:11ZAndrei Pavelandrei@isc.orgSynchronous run scriptAs ARM states
> Currently, enabling synchronous calls to external scripts is not supported.
Sync run script is not supported.
With the addition of sync process spawn functionality in issue 3025, this is now doable.As ARM states
> Currently, enabling synchronous calls to external scripts is not supported.
Sync run script is not supported.
With the addition of sync process spawn functionality in issue 3025, this is now doable.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3273Upgrade schema on startup2024-03-14T14:36:20ZAndrei Pavelandrei@isc.orgUpgrade schema on startupKea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.Kea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3272Refactor ProcessSpawn2024-03-14T14:34:16ZAndrei Pavelandrei@isc.orgRefactor ProcessSpawnThere are a few things that could be improved in the ProcessSpawn implementation. They become more apparent now that the synchronous functionality has been added to it, but the issues were present before too.
- The asynchronous implemen...There are a few things that could be improved in the ProcessSpawn implementation. They become more apparent now that the synchronous functionality has been added to it, but the issues were present before too.
- The asynchronous implementation of ProcessSpawn relies on having a global IO signal set and on having the IO service being periodically polled in order to wait for child processes which is why it uses the main IO service. For this reason:
- There needs to be a dedicated AsyncProcessSpawn class that should be a singleton to signal to the developer that it has global dependency objects.
- There needs to be a method in AsyncProcessSpawn that sets the IO service. It needs to be callable only once and called as close as possible to the creation of the main IO service. Spawning would throw if the IO service is not initialized. This is to avoid the current behavior which sets the IO service on the first ProcessSpawn creation which could be on a null IOServicePtr. See `src/hooks/dhcp/run_script/run_script.cc` or `src/hooks/dhcp/forensic_log/rotating_file.cc`.
- There should be a new class encapsulating the synchronous implementation, say `SyncProcessSpawn`. It does not have to be a singleton since waiting for the child process is done in the scope it was declared, and the object can be safely deleted afterwards.
- It is worth considering to change the sync variant to use an IO signal set and an IO service like the async variant, but these should not be global, but declarable by the developer, or even better, hidden by the implementation.
- The dismiss feature in spawn is not used in code. I suggest removing it.
- The async process spawn is currently fire-and-forget. It would be nice for the async process spawn to have the ability to be notified that the process has finished and that its status is available. Maybe with the help of a condition variable?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3269Possible problem with RADIUS and shared networks2024-03-25T14:08:01ZFrancis DupontPossible problem with RADIUS and shared networksRADIUS uses the (re)selected subnet to fetch a cached host entry: this is not correct with shared networks where it should try all subnets of the shared networks without a guard incompatible with the query. And when RADIUS creates a new ...RADIUS uses the (re)selected subnet to fetch a cached host entry: this is not correct with shared networks where it should try all subnets of the shared networks without a guard incompatible with the query. And when RADIUS creates a new host entry for a reserved address it uses the (re)selected subnet instead of a subnet where the address belongs.
These two problems can make RADIUS to fail to find a cached entry: not a bug as the server will return the informations but not without performance impact...next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3268selectSubnet() should return a ConstSubnetXPtr2024-03-18T09:34:02ZFrancis DupontselectSubnet() should return a ConstSubnetXPtrTwo proposals to improve subnets:
- use for getSubnet the same code as for getBySubnetId (so O(log(N)) vs current O(N))
- selectSubnet should return a ConstSubnetXPtr i.e. `boost::shared_ptr<const SubnetX>`
The first proposal is trivi...Two proposals to improve subnets:
- use for getSubnet the same code as for getBySubnetId (so O(log(N)) vs current O(N))
- selectSubnet should return a ConstSubnetXPtr i.e. `boost::shared_ptr<const SubnetX>`
The first proposal is trivial tp implement so should be done ASAP if there is no good reason to keep the current full scan.
The second proposal is more complex: if a SubnetXPtr can be cast to a ConstSubnetXPtr it is not true for boost::any_cast (so for hook parameters) and of course it requires to not use a not const method (but as there is no reason to modify the subnet returned by selectSubnet one can consider that all not modifying methods should be const methods...).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3259IP allocation fails for reserved client with assingned class2024-03-28T14:57:21ZMichal ŠnajdrIP allocation fails for reserved client with assingned classHello,
using KEA 2.4.1 and experiencing issue with assigning addresses to PXE clients with configured class for assigning different boot image depending on option 60.
I have anonymized MAC to aa:bb:cc:dd:ee:ff from real one and also an...Hello,
using KEA 2.4.1 and experiencing issue with assigning addresses to PXE clients with configured class for assigning different boot image depending on option 60.
I have anonymized MAC to aa:bb:cc:dd:ee:ff from real one and also anonymized IPs.
Same behavior for multiple hosts in multiple subnets, following one host for example. No issue on segments using reservations and not using client-class.
3 messages are logged for each DISCOVERY.
```plaintext
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: failed to allocate an IPv4 lease in the subnet 10.10.10.0/24, subnet-id 1251066000, shared network (none)
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_NO_POOLS [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: no pools were available for the address allocation
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: Failed to allocate an IPv4 address for client with classes: ALL, HA_dhcp-srv1.company.cz, archi00, UNKNOWN
```
As seen from log, subnet is correctly recognized and it doesn't have any pool. Checked that configuration file with segment definition is included.
Subnet definition, only reservations (shortened to one host, all reservations defined in same format, no typo on MAC, checked):
```plaintext
{
"subnet": "10.10.10.0/24",
"id": 1251066000,
"option-data": [
{
"name": "routers",
"data": "10.10.10.1"
},
{
"name": "domain-name",
"data": "company.cz"
}
],
"next-server": "10.30.30.30",
"reservations": [
.......
{
#"hostname": "server.company.cz",
"hw-address": "aa:bb:cc:dd:ee:ff",
"ip-address": "10.10.10.57"
},
.......
]
};
```
Configuration of client-classes:
```plaintext
"client-classes": [
{
"name": "archi07",
"test": "(substring(option[60].hex,0,20) == 'PXEClient:Arch:00007') and (pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1)",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/x86_64-efi/core.efi"
}
]
},
{
"name": "archi09",
"test": "(substring(option[60].hex,0,20) == 'PXEClient:Arch:00009') and (pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1)",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/x86_64-efi/core.efi"
}
]
},
{
"name": "archi00",
"test": "(pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1) and (not member ('archi07') or not member ('archi09'))",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/i386-pc/core.0"
}
]
}
],
```
We had switched back to old isc-dhcp-server for affected segments for now. There clients are assigned with address.
Do we miss something or is this a bug?
Thanks Michaloutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3257ddns-update-on-renew and cache-threshold still produce ddns updates2024-03-27T12:52:01ZDarren Ankneyddns-update-on-renew and cache-threshold still produce ddns updatesIf a Kea server (2.4.1) has these settings:
```
...
"cache-threshold": 0.25,
"ddns-update-on-renew": true,
...
```
and a client renews their lease at under 25% of the lease length, ddns updates are still sent.
```
$ sudo tail -f /var/lo...If a Kea server (2.4.1) has these settings:
```
...
"cache-threshold": 0.25,
"ddns-update-on-renew": true,
...
```
and a client renews their lease at under 25% of the lease length, ddns updates are still sent.
```
$ sudo tail -f /var/log/kea/kea-dhcp4.log | egrep 'DHCP4_LEASE_REUSE|DHCPSRV_DHCP_DDNS_NCR_SENT'
2024-02-15 16:46:35.032 INFO [kea-dhcp4.leases/1192.140241126283008] DHCP4_LEASE_REUSE [hwtype=1 c8:7f:54:9e:cf:c8], cid=[01:c8:7f:54:9e:cf:c8], tid=0x17c6ef6f: lease 192.168.20.20 has been reused for 24845 seconds
2024-02-15 16:46:35.033 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
2024-02-15 16:46:35.033 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
2024-02-15 16:46:40.807 INFO [kea-dhcp4.leases/1192.140241159853824] DHCP4_LEASE_REUSE [hwtype=1 c8:7f:54:9e:cf:c8], cid=[01:c8:7f:54:9e:cf:c8], tid=0xfbfead04: lease 192.168.20.20 has been reused for 24840 seconds
2024-02-15 16:46:40.807 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
2024-02-15 16:46:40.808 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
```
The customer who brought this to our attention notes:
> While looking at some customer logs I noticed that we were both reusing a lease and doing DDNS update for that reused lease. It seems like if a lease is being reused and therefore it doesn't have any changes to the client DNS name that Kea shouldn't redo the DDNS even if the configuration has update on renew enabled. As soon as the device renews outside of the threshold window I would expect it to do a DDNS update based on the update on renew option.
I've looked at the code and the design. It appears that in dhcp4_srv.cc:assignLease() the call to createNameChangeRequests() is called without checking the threshold and the threshold isn't checked within that function.
The design doesn't explicitly say anything but seems to suggest that the DDNS update shouldn't be done if a lease is reused.
I am unsure if this is a feature request or a bug report as I am not sure of the intended behavior here. It seems like it would be preferable to reduce load by not sending ddns updates on a reused lease.
[SF1707](https://isc.lightning.force.com/lightning/r/Case/500S6000005OUblIAG/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3256fix issues pointed out in 2.5.5 sanity checks2024-03-27T13:51:03ZWlodzimierz Wencelfix issues pointed out in 2.5.5 sanity checkscomments copied from isc-projects/kea#3238
1.
couple unused warnings reported on freebsd-13.0-amd64 when running distcheck:
```
18:49:50 --- run_unittests-interval_timer_unittest.o ---
18:49:50 ../../../../../../src/lib/asiolink/test...comments copied from isc-projects/kea#3238
1.
couple unused warnings reported on freebsd-13.0-amd64 when running distcheck:
```
18:49:50 --- run_unittests-interval_timer_unittest.o ---
18:49:50 ../../../../../../src/lib/asiolink/tests/interval_timer_unittest.cc:55:28: warning: private field 'test_obj_' is not used [-Wunused-private-field]
18:49:50 IntervalTimerTest* test_obj_;
18:49:50 ^
18:49:50 ../../../../../../src/lib/asiolink/tests/interval_timer_unittest.cc:141:28: warning: private field 'test_obj_' is not used [-Wunused-private-field]
18:49:50 IntervalTimerTest* test_obj_;
18:49:50 ^
18:49:50 2 warnings generated.
```
```
18:49:50 CXX run_unittests-tls_listener_unittests.o
18:49:50 ../../../../../../src/lib/tcp/tests/tls_listener_unittests.cc:38:12: warning: unused variable 'REQUEST_TIMEOUT' [-Wunused-const-variable]
18:49:50 const long REQUEST_TIMEOUT = 10000;
18:49:50 ^
18:49:50 ../../../../../../src/lib/tcp/tests/tls_listener_unittests.cc:42:12: warning: unused variable 'SHORT_REQUEST_TIMEOUT' [-Wunused-const-variable]
18:49:50 const long SHORT_REQUEST_TIMEOUT = 200;
18:49:50 ^
18:49:50 2 warnings generated.
18:49:50 --- run_unittests-tcp_listener_unittests.o ---
18:49:50 ../../../../../../src/lib/tcp/tests/tcp_listener_unittests.cc:43:12: warning: unused variable 'REQUEST_TIMEOUT' [-Wunused-const-variable]
18:49:50 const long REQUEST_TIMEOUT = 10000;
18:49:50 ^
18:49:50 ../../../../../../src/lib/tcp/tests/tcp_listener_unittests.cc:47:12: warning: unused variable 'SHORT_REQUEST_TIMEOUT' [-Wunused-const-variable]
18:49:50 const long SHORT_REQUEST_TIMEOUT = 200;
18:49:50 ^
18:49:50 2 warnings generated.
18:49:50 --- run_unittests ---
```
```
18:49:50 CXX libkea_dhcpsrv_la-ncr_generator.lo
18:49:50 --- libkea_dhcpsrv_la-mysql_lease_mgr.lo ---
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_lease_mgr.cc:89:14: warning: unused variable 'HOSTNAME_MAX_LEN' [-Wunused-const-variable]
18:49:50 const size_t HOSTNAME_MAX_LEN = 255;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_lease_mgr.cc:95:14: warning: unused variable 'ADDRESS6_TEXT_MAX_LEN' [-Wunused-const-variable]
18:49:50 const size_t ADDRESS6_TEXT_MAX_LEN = 39;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_lease_mgr.cc:98:14: warning: unused variable 'USER_CONTEXT_MAX_LEN' [-Wunused-const-variable]
18:49:50 const size_t USER_CONTEXT_MAX_LEN = 8192;
18:49:50 ^
18:49:50 3 warnings generated.
18:49:50 --- libkea_dhcpsrv_la-mysql_host_data_source.lo ---
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1803:25: warning: unused variable 'OPTION_ID_COL' [-Wunused-const-variable]
18:49:50 static const size_t OPTION_ID_COL = 0;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1804:25: warning: unused variable 'CODE_COL' [-Wunused-const-variable]
18:49:50 static const size_t CODE_COL = 1;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1805:25: warning: unused variable 'VALUE_COL' [-Wunused-const-variable]
18:49:50 static const size_t VALUE_COL = 2;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1806:25: warning: unused variable 'FORMATTED_VALUE_COL' [-Wunused-const-variable]
18:49:50 static const size_t FORMATTED_VALUE_COL = 3;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1807:25: warning: unused variable 'SPACE_COL' [-Wunused-const-variable]
18:49:50 static const size_t SPACE_COL = 4;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1808:25: warning: unused variable 'PERSISTENT_COL' [-Wunused-const-variable]
18:49:50 static const size_t PERSISTENT_COL = 5;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1809:25: warning: unused variable 'CANCELLED_COL' [-Wunused-const-variable]
18:49:50 static const size_t CANCELLED_COL = 6;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1810:25: warning: unused variable 'USER_CONTEXT_COL' [-Wunused-const-variable]
18:49:50 static const size_t USER_CONTEXT_COL = 7;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1811:25: warning: unused variable 'DHCP_SUBNET_ID_COL' [-Wunused-const-variable]
18:49:50 static const size_t DHCP_SUBNET_ID_COL = 8;
18:49:50 ^
18:49:50 ../../../../../src/lib/dhcpsrv/mysql_host_data_source.cc:1812:25: warning: unused variable 'HOST_ID_COL' [-Wunused-const-variable]
18:49:50 static const size_t HOST_ID_COL = 9;
18:49:50 ^
18:49:50 10 warnings generated.
```
on ubuntu-20.04-amd64 and ubuntu-22.04-amd64 running distcheck:
```
19:19:17 make[6]: Entering directory '/home/ubuntu/workspace/kea-dev/ut-distcheck/kea-2.5.5-git/_build/sub/src/lib/mysql'
19:19:17 CXX mysql_connection.lo
19:19:17 CXX mysql_binding.lo
19:19:17 ../../../../../src/lib/mysql/mysql_connection.cc: In member function ‘void isc::db::MySqlConnection::openDatabase()’:
19:19:17 ../../../../../src/lib/mysql/mysql_connection.cc:231:34: warning: ‘bool mysql_ssl_set(MYSQL*, const char*, const char*, const char*, const char*, const char*)’ is deprecated: Use mysql_options() instead. [-Wdeprecated-declarations]
19:19:17 231 | cipher_list);
19:19:17 | ^
19:19:17 In file included from ../../../../../src/lib/mysql/mysql_constants.h:10,
19:19:17 from ../../../../../src/lib/mysql/mysql_binding.h:18,
19:19:17 from ../../../../../src/lib/mysql/mysql_connection.h:15,
19:19:17 from ../../../../../src/lib/mysql/mysql_connection.cc:12:
19:19:17 /usr/include/mysql/mysql.h:464:1: note: declared here
19:19:17 464 | mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert, const char *ca,
19:19:17 | ^~~~~~~~~~~~~
19:19:17 ../../../../../src/lib/mysql/mysql_connection.cc:231:34: warning: ‘bool mysql_ssl_set(MYSQL*, const char*, const char*, const char*, const char*, const char*)’ is deprecated: Use mysql_options() instead. [-Wdeprecated-declarations]
19:19:17 231 | cipher_list);
19:19:17 | ^
19:19:17 In file included from ../../../../../src/lib/mysql/mysql_constants.h:10,
19:19:17 from ../../../../../src/lib/mysql/mysql_binding.h:18,
19:19:17 from ../../../../../src/lib/mysql/mysql_connection.h:15,
19:19:17 from ../../../../../src/lib/mysql/mysql_connection.cc:12:
19:19:17 /usr/include/mysql/mysql.h:464:1: note: declared here
19:19:17 464 | mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert, const char *ca,
19:19:17 | ^~~~~~~~~~~~~
```
```
19:19:17
19:19:17 [----------] 20 tests from MySqlConnectionTest
19:19:17 [ RUN ] MySqlConnectionTest.select
19:19:17 WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
19:19:17 [ OK ] MySqlConnectionTest.select (861 ms)
19:19:17 [ RUN ] MySqlConnectionTest.selectNullInteger
19:19:17 WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
```
running ut-extended on debian-11-aarch64 and debian-12-aarch64:
```
16:06:36 /bin/bash ../../../libtool --tag=CXX --mode=compile ccache c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DOS_LINUX -I../../.. -I../../.. -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC -g3 -ggdb -O0 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -MT simple_parser.lo -MD -MP -MF .deps/simple_parser.Tpo -c -o simple_parser.lo simple_parser.cc
16:06:36 libtool: compile: ccache c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DOS_LINUX -I../../.. -I../../.. -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC -g3 -ggdb -O0 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -MT server_tag.lo -MD -MP -MF .deps/server_tag.Tpo -c server_tag.cc -fPIC -DPIC -o .libs/server_tag.o
16:06:36 libtool: compile: ccache c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DOS_LINUX -I../../.. -I../../.. -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC -g3 -ggdb -O0 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -MT simple_parser.lo -MD -MP -MF .deps/simple_parser.Tpo -c simple_parser.cc -fPIC -DPIC -o .libs/simple_parser.o
16:06:37 data.cc: In member function ‘virtual void isc::data::StringElement::toJSON(std::ostream&) const’:
16:06:37 data.cc:905:21: warning: comparison is always true due to limited range of data type [-Wtype-limits]
16:06:37 905 | if (((c >= 0) && (c < 0x20)) || (c < 0) || (c >= 0x7f)) {
16:06:37 | ~~^~~~
16:06:37 data.cc:905:48: warning: comparison is always false due to limited range of data type [-Wtype-limits]
16:06:37 905 | if (((c >= 0) && (c < 0x20)) || (c < 0) || (c >= 0x7f)) {
16:06:37 |
```
```
16:08:33 /bin/bash ../../../libtool --tag=CXX --mode=compile ccache c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DOS_LINUX -I../../.. -I../../.. -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC -g3 -ggdb -O0 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -MT libkea_http_la-http_message_parser_base.lo -MD -MP -MF .deps/libkea_http_la-http_message_parser_base.Tpo -c -o libkea_http_la-http_message_parser_base.lo `test -f 'http_message_parser_base.cc' || echo './'`http_message_parser_base.cc
16:08:33 libtool: compile: ccache c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DOS_LINUX -I../../.. -I../../.. -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC -g3 -ggdb -O0 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -MT libkea_http_la-http_message_parser_base.lo -MD -MP -MF .deps/libkea_http_la-http_message_parser_base.Tpo -c http_message_parser_base.cc -fPIC -DPIC -o .libs/libkea_http_la-http_message_parser_base.o
16:08:33 http_message_parser_base.cc: In member function ‘bool isc::http::HttpMessageParserBase::isChar(char) const’:
16:08:33 http_message_parser_base.cc:266:15: warning: comparison is always true due to limited range of data type [-Wtype-limits]
16:08:33 266 | return (c >= 0);
16:08:33 | ~~^~~~
16:08:33 http_message_parser_base.cc: In member function ‘bool isc::http::HttpMessageParserBase::isCtl(char) const’:
16:08:33 http_message_parser_base.cc:271:17: warning: comparison is always true due to limited range of data type [-Wtype-limits]
16:08:33 271 | return (((c >= 0) && (c <= 31)) || (c == 127));
16:08:33 |
```
2.
On macOS 14.2.1 got a build problem during sanity checks:
```
mysql_legal_log.cc:33:1: error: implicit instantiation of undefined template 'boost::array<isc::db::TaggedStatement, 1>'
tagged_statements = { {
^
/usr/local/include/boost/lexical_cast/detail/converter_lexical.hpp:56:11: note: template is declared here
class array;
^
1 error generated.
```
Fixed by adding an explicit include of boost/array.hpp
3.
compilation erro on macOS:
```
mysql_connection.cc:230:9: error: use of undeclared identifier 'mysql_ssl_set'
mysql_ssl_set(mysql_, key_file, cert_file, ca_file, ca_dir,
^
1 error generated.
make[5]: *** [mysql_connection.lo] Error 1
```
fix:
```
< mysql_ssl_set(mysql_, key_file, cert_file, ca_file, ca_dir,
< cipher_list);
---
> mysql_options(mysql_, MYSQL_OPT_SSL_KEY, key_file);
> mysql_options(mysql_, MYSQL_OPT_SSL_CERT, cert_file);
> mysql_options(mysql_, MYSQL_OPT_SSL_CA, ca_file);
> mysql_options(mysql_, MYSQL_OPT_SSL_CAPATH, ca_dir);
> mysql_options(mysql_, MYSQL_OPT_SSL_CIPHER, cipher_list); cipher_list);
```
4.
also minor:
```
../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
./mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_impl.cc:9:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:535:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
mysql_cb_impl.cc:208:11: note: in instantiation of function template specialization 'isc::db::MySqlConnection::insertQuery<int>' requested here
conn_.insertQuery(index, in_bindings);
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_impl.cc:9:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:460:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
status = mysql_stmt_bind_param(getStatement(index),
^
mysql_cb_impl.cc:247:15: note: in instantiation of function template specialization 'isc::db::MySqlConnection::selectQuery<int>' requested here
conn_.selectQuery(index, in_bindings, out_bindings,
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_callouts.cc:16:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
./mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp6.cc:10:
In file included from ./mysql_cb_dhcp6.h:10:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
./mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp4.cc:9:
In file included from ./mysql_cb_dhcp4.h:10:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
./mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp6.cc:10:
In file included from ./mysql_cb_dhcp6.h:10:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
mysql_cb_dhcp6.cc:251:19: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<isc::dhcp::MySqlConfigBackendDHCPv6Impl::StatementIndex>' requested here
if (conn_.updateDeleteQuery(MySqlConfigBackendDHCPv6Impl::UPDATE_GLOBAL_PARAMETER6,
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp6.cc:10:
In file included from ./mysql_cb_dhcp6.h:10:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:535:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
mysql_cb_dhcp6.cc:257:19: note: in instantiation of function template specialization 'isc::db::MySqlConnection::insertQuery<isc::dhcp::MySqlConfigBackendDHCPv6Impl::StatementIndex>' requested here
conn_.insertQuery(MySqlConfigBackendDHCPv6Impl::INSERT_GLOBAL_PARAMETER6,
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp6.cc:10:
In file included from ./mysql_cb_dhcp6.h:10:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:460:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
status = mysql_stmt_bind_param(getStatement(index),
^
mysql_cb_dhcp6.cc:407:15: note: in instantiation of function template specialization 'isc::db::MySqlConnection::selectQuery<isc::dhcp::MySqlConfigBackendDHCPv6Impl::StatementIndex>' requested here
conn_.selectQuery(index, in_bindings, out_bindings,
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp4.cc:9:
In file included from ./mysql_cb_dhcp4.h:10:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
mysql_cb_dhcp4.cc:242:19: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<isc::dhcp::MySqlConfigBackendDHCPv4Impl::StatementIndex>' requested here
if (conn_.updateDeleteQuery(MySqlConfigBackendDHCPv4Impl::UPDATE_GLOBAL_PARAMETER4,
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp4.cc:9:
In file included from ./mysql_cb_dhcp4.h:10:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:535:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
mysql_cb_dhcp4.cc:248:19: note: in instantiation of function template specialization 'isc::db::MySqlConnection::insertQuery<isc::dhcp::MySqlConfigBackendDHCPv4Impl::StatementIndex>' requested here
conn_.insertQuery(MySqlConfigBackendDHCPv4Impl::INSERT_GLOBAL_PARAMETER4,
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp4.cc:9:
In file included from ./mysql_cb_dhcp4.h:10:
In file included from ./mysql_cb_impl.h:25:
../../../../src/lib/mysql/mysql_connection.h:460:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
status = mysql_stmt_bind_param(getStatement(index),
^
mysql_cb_dhcp4.cc:371:15: note: in instantiation of function template specialization 'isc::db::MySqlConnection::selectQuery<isc::dhcp::MySqlConfigBackendDHCPv4Impl::StatementIndex>' requested here
conn_.selectQuery(index, in_bindings, out_bindings,
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
```
```
In file included from mysql_cb_impl_unittest.cc:8:
In file included from ../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_impl.h:25:
../../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
1 warning generated.
In file included from mysql_cb_dhcp4_mgr_unittest.cc:10:
In file included from ../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_dhcp4.h:10:
In file included from ../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_impl.h:25:
../../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp6_mgr_unittest.cc:10:
In file included from ../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_dhcp6.h:10:
In file included from ../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_impl.h:25:
../../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
1 warning generated.
1 warning generated.
In file included from mysql_cb_dhcp4_unittest.cc:15:
In file included from ../../../../../src/lib/dhcpsrv/testutils/mysql_generic_backend_unittest.h:11:
../../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
In file included from mysql_cb_dhcp6_unittest.cc:15:
In file included from ../../../../../src/lib/dhcpsrv/testutils/mysql_generic_backend_unittest.h:11:
../../../../../src/lib/mysql/mysql_connection.h:579:22: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(getStatement(index),
^
../../../../../src/hooks/dhcp/mysql_cb/mysql_cb_impl.h:294:23: note: in instantiation of function template specialization 'isc::db::MySqlConnection::updateDeleteQuery<int>' requested here
return (conn_.updateDeleteQuery(index, in_bindings));
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
1 warning generated.
```
```
mysql_legal_log.cc:382:18: warning: 'mysql_stmt_bind_param' is deprecated: Use mysql_stmt_bind_named_param() instead. [-Wdeprecated-declarations]
int status = mysql_stmt_bind_param(ctx->conn_.getStatement(INSERT_LOG),
^
/usr/local/Cellar/mysql/8.3.0/include/mysql/mysql.h:764:3: note: 'mysql_stmt_bind_param' has been explicitly marked deprecated here
[[deprecated("Use mysql_stmt_bind_named_param() instead.")]]
^
1 warning generated.
```
Reported by @razvan and @fdupont , thank you :)kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3255CA reconfig doesn't pick up on new certificates2024-02-22T15:00:09ZPeter DaviesCA reconfig doesn't pick up on new certificatesCA reconfig doesn't pick up on new certificates:
After changing the certificates directory in the kea-ctrl-agent configuration
file and sending a SIGHUP signal, kea-ctrl-agent reports
DCTL_CONFIG_COMPLETE server has completed...CA reconfig doesn't pick up on new certificates:
After changing the certificates directory in the kea-ctrl-agent configuration
file and sending a SIGHUP signal, kea-ctrl-agent reports
DCTL_CONFIG_COMPLETE server has completed configuration:
However, the agent still uses the old certificates:
Users that employ the systemd restart command may expect a different behaviour
A workaround would be to kill the process and restart a new one.
[000016830](https://isc.lightning.force.com/lightning/r/Case/500S60000055eAC/view)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3254Include git commit hash for premium in the config report2024-03-22T16:21:17ZAndrei Pavelandrei@isc.orgInclude git commit hash for premium in the config reportThe report includes the git commit hash for core in the config report that can be accessed with the `-W` parameter when Kea was built from sources. It would be nice to have the git commit hash for premium as well, if Kea was built with p...The report includes the git commit hash for core in the config report that can be accessed with the `-W` parameter when Kea was built from sources. It would be nice to have the git commit hash for premium as well, if Kea was built with premium. It could be mentioned under `Extended version:` or under `Premium hooks: yes`.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3252HA multiple relationships and RADIUS reselect are incompatible2024-03-27T15:26:47ZFrancis DupontHA multiple relationships and RADIUS reselect are incompatibleNothing trivial can be done to fix this other to drop the first query (RADIUS hook parks the query at the subnet select callout and knows the right subnet when the RADIUS response is received). For other queries using cached RADIUS infor...Nothing trivial can be done to fix this other to drop the first query (RADIUS hook parks the query at the subnet select callout and knows the right subnet when the RADIUS response is received). For other queries using cached RADIUS information the correctness relies on the order of the HA and RADIUS hooks (RADIUS before HA).kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3251Fix drop statistics in subnet6_select and RADIUS hook2024-03-07T14:55:13ZFrancis DupontFix drop statistics in subnet6_select and RADIUS hookThe pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.The pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3250Unattended terminated state and a reboot2024-03-27T21:53:51ZMarcin SiodelskiUnattended terminated state and a rebootConsider the following case. The clocks on two HA-enabled servers diverge and the clock skew eventually exceeds 60 seconds. As a result, both servers transition to the terminated state. In this state, the servers continue serving DHCP cl...Consider the following case. The clocks on two HA-enabled servers diverge and the clock skew eventually exceeds 60 seconds. As a result, both servers transition to the terminated state. In this state, the servers continue serving DHCP clients but do not exchange the lease updates nor heartbeats. An administrator neglects to correct the clocks and one of the servers reboots. The server enters the `waiting` state and remains in this state hoping that the other server is restarted so they can continue the lease database synchronization and start normal operation. However, the server is unaware that its reboot was not triggered in the course of fixing the clocks, so it will wait for the partner endlessly (or until the administrator comes to work in the morning). The waiting server is not responding to the DHCP traffic until then.
This situation should not occur in a setup where NTP has been enabled. It also should not occur if there is a proper monitoring to detect that the clocks diverge early enough. However, there are chances this situation may happen when all of this is neglected.
The proposed solution is to apply a timeout (could even be several to 10 minutes long) for a server in the waiting state. If the transition of its partner does not occur until this timeout elapses, the server in the waiting state transitions back to the terminated state and continues serving the clients. The waiting server MUST NOT transition to the waiting state immediately after it detects that its partner is in the terminated state to allow enough time to the administrator to reboot the server sequentially after correcting the clocks.
[SF1598](https://isc.lightning.force.com/lightning/r/Case/500S6000003jBs3IAE/view)kea2.5.8