Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-11-23T12:57:27Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3158Whether kea-dhcpv6 contains the option to configure an ipv6 gateway?2023-11-23T12:57:27ZBei ChenWhether kea-dhcpv6 contains the option to configure an ipv6 gateway?I am using version 2.4.0, dhcpv4 has options for configuring the default gateway, does dhcpv6 have similar options for configuring the default gateway?I am using version 2.4.0, dhcpv4 has options for configuring the default gateway, does dhcpv6 have similar options for configuring the default gateway?https://gitlab.isc.org/isc-projects/kea/-/issues/3157Sanity checks for Kea 2.4.1 rc12023-11-27T08:36:41ZAndrei Pavelandrei@isc.orgSanity checks for Kea 2.4.1 rc1We are now at step SANITY CHECKS of Kea 2.4.1 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.4.1 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.4.1-rc1`
* `/data/shared/sweng/kea/releases/premium-2.4.1-rc1`
* `/data/shared/sweng/kea/releases/subscription-2.4.1-rc1`
* `/data/shared/sweng/kea/releases/enterprise-2.4.1-rc1`
```
SHA256 (kea-2.4.1.tar.gz) = 01fc0109dd31b30de32633bf0b36217c04a68feb4de81b62fbf2187ab3d030db
SHA256 (kea-enterprise-2.4.1.tar.gz) = f5319bccb740259d43f9e0473f81cd23cbf6a5426e3d04eb73582ed223e1f7e7
SHA256 (kea-premium-2.4.1.tar.gz) = 8c4f6cf883947b65faf64aea80ccd616553ece8b6d1ea3d172b8d326351cc8d6
SHA256 (kea-subscription-2.4.1.tar.gz) = 755bdf869a8d848d7fb0aa78bf14b3e07cb5b4332c2e996bfcbc409031dec408
```
#### Packages on packages.aws.isc.org
* [APK: 2.4.1-r20231116233850](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20231116233850.apk)
* [deb: 2.4.1-isc20231116233850](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.4.1-isc20231116233850)
* [RPM: 2.4.1-isc20231116233850.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.4.1-isc20231116233850*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-2.4/job/pkg/25/
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.4.1https://gitlab.isc.org/isc-projects/kea/-/issues/3156Changes for Kea 2.4.1 release2023-11-23T13:38:03ZAndrei Pavelandrei@isc.orgChanges for Kea 2.4.1 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.4.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/31552.4.1 release checklist2023-11-29T21:04:03ZAndrei Pavelandrei@isc.org2.4.1 release checklist# Kea 2.4.1 Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the act...# Kea 2.4.1 Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual freeze. For new stable releases or maintenance releases, please don't use the `kea-dev` build farm; use a dedicated build farm for each release cycle.
1. [x] Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [ ] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. [x] Create a Gitlab issue for bumping up library versions and `KEA_HOOKS_VERSION` and notify developers.
* In case of no developers available, it can be done by running: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that).
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. [ ] If any changes have been done to database schemas, then:
1. [ ] Check that a previously released schema has not been changed.
1. [ ] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. [x] Prepare release notes.
1. [x] Create release note on Kea GitLab wiki and notify @tomek. It should be created under the `Release-Notes` directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.3.4
1. [x] Finish release notes and conduct its review.
1. [x] Notify support that release notes are ready for review. To avoid conflicts in edits wait with next step after review is done.
1. [x] Notify @sgoldlust or @vicky that release notes are ready for review. Due to time difference please do this at least 36 hours before planned release.
1. [x] Check that packages can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [ ] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) \
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 2.3.4 --repo-dir ~/isc/repos/kea/`. \
Help: `GITLAB_TOKEN='...' ./update-code-for-release.py --help`. \
The script requires an explicit flag for stable and maintenances releases e.g. `--repo-branch v2_4`. \
The script makes the following changes and actions:
1. Runs [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/prepare_kea_release.sh) that:
1. Adds release entries in ChangeLogs.
1. Updates Kea version in configure.ac.
1. Updates copyright years in files that were changed in current year.
1. Sorts message files.
1. Regenerates message files headers.
1. Regenerates parsers using Bison from Docker
1. [x] Run the script again with the `--upload` flag which:
1. Creates an issue in GitLab for release changes in kea repo.
1. Creates branches and merge requests for kea and kea-premium.
1. Commits the changes in both repos.
1. Checks out created branches in both repos.
1. Commits and pushes the changes to GitLab server.
1. [x] Check manually User's Guide sections:
1. [x] Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed.
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. [x] Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. [x] Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/)).
1. [x] Check and update Build Requirements.
1. [x] Check configure options against what `./configure -h` says.
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages up to date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. It's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid.
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick:
1. `rc1` if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. Submit the job that will automatically:
1. Upload the tarballs.
1. Create a GitLab issue for sanity checks, put the announcement there.
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.\
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
Now it's time to publish the code.
1. [x] Update Release Notes with ChangeLog entries.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. `Kea-2.3.4`).
1. Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description:
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/).
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/).
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. This job will also:
- Open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org.
- Create Git tags `Kea-a.b.c` in Kea main and premium repositories.
- Create Gitlab releases `Kea-a.b.c` in Kea main and premium repositories.
1. [x] Sign tarballs with the personal key, by running [sign_kea_and_upload_asc.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh) which signs, verifies signatures and uploads them.
- If release engineer does NOT have signing key, please contact team member.
1. [x] Confirm that the tarballs have the checksums mentioned on the signing ticket.
1. [ ] Wait for clearance from Security Officer to proceed with the public release (if applicable). If this is a security release, next steps will be impacted by CVE checklist.
1. [x] Login to repo.isc.org and upload final tarball to public ftp using make-available script (only OPS can remove incorrectly uploaded tarballs).
* [x] For premium tarballs use `--private` option.
* For newest stable release use `--symlink=cur` option.
* Example command: `make-available --public --symlink=cur /data/shared/sweng/kea/releases/2.3.4`.
* [x] save links to all premium tarballs and put them into signing ticket as a comment.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io:
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Check that Docker images can be uploaded to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/).
* Make sure the right package job is selected under `Packages`.
* Tick `Upload`.
* Leave `TestProdRepos` to `testing`.
* Leave `versionTag` ticked.
* Tick `latestTag` if this is a stable or a maintenance release.
* If this is a stable or maintenance release, change `KeaDockerBranch` to the appropriate branch.
* Press `Build`.
1. [x] Build and upload Docker images to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/) with the same actions as above except change `TestProdRepos` to `production`.
1. [x] Update ReadTheDocs:
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
1. [ ] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Contact Marketing team, and find a member who will continue work on this release:
1. [x] Assign this ticket to person who will continue.
1. [x] Share link to signing ticket either directly or as a comment in this issue.
## Marketing
1. [x] Publish links to downloads on ISC website.
1. [x] Update the supported versions document in the Salesforce portal (if there are stable versions released), and update the Kea document in the portal.
1. [x] If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Verify that the KB on installing from Cloudsmith has also been updated, then update the Kea document in the SF portal and notify support customers that this new private repo exists.
1. [x] If a new Cloudsmith repository is used, make sure that the Zapier scripts are updated.
* If those are not updated, there was an error made during preparation for new stable release. Please contact QA team and coordinate fix.
1. [x] Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
1. [x] Write release email to _kea-announce_.
1. [ ] Write email to _kea-users_ (if a major release).
1. [x] Announce on social media.
1. [x] Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea\_(software)).
1. [ ] Write blog article (if a major release).
1. [ ] Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
1. [ ] Update Kea Premium and Kea Subscription data sheets if any new hooks.
1. [ ] Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
1. [x] Contact Support team, find a person who will continue this release and assign this issue to them.
## Support
1. [x] Update tickets in case of waiting for support customers.
1. [x] Close this ticketkea2.4.1Darren AnkneyDarren Ankney2023-11-29https://gitlab.isc.org/isc-projects/kea/-/issues/3154Kea fails to link with log4cplus if the UNICODE macro is defined2024-01-16T16:22:58ZAndrei Pavelandrei@isc.orgKea fails to link with log4cplus if the UNICODE macro is definedThis has been observed in the fuzzing experiments on an Ubuntu 20.04 OSS-fuzz container, and also prior to that on my local FreeBSD 13 VM.
When attempting to build Kea, it complains at `./configure` about `configure: error: Needs log4cp...This has been observed in the fuzzing experiments on an Ubuntu 20.04 OSS-fuzz container, and also prior to that on my local FreeBSD 13 VM.
When attempting to build Kea, it complains at `./configure` about `configure: error: Needs log4cplus library`.
`config.log` shows:
```
conftest.cpp:(.text+0x21): undefined reference to `log4cplus::Logger::getInstance(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)'
```
Doing `CXXFLAGS='-UUNICODE' LDFLAGS='-UUNICODE' ./configure` fixes it, although it is likely that only one of the set of flags is needed.
What happens is the log4cplus headers have UNICODE macros that makes its code use wide character strings instead of regular strings, hence the undefined symbol. See `/usr/include/log4cplus/clogger.h`, `/usr/include/log4cplus/tchar.h`, `/usr/include/log4cplus/tstring.h`, and others.
log4cplus is likely not the one setting the macro, but likely other dependencies or some system component like the compiler itself. Likely the latter, which is why it appears on fringe systems.
This error could be prevented without manually specifying flags when `.configure`-ing. Either:
1. Follow in the steps of log4cplus and split the use of its functions according to whether UNICODE is defined or not and provide a `getInstance()` that uses wide character strings if it is defined.
2. Detect if Kea can link with log4cplus in `configure.ac` and add `-UUNICODE` to the set of flags if the error above ocurs. This is rather intrusive and also inaccurate.kea2.5.5https://gitlab.isc.org/isc-projects/kea/-/issues/3153Bump up library versions for 2.4.12023-11-23T13:38:03ZAndrei Pavelandrei@isc.orgBump up library versions for 2.4.1Bump up library versions for %"kea2.4.1".Bump up library versions for %"kea2.4.1".kea2.4.1Razvan BecheriuRazvan Becheriuhttps://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/3151Reject RADIUS config with multiple default NAS ports2023-11-23T14:42:38ZAndrei Pavelandrei@isc.orgReject RADIUS config with multiple default NAS portsA default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accor...A default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accordingly.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3150dhcpv4 and dhcpv6 services go down for some reason2023-11-16T18:13:47ZSandeep Gagalapallydhcpv4 and dhcpv6 services go down for some reasonHello Kea Support,
We are facing some intermittent issues with dhcpv4 and dhcpv6 services going down for some reason.
Our setup includes two kea instances ( 2.4.0 ) running on Ubuntu 18.04 and connect to an AWS RDS MySQL Instance.
c...Hello Kea Support,
We are facing some intermittent issues with dhcpv4 and dhcpv6 services going down for some reason.
Our setup includes two kea instances ( 2.4.0 ) running on Ubuntu 18.04 and connect to an AWS RDS MySQL Instance.
can you please review the configs of dhcp4 attached ?
The network connection between Kea servers and mySQL DB seems to working fine.
[kea-dhcp-1.conf](/uploads/cb2fc2093bd1450cf23694d64c62d3b2/kea-dhcp-1.conf)
[kea-dhcp-2.conf](/uploads/7a3f41c2f2be740e986dbd5232a3f0dc/kea-dhcp-2.conf)https://gitlab.isc.org/isc-projects/kea/-/issues/3149Bulk Leasequery (BLQ) needs to be able to match PDs associated with a link, e...2024-01-18T20:33:05ZCathy AlmondBulk Leasequery (BLQ) needs to be able to match PDs associated with a link, even if the subnet of the PD is outside of the subnet of the linkI'm reporting this a bug, since this is missing functionality, but functionality that is clearly important operationally, and without this (or a viable workaround) means the use of BLQ by a rebooting router is useless for finding and qui...I'm reporting this a bug, since this is missing functionality, but functionality that is clearly important operationally, and without this (or a viable workaround) means the use of BLQ by a rebooting router is useless for finding and quickly reprovisioning PDs as well as IAs.
**Describe the bug**
A router is using BLQ to learn of the existing leases associated with its link following a reboot. Particularly it's interested in the PDs since it's going to need to set up its routing appropriately to the client PDs.
BLQ using `query-by-link-address` is retrieving only the IAs associated with the link. This is sort of unsurprising since the PDs, although associated with the subnet that matches the link, aren't members of that subnet (this is also unsurprising).
However, in the leases memfile, both the IA and the PD have the same subnet id (the id of the subnet that matches to the link), and the IA, unsurprisingly is an address within that subnet.
- There is no PD pool associated with the subnet in the dhcp6 configuration
- All the PDs are assigned using HRs - but they *are* associated with the same subnet as the client IA
- I can see in the leases file, that the subnet ID is correct, if BLQ happened internally to be using subnet ID to 'find' leases associated with a link address.
I can't see any other way to get this information currently. The natural way to use BLQ here is to specify the link address (which also does match in the leases database, as well as the subnet ID associated with this link address's subnet). But the underlying lease search code doesn't seem to be using either of these.
How else is a router going to get the list of PDs it should be provisioning? Clearly after just rebooting, it's not going to **know** what ranges of prefixes have been delegated since PD subnets are independent of the subnet via which they're being delegated anyway.
See details in the customer case linked below.
I've also been discussing the semantics of the documentation and other information around BLQ with Kea Engineering, who have requested that I open this issue.
**Environment:**
- Kea version: 2.4.0
- OS: N/A
- Using memfile for leases, postgresql for HRs and mysql for config:
```
...
"Dhcp6": {
"allocator": "iterative",
"calculate-tee-times": true,
"config-control": {
"config-databases": [
{
"host": "127.0.0.1",
"max-reconnect-tries": 30,
"name": "kea",
"password": "<obscured>",
"port": 3306,
"reconnect-wait-time": 2000,
"type": "mysql",
"user": "kea"
}
],
"config-fetch-wait-time": 60
},
...
"lease-database": {
"lfc-interval": 3600,
"type": "memfile"
},
...
"reservations-global": false,
"reservations-in-subnet": true,
"reservations-lookup-first": false,
"reservations-out-of-pool": false,
...
"library": "\/usr\/lib\/x86_64-linux-gnu\/kea\/hooks\/libdhcp_lease_query.so",
"parameters": {
"advanced": {
"active-query-enabled": false,
"bulk-query-enabled": true,
"extended-info-tables-enabled": true,
"lease-query-ip": "<obscured>",
"lease-query-tcp-port": 547,
"max-bulk-query-threads": 0,
"max-concurrent-queries": 0,
"max-leases-per-fetch": 100,
"max-requester-connections": 10,
"max-requester-idle-time": 300
},
"requesters": [
"<obscured>"
]
}
}
],
"host-reservation-identifiers": [
"duid",
"flex-id"
],
"hostname-char-replacement": "",
"hostname-char-set": "[^A-Za-z0-9.-]",
"hosts-databases": [
{
"host": "127.0.0.1",
"max-reconnect-tries": 30,
"name": "kea",
"password": "<obscured>",
"port": 3306,
"reconnect-wait-time": 2000,
"type": "mysql",
"user": "kea"
}
],
```
- Using hooks:
> libdhcp_ha.so
> libdhcp_mysql_cb.so
> libdhcp_host_cmds.so
> libdhcp_lease_cmds.so
> libdhcp_subnet_cmds.so
> libdhcp_cb_cmds.so
> libdhcp_flex_id.so
> libdhcp_legal_log.so
> libdhcp_lease_query.so
**Additional Information**
Here's the operational use case supporting this:
> The DHCP BLQ needs to return the PDs including from any reservations. For our use case, PDs are the one thing we are actually looking to grab when using BLQ. Our routers will send a BLQ after they reload so that they can re-populate the PD routes and subscribers v6 networks can begin working again.
**Contacting you**
See [SF#1426](https://isc.lightning.force.com/lightning/r/5007V00002Zkn9vQAB/view?0.source=alohaHeader)kea2.5.5Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3148backport hammer changes that fix errors in jenkins2023-11-23T13:38:03ZAndrei Pavelandrei@isc.orgbackport hammer changes that fix errors in jenkins* https://jenkins.aws.isc.org/view/Kea-2.4/job/kea-2.4/job/ut-extended/10/execution/node/253/log/
```plaintext
22:45:57 [HAMMER] 2023-11-13 20:45:56,978 Job for mariadb.service failed because the control process exited with error code...* https://jenkins.aws.isc.org/view/Kea-2.4/job/kea-2.4/job/ut-extended/10/execution/node/253/log/
```plaintext
22:45:57 [HAMMER] 2023-11-13 20:45:56,978 Job for mariadb.service failed because the control process exited with error code.
22:45:57 [HAMMER] 2023-11-13 20:45:56,978 See "systemctl status mariadb.service" and "journalctl -xe" for details.
```
Should be fixed by 82b3ee8457dc39226f196250d5c62f7f1ad49493.
* https://jenkins.aws.isc.org/view/Kea-2.4/job/kea-2.4/job/pkg/19/execution/node/99/log/
```plaintext
23:13:20 [HAMMER] 2023-11-13 21:13:20,375 >>>>> Executing mv kea-pkg/* kea-pkg in /home/alpine/workspace/kea-2.4/pkg
23:13:20 [HAMMER] 2023-11-13 21:13:20,376 mv: 'kea-pkg/isc-kea-2.4.0-r20231113204504.apk' and 'kea-pkg/isc-kea-2.4.0-r20231113204504.apk' are the same file
23:13:20 [HAMMER] 2023-11-13 21:13:20,376 mv: 'kea-pkg/isc-kea-admin-2.4.0-r20231113204504.apk' and 'kea-pkg/isc-kea-admin-2.4.0-r20231113204504.apk' are the same file
23:13:20 [HAMMER] 2023-11-13 21:13:20,376 mv: 'kea-pkg/isc-kea-common-2.4.0-r20231113204504.apk' and 'kea-pkg/isc-kea-common-2.4.0-r20231113204504.apk' are the same file
```
Should be fixed by 60e92acc095e56f0f4db5281e850d6c3879ca71d.kea2.4.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3147Packaging on Alpine 3.16 tries to move files to the same location as the source2023-11-23T13:38:03ZAndrei Pavelandrei@isc.orgPackaging on Alpine 3.16 tries to move files to the same location as the source```
09:26:57 [HAMMER] 2023-11-13 07:26:56,616 >>>>> Executing mv kea-pkg/* kea-pkg in /home/alpine/workspace/kea-dev/pkg
09:26:57 [HAMMER] 2023-11-13 07:26:56,617 mv: 'kea-pkg/isc-kea-2.5.4-r20231113065823.apk' and 'kea-pkg/isc-kea-2...```
09:26:57 [HAMMER] 2023-11-13 07:26:56,616 >>>>> Executing mv kea-pkg/* kea-pkg in /home/alpine/workspace/kea-dev/pkg
09:26:57 [HAMMER] 2023-11-13 07:26:56,617 mv: 'kea-pkg/isc-kea-2.5.4-r20231113065823.apk' and 'kea-pkg/isc-kea-2.5.4-r20231113065823.apk' are the same file
```
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1345/execution/node/94/log/?consoleFull
Does not happen on other alpines, or any other distributions.kea2.5.4Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3145Backport #3017: fix for interface redetection regression2023-11-23T13:38:03ZAndrei Pavelandrei@isc.orgBackport #3017: fix for interface redetection regressionThis ticket is about backporting the fix for the interface redetection regression that was developed in #3017 and released in %kea2.5.3.This ticket is about backporting the fix for the interface redetection regression that was developed in #3017 and released in %kea2.5.3.kea2.4.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3144redetect-interfaces command2024-02-08T14:35:31ZTomek Mrugalskiredetect-interfaces commandThe idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is tha...The idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is that Kea could be told that some new interfaces appeared or disappeared (VLAN, PPP, some other tunnel etc.) and Kea should redetect them. For an added bonus, there should be a way to tell Kea to open sockets on those new interfaces. This can be done either by telling Kea to open the on any newly detected interfaces or perhaps return a list of interfaces and have a dedicated call `open-socket` or something similar? Anyway, this would be useful to have a mini-design for.
This problem is not new and there are many requests in this problem space:
- A [nicely described use case in #3040](https://gitlab.isc.org/isc-projects/kea/-/issues/3040#note_414899)
- #1084
- #3062
- possibly couple morenext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3143Backport #3111: FLQ fix2023-11-23T13:38:03ZTomek MrugalskiBackport #3111: FLQ fixThis ticket is about backporting FLQ race condition fix that was developed in #3111 and released in %kea2.5.3.This ticket is about backporting FLQ race condition fix that was developed in #3111 and released in %kea2.5.3.kea2.4.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3142deadlock caused by race between start stop and wait2023-11-21T12:04:58ZRazvan Becheriudeadlock caused by race between start stop and waitdeadlock on master is caused by the fact that ```start``` is calling ```enable``` which is setting ```working_``` to thread count:
```
void enable(uint32_t thread_count) {
std::lock_guard<std::mutex> lock(mutex_);
...deadlock on master is caused by the fact that ```start``` is calling ```enable``` which is setting ```working_``` to thread count:
```
void enable(uint32_t thread_count) {
std::lock_guard<std::mutex> lock(mutex_);
enabled_ = true;
working_ = thread_count;
}
```
and ```stop``` is calling ```disable``` which just sets ```enabled_``` to false
```
void disable() {
{
std::lock_guard<std::mutex> lock(mutex_);
enabled_ = false;
}
// Notify pop so that it can exit.
cv_.notify_all();
}
```
some threads just exit without calling ```pop```:
```
/// @brief run function of each thread
void run() {
while (queue_.enabled()) { // <<< --- exit here without calling pop
WorkItemPtr item = queue_.pop();
if (item) {
try {
(*item)();
} catch (...) {
// catch all exceptions
}
}
}
}
```
and never reach the code which is decrementing ```working_```:
```
Item pop() {
std::unique_lock<std::mutex> lock(mutex_);
--working_; // <<< --- this code is never reached
// Wait for push or disable functions.
if (working_ == 0 && queue_.empty()) {
wait_cv_.notify_all();
}
cv_.wait(lock, [&]() {return (!enabled_ || !queue_.empty());});
if (!enabled_) {
return (Item());
}
```
so any call to ```wait``` will cause a deadlock because ```working_``` never reaches 0:
```
void wait() {
std::unique_lock<std::mutex> lock(mutex_);
// Wait for any item or for working threads to finish.
wait_cv_.wait(lock, [&]() {return (working_ == 0 && queue_.empty());}); // <<< --- deadlock here
}
```
to replicate apply this patch on master (UTs changes only) and they will fail:
```
diff --git a/src/lib/util/tests/thread_pool_unittest.cc b/src/lib/util/tests/thread_pool_unittest.cc
index 9c636c9e85..1c2e3a3efe 100644
--- a/src/lib/util/tests/thread_pool_unittest.cc
+++ b/src/lib/util/tests/thread_pool_unittest.cc
@@ -533,7 +533,7 @@ TEST_F(ThreadPoolTest, wait) {
ASSERT_EQ(thread_pool.size(), 0);
items_count = 64;
- thread_count = 16;
+ thread_count = 256;
// prepare setup
reset(thread_count);
@@ -556,15 +556,13 @@ TEST_F(ThreadPoolTest, wait) {
// calling start should create the threads and should keep the queued items
EXPECT_NO_THROW(thread_pool.start(thread_count));
- // the thread count should match
- ASSERT_EQ(thread_pool.size(), thread_count);
+ thread_pool.stop();
// wait for all items to be processed
- thread_pool.wait();
+ ASSERT_TRUE(thread_pool.wait(1));
// the item count should be 0
ASSERT_EQ(thread_pool.count(), 0);
- // the thread count should match
- ASSERT_EQ(thread_pool.size(), thread_count);
+
// all items should have been processed
ASSERT_EQ(count(), items_count);
```
without timeout on ```wait``` they cause a deadlock.kea2.5.4Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3141Update DNR docs to RFC 94632024-02-23T16:22:33ZPiotrek ZadrogaUpdate DNR docs to RFC 9463As of November 2023, draft-ietf-add-dnr/16 was published as RFC 9463.
There are some comments in code referring to draft, they could be updated with RFC no. for clarity.
Sadly, the on-wire format has changed between draft and RFC. Kea ...As of November 2023, draft-ietf-add-dnr/16 was published as RFC 9463.
There are some comments in code referring to draft, they could be updated with RFC no. for clarity.
Sadly, the on-wire format has changed between draft and RFC. Kea code needs to be updated.kea2.5.6Piotrek ZadrogaPiotrek Zadrogahttps://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/3139update release checklist2023-11-22T13:51:05ZWlodzimierz Wencelupdate release checklistWe recently changed a bit a process (added docker) and we are discussing changing which team is doing what. Update release checklist template accordinglyWe recently changed a bit a process (added docker) and we are discussing changing which team is doing what. Update release checklist template accordinglykea2.5.4Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3138ddns-qualifying-suffix documentation typo2023-11-09T21:39:03ZDavid Greavesddns-qualifying-suffix documentation typo---
name: ddns-qualifying-suffix documentation typo
about: Typo
---
**Describe the bug**
The docs here https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#kea-dhcp4-name-generation-for-ddns-update-requests
say:
"The suffix used w...---
name: ddns-qualifying-suffix documentation typo
about: Typo
---
**Describe the bug**
The docs here https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#kea-dhcp4-name-generation-for-ddns-update-requests
say:
"The suffix used when generating an FQDN, or when qualifying a partial name, is specified by the ddns-qualifying-suffix parameter. It is strongly recommended that the user supply a value for the qualifying **prefix** when DDNS updates are enabled."
This should say "value for the qualifying suffix when DDNS updates are enabled suffix", not prefix.
Sorry, I could not find the documentation source to submit a PR :)
**Contacting you**
via emailkea2.5.4Razvan BecheriuRazvan Becheriu