Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-27T12:51:09Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3140Feature request: Add Statistics Counters for dropped packets (for various dif...2024-03-27T12:51:09ZCathy AlmondFeature request: Add Statistics Counters for dropped packets (for various different reasons)---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
...---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
This is loosely related to issue #3125 for counting some dropped packets due to HA (#3125 is more about not logging them unnecessarily though, or being able to disable the per-event logging).
This is a request to add a specific packet counts for both HA and for other dropped packets such as ones dropped due to kea being disabled.
Customer requesting this feature currently has an issue where they can't tell if an operator has misconfigured their network such that Kea wasn't receiving any traffic or if it was in a disabled state due to Kea HA sync.
Version 2.2
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3137Audit revision conflicts between IPv4 and IPv6 due to shared session variable2023-11-23T14:37:03ZMaurice MakaayAudit revision conflicts between IPv4 and IPv6 due to shared session variable**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_rev...**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_revision_id`. These session variables tightly couple the two paths, which can lead to conflicts.
**To Reproduce**
Here's an example scenario for a conflict:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, ok
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, fail
```
Because the global revision id now points at 2, but only `dhcp6_audit` with id 1 exists, we get:
```
ERROR: insert or update on table "dhcp6_audit" violates foreign key constraint "fk_dhcp6_audit_revision"
DETAIL: Key (revision_id)=(2) is not present in table "dhcp6_audit_revision".
CONTEXT: SQL statement "INSERT INTO dhcp6_audit (object_type, object_id, modification_type, revision_id)
VALUES (object_type_val, object_id_val,
(SELECT id FROM modification WHERE modification_type = modification_type_val),
audit_revision_id)"
PL/pgSQL function createauditentrydhcp6(character varying,bigint,character varying) line 11 at SQL statement
SQL statement "SELECT createAuditEntryDHCP6('dhcp6_client_class', NEW.id, 'create')"
PL/pgSQL function func_dhcp6_client_class_ains() line 4 at PERFORM
```
In this case, the INSERT breaks, because the DHCP6 audit record points to a non-existent `dhcp6_audit_revision` id.
Another scenario is possible, where coincidentally the incorrect revision id does exist. In that case, the audit will be assigned to an old revision in the audit trail, changing history. An example scenario for this one:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('one'); -- uses audit_revision_id = 1, ok
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('two'); -- uses audit_revision_id = 2, ok
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 1, ok
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('three'); -- uses audit_revision_id = 1, fail
```
**Expected behavior**
The audit revisions should be independent and use their own specific session variables, instead of shared ones.
When running the first scenario from the reproduction scenario:
- It must not fail
- The DHCP6 change must be logged in `dhcp6_audit` with `revision_id` = 1
- The DHCP4 change must be logged in `dhcp4_audit` with `revision_id` = 2
When running the second scenario:
- DHCP4 client class 'one' must be related to `dhcp4_audit' with `revision_id` = 1
- DHCP4 client class 'two' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP4 client class 'three' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP6 client class 'something' must be related to `dhcp6_audit' with `revision_id` = 1
**Environment:**
- Kea version: 2.5.3 and before
- Affects both MySQL and PostgreSQL
**Work-around**
To prevent issues with the current database schema, make sure that DHCP4 and DHCP6 updates are separated in the query sequence:
- create DHCP4 audit revision
- perform all DHCP4 updates
- create DHCP6 audit revision
- perform all DHCP6 updates
**Contacting you**
You can reach me at account-gitlab-isc@makaay.nloutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3135DHCPv4 V-I Vendor Class option data-len is treated as part of opaque-data string2024-01-25T06:40:06ZErik FlinkDHCPv4 V-I Vendor Class option data-len is treated as part of opaque-data string**Describe the bug**
The [OptionVendorClass](src/lib/dhcp/option_vendor_class.h#L42) encapsulates both DHCPv6 Vendor Class and DHCPv4 V-I Vendor Class options, but for DHCPv4 V-I Vendor Class options the first byte of vendor-class-data...**Describe the bug**
The [OptionVendorClass](src/lib/dhcp/option_vendor_class.h#L42) encapsulates both DHCPv6 Vendor Class and DHCPv4 V-I Vendor Class options, but for DHCPv4 V-I Vendor Class options the first byte of vendor-class-data is treated as part of the opaque-data string even though it is a data-len as specified in [RFC 3925 section 3](https://datatracker.ietf.org/doc/html/rfc3925#section-3).
**Expected behavior**
For both DHCPv6 Vendor Class and DHCPv4 V-I Vendor Class options, the tuple collection should consist of tuples of opaque-data and corresponding length field.
**Actual behavior**
- For DHCPv6 Vendor Class option, the tuple collection consists of tuples of opaque-data and corresponding length as expected.
- For DHCPv4 V-I Vendor Class option, the tuple collection consists of tuples containing vendor-class-data and corresponding length.
**Additional Information**
The actual behavior can been observed by enabling Kea debug logs and observing logs of incoming packets containing DHCPv4 V-I Vendor Class options, or by implementing a Kea hook that inspects the option. It can also be confirmed by comparing implementations of [`OptionVendorClass::pack`](src/lib/dhcp/option_vendor_class.cc#L38) and [`OptionVendorClass::unpack`](src/lib/dhcp/option_vendor_class.cc#L58) functions with RFC specifications.
DHCPv6 Vendor Class option is specified in [RFC 8415 section 21.16](https://datatracker.ietf.org/doc/html/rfc8415#section-21.16)
DHCPv4 V-I Vendor Class option is specified in [RFC 3925 section 3](https://datatracker.ietf.org/doc/html/rfc3925#section-3)
DHCPv6 Vendor Class option contains one or more instances of vendor-class-data corresponding to a single Enterprise Number, while DHCPv4 V-I Vendor Class option contains information corresponding to one or more Enterprise Numbers and one or more corresponding instances of vendor-class-data corresponding to each Enterprise Number. This difference is not handled by Kea, as also mentioned in #2521.
A related bug was recently reported and solved in Wireshark ([DHCPv4 Option 124 parsing is incorrect (#18970) · Issues · Wireshark Foundation / Wireshark · GitLab](https://gitlab.com/wireshark/wireshark/-/issues/18970)). It caused Wireshark to parse DHCPv4 V-I Vendor Class option incorrectly and not flag packets as malformed if the data-len field inside the vendor-class-data field was set incorrectly, such as if the whole vendor-class-data field was treated as opaque-data like Kea does.
**Contact**
erik.flink@ericsson.comnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3134Kea tries to open sockets on wrong interfaces when using "service-sockets-req...2024-02-08T14:34:25ZYannikKea tries to open sockets on wrong interfaces when using "service-sockets-require-all"I am using kea with this `interfaces-config`:
```
"interfaces": ["enp88s0.140"],
"service-sockets-require-all": true,
"service-sockets-max-retries": 100000
```
For some reason, kea tries to open sockets on other interfaces than the spe...I am using kea with this `interfaces-config`:
```
"interfaces": ["enp88s0.140"],
"service-sockets-require-all": true,
"service-sockets-max-retries": 100000
```
For some reason, kea tries to open sockets on other interfaces than the specified `enp88s0.140`. According to the docs, `The “service-sockets-require-all” option makes Kea require all sockets to be successfully bound.`. As far as I understand that, it means that it will retry opening sockets for the specified interfaces until they are successfully bound. However, it does not mean binding sockets for all interfaces (that would make `interfaces` useless).
I noticed this issue because some interfaces on this system do not have ip adresses asssigned, which results in kea logging the following errors over and over:
```
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap0 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap1 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap2 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap3 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap4 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap5 has no usable IPv4 addresses configured
```
Here is the list of configured interfaces on this host:
```
$ ip link show |grep -v ether
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
3: enp88s0.20@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
4: enp88s0.140@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
5: enp88s0.160@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
6: enp88s0.300@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
7: enp88s0.310@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
8: macvtap0@enp88s0.20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
9: macvtap1@enp88s0.300: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
10: macvtap2@enp88s0.300: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
11: macvtap3@enp88s0.300: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
12: macvtap4@enp88s0.140: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
13: macvtap5@enp88s0.160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3133Read TSIG secret from file2024-03-27T22:49:58ZIulian MegheaRead TSIG secret from file---
name: Feature request
about: Suggest an idea for this project
---
Allow reading tsig-keys (at least the secret) from an external file. This way it can integrate better with secret management tools.
For example the configuration cou...---
name: Feature request
about: Suggest an idea for this project
---
Allow reading tsig-keys (at least the secret) from an external file. This way it can integrate better with secret management tools.
For example the configuration could use more relaxed permissions but the file containing the tsig secret can use very restrictive permissions.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3129extend hammer to prepare kea to test it with TSAN2024-03-28T08:12:03ZWlodzimierz Wencelextend hammer to prepare kea to test it with TSANWhile checking what is really needed to run fully automated system tests against KEA with TSAN enabled I came to a conclusion that different compilation procedure have to be incorporated in hammer.
In TSAN job in jenkins we are using:
`...While checking what is really needed to run fully automated system tests against KEA with TSAN enabled I came to a conclusion that different compilation procedure have to be incorporated in hammer.
In TSAN job in jenkins we are using:
```
CXX=clang++
CXXFLAGS="-g3 -ggdb -O0 -fsanitize=thread -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches"
TSAN_OPTIONS="detect_deadlocks=1 second_deadlock_stack=1"
```kea2.5.8Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3125HA ignored packets cause DROP statistics counter increment2024-03-27T12:58:00ZDarren AnkneyHA ignored packets cause DROP statistics counter incrementHA_BUFFER6_RECEIVE_NOT_FOR_US increments drop counters.
- This happens at least with a load balancing configuration.
- I think maybe not with hot-standby since I don't think the service logs anything or cares about incoming client pack...HA_BUFFER6_RECEIVE_NOT_FOR_US increments drop counters.
- This happens at least with a load balancing configuration.
- I think maybe not with hot-standby since I don't think the service logs anything or cares about incoming client packets unless it loses contact with the HA peer?
- I cite BUFFER6 above but I'm sure the same is true for DHCPv4.
Possible solutions:
- introduce a new drop status that could be discounted later or part of a different drop statistic?
- Could introduce new status that it is ignored or filtered instead of dropped?
[SF1374](https://isc.lightning.force.com/lightning/r/Case/5007V00002YkO0oQAF/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3114Second Device Unique ID (duid) on DHCP6-Server2023-12-21T14:31:57ZschniefiSecond Device Unique ID (duid) on DHCP6-ServerI would like to reserve an IPv6 address in a multi-boot system for both the first DUID (Linux) and the second DUID (Windows).\
Is it possible to specify a second DUID in one IPv6 reservation? So as in the following example:
`{ "command"...I would like to reserve an IPv6 address in a multi-boot system for both the first DUID (Linux) and the second DUID (Windows).\
Is it possible to specify a second DUID in one IPv6 reservation? So as in the following example:
`{ "command": "reservation-add", "service": [ "dhcp6" ], "arguments": { "reservation": { "subnet-id": 123, "hostname": "xyz", "ip-addresses": ["1999:123:56a:1800::123"], "duid": "11:11:11:11:11:11", "duid2": "22:22:22:22:22:22" } } }`
When searching for the IPv6 reservation, both the duid and duid2 should be possible inputs:
`{ "command": "reservation-get", "service": [ "dhcp6" ], "arguments": { "subnet-id": 123, "identifier-type": "duid", "identifier": "11:11:11:11:11:11" } }`\
or\
`{ "command": "reservation-get", "service": [ "dhcp6" ], "arguments": { "subnet-id": 123, "identifier-type": "duid2", "identifier": "22:22:22:22:22:22" } }`
For differentiation, the IPv6 reservations should adhere to the following uniqueness criteria:
* unique("ip-address","subnet-id","duid")
* unique("ip-address","subnet-id","duid2")outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3113Don't seem to be able to skip subnet/lease selection in a hook2024-03-28T08:10:19ZAndrew ForgueDon't seem to be able to skip subnet/lease selection in a hookWhat's the proper way to skip lease/subnet selection and delegate _everything_ to a hook library? I'm trying to hook kea up to a custom IPAM system.
The best I can tell is that you implement `pkt4_receive`/`pkt4_send` and tell `lease4_...What's the proper way to skip lease/subnet selection and delegate _everything_ to a hook library? I'm trying to hook kea up to a custom IPAM system.
The best I can tell is that you implement `pkt4_receive`/`pkt4_send` and tell `lease4_select` and `subnet4_select` as `setStatus(CalloutHandle::NEXT_STEP_SKIP)`.
The hook documentation for lease4_select says:
> Next step status: If any callout installed on the "lease4_select" hook sets the next step action to SKIP, the server will not assign any lease and the callouts become responsible for the lease assignment. If the callouts fail to provide a lease, the packet processing will continue, but client will not get an address.
I'm confused as to which (other) callouts should "provide a lease" if I'm skipping lease4_select? Should I be overwriting the lease4 argument in `lease4_select` instead, and setting `NEXT_STATUS_CONTINUE`? If I do this, how do I prevent Kea from recording the lease? Do I need to SKIP `lease4_*` callouts too?
The only subnet is one from `0.0.0.0` - `255.255.255.255`
```
int pkt4_receive(CalloutHandle &handle) {
... business logic here ...
}
int pkt4_send(CalloutHandle &handle) {
... business logic here ...
}
int lease4_select(CalloutHandle &handle) {
handle.setStatus(CalloutHandle::NEXT_STEP_SKIP);
return 0;
}
int subnet4_select(CalloutHandle &handle) {
handle.setStatus(CalloutHandle::NEXT_STEP_SKIP);
return 0;
}
```
Kea 2.4 seems to drop the packet after DHCP4_PACKET_NAK_0003 (even though pkt4_send will eventually fill in everything), the client never receives anything:
```
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610219676288] DHCP4_BUFFER_RECEIVED received buffer from 127.1.2.3:6671 to 127.0.0.1:6672 over interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.options/657887.140610166056640] DHCP4_BUFFER_UNPACK parsing buffer received from 127.1.2.3 to 127.0.0.1 over interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_PACKET_RECEIVED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: DHCPDISCOVER (type 1) received from 127.1.2.3 to 127.0.0.1 on interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_QUERY_DATA [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1, packet details: local_address=127.0.0.1:6672, remote_address=127.1.2.3:6671, msg_type=DHCPDISCOVER (1), transid=0x
1,
options:
type=053, len=001: 1 (uint8)
type=060, len=015: "HTTPClient::7::" (string)
type=082, len=012:,
options:
type=001, len=004: 65:74:68:30
type=005, len=004: 172.16.42.1 (ipv4-address)
type=093, len=002: 0(uint16)
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_GENERIC Carbide: type=082, len=012:,
options:
type=001, len=004: 65:74:68:30
type=005, len=004: 172.16.42.1 (ipv4-address)
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_PKT4_RECEIVE: CIRCUIT ID [eth0] in packet
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_GENERIC Carbide: type=060, len=015: "HTTPClient::7::" (string)
2023-10-17 06:44:16.759 ERROR [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_PKT4_RECEIVE: Missing option [93] in packet
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7fe25b9f3ae3 (callout duration: 87.199 ms)
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 87.199 ms)
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 0.0.0.0/0 for packet received by matching address 172.16.42.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_SUBNET_SELECTED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: the subnet with ID 1 was selected for client assignments
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_SUBNET_DATA [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: the selected subnet details: 0.0.0.0/0
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=020000000001, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier circuit-id=65746830, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcp4/657887.140610166056640] DHCP4_CLASS_ASSIGNED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: client packet has been assigned to the following class(es): UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcp4/657887.140610166056640] DHCP4_CLASS_ASSIGNED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_HTTPClient::7::, UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.ddns/657887.140610166056640] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: processing client's Hostname option
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 02:00:00:00:00:01
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 0.0.0.1, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 1 and address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_BEGIN begin all callouts for hook lease4_select
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook lease4_select that has address 0x7fe25b9f4647 (callout duration: 0.007 ms)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_COMPLETE completed callouts for hook lease4_select (total callouts duration: 0.007 ms)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_HOOK_LEASE4_SELECT_SKIP Lease4 creation was skipped, because of callout skip flag.
```
... not sure what's supposed to happen at this point to prevent the WARN/ERROR of not having a lease ...
Then:
```
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to allocate an IPv4 lease in the subnet 0.0.0.0/0, subnet-id 1, shared network (none)
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to allocate an IPv4 address after 1 attempt(s)
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: Failed to allocate an IPv4 address for client with classes: ALL, VENDOR_CLASS_HTTPClient::7
::, UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.bad-packets/657887.140610166056640] DHCP4_PACKET_NAK_0003 [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to advertise a lease, client sent ciaddr 0.0.0.0, requested-ip-address (no address)
```
... no further output here ...kea2.6.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3103RADIUS realm config entry does nothing2023-11-09T15:41:47ZFrancis DupontRADIUS realm config entry does nothingFour possible solutions:
- to nothing (or put the ticket in Outstanding)
- add a note in ARM saying it is not yet supported
- remove it from the config
- implement it (i.e. adding @<realm> to all User-Name attributes)Four possible solutions:
- to nothing (or put the ticket in Outstanding)
- add a note in ARM saying it is not yet supported
- remove it from the config
- implement it (i.e. adding @<realm> to all User-Name attributes)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3102Possible bug for not pure option containers2023-10-13T23:32:53ZFrancis DupontPossible bug for not pure option containersHere the word pure means empty type, and container an option with sub-options. This ticket is from a dicussion in #2881 which fixed pure option containers.
The goal is to verify that toElement o parse gives back cvs-format and data entr...Here the word pure means empty type, and container an option with sub-options. This ticket is from a dicussion in #2881 which fixed pure option containers.
The goal is to verify that toElement o parse gives back cvs-format and data entries. If it is not the case Option::toBinary should be extended with a new parameter to not include sub-options.next-stable-2.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3100Support array of OPT_RECORD_TYPE for Option definition2024-01-09T11:40:57ZPiotrek ZadrogaSupport array of OPT_RECORD_TYPE for Option definitionWhile working on #3074 it occurred to me that it would be very useful to be able to define new Option as an array of OPT_RECORD_TYPE.
We could consider implementing that in Kea.While working on #3074 it occurred to me that it would be very useful to be able to define new Option as an array of OPT_RECORD_TYPE.
We could consider implementing that in Kea.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3098Effect of behavioural parameters when ddns is disabled:2024-03-27T12:58:34ZPeter DaviesEffect of behavioural parameters when ddns is disabled:
Effect of behavioural parameters when ddns is disabled:
There are a number of behavioural parameters which control what gets sent to d2.
Some settings also control what is returned to the client and saved as the host-
name in th...
Effect of behavioural parameters when ddns is disabled:
There are a number of behavioural parameters which control what gets sent to d2.
Some settings also control what is returned to the client and saved as the host-
name in the lease information.
Setting "dhcp-ddns.enable-updates": false turns off ddns, but some of these settings
remain active.
For example, the "ddns-qualifying-suffix" setting may affect hostnames even if
ddns are disabled. It has been brought to our attention that this is not clearly
documented in the ARM.
RT [#22818](https://support.isc.org/Ticket/Display.html?id=22818)
SF [#00001287](https://isc.lightning.force.com/lightning/r/Case/5007V00002XcaY4QAJ/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3096No error message when I apply a different subnet with the same subnet id2023-10-05T20:40:41ZSandeep GagalapallyNo error message when I apply a different subnet with the same subnet idHi,
I was testing the premium hook command "remote-subnet4-set" to see if there is way to let the user know that there is an existing subnet-id , what happens is if I add a new subnet with the same subnet-id which I used before it gets...Hi,
I was testing the premium hook command "remote-subnet4-set" to see if there is way to let the user know that there is an existing subnet-id , what happens is if I add a new subnet with the same subnet-id which I used before it gets replaced instead of throwing an error or message in response. How can make these records unique ?
For example. If I send this command first and then lets say if another user uses the same id '2' , the config is getting replaced.
```
{
"command": "remote-subnet4-set",
"service": [
"dhcp4"
],
"arguments": {
"subnets": [
{
"id": 2,
"subnet": "192.0.2.0/24",
"shared-network-name": "",
"pools": [
{
"pool": "192.0.2.100 - 192.0.2.200",
}
]
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"all"
]
}
}
```
Thank You,
Sandeepnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3094Support for IPv6-only networks with RFC 8925 (v6-only-preferred)2023-09-28T14:31:07ZBrian CandlerSupport for IPv6-only networks with RFC 8925 (v6-only-preferred)**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on ...**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on kea-users or kea-dev mailing lists? Yes: https://lists.isc.org/pipermail/kea-users/2023-July/004207.html
**Is your feature request related to a problem? Please describe.**
In APRICOT 2024 next year, there will be a separate IPv6-only wifi network (in parallel with the main conference SSID). There's nothing new about that.
However, this year we want to ensure that clients will gracefully fall back to IPv6-only operation *and* make use of a NAT64 device to access the IPv4-only Internet via the client's embedded CLAT. MacOS, Android and iOS support this mode of operation. Full details are in the article here: https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-networks/
In summary, these clients will request option 108 in their (DHCPv4) discover request. The server should respond with yiaddr 0.0.0.0 and option 108. The client will then activate their CLAT, as long as they also get the NAT64 prefix from a separate field (PREF64) in the RA's.
Running ISC-KEA or ISC-DHCPD for the DHCPv4 service doesn't currently work well here. Well, it *does* work for those clients which support option 108. But for clients which don't, they will be offered an IPv4 address, and will configure their interface with it. This is supposed to be an IPv6-only network, and hence we don't want machines to pick up an IPv4 address. They will find they have failing connectivity when they try to use their IPv4 address.
*Not* running a DHCPv4 server at all is not an option, because the clients won't enable their CLAT unless they've successfully done the option 108 dance.
**Describe the solution you'd like**
I would like KEA to implement the following:
- Allow IPv4 subnets to have no pool
- Allow IPv4 subnets to have a flag for enabling v6-preferred
- In such a subnet, if a client requests option 108, then return yiaddr 0.0.0.0 with option 108
- (Optionally: if I client sents option 116, then return yiaddr 0.0.0.0 with option 116)
- Otherwise, if there's no pool, then do whatever you'd normally do when the pool is exhausted (presumably either send no response, or send a NAK)
(Option 116 is RFC 2563: it also returns yiaddr 0.0.0.0. It lets you tell a client *not* to configure a global v4 address, and also to tell it whether or not to configure a link-local address. In principle, it could also reduce DHCPv4 discovery chatter in networks without v4. However I mark this support "optionally" because I've not actually found a client which makes use of this option yet)
**Describe alternatives you've considered**
There's a discussion in the list at https://lists.isc.org/pipermail/kea-users/2023-July/004207.html
The key thing I need to make sure is that *no* IPv4 address is returned to a client unless it requests option 108.
Note that the client doesn't actually *send* option 108, it puts 108 in its parameter request list, and it seems to be quite tricky to handle this in KEA. The best I could come up with was:
```
"client-classes": [
{
"name": "rfc8925",
// We need to test whether option 108 is in the client's parameter request list (option 55).
// That's not the same as "option[108].exists"
// https://kea.readthedocs.io/en/latest/arm/classify.html#using-expressions-in-classification
"test": "substring(option[55].hex, 0, 1) == 0x6c
or substring(option[55].hex, 1, 1) == 0x6c or substring(option[55].hex, 2, 1) == 0x6c
or substring(option[55].hex, 3, 1) == 0x6c or substring(option[55].hex, 4, 1) == 0x6c
or substring(option[55].hex, 5, 1) == 0x6c or substring(option[55].hex, 6, 1) == 0x6c
or substring(option[55].hex, 7, 1) == 0x6c or substring(option[55].hex, 8, 1) == 0x6c
or substring(option[55].hex, 9, 1) == 0x6c or substring(option[55].hex, 10, 1) == 0x6c
or substring(option[55].hex, 11, 1) == 0x6c or substring(option[55].hex, 12, 1) == 0x6c"
},
],
```
(it's ugly and incomplete - what if the client send more than 13 options?)
Then avoid sending any response to clients which *don't* provide this option:
```
"pools": [
{
// Only give OFFERs to devices which support RFC 8925
"pool": "10.12.65.2 - 10.12.65.254",
"client-class": "rfc8925"
}
],
"option-data": [
{
"name": "v6-only-preferred",
"data": "0"
}
],
```
That kind-of works. It's still not entirely RFC 8925 compliant as it *should* set the yiaddr to 0.0.0.0 (I couldn't see how to do that with the non-commercial plugins) and it *shouldn't* need to consume an address from the pool, although I can make that pool arbitrarily large.
As described before: the option of *not* running DHCPv4 service doesn't work, because the clients won't activate their CLAT without having received option 108.
What I have ended up doing is writing some custom DHCPv4 server modules for a standalone Go DHCP server:
https://github.com/coredhcp/coredhcp/pull/170
**Additional context**
This is a demonstration network at a conference, so it's not exactly "production" but more is a technology demonstrator of how well an IPv6-only network with NAT64 could work.
When I've tested this locally, I find that IPv4 access via the NAT64 works nicely, even when using IPv4 literals. For example, "ping 8.8.8.8" or browse to https://1.1.1.1 work fine (except from Safari). The traffic is actually IPv6 across to the NAT64. No DNS64 is required.
We'd like to demonstrate this so people can evaluate the feasibility of real deployment of single-stack IPv6 networks now or in the future.
**Funding its development**
Only in-kind development contributions
**Participating in development**
Yes, willing to contribute to discussions and/or testing.
**Contacting you**
brian@nsrc.orgnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3092Query to add subnet into mySQL backend2023-09-28T13:21:17ZSandeep GagalapallyQuery to add subnet into mySQL backendHello, I need some help with adding a v4 and v6 subnet into mySQL backend via a query instead of using the cb_command hook . I tried looking at several sources but no luck.
Can you please share any documentation for adding a subnet dire...Hello, I need some help with adding a v4 and v6 subnet into mySQL backend via a query instead of using the cb_command hook . I tried looking at several sources but no luck.
Can you please share any documentation for adding a subnet directly to mySQL backend ?
I am running kea 2.4.0 with mySQL schema version 19.0.
Thank You.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3090Move the krb5.conf config file in hammer2023-10-05T13:49:05ZFrancis DupontMove the krb5.conf config file in hammerWhen a Kerberos V library is installed a kerb5.conf config file is installed. Often it interferes with the gss_tig hook unit tests making some of them to fail. As documented in the ARM the default setting from this config file can be inc...When a Kerberos V library is installed a kerb5.conf config file is installed. Often it interferes with the gss_tig hook unit tests making some of them to fail. As documented in the ARM the default setting from this config file can be incompatible with these tests. The solution is to remove or rename it: this ticket is about doing this in hammer.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3082kea-ctrl-agent and dual stack listening2024-03-21T11:45:53ZDarren Ankneykea-ctrl-agent and dual stack listeningThe `kea-ctrl-agent` can presently only listen on one address, be that an IPv4 or IPv6 address. If you have a dual stack on the equipment where you want to listen, then you have to choose either the IPv4 or the IPv6 address to configure...The `kea-ctrl-agent` can presently only listen on one address, be that an IPv4 or IPv6 address. If you have a dual stack on the equipment where you want to listen, then you have to choose either the IPv4 or the IPv6 address to configure in the `kea-ctrl-agent.json`.
I propose to add a new parameter to the kea-ctrl-agent configuration "http-hosts" as shown:
```
{
"Control-agent": {
"http-hosts": [
"2001:db8::2",
"10.1.2.2"
],
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
This would allow listening on multiple IP addresses especially in a dual stack environment. Also, the new parameter would preserve backward compatibility.
FYI: I did solve this problem by running two copies of the `kea-ctrl-agent`. However, I'm not convinced that is a good solution. Configurations and other details included below for illustration.
<details><summary>kea-dhcp4.json</summary>
```
{
"Dhcp4": {
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
},
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100 - 10.1.2.254"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "INFO",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>kea-ctrl-agent-v4.json</summary>
```
{
"Control-agent": {
"http-host": "10.1.2.2",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
</details>
<details><summary>kea-ctrl-agent-v6.json</summary>
```
{
"Control-agent": {
"http-host": "2001:db8::2",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
</details>
<details><summary>Configuration of ens256</summary>
```
3: ens256: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:c0:5f:47 brd ff:ff:ff:ff:ff:ff
altname enp26s0
inet 10.1.2.2/24 brd 10.1.2.255 scope global ens256
valid_lft forever preferred_lft forever
inet6 2001:db8::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fec0:5f47/64 scope link
valid_lft forever preferred_lft forever
```
</details>
<details><summary>Daemon command lines</summary>
```
kea-dhcp4 -c kea-dhcp4.json
```
```
kea-ctrl-agent -c kea-ctrl-agent-v4.json
```
```
kea-ctrl-agent -c kea-ctrl-agent-v6.json
```
</details>
<details><summary>Send config-get with curl to both</summary>
```
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://10.1.2.2:8000/ | jq
```
```
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://[2001:db8::2]:8000/
```
</details>
Both returned a result successfully.
[SF1260](https://isc.lightning.force.com/lightning/r/Case/5007V00002X2x4cQAB/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3064performance drop during 2.3 release cycle for mysql2023-09-21T13:53:17ZWlodzimierz Wencelperformance drop during 2.3 release cycle for mysqlWe observed huge performance drop during 2.3 release cycle, Exactly between 2.3.8 and 2.3.9
![Screenshot_2023-09-14_at_09.55.50](/uploads/06cdfb127f6609246e68c58d63663a2e/Screenshot_2023-09-14_at_09.55.50.png)
![Screenshot_2023-09-14_at...We observed huge performance drop during 2.3 release cycle, Exactly between 2.3.8 and 2.3.9
![Screenshot_2023-09-14_at_09.55.50](/uploads/06cdfb127f6609246e68c58d63663a2e/Screenshot_2023-09-14_at_09.55.50.png)
![Screenshot_2023-09-14_at_09.57.01](/uploads/d9fb7fbabb11d49faa3e40efbd6f4bac/Screenshot_2023-09-14_at_09.57.01.png)
Please check [report on master](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html), during this work I was testing migration to binary addresses in mysql and this did not show performance degradation in [the report](https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/performance/108/artifact/qa-dhcp/kea/performance-jenkins/report.html)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3062Any interface created while retrying sockets are used unfiltered2024-02-08T14:35:31ZEfe Can İçözAny interface created while retrying sockets are used unfiltered
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in conf...
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in configuration file.
**To Reproduce**
Steps to reproduce the behavior:
1. Set a dummy interface and ensure that it's down.
`ip link add dummy0 type dummy`
`ip addr add 192.168.1.1/24 dev dummy0`
`ip link set dummy0 down`
2. Run Kea dhcp4 server with the following config
{
"Dhcp4": {
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"interfaces-config": {
"interfaces": [ "dummy0/192.168.1.1" ],
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 1000
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/dhcp4.leases"
},
"subnet4": [
{
"subnet": "192.168.1.0/24",
"interface": "dummy0",
"pools": [
{
"pool": "192.168.1.4 - 192.168.1.254",
}
]
}
]
}
}
3. At this point Kea will print `DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface dummy0 is down` messages.
4. Add another interface with
`ip link add dummy1 type dummy`
`ip addr add 10.10.1.1/24 dev dummy1`
`ip link set dummy1 up`
5. Set dummy0 online to let Kea run
`ip link set dummy1 up`
6. Check open sockets by Kea
`netstat -tulpan | grep kea` which is
udp 0 0 192.168.1.1:67 0.0.0.0:* 694387/kea-dhcp4
udp 0 0 10.10.1.1:67 0.0.0.0:* 694387/kea-dhcp4
**Expected behavior**
Server should only listen _dummy0_ interface.
**Environment:**
- Kea version: 2.2.0
- OS: Ubuntu 22.04.3 x64
**Additional Information**
This issue happened also on our custom yocto build on imx8qxp with aarch64next-stable-2.6