ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-03-22T11:01:26Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3173Make the isc__nm_uvreq_t caching unlocked (or mostly so)2022-03-22T11:01:26ZOndřej SurýMake the isc__nm_uvreq_t caching unlocked (or mostly so)April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/23292.0.2 release checklist2022-03-03T10:52:24ZWlodzimierz Wencel2.0.2 release checklist---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaRelease...---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# Kea 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 those checks and updates can be made before the actual freeze.
1. 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/tarball-internal/Kea_20Build_20Checks/)
1. [ ] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./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. [x] Check that a previously released schema has not been changed.
1. [x] 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. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [ ] Finish release notes and conduct its review
1. [x] Run [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
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 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. [ ] Check if ReadTheDocs can build Kea documentation.
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. [ ] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates Gitlab issue and MR for release changes
- adds release entries to ChangeLogs
- regenerates BNF grammar
- regenerates documentation
- regenerates messages
- reorders messages in alphabetical order
- regenerates parsers
- updates copyright dates
- pushes the changes to MR
1. Check manually User's Guide sections:
1. 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. 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. 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 [tarball-internal](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/) 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 all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page 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-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
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. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
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
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs 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. For stable releases, change the default version to point to this stable release.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever: <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button: <br>
1. [tarball-internal job](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
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` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [ ] ***(Support)*** Wait for the signing ticket from the release engineer.
- [ ] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [ ] ***(Support)*** Sign the tarballs.
- [ ] ***(Support)*** Upload signature files to repo.isc.org.
- [ ] ***(Support)*** Place tarballs in public location on FTP site.
- [ ] ***(Support)*** Publish links to downloads on ISC website.
- [ ] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [ ] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** 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. Then update support customers that this new private repo exists.
- [ ] ***(Support)*** Update tickets in case of waiting for support customers.
- [ ] ***(QA)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [ ] ***(Marketing)*** 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.
- [ ] ***(Marketing)*** Announce on social media.
- [ ] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).kea2.0.2Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2325Wrong file creation dates on files installed by Kea Cloudsmith packages2022-03-04T16:53:37ZVicky Riskvicky@isc.orgWrong file creation dates on files installed by Kea Cloudsmith packagesA user installing Kea from the ISC Cloudsmith repo reported:
Thanks! I installed from Debian packages (v2.0.1) but somehow they do not work.
The files:
```
root@dhcp01:/usr/lib/x86_64-linux-gnu/kea/hooks# ls -l
total 3192
-rw-r--r-- 1...A user installing Kea from the ISC Cloudsmith repo reported:
Thanks! I installed from Debian packages (v2.0.1) but somehow they do not work.
The files:
```
root@dhcp01:/usr/lib/x86_64-linux-gnu/kea/hooks# ls -l
total 3192
-rw-r--r-- 1 root root 63664 Apr 2 2019 libdhcp_bootp.so
-rw-r--r-- 1 root root 129312 Apr 2 2019 libdhcp_flex_id.so
-rw-r--r-- 1 root root 133248 Apr 2 2019 libdhcp_flex_option.so
-rw-r--r-- 1 root root 687728 Apr 2 2019 libdhcp_ha.so
-rw-r--r-- 1 root root 145568 Apr 2 2019 libdhcp_host_cmds.so
-rw-r--r-- 1 root root 268608 Apr 2 2019 libdhcp_lease_cmds.so
-rw-r--r-- 1 root root 420936 Apr 2 2019 libdhcp_legal_log.so
-rw-r--r-- 1 root root 1073680 Apr 2 2019 libdhcp_mysql_cb.so
-rw-r--r-- 1 root root 182384 Apr 2 2019 libdhcp_run_script.so
-rw-r--r-- 1 root root 145696 Apr 2 2019 libdhcp_stat_cmds.so
```
djt installed using the same instructions and got the same result - the file dates are wrong. by running a
`kea-dhcp4 -V` he found that the version is indeed 2.0.1, so the dates on the files are wrong.kea2.1.4Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2324Sanity checks for Kea 2.1.3 rc22022-03-28T14:24:36ZjenkinsSanity checks for Kea 2.1.3 rc2```
We are now at step SANITY CHECKS of Kea 2.1.3 rc2.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Be...```
We are now at step SANITY CHECKS of Kea 2.1.3 rc2.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Before starting any checks, please state what check you are doing in a
thread/discussion (not as comment) in Sanity Checks issue in GitLab:
None
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/2.1.3-rc2
/data/shared/sweng/kea/releases/premium-2.1.3-rc2
/data/shared/sweng/kea/releases/subscription-2.1.3-rc2
SHA256 (kea-2.1.3.tar.gz) = 09d00c61a75e83b69ce7cf802817f4c54e626d16e492ebadf699177b19b9463d
SHA256 (kea-premium-2.1.3.tar.gz) = 8945f98dc912d8df882809a33110090c238fd20debf3de923e22607efc6e9b62
SHA256 (kea-subscription-2.1.3.tar.gz) = ee845c11fd9becc7bfc99f9d5cd9eef1369640e3519366f18c12baa05926f27a
2) APK, deb, RPM packages on packages.aws.isc.org, exact packages versions are stored here:
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/710/
Release versions are:
APK: 2.1.3-r20220221185559: https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20220221185559.apk
deb: 2.1.3-isc20220221185559: https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.1.3-isc20220221185559
RPM: 2.1.3-isc20220221185559.[os]: https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.1.3-isc20220221185559*
Installation instructions are here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks, chapter 4. Sanity Checks, point 9.
```kea2.1.3https://gitlab.isc.org/isc-projects/kea/-/issues/2323Postgresql CB gmt_epoch() function requires cast to BIGINT under PostgreSQL 9x2022-02-21T18:45:57ZThomas MarkwalderPostgresql CB gmt_epoch() function requires cast to BIGINT under PostgreSQL 9xA user function, gmt_epoc(), added to the schema for PostgreSQL CB requires casting the expression to BIGINT under PostgreSQL 9.0. Apparently the cast is not needed in 11+.A user function, gmt_epoc(), added to the schema for PostgreSQL CB requires casting the expression to BIGINT under PostgreSQL 9.0. Apparently the cast is not needed in 11+.Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2321Sanity checks for Kea 2.1.3 rc12022-02-24T13:58:57ZjenkinsSanity checks for Kea 2.1.3 rc1```
We are now at step SANITY CHECKS of Kea 2.1.3 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Be...```
We are now at step SANITY CHECKS of Kea 2.1.3 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Before starting any checks, please state what check you are doing in a
thread/discussion (not as comment) in Sanity Checks issue in GitLab:
None
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/2.1.3-rc1
/data/shared/sweng/kea/releases/premium-2.1.3-rc1
/data/shared/sweng/kea/releases/subscription-2.1.3-rc1
SHA256 (kea-2.1.3.tar.gz) = 4295cf11c3ebe29cb99bc1039dcaa357bac7bc557a6c4c3693bc80f2008ce982
SHA256 (kea-premium-2.1.3.tar.gz) = a607ac7ebd7b23a3cf431e415ef8b310793389fcf98111d61204b567bc76ae8a
SHA256 (kea-subscription-2.1.3.tar.gz) = 9b9c09b84335e2fddea675d3b0dd67b31616c4a899f81a0b2472fd95c40732a0
2) APK, deb, RPM packages on packages.aws.isc.org, exact packages versions are stored here:
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/709/
Release versions are:
APK: 2.1.3-r20220221113544: https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20220221113544.apk
deb: 2.1.3-isc20220221113544: https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.1.3-isc20220221113544
RPM: 2.1.3-isc20220221113544.[os]: https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.1.3-isc20220221113544*
Installation instructions are here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks, chapter 4. Sanity Checks, point 9.
```kea2.1.3https://gitlab.isc.org/isc-projects/kea/-/issues/2320Changes for Kea 2.1.3 release2022-02-24T13:59:05ZAndrei Pavelandrei@isc.orgChanges for Kea 2.1.3 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.1.3Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/2319CB include statement2023-05-01T09:41:23ZPeter DaviesCB include statementCB include statement:
I could be useful for users to have the ability of using "include" files in the "Configuration Backend"
It has been suggested that this could be implemented as an extension to #2006
[RT #15938](https://suppor...CB include statement:
I could be useful for users to have the ability of using "include" files in the "Configuration Backend"
It has been suggested that this could be implemented as an extension to #2006
[RT #15938](https://support.isc.org/Ticket/Display.html?id=15938)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2318Kea 2.1.3 Release Checklist2022-02-24T13:21:23ZMarcin GodzinaKea 2.1.3 Release Checklist---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea 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 those checks and updates can be made before the actual freeze.
1. 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/tarball-internal/Kea_20Build_20Checks/)
1. [ ] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./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. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.2
1. [x] Finish release notes and conduct its review
1. [x] Run [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
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) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates a Kea issue and MR for release changes,
- runs several updating scripts
- pushes the changes to MR
1. Check manually User's Guide sections:
1. 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. 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. 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 [tarball-internal](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/) 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 sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed lib versions
1. which were updated? (save results)
1. any of the lib from current release has lower number then corresponding lib from previous release? (!)
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page 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-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
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. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
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
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever: <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button: <br>
1. [tarball-internal job](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs 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. For stable releases, change the default version to point to this stable release.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [ ] ***(Support)*** Place tarballs in public location on FTP site.
- [ ] ***(Support)*** Publish links to downloads on ISC website.
- [ ] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [ ] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new major version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [ ] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(Marketing)*** 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.
- [x] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [x] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [x] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).
## Post-Release, But Before Code Unfreeze
- [x] 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` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`kea2.1.3Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/bind9/-/issues/3162configure ignores PYTHON environment variable2022-02-18T10:05:52ZPetr Špačekpspacek@isc.orgconfigure ignores PYTHON environment variable### Summary
Setting `PYTHON=/usr/bin/python2` variable before running `configure` does not actually cause Python 2 to be used. This contradicts `configure --help`:
```
Some influential environment variables:
PYTHON path to pytho...### Summary
Setting `PYTHON=/usr/bin/python2` variable before running `configure` does not actually cause Python 2 to be used. This contradicts `configure --help`:
```
Some influential environment variables:
PYTHON path to python executable
```
At the same time `--with-python=/usr/bin/python2` seems to work.
### BIND version used
- ~"v9.11" seem to work as expected
- ~"Affects v9.16" : a30dac540ee6bb442852d258fa60b0cc0f319e15
- ~"v9.18" and ~"v9.19" seem to work as expected
### Steps to reproduce
- PREFIX=/tmp/v9_16 PYTHON=/usr/bin/python2 ./configure
- make
- make install
- find /tmp/v9_16 | grep site-packages
### What is the current *bug* behavior?
- Python libraries get installed into /tmp/v9_16/lib/python3.10/site-packages/isc
- System tests use `python` interpreter instead of `python2`
### What is the expected *correct* behavior?
The specified Python interpreter is used.
### Relevant logs and/or screenshots
- [config.log](/uploads/95c03049ac360b6ffea5473743a9231d/config.log)
### Possible fixes
Either use the value from PYTHON variable, or remove the variable altogether.https://gitlab.isc.org/isc-projects/kea/-/issues/2316Sparse IPv6 allocations2023-01-20T11:51:02ZTomek MrugalskiSparse IPv6 allocationsA request coming from a customer (see [support#20158](https://support.isc.org/Ticket/Display.html?id=20158)):
> The cable operator are requesting that IA_NA address (/128) is taken for each customer from a different /64.
The use case a...A request coming from a customer (see [support#20158](https://support.isc.org/Ticket/Display.html?id=20158)):
> The cable operator are requesting that IA_NA address (/128) is taken for each customer from a different /64.
The use case asks for both address (IA_NA) and prefix (IA_PD).
This is something we can't do right now reasonably. @marka pointed out that it's pretty classic IPv6 case for telco and pointed to [RFC7278](https://datatracker.ietf.org/doc/html/rfc7278).
In Kea's terms, there are couple factors:
- we could develop a hook for this that would overrule kea's lease6_select.
- we could implement new allocator that for PD would work as usual, but for IA_NA, it would look for allocated PD for this client and synthesize IPv6 address from it.
Related RFCs: [RFC7278](https://datatracker.ietf.org/doc/html/rfc7278), [RFC6603](https://datatracker.ietf.org/doc/html/rfc6603).kea2.3.4https://gitlab.isc.org/isc-projects/stork/-/issues/711Stork agent to support authentication with Prometheus and bearer token2022-02-18T11:19:38ZGavin WillStork agent to support authentication with Prometheus and bearer tokenUsing just the stork agent I would like to send metrics to an externally hosted prometheus
This looks possible with the stork config with
```### settings for exporting stats to Prometheus
### the IP or hostname on which the agent expor...Using just the stork agent I would like to send metrics to an externally hosted prometheus
This looks possible with the stork config with
```### settings for exporting stats to Prometheus
### the IP or hostname on which the agent exports Kea statistics to Prometheus
# STORK_AGENT_PROMETHEUS_KEA_EXPORTER_ADDRESS=
```
but i cannot see in docs or searching a way to authenticate with the prometheus server. I have a prometheus https endpoint url and a bearer_token to auth.
Does stork support this? Happy to do a PR if pointed in the right directionhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/226docs/trivial: typo in dhcpd.conf.5 manpage2022-03-04T09:34:38ZJan "Yenya" Kasprzakdocs/trivial: typo in dhcpd.conf.5 manpageHello,
there is apparently a typo in dhcpd.conf.5 manpage:
"_The valid lifetime determines at what point **at** lease might be said to have expired_"
Patch attached:
[dhcpd.conf.5.diff](/uploads/fe4251426005e586c2ec3746c9860328/dhcpd...Hello,
there is apparently a typo in dhcpd.conf.5 manpage:
"_The valid lifetime determines at what point **at** lease might be said to have expired_"
Patch attached:
[dhcpd.conf.5.diff](/uploads/fe4251426005e586c2ec3746c9860328/dhcpd.conf.5.diff)
Thanks for considering this.4.4.3Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/3161Clients consuming all TCP connections2022-11-25T17:10:44ZWilliam TaylorClients consuming all TCP connections<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
We seem to be having an issue where tcp connections keep getting maxed out and then no further queries via tcp are possible. We have usually identified a few clients that have lots of connections in CLOSE_WAIT state and then firewall them off.
### BIND version used
# named -v
BIND 9.16.25-RedHat-9.16.25-1.el7 (Extended Support Version) <id:3e14423>
### Steps to reproduce
start bind
### What is the current *bug* behavior?
client consumes all tcp connections and bind no longer responds. udp still works fine
### What is the expected *correct* behavior?
bind should close the sockets properly?
### Relevant configuration files
```
# grep tcp /etc/named/named.conf
tcp-clients 2048;
```
### Relevant logs and/or screenshots
```
# netstat -padn | grep CLOSE_WAIT | grep 123.456.789.123 |wc -l
274
```
Will attach a tcp dump if needed.
![bindtcpconnections](/uploads/227bd54b381d7e01a4b2f567ac1e470e/bindtcpconnections.png)https://gitlab.isc.org/isc-projects/bind9/-/issues/3160Linking failure on macOS 12.22022-06-15T13:26:16ZDaniel LukeLinking failure on macOS 12.2### Summary
bind9.18.0 fails to build on macOS 12.2 when linking filter_aaaa
### BIND version used
9.18.0
### Steps to reproduce
Attempt to build on macOS 12.2.x
### What is the current *bug* behavior?
build fails due to missing s...### Summary
bind9.18.0 fails to build on macOS 12.2 when linking filter_aaaa
### BIND version used
9.18.0
### Steps to reproduce
Attempt to build on macOS 12.2.x
### What is the current *bug* behavior?
build fails due to missing symbols when linking
### What is the expected *correct* behavior?
build succeeds
### Possible fixes
This patch is what I'm currently using to fix the MacPorts build (although you probably want to patch the .am files instead of the .in files):
```--- bin/plugins/Makefile.in.orig 2022-01-24 15:06:42.000000000 -0500
+++ bin/plugins/Makefile.in 2022-02-16 15:00:47.000000000 -0500
@@ -478,8 +478,8 @@
pkglib_LTLIBRARIES = filter-aaaa.la filter-a.la
filter_aaaa_la_SOURCES = filter-aaaa.c
filter_a_la_SOURCES = filter-a.c
-filter_aaaa_la_LDFLAGS = -avoid-version -module -shared -export-dynamic
-filter_a_la_LDFLAGS = -avoid-version -module -shared -export-dynamic
+filter_aaaa_la_LDFLAGS = $(LIBISC_LIBS) $(LIBISCCFG_LIBS) $(LIBDNS_LIBS) $(LIBNS_LIBS) -avoid-version -module -shared -export-dynamic
+filter_a_la_LDFLAGS = $(LIBISC_LIBS) $(LIBISCCFG_LIBS) $(LIBDNS_LIBS) $(LIBNS_LIBS) -avoid-version -module -shared -export-dynamic
all: all-am
.SUFFIXES:
--- bin/tests/system/dyndb/driver/Makefile.in.orig 2022-02-16 15:24:01.000000000 -0500
+++ bin/tests/system/dyndb/driver/Makefile.in 2022-02-16 15:24:20.000000000 -0500
@@ -457,7 +457,7 @@
util.h \
zone.h
-sample_la_LDFLAGS = -avoid-version -module -shared -export-dynamic -rpath $(abs_builddir)
+sample_la_LDFLAGS = $(LIBISC_LIBS) $(LIBISCCFG_LIBS) $(LIBDNS_LIBS) $(LIBNS_LIBS) -avoid-version -module -shared -export-dynamic -rpath $(abs_builddir)
all: all-am
.SUFFIXES:
--- bin/tests/system/dlzexternal/driver/Makefile.in.orig 2022-02-16 15:42:36.000000000 -0500
+++ bin/tests/system/dlzexternal/driver/Makefile.in 2022-02-16 15:43:01.000000000 -0500
@@ -442,7 +442,7 @@
driver.c \
driver.h
-dlzexternal_la_LDFLAGS = -avoid-version -module -shared -export-dynamic -rpath $(abs_builddir)
+dlzexternal_la_LDFLAGS = $(LIBISC_LIBS) -avoid-version -module -shared -export-dynamic -rpath $(abs_builddir)
all: all-am
.SUFFIXES:
--- bin/tests/system/hooks/driver/Makefile.in.orig 2022-02-16 15:48:28.000000000 -0500
+++ bin/tests/system/hooks/driver/Makefile.in 2022-02-16 15:49:02.000000000 -0500
@@ -439,7 +439,7 @@
check_LTLIBRARIES = test-async.la
test_async_la_SOURCES = test-async.c
-test_async_la_LDFLAGS = -avoid-version -module -shared -export-dynamic -rpath $(abs_builddir)
+test_async_la_LDFLAGS = $(LIBISC_LIBS) $(LIBNS_LIBS) -avoid-version -module -shared -export-dynamic -rpath $(abs_builddir)
all: all-am
.SUFFIXES:
```https://gitlab.isc.org/isc-projects/kea/-/issues/2310CA extend COMMAND_RECEIVED message2022-02-10T14:15:32ZPeter DaviesCA extend COMMAND_RECEIVED messageCA extend COMMAND_RECEIVED message:
On the Control Agent would it be possible to log the IP address of the sending client on the same line as the COMMAND_RECEIVED message.
for example:
2022-02-10 13:18:03.145 INFO [kea-ct...CA extend COMMAND_RECEIVED message:
On the Control Agent would it be possible to log the IP address of the sending client on the same line as the COMMAND_RECEIVED message.
for example:
2022-02-10 13:18:03.145 INFO [kea-ctrl-agent.commands/31927.140456776408625] COMMAND_RECEIVED Received command 'subnet4-list' from 10.0.2.15
[RT #15938 ](https://support.isc.org/Ticket/Display.html?id=15938)https://gitlab.isc.org/isc-projects/kea/-/issues/2309PgSqlBasicsTest.ptimeTimestamp fails on Debian 92022-07-08T13:55:27ZAndrei Pavelandrei@isc.orgPgSqlBasicsTest.ptimeTimestamp fails on Debian 9There is a Postgres unit test that claims we can insert year 3021 timestamps in Postgres, but I think we can only go up to 2038 in Debian 9.
https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/637/#showFailuresLink
```
15:11:23 [ ...There is a Postgres unit test that claims we can insert year 3021 timestamps in Postgres, but I think we can only go up to 2038 in Debian 9.
https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/637/#showFailuresLink
```
15:11:23 [ RUN ] PgSqlBasicsTest.ptimeTimestamp
15:11:23 NOTICE: table "basics" does not exist, skipping
15:11:23 pgsql_exchange_unittest.cc:984: Failure
15:11:23 Failed
15:11:23 no exception, expected: BadValue
15:11:23 [ FAILED ] PgSqlBasicsTest.ptimeTimestamp (13 ms)
```
Here are some hints on what might be wrong with values taken from `PsqlBindArray::addTimestamp(const boost::posix_time::ptime& timestamp)` called from the unit test:
| | Debian 9 | Other OSs |
| ------------------------------- | ---------------------------------------------------- | ---------------------------------------------------- |
| lscpu | Architecture: x86_64, CPU op-mode(s): 32-bit, 64-bit | Architecture: x86_64, CPU op-mode(s): 32-bit, 64-bit |
| sizeof(time_duration::sec_type) | 4 | 8 |
| timestamp | 3021-Jan-21 10:14:15 | 3021-Jan-21 10:14:15 |
| epoch | 1970-Jan-01 00:00:00 | 1970-Jan-01 00:00:00 |
| since_epoch | -1191605513 | 33168132855 |
| input_time | -1191605513 | 33168132855 |kea2.2.0 - a new stable branchhttps://gitlab.isc.org/isc-projects/stork/-/issues/707Download troubleshooting tarball contains empty events-latest.json2022-05-31T11:32:06ZTomek MrugalskiDownload troubleshooting tarball contains empty events-latest.jsonSteps to reproduce:
1. start demo, authorize agent-kea
2. click on agent-kea, observe the events (5 in my case: machine added, added ca,v4,v6,d2 daemons)
3. click download troubleshooting data
The `2022-02-09T15-30-40Z_events_latest.js...Steps to reproduce:
1. start demo, authorize agent-kea
2. click on agent-kea, observe the events (5 in my case: machine added, added ca,v4,v6,d2 daemons)
3. click download troubleshooting data
The `2022-02-09T15-30-40Z_events_latest.json` file is 4 bytes long. The tarball in the first comment.
I think the events file should contain all the events related to that machine or any of the daemons running on that machine.
On a related note, the filenames are inconvenient. I'd swap the filename order, so it would be `name`-`timestamp`, rather than the other way around. When opening in gui (e.g. gnome shell), I saw only the beginnings of the filenames which all were the same.1.4https://gitlab.isc.org/isc-projects/stork/-/issues/706Download troubleshooting info doesn't work2022-07-12T08:31:04ZTomek MrugalskiDownload troubleshooting info doesn't workI've been playing with the Stork demo on master (ea964f549acca39037363fcd7dbf67ff24d0e024). The demo was running on for a while and then I've tried to download the troubleshooting info and it didn't work. Here's what I saw:
![stork-down...I've been playing with the Stork demo on master (ea964f549acca39037363fcd7dbf67ff24d0e024). The demo was running on for a while and then I've tried to download the troubleshooting info and it didn't work. Here's what I saw:
![stork-download-troubleshooting-info](/uploads/b2a07ebd65c22a6b10ae7aad28824fbb/stork-download-troubleshooting-info.png).
My setup was:
- 192.168.1.99 - ubuntu 21.04, running the demo.
- 192.168.1.101 - ubuntu 21.10, the laptop running the firefox that was showing the demo.1.5Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2303Client class option is not correctly assigned (boot-file-name for PXE)2022-02-17T17:02:34ZSamuel HameauClient class option is not correctly assigned (boot-file-name for PXE)---
name: Bug report
about: client class option mismatch
---
**Describe the bug**
Client class option is not correctly assigned (boot-file-name for PXE)
I'm unable to boot in UEFI as invalid boot-file-name is given.
**To Reproduce**
S...---
name: Bug report
about: client class option mismatch
---
**Describe the bug**
Client class option is not correctly assigned (boot-file-name for PXE)
I'm unable to boot in UEFI as invalid boot-file-name is given.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4with the following config
```
"client-classes": [
{...},
{
"name": "UEFI-64-1",
"test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00007'",
"boot-file-name": "efi64/syslinux.efi"
},
{...},
{
"name": "Legacy",
"test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00000'",
"boot-file-name": "pxelinux.0"
}
]
```
Please note that 'pxelinux.0' is only mentionned here in the config.
2. Client boot and selects Network UEFI Boot. DHCP server is on the same network (no relay)
3. Client send DHCP Discover packet with option 60/Vendor Class identifier set to "PXEClient:Arch:00007:UNDI:003016" (see tcpdump capture)
4. Kea answer with "pxelinux.0" as Boot file name in its DHCP Offer
**Expected behavior**
I would expect to get "efi64/syslinux.efi" as boot file name, as it matches the class test condition. It does not match the test condidition for legacy pxelinux.0.
**Environment:**
- Kea version:
```# kea-dhcp4 -V
2.0.1
tarball
linked with:
log4cplus 1.1.2
OpenSSL 1.1.1f 31 Mar 2020
database:
MySQL backend 12.0, library 8.0.27
PostgreSQL backend 6.2, library 120009
Memfile backend 2.1
```
- OS: [Ubuntu 20.04 x64]
- Which features were compiled in : unsing mysql backend
- If/which hooks where loaded in: not using hooks.
**Additional Information**
```
# tcpdump -ni eth0 ether host xx:xx:xx:xx:xx:xx and port bootpc -w dhcp.cap
# tcpdump -Ar dhcp.cap
reading from file dhcp.cap, link-type EN10MB (Ethernet)
17:03:45.684558 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx (oui Unknown), length 347
E..w."..@.`U.........D.C.c>Q.....dg.....................T../,...........................................................................................................................................................................................................c.Sc5..9...7#..............()*+236:;<BCa........a..L=.(J%...\..?...^....]...< PXEClient:Arch:00007:UNDI:003016.
17:03:45.687441 IP server-01.exmple.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 334
E..j..@...A[.........C.D.V.......dg.....................T../,...........tftpserver.exemple.com..................................pxelinux.0......................................................................................................................c.Sc5......................client.exemple.com3.....6.....B.192.168.0.14.
```
**Contacting you**
by gitlab/emailWlodzimierz WencelWlodzimierz Wencel