Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-21T14:57:02Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3292kea 2.4.x: make install fails with python 3.122024-03-21T14:57:02ZNatanael Copakea 2.4.x: make install fails with python 3.12kea 2.4.1 fails to `make install` with python 3.12:
```
...
make[4]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[5]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
/bi...kea 2.4.1 fails to `make install` with python 3.12:
```
...
make[4]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[5]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
/bin/mkdir -p '/home/ncopa/aports/main/kea/pkg/kea/usr/sbin'
/bin/mkdir -p '/home/ncopa/aports/main/kea/pkg/kea/usr/lib/python3.12/site-packages/kea'
/usr/bin/install -c kea-shell '/home/ncopa/aports/main/kea/pkg/kea/usr/sbin'
/usr/bin/install -c -m 644 kea_conn.py kea_connector3.py '/home/ncopa/aports/main/kea/pkg/kea/usr/lib/python3.12/site-packages/kea'
Traceback (most recent call last):
File "<string>", line 2, in <module>
ModuleNotFoundError: No module named 'imp'
make[5]: *** [Makefile:528: install-pkgpythonPYTHON] Error 1
make[5]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[4]: *** [Makefile:740: install-am] Error 2
make[4]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[3]: *** [Makefile:577: install-recursive] Error 1
make[3]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[2]: *** [Makefile:464: install-recursive] Error 1
make[2]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin'
make[1]: *** [Makefile:462: install-recursive] Error 1
make[1]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src'
make: *** [Makefile:649: install-recursive] Error 1
```
From https://docs.python.org/3/whatsnew/3.12.html
> The asynchat, asyncore, and imp modules have been removed, along with several unittest.TestCase method aliases.https://gitlab.isc.org/isc-projects/kea/-/issues/3291stat-lease4-get does not return leases statistics correctly2024-03-15T10:00:43ZJohn Papstat-lease4-get does not return leases statistics correctly**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server'...**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server's CLI using curl. Although there are active leases for clients the Web UI displays 0 for assigned IPs on all subnets. Probably a bug in the stat-lease4-get API command.
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea server 2.0.2, Stork 1.15.0 and run them with the following configs: '...'
2. Configure several subnets.
2. Have 3 VMs act as clients on all subnets and get ip addresses from kea server
3. Clients get IP address but the Stork GUI shows 0 for all lease statistics.
**Expected behavior**
Stork GUI should display the leases statistics for the connected clients.
**Environment:**
- Kea version: 2.0.2
- Stork: 1.15.0
- OS: Ubuntu 22.04 x64
- Kea: Hooks libdhcp_stat_cmds.so, libdhcp_lease_cmds.so
**Additional Information**
Querying the DHCP agent from the stork server using the cli and the management API I figured out that the stat-lease4-get command without arguments returns different results for the same subnet than the stat-lease4-get command having the subnet-id as an argument.
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"]}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 47, 56, 0, 0, 0 ], [ 51, 56, 0, 0, 0 ], [ 66, 41, 0, 0, 0 ] ], "timestamp": "2024-03-08 14:09:09.100431" } }, "result": 0, "text": "stat-lease4-get[all subnets]: 3 rows found" } ]
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"], "arguments": {"subnet-id" : 66}}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 66, 41, 0, 3, 0 ] ], "timestamp": "2024-03-08 14:09:17.884123" } }, "result": 0, "text": "stat-lease4-get[subnet-id=66]: 1 rows found" } ]
The second output above has the correct leases stats for subnet-id 66 while the first output shows 0 leases for subnet-id 66https://gitlab.isc.org/isc-projects/kea/-/issues/3290Clarify application of the ha-scopes command in the actual deployments2024-03-14T15:02:26ZMarcin GodzinaClarify application of the ha-scopes command in the actual deployments`ha-scopes` command can modify servers scopes without changing its role and other HA parameters.
It can be a powerful tool, but its use can put the server in a state that will be very confusing for the Administrator.
I think this comman...`ha-scopes` command can modify servers scopes without changing its role and other HA parameters.
It can be a powerful tool, but its use can put the server in a state that will be very confusing for the Administrator.
I think this command requires more documentation and warnings about its usage.
For example: \
We have a hot standby pair and send the `ha-scopes` command to the `standby` server, enabling scopes of both servers.
This results in `primary` and `standby` servers replying to DHCP traffic. But the second server still reports as in a `standby` state.
This can lead to massive confusion for Administrators.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3289DHCPv4: bad option 81 data (invalid FQDN) causes halt in further processing o...2024-03-14T15:00:06ZDarren AnkneyDHCPv4: bad option 81 data (invalid FQDN) causes halt in further processing of packetA packet with option 81 attached with an empty label causes further processing of the client's DHCPv4 packet to cease and the packet to be dropped.
This is very simple to reproduce with the following
<details><summary>Simple configurat...A packet with option 81 attached with an empty label causes further processing of the client's DHCPv4 packet to cease and the packet to be dropped.
This is very simple to reproduce with the following
<details><summary>Simple configuration</summary>
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"option-data": [
{
"name": "domain-name-servers",
"data": "10.0.0.1"
}
],
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100-10.1.2.200"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
and sending packets with malformed FQDN using `perfdhcp`:
```
perfdhcp -4 -r 1 -p 10 -l ens256 -R 1 -o 81,0100002E656D7074792E6C6162656C2E6578616D706C652E636F6D
```
<details><summary>Messages like this are logged</summary>
```
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.packets/52340.281473684041744] DHCP4_BUFFER_RECEIVED received buffer from 10.1.2.6:67 to 255.255.255.255:67 over interface ens256
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.options/52340.281473642041216] DHCP4_BUFFER_UNPACK parsing buffer received from 10.1.2.6 to 255.255.255.255 over interface ens256
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.bad-packets/52340.281473642041216] DHCP4_PACKET_DROP_0001 failed to parse packet from 10.1.2.6 to 255.255.255.255, received over interface ens256, reason: failed to parse the domain-name in DHCPv4 Client FQDN Option: non terminating empty label in .empty.label.example.com, hwaddr=00:0c:01:02:03:04
```
</details>
Clients with such incorrect FQDNs in option 81 are not able to get an IP address. Option 81 content from such clients is probably not useable and should perhaps be ignored but the client should still get an IP address possibly? This type of error in option 81 was allowed in ISC DHCP and so this is a problem for those migrating to Kea from ISC DHCP.
Attached a pcap of the DHCP packets generated by `perfdhcp`: [fqdn-test.pcap](/uploads/810d5aa88d78f58f1c4b39d6b1eec3d1/fqdn-test.pcap)
[SF1790](https://isc.lightning.force.com/lightning/r/Case/500S6000006lxqtIAA/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3288add couple sentences describing what tools/kea-breeder/kb.py does and why2024-03-14T14:58:34ZWlodzimierz Wenceladd couple sentences describing what tools/kea-breeder/kb.py does and whyExtend help message or just add comments to explain what is the purpose of `tools/kea-breeder/kb.py` scriptExtend help message or just add comments to explain what is the purpose of `tools/kea-breeder/kb.py` scriptkea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3287enable pylint and pycodestyle on all python files in kea repo2024-03-14T14:57:35ZWlodzimierz Wencelenable pylint and pycodestyle on all python files in kea repoextend kea pipeline with similar solution to what we are using in qa repo.extend kea pipeline with similar solution to what we are using in qa repo.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3286Allow absolute values for DDNS RR TTLs (to correctly meet RFC 4702, Section 5)2024-03-21T14:54:27ZRobin EdserAllow absolute values for DDNS RR TTLs (to correctly meet RFC 4702, Section 5)We are currently preparing a migration from `dhcpd` to Kea and are struggling a bit with DNS TTLs for DDNS entries created with Kea. We have a requirement from the organisation to have our default lease time be `2 days` / `172800 seconds...We are currently preparing a migration from `dhcpd` to Kea and are struggling a bit with DNS TTLs for DDNS entries created with Kea. We have a requirement from the organisation to have our default lease time be `2 days` / `172800 seconds`, but in combination with a short TTL of `300 seconds` because our Juniper firewall rules are almost entirely name based.
Since Kea only calculates the TTL we are currently having to set `ddns-ttl-percent` to `.00174` to get a `301 second` TTL. However since we are setting this globally, the result is that any client classes where we explicitly want much shorter lease than the default to get a `1 second` TTL.
RFC 4702, Section 5 does also mention that TTLs should also be configurable as an absolute time interval:
> We recognize that individual administrators
will have varying requirements: DHCP servers and clients SHOULD allow
administrators to configure TTLs and upper and lower bounds on the
TTL values, either as an absolute time interval or as a percentage of
the lease time.
This is something that would be ideal for us and hopefully useful for others. I hope it can be considered.
Thank you to the Kea devs and ISC for all your hard work :heart:next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3285Remove DNS GENERATE directive2024-03-12T14:01:57ZRazvan BecheriuRemove DNS GENERATE directiveThe following discussion from !2236 should be addressed:
- [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2236#note_443526): (+2 comments)
> IMHO you can get rid of the GENERATE direct...The following discussion from !2236 should be addressed:
- [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2236#note_443526): (+2 comments)
> IMHO you can get rid of the GENERATE directive so I suggest to remove this case and associated code and tests.kea2.5.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3283CableLabs option (RFC3495): Inconsistent "option_def" usage in client class d...2024-03-28T17:32:26ZPeter 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.8https://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/3280Fix doxygen errors2024-03-12T16:00:39ZThomas MarkwalderFix doxygen errorsThere are a slew of doxygen errors that should be fixed. I attached an error report[doxygen-error.log](/uploads/cba7a4ce50a93cad07e9477202585ee5/doxygen-error.log)There are a slew of doxygen errors that should be fixed. I attached an error report[doxygen-error.log](/uploads/cba7a4ce50a93cad07e9477202585ee5/doxygen-error.log)kea2.5.7Thomas MarkwalderThomas Markwalderhttps://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/3278Perfmon-Hook-Task-4 Implement PerfMonMgr Basics - start up, configuration2024-03-26T19:39:49ZThomas MarkwalderPerfmon-Hook-Task-4 Implement PerfMonMgr Basics - start up, configurationComplete Hook Task 4: Implement PerfMonMgr Basics - start up, configuration.
This creates the initial PerfMonMgr class with stub functions. It should be able to parse configuration but not yet provide data processing.
See https://gitla...Complete Hook Task 4: Implement PerfMonMgr Basics - start up, configuration.
This creates the initial PerfMonMgr class with stub functions. It should be able to parse configuration but not yet provide data processing.
See https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#perfmon-hook-taskskea2.5.8Thomas MarkwalderThomas Markwalderhttps://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?backlog