ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-11-12T20:22:29Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/140Client Link-Layer Address Option in DHCPv62020-11-12T20:22:29ZChristian RebischkeClient Link-Layer Address Option in DHCPv6---
name: Client Link-Layer Address Option in DHCPv6
about: Add Client Link-Layer Address Option in DHCPv6
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? **not sur...---
name: Client Link-Layer Address Option in DHCPv6
about: Add Client Link-Layer Address Option in DHCPv6
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? **not sure**
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a **not sure**
good time to consider migration? **not sure**
- Are you sure what you would like to do is not possible using some other mechanisms? **not sure**
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists? **no**
**Is your feature request related to a problem? Please describe.**
I would like to see this feature in ISC-DHCP: https://tools.ietf.org/html/rfc6939
**Describe the solution you'd like**
See above
**Describe alternatives you've considered**
There is no real alternative right now, as far as I am aware.
**Additional context**
none
**Funding its development**
Sorry, I can't fund.
**Participating in development**
I would be willing to donate a PR, but my C skills are a little bit rusty and I would need some 'direction' where I need to add this feature. How complicated is this to add? The RFC seems pretty short.
**Contacting you**
christian.rebischke@avency.dehttps://gitlab.isc.org/isc-projects/kea/-/issues/1448Load kea config from another kea server2021-09-30T15:18:17ZPeter DaviesLoad kea config from another kea serverLoad kea config from another kea server
I would appear we have all the necessary mechanisms to enable a secondary HA server to load its configuration from the primary.
This feature could be enabled with a command line parameter that co...Load kea config from another kea server
I would appear we have all the necessary mechanisms to enable a secondary HA server to load its configuration from the primary.
This feature could be enabled with a command line parameter that could instruct the server to look and retrieve its config from a server/address before loading its local config.
In this way users running into issues caused by mismatching configurations and typos.
The interface name and "this-server-name" would need to be syntherzied somehow.Kea1.9-backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/21979.16.6 exited with assertion failure after minor in-flight configuration change2022-01-25T16:56:10ZHåvard Eidnes9.16.6 exited with assertion failure after minor in-flight configuration change<!--
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
10s after a minor configuration change, BIND exited with an assertion failure.
After a restart, it has continued working as normal.
### BIND version used
```
BIND 9.16.6 (Stable Release) <id:25846cf>
running on NetBSD amd64 9.0_RC1 NetBSD 9.0_RC1 (GENERIC) #0: Sat Dec 14 12:36:33 UTC 2019 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--enable-dnstap' '--with-protobuf-c=/usr/pkg' '--with-libfstrm=/usr/pkg' '--sysconfdir=/etc' '--localstatedir=/var'
compiled by GCC 7.4.0
compiled with OpenSSL version: OpenSSL 1.1.1c 28 May 2019
linked to OpenSSL version: OpenSSL 1.1.1c 28 May 2019
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with zlib version: 1.2.10
linked to zlib version: 1.2.10
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
The configuration changes introduced were:
```
--- named.conf 2020/10/02 10:02:54 1.23
+++ named.conf 2020/10/02 10:06:18 1.24
@@ -1,7 +1,6 @@
options {
directory "/etc/namedb";
- dnssec-enable yes;
dnssec-validation yes;
managed-keys-directory "keys";
@@ -17,6 +16,10 @@
// minimization for now. May be related to forwarding...
//qname-minimization off;
+ // Be nice, conform to DNS flag day 2020
+ edns-udp-size 1232;
+ max-udp-size 1232;
+
// Force these in preparation for anycast addresses
// which we never want to use as query source
query-source address 158.37.2.68;
@@ -82,7 +85,7 @@
};
};
-managed-keys {
+trust-anchors {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
```
### What is the current *bug* behavior?
```
Oct 2 12:06:07 tos-res named[6701]: reloading configuration succeeded
Oct 2 12:06:07 tos-res named[6701]: scheduled loading new zones
Oct 2 12:06:07 tos-res named[6701]: any newly configured zones are now loaded
Oct 2 12:06:07 tos-res named[6701]: running
Oct 2 12:06:17 tos-res named[6701]: resolver.c:10193: INSIST(((res->dbuckets[i].list).head == ((void *)0))) failed, back trace
Oct 2 12:06:17 tos-res named[6701]: #0 0x434978 in assertion_failed()+0x4d
Oct 2 12:06:17 tos-res named[6701]: #1 0x5edd88 in isc_assertion_failed()+0xa
Oct 2 12:06:17 tos-res named[6701]: #2 0x550e33 in dns_resolver_detach()+0x501
Oct 2 12:06:17 tos-res named[6701]: #3 0x5896cf in destroy()+0x129
Oct 2 12:06:17 tos-res named[6701]: #4 0x58a427 in adb_shutdown()+0x52
Oct 2 12:06:17 tos-res named[6701]: #5 0x610f77 in run()+0x6b2
Oct 2 12:06:17 tos-res named[6701]: #6 0x72753c20c1d8 in _fini()+0x72753bbc5778
Oct 2 12:06:17 tos-res named[6701]: #7 0x72753bc87af0 in _fini()+0x72753b641090
Oct 2 12:06:17 tos-res named[6701]: exiting (due to assertion failure)
```
### What is the expected *correct* behavior?
BIND should have continued working as normal.
I don't know, it *may* be coincidental, but 10s is "too close for comfort".
Besides, that BIND continues working now after a full restart tends to indicate
that the problem was the in-flight configuration change and not the configuration
change itself.
### Relevant configuration files
`named-checkconf -px` output follows:
```
logging {
channel "normal" {
syslog "local2";
severity dynamic;
};
channel "trash" {
syslog "local3";
severity dynamic;
};
channel "security" {
syslog "local4";
severity dynamic;
};
channel "qerrs" {
syslog "local1";
severity dynamic;
};
channel "queries" {
syslog "local0";
severity dynamic;
};
channel "client_log" {
file "/var/log/client.log" versions 30 size 10485760;
severity dynamic;
print-time yes;
};
channel "rpzlog" {
file "/var/log/named.rpz" versions 50 size 10485760;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "null" {
null ;
};
category "default" {
"normal";
"default_debug";
};
category "general" {
"normal";
"default_debug";
};
category "config" {
"normal";
"default_debug";
};
category "network" {
"normal";
"default_debug";
};
category "notify" {
"normal";
"default_debug";
};
category "xfer-in" {
"normal";
"default_debug";
};
category "xfer-out" {
"normal";
"default_debug";
};
category "dnssec" {
"security";
};
category "security" {
"security";
};
category "rpz" {
"rpzlog";
};
category "database" {
"null";
};
category "lame-servers" {
"null";
};
category "update-security" {
"null";
};
category "update" {
"null";
};
category "query-errors" {
"qerrs";
};
category "queries" {
"queries";
};
category "client" {
"client_log";
};
};
options {
datasize 8589934592;
directory "/etc/namedb";
dnstap-output unix"/var/run/named/dnstap.sock";
hostname "tos-res.uninett.no";
listen-on {
"any";
};
listen-on-v6 {
"any";
};
managed-keys-directory "keys";
querylog no;
server-id "tos-res.uninett.no";
dnssec-validation yes;
dnstap {
client query;
};
edns-udp-size 1232;
max-udp-size 1232;
qname-minimization relaxed;
query-source address 158.37.2.68 port 0;
query-source-v6 address 2001:700:0:804f::ca53 port 0;
recursion yes;
response-policy {
zone "dns-rpz.uninett.no";
zone "zone3.ph.rpz.switch.ch" policy disabled;
zone "zone3.mw.rpz.switch.ch" policy disabled;
zone "zone3.misc.rpz.switch.ch" policy disabled;
} break-dnssec yes;
allow-query {
"localnets";
78.91.0.0/16;
128.39.0.0/16;
129.177.0.0/16;
129.240.0.0/15;
129.242.0.0/16;
144.164.0.0/16;
151.157.0.0/16;
152.94.0.0/16;
156.116.0.0/16;
157.249.0.0/16;
158.36.0.0/14;
161.4.0.0/16;
192.111.33.0/24;
192.133.32.0/24;
192.146.238.0/23;
193.156.0.0/15;
2001:700::/32;
146.172.4.0/23;
148.122.20.52/31;
148.123.37.165/32;
2001:67c:29f4::/48;
44.141.124.0/24;
44.141.132.0/24;
193.35.52.0/22;
};
forward first;
forwarders {
158.38.0.168;
128.39.2.24;
};
};
statistics-channels {
inet 127.0.0.1 port 8053 allow {
127.0.0.1/32;
};
inet 158.37.2.68 port 8053 allow {
158.38.62.0/23;
158.38.10.0/24;
};
};
server 54.209.136.173/32 {
send-cookie no;
};
server 204.153.45.2/32 {
send-cookie no;
};
trust-anchors {
"." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
"." initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
"7.4.nrenum.net" initial-key 257 3 8 "AwEAAdyLRICD7vMGdRG+uwF9176xm5u+E22zJehX7luBrY8LeUsw0aT9
WxBe2aKYSoBbAROVcuQJ/8EbbL+XhX5RKieRZFLDS1hQc+BpLY4Vse5G
2OeWYbH9lWEUM6/XErTsUikYfchXxWg6PkidN/howfNmo7iHDgeG/Xfz
E+i2MLZHCCnNND6v2DE8aP4qYzmU/jEc7n4814z2HR1dzpK/eXZwY3Tv
MjnTh3cqayi8b2B7+tedwV874plFOtMdTwywnMnXf1R3C3HBIZXHu55F
Ptd7cMbikW0lEc7BRRYL50knDMk7jcnsnA7MI1hOu3vI1cNAUWM+CmWX
DXShJKcLF0s=";
};
zone "." {
type hint;
file "root.cache";
};
zone "localhost" {
type master;
file "localhost";
};
zone "127.IN-ADDR.ARPA" {
type master;
file "127";
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "loopback.v6";
};
zone "dns-rpz.uninett.no" {
type slave;
file "sz/dns-rpz.uninett.no";
masters {
158.38.212.119;
};
};
zone "zone3.ph.rpz.switch.ch" {
type slave;
file "sz/zone3.ph.rpz.switch.ch";
masters {
158.38.212.119;
};
};
zone "zone3.mw.rpz.switch.ch" {
type slave;
file "sz/zone3.mw.rpz.switch.ch";
masters {
158.38.212.119;
};
};
zone "zone3.misc.rpz.switch.ch" {
type slave;
file "sz/zone3.misc.rpz.switch.ch";
masters {
158.38.212.119;
};
};
```
### Relevant logs and/or screenshots
See above.
### Possible fixes
Sorry, don't know.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/kea/-/issues/1447use thread_local to optimize access to thread context2021-10-20T11:53:14ZRazvan Becheriuuse thread_local to optimize access to thread contextmoved from
#1333 https://gitlab.isc.org/isc-projects/kea/-/merge_requests/917
and
#1333 https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/130moved from
#1333 https://gitlab.isc.org/isc-projects/kea/-/merge_requests/917
and
#1333 https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/130outstandingWlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1446Control the amount of certain attributes in RADIUS packets per RFCs 2865, 28662024-03-20T11:22:24ZAndrei Pavelandrei@isc.orgControl the amount of certain attributes in RADIUS packets per RFCs 2865, 2866Attributes that are marked with `0`, `0-1`, `1` in RFCs 2865, 2866 need to be verified when building a RADIUS packet. `0+` has no restrictions. More details in #1441.Attributes that are marked with `0`, `0-1`, `1` in RFCs 2865, 2866 need to be verified when building a RADIUS packet. `0+` has no restrictions. More details in #1441.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1445Forensic logging should cover DECLINE and RELEASE2020-10-22T17:18:24ZTomek MrugalskiForensic logging should cover DECLINE and RELEASEIt was reported (see [support#17179](https://support.isc.org/Ticket/Display.html?id=17179)) that the forensic logging could handle the situation better when:
* client sends DECLINE
* client sends RELEASE
See patch attached in the suppo...It was reported (see [support#17179](https://support.isc.org/Ticket/Display.html?id=17179)) that the forensic logging could handle the situation better when:
* client sends DECLINE
* client sends RELEASE
See patch attached in the support ticket.kea1.9.1Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2195FreeBSD dnstap system test failure2021-02-23T14:20:11ZDiego dos Santos FronzaFreeBSD dnstap system test failurednstap system test on FreeBSD may fail due to an attempt in reading a not yet flushed dnstap file captured by fstrm_capture tool.dnstap system test on FreeBSD may fail due to an attempt in reading a not yet flushed dnstap file captured by fstrm_capture tool.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/kea/-/issues/1444LeaseX-update and leaseX-del cmds must be propaged to ha members2021-10-19T07:34:04Zmirackle-spbLeaseX-update and leaseX-del cmds must be propaged to ha members---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request ...---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request to primary is not enough. I need to send same request to stand-by member.
**Describe the solution you'd like**
Send update and del cmds to all ha members after completion on one node to maintain sync.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2194Occasional rndc crashes in tcp_connect_cb() on OpenBSD2020-12-09T09:53:30ZMichał KępieńOccasional rndc crashes in tcp_connect_cb() on OpenBSDEven with !4089 merged, we still seem to be getting occasional `rndc`
crashes on OpenBSD:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1191900
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1181144
- https://gitlab.isc.o...Even with !4089 merged, we still seem to be getting occasional `rndc`
crashes on OpenBSD:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1191900
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1181144
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1179956
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1176830
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1176824
While backtrace collection in GitLab CI is broken for OpenBSD[^1], the
core dumps themselves seem to be usable once you load them into GDB with
the right executables.
Here are some bits I personally found important:
```
(gdb) bt
#0 0x000005ee0feb049f in uv_handle_get_data () from /usr/local/lib/libuv.so.2.1
#1 0x000005ee6570b50e in tcp_connect_cb (uvreq=0x5edcf49e378, status=-48) at netmgr/tcp.c:156
#2 0x000005ee6570b408 in isc__nm_async_tcpconnect (ev0=Variable "ev0" is not available.
) at netmgr/tcp.c:136
#3 0x000005ee6570abbe in process_queue (worker=0x5edec985000, queue=0x5edec986080) at netmgr/netmgr.c:618
#4 0x000005ee0feb4548 in uv__async_io () from /usr/local/lib/libuv.so.2.1
#5 0x000005ee0fec59dc in uv__io_poll () from /usr/local/lib/libuv.so.2.1
#6 0x000005ee0feb4be0 in uv_run () from /usr/local/lib/libuv.so.2.1
#7 0x000005ee657077aa in nm_thread (worker0=0x5edec985000) at netmgr/netmgr.c:488
...
(gdb) frame 1
#1 0x000005ee6570b50e in tcp_connect_cb (uvreq=0x5edcf49e378, status=-48) at netmgr/tcp.c:156
156 sock = uv_handle_get_data((uv_handle_t *)uvreq->handle);
(gdb) print uvreq
$3 = (uv_connect_t *) 0x5edcf49e378
(gdb) print uvreq->handle
$4 = (uv_stream_t *) 0x0
```
Output of `thread apply all bt full` [attached][1] anyway.
[^1]: That is because source binary identification in GDB on OpenBSD
works differently than on all other systems and I see no obvious
way to make it work.
[1]: /uploads/0975475e2fc45e65d7c6b0a9d3c0bb8c/thread-apply-all-bt-full.txtDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1442investigate result of GTEST_SHUFFLE2020-11-18T12:42:03ZWlodzimierz Wencelinvestigate result of GTEST_SHUFFLEFix failing tests using seeds generated in the run:
https://jenkins.isc.org/job/kea-dev/job/ut-basic/52
* seed on fedora: 92727
* seed on debian: 24338
* seed on ubuntu: 11764
* seed on centos: 91424
to run tests with those seeds it's...Fix failing tests using seeds generated in the run:
https://jenkins.isc.org/job/kea-dev/job/ut-basic/52
* seed on fedora: 92727
* seed on debian: 24338
* seed on ubuntu: 11764
* seed on centos: 91424
to run tests with those seeds it's needed to have env variables `GTEST_SHUFFLE=1` and `GTEST_SHUFFLE_SEED` with SEED replaced by int.
This exercise is aimed to check if fixing those tests will resolve in fixing kea core code or just tests, if it will be just test code we will not enable GTEST_SHUFFLE in buildfarm.kea1.9.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1441RADIUS hook tweaks for Cisco hardware: optional different formatting of a par...2021-05-04T14:32:10ZTomek MrugalskiRADIUS hook tweaks for Cisco hardware: optional different formatting of a parameterThere's a [support#16875](https://support.isc.org/Ticket/Display.html?id=16875), asking for solution to the RADIUS problem with non-standard formatting for a parameter. In this deployment, a Cisco hardware is used as RADIUS server.
The ...There's a [support#16875](https://support.isc.org/Ticket/Display.html?id=16875), asking for solution to the RADIUS problem with non-standard formatting for a parameter. In this deployment, a Cisco hardware is used as RADIUS server.
The implementation expects the radius attribute conveying the MAC address to use a non-standard 0000.0000.0000, rather than the typical 00:00:00:00:00:00.
I haven't looked at the implementation, but it seems reasonable to provide an optional formatting knob that, when enabled, will use this alternative formatting. The default should remain as it is now.kea1.9.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2193TSAN errors in v9_16 to be investigated.2020-10-02T01:43:18ZMark AndrewsTSAN errors in v9_16 to be investigated.Job [#1192145](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1192145) failed for fc3cab22a44cff8458cf39865836c7e5d883cbed:
```
I:System test result summary:
I: 2 FAIL
I: 94 PASS
I: 3 SKIPPED
I:The following system tests...Job [#1192145](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1192145) failed for fc3cab22a44cff8458cf39865836c7e5d883cbed:
```
I:System test result summary:
I: 2 FAIL
I: 94 PASS
I: 3 SKIPPED
I:The following system tests failed:
I: nsupdate
I: tcp
I:ThreadSanitizer reported issues for the following system tests:
I: tcp
```
Races over access to `sock->rcb.recv` and `sock->rcbarg`. `sock->rcbarg` in this case.
`sock->rcbarg` is set to NULL before calling `isc_nm_stoplistening`. Additionally we
need to wait for isc_nm_stoplistening to be processed when it is sent via the event
queue.
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1:
#0 processbuffer lib/isc/netmgr/tcpdns.c:185:15
#1 resume_processing lib/isc/netmgr/tcpdns.c:421:12
#2 isc_nmhandle_unref lib/isc/netmgr/netmgr.c:1173:4
#3 isc__nm_uvreq_put lib/isc/netmgr/netmgr.c:1288:3
#4 tcpdnssend_cb lib/isc/netmgr/tcpdns.c:449:2
#5 tcp_send_cb lib/isc/netmgr/tcp.c:892:2
#6 <null> <null>
Previous write of size 8 at 0x000000000001 by thread T2 (mutexes: write M1):
#0 memset <null>
#1 isc__nm_tcpdns_stoplistening lib/isc/netmgr/tcpdns.c:330:15
#2 isc_nm_stoplistening lib/isc/netmgr/netmgr.c:1358:3
#3 ns_interface_shutdown lib/ns/interfacemgr.c:564:3
#4 purge_old_interfaces lib/ns/interfacemgr.c:658:4
#5 ns_interfacemgr_shutdown lib/ns/interfacemgr.c:386:2
#6 shutdown_server bin/named/./server.c:9851:2
#7 dispatch lib/isc/task.c:1152:7
#8 run lib/isc/task.c:1344:2
```November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/kea/-/issues/1440wrap lines in ChangeLog to 732020-10-02T08:53:38ZMichal Nowikowskiwrap lines in ChangeLog to 73This is needed to make email with announcement look ok.This is needed to make email with announcement look ok.kea1.9.1https://gitlab.isc.org/isc-projects/bind9/-/issues/2192TSAN error accessing listener->connections2020-10-02T08:48:36ZMark AndrewsTSAN error accessing listener->connectionsJob [#1191892](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1191892) failed for cdd9852447067a0ec4841ff3ffbd326ad03bb5a7:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 conn_reset b...Job [#1191892](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1191892) failed for cdd9852447067a0ec4841ff3ffbd326ad03bb5a7:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 conn_reset bin/named/controlconf.c:574
#1 isc_nmhandle_detach netmgr/netmgr.c:1257
#2 isc__nm_uvreq_put netmgr/netmgr.c:1389
#3 tcp_send_cb netmgr/tcp.c:1030
#4 <null> <null>
#5 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2:
#0 conn_reset bin/named/controlconf.c:574
#1 isc_nmhandle_detach netmgr/netmgr.c:1257
#2 control_recvmessage bin/named/controlconf.c:556
#3 recv_data lib/isccc/ccmsg.c:110
#4 isc__nm_tcp_shutdown netmgr/tcp.c:1161
#5 shutdown_walk_cb netmgr/netmgr.c:1511
#6 uv_walk <null>
#7 process_queue netmgr/netmgr.c:656
#8 process_normal_queue netmgr/netmgr.c:582
#9 process_queues netmgr/netmgr.c:590
#10 async_cb netmgr/netmgr.c:548
#11 <null> <null>
#12 <null> <null>
Location is heap block of size 265 at 0x000000000017 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713
#2 mem_get lib/isc/mem.c:622
#3 isc___mem_get lib/isc/mem.c:1044
#4 isc__mem_get lib/isc/mem.c:2432
#5 add_listener bin/named/controlconf.c:1127
#6 named_controls_configure bin/named/controlconf.c:1324
#7 load_configuration bin/named/server.c:9181
#8 run_server bin/named/server.c:9819
#9 dispatch lib/isc/task.c:1152
#10 run lib/isc/task.c:1344
#11 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:232
#3 create_managers bin/named/main.c:909
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:232
#3 create_managers bin/named/main.c:909
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
SUMMARY: ThreadSanitizer: data race bin/named/controlconf.c:574 in conn_reset
```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/bind9/-/issues/2191Missing locks when accessing keynode.initial and keynode.managed triggered TSAN.2020-10-02T08:49:12ZMark AndrewsMissing locks when accessing keynode.initial and keynode.managed triggered TSAN.Job [#1190729](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1190729) failed for 96d2ec16a29c73050f8ad7a97930093294ba9ac7:
```
WARNING: ThreadSanitizer: data race
Write of size 1 at 0x000000000001 by thread T1 (mutexes: write M1):...Job [#1190729](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1190729) failed for 96d2ec16a29c73050f8ad7a97930093294ba9ac7:
```
WARNING: ThreadSanitizer: data race
Write of size 1 at 0x000000000001 by thread T1 (mutexes: write M1):
#0 dns_keynode_trust lib/dns/keytable.c:836
#1 keyfetch_done lib/dns/zone.c:10187
#2 dispatch lib/isc/task.c:1152
#3 run lib/isc/task.c:1344
#4 <null> <null>
Previous read of size 1 at 0x000000000001 by thread T2 (mutexes: read M2):
#0 keynode_dslist_totext lib/dns/keytable.c:682
#1 dns_keytable_totext lib/dns/keytable.c:732
#2 named_server_dumpsecroots bin/named/server.c:11357
#3 named_control_docommand bin/named/control.c:264
#4 control_command bin/named/controlconf.c:390
#5 dispatch lib/isc/task.c:1152
#6 run lib/isc/task.c:1344
#7 <null> <null>
Location is heap block of size 241 at 0x000000000010 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713
#2 mem_get lib/isc/mem.c:622
#3 mem_allocateunlocked lib/isc/mem.c:1268
#4 isc___mem_allocate lib/isc/mem.c:1288
#5 isc__mem_allocate lib/isc/mem.c:2453
#6 isc___mem_get lib/isc/mem.c:1037
#7 isc__mem_get lib/isc/mem.c:2432
#8 new_keynode lib/dns/keytable.c:346
#9 insert lib/dns/keytable.c:393
#10 dns_keytable_add lib/dns/keytable.c:421
#11 process_key bin/named/server.c:955
#12 load_view_keys bin/named/server.c:983
#13 configure_view_dnsseckeys bin/named/server.c:1140
#14 configure_view bin/named/server.c:5371
#15 load_configuration bin/named/server.c:9110
#16 loadconfig bin/named/server.c:10310
#17 named_server_reconfigcommand bin/named/server.c:10693
#18 named_control_docommand bin/named/control.c:250
#19 control_command bin/named/controlconf.c:390
#20 dispatch lib/isc/task.c:1152
#21 run lib/isc/task.c:1344
#22 <null> <null>
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
SUMMARY: ThreadSanitizer: data race lib/dns/keytable.c:836 in dns_keynode_trust
```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/1439Sanity checks for Kea 1.9.0 rc12020-10-02T12:03:54ZjenkinsSanity checks for Kea 1.9.0 rc1```We are now at step SANITY CHECKS of Kea 1.9.0 rc1.
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. ple...```We are now at step SANITY CHECKS of Kea 1.9.0 rc1.
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. please, state in Sanity Checks issue in GitLab
what check you are doing in a thread/discussion (not as comment).
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/1.9.0-rc1
/data/shared/sweng/kea/releases/premium-1.9.0-rc1
/data/shared/sweng/kea/releases/subscription-1.9.0-rc1
SHA256 (kea-1.9.0.tar.gz) = 054e66b9cd987a43d2745abd7c850d4ffb532e611da1c8b13f23ccbb4a71f8e0)
SHA256 (kea-premium-1.9.0.tar.gz) = f4b5e36a5936727e15c1566d6a2f08d3d9c1b5eb8a8a3c0e348f9b280b5dc397)
SHA256 (kea-subscription-1.9.0.tar.gz) = 535a4177d9c227efa7c7b0f3af759fff7947ae6499885fcd9ec72e62656aeb3f)
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.isc.org/job/kea-dev/job/pkg/64/
Release version is 1.9.0-isc0003520200928143245 (please verify if it is this version while installing).
Install instruction is here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, chapter 4. Sanity Checks, point 9.
```https://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 Becheriu