ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-07-05T09:32:08Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1920MySQL schema update for storing classes in the config backend2021-07-05T09:32:08ZMarcin SiodelskiMySQL schema update for storing classes in the config backendThe [design document](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/client-classes-in-cb) describes extensions to the existing config backend schema to store client classes. This issue covers the implementation of the schema ch...The [design document](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/client-classes-in-cb) describes extensions to the existing config backend schema to store client classes. This issue covers the implementation of the schema changes. It is a part of the larger work requested #1167.kea1.9.10Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/560Pool utilization shows inaccurate numbers2022-08-29T08:33:23ZTommyPool utilization shows inaccurate numbers**Setup:**
Kea DHCPv4. There is a pool with 21 ip addresses to assign dynamically while others are set by reservations.
**Stork Server version:**
<del>0.18.0</del> **1.0.0**
**Problem:**
Stork Server sees only those 21 ip addresses b...**Setup:**
Kea DHCPv4. There is a pool with 21 ip addresses to assign dynamically while others are set by reservations.
**Stork Server version:**
<del>0.18.0</del> **1.0.0**
**Problem:**
Stork Server sees only those 21 ip addresses but host reservations are counted in the statistics as well so I get numbers like:
```
Available: 21
Used: 91
```
It also affects the Web UI:
![image](/uploads/80cdf1e1ef22da80593664f3973dcb0c/image.png)
I do not have premium hooks installed.1.1Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2756RNDC fails when using keys with different algorithms within a control channel.2021-08-19T05:23:41ZEverett FultonRNDC fails when using keys with different algorithms within a control channel.Ref: https://support.isc.org/Ticket/Display.html?id=18569
A customer who is planning to change 'rndc' key algorithm from md5 to sha256, reports that in a list of keys configured in a single 'inet' block, the first-listed key work prope...Ref: https://support.isc.org/Ticket/Display.html?id=18569
A customer who is planning to change 'rndc' key algorithm from md5 to sha256, reports that in a list of keys configured in a single 'inet' block, the first-listed key work properly, subsequent keys using the same algorithm will also work, while later keys with different algorithms will fail.
### BIND version used
9.16.15, also confirmed on 9.11.31
### Steps to reproduce
Keys with differing algorithms, e.g.: md5 and sha256, and BIND configuration containing the keys in a control channel:
```
acl "rndc-users" {
192.168.12.100/32;
192.168.12.82/32;
};
key "key1" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "key2" {
algorithm "hmac-md5";
secret "????????????????????????";
};
.
.
.
controls {
inet 192.168.12.95 allow {
"rndc-users";
} keys {
"key1";
"key2";
};
};
```
Same key material in rndc.conf on remote hosts referenced by the 'rndc-users' ACL.
### What is the current *bug* behavior?
First key in the list will work properly, as well as any other keys using the same algorithm. A key in the list of a different algorithm will fail, and also any subsequent keys based on the algorithm of the first key.
rndc fails with the error:
```
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized,
* the key signing algorithm is incorrect, or
* the key is invalid.
```
A workaround is to set up another control channel on a different port, so each channel only has keys of the same algorithm.
### What is the expected *correct* behavior?
Customer expected both old and new keys to be functional.
Specific keys and config are in Support ticket linked above, but this problem is reproducible with any similar situation.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/kea/-/issues/1919ZTP with KEA for Huawei switches2021-07-29T14:50:36ZBranka AndrijasevicZTP with KEA for Huawei switchesHi ISC Support,
In the context of using KEA DHCP for ZTP of Huawei Switches, we’re right now facing an issue within the implementation of RFC Compliance within KEA DHCP.
Based on the documentation of Huawei (see https://support.hu...Hi ISC Support,
In the context of using KEA DHCP for ZTP of Huawei Switches, we’re right now facing an issue within the implementation of RFC Compliance within KEA DHCP.
Based on the documentation of Huawei (see https://support.huawei.com/enterprise/en/doc/EDOC0100533703?section=j004) the Switch Firmware is relying on the overlapping Options 141 + 146 (see https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#id2) which are conflicting in terms of DHCP Option Type.
We would therefore kindly ask ISC to review this issue, as it’s entirely blocking the introduction of ZTP / Autoconfiguration of Huawei Switches within our installation base.
In case no solution exists out of the box, we would further ask ISC to consider a compatibility option for allowing the override of standard RFC-ed options, see e.g. https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#kea-dhcpv4-compatibility-configuration-parameters
Kind Regardsoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1918Kea 1.9.8 is not working with Dell X10522022-09-01T14:36:29ZTommyKea 1.9.8 is not working with Dell X1052---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug:**
Kea does not work with Dell X1052 switch. While having no issues with old dhcpd or any other dhcp server.
**To Reproduce**
Steps to reproduce the...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug:**
Kea does not work with Dell X1052 switch. While having no issues with old dhcpd or any other dhcp server.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea (dhcpv4) with the configuration that is provided below.
2. A client sends `DISCOVER` packet.
3. Kea answers with `OFFER`.
4. Client does not follow with `REQUEST`.
**Expected behavior:**
The client is supposed to send back `REQUEST` packet.
**Environment:**
- Kea version: 1.9.8
- OS: Ubuntu 20.04.2 LTS
- If/which hooks where loaded in: libdhcp_lease_cmds.so, libdhcp_stat_cmds.so, libdhcp_ha.so. But, as I mentioned, tried it with the default configuration and result was the same.
**Additional Information**
Configuration:
```
{
"Dhcp4": {
"next-server": "10.5.255.254",
"boot-file-name": "/dev/null",
"echo-client-id": false,
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea/dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"valid-lifetime": 300,
"max-valid-lifetime": 300,
"interfaces-config": {
"interfaces": [
"eno1/10.5.255.254"
]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/tmp/kea-ipv4-leases.csv",
"lfc-interval": 600
},
"option-data": [
{
"space": "dhcp4",
"name": "domain-name-servers",
"code": 6,
"data": "8.8.8.8"
}
],
"shared-networks": [
{
"name": "test",
"subnet4": [
{
"subnet": "10.5.0.0/16",
"pools": [
{
"pool": "10.5.20.100 - 10.5.40.100"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "10.5.0.1"
}
]
}
]
}
]
}
}
```
Kea debug output:
```
2021-06-07 21:26:36.579 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.5.0.0/16 for packet received by matching address 10.5.255.254
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.packets/736980.140690847578560] DHCP4_SUBNET_SELECTED [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: the subnet with ID 1 was selected for client assignments
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.packets/736980.140690847578560] DHCP4_SUBNET_DATA [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: the selected subnet details: 10.5.0.0/16
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by hwaddr=684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=684F64BE59E3, found 0 host(s)
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier hwaddr=684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by client-id=01684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01684F64BE59E3, found 0 host(s)
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier client-id=01684F64BE59E3
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcp4/736980.140690847578560] DHCP4_CLASS_ASSIGNED [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: client packet has been assigned to the following class(es): UNKNOWN
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcp4/736980.140690847578560] DHCP4_CLASS_ASSIGNED [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_X1052, UNKNOWN
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.ddns/736980.140690847578560] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: processing client's Hostname option
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:68:4f:64:be:59:e3
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 68:4f:64:be:59:e3
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.alloc-engine/736980.140690847578560] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.5.20.163
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.5.20.164
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 10.5.20.164
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.5.20.164
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.5.20.164, found 0 host(s)
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 1 and address 10.5.20.164
2021-06-07 21:26:36.582 INFO [kea-dhcp4.leases/736980.140690847578560] DHCP4_LEASE_ADVERT [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: lease 10.5.20.164 will be advertised
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.options/736980.140690847578560] DHCP4_PACKET_PACK [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: preparing on-wire format of the packet to be sent
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.packets/736980.140690847578560] DHCP4_PACKET_SEND [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: trying to send packet DHCPOFFER (type 2) from 10.5.255.254:67 to 255.255.255.255:68 on interface eno1
2021-06-07 21:26:36.583 DEBUG [kea-dhcp4.packets/736980.140690847578560] DHCP4_RESPONSE_DATA [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: responding with packet DHCPOFFER (type 2), packet details: local_address=10.5.255.254:67, remote_address=255.255.255.255:68, msg_type=DHCPOFFER (2), transid=0x9d0e4aed,
options:
type=001, len=004: 4294901760 (uint32)
type=003, len=004: 10.5.0.1
type=006, len=004: 8.8.8.8
type=051, len=004: 300 (uint32)
type=053, len=001: 2 (uint8)
type=054, len=004: 10.5.255.254
type=061, len=007: 01:68:4f:64:be:59:e3
```
PCAP when DELL x1052 is trying to get dhcp from Kea (not working):
[kea.pcap](/uploads/8ffbf576932a58e56aa46b81218a349c/kea.pcap)
PCAP when DELL x1052 is trying to get dhcp from dhcpd (working as expected):
[dhcpd.pcap](/uploads/5d884c3cdf13b3902bf147f5bc20f04f/dhcpd.pcap)
- There are no errors or related logs in X1052 switch.
- If offer is sent from any other dhcp server Dell switch accepts it and sends `REQUEST` back as expected. Then you can start Kea and it will continue to work with Kea as well, as the `offer` part is already 'done' and `REQUEST` packets are being sent from Dell.
- Working on this with Dell support as well, but no results at the moment.
- If anyone has any insights of what could be tested to change this behaviour - please let me know.
If you need more details - just let me know and I will provide it.
**Contacting you:**
Send a message in GitLab.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/559Stork Agent exporters binds on * (all) no matter what is listed in config2021-08-11T13:16:37ZToozStork Agent exporters binds on * (all) no matter what is listed in configAs the title says:
Stork agent kea, bind9 exporters always listens on *:Port no matter what is given in the `agent.env` configuration file.
agent.env configuration:
```
# address to bind ie. for listening
STORK_AGENT_ADDRESS=127.0.0.1
S...As the title says:
Stork agent kea, bind9 exporters always listens on *:Port no matter what is given in the `agent.env` configuration file.
agent.env configuration:
```
# address to bind ie. for listening
STORK_AGENT_ADDRESS=127.0.0.1
STORK_AGENT_PROMETHEUS_KEA_EXPORTER_ADDRESS=127.0.0.1
STORK_AGENT_PROMETHEUS_BIND9_EXPORTER_ADDRESS=127.0.0.1
```
`ss` command output:
```
LISTEN 0 4096 127.0.0.1:8080 0.0.0.0:* users:(("stork-agent",pid=64694,fd=8))
LISTEN 0 4096 *:9119 *:* users:(("stork-agent",pid=64694,fd=7))
LISTEN 0 4096 *:9547 *:* users:(("stork-agent",pid=64694,fd=46))
```
Seems like only the `STORK_AGENT_ADDRESS` parameter is proceeded as it should.
Stork agent version: 0.18.0
Stork installed from repository, so starting just with `systemctl start isc-stork-agent`
Stork logs:
```
Jun 8 16:06:37 ubuntu-server stork-agent[1398]: #033[36mINFO#033[0m[2021-06-08 16:06:37] main.go:23 Starting Stork Agent, version 0.18.0, build date 2021-06-01 09:57
Jun 8 16:06:37 ubuntu-server stork-agent[1398]: #033[36mINFO#033[0m[2021-06-08 16:06:37] promkeaexporter.go:269 Prometheus Kea Exporter listening on :9547, stats pulling interval: 10 seconds
Jun 8 16:06:37 ubuntu-server stork-agent[1398]: #033[36mINFO#033[0m[2021-06-08 16:06:37] monitor.go:95 Started app monitor
Jun 8 16:06:37 ubuntu-server stork-agent[1398]: #033[36mINFO#033[0m[2021-06-08 16:06:37]prombind9exporter.go:822 Prometheus BIND 9 Exporter listening on :9119, stats pulling interval: 10 seconds
Jun 8 16:06:37 ubuntu-server stork-agent[1398]: #033[36mINFO#033[0m[2021-06-08 16:06:37] agent.go:420 started serving Stork Agent #033[36maddress#033[0m="[::]:8080"
```0.19Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1917Diverse updates to ARM II2021-06-17T13:14:59ZPeter DaviesDiverse updates to ARM IIDiverse updates and typos.Diverse updates and typos.kea1.9.9Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1916Change to debug level for DHCP4_PACKET_DROP_x2021-06-25T16:43:35ZPeter DaviesChange to debug level for DHCP4_PACKET_DROP_xChange to debug level for DHCP4_PACKET_DROP_x:
The DHCP4_PACKET_DROP_x messages may not have the correct visibility due to the high debug level they get generated at.
Message in particular DHCP4_PACKET_DROP_0013 is generated at debug...Change to debug level for DHCP4_PACKET_DROP_x:
The DHCP4_PACKET_DROP_x messages may not have the correct visibility due to the high debug level they get generated at.
Message in particular DHCP4_PACKET_DROP_0013 is generated at debug level DBGLVL_TRACE_BASIC and greater.
Would it be possible to generate this message at a lower level - between levels 5 - 10 has been suggested.
[RT #18571](https://support.isc.org/Ticket/Display.html?id=18571)kea1.9.9Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1915Change to ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET message2021-06-25T16:43:36ZPeter DaviesChange to ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET messageChange to ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET message:
Would it be possible to add subnet address & prefix fields to the ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET message.
Currently the message show the client identifier and the subnet number...Change to ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET message:
Would it be possible to add subnet address & prefix fields to the ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET message.
Currently the message show the client identifier and the subnet number.
"% 1: failed to allocate an IPv4 address in the subnet with id % 2"
[RT #18571](https://support.isc.org/Ticket/Display.html?id=18571)kea1.9.9Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/stork/-/issues/558Stork Agent registers with different token on each service/server restart2021-09-07T08:46:54ZToozStork Agent registers with different token on each service/server restartWhen using auto registration to stork server from stork agent side, the same machine registers with different agent token each time, so you have to move it from unauthorised to authorised on each server/service restart, configuration eg:...When using auto registration to stork server from stork agent side, the same machine registers with different agent token each time, so you have to move it from unauthorised to authorised on each server/service restart, configuration eg:
```
STORK_AGENT_SERVER_URL=http://example.com
STORK_AGENT_ADDRESS=111.111.111.111
```
to reproduce this just use the configuration above, restart `isc-stork-agent` and look at the Machines dashboard, it is moved from Authorised to Unauthorised and has different token provided.
Not sure if this behaviour is expected?0.20https://gitlab.isc.org/isc-projects/stork/-/issues/557Error when registering stork agent via script downloaded from stork server wh...2021-09-07T17:26:06ZToozError when registering stork agent via script downloaded from stork server when it's under nginx proxyStork Server is installed on remote server and is under nginx proxy. Nginx configuration is the same as you provide in your example. Everything works except registering stork agent via script downloaded from the server (services -> machi...Stork Server is installed on remote server and is under nginx proxy. Nginx configuration is the same as you provide in your example. Everything works except registering stork agent via script downloaded from the server (services -> machines -> how to install agent on new machine).
You get an example like:
```
wget http://example.com/stork-install-agent.sh
chmod a+x stork-install-agent.sh
sudo ./stork-install-agent.sh
```
When executing these commands on machine that should run stork agent you get the following error:
```
./stork-install-agent.sh: line 1: syntax error near unexpected token `newline'
./stork-install-agent.sh: line 1: `<!DOCTYPE html>'
```
Is this some sort of a misconfiguration from my side or it's a bug?
NOTE: when trying directly via IP address instead of domain it works as it should.
Content of stork-install-agent.sh:
```
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Stork</title>
<base href="/" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link rel="icon" type="image/x-icon" href="favicon.ico" />
<link href="https://fonts.googleapis.com/css?family=Mansalva&display=swap" rel="stylesheet" />
<link rel="stylesheet" href="styles.59fb5e3c22a146135eaa.css"></head>
<body style="font-family: 'Open Sans', 'Helvetica Neue', sans-serif">
<app-root></app-root>
<script src="runtime-es2015.0dae8cbc97194c7caed4.js" type="module"></script><script src="runtime-es5.0dae8cbc97194c7caed4.js" nomodule defer></script><script src="polyfills-es5.12b5c32d1603e35dd556.js" nomodule defer></script><script src="polyfills-es2015.09ee2f719bd21ab5c7b1.js" type="module"></script><script src="scripts.fb336acc5f50a08fd950.js" defer></script><script src="main-es2015.f4e4057b7b085515a0f4.js" type="module"></script><script src="main-es5.f4e4057b7b085515a0f4.js" nomodule defer></script></body>
</html>
```0.20Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/195isc-dhcp-server fails to start after update2022-01-20T15:35:06ZxJustmy2centsisc-dhcp-server fails to start after update---
name: Bug report
about: DHCP Server fails to control subservices after upgrade
---
**Describe the bug**
**log from apt upgrade:**
```
Setting up isc-dhcp-server (4.3.5-3+deb9u2) ...
Job for isc-dhcp-server.service failed because ...---
name: Bug report
about: DHCP Server fails to control subservices after upgrade
---
**Describe the bug**
**log from apt upgrade:**
```
Setting up isc-dhcp-server (4.3.5-3+deb9u2) ...
Job for isc-dhcp-server.service failed because the control process exited with error code.
See "systemctl status isc-dhcp-server.service" and "journalctl -xe" for details.
invoke-rc.d: initscript isc-dhcp-server, action "start" failed.
* isc-dhcp-server.service - LSB: DHCP server
Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-06-06 10:34:25 CEST; 82ms ago
Docs: man:systemd-sysv-generator(8)
Process: 20278 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/isc-dhcp-server.service
`-1457 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf
Jun 06 10:34:24 derdapp003 systemd[1]: Starting LSB: DHCP server...
Jun 06 10:34:24 derdapp003 isc-dhcp-server[20278]: Launching both IPv4 and IPv6 servers (please configure INTERFACES in /etc/default/isc-dhcp-serve…he other).
Jun 06 10:34:25 derdapp003 isc-dhcp-server[20278]: Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid curr….. failed!
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Jun 06 10:34:25 derdapp003 systemd[1]: Failed to start LSB: DHCP server.
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
```
```
root@derdapp003:~# ps -ef|grep dhcp
root 1457 1 0 Apr20 ? 00:03:24 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf
root 20508 19428 0 10:37 pts/0 00:00:00 grep dhcp
```
**Cause**:
I have only IPv4 configured and up and running. On the upgrade isc seems to want IPv6 to be configured and fails with unspecific reason "exit-code".
First issue: the subprocess for dhcpd ipv4 is not stopped or not stopped in a correct manner.
Killing it manualy results in a pid file remaining, that also needs to be removed:
```
Jun 6 10:45:50 localhost isc-dhcp-server[20975]: Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid currenty exists) ... failed!
Jun 6 10:45:50 localhost systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Jun 6 10:45:50 localhost systemd[1]: Failed to start LSB: DHCP server.
```
Even doing so, the ics-dhcp-server fails on the next start with the same error in sequence.
After configuring `nano /etc/default/isc-dhcp-server`
with
```
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACESv4="eth0.200 eth0.300 eth0.400"
INTERFACESv6=""
```
the server starts w/o any errors.
**claims**:
1. if no ipv6 interface is configured, the server should not fail to start, but just drop the ipv6 sequence
2. if the ics-dhcp-server fails to start for any reason, it should take care about subprocesses to be stopped in a correct way not leaving ghosts or pidfiles.
**Systeminformation**:
```
Linux derdapp003 4.19.59-sunxi #5.91 SMP Mon Jul 15 14:09:32 CEST 2019 armv7l GNU/Linux
description: ARMv7 Processor rev 4 (v7l)
product: LeMaker Banana Pro
~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.13 (stretch)
Release: 9.13
Codename: stretch
~# dpkg -l|grep dhcp
ii isc-dhcp-client 4.3.5-3+deb9u2 armhf DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.5-3+deb9u2 armhf common manpages relevant to all of the isc-dhcp packages
ii isc-dhcp-server 4.3.5-3+deb9u2 armhf ISC DHCP server for automatic IP address assignment
```https://gitlab.isc.org/isc-projects/kea/-/issues/1914HAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading sometimes fails2023-02-27T13:41:09ZAndrei Pavelandrei@isc.orgHAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading sometimes failsThis time it happened on distcheck on CentOS 8.
https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/415/execution/node/136/log/?consoleFull
```
16:04:40 [ RUN ] HAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading
16:04:...This time it happened on distcheck on CentOS 8.
https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/415/execution/node/136/log/?consoleFull
```
16:04:40 [ RUN ] HAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading
16:04:40 ../../../../../../../src/hooks/dhcp/high_availability/tests/ha_service_unittest.cc:1096: Failure
16:04:40 Expected equality of these values:
16:04:40 2
16:04:40 factory3_->getResponseCreator()->getReceivedRequests().size()
16:04:40 Which is: 1
16:04:40 ../../../../../../../src/hooks/dhcp/high_availability/tests/ha_service_unittest.cc:1102: Failure
16:04:40 Value of: update_request3
16:04:40 Actual: false
16:04:40 Expected: true
16:04:40 [ FAILED ] HAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading (2 ms)
```backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2755Bad TKEY samples in genzone.sh comment2021-07-08T08:02:48ZFrancis DupontBad TKEY samples in genzone.sh commentIn bin/tests/system/genzone.sh there are two TKEY RR samples using a number for the algorithm field when RFC 2930 specifies this field as a DNS name. As the TKEY RR is a meta RR which should never appear in a real zone file these samples...In bin/tests/system/genzone.sh there are two TKEY RR samples using a number for the algorithm field when RFC 2930 specifies this field as a DNS name. As the TKEY RR is a meta RR which should never appear in a real zone file these samples are in a comment which starts at line 422 making this ticket less than minor...July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)https://gitlab.isc.org/isc-projects/kea/-/issues/1913NameChangeUDPTest.roundTripTest sometimes fails2021-10-22T07:38:07ZAndrei Pavelandrei@isc.orgNameChangeUDPTest.roundTripTest sometimes failsThis time it happened on CentOS 8 distcheck.
https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/414/execution/node/148/log/
```
23:38:28 [ RUN ] NameChangeUDPTest.roundTripTest
23:38:28 ../../../../../../src/lib/dhcp_ddns/tes...This time it happened on CentOS 8 distcheck.
https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/414/execution/node/148/log/
```
23:38:28 [ RUN ] NameChangeUDPTest.roundTripTest
23:38:28 ../../../../../../src/lib/dhcp_ddns/tests/ncr_udp_unittests.cc:1062: Failure
23:38:28 Value of: checkSendVsReceived(sent_ncrs_[i], received_ncrs_[i])
23:38:28 Actual: false
23:38:28 Expected: true
23:38:28 ../../../../../../src/lib/dhcp_ddns/tests/ncr_udp_unittests.cc:1062: Failure
23:38:28 Value of: checkSendVsReceived(sent_ncrs_[i], received_ncrs_[i])
23:38:28 Actual: false
23:38:28 Expected: true
23:38:28 [ FAILED ] NameChangeUDPTest.roundTripTest (0 ms)
```kea2.1.0https://gitlab.isc.org/isc-projects/dhcp/-/issues/194resolvconf support is missing in dhclient2022-03-09T19:00:02Zonehalf3544resolvconf support is missing in dhclientBy default dhclient overwrites the /etc/resolv.conf once the nameservers' ips are obtain from the DHCP server or the lease is renewed. This becomes problematic when there are other source of those from other interfaces (e.g. openconnect/...By default dhclient overwrites the /etc/resolv.conf once the nameservers' ips are obtain from the DHCP server or the lease is renewed. This becomes problematic when there are other source of those from other interfaces (e.g. openconnect/openvpn, which set up DNS servers from the private network). The natural solution is the usage of resolvconf, which manages such updates from multiple sources and merges them into /etc/resolv.conf
Since this is more like a feature request, it was suggested that this should be fixed here (https://bbs.archlinux.org/viewtopic.php?pid=1969134).
Would such PR be accepted? The changes are quite trivial..
Thanks.
**Describe the bug**
dhclient overwrites the /etc/resolv.conf blindly, disregarding the fact that it could have been updated by other (dhcp) clients
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient with default config
2. Modify /etc/resolv.conf by any means
3. Wait for the lease renewal on the dhclient interface
4. Observe the contents of the /etc/resolv.conf
**Expected behavior**
/etc/resolv.conf contents should be preserved somehow. Proposed way is to use resolvconf for that.
**Environment:**
dhclient --version
isc-dhclient-4.4.2
- OS: ArchLinux
Linux laptop_name 5.12.7-arch1-1 #1 SMP PREEMPT Wed, 26 May 2021 22:03:57 +0000 x86_64 GNU/Linux
pacman -F dhclient
core/netctl 1.24-1
usr/lib/netctl/dhcp/dhclient
**Additional Information**
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
It is not - https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux#L80
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
Did not check, but would prefer to keep original dhclient
- Are you sure what you would like to do is not possible using some other mechanisms?
Using hooks, yes, but feature implementation is better to be done as close to the source as possible
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
arch linux forum - https://bbs.archlinux.org/viewtopic.php?pid=1969134#p1969134
**Is your feature request related to a problem? Please describe.**
I'm frustrated when my VPN tunnel DNS server IP is overwritten with the ISP dhcp
**Describe the solution you'd like**
Check if /usr/bin/resolvconf exists and use it if it does
**Describe alternatives you've considered**
switch to a different dhcp client
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs?
I could provide the patch once I can fork the project here
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code?
yes
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.
onehalf3544@gmail.comOutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2754Bind not returning RPZ entries when edns0 z-field set to 0x80002021-06-03T21:48:32ZPatrick KavajinBind not returning RPZ entries when edns0 z-field set to 0x8000<!--
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
We noticed that dns queries which get forwarded by coredns to our bind do not get the answers we expect.
Queries against domains where we override the A record using a rpz get the regular A record as an answer instead of the overridden one.
By diffing direct queries against the bind using dig and queries forwarded over coredns we saw that coredns sets the edns0 z-field to 0x8000 instead of 0x0000 like dig. If i understand it correctly, 0x8000 means something like "allow dnssec security rr".
Read through some of the RFCs but I'm still not sure if this is a bug or expected behaviour to bypass the rpz in this case.
So, sorry for wasting your time if this is indeed wanted.
### BIND version used
1:9.11.5.P4+dfsg-5.1+deb10u5
### Steps to reproduce
1. Set up a bind with a db.rpz overriding the A record for a public domain name.
2. Query against it with edns0 z-field set to 0x0000 -> you get the A record from the rpz
3. Query against it with edns0 z-field set to 0x8000 -> you get the public A record
See the following db.rpz as an example:
```
$TTL 60
@ IN SOA localhost. root.localhost. (
1234567890 ; serial
1h ; refresh
30m ; retry
1w ; expiry
30m) ; minimum
IN NS localhost.
*.int.prod.nect.com A 192.168.13.37
```
I used the following two calls to craft the dns packets and watched the responses with wireshark, prolly there's also an option for dig to test it:
```
# z field set to 0x0000
echo -n -e "\x5b\x30\x01\x20\x00\x01\x00\x00\x00\x00\x00\x01\x10\x77\x61\x73\x64\x65\x6d\x66\x69\x63\x6b\x69\x73\x74\x64\x61\x73\x03\x69\x6e\x74\x04\x70\x72\x6f\x64\x04\x6e\x65\x63\x74\x03\x63\x6f\x6d\x00\x00\x01\x00\x01\x00\x00\x29\x10\x00\x00\x00\x00\x00\x00\x0c\x00\x0a\x00\x08\x00\xa9\xf9\xeb\x26\xc0\x68\x8b" | nc -u 127.0.0.1 53
# z field set to 0x8000
echo -n -e "\x5b\x30\x01\x20\x00\x01\x00\x00\x00\x00\x00\x01\x10\x77\x61\x73\x64\x65\x6d\x66\x69\x63\x6b\x69\x73\x74\x64\x61\x73\x03\x69\x6e\x74\x04\x70\x72\x6f\x64\x04\x6e\x65\x63\x74\x03\x63\x6f\x6d\x00\x00\x01\x00\x01\x00\x00\x29\x10\x00\x00\x00\x80\x00\x00\x0c\x00\x0a\x00\x08\x00\xa9\xf9\xeb\x26\xc0\x68\x8b" | nc -u 127.0.0.1 53
```
Expected behaviour is to get the entry from the rpz, no matter what flag the client set.https://gitlab.isc.org/isc-projects/stork/-/issues/556Attempt to reduce Stork dependencies2023-12-11T10:00:07ZTomek MrugalskiAttempt to reduce Stork dependenciesThe recent security audit shows that we have lots of dependencies and that means more exposure to third party vulnerabilities and potential necessity to do frequent Stork security updates. That is something we clearly want to avoid.
@on...The recent security audit shows that we have lots of dependencies and that means more exposure to third party vulnerabilities and potential necessity to do frequent Stork security updates. That is something we clearly want to avoid.
@ondrej mentioned two tools that may possibly be helpful:
- https://dependencytrack.org/
- https://github.com/oss-review-toolkit/ort
I'm sure there are others. We should look at them and see if there's anything we don't need in our dependencies. This tickets covers just doing the analysis and assess how much effort would it be to do the dependency removal, if it is even feasible. The actual removal is out of scope.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1912update lib dns++ python tools2021-06-03T15:37:03ZFrancis Dupontupdate lib dns++ python tools#1880 showed that even they still work the python tools used for the dns++ library should be updated:
- src/lib/dns/gen-rdatacode.py complains about a not existing (BTW for a long time) file in a not existing (this point triggers the er...#1880 showed that even they still work the python tools used for the dns++ library should be updated:
- src/lib/dns/gen-rdatacode.py complains about a not existing (BTW for a long time) file in a not existing (this point triggers the error) src/lib/dns/python directory. IMHO the corresponding code is obsolete i.e. implements a feature which has not been used since a lot of years if it was used one day...
- src/lib/util/python/gen_wiredata.py triggers a warning with python3. I added a comment at the corresponding line of code.
The documentation should be updated too: for the first script it is in the s-rdatacode entry of the Makefile. The second is in a commented entry of the src/lib/dns/tests/testdata Makefile and requires to be called in the UTC timezone when timestamps are generated as for RRSIG or TKEY RRs (I used with success the TZ environment variable).outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2753timer_test subtests are not independent2021-07-12T03:58:03ZMark Andrewstimer_test subtests are not independentJob [#1773630](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1773630) failed for 6d84bff56595a2d06014f344f4b76bc4f316168a:
Only the first subtest failed below (timer_test.c:234 subthread_assert_true) but 2..5 reported failures.
```
...Job [#1773630](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1773630) failed for 6d84bff56595a2d06014f344f4b76bc4f316168a:
Only the first subtest failed below (timer_test.c:234 subthread_assert_true) but 2..5 reported failures.
```
1..5
# timer_test.c:234 subthread_assert_true
not ok 1 - ticker
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 2 - once_life
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 3 - once_idle
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 4 - reset
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 5 - purge
# 0x22 != 0
# timer_test.c:585: error: Failure!
```August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Mark AndrewsMark Andrews