ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-12-03T15:25:55Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/145DHCPD 4.4.2 5 bad IP checksums seen in 5 packets2020-12-03T15:25:55ZAndrea PostiglioneDHCPD 4.4.2 5 bad IP checksums seen in 5 packetsthis is the syslog dhcpd
```
Nov 4 20:05:32 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:05:33 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.149 to 08:00:27:8a:48:da via br0
Nov 4 20:05:46 thunderd...this is the syslog dhcpd
```
Nov 4 20:05:32 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:05:33 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.149 to 08:00:27:8a:48:da via br0
Nov 4 20:05:46 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:05:47 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.150 to 08:00:27:8a:48:da via br0
Nov 4 20:07:19 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:07:20 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.151 to 08:00:27:8a:48:da via br0
```
```
customsrescuecd ~ # dhclient -v eth0
Internet Systems Consortium DHCP Client 4.4.2 Gentoo-r2
Copyright 2004-2020 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/08:00:27:8a:48:da
Sending on LPF/eth0/08:00:27:8a:48:da
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
5 bad IP checksums seen in 5 packets
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
```
it seems that the udp packets generated by the server despite being a physical machine have the wrong checksum!
can someone help me?https://gitlab.isc.org/isc-projects/bind9/-/issues/2246Backport netmgr-related merge requests2021-08-12T09:36:56ZMichał KępieńBackport netmgr-related merge requestsThis issue contains a list of netmgr-related merge requests which should
be eventually backported to `v9_16`, but may need to wait in a queue for
a while before that happens.
**Merge requests that *must* be backported:**
- [x] ~~!378...This issue contains a list of netmgr-related merge requests which should
be eventually backported to `v9_16`, but may need to wait in a queue for
a while before that happens.
**Merge requests that *must* be backported:**
- [x] ~~!3781 Fix socket closing races.~~
- [x] !4318 (included in !4455) Resolve "Add netmgr functions to support outgoing DNS queries"
- [x] !4341 (included in !4455) Fix improper closed connection handling in tcpdns.
- [x] !4386 (included in !4455) Turn all the callback to be always asynchronous
- [x] **!4444 Refactor netmgr and add more unit tests**
- [x] !4452 (included in !4455) Avoid netievent allocations when the callbacks can be called directly
- [x] !4458 (included in !4455) Make netmgr initialize and cleanup Winsock itself
- [x] !4459 (included in !4455) Distribute queries among threads even on platforms without SO_REUSEPORT_LB
- [x] !4465 (included in !4455) Don't use stack allocated buffer for uv_write()
- [x] !4468 (included in !4455) Fix datarace when UDP/TCP connect fails and we are in nmthread
- [x] !4469 (included in !4455) Use sock->nchildren instead of mgr->nworkers when initializing NM
- [x] !4472 (included in !4455) Fix s/HAVE_REUSEPORT_LB/HAVE_SO_REUSEPORT_LB/ typo in #define
**Merge requests that *may* be backported:**
- [ ] !4115 Resolve "convert dig and friends to use the netmgr"
- [ ] !4246 use netmgr for xfrin
- [ ] !4374 address some possible shutdown races in xfrin
- [ ] !4397 Resolve ""dig" crashes when interrupted while waiting for a TCP connection"
- [ ] !4466 Configure the system-wide TCP connection timeout on OpenBSD
- [ ] !4633 Resolve "Incorrect size passed to isc_mem_put"
- [x] !4628 Improve reliability of the netmgr unit tests
- [x] !4845 netmgr: Make it possible to recover from ISC_R_TIMEDOUT (backported without the relevant changes to `dig`, `rndc`, or xfrin)
- [ ] !4898 Prevent the double xfrin_fail() call
- [x] !4930 ensure read timeouts are recoverable
- [ ] !4796 Add workaround for "nslookup segfaults for SERVFAIL"
- [x] !4918 Refactor taskmgr to run on top of netmgr
- [x] !4983 Destroy netmgr before destroying taskmgr
- [x] !4981 Add nanosleep and usleep Windows shims
- [ ] !4982 Add support for generating backtraces on Windows
- [x] !5009 Bump the netmgr quantum to 1024
- [x] !5013 initalise sock->cond
- [x] !5021 Fix the outgoing UDP socket selection on Windows
[^1]: likely made redundant by !4444September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/stork/-/issues/442deploy_demo job fails on copying agent-kea-many-subnets2020-11-04T14:47:07ZMarcin Siodelskideploy_demo job fails on copying agent-kea-many-subnetsThe deploy_demo CI job fails. See: https://gitlab.isc.org/isc-projects/stork/-/jobs/1272627The deploy_demo CI job fails. See: https://gitlab.isc.org/isc-projects/stork/-/jobs/12726270.13Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/441Sanity checks for 0.13.0 release2022-02-02T09:51:30ZMarcin SiodelskiSanity checks for 0.13.0 releasePlease do your sanity checks according to the steps below:
1. Download the tarball, verify it is sane, build it and run tests.<br>
Tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/1272748/artifacts/browse
2. Start the d...Please do your sanity checks according to the steps below:
1. Download the tarball, verify it is sane, build it and run tests.<br>
Tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/1272748/artifacts/browse
2. Start the demo with `rake docker_up` and follow the steps from: https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
3. Install server and agent locally e.g. on VMs from the binary packages:<br>
debs: https://gitlab.isc.org/isc-projects/stork/-/jobs/1272749/artifacts/browse <br>
rpms: https://gitlab.isc.org/isc-projects/stork/-/jobs/1272750/artifacts/browse0.13https://gitlab.isc.org/isc-projects/kea/-/issues/1524KEA 1.8 API config-write command not enough permissions on /etc/kea/kea-dhcp4...2021-01-26T20:29:58ZNiekKEA 1.8 API config-write command not enough permissions on /etc/kea/kea-dhcp4.conf, same permissions as in KEA 1.4---
name: Bug report
about: KEA 1.8 API config-write command not enough permissions on /etc/kea/kea-dhcp4.conf
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT REPORT IT HERE. Plea...---
name: Bug report
about: KEA 1.8 API config-write command not enough permissions on /etc/kea/kea-dhcp4.conf
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to security-office(at)isc(dot)org.
**Describe the bug**
We currently run KEA 1.4 on Ubuntu 16.04 containers within our production environment. The KEA API is used with the write-config command to push an updated config to the KEA container. In version 1.4 this works perfect.
At the moment we are rebuilding our environment on new servers. KEA is still deployed in containers with LXC, except we upgraded to Ubuntu 20.04 and KEA 1.8. KEA is installed via the Cloudsmith repositories. The kea-ctrl agent is deployed and working correctly, except for the config-write command. When this command is executed in our new environment, we receive the following message:
result text
------ ----
1 Error during write-config:Unable to open file /etc/kea/kea-dhcp4.conf for writing
This problem is solved by editing the permissions on the file so that the _public_ has _write__ permissions on the file. In the old environment we didn't had to change the file permissions to make this work.
**To Reproduce**
Steps to reproduce the behavior:
1. Make sure the kea-ctrl-agent is working correctly.
2. The default file permissions on kea-dhcp4.conf in the /etc/kea/ folder is unchanged: so -rw-r--r-- (chmod 644).
3. Execute an API call with the config-write command and argument /etc/kea/kea-dhcp4.conf.
4. The following error is thrown: Error during write-config:Unable to open file /etc/kea/kea-dhcp4.conf for writing.
5. Change the file permissions on /etc/kea/kea-dhcp4.conf to: -rw-r--rw- (chmod 646).
6. Execute an API call with the config-write command and argument /etc/kea/kea-dhcp4.conf.
7. API call is successfull.
**Expected behavior**
KEA 1.4 on Ubuntu 16.04 with the same file permissions executes the config-write API call successfull with the default file permissions (-rw-r--r-- chmod 644)
The expected behavior in KEA 1.8 on Ubuntu 20.04 was the same. But we had to change the file permissions.
**Environment:**
- Kea version: 1.8
- OS: Ubuntu 20.04 host, KEA is running in LXC Ubuntu 20.04 containers.
- HA Hooks are loaded.
**Additional Information**
The actual questions is: Do we need to change the file permissions to execute some of the API calls, where this wasn't necessary on KEA 1.4. And if this is necessary, is this documented somewhere?
**Contacting you**
Contact us be reacting to this post please.kea1.9.4Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1523Release notes: add notes for required config changes on update2020-12-11T18:12:44ZChrisRelease notes: add notes for required config changes on update**Describe the bug**
When updating from 1.6 to 1.8, the logger configuration needs to be moved/updated. Without the configuration change Kea won't start leading to potentially unclear debugging, since only a syntax error is reported.
**...**Describe the bug**
When updating from 1.6 to 1.8, the logger configuration needs to be moved/updated. Without the configuration change Kea won't start leading to potentially unclear debugging, since only a syntax error is reported.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea 1.6 dhcpv4 with logging configuration
2. Update to 1.8
3. See error
**Expected behavior**
A note in release notes informing of the required config change, detection of deprecated configuration and error message pointing it out.kea1.9.3Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/stork/-/issues/440add webui unittests for changes from !2372022-03-01T14:19:02ZMichal Nowikowskiadd webui unittests for changes from !237backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/439tests for kea statistics from #413 should be enabled2021-05-31T15:29:31ZMichal Nowikowskitests for kea statistics from #413 should be enabledCurrently there is a problem with GitLab CI and VM with LXD that runs only in IPv6. These tests and especially Kea needs IPv4.
Problem is probably connected with configuration of VM. It needs to be fixed, recreated and uploaded do regis...Currently there is a problem with GitLab CI and VM with LXD that runs only in IPv6. These tests and especially Kea needs IPv4.
Problem is probably connected with configuration of VM. It needs to be fixed, recreated and uploaded do registry.0.18Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1522update reference to rfc2845bis2020-12-04T11:51:25ZFrancis Dupontupdate reference to rfc2845bisThe reference is a bit obsolete: I propose to update it by the RFC 8945The reference is a bit obsolete: I propose to update it by the RFC 8945kea1.9.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1521remove all occurrences of delete keyword by using smart pointers2020-11-26T16:51:47ZRazvan Becheriuremove all occurrences of delete keyword by using smart pointerswe should also check for all calls to new (I know we can not always remove new by make_shared because not always the constructor is public).we should also check for all calls to new (I know we can not always remove new by make_shared because not always the constructor is public).outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1520Add debugging symbols for --enable-debug2023-09-22T13:16:24ZAndrei Pavelandrei@isc.orgAdd debugging symbols for --enable-debugHaving issues debugging like code jumping all over the place when I do a simple next command in gdb. Or "optimized values" showing up when printing variable. I propose to add debugging symbols and lower optimization level to facilitate t...Having issues debugging like code jumping all over the place when I do a simple next command in gdb. Or "optimized values" showing up when printing variable. I propose to add debugging symbols and lower optimization level to facilitate this. Like `CXXFLAGS="${CXXFLAGS} -g3 -ggdb -O0"` when `./configure --enable-debug` command is issued.kea2.5.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2245bind 9.16.8 does not honor CPU affinity2021-01-21T08:12:54ZOle Bjørn Hessenbind 9.16.8 does not honor CPU affinity
### Summary
bind 9.16.8 does not honor CPU affinity mask on linux.
We are running a dpdk application that works as an firewall/ddos
protection protecting named. To run dpdk we need to reserve
a couple of dedicated CPUs for dpdk threa...
### Summary
bind 9.16.8 does not honor CPU affinity mask on linux.
We are running a dpdk application that works as an firewall/ddos
protection protecting named. To run dpdk we need to reserve
a couple of dedicated CPUs for dpdk threads. These threads must
run on same CPU socket as PCI-bus/NIC card, so they must run on
the first CPU socket. No other threads must use these CPUs that
is dedicated to this dpdk application.
On linux the command taskset is used to set the CPU affinity mask
for a process. Or one can use kernel boot parameter isolcpus to
set system CPU affinity.
The problem is that named ignores the existing affinity mask and blindly
binds the threads for isc-{net,worker,socket}-{nr} to process number {nr}.
### BIND version used
BIND 9.16.8
### Steps to reproduce
``` sh
# taskset fff0 ./bin/named/named -f -c /etc/named/named.conf -u named -U 6 -n 10
# ps -T -o pid,psr,time,comm -e | egrep 'isc-net-0000'
32374 0 00:00:00 isc-net-0000
```
The taskset command signals to named that it can select all cpus but not cpu 0,1,2,3
### What is the current *bug* behavior?
### What is the expected *correct* behavior?
Select next available CPU relative to the existing affinity mask.
For the process above I would have expected the first thread to
bind to CPU 4.
``` sh
# ps -T -o pid,psr,time,comm -e | egrep 'isc-net-0000'
32374 4 00:00:00 isc-net-0000
```
### Possible fixes
The following code fetches the existing affinity mask and use it to
select next available CPU.
``` c
# cat ../telenor-patches/telenor-honor-affinity.patch
diff -r -c ../bind-9.16.8-orig/lib/isc/pthreads/thread.c lib/isc/pthreads/thread.c
*** ../bind-9.16.8-orig/lib/isc/pthreads/thread.c 2020-10-13 10:41:40.000000000 +0200
--- lib/isc/pthreads/thread.c 2020-10-30 12:24:26.627360658 +0100
***************
*** 155,162 ****
cpuset_destroy(cset);
#else /* linux? */
cpu_set_t set;
CPU_ZERO(&set);
! CPU_SET(cpu, &set);
if (pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &set) !=
0) {
return (ISC_R_FAILURE);
--- 155,174 ----
cpuset_destroy(cset);
#else /* linux? */
cpu_set_t set;
+ if (pthread_getaffinity_np(pthread_self(), sizeof(cpu_set_t), &set) !=
+ 0) {
+ return (ISC_R_FAILURE);
+ }
+ int cpu_id = -1, cpu_aff_ok_counter = -1;
+ while (cpu_aff_ok_counter < cpu) {
+ cpu_id++;
+ if (CPU_ISSET(cpu_id, &set)) /* true if process affinity allows using cpu */
+ cpu_aff_ok_counter++;
+ if (cpu_id > 10000)
+ return (ISC_R_FAILURE);
+ }
CPU_ZERO(&set);
! CPU_SET(cpu_id, &set);
if (pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &set) !=
0) {
return (ISC_R_FAILURE);
```January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/kea/-/issues/1519Jenkins does not report crashes2021-01-06T13:29:16ZFrancis DupontJenkins does not report crashesI am afraid that the way Jenkins analyzes unit test reports misses some crashes. This ticket is about fixing this, for instance adding a message at the end of the main function of unit tests.
It is clearly a QA matter as another solutio...I am afraid that the way Jenkins analyzes unit test reports misses some crashes. This ticket is about fixing this, for instance adding a message at the end of the main function of unit tests.
It is clearly a QA matter as another solution is to use a better analyzer script...kea1.9.4Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/144Cisco ASA / AnyConnect VPN using ISC DHCPD - reassign IP-Address-leases to sa...2020-12-03T15:37:35ZGunnar HaslingerCisco ASA / AnyConnect VPN using ISC DHCPD - reassign IP-Address-leases to same VPN-Clients**Scenario:**
- Cisco AnyConnect VPN-Clients
- Cisco ASA Appliance as DHCP-Client for the VPN-Clients
- ISC DHCPD as DHCP-Server for the Cisco ASA
We like to have a lease-time of e.g. 8 days. A client connecting today should get the sam...**Scenario:**
- Cisco AnyConnect VPN-Clients
- Cisco ASA Appliance as DHCP-Client for the VPN-Clients
- ISC DHCPD as DHCP-Server for the Cisco ASA
We like to have a lease-time of e.g. 8 days. A client connecting today should get the same IP as it got yesterday. Our idea is to provide an IP-lease-Pool big enough to have pseudo-static Client-IP-Addresses. The address the client gets on it's first connect should be the same it gets the following days/months.
**Currently VPN-Clients are not assigned the same IP-Address, because:**
- Cisco ASA is acting as DHCP-Client for the VPN-Clients
- The Client-MAC of all VPN-Clients is the same (the ASA MAC)
The Client-UID (Client identifier) sent by the ASA is a combined-string of `"cisco-$MAC-$Hostname$Counter-inside"`.
- For example: `cisco-0050.5680.4b04-ClientA4567-inside`
- The Prefix "cisco" + MAC-Address of the Cisco-ASA is always the same: `cisco-0050.5680.4b04`
- The Hostname (e.g. "ClientA") is the real (unique) Hostname of our Client-Machines
- The counter counts up on every connection.
- Suffix "-inside" is always the same
- If "ClientA" disconnects and connects again it will be like `cisco-0050.5680.4b04-ClientA4568-inside` (the last digits count up)
- There seem to be no way to configure the Cisco ASA to not count up the Client-UIDs last digits on each connection
- We tried to use Option "`ignore-client-uids true;`" to reassign the same IP-Address - but this does not work, because without UID only the MAC-Address is used to re-assign the IP-Address, but all Clients have the same (Cisco ASA) MAC-Address.
**Are there any suggestions?**
- If there is no solution for this scenario, we are interested to implement an new ISC DHCPd Option "`hostname-as-uid true;`" to create the possibility to address this scenario.
- This option "`hostname-as-uid true;`" could be used like the existing "`ignore-client-uids true;`" Option, but instead of not saving the Client-UID we would override the received Client-UID with the received hostname-option.
- All functionality like storing the uid to the lease-file, checking if there is a lease for the client with the given Client-UID etc... will be done with the "replaced uid" (= Hostname) instead of the real received Client-UID.
- Are there any other suggestions or comments on this?
- Is there interest to accept a merge request if we implement such a feature?Outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/438Update version numbers and other changes before 0.13 release2020-11-04T11:55:29ZMarcin SiodelskiUpdate version numbers and other changes before 0.13 releaseWe need to bump version numbers, update ChangeLog and possibly apply other changes prior to the 0.13 release.We need to bump version numbers, update ChangeLog and possibly apply other changes prior to the 0.13 release.0.13Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2244NTA-related crash after reconfiguring views2020-12-03T15:36:27ZFritz ElfertNTA-related crash after reconfiguring views<!--
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
After modifying /etc/named.conf (moving some zones into a separate view) and restarting named,
it crashed every few (approx. 5) minutes. Before the config change, I had experimented with the
rndc nta ZONE, where ZONE was one of the zones that have been moved into a separate view.
### BIND version used
```
BIND 9.11.23-RedHat-9.11.23-1.fc32 (Extended Support Version) <id:4f70056>
running on Linux x86_64 5.8.13-200.fc32.x86_64 #1 SMP Thu Oct 1 21:49:42 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--enable-openssl-hash' '--with-geoip2' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=yes' '--with-libjson' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.2.1 20200723 (Red Hat 10.2.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
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
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
See https://bugzilla.redhat.com/show_bug.cgi?id=1893761
(config files and gdb output are attached there)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/1517Overlapping Subnet Warning2022-05-25T09:25:25ZPeter DaviesOverlapping Subnet WarningOverlapping Subnet Warning:
It is at present not considered an error to configure a subnet that has an address space that either partially or completely overlaps the address space of existing subnet.
It may however be of interest to ...Overlapping Subnet Warning:
It is at present not considered an error to configure a subnet that has an address space that either partially or completely overlaps the address space of existing subnet.
It may however be of interest to administrators that this sort of configuration exists.
Would it be possible to allow Kea to log a warning message when it discovers this type of situation?
refers to RT [#17206](https://support.isc.org/Ticket/Display.html?id=17206)kea2.1-backloghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/143Fork rights for raw IP contribution2020-11-02T17:16:23ZLoic PoulainFork rights for raw IP contributionHi folks, (@tomek, @vicky)
I would like to submit contribution(s) for enabling raw IP support in dhcpclient. It is requested for pure IP devices/interfaces that do not rely on an extra underlying protocol. The typical use case is WWAN m...Hi folks, (@tomek, @vicky)
I would like to submit contribution(s) for enabling raw IP support in dhcpclient. It is requested for pure IP devices/interfaces that do not rely on an extra underlying protocol. The typical use case is WWAN modems.
For this I need fork rights.
Regards,
Loichttps://gitlab.isc.org/isc-projects/bind9/-/issues/2243CID 312970: Incorrect expression (COPY_PASTE_ERROR) in tcp.c2020-11-05T00:32:08ZMichal NowakCID 312970: Incorrect expression (COPY_PASTE_ERROR) in tcp.cCoverity identified possible issue on `main` in 8fcad58ea6b8a2b247e4c894ef3d49778dd07b54:
```
*** CID 312970: Incorrect expression (COPY_PASTE_ERROR)
/lib/isc/netmgr/tcp.c: 282 in tcp_connect_cb()
276 }
277
278 isc__nm_...Coverity identified possible issue on `main` in 8fcad58ea6b8a2b247e4c894ef3d49778dd07b54:
```
*** CID 312970: Incorrect expression (COPY_PASTE_ERROR)
/lib/isc/netmgr/tcp.c: 282 in tcp_connect_cb()
276 }
277
278 isc__nm_incstats(sock->mgr, sock->statsindex[STATID_CONNECT]);
279 r = uv_tcp_getpeername(&sock->uv_handle.tcp, (struct sockaddr *)&ss,
280 &(int){ sizeof(ss) });
281 if (r != 0) {
>>> CID 312970: Incorrect expression (COPY_PASTE_ERROR)
>>> "status" in "isc___nm_uverr2result(status, true, "netmgr/tcp.c", 282U)" looks like a copy-paste error.
282 failed_connect_cb(sock, req, isc__nm_uverr2result(status));
283 return;
284 }
285
286 atomic_store(&sock->connecting, false);
287
```
It's possible that Coverity is dead wrong about this, if so let me know and I add it to ignore list in Coverity Scan dashboard.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/kea/-/issues/1516Fix doxygen2020-11-18T12:49:14ZFrancis DupontFix doxygenA few doxygen trivial errors introduced recently should be fixed.A few doxygen trivial errors introduced recently should be fixed.kea1.9.2Francis DupontFrancis Dupont