ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-06-22T15:15:46Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/139ipv6 address contains 'add', make conf check error2021-06-22T15:15:46Zdreamandtureipv6 address contains 'add', make conf check erroripv6 address contains 'add', make conf check error
fixed-address6 240c:4051:2125:713:add:89ff:fd63:1e42;
line 2132: Invalid IPv6 address.
fixed-address6 240c:4051:2125:713:add:
^
!...ipv6 address contains 'add', make conf check error
fixed-address6 240c:4051:2125:713:add:89ff:fd63:1e42;
line 2132: Invalid IPv6 address.
fixed-address6 240c:4051:2125:713:add:
^
![image](/uploads/6f906431f0ffffe32338c0045505d2f9/image.png)https://gitlab.isc.org/isc-projects/bind9/-/issues/2190dig: "-u" (microsecond timestamp precision) does not work in YAML output mode2022-04-26T13:14:41Zchampiondotdig: "-u" (microsecond timestamp precision) does not work in YAML output modeHI,ALL:
The version BIND-9.16.7 of the software I'm using
dig www.google.com +yaml
When using the above command to query, there is no query time like option('-u') in the output result
dig www.google.com -u
**;; Query time: 6999 u...HI,ALL:
The version BIND-9.16.7 of the software I'm using
dig www.google.com +yaml
When using the above command to query, there is no query time like option('-u') in the output result
dig www.google.com -u
**;; Query time: 6999 usec**
Combined with the output
dig www.google.com -u +yamlOctober 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/2189some comments in lib/dns/stats.c use incorrect notation for bit values2020-10-02T09:24:41ZBrian Conrysome comments in lib/dns/stats.c use incorrect notation for bit valuesSome of the comments in `lib/dns/stats.c` refer to values in a 2-bit field as `0x11`, which requires 5 bits, instead of `0b11`.
affects 9.16 and 9.17Some of the comments in `lib/dns/stats.c` refer to values in a 2-bit field as `0x11`, which requires 5 bits, instead of `0b11`.
affects 9.16 and 9.17October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/kea/-/issues/1438Simplify and document version-info bump up procedure2020-12-07T21:15:03ZMarcin SiodelskiSimplify and document version-info bump up procedureThe following page describes how to bump up library version numbers before a software release with libtool:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Most of the cases we bump up `current` version ...The following page describes how to bump up library version numbers before a software release with libtool:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Most of the cases we bump up `current` version number to indicate that new Kea must use new library. The major source of confusion was the `age` number. This number should be set back to 0 whenever the new library should not be used by the old Kea code to avoid crashes. In libtool terms this is the case when existing interfaces has been changed or removed. The old Kea version could be using those interfaces in the form in which they previously existed leading to crashes.
We recently tried to follow the guidelines in keeping the `age` number positive and incremented, rather than set to 0 in cases when the new lib version could work with old Kea version. In libtool terms it is the case when new interfaces were added and existing interfaces were neither changed nor removed. So, the old Kea version is never using new interfaces but that's ok. Since old interfaces are not modified it is safe for old Kea to use them. That's the theory....
The reality is that engineers working on the tickets to bump up lib version numbers often face a dilemma what it means that the interfaces are neither changed nor removed. Well, removed may be more obvious. For changes, the fact that you don't instantly see them doesn't mean they don't exist. Kea is a complex software and there are many dependencies between various modules. We think that we made a mistake several times assuming that no interfaces were changed but the changes took place, only they weren't that obvious.
This ticket is to propose and document some consistent way of using libtool version numbers which would minimize the risk of mistakes.
One of the schemes to be considered is the following:
- if there were any code changes in the library between previous release and current release bump up current version number and set other numbers to 0, i.e. c+1:0:0.
- if there were no code changes in the library, leave the version-info as is.
That way we'd preclude the use of old Kea versions with new Kea libraries versions. We'd also require that new Kea version is always using the most recent code, even if the applied changes were cosmetic. This is a brute force way to keep the libs consistent with the Kea version, which may be considered as a down side, but it also has some advantages besides mistakes avoidance....
One of the benefits of such approach is that it becomes trivial to automate lib version bumps with a script that checks whether there were any changes in the lib and bumps up current number. Previously, an engineer had to look and investigate what class of changes were applied and that's not something the script could do.kea1.9.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2188Bug in message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) fa...2024-03-22T08:14:06ZFstarkBug in message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed<!--
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
message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed, back trace
```
test@test:~/bind9/collect$ ./dns_message_parse_fuzzer id\:000000\,sig\:06\,src\:002736+001626\,time\:192782276\,op\:splice\,rep\:128
INFO: Seed: 1666455395
INFO: Loaded 1 modules (61310 inline 8-bit counters): 61310 [0x100d2b0, 0x101c22e),
INFO: Loaded 1 PC tables (61310 PCs): 61310 [0x101c230,0x110ba10),
./dns_message_parse_fuzzer: Running 1 inputs 1 time(s) each.
Running: id:000000,sig:06,src:002736+001626,time:192782276,op:splice,rep:128
message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed, back trace
./dns_message_parse_fuzzer() [0xab474a]
./dns_message_parse_fuzzer() [0xab43d0]
./dns_message_parse_fuzzer() [0xab422a]
./dns_message_parse_fuzzer() [0x566c5f]
./dns_message_parse_fuzzer() [0x566da7]
./dns_message_parse_fuzzer() [0x551bc4]
./dns_message_parse_fuzzer() [0x550f98]
./dns_message_parse_fuzzer() [0x45a0c2]
./dns_message_parse_fuzzer() [0x445843]
./dns_message_parse_fuzzer() [0x44b89f]
./dns_message_parse_fuzzer() [0x473213]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f0090f5eb97]
./dns_message_parse_fuzzer() [0x41fed9]
==23768== ERROR: libFuzzer: deadly signal
#0 0x527611 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
#1 0x472a38 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
#2 0x458b63 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:232:3
#3 0x7f009196489f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1289f)
#4 0x7f0090f7bf46 in __libc_signal_restore_set /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/nptl-signals.h:80
#5 0x7f0090f7bf46 in gsignal /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:48
#6 0x7f0090f7d8b0 in abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:79
#7 0xab4233 in isc_assertion_failed /src/bind9/lib/isc/assertions.c:47:2
#8 0x566c5e in msgreset /src/bind9/lib/dns/message.c:673:2
#9 0x566da6 in dns_message_destroy /src/bind9/lib/dns/message.c:801:2
#10 0x551bc3 in render_message /src/bind9/fuzz/dns_message_parse.c:131:2
#11 0x550f97 in LLVMFuzzerTestOneInput /src/bind9/fuzz/dns_message_parse.c:162:11
#12 0x45a0c1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:558:15
#13 0x445842 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:296:6
#14 0x44b89e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:796:9
#15 0x473212 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
#16 0x7f0090f5eb96 in __libc_start_main /build/glibc-2ORdQG/glibc-2.27/csu/../csu/libc-start.c:310
#17 0x41fed8 in _start (/home/test/bind9/collect/dns_message_parse_fuzzer+0x41fed8)
NOTE: libFuzzer has rudimentary signal handlers.
Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
```
### BIND version used
master-git
### Steps to reproduce
./fuzzer POC
[bind9.zip](/uploads/58bf9e655b37622954937535b1e69bd6/bind9.zip)
### What is the current *bug* behavior?
crash
### Relevant logs and/or screenshots
File in zip
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1437distcheck is failing2020-09-28T10:31:43ZMichal Nowikowskidistcheck is failingFailed builds on jenkins:
https://jenkins.isc.org/job/kea-dev/job/distcheck/
from # 10 to # 13.
The failures can look differently:
1.
```
[----------] Global test environment tear-down
[==========] 651 tests from 46 test cases ran. (6...Failed builds on jenkins:
https://jenkins.isc.org/job/kea-dev/job/distcheck/
from # 10 to # 13.
The failures can look differently:
1.
```
[----------] Global test environment tear-down
[==========] 651 tests from 46 test cases ran. (6828 ms total)
[ PASSED ] 642 tests.
[ FAILED ] 9 tests, listed below:
[ FAILED ] IfaceMgrTest.receiveTimeout6
[ FAILED ] IfaceMgrTest.sockets6
[ FAILED ] IfaceMgrTest.socketsFromIface
[ FAILED ] IfaceMgrTest.socketsFromAddress
[ FAILED ] IfaceMgrTest.socketsFromRemoteAddress
[ FAILED ] IfaceMgrTest.sendReceive6
[ FAILED ] PktFilterInet6Test.openSocket
[ FAILED ] PktFilterInet6Test.send
[ FAILED ] PktFilterInet6Test.receive
9 FAILED TESTS
YOU HAVE 7 DISABLED TESTS
FAIL: libdhcp++_unittests
======================================
1 of 1 test failed
Please report to kea-dev@lists.isc.org
======================================
make[7]: *** [Makefile:1738: check-TESTS] Błąd 1
make[7]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib/dhcp/tests'
make[6]: *** [Makefile:1889: check-am] Błąd 2
make[6]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib/dhcp/tests'
make[5]: *** [Makefile:1645: check-recursive] Błąd 1
make[5]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib/dhcp/tests'
make[4]: *** [Makefile:1171: check-recursive] Błąd 1
make[4]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib/dhcp'
make[3]: *** [Makefile:458: check-recursive] Błąd 1
make[3]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib'
make[2]: *** [Makefile:451: check-recursive] Błąd 1
make[2]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src'
make[1]: *** [Makefile:622: check-recursive] Błąd 1
make[1]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub'
make: *** [Makefile:836: distcheck] Błąd 1
```
or 2.
```
22:14:46.082 [----------] Global test environment tear-down
22:14:46.082 [==========] 650 tests from 25 test cases ran. (14302 ms total)
22:14:46.082 [ PASSED ] 649 tests.
22:14:46.082 [ FAILED ] 1 test, listed below:
22:14:46.082 [ FAILED ] CtrlChannelDhcpv4SrvTest.controlChannelStats
22:14:46.082
22:14:46.082 1 FAILED TEST
22:14:46.082 YOU HAVE 2 DISABLED TESTS
22:14:46.082
22:14:46.082 FAIL: dhcp4_unittests
22:14:46.082 ======================================
22:14:46.082 1 of 1 test failed
22:14:46.082 Please report to kea-dev@lists.isc.org
22:14:46.082 ======================================
22:14:46.082 make[6]: *** [Makefile:1307: check-TESTS] Error 1
22:14:46.082 make[6]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests'
22:14:46.082 make[5]: *** [Makefile:1433: check-am] Error 2
22:14:46.082 make[5]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests'
22:14:46.082 make[4]: *** [Makefile:714: check-recursive] Error 1
22:14:46.082 make[4]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4'
22:14:46.082 make[3]: *** [Makefile:453: check-recursive] Error 1
22:14:46.082 make[3]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin'
22:14:46.082 make[2]: *** [Makefile:451: check-recursive] Error 1
22:14:46.082 make[2]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src'
22:14:46.082 make[1]: *** [Makefile:622: check-recursive] Error 1
22:14:46.082 make[1]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub'
22:14:46.082 make: *** [Makefile:836: distcheck] Error 1
```
or 3.
```
20:50:12.373 Running command "/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/kea-dhcp4 -t /home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json".
20:50:12.373 Syntax check failed with: /home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json:1.11-22: got unexpected keyword "interfaces" in Dhcp4 map.
20:50:12.373 PASSED dhcpv4.syntax_check_bad_syntax
20:50:12.373
20:50:12.373
20:50:12.374 START TEST dhcpv4.syntax_check_bad_values
20:50:12.374 Creating Kea configuration file: /home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json.
20:50:12.374 Running command "/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/kea-dhcp4 -t /home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json".
20:50:12.374 Error encountered: subnet configuration failed: a pool of type V4, with the following address range: 192.168.0.10-192.168.0.100 does not match the prefix of a subnet: 10.0.0.0/8 to which it is being added (/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json:1:173)
20:50:12.374 PASSED dhcpv4.syntax_check_bad_values
20:50:12.374
20:50:12.374 make[6]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests'
20:50:12.374 Makefile:1392: recipe for target 'check-am' failed
20:50:12.374 make[5]: *** [check-am] Error 2
20:50:12.374 make[5]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests'
20:50:12.374 Makefile:701: recipe for target 'check-recursive' failed
20:50:12.374 make[4]: *** [check-recursive] Error 1
20:50:12.374 make[4]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4'
20:50:12.374 Makefile:453: recipe for target 'check-recursive' failed
20:50:12.374 make[3]: *** [check-recursive] Error 1
20:50:12.374 make[3]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin'
20:50:12.374 Makefile:451: recipe for target 'check-recursive' failed
20:50:12.374 make[2]: *** [check-recursive] Error 1
20:50:12.374 make[2]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src'
20:50:12.374 Makefile:622: recipe for target 'check-recursive' failed
20:50:12.374 make[1]: *** [check-recursive] Error 1
20:50:12.374 make[1]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub'
20:50:12.374 Makefile:828: recipe for target 'distcheck' failed
20:50:12.374 make: *** [distcheck] Error 1
```kea1.9.0https://gitlab.isc.org/isc-projects/kea/-/issues/1436Document DHCPv6 options set by Kea2020-10-23T11:04:48ZTomek MrugalskiDocument DHCPv6 options set by KeaThere's a long list of v6 options that Kea supports, but they're not listed as supported, because they can't be configured explicitly. However, support requested a documentation for similar options in v4 (see #1323) and @tomek added it. ...There's a long list of v6 options that Kea supports, but they're not listed as supported, because they can't be configured explicitly. However, support requested a documentation for similar options in v4 (see #1323) and @tomek added it. We should have a similar list for v6.
It's actually easy to do: checkout old branch (e.g. v1_4_0) and look at doc/guide/dhcp6-srv.xml for comments around line 1344.kea1.9.1https://gitlab.isc.org/isc-projects/kea/-/issues/1435Backport #1431 (remove mutli-threading experimental message)2020-11-27T06:38:00ZTomek MrugalskiBackport #1431 (remove mutli-threading experimental message)We should remove the experimental message from 1.8.x branch.We should remove the experimental message from 1.8.x branch.kea1.8.1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1434HA hook with mysql backend not working2020-11-05T16:25:38ZMichal HynekHA hook with mysql backend not workingHello, I Have problem with HA (in my case hot-standby). Server is unable to sync leases.
```
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 100.104.3.2
202...Hello, I Have problem with HA (in my case hot-standby). Server is unable to sync leases.
```
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 100.104.3.2
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_UPDATE_ADDR4 updating IPv4 lease for address 100.104.3.2
2020-09-25 09:51:32.806 WARN [kea-dhcp4.ha-hooks/34387.140540437956480] HA_LEASE_SYNC_FAILED synchronization failed for lease: { "cltt": 1600979173, "fqdn-fwd": true, "fqdn-rev": true, "hostname": "lt_pohorany_137_eap1", "hw-address": "c4:ad:34:ce:99:64", "ip-address": "100.104.3.2", "state": 0, "subnet-id": 10010400, "valid-lft": 432000 }, reason: unable to update lease for address 100.104.3.2 as it does not exist
```
mysql debug:
```
2020-09-25T07:51:32.806428Z 370 Execute SELECT address, hwaddr, client_id, valid_lifetime, expire, subnet_id, fqdn_fwd, fqdn_rev, hostname, state, user_context FROM lease4 WHERE address = 1684538114
2020-09-25T07:51:32.806540Z 370 Execute UPDATE lease4 SET address = 1684538114, hwaddr = 'ĭ4Ιd', client_id = NULL, valid_lifetime = 432000, expire = '2020-09-29 22:26:13', subnet_id = 10010400, fqdn_fwd = 1, fqdn_rev = 1, hostname = 'lt_pohorany_137_eap1', state = 0, user_context = NULL WHERE address = 1684538114 AND expire = '1970-01-01 01:00:00'
```
you can see it tries to match weird expire value '1970-01-01 01:00:00' but in database is:
```
mysql> SELECT * FROM dhcp.lease4 WHERE address=1684538114;
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
| address | hwaddr | client_id | valid_lifetime | expire | subnet_id | fqdn_fwd | fqdn_rev | hostname | state | user_context |
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
| 1684538114 | ĭ4Ιd | NULL | 432000 | 2020-09-27 10:26:13 | 10010400 | 1 | 1 | lt_pohorany_137_eap1 | 0 | NULL |
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
1 row in set (0.00 sec)
```
Time is synchronized on both server. Same timezone selected.
**Expected behavior**
- Lease on remote site will update
**Environment:**
- Kea version: 1.8.0 + libdhcp_lease_cmds + libdhcp_ha
- OS: Debian x64
- Mysql server: 5.7.31 (Percona Server)kea1.9.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1433hammer: problem with building centos 8 and passing attempts argument2021-05-04T10:55:36ZMichal Nowikowskihammer: problem with building centos 8 and passing attempts argumentkea1.9.0Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1432hammer: building centos 8 fails due to network issues2021-05-04T10:55:36ZMichal Nowikowskihammer: building centos 8 fails due to network issuessolution: add retries on network operationssolution: add retries on network operationskea1.9.0Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1431Misleading multithread msg being generated on startup2020-11-04T20:08:17ZPeter DaviesMisleading multithread msg being generated on startupKea 1.8.0
When multithreading is enabled Kea logs the following message:
DHCP4_MULTI_THREADING_WARNING The multi-threading feature is experimental. Don't use in production environment." is multi-threading still a experimental feature?
T...Kea 1.8.0
When multithreading is enabled Kea logs the following message:
DHCP4_MULTI_THREADING_WARNING The multi-threading feature is experimental. Don't use in production environment." is multi-threading still a experimental feature?
This text ought to be amended.kea1.9.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2185nsdname-wait-recurse speed test fails under tsan2020-10-02T08:38:18ZMark Andrewsnsdname-wait-recurse speed test fails under tsan```
7640I:rpzrecurse:checking 'nsdname-wait-recurse no' is faster than 'nsdname-wait-recurse yes' (72)
7641I:rpzrecurse:timing 'nsdname-wait-recurse yes' (default)
7642I:rpzrecurse:elapsed time 0 seconds
7643I:rpzrecurse:timing 'nsdname-...```
7640I:rpzrecurse:checking 'nsdname-wait-recurse no' is faster than 'nsdname-wait-recurse yes' (72)
7641I:rpzrecurse:timing 'nsdname-wait-recurse yes' (default)
7642I:rpzrecurse:elapsed time 0 seconds
7643I:rpzrecurse:timing 'nsdname-wait-recurse no'
7644I:rpzrecurse:elapsed time 0 seconds
7645I:rpzrecurse:failed
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/stork/-/issues/413Stork not pulling lease stats for DHCP42023-03-15T16:52:51ZleecgenesisStork not pulling lease stats for DHCP4---
name: Stork not pulling lease stats for DHCP4
about: Stork colocated on a single kea-dhcp4/6 host running Kea 1.8.0 and Stork 0.11 is not reporting DHCP4 lease statistics.
---
**Describe the bug**
I have a single DHCP VM built with...---
name: Stork not pulling lease stats for DHCP4
about: Stork colocated on a single kea-dhcp4/6 host running Kea 1.8.0 and Stork 0.11 is not reporting DHCP4 lease statistics.
---
**Describe the bug**
I have a single DHCP VM built with Kea version 1.8.0 and Stork 0.11 running on CentOS 7 using prebuilt packages. It's sole purpose is to serve as a DHCP helper for a small regional network. It's currently got 3 IPv4 ranges and 4 IPv6 ranges. The IPv4 ranges contain approximately 1000 IPv4 addresses, and the IPv6 ranges are /64's with prefix delegation handing out /56's from a larger /48 block.
Stork is working fine, on non-standard ports, however the DHCP4 statistics never report. IPv6 statistics, including leases AND prefix-delegations report just fine. Looking at the stdout for the isc-stork-server process, I see the following repeating errors every minute:
statspuller.go:59 missing key total-addreses in LocalSubnet 4 stats
statspuller.go:59 missing key total-addreses in LocalSubnet 5 stats
statspuller.go:59 missing key total-addreses in LocalSubnet 6 stats
Additionally,
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea 1.8.0, Stork 0.11 from package manager in CentOS 7.
2. Configure kea-ctrl-agent, kea-dhcp4, kea-dhcp6, and agent.env, server.env as attached.
3. DHCP Processes work, clients receive addresses and IPv6 Prefix Delegations.
4. Kea functions as expected.
5. Stork does NOT display DHCP4 statistics, DOES display DHCP6 statistics.
**Expected behavior**
I expect stork to display both DHCP4 and DHCP6 statistics for all discovered ranges.
**Environment:**
- Kea version: 1.8.0
- Stork: 0.11.0
- OS: CentOS 7.8
- Kea: Using MySQL backend, but memfile and PSQL backend also compiled in.
- Kea: Using libdhcp_stat_cmds.so and libdhcp_lease_cmds.so on both DHCP4 and DHCP6.
[agent.env](/uploads/d8037ffb05b4d499d03d5114cd04d819/agent.env)
[kea-ctrl-agent.conf](/uploads/f5c4d0cfeca2c8f72c17160f842bc189/kea-ctrl-agent.conf)
[kea-dhcp4.conf](/uploads/56f052faff28a147b0ca5f0dddbcb249/kea-dhcp4.conf)
[kea-dhcp6.conf](/uploads/91598b56fcd21981d1a9da2cf27a7524/kea-dhcp6.conf)
[server.env](/uploads/6e79c09f7caa83e28275697779c5f8da/server.env)0.13Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2184Add RFC8906 to list of RFCs in doc/arm/general.rst2020-09-24T11:55:10ZSuzanne GoldlustAdd RFC8906 to list of RFCs in doc/arm/general.rstNow that RFC8906 has been officially accepted/published, I want to add it to the list of RFCs in the ARM.Now that RFC8906 has been officially accepted/published, I want to add it to the list of RFCs in the ARM.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/kea/-/issues/1430flex_option should be able to generate option data according to a specified p...2020-09-28T12:47:01ZRazvan Becheriuflex_option should be able to generate option data according to a specified patternkea1.9.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1429hammer: add support for building kea on Alpine 3.122021-05-04T10:55:36ZMichal Nowikowskihammer: add support for building kea on Alpine 3.12kea1.9.1Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1428Multiple reservations for the same IP2022-10-25T13:30:06ZTomek MrugalskiMultiple reservations for the same IPA new use case has been brought to our attention. A new device with two NICs is being powered. Each NIC has its own MAC address. However, at any given time only one of those NICs is connected and powered up. Sadly, it's not possible to d...A new use case has been brought to our attention. A new device with two NICs is being powered. Each NIC has its own MAC address. However, at any given time only one of those NICs is connected and powered up. Sadly, it's not possible to determine this a'priori which interface will be connected. The intention here to have the same IP address assigned, regardless which NIC will be used.
Under normal circumstances, it is a configuration error to have more than one reservation for the same IP. However, the use case above provides an external constraint that ensures this conflict will never be observed, as there is always only one of the two reservations that will be in use.
The goal of this ticket is to make such operation possible.
While we will start this work in %"kea1.9.0", given the imminent code freeze this Friday, the solution will likely be available in %"kea1.9.1"
[Support ticket #17096](https://support.isc.org/Ticket/Display.html?id=17096)kea1.9.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2183DNS Flag Day 20202022-04-26T13:13:00ZOndřej SurýDNS Flag Day 2020This is a issue to make the necessary changes for DNS Flag Day 2020.This is a issue to make the necessary changes for DNS Flag Day 2020.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1427bump up library versions and HOOKS_VERSION if needed (kea 1.9.0 release)2020-09-23T12:07:48ZMichal Nowikowskibump up library versions and HOOKS_VERSION if needed (kea 1.9.0 release)if not needed, please close this issueif not needed, please close this issuekea1.9.0