ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-08-25T14:56:05Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2010Sanity checks for Kea 1.9.10 rc32021-08-25T14:56:05ZjenkinsSanity checks for Kea 1.9.10 rc3```We are now at step SANITY CHECKS of Kea 1.9.10 rc3.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Be...```We are now at step SANITY CHECKS of Kea 1.9.10 rc3.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Before starting any checks, please state what check you are doing in a
thread/discussion (not as comment) in Sanity Checks issue in GitLab:
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.10-rc3
/data/shared/sweng/kea/releases/premium-1.9.10-rc3
/data/shared/sweng/kea/releases/subscription-1.9.10-rc3
SHA256 (kea-1.9.10.tar.gz) = c3db991c6969ab06ff5c0fc2948de3a1d0293d5e1f6d7280cb551eb41516f922
SHA256 (kea-premium-1.9.10.tar.gz) = fcf51137a30ce953ed209093f55a763603c359d4bcb7f8722595de777df50a37
SHA256 (kea-subscription-1.9.10.tar.gz) = dd1339646a752a31d8e593dbe7c5ebefa82b08ea85b951aedc4776d13b2ee41e
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/460/
Release version is 1.9.10-r20210730172914 (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.
```kea1.9.10https://gitlab.isc.org/isc-projects/kea/-/issues/2012MacOS does not use @prefix@ for python scripts2021-08-25T14:55:40ZRazvan BecheriuMacOS does not use @prefix@ for python scriptsfound during sanity checks for 1.9.10
#2010
fix is simple (thx @andrei):
```
diff --git a/src/bin/shell/Makefile.am b/src/bin/shell/Makefile.am
index 786d4f676a..430116988a 100644
--- a/src/bin/shell/Makefile.am
+++ b/src/bin/shell/Ma...found during sanity checks for 1.9.10
#2010
fix is simple (thx @andrei):
```
diff --git a/src/bin/shell/Makefile.am b/src/bin/shell/Makefile.am
index 786d4f676a..430116988a 100644
--- a/src/bin/shell/Makefile.am
+++ b/src/bin/shell/Makefile.am
@@ -1,5 +1,8 @@
SUBDIRS = . tests
+PYTHON_PREFIX=@prefix@
+PYTHON_EXEC_PREFIX=@prefix@
+
pkgpython_PYTHON = kea_conn.py kea_connector2.py kea_connector3.py
sbin_SCRIPTS = kea-shell
```
not sure if this interferes with:
--with-site-packageskea1.9.11Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2875DoH code relies on HTTP headers processing order2021-08-25T08:02:29ZArtem BoldarievDoH code relies on HTTP headers processing orderDoH code makes assumptions regarding the HTTP (pseudo)header processing order. In particular, it assumes that `:method:` pseudo-header will be processed one of the first, which might not be true. In this case, the request will be treated...DoH code makes assumptions regarding the HTTP (pseudo)header processing order. In particular, it assumes that `:method:` pseudo-header will be processed one of the first, which might not be true. In this case, the request will be treated as a bad one.
The problem was found when testing the DoH code with `h2load`, an `HTTP/2` and `HTTP 1.1` benchmarking tool being developed by `libnghttp2` authors. The problem revealed itself only when testing `POST` requests (`GET` requests were fine).
```
h2load -t 8 -c 300 -m 100 -n 1000000 -d ~/projects/isc/request_data.bin -H "content-type:application/dns-message" https://doh.example.com/dns-query
```
In order to resolve the problem we need to move the checks which require certain headers to be processed first into `server_on_request_recv()`, which knows all the required context.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/kea/-/issues/1978Document in the Kea ARM that Kea and database timezones must match2021-08-25T05:32:16ZMarcin SiodelskiDocument in the Kea ARM that Kea and database timezones must matchThere was a user issue described in the https://gitlab.isc.org/isc-projects/kea/-/issues/1968 which caused the Kea servers to refuse renewing leases when Kea server used a different timezone setting than the database timezone setting. I ...There was a user issue described in the https://gitlab.isc.org/isc-projects/kea/-/issues/1968 which caused the Kea servers to refuse renewing leases when Kea server used a different timezone setting than the database timezone setting. I skimmed through our documentation and found no indication that they must match. I propose that we better document in the Kea ARM that the timezone settings between Kea and database must not differ. I also propose that we add some examples how it can be verified for different databases. This is purely a documentation change.kea1.9.11Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2842Clean up catalog journal2021-08-25T05:18:13ZMark AndrewsClean up catalog journalFrom bind-users
```
Hi
Using BIND-9.16.19: When removing a member zone from a catz (catalog zone), then the journal files are not removed on the slave:
Current situation before removing the zone "example.com" from catz:
$ ls -lahF
-r...From bind-users
```
Hi
Using BIND-9.16.19: When removing a member zone from a catz (catalog zone), then the journal files are not removed on the slave:
Current situation before removing the zone "example.com" from catz:
$ ls -lahF
-rw-r--r--. 1 named named 4.0K 28. Jul 15:21 __catz___default_catalog.123456.local_example.com.db
-rw-r--r--. 1 named named 1.2K 28. Jul 15:26 __catz___default_catalog.123456.local_example.com.db.jnl
After removing the zone on the master (catz), the slave removes the __catz___default_...-files for the corresponding zone, but not the journal-file:
28-Jul-2021 15:29:56.018 general: info: catz: updating catalog zone 'catalog.123456.local' with serial 2021072803
28-Jul-2021 15:29:56.018 xfer-in: info: zone catalog.123456.local/IN: transferred serial 2021072803: TSIG 'master-slave'
28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123456.local/IN' from 172.16.1.1#53: Transfer status: success
28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123546.local/IN' from 172.16.1.1#53: Transfer completed: 1 messages, 5 records, 343 bytes, 0.001 secs (343000 bytes/sec) (serial 2021072803)
28-Jul-2021 15:29:56.020 general: info: catz: deleting zone 'example.com' from catalog 'catalog.123456.local' - success
28-Jul-2021 15:29:56.021 general: warning: catz: catz_delzone_taskaction: zone 'example.com' deleted
$ ls -lahF
-rw-r--r--. 1 named named 1.2K 28. Jul 15:26 __catz___default_catalog.123456.local_example.com.db.jnl
Is this intentional or possibly a bug?
Many thanks.
Kind regards,
Tom
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1982Access to CB after temporary loss of connection to database2021-08-24T15:01:09ZPeter DaviesAccess to CB after temporary loss of connection to databaseAccess to CB after temporary loss of connection to database
After loss of connection to mysql based Configuration Backend and subsequent recovery periodic CB updates and remote* commands to fail.
[RT #18098](https://support.isc.org/T...Access to CB after temporary loss of connection to database
After loss of connection to mysql based Configuration Backend and subsequent recovery periodic CB updates and remote* commands to fail.
[RT #18098](https://support.isc.org/Ticket/Display.html?id=18098)kea1.9.11Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1980Does not build with Boost 1.77 beta12021-08-24T14:58:50ZBrad SmithDoes not build with Boost 1.77 beta1Build testing the OpenBSD ports tree with Boost 1.77. Kea 1.8.2 does not build with Boost 1.77 beta1 as shown..
```
c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DDHCP_DATA_DIR="/var/lib/kea" -DTOP_BUILDDIR="...Build testing the OpenBSD ports tree with Boost 1.77. Kea 1.8.2 does not build with Boost 1.77 beta1 as shown..
```
c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DDHCP_DATA_DIR="/var/lib/kea" -DTOP_BUILDDIR="../../.." -DKEA_LFC_EXECUTABLE="/usr/local/sbin/kea-lfc" -isystem /usr/local/include -I/usr/local/include/mysql -I/usr/local/include/mysql/mysql -DOS_BSD -Qunused-arguments -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -Wno-unused-variable -Wno-unused-parameter -fPIC -O2 -pipe -MT libkea_dhcpsrv_la-timer_mgr.lo -MD -MP -MF .deps/libkea_dhcpsrv_la-timer_mgr.Tpo -c timer_mgr.cc -fPIC -DPIC -o .libs/libkea_dhcpsrv_la-timer_mgr.o
timer_mgr.cc:68:14: error: no template named 'map' in namespace 'std'; did you mean 'max'?
typedef std::map<std::string, TimerInfoPtr> TimerInfoMap;
~~~~~^~~
max
/usr/include/c++/v1/algorithm:2624:1: note: 'max' declared here
max(const _Tp& __a, const _Tp& __b, _Compare __comp)
^
timer_mgr.cc:68:14: error: C++ requires a type specifier for all declarations
typedef std::map<std::string, TimerInfoPtr> TimerInfoMap;
~~~~~~~ ^
timer_mgr.cc:68:14: error: typedef declarator cannot be qualified
typedef std::map<std::string, TimerInfoPtr> TimerInfoMap;
~~~~~^
timer_mgr.cc:68:14: error: typedef name must be an identifier
typedef std::map<std::string, TimerInfoPtr> TimerInfoMap;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
timer_mgr.cc:68:44: error: expected ';' after top level declarator
typedef std::map<std::string, TimerInfoPtr> TimerInfoMap;
^
;
timer_mgr.cc:160:5: error: unknown type name 'TimerInfoMap'
TimerInfoMap registered_timers_;
^
timer_mgr.cc:207:5: error: use of undeclared identifier 'TimerInfoMap'
TimerInfoMap::iterator timer_info_it = registered_timers_.find(timer_name);
^
timer_mgr.cc:233:5: error: unknown type name 'TimerInfoMap'
TimerInfoMap registered_timers_copy(registered_timers_);
^
timer_mgr.cc:236:10: error: use of undeclared identifier 'TimerInfoMap'
for (TimerInfoMap::iterator timer_info_it = registered_timers_copy.begin();
^
timer_mgr.cc:256:4: error: use of undeclared identifier 'TimerInfoMap'
TimerInfoMap::const_iterator timer_info_it = registered_timers_.find(timer_name);
^
timer_mgr.cc:275:5: error: use of undeclared identifier 'TimerInfoMap'
TimerInfoMap::const_iterator timer_info_it = registered_timers_.find(timer_name);
^
timer_mgr.cc:287:5: error: use of undeclared identifier 'TimerInfoMap'
TimerInfoMap::iterator timer_info_it = registered_timers_.find(timer_name);
^
timer_mgr.cc:160:18: warning: private field 'registered_timers_' is not used [-Wunused-private-field]
TimerInfoMap registered_timers_;
^
1 warning and 12 errors generated.
```kea1.9.11Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2031build fails with boost-1.77.02021-08-24T14:58:48ZLars Wendlerbuild fails with boost-1.77.0```
/bin/sh ../../../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DDHCP_DATA_DIR="\"/var/lib/kea\"" -DTOP_BUILDDIR="\"../../..\"" -DKEA_LFC_EXECUTABLE=...```
/bin/sh ../../../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DDHCP_DATA_DIR="\"/var/lib/kea\"" -DTOP_BUILDDIR="\"../../..\"" -DKEA_LFC_EXECUTABLE="\"/
usr/sbin/kea-lfc\"" -DOS_LINUX -I../../.. -I../../.. -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC -march=native -mtune=native -O2 -pipe -c -o libkea_dhcpsrv_la-timer_mgr.lo `test -f 'timer_mgr.cc' || echo './'`timer_mgr.cc
libtool: compile: x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -DDHCP_DATA_DIR=\"/var/lib/kea\" -DTOP_BUILDDIR=\"../../..\" -DKEA_LFC_EXECUTABLE=\"/usr/sbin/kea-lfc\" -DOS_LINUX -I../../.. -I../../.. -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC -march=native -mtune=native -O2 -pipe -c timer_mgr.cc -fPIC -DPIC -o .libs/libkea_dhcpsrv_la-timer_mgr.o
timer_mgr.cc:72:14: error: ‘map’ in namespace ‘std’ does not name a template type
72 | typedef std::map<std::string, TimerInfoPtr> TimerInfoMap;
| ^~~
timer_mgr.cc:16:1: note: ‘std::map’ is defined in header ‘<map>’; did you forget to ‘#include <map>’?
15 | #include <boost/scoped_ptr.hpp>
+++ |+#include <map>
16 |
timer_mgr.cc:220:5: error: ‘TimerInfoMap’ does not name a type; did you mean ‘TimerInfoPtr’?
220 | TimerInfoMap registered_timers_;
| ^~~~~~~~~~~~
| TimerInfoPtr
timer_mgr.cc: In constructor ‘isc::dhcp::TimerMgrImpl::TimerMgrImpl()’:
timer_mgr.cc:227:5: error: class ‘isc::dhcp::TimerMgrImpl’ does not have any field named ‘registered_timers_’
227 | registered_timers_(), mutex_(new std::mutex) {
| ^~~~~~~~~~~~~~~~~~
timer_mgr.cc: In member function ‘void isc::dhcp::TimerMgrImpl::registerTimerInternal(const string&, const Callback&, long int, const isc::asiolink::IntervalTimer::Mode&)’:
timer_mgr.cc:263:9: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
263 | if (registered_timers_.find(timer_name) != registered_timers_.end()) {
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc:275:5: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
275 | registered_timers_.insert(std::pair<std::string, TimerInfoPtr>(timer_name,
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc: In member function ‘void isc::dhcp::TimerMgrImpl::unregisterTimerInternal(const string&)’:
timer_mgr.cc:292:5: error: ‘TimerInfoMap’ has not been declared
292 | TimerInfoMap::iterator timer_info_it = registered_timers_.find(timer_name);
| ^~~~~~~~~~~~
timer_mgr.cc:295:9: error: ‘timer_info_it’ was not declared in this scope
295 | if (timer_info_it == registered_timers_.end()) {
| ^~~~~~~~~~~~~
timer_mgr.cc:295:26: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
295 | if (timer_info_it == registered_timers_.end()) {
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc:304:5: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
304 | registered_timers_.erase(timer_info_it);
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc:304:30: error: ‘timer_info_it’ was not declared in this scope
304 | registered_timers_.erase(timer_info_it);
| ^~~~~~~~~~~~~
timer_mgr.cc: In member function ‘void isc::dhcp::TimerMgrImpl::unregisterTimersInternal()’:
timer_mgr.cc:328:5: error: ‘TimerInfoMap’ was not declared in this scope; did you mean ‘TimerInfoPtr’?
328 | TimerInfoMap registered_timers_copy(registered_timers_);
| ^~~~~~~~~~~~
| TimerInfoPtr
timer_mgr.cc:331:10: error: ‘TimerInfoMap’ is not a class, namespace, or enumeration
331 | for (TimerInfoMap::iterator timer_info_it = registered_timers_copy.begin();
| ^~~~~~~~~~~~
timer_mgr.cc:332:10: error: ‘timer_info_it’ was not declared in this scope
332 | timer_info_it != registered_timers_copy.end(); ++timer_info_it) {
| ^~~~~~~~~~~~~
timer_mgr.cc:332:27: error: ‘registered_timers_copy’ was not declared in this scope
332 | timer_info_it != registered_timers_copy.end(); ++timer_info_it) {
| ^~~~~~~~~~~~~~~~~~~~~~
timer_mgr.cc: In member function ‘bool isc::dhcp::TimerMgrImpl::isTimerRegistered(const string&)’:
timer_mgr.cc:341:17: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
341 | return (registered_timers_.find(timer_name) != registered_timers_.end());
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc:343:17: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
343 | return (registered_timers_.find(timer_name) != registered_timers_.end());
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc: In member function ‘size_t isc::dhcp::TimerMgrImpl::timersCount() const’:
timer_mgr.cc:351:17: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
351 | return (registered_timers_.size());
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc:353:17: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
353 | return (registered_timers_.size());
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc: In member function ‘void isc::dhcp::TimerMgrImpl::setupInternal(const string&)’:
timer_mgr.cc:370:4: error: ‘TimerInfoMap’ has not been declared
370 | TimerInfoMap::const_iterator timer_info_it = registered_timers_.find(timer_name);
| ^~~~~~~~~~~~
timer_mgr.cc:371:8: error: ‘timer_info_it’ was not declared in this scope
371 | if (timer_info_it == registered_timers_.end()) {
| ^~~~~~~~~~~~~
timer_mgr.cc:371:25: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
371 | if (timer_info_it == registered_timers_.end()) {
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc:378:37: error: ‘timer_info_it’ was not declared in this scope; did you mean ‘timer_info’?
378 | const TimerInfoPtr& timer_info = timer_info_it->second;
| ^~~~~~~~~~~~~
| timer_info
timer_mgr.cc: In member function ‘void isc::dhcp::TimerMgrImpl::cancelInternal(const string&)’:
timer_mgr.cc:398:5: error: ‘TimerInfoMap’ has not been declared
398 | TimerInfoMap::const_iterator timer_info_it = registered_timers_.find(timer_name);
| ^~~~~~~~~~~~
timer_mgr.cc:399:9: error: ‘timer_info_it’ was not declared in this scope
399 | if (timer_info_it == registered_timers_.end()) {
| ^~~~~~~~~~~~~
timer_mgr.cc:399:26: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
399 | if (timer_info_it == registered_timers_.end()) {
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc:404:5: error: ‘timer_info_it’ was not declared in this scope
404 | timer_info_it->second->interval_timer_.cancel();
| ^~~~~~~~~~~~~
timer_mgr.cc: In member function ‘void isc::dhcp::TimerMgrImpl::timerCallback(const string&)’:
timer_mgr.cc:410:5: error: ‘TimerInfoMap’ has not been declared
410 | TimerInfoMap::iterator timer_info_it = registered_timers_.find(timer_name);
| ^~~~~~~~~~~~
timer_mgr.cc:411:9: error: ‘timer_info_it’ was not declared in this scope
411 | if (timer_info_it != registered_timers_.end()) {
| ^~~~~~~~~~~~~
timer_mgr.cc:411:26: error: ‘registered_timers_’ was not declared in this scope; did you mean ‘registerTimer’?
411 | if (timer_info_it != registered_timers_.end()) {
| ^~~~~~~~~~~~~~~~~~
| registerTimer
timer_mgr.cc:408:48: warning: unused parameter ‘timer_name’ [-Wunused-parameter]
408 | TimerMgrImpl::timerCallback(const std::string& timer_name) {
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
make[5]: *** [Makefile:1641: libkea_dhcpsrv_la-timer_mgr.lo] Error 1
```
And indeed, the fix gcc suggests works:
```
--- kea-1.9.10/src/lib/dhcpsrv/timer_mgr.cc
+++ kea-1.9.10/src/lib/dhcpsrv/timer_mgr.cc
@@ -13,6 +13,7 @@
#include <util/multi_threading_mgr.h>
#include <boost/scoped_ptr.hpp>
+#include <map>
#include <functional>
#include <utility>
```kea1.9.11https://gitlab.isc.org/isc-projects/dhcp/-/issues/88Bug in dhcpd with ipv6 and network interface aliases2021-08-24T14:28:14ZGhost UserBug in dhcpd with ipv6 and network interface aliases
Hi
We have detected a problem when using dhcpdv6 when there are messages received from an IPv6 interface (eth0) which has an interface alias (eth0:0) [1]. dhcpd tries to answer using the alias and fails with a bad file descriptor bec...
Hi
We have detected a problem when using dhcpdv6 when there are messages received from an IPv6 interface (eth0) which has an interface alias (eth0:0) [1]. dhcpd tries to answer using the alias and fails with a bad file descriptor because eth0 and eth0:0 have the same interface index, so the following patch ignores interfaces with invalid write file descriptors.
Cheers
Alejandro.
[1]
```
# ifconfig
eth0 Link encap:Ethernet HWaddr A
inet addr:B Bcast:C Mask:255.255.255.0
inet6 addr: D/64 Scope:Global
inet6 addr: D/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7182898 errors:0 dropped:22 overruns:0 frame:0
TX packets:4863373 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3551746525 (3.5 GB) TX bytes:4883184122 (4.8 GB)
eth0:0 Link encap:Ethernet HWaddr A
inet addr:E Bcast:F Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
```
**To Reproduce**
1. Run dhcpd with a ip pool in eth0 in ipv6 and a interface alias eth0:0
```
/usr/sbin/dhcpd -d -6 -user dhcpd -group dhcpd -cf /etc/dhcp/dhcpd6.conf --no-pid
```
2. A client does a IPv6 request and doesn't gets an answer.
3. The server doesn't answer.
4. See error
```
Sending Relay-reply to XX::XX port 547
send_packet6: Bad file descriptor
dhcpv6: send_packet6() sent -1 of 239 bytes
```
**Expected behavior**
The server is supposed to send back packet A with address B assigned.
**Environment:**
- ISC DHCP version: isc-dhcpd-4.4.1
- OS: Debian buster
**Additional Information**
gdb shows that ```if_nametoindex(ip->name)``` is equal for eth0 and eth0:0. But eth0:0 does not have a valid file descriptor.
[patch.patch](/uploads/b4773b08980a36cfc4d7a40a3d0b23d5/patch.patch)4.5.0-betahttps://gitlab.isc.org/isc-projects/kea/-/issues/1944add "store-extended-info" in the yang-model for netconf.2021-08-23T14:00:58ZPeter Daviesadd "store-extended-info" in the yang-model for netconf.config-get returns "store-extended-info": false
I would maybe be helpful to add "store-extended-info" in the yang-model for netconf.
And perhaps some newer unsupported keywords.
[RT #18709](https://support.isc.org/Ticket/Display...config-get returns "store-extended-info": false
I would maybe be helpful to add "store-extended-info" in the yang-model for netconf.
And perhaps some newer unsupported keywords.
[RT #18709](https://support.isc.org/Ticket/Display.html?id=18709 )kea1.9.11Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2735BIND 9.16, must stop named, delete .jnl files for signed zones to be updated2021-08-22T08:15:10ZHakan GustafssonBIND 9.16, must stop named, delete .jnl files for signed zones to be updated<!--
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
For a signed zone to be updated I have to stop named, delete all the "." files, update the serial number and then start named again. If I do a normal update, just update the serial number and then run "rndc reload", I got this error message "29-May-2021 13:54:52.008 general: error: zone ******.se/IN (signed): receive_secure_serial: unchanged", and the zone don't update. I have had this issue in previous versions also, now I run 9.16.16.
### BIND version used
```
BIND 9.16.16 (Stable Release) <id:0c314d8>
running on Linux x86_64 4.18.0-305.el8.x86_64 #1 SMP Thu Apr 29 08:54:30 EDT 2021
built by make with '--prefix=/service/dns/bind-9.16.16' '--sysconfdir=/data/dns/named' '--localstatedir=/var' '--with-openssl=/service/dns/openssl' 'LDFLAGS=-ldl'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.23.1
linked to libuv version: 1.23.1
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /data/dns/named/named.conf
rndc configuration: /data/dns/named/rndc.conf
DNSSEC root key: /data/dns/named/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
Update the serial number for signed zone och then do a "rndc reload"
### What is the current *bug* behavior?
The zone doesn't update
### What is the expected *correct* behavior?
The zone should be updated after I have changed the serial number
### Relevant configuration files
I use a manually policy for signed zones, "dnssec-policy modified;"
```
dnssec-policy "modified" {
keys {
csk lifetime unlimited algorithm rsasha256 2048;
};
};
```
### Relevant logs and/or screenshots
"29-May-2021 13:54:52.008 general: error: zone ******.se/IN (signed): receive_secure_serial: unchanged"
### Possible fixes
The workaround is to stop named, delete all "." files (.jbk, .jnl, .signed, .signed.jnl), update the serial number, start named again.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1386DDNS update-conflict-detection2021-08-21T02:53:09ZShawn RouthierDDNS update-conflict-detectionThe second of the DDNS features from DHCPD
In DHCPD there is an option update-conflict-detection that allows the administrator to specify
if the DDNS process should do conflict detection or simply overwrite any current information.
Thi...The second of the DDNS features from DHCPD
In DHCPD there is an option update-conflict-detection that allows the administrator to specify
if the DDNS process should do conflict detection or simply overwrite any current information.
This can be useful in cases where a client is being replaced such that the name remains the same
but a different identifier is used. For example if a client is moving from a wireless to a wired
network such that the client id or hardware address change.
It does have the drawback of eliminating the safety of the conflict detection and so should be
off by default and used with care by the administrators. It may need to be done on a per network,
range or host basis.
I have split the work into two MRs:
!965:
1. Adds a new parameter, use-conflict-resolution, to NameChangeRequest messages
2. Modify D2 to support adding and removing DNS entries without employing conflict resolution
A subsequent MR will add a new configuration parameter, ddns-use-conflict-resolution, to kea-dhcp4/kea-dhcp6.kea1.9.1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1385DDNS update-optimization2021-08-21T02:53:09ZShawn RouthierDDNS update-optimizationThis is one of several tickets to add some of the features for DDNS support from DHCPD to Kea.
In DHCPD there is an option "update-optimization" that allows the administrator to configure
if a DDNS update is attempted only when a client...This is one of several tickets to add some of the features for DDNS support from DHCPD to Kea.
In DHCPD there is an option "update-optimization" that allows the administrator to configure
if a DDNS update is attempted only when a client seems to have changed or on every renewal.
This feature would allow a Kea server to "heal" the DNS if some of the DNS information had
become inconsistent. Specifically it would address the case where an entry has been removed
from the DNS without Kea becoming aware of it.kea1.9.1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1172applying lease timer values to a class2021-08-20T15:36:11ZPeter Daviesapplying lease timer values to a classCustomer request: [#RT16196](https://support.isc.org/Ticket/Display.html?id=16196)
The ability to assign lease timer values to Client Class definitions.Customer request: [#RT16196](https://support.isc.org/Ticket/Display.html?id=16196)
The ability to assign lease timer values to Client Class definitions.kea1.9.11Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/725Consistency of Element constness in Element containers2021-08-20T14:15:47ZAndrei Pavelandrei@isc.orgConsistency of Element constness in Element containers```
class ListElement : public Element {
std::vector<ElementPtr> l;
[...]
}
```
```
class MapElement : public Element {
std::map<std::string, ConstElementPtr> m;
[...]
}
```
Making these containers have the same const...```
class ListElement : public Element {
std::vector<ElementPtr> l;
[...]
}
```
```
class MapElement : public Element {
std::map<std::string, ConstElementPtr> m;
[...]
}
```
Making these containers have the same constness for the underlying type would enable less friction in:
1. Generic helper functions acting on both
2. Generic high-level use of both
04fa0d3f0b83d544044475cd51de100faf17a410 changed ListElement to hold ElementPtr instead of ConstElementPtr.
Would you consider it?outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1710Setting lease time via client classification for ipv62021-08-20T13:41:19ZPeter DaviesSetting lease time via client classification for ipv6Setting lease time via client classification for ipv6:
In order to grant the same lease time to a group of clients it would be useful to be able to adjust the lease time via the client classification mechanism. By allowing definition ...Setting lease time via client classification for ipv6:
In order to grant the same lease time to a group of clients it would be useful to be able to adjust the lease time via the client classification mechanism. By allowing definition of "valid-lifetime" parameter.
This is a follow on to GL #1635 "Setting lease time via client classification" which implemented this change for dhcpv4. To my knowledge this has as yet not been request by anyone as of yet.kea1.9.11Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2045hammer.py: NETCONF2021-08-20T09:01:40ZAndrei Pavelandrei@isc.orghammer.py: NETCONFkea1.9.11https://gitlab.isc.org/isc-projects/kea/-/issues/2018Import the GSS-API installation doc2021-08-19T20:30:02ZFrancis DupontImport the GSS-API installation docThere is an installation doc in the GSS-TSIG wiki (https://gitlab.isc.org/isc-external/kea-gss-tsig/-/wikis/Install): it should be integrated in Kea documentation (note the with-gssapi is included in the last release so this is required).There is an installation doc in the GSS-TSIG wiki (https://gitlab.isc.org/isc-external/kea-gss-tsig/-/wikis/Install): it should be integrated in Kea documentation (note the with-gssapi is included in the last release so this is required).kea1.9.11Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1860more lenient parsing of DHCPv6 option 162021-08-19T19:30:10ZAndrei Pavelandrei@isc.orgmore lenient parsing of DHCPv6 option 16kea-dhcp6 currently enforces a format of length-value pairs when parsing vendor-class-data and vendor-option-data fields of option 16 ~~and 17~~, respectively. This is not mentioned in RFC 8415, nor does it recommend against, and so the ...kea-dhcp6 currently enforces a format of length-value pairs when parsing vendor-class-data and vendor-option-data fields of option 16 ~~and 17~~, respectively. This is not mentioned in RFC 8415, nor does it recommend against, and so the decision is left to the implementer:
```
vendor-option-data Vendor options, interpreted by
vendor-specific code on the clients and
servers. A variable-length field (4 octets
less than the value in the option-len field).
```
The mentioned option-len field is the length of the entire option. That is also checked against, and that behavior is RFC-compliant and should be left as it is. Not only is it required, but it is also sufficient to determine the size of said data fields.
The suggestion is to not check against the inner length i.e. inside the data fields. There are considerations to be made whether it should be done:
* generally
* on a vendor-by-vendor basis
* with a configurable boolean setting as "support-broken-clients", "lenient-option-parsing", and so on.
See the ongoing discussion for more clues: [RT#18187](https://support.isc.org/Ticket/Display.html?id=18187)kea1.9.8Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2009check GSS-API negotiated anti-replay and mutual auth services2021-08-19T18:48:44ZFrancis Dupontcheck GSS-API negotiated anti-replay and mutual auth servicesRFC 3645 about GSS-TSIG requires in 3.1.1 page 7 that:
> The values of replay_det_state and mutual_state indicate if the
security package provides replay detection and mutual authentication,
respectively. If returned major_status ...RFC 3645 about GSS-TSIG requires in 3.1.1 page 7 that:
> The values of replay_det_state and mutual_state indicate if the
security package provides replay detection and mutual authentication,
respectively. If returned major_status is GSS_S_COMPLETE AND one or
both of these values are FALSE, the client MUST abandon this
algorithm.
This ticket will add this sanity check to the GSS-API init() method.kea1.9.11Francis DupontFrancis Dupont