Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-27T12:51:09Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3140Feature request: Add Statistics Counters for dropped packets (for various dif...2024-03-27T12:51:09ZCathy AlmondFeature request: Add Statistics Counters for dropped packets (for various different reasons)---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
...---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
This is loosely related to issue #3125 for counting some dropped packets due to HA (#3125 is more about not logging them unnecessarily though, or being able to disable the per-event logging).
This is a request to add a specific packet counts for both HA and for other dropped packets such as ones dropped due to kea being disabled.
Customer requesting this feature currently has an issue where they can't tell if an operator has misconfigured their network such that Kea wasn't receiving any traffic or if it was in a disabled state due to Kea HA sync.
Version 2.2
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/1989Issues with qualifying suffix when clients use a combination of Hostname and ...2024-03-27T12:50:32ZMarcin SiodelskiIssues with qualifying suffix when clients use a combination of Hostname and Client FQDN optionA client sends option 12 (Hostname) or option 81 (Client FQDN) to communicate the desired name to the server. The server assumes that the client sends one of these options, not both. If the Client FQDN is present in the client's message,...A client sends option 12 (Hostname) or option 81 (Client FQDN) to communicate the desired name to the server. The server assumes that the client sends one of these options, not both. If the Client FQDN is present in the client's message, it processes this option and ignores the Hostname option.
The server may append a qualifying suffix to the received name or replace the name entirely. The qualified name is terminated with a dot in Client FQDN and is never terminated with a dot in the Hostname option.
We deliberately made a change in the processing of the Hostname option several years ago when it turned out that some DHCP clients have issues with consuming the dot terminated hostname. It appears that it has implications for some clients.
We received a report about a client who uses a combination of option 12 and option 81 in the 4-way exchange. The client sends a partial name in option 12. The server qualifies the name with the suffix and sends option 12 back. The client uses the qualified name (without a dot) and sends it in the Client FQDN option as a partial name. The server qualifies the received name again on the grounds that it is a partial name. Even though the client shouldn't use a combination of these options, we could probably prevent qualifying the name twice by checking if the received name already has a suffix equal to the configured one.
One solution that comes to mind is to always append the dot to the hostnames returned in option 12. However, as mentioned before, we deliberately removed the dots because some clients did not accept them.
We can also consider whether it should be possible to explicitly include a dot via host reservations. If a host reservation has a dot for the hostname, the server would always include a dot. Thus, it would be possible to make exceptions for selected clients.
[RT #18375](https://support.isc.org/Ticket/Display.html?id=18735)
UPDATE: The original problem has been addressed in #1529. However, there's a request [see below](https://gitlab.isc.org/isc-projects/kea/-/issues/1989#note_227456) to add two parameters:
- [ ] allow the administrator to configure which field (option 12 or option 81) to prefer if both exist (RFC violation, that you can actually do now with DDNS tuning hook).
- [ ] including a trailing dot or not could be a configurable feature (or it could be left to the administrator if they include a trailing dot on the qualifying suffix itself.)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2819Add max TTL time to D22024-03-27T12:49:15ZDarren AnkneyAdd max TTL time to D2With the addition of being able to set the DDNS TTL with `ddns-ttl-percent` to some percentage of lease time, it might be a good idea to add a maximum possible TTL to the `kea-ddns` configuration. This should be an absolute time limit. ...With the addition of being able to set the DDNS TTL with `ddns-ttl-percent` to some percentage of lease time, it might be a good idea to add a maximum possible TTL to the `kea-ddns` configuration. This should be an absolute time limit. For example, `3600` for one hour maximum TTL length. In this example, if Kea sent something higher than this, D2 would truncate the TTL to `3600`. If the proposed setting is not present in D2 then there should be no change from current behavior which, I believe, is no limit to the length of the TTL.
[RT21610](https://support.isc.org/Ticket/Display.html?id=21610)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3314RBAC: Omitting configuration option results in logged error2024-03-26T21:44:52ZDarren AnkneyRBAC: Omitting configuration option results in logged errorThe configuration directive `"response-filters"` seems to be de facto required whereas the ARM seems to imply that this parameter should be optional as it shows examples where the parameter is not present (see the extensive example). It...The configuration directive `"response-filters"` seems to be de facto required whereas the ARM seems to imply that this parameter should be optional as it shows examples where the parameter is not present (see the extensive example). It doesn't actually say whether the parameter is required or optional, however.
Omitting the directive causes this error:
```
[kea-ctrl-agent.callouts/401411.129873316435840] HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook response registered by library with index 1 (callout address 0x761e7c475880): unable to find callout context associated with the current library index (1) (callout duration: 0.047 ms)
```
The error does not seem to cause any harm as the operations still seem to be performed. This can fill up the logs though if there is a lot of API access (such as in the case of Stork).
Adding the directive to the roles configuration(s) removes the error.
[SF1816](https://isc.lightning.force.com/lightning/r/Case/500S6000007Ho67IAC/view)Francis DupontFrancis Duponthttps://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/3313Bump up version in configure.ac to 2.5.8-git2024-03-26T19:09:46ZMarcin GodzinaBump up version in configure.ac to 2.5.8-gitBump up version in configure.ac.Bump up version in configure.ac.kea2.5.8Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/3299Improve MT RADIUS unit tests2024-03-26T18:31:40ZAndrei Pavelandrei@isc.orgImprove MT RADIUS unit testsImprove RADIUS unit tests:
- no goal: write tests for session history: instead implement #414
- MT: see below
- async access added new ways to have a query to be dropped: add these cases
- find a way to detect accounting exchange te...Improve RADIUS unit tests:
- no goal: write tests for session history: instead implement #414
- MT: see below
- async access added new ways to have a query to be dropped: add these cases
- find a way to detect accounting exchange termination (e.g. a class counter of pending exchanges)
RADIUS could have more thorough MT unit tests:
- Start thread pool for accounting by calling the `dhcp*_srv_configured` callout. Currently it is only called for auth. Waiting for work to finish in accounting is not as trivial for auth. Auth uses the unparking for that. (see last general point)
- In both access and accounting, start a second thread pool that simulates the core Kea thread pool / DHCP clients.
- Convert more (all?) ST unit tests to MT. Currently there are only 4 MT unit tests: (v4 + v6) x (access + accounting).kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3218Kea dhcp v4 server ip reservation configuration using uuid-guid (dhcp option ...2024-03-26T13:17:34ZBenoit SansoniKea dhcp v4 server ip reservation configuration using uuid-guid (dhcp option 97; rfc 4578)Hi,
I would like to set a dhcp v4 reservation ip using "uuid-guid" (that correspond to dhcp option 97 / RFC 4578).
This is my current kea server configuration using an hardware address that works fine :
"reservations": [...Hi,
I would like to set a dhcp v4 reservation ip using "uuid-guid" (that correspond to dhcp option 97 / RFC 4578).
This is my current kea server configuration using an hardware address that works fine :
"reservations": [
{
"hostname": "board",
"hw-address": "01:02:03:04:05:06",
"ip-address": "192.168.0.2",
"option-data": [
{
"name": "boot-file-name",
"data": "file.bin"
}
]
},
When I replaced in this configuration the hw-address by "uuid-guid", the "uuid-guid" filed is not expected by kea dhcp server.
In the documentation I can see that the default host reservation identifiers are:
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ]
Is the "uuid-guid" is supported for IP reservation ?
Is it a feature that will be developped in the future ?
If the reservation with "uuid-guid" identifier is supported, What should configuration need to be applied ?
Thanks in advance for your help
Benoitoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3309Sanity checks for Kea 2.5.7 rc12024-03-26T06:25:10ZMarcin GodzinaSanity checks for Kea 2.5.7 rc1We are now at step SANITY CHECKS of Kea 2.5.7 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.5.7 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.5.7-rc1`
* `/data/shared/sweng/kea/releases/premium-2.5.7-rc1`
* `/data/shared/sweng/kea/releases/subscription-2.5.7-rc1`
* `/data/shared/sweng/kea/releases/enterprise-2.5.7-rc1`
```
SHA256 (kea-2.5.7.tar.gz) = 7a3a05ca11b5fe8c4e72a31169b6bed94368c4a7af6d388c86321da96568a1d4
SHA256 (kea-enterprise-2.5.7.tar.gz) = f61c1636df974c4531060d93218baf569b77a50f944882558593be8737984911
SHA256 (kea-premium-2.5.7.tar.gz) = 5c82b56a3e338f5f664a04fd1c271e0a8ff2dfd610dee0416dbfca8ee4f830a4
SHA256 (kea-subscription-2.5.7.tar.gz) = 42aa2106fb0595d23976807988a2f4b546f5bad718efdffce2af9b6bdd867aba
```
#### Packages on packages.aws.isc.org
* [APK: 2.5.7-r20240322162202](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20240322162202.apk)
* [deb: 2.5.7-isc20240322162202](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.5.7-isc20240322162202)
* [RPM: 2.5.7-isc20240322162202.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.5.7-isc20240322162202*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1460/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).kea2.5.72024-03-25https://gitlab.isc.org/isc-projects/kea/-/issues/3311kea-dhcp4 and 6: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be remov...2024-03-25T21:07:26ZHarry G. Coinkea-dhcp4 and 6: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.On both dhcp 4 and 6, over many upgrades in the past month this warning remains:
kea-dhcp4: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
Likely on the next major db client upgrade, mysql and maria...On both dhcp 4 and 6, over many upgrades in the past month this warning remains:
kea-dhcp4: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
Likely on the next major db client upgrade, mysql and mariadb will no longer answer kea requests.
Probably worth fixing 'real soon now', before conditions of time pressure arise from total failure.https://gitlab.isc.org/isc-projects/kea/-/issues/2787A client class reservation in FreeRADIUS only applies to the first exchange i...2024-03-25T15:05:41ZAndrei Pavelandrei@isc.orgA client class reservation in FreeRADIUS only applies to the first exchange if there is also an address reservation for the same hostIf you have both an address reservation and a client class reservation in RADIUS, like so:
```
00:03:00:01:08:00:27:b0:c1:42 Cleartext-password := "08:00:27:b0:c1:42"
Framed-IP-Address = "192.168.52.52",
Framed-IPv6-Ad...If you have both an address reservation and a client class reservation in RADIUS, like so:
```
00:03:00:01:08:00:27:b0:c1:42 Cleartext-password := "08:00:27:b0:c1:42"
Framed-IP-Address = "192.168.52.52",
Framed-IPv6-Address = "2001:db8:50::52",
Framed-Pool = "gold",
Framed-IPv6-Pool = "gold"
```
The client class is only assigned to the packet from the first exchange, but not to the packet from the second exchange, like so:
```
DEBUG [kea-dhcp6.packets] DHCP6_QUERY_DATA duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f, packet details: localAddr=[ff02::1:2]:0 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=1(SOLICIT), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.dhcp6] DHCP6_CLASS_ASSIGNED duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f: client packet has been assigned to the following class(es): ALL, gold, KNOWN
--
DEBUG [kea-dhcp6.packets] DHCP6_RESPONSE_DATA responding with packet type 2 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=2(ADVERTISE), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.packets] DHCP6_QUERY_DATA duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f, packet details: localAddr=[ff02::1:2]:0 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=3(REQUEST), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.dhcp6] DHCP6_CLASS_ASSIGNED duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f: client packet has been assigned to the following class(es): ALL, KNOWN
--
DEBUG [kea-dhcp6.packets] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=7(REPLY), transid=0xf9cf5f
```
If the client class would have also been assigned in the second exchange, it could have potentially resulted in a different lease, depending on Kea configuration.
This behavior is exhibited with v4 too.
See https://gitlab.isc.org/isc-projects/kea/-/issues/2761#note_357250 for slightly more details.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2761Out-of-subnet address reservations done via RADIUS authorization now reselect...2024-03-25T15:05:37ZAndrei Pavelandrei@isc.orgOut-of-subnet address reservations done via RADIUS authorization now reselect subnet despite reselect-subnet-address being false if the client got assigned to a shared-network subnetPrior to the merging of gitlab ticket 2631 in Kea 2.3.5, RADIUS reservations were allowed to be out-of-subnet. Arguably, this might not have been useful, but a nuissance instead. So from that perspective, the behavior might have been imp...Prior to the merging of gitlab ticket 2631 in Kea 2.3.5, RADIUS reservations were allowed to be out-of-subnet. Arguably, this might not have been useful, but a nuissance instead. So from that perspective, the behavior might have been improved. However, the logic is quite fragmented now:
| RADIUS reserved address | subnet type | reselect-subnet-address | Outcome before 2631 | Outcome after 2631 |
| ----------------------- | -------------- | ----------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| inside selected subnet | doesn't matter | doesn't matter | reservation leased, no reselection, address in range of subnet | same |
| outside selected subnet | standalone | false | reservation leased, no reselection, address out of range of subnet | same |
| outside selected subnet | standalone | true | reservation leased, subnet reselection is attempted globally | same |
| outside selected subnet | shared network | false | reservation leased, no reselection, address out of range of subnet | reservation leased, subnet reselection is attempted, but only within shared network |
| outside selected subnet | shared network | true | reservation leased, subnet reselection is attempted globally | same (unlikely, but it might be that the reselection is done only within the shared network, TBT...) |
Things that could be done:
* Document this behavior in the RADIUS ARM.
* Write unit tests to assert this new behavior.
* Adapt the system tests that started failing.
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-multiple-subnets-memfile]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-multiple-subnets-mysql]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-multiple-subnets-postgresql]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-network-memfile]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-network-mysql]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-network-postgresql]`next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3152Extraneous second lookup in host cache in the radius access callout when subn...2024-03-25T14:14:24ZAndrei Pavelandrei@isc.orgExtraneous second lookup in host cache in the radius access callout when subnet is not reselectedIn `subnetX_select` callouts for `libdhcp_radius.so`, there are two `getXAny` lookups in the host cache. The second one has the purpose of fetching the host again with the new subnet ID. But this makes sense only if the subnet was resele...In `subnetX_select` callouts for `libdhcp_radius.so`, there are two `getXAny` lookups in the host cache. The second one has the purpose of fetching the host again with the new subnet ID. But this makes sense only if the subnet was reselected since the first retrieval as part of the subnet reselection process that is specific to RADIUS. However, it is called regardless of whether the subnet was reselected or not. This could be optimized.next-stable-2.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://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/3310Documentation should include more examples with IPv6 addresses in URLs2024-03-25T12:34:33ZFrancis DupontDocumentation should include more examples with IPv6 addresses in URLsThe reason is the syntax is no so trivial... I suggest to add at least one in ARM (hooks-ha.rst) and in kea6 examples.The reason is the syntax is no so trivial... I suggest to add at least one in ARM (hooks-ha.rst) and in kea6 examples.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3303db-delay with reservations database "imagines" database connection2024-03-22T21:44:42ZMarcin Godzinadb-delay with reservations database "imagines" database connectionAfter kea#3300 fix, there is still a problem left:
When using the reservations database, Kea detects that there is no database and states that it is the first of 5 retries.
Then reports `database connection lost` and immediately reports ...After kea#3300 fix, there is still a problem left:
When using the reservations database, Kea detects that there is no database and states that it is the first of 5 retries.
Then reports `database connection lost` and immediately reports `database connection recovered.` (line 35 in log) (but the database is shut down) and proceeds like it has a database (so it serves traffic, etc.)
reproducable on v4, v6, MySQL and postgr
[kea-dhcp4.conf](/uploads/8ab1eb9ca661f49dba54190969c1d532/kea-dhcp4.conf)
[kea.log](/uploads/1016f040cd96d876517feb57fe8e342b/kea.log)kea2.5.7Marcin GodzinaMarcin Godzinahttps://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/3307Changes for Kea 2.5.7 release2024-03-22T15:55:28ZMarcin GodzinaChanges for Kea 2.5.7 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.5.7Marcin GodzinaMarcin Godzina2024-03-27https://gitlab.isc.org/isc-projects/kea/-/issues/3306Changes for Kea 2.5.7 release2024-03-22T15:26:13ZMarcin GodzinaChanges for Kea 2.5.7 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.5.72024-03-27https://gitlab.isc.org/isc-projects/kea/-/issues/3304bump up lib versions for 2.5.72024-03-22T14:53:31ZRazvan Becheriubump up lib versions for 2.5.7kea2.5.7Razvan BecheriuRazvan Becheriu