Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-09-21T10:10:46Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3015Post audit: update docs2023-09-21T10:10:46ZTomek MrugalskiPost audit: update docs@manu completed an audit and pointed the following problems [in his report](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023):
- [ ] 2. Elaborate more about \[meta\] package, in particular how to run only selec...@manu completed an audit and pointed the following problems [in his report](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023):
- [ ] 2. Elaborate more about \[meta\] package, in particular how to run only selected service. Looks like a good idea also to update the security section and point out that one should only run the services that are strictly needed.
- [ ] 3. Elaborate more about `interface` requirement for making the service running in [ARM QuickStart section](https://kea.readthedocs.io/en/kea-2.2.0/arm/quickstart.html#quick-start-guide-for-dhcpv4-and-dhcpv6-services) - this should be easy, a sentence or two pointing out that binding address is by default set to defensive 127.0.0.1.
- [ ] 4. Correct references in configs
- [ ] 5. Clarify sentence in DDNS (it's `dhcp-ddns` in `Dhcp4` or `Dhcp6`)
- [ ] 6. Clarify about sockets open by default (add something like this "While Kea doesn't open any sockets by default on its own, the default configs shipped with packages do define some socket and Kea opens them).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3013Prepared statement needs to be re-prepared2023-08-24T13:27:42ZYehuda KatzPrepared statement needs to be re-prepared**Describe the bug**
This probably doesn't qualify as a Kea bug, but I thought it might be worth asking about.
We are running 2 kea servers with a shared MySQL (MariaDB) backend. We recently upgraded from MariaDB 10.3 to MariaDB 10.5.
W...**Describe the bug**
This probably doesn't qualify as a Kea bug, but I thought it might be worth asking about.
We are running 2 kea servers with a shared MySQL (MariaDB) backend. We recently upgraded from MariaDB 10.3 to MariaDB 10.5.
We replaced the `hosts` table with a `hosts_history` TABLE (added a `deleted_at` column to allow for keeping host history) and a `hosts` VIEW that only shows non-deleted items. This has been working for us for many years.
Everything seems to work for a while until randomly, we start getting errors for systems with host reservations.
The error in the log is:
```
2023-08-14 18:52:59.613 DEBUG [kea-dhcp4.bad-packets/169655.139690552555648] DHCP4_PACKET_DROP_0007 [hwtype=1 xx:xx:xx:xx:xx:17], cid=[no info], tid=0xee1b36c3
: failed to process packet: unable to execute for <SELECT h.host_id, h.dhcp_identifier, h.dhcp_identifier_type, h.dhcp4_subnet_id, h.dhcp6_subnet_id, h.ipv4_address, h.hostname, h.dhcp4_client_classes, h.dhcp6_client_classes, h.us
er_context, h.dhcp4_next_server, h.dhcp4_server_hostname, h.dhcp4_boot_file_name, h.auth_key, o.option_id, o.code, o.value, o.formatted_value, o.space, o.persistent, o.user_context FROM hosts AS h LEFT JOIN dhcp4_options AS o ON h
.host_id = o.host_id WHERE h.dhcp4_subnet_id = ? AND h.dhcp_identifier_type = ? AND h.dhcp_identifier = ? ORDER BY h.host_id, o.option_id>, reason: Prepared statement needs to be re-prepared (error code 1615)
```
When this happens, the host making the request gets no response, not even an error. (Similar to #281?)
It is not clear exactly how to reproduce this error. We even created a completely new copy of the database using `kea-admin` and it ran fine for just less than 24 hours before stopping with the same error.
**To Reproduce**
Steps to reproduce the behavior:
1. Create a MySQL database. Rename the `hosts` table to `hosts_history` and create a VIEW for `hosts`:
```sql
CREATE VIEW `hosts` AS select distinct `hosts_history`.`host_id` AS `host_id`,
`hosts_history`.`dhcp_identifier` AS `dhcp_identifier`,`hosts_history`.`dhcp_identifier_type` AS `dhcp_identifier_type`,
`hosts_history`.`dhcp4_subnet_id` AS `dhcp4_subnet_id`,`hosts_history`.`dhcp6_subnet_id` AS `dhcp6_subnet_id`,
`hosts_history`.`ipv4_address` AS `ipv4_address`,`hosts_history`.`hostname` AS `hostname`,`hosts_history`.`dhcp4_client_classes` AS `dhcp4_client_classes`,
`hosts_history`.`dhcp6_client_classes` AS `dhcp6_client_classes`,`hosts_history`.`dhcp4_next_server` AS `dhcp4_next_server`,
`hosts_history`.`dhcp4_server_hostname` AS `dhcp4_server_hostname`,`hosts_history`.`dhcp4_boot_file_name` AS `dhcp4_boot_file_name`,
`hosts_history`.`user_context` AS `user_context`,`hosts_history`.`auth_key` AS `auth_key`
from `hosts_history` where `hosts_history`.`deleted` IS NULL
```
1. Run Kea dhcp4 with standard mysql configuration
1. The client uses the standard linux dhclient or the Nagios `check_dhcp` plugin.
1. The server usually send standard responses except sometimes when it logs this error and sends no response.
**Expected behavior**
1. Valid responses should always be sent
2. An error should be sent back to the client when there is a server error.
**Environment:**
- Kea version: Supplied from RHEL9 EPEL respository
```
# kea-dhcp4 -V
2.2.0
tarball
linked with:
log4cplus 2.0.5
OpenSSL 3.0.7 1 Nov 2022
database:
MySQL backend 14.0, library 3.2.6
PostgreSQL backend 13.0, library 130011
Memfile backend 2.1
```
- OS: RHEL 9.2outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3007Kea builds are not reproducible2024-02-28T12:06:07ZSudip MukherjeeKea builds are not reproducible---
name: Bug report
about: The latest version of kea is failing the reproducible build as it adds the build path in kea-admin script.
---
**Describe the bug**
The latest version of kea is failing the reproducible build as it adds the ...---
name: Bug report
about: The latest version of kea is failing the reproducible build as it adds the build path in kea-admin script.
---
**Describe the bug**
The latest version of kea is failing the reproducible build as it adds the build path in kea-admin script.
**To Reproduce**
Steps to reproduce the behavior:
1. Build kea
2. Again build kea at a different build location
3. Use diffoscope to compare kea-admin
4. See error
The result can be seen at https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230806-_h282f1z/packages/diff-html/
**Expected behavior**
The built kea-admin should not contain any reference to build path.
**Environment:**
- Kea version: v2.5.0
- OS: All
- Which features were compiled in (in particular which backends): NA
- If/which hooks where loaded in: NA
**Additional Information**
The attached patch will fix the reproducible build and verified with diffoscope. [0001-kea-fix-reproducible-build-failure.patch](/uploads/7b4b13a72d4953a65e6768bdc4f78483/0001-kea-fix-reproducible-build-failure.patch)
**Contacting you**
Please email at sudipm.mukherjee@gmail.comoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3006Kea fails to listen alongside dnsmasq, but doesn't report a failure2023-10-25T11:41:34ZZenKea fails to listen alongside dnsmasq, but doesn't report a failureUsing Gentoo with kernel 6.1.41 and net-misc/kea-2.2.0-1::gentoo USE="filecaps openssl samples -debug -doc -mysql -postgres -shell -test" PYTHON_SINGLE_TARGET="python3_11 -python3_10" 0 KiB
Kea starts without an error:
```
kea-dhcp4 -...Using Gentoo with kernel 6.1.41 and net-misc/kea-2.2.0-1::gentoo USE="filecaps openssl samples -debug -doc -mysql -postgres -shell -test" PYTHON_SINGLE_TARGET="python3_11 -python3_10" 0 KiB
Kea starts without an error:
```
kea-dhcp4 -c /etc/kea/kea-dhcp4.conf -d
2023-08-08 10:44:58.401 DEBUG [kea-dhcp4.dhcp4/8231.140323795412096] DHCP4_START_INFO pid: 8231, server port: 67, client port: 0, verbose: yes
2023-08-08 10:44:58.402 INFO [kea-dhcp4.dhcp4/8231.140323795412096] DHCP4_STARTING Kea DHCPv4 server version 2.2.0-gentoo (stable) starting
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.dhcp4/8231.140323795412096] DHCP4_OPEN_SOCKET opening service sockets on port 67
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command list-commands registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command build-report registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command config-backend-pull registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command config-get registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command config-reload registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command config-set registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command config-test registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command config-write registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command dhcp-enable registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command dhcp-disable registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command libreload registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command leases-reclaim registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command server-tag-get registered
2023-08-08 10:44:58.402 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command shutdown registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command status-get registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command version-get registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-get registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-reset registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-remove registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-get-all registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-reset-all registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-remove-all registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-sample-age-set registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-sample-age-set-all registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-sample-count-set registered
2023-08-08 10:44:58.403 DEBUG [kea-dhcp4.commands/8231.140323795412096] COMMAND_REGISTERED Command statistic-sample-count-set-all registered
```
but does not actually listen on any ports. I think it does this when dnsmasq is listening on 0.0.0.0, but I defined both interfaces for it to listen on with:
```
"interfaces": [ "fib.lan/10.10.10.1", "ethernet2/192.168.2.1" ]
```
Stopping dnsmasq (which was started by libvirtd) resolves this, but I was able to run ISC this way.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3005ddns CHG_ADD before CHG_REMOVE2023-11-16T18:46:52Zphilip-smartbitddns CHG_ADD before CHG_REMOVE---
name: ddns add nsupdate before remove nsupdate
---
**Describe the bug**
we updated kea to 2.4.0 and set ddns-update-on-renew to true. Since the update we noticed that some hosts lost their dns records (but had a correct lease). fr...---
name: ddns add nsupdate before remove nsupdate
---
**Describe the bug**
we updated kea to 2.4.0 and set ddns-update-on-renew to true. Since the update we noticed that some hosts lost their dns records (but had a correct lease). from around 13:00 07/aug/2023 until now we had 6 hosts losing their dns record. we updated to kea 2.4.0 on 13:00 07/aug/2023
In the kea ddns log we noticed that the problem hosts all showed a CHG_ADD before a CHG_REMOVE:
2023-08-07 18:07:36.634 INFO [kea-dhcp-ddns.d2-to-dns/1587] DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [host01.internal.]
IP Address: [10.20.30.40]
DHCID: [000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3]
Lease Expires On: 20230807161112
Lease Length: 216
Conflict Resolution: no
2023-08-07 18:07:36.674 INFO [kea-dhcp-ddns.d2-to-dns/1587] DHCP_DDNS_REMOVE_SUCCEEDED DHCP_DDNS Request ID 000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3: successfully removed the DNS mapping addition for this request: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [host01.internal.]
IP Address: [10.20.30.40]
DHCID: [000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3]
Lease Expires On: 20230807154204
Lease Length: 216
Conflict Resolution: no
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcp4 with the following settings enabled:
"ddns-update-on-renew": true,
"ddns-use-conflict-resolution": false
2. A few hunderd vm's doing a renew every 1800 seconds
3. wait and randomly some hosts lose their dns record's
4. See error above
**Expected behavior**
we expect that kea ddns *always* does a CHG_REMOVE before a CHG_ADD
**Environment:**
- Kea version: 2.4.0 with default multithreading on, package installed via cloudsmith debian repo
- OS: Debian 11
- ha is enabled with default multithreading on, hot-standby
- auth dns server is powerdns 4.8.1
**Additional Information**
we only use dhcp4, no dhcp6
we configured powerdns with distributor-threads=1 and reuseport=no
The kea and (power)dns vm's didn't have high cpu usage or iowait, they weren't overload in any way.
**Contacting you**
contact via gitlab or emailnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3000DHCPv4 - 2.4.0 segfault vol22024-03-22T13:05:43ZVecĂnoDHCPv4 - 2.4.0 segfault vol2**Describe the bug**
The dmesg shows the segfault errors. I have already addressed this issue here: https://gitlab.isc.org/isc-projects/kea/-/issues/2997 version 2.2.0 but I switched to the newer 2.4.0 ... the error occurs less frequentl...**Describe the bug**
The dmesg shows the segfault errors. I have already addressed this issue here: https://gitlab.isc.org/isc-projects/kea/-/issues/2997 version 2.2.0 but I switched to the newer 2.4.0 ... the error occurs less frequently, but still is here. :disappointed:
```
Aug 01 07:00:25 router kernel: kea-lfc[21463]: segfault at 7f50dc000020 ip 00007f50eecaa170 sp 00007f50ed6c6db0 error 6 likely on CPU 1 (core 6, socket 0)
Aug 01 07:00:25 router kernel: Code: ee 48 89 df e8 b1 f3 06 00 85 c0 0f 85 41 01 00 00 48 8b 05 4a 71 14 00 48 83 e8 01 48 39 e8 0f 82 b5 00 00 00 66 0f 6f 0c 24 <4c> 89 6b 20 0f 11 4b 10 90 48 83 c4 18 48 89 d8 5b 5d 41 5c 41 5d
Aug 01 17:00:31 router kernel: kea-lfc[22122]: segfault at 7f22b8000020 ip 00007f22cfaaa170 sp 00007f22ce4c6db0 error 6 likely on CPU 3 (core 12, socket 0)
Aug 01 17:00:31 router kernel: Code: ee 48 89 df e8 b1 f3 06 00 85 c0 0f 85 41 01 00 00 48 8b 05 4a 71 14 00 48 83 e8 01 48 39 e8 0f 82 b5 00 00 00 66 0f 6f 0c 24 <4c> 89 6b 20 0f 11 4b 10 90 48 83 c4 18 48 89 d8 5b 5d 41 5c 41 5d
```
**Environment:**
* Kea version: 2.4.0-2 - https://archlinux.org/packages/extra-testing/x86_64/kea/
* OS: Arch Linux x64, 6.1.39-2-lts
**Debugging:**
I am very sorry to provide you with some valuable information. I tried to do the debugging - https://bbs.archlinux.org/viewtopic.php?id=287607 , but I'm an inexperienced user and don't know how to do it. I'm sorry.
https://wiki.archlinux.org/title/Debugging/Getting_traces#Getting_the_trace
[kea-dhcp4.conf](/uploads/dc7b2d987cae6ad94682e975e8428a1a/kea-dhcp4.conf)
@razvankea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2999configure makes erroneous assumption to discover location of OpenSSL librarie...2023-08-10T13:50:53ZMark Priorconfigure makes erroneous assumption to discover location of OpenSSL libraries on macOSThe configure script supplied in the tarball aborts when trying to determine support for OpenSSL routines on macOS due to an erroneous assumption.
The configure script builds code snippets to determine availability of various EVP routin...The configure script supplied in the tarball aborts when trying to determine support for OpenSSL routines on macOS due to an erroneous assumption.
The configure script builds code snippets to determine availability of various EVP routines. To determine the location of the OpenSSL libraries it executes the following code
```
# Now search for the system OpenSSL library.
if test "${use_openssl}" = "yes" ; then
for d in /usr /usr/local /usr/local/ssl /usr/local/opt/openssl /usr/pkg /usr/sfw; do
if test -f $d/include/openssl/opensslv.h; then
use_openssl="${d}"
openssl_headers="${d}/include"
for l in lib lib64; do
if test -f "${d}/${l}/libssl.so"; then
openssl_libraries="${d}/${l}"
break
fi
done
if test -n "${openssl_headers}" && test -n "${openssl_libraries}"; then
break
fi
fi
done
fi
```
macOS does not use .so type libraries and so even though this code successfully sets use_openssl and openssl_headers if OpenSSL is installed it fails to set openssl_libraries.
The following code is then executed
```
if test "${openssl_headers}" = "/usr/include" ; then
CRYPTO_CFLAGS=""
CRYPTO_INCLUDES=""
CRYPTO_LIBS="-lssl -lcrypto"
else
CRYPTO_CFLAGS=""
CRYPTO_INCLUDES="-I${openssl_headers}"
case $host in
*-solaris*)
CRYPTO_LIBS="-L${openssl_libraries} -R${openssl_libraries} -lssl -lcrypto"
;;
*-hp-hpux*)
CRYPTO_LIBS="-L${openssl_libraries} -Wl,+b: -lssl -lcrypto"
;;
*-apple-darwin*)
if test -f "${openssl_libraries}/libcrypto.dylib" ; then
CRYPTO_LIBS="-L${openssl_libraries} -lssl -lcrypto"
else
CRYPTO_LIBS="${openssl_libraries}/libssl.a ${openssl_libraries}/libcrypto.a"
fi
;;
*)
CRYPTO_LIBS="-L${openssl_libraries} -lssl -lcrypto"
;;
esac
fi
```
If openssl_headers is NOT `/usr/include`, which is likely on macOS since it's not an Apple supplied library and a standard build of OpenSSL will install in `/usr/local` instead of `/usr`, then CRYPTO_LIBS will be set to `/libssl.a /lib/crypto.a`, neither of which exist.
This will cause the following code snippets that test the existence of various EVP routing to all fail and hence configure aborts.
**Environment:**
- Kea version: kea-2.4.0
- OS: macOS 10.13.6next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2996implement draft-ietf-dhc-addr-notification2023-11-10T11:53:16ZVicky Riskvicky@isc.orgimplement draft-ietf-dhc-addr-notificationImplement https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/, once there is a client implementation to test with, possibly Android from Google.
Also known as "Registering Self-generated IPv6 Addresses using DHCPv6" this...Implement https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/, once there is a client implementation to test with, possibly Android from Google.
Also known as "Registering Self-generated IPv6 Addresses using DHCPv6" this draft implements a message from the DHCPv6 client to a DHCPv6 server to log the address the client is using. This enables the server administrator to better troubleshoot issues related to DHCP, because there is a centralized record of addresses associated with the clients using them.
The requirements in the draft include accepting the registration message from the client, returning an appropriately formed acknowledgement, logging a lease in the lease db, and retiring the address after the preferred lifetime has elapsed without a refresh.
[ [ After receiving this ADDR-REG-INFORM message, the address
registration server SHOULD verify that the address being registered
is "appropriate to the link" as defined by [RFC8415]. If the server
believes that address being registered is not appropriate to the
link [RFC8415], it MUST drop the message, and SHOULD log this fact.
If the address is appropriate, the server:
- [ ] SHOULD register or update a binding between the provided Client
Identifier and IPv6 address in its database;
- [ ] SHOULD log the address registration information (as is done
normally for clients which have requested an address), unless
configured not to do so;
- [ ] SHOULD mark the address as unavailable for use and not include it
in future ADVERTISE messages.
- [ ] SHOULD send back an ADDR-REG-REPLY message.
- [ ] If the address registration server does not receive such a refresh
after the preferred lifetime has passed, it SHOULD remove the record
of the Client-Identifier-to-IPv6-address binding.
There aren't any specific requirements in the draft about how to facilitate finding or monitoring these 'leases' so that is all implementation-specific. We might want to log receipt of these messages, if we can't mark the leases to indicate it was reported by the client, rather than a 'regular' dynamic lease from the DHCPv6 server.
- consider some indication on the lease record that this is self-assigned that would facilitate filtering and locating just this kind of lease records
- consider some log message indicating this was a self-assigned address reported by the clientbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2984Add support for Delegated-IPv6-Prefix to RADIUS hook2024-03-27T12:55:24ZDarren AnkneyAdd support for Delegated-IPv6-Prefix to RADIUS hookCurrently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to cr...Currently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to create a reservation for a prefix based on the content of delegated-ipv6-prefix (https://www.rfc-editor.org/rfc/rfc4818) in the access-accept response.
[RT22056](https://support.isc.org/Ticket/Display.html?id=22056)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2983mysql: Deprecated program name. It will be removed in a future release, use '...2023-08-10T13:48:04ZAndrei Pavelandrei@isc.orgmysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' insteadSome unit tests started showing these warnings:
```
[ RUN ] mysql.db-init
Wiping whole database keatest...
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated pro...Some unit tests started showing these warnings:
```
[ RUN ] mysql.db-init
Wiping whole database keatest...
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
Wiping whole database keatest...
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
[ OK ] mysql.db-init
```
The suggestion is to follow the warning's advice and replace the mysql client invocation with mariadb.
I used this version of the mysql client:
```
$ mysql --version
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
mysql from 11.0.2-MariaDB, client 15.2 for Linux (x86_64) using readline 5.1
$ mariadb --version
mariadb from 11.0.2-MariaDB, client 15.2 for Linux (x86_64) using readline 5.1
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2981"make coverage" doesn't work2023-08-10T13:44:47ZAndrei Pavelandrei@isc.org"make coverage" doesn't workThe coverage job in our internal Jenkins test environment started failing, when we upgraded Fedora from 36 to 38, likely because of a new gcovr version. That job uses an out-of-band set of actions to build the coverage report. While look...The coverage job in our internal Jenkins test environment started failing, when we upgraded Fedora from 36 to 38, likely because of a new gcovr version. That job uses an out-of-band set of actions to build the coverage report. While looking for alternatives, it was noticed that `make coverage` doesn't work either:
```
$ make coverage
[... goes on to run unit tests, but when the report needs to be made aka "make report-coverage" ...]
/bin/sh: -c: line 9: syntax error: unexpected end of file
make: *** [Makefile:1126: report-cpp-coverage] Error 2
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2979RAI based flex-id reservations2024-03-27T12:56:42ZPeter DaviesRAI based flex-id reservationsRAI based flex-id reservations:
When providing dhcp services for customer equipment, maintaining a consistent IP
address is often desired even when customers replace their equipment.
Host reservations may be defined using a ...RAI based flex-id reservations:
When providing dhcp services for customer equipment, maintaining a consistent IP
address is often desired even when customers replace their equipment.
Host reservations may be defined using a flex-id host identifier based on some
RAI options; however, the lease data will typically contain the hw-address as
the identifier.
This works well until the customer replaces his equipment and there is an active
lease on the reserved address with the old client's hw-address. In this case,
Kea will regard this as an address conflict.
Enabling the "replace-client-id" flex-id flag can mitigate this; however, changing
the value of this flag on a running Kea server will cause address conflicts.
Is there a way to address this problem?
[RT #20140](https://support.isc.org/Ticket/Display.html?id=20140)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2976Implement the ISC DHCP stash-agent-options in Kea2024-03-28T14:24:33ZFrancis DupontImplement the ISC DHCP stash-agent-options in KeaSee #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the R...See #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the RAI from its user context. Requires some design but on the paper this should do the job...
Note this is for v4 only because v6 requires a specific setup on both the client and the server for direct unicast queries so the problem never occurs in the real world.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2974New localize DHCP server command2023-09-01T14:23:21ZFrancis DupontNew localize DHCP server commandThe idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.The idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2972Empty hardware addresses not handled by PostgreSQL lease manager.2023-08-31T13:54:12ZFrancis DupontEmpty hardware addresses not handled by PostgreSQL lease manager.The PostgreSQL lease manager creates a type 1 (ETHER) hardware address on empty value for v4 leases instead to leave a null pointer (aka "none").
Minor bug so leaving it to next triage.The PostgreSQL lease manager creates a type 1 (ETHER) hardware address on empty value for v4 leases instead to leave a null pointer (aka "none").
Minor bug so leaving it to next triage.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2961Remove support for the deprecated auto-generated subnet IDs feature2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated auto-generated subnet IDs feature[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ipv4-subnet-identifier):
> It is one of the reasons why auto-generated subnet identifiers are deprecated starting from Kea version 2.4.0.
The deprecatio...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ipv4-subnet-identifier):
> It is one of the reasons why auto-generated subnet identifiers are deprecated starting from Kea version 2.4.0.
The deprecation happened in Kea 2.4. Kea 2.4 shipped with the deprecation warning in the ARM. Kea 2.5 can have the feature removed.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2960Remove support for the deprecated libreload command2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated libreload command[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/install.html#libreload-command):
> The libreload command was deprecated in Kea 2.3.4. The code to handle this command is still there, but there are reports of it being b...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/install.html#libreload-command):
> The libreload command was deprecated in Kea 2.3.4. The code to handle this command is still there, but there are reports of it being buggy and not really usable. Kea 2.3 and 2.4 versions will produce a warning when this command is used, and it will be removed entirely sometime in the 2.5 branch.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2959Remove support for the deprecated reservation-mode config flag2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated reservation-mode config flag[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#address-reservation-types):
> Since Kea 1.9.1, reservation mode has been replaced by three boolean flags, reservations-global, reservations-in-subnet, and...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#address-reservation-types):
> Since Kea 1.9.1, reservation mode has been replaced by three boolean flags, reservations-global, reservations-in-subnet, and reservations-out-of-pool, which allow the configuration of host reservations both globally and in a subnet.
The deprecation happened in Kea 1.9. Kea 2.0 shipped with the deprecation warning in the ARM. Kea 2.1 could have had support for these parameters removed.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2958Remove support for the deprecated dhcp-ddns config flags2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated dhcp-ddns config flags[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ddns-for-dhcpv4):
> [the D2 parameters] have been moved out of the dhcp-ddns section so that they may be specified at the global, shared-network, and/or s...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ddns-for-dhcpv4):
> [the D2 parameters] have been moved out of the dhcp-ddns section so that they may be specified at the global, shared-network, and/or subnet levels.
The deprecation happened in Kea 1.7. Kea 1.8 shipped with the deprecation warning in the ARM. Kea 1.9 could have had support for these parameters removed.
As a side note, the quotes statement contradicts another one in the ARM that says:
> These parameters can only be specified within the top-level dhcp-ddns section in the kea-dhcp4 configuration.
Also `ncr-format"` has an extraneous quote around that part of the ARM.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2957dhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on...2024-03-22T13:05:49ZJohn W. O'Briendhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on dhcp6_server table---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the b...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the behavior:
1. Initialize a PostgreSQL database using dhcpdb_create.pgsql
2. Inspect the dhcp4_server_modification_ts index
3. See that it is associated with the dhcp6_server table
**Expected behavior**
A clear and concise description of what you expected to happen:
The dhcp4_server_modification_ts index should be associated with the dhcp4_server table.
**Environment:**
- Kea version: 2.2.0
- OS: FreeBSD 13.2-RELEASE amd64
- Compiled with pgsql backend
- Loaded hooks: pgsql_cb
**Additional Information**
```
kea=> \di dhcp4_server_modification_ts
List of relations
Schema | Name | Type | Owner | Table
--------+------------------------------+-------+-------+--------------
public | dhcp4_server_modification_ts | index | kea | dhcp6_server
(1 row)
```
This appears to have been introduced as a [copy/paste error in version 7.0 of the schema](https://gitlab.isc.org/isc-projects/kea/-/blob/Kea-2.3.8/src/share/database/scripts/pgsql/dhcpdb_create.pgsql#L1398). I could identify no correspond bug in the MySQL schema.
**Contacting you**
* SMS/Signal: (available upon request)
* GitHub/GitLab: neirbowj
* Mastodon: [@neirbowj@mastodon.online](https://mastodon.online/@neirbowj)kea2.5.8