Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-22T09:52:31Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3294Deletion of v6 reservation over API by address causes all v6 reservations to ...2024-03-22T09:52:31ZAndrew MulheirnDeletion of v6 reservation over API by address causes all v6 reservations to disappear---
name: Deletion of v6 reservation over API by address causes all v6 reservations to disappear
about: Kea 2.4.1
---
**Describe the bug**
I am using the API to add and remove reservations for v4 and v6.
I find that removing a v4 re...---
name: Deletion of v6 reservation over API by address causes all v6 reservations to disappear
about: Kea 2.4.1
---
**Describe the bug**
I am using the API to add and remove reservations for v4 and v6.
I find that removing a v4 reservation by IP address works as expected, but removing a v6 reservation results in all reservations being deleted.
**To Reproduce**
Steps to reproduce the behavior:
1. Create two v6 reservations in the database
2. send a 'reservation-del' to the dhcp6 process via the API to remove one address
3. run a 'reservation-get-all' and receive the message ```"text": "0 IPv6 host(s) found."```
4. Perform the same sequence with v4 and it succeeds
5. Check the postgres database contents and see that the v6 reservations table is empty
Note that if I do a deletion specifying the flex-id or DUID of a reservation, only that single reservation is removed.
**Expected behavior**
I am expecting that a single IPv6 reservation is deleted.
**Environment:**
- Kea version: 2.4.1
- OS: Ubuntu 22.04.4 LTS
- Installed from kea packages on cloudsmith
- Flex-id, HA, host commands and lease commands are in use.
**Additional Information**
reservation-get-all result over api:
```
[
{
"arguments": {
"hosts": [
{
"client-classes": [],
"flex-id": "67622D6C6F6E39382D7273773030313A78652D302F302F33",
"hostname": "123123.vorboss.lab",
"ip-addresses": [
"2a00:e340:1102::3"
],
"option-data": [],
"prefixes": [
"2a00:e340:1103:300::/56"
],
"subnet-id": 1
},
{
"client-classes": [],
"flex-id": "67622D6C6F6E39382D7273773030313A78652D302F302F34",
"hostname": "123124.vorboss.lab",
"ip-addresses": [
"2a00:e340:1102::4"
],
"option-data": [],
"prefixes": [
"2a00:e340:1103:400::/56"
],
"subnet-id": 1
}
]
},
"result": 0,
"text": "2 IPv6 host(s) found."
}
]
```
Deletion sent:
```
{
"command": "reservation-del",
"service": ["dhcp6"],
"arguments": {
"subnet-id": 1,
"ip-address": "2a00:e340:1102::4"
}
}
```
Debug from kea-ctrl-agent:
```
INFO COMMAND_RECEIVED Received command 'reservation-del'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_del
INFO HOST_CMDS_RESERV_DEL reservation-del command called (parameters: { "ip-address": "2a00:e340:1102::4", "subnet-id": 1 })
INFO HOST_CMDS_RESERV_DEL_SUCCESS reservation-del command success (parameters: { "ip-address": "2a00:e340:1102::4", "subnet-id": 1 })
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook $reservation_del that has address 0x7ff2f67cecb0 (callout duration: 3.743 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_del (total callouts duration: 3.743 ms)
```
Subsequent reservation-get-all:
```
[
{
"arguments": {
"hosts": []
},
"result": 3,
"text": "0 IPv6 host(s) found."
}
]
```
**Contacting you**
My work email is andrew.mulheirn@vorboss.comkea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3276Kea primary server in "passive backup" freeze/crash on receiving ha-sync2024-03-28T10:34:28ZMarcin GodzinaKea primary server in "passive backup" freeze/crash on receiving ha-syncKea HA server set as `primary` freezes after receiving `ha-sync` command with proper arguments.
The backup server does NOT crash.
Freeze occurs only in `passive-backup` mode.
The problem exists in both v4 and v6. Also, in Memfile and m...Kea HA server set as `primary` freezes after receiving `ha-sync` command with proper arguments.
The backup server does NOT crash.
Freeze occurs only in `passive-backup` mode.
The problem exists in both v4 and v6. Also, in Memfile and mysql/psql lease database.
**Kea versions tested:**
- 2.5.7-git 8c1f22e3fb65225a0279606a8a65962850a5f881
- 2.4.0 release tarball
**Tested systems:**
- Fedora 38 in VM on my local setup.
- Ubuntu 22.04, Alpine 3.16, Fedora 36 on Jenkins build farm.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea HA servers in **Passive backup** configuration (tested configuration provided)
2. Wait for servers to connect.
3. Optionally add leases (crashes either way)
4. Send the `ha-sync` command with proper arguments to the primary server. (`"server-name": "server2"` for provided configuration) (Invalid arguments respond with error)
The primary server freezes after receiving a response to the `dhcp-disable` command, sent automatically to the backup server. It does not respond to kea-ctrl agent, keyboard interrupts or SIGHUP
<details><summary>Commands tested to freeze provided config:</summary>
```
{
command": "ha-sync",
"arguments": {
"server-name": "server2"
}
}
```
```
{
command": "ha-sync",
"arguments": {
"server-name": "server1"
}
}
```
```
{
command": "ha-sync",
"arguments": {
"server-name": "server2",
"max-period": 60
}
}
```
</details>
**Configuration**
<details><summary>Primary</summary>
```
{
"Dhcp4": {
"option-data": [],
"hooks-libraries": [
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"peers": [
{
"auto-failover": true,
"name": "server1",
"role": "primary",
"url": "http://192.168.56.102:8003/"
},
{
"auto-failover": true,
"name": "server2",
"role": "backup",
"url": "http://192.168.56.103:8003/"
}
],
"state-machine": {
"states": []
},
"mode": "passive-backup",
"this-server-name": "server1",
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
}
}
]
}
},
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [],
"subnet4": [
{
"subnet": "192.168.50.0/24",
"pools": [
{
"pool": "192.168.50.1-192.168.50.200"
}
],
"interface": "enp0s9"
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/home/mgodzina/installed/keadev/var/run/kea/control_socket"
},
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "/home/mgodzina/installed/keadev/var/log/kea.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"lease-database": {
"type": "memfile"
}
}
}
```
</details>
<details><summary>Backup</summary>
```
{
"Dhcp4": {
"option-data": [],
"hooks-libraries": [
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"peers": [
{
"auto-failover": true,
"name": "server1",
"role": "primary",
"url": "http://192.168.56.102:8003/"
},
{
"auto-failover": true,
"name": "server2",
"role": "backup",
"url": "http://192.168.56.103:8003/"
}
],
"state-machine": {
"states": []
},
"mode": "passive-backup",
"this-server-name": "server2",
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
}
}
]
}
},
{
"library": "/home/mgodzina/installed/keadev/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [],
"subnet4": [
{
"subnet": "192.168.50.0/24",
"pools": [
{
"pool": "192.168.50.1-192.168.50.200"
}
],
"interface": "enp0s9"
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/home/mgodzina/installed/keadev/var/run/kea/control_socket"
},
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "/home/mgodzina/installed/keadev/var/log/kea.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"lease-database": {
"type": "memfile"
}
}
}
```
</details>
**Logs**
<details><summary>Primary server log tail</summary>
```
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.commands/2096.139741364354944] COMMAND_SOCKET_CONNECTION_OPENED Opened socket 38 for incoming command connection
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.commands/2096.139741364354944] COMMAND_SOCKET_READ Received 127 bytes over command socket 38
2024-02-28 16:20:13.417 INFO [kea-dhcp4.commands/2096.139741364354944] COMMAND_RECEIVED Received command 'ha-sync'
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.callouts/2096.139741364354944] HOOKS_CALLOUTS_BEGIN begin all callouts for hook $ha_sync
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_CLIENT_REQUEST_SEND sending HTTP request POST / HTTP/1.1 to http://192.168.56.103:8003/
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_CLIENT_REQUEST_SEND_DETAILS detailed information about request sent to http://192.168.56.103:8003/:
POST / HTTP/1.1
Host: 192.168.56.103
Content-Length: 86
Content-Type: application/json
{ "arguments": { "origin": 2000 }, "command": "dhcp-disable", "service": [ "dhcp4" ] }
2024-02-28 16:20:13.417 INFO [kea-dhcp4.ha-hooks/2096.139741364354944] HA_SYNC_START server1: starting lease database synchronization with server2
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_SERVER_RESPONSE_RECEIVED received HTTP response from http://192.168.56.103:8003/
2024-02-28 16:20:13.417 DEBUG [kea-dhcp4.http/2096.139741364354944] HTTP_SERVER_RESPONSE_RECEIVED_DETAILS detailed information about well-formed response received from http://192.168.56.103:8003/:
HTTP/1.1 200 OK
Content-Length: 54
Content-Type: application/json
Date: Wed, 28 Feb 2024 15:20:13 GMT
[ { "result": 0, "text": "DHCPv4 service disabled" } ]
```
</details>
<details><summary>Backup server log snippet with timeout:</summary>
```
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_REQUEST_RECEIVE_START start receiving request from 192.168.56.102 with timeout 10
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_DATA_RECEIVED received 179 bytes from 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_CLIENT_REQUEST_RECEIVED received HTTP request from 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_CLIENT_REQUEST_RECEIVED_DETAILS detailed information about well-formed request received from 192.168.56.102:
POST / HTTP/1.1
Host: 192.168.56.103
Content-Length: 86
Content-Type: application/json
{ "arguments": { "origin": 2000 }, "command": "dhcp-disable", "service": [ "dhcp4" ] }
2024-02-28 16:20:13.413 INFO [kea-dhcp4.commands/20519.140151306917568] COMMAND_RECEIVED Received command 'dhcp-disable'
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUTS_BEGIN begin all callouts for hook command_processed
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook command_processed that has address 0x7f778767ffe0 (callout duration: 0.000 ms)
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.callouts/20519.140151306917568] HOOKS_CALLOUTS_COMPLETE completed callouts for hook command_processed (total callouts duration: 0.000 ms)
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_SERVER_RESPONSE_SEND sending HTTP response HTTP/1.1 200 OK to 192.168.56.102
2024-02-28 16:20:13.413 DEBUG [kea-dhcp4.http/20519.140151306917568] HTTP_SERVER_RESPONSE_SEND_DETAILS detailed information about response sent to 192.168.56.102:
HTTP/1.1 200 OK
Content-Length: 54
Content-Type: application/json
Date: Wed, 28 Feb 2024 15:20:13 GMT
[ { "result": 0, "text": "DHCPv4 service disabled" } ]
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:17.831 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.033 ms
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:17.832 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
2024-02-28 16:20:21.840 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.032 ms
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:27.852 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:37.891 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.027 ms
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.alloc-engine/20519.140151383601024] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2024-02-28 16:20:37.892 DEBUG [kea-dhcp4.dhcpsrv/20519.140151383601024] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2024-02-28 16:20:43.433 DEBUG [kea-dhcp4.http/20519.140151315310272] HTTP_IDLE_CONNECTION_TIMEOUT_OCCURRED closing persistent connection with 192.168.56.102 as a result of a timeout
2024-02-28 16:20:43.433 DEBUG [kea-dhcp4.http/20519.140151315310272] HTTP_CONNECTION_STOP stopping HTTP connection from 192.168.56.102
```
</details>
[gdb.txt](/uploads/de79e56462885f7947eab90267f7a658/gdb.txt)kea2.5.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3251Fix drop statistics in subnet6_select and RADIUS hook2024-03-07T14:55:13ZFrancis DupontFix drop statistics in subnet6_select and RADIUS hookThe pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.The pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3200Kea unable to remove pid file on exit when installed via rpm2024-03-28T12:35:45ZWlodzimierz WencelKea unable to remove pid file on exit when installed via rpmjournal:
```
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO HOSTS_BACKENDS_REGISTERED the following host backend ...journal:
```
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCP6_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always perfo>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: 2001:db8:1::/64 with params: t1=1000, >
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea6-ctrl-socket
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_CONFIG_COMPLETE DHCPv6 server has completed configuration: added IPv6 subnets: 1; DDNS: disabled
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600 type=memfile universe=6
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases6.csv
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_BUILD_EXTENDED_INFO_TABLES6 building extended info tables saw 0 leases, extended info sanity ch>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_USING_SERVERID server is using server-id 00:01:00:01:2d:21:94:f1:0e:90:95:e1:82:d1 and stores in the file>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_NA leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_TA leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_PD leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCP6_MULTI_THREADING_INFO enabled: yes, number of threads: 4, queue size: 64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_STARTED Kea DHCPv6 server version 2.5.5 started
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal systemd[1]: Stopping kea-dhcp6.service - Kea DHCPv6 Service...
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_SHUTDOWN server shutdown
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: terminate called after throwing an instance of 'isc::util::PIDFileError'
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: what(): Unable to delete PID file '/run/kea/kea-dhcp6.kea-dhcp6.pid'
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=dumped, status=6/ABRT
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'core-dump'.
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: Stopped kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12118]: kea-dhcp6.service: Failed to set up special execution directory in /run: Permission denied
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12118]: kea-dhcp6.service: Failed at step RUNTIME_DIRECTORY spawning /usr/sbin/kea-dhcp6: Permission denied
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=exited, status=233/RUNTIME_DIRECTORY
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'exit-code'.
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12857]: kea-dhcp6.service: Failed to set up special execution directory in /run: Permission denied
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12857]: kea-dhcp6.service: Failed at step RUNTIME_DIRECTORY spawning /usr/sbin/kea-dhcp6: Permission denied
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=exited, status=233/RUNTIME_DIRECTORY
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'exit-code'.
```
probably packaging issue but it's up for investigation.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3197tftp-server-name (option 66) and boot-file-name (option 67)2024-01-11T14:56:42ZGavin McKeetftp-server-name (option 66) and boot-file-name (option 67)Hi,
Kea DHCPv4 server version 2.5.4
I am trying to provide a list of tftp servers and boot file names according to the ZTP requirements of MLXOS (Nvidia Infiniband switches)
https://docs.nvidia.com/networking/display/mlnxosv3111014/ge...Hi,
Kea DHCPv4 server version 2.5.4
I am trying to provide a list of tftp servers and boot file names according to the ZTP requirements of MLXOS (Nvidia Infiniband switches)
https://docs.nvidia.com/networking/display/mlnxosv3111014/getting+started#src-138809553_GettingStarted-RunningDHCP-ZTP
They state, that I must provide options in the following format.
```
option tftp-server-name "<image server url>, <config server url>, <docker container server url>";
option bootfile-name "<image file>, <config file>, <docker container file>";
```
When I define the Option config as follows
```
"option-data": [
{
// For each IPv4 subnet you most likely need to specify at
// least one router.
"name": "routers",
"data": "172.25.40.1"
},
{
"name": "domain-name-servers",
"data": "8.8.8.8"
},
{
"name": "cumulus-provision-url",
"data": "http://172.25.43.23:8080/scripts/nvue-ztp.py"
},
{
"name": "tftp-server-name",
"csv-format": true,
"data": "http://172.25.43.23:8080/mlxos,http://172.25.43.23:8080/configs/ib/,",
"space": "dhcp4"
},
{
"name": "boot-file-name",
"csv-format": true,
"data": "image-X86_64-3.11.1014.img,ib-config.conf,",
"space": "dhcp4"
}
]#
```
I only ever see the following offer on the wire, i.e the first URL and first file name.
![image](/uploads/1d85bf46828cc9fdcc58d3215ede969b/image.png)
I've exhasuitvely to override the Option definition, trying with type=record and record-types="string,string,string" nothing I do works.
Can someone advise if this is a bug? Or if there is a way to do this in Kea.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3196Thread sanitizer warnings with std::bind2024-03-29T11:09:29ZMarcin SiodelskiThread sanitizer warnings with std::bindI ran a DHCPv4 server compiled with a thread sanitizer, and I got the following sporadic failure:
```
==================
WARNING: ThreadSanitizer: data race (pid=95142)
Write of size 8 at 0x7b0c0000c220 by main thread:
#0 operator ...I ran a DHCPv4 server compiled with a thread sanitizer, and I got the following sporadic failure:
```
==================
WARNING: ThreadSanitizer: data race (pid=95142)
Write of size 8 at 0x7b0c0000c220 by main thread:
#0 operator delete(void*, unsigned long) ../../../../src/libsanitizer/tsan/tsan_new_delete.cpp:150 (libtsan.so.0+0x8e878)
#1 std::_Function_base::_Base_manager<std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)> >::_M_destroy(std::_Any_data&, std::integral_constant<bool, false>) /usr/include/c++/11/bits/std_function.h:175 (kea-dhcp4+0xbe1ab)
#2 std::_Function_base::_Base_manager<std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)> >::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation) /usr/include/c++/11/bits/std_function.h:203 (kea-dhcp4+0xbe1ab)
#3 std::_Function_handler<void (), std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)> >::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation) /usr/include/c++/11/bits/std_function.h:282 (kea-dhcp4+0xbe1ab)
#4 std::_Function_base::~_Function_base() /usr/include/c++/11/bits/std_function.h:244 (kea-dhcp4+0xbccd2)
#5 std::function<void ()>::~function() /usr/include/c++/11/bits/std_function.h:334 (kea-dhcp4+0xbccd2)
#6 boost::detail::sp_ms_deleter<std::function<void ()> >::destroy() /usr/include/boost/smart_ptr/make_shared_object.hpp:59 (kea-dhcp4+0xbccd2)
#7 boost::detail::sp_ms_deleter<std::function<void ()> >::operator()(std::function<void ()>*) /usr/include/boost/smart_ptr/make_shared_object.hpp:93 (kea-dhcp4+0xbccd2)
#8 boost::detail::sp_counted_impl_pd<std::function<void ()>*, boost::detail::sp_ms_deleter<std::function<void ()> > >::dispose() /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:169 (kea-dhcp4+0xbccd2)
#9 boost::detail::sp_counted_base::release() /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_atomic.hpp:120 (kea-dhcp4+0x5420a)
#10 boost::detail::shared_count::~shared_count() /usr/include/boost/smart_ptr/detail/shared_count.hpp:432 (kea-dhcp4+0xb845a)
#11 boost::shared_ptr<std::function<void ()> >::~shared_ptr() /usr/include/boost/smart_ptr/shared_ptr.hpp:335 (kea-dhcp4+0xb845a)
#12 isc::dhcp::Dhcpv4Srv::runOne() /home/marcin/devel/kea/src/bin/dhcp4/dhcp4_srv.cc:1113 (kea-dhcp4+0xb845a)
#13 isc::dhcp::Dhcpv4Srv::run() /home/marcin/devel/kea/src/bin/dhcp4/dhcp4_srv.cc:1023 (kea-dhcp4+0xb87b7)
#14 main /home/marcin/devel/kea/src/bin/dhcp4/main.cc:282 (kea-dhcp4+0x5082a)
Previous read of size 8 at 0x7b0c0000c220 by thread T6:
#0 boost::shared_ptr<isc::hooks::CalloutHandle> isc::dhcp::getCalloutHandle<boost::shared_ptr<isc::dhcp::Pkt4> >(boost::shared_ptr<isc::dhcp::Pkt4> const&) ../../../src/lib/dhcpsrv/callout_handle_store.h:50 (kea-dhcp4+0xb7f7d)
#1 isc::dhcp::Dhcpv4Srv::processPacketAndSendResponse(boost::shared_ptr<isc::dhcp::Pkt4>&) /home/marcin/devel/kea/src/bin/dhcp4/dhcp4_srv.cc:1139 (kea-dhcp4+0xb7f7d)
#2 isc::dhcp::Dhcpv4Srv::processPacketAndSendResponseNoThrow(boost::shared_ptr<isc::dhcp::Pkt4>&) /home/marcin/devel/kea/src/bin/dhcp4/dhcp4_srv.cc:1122 (kea-dhcp4+0xb88c7)
#3 void std::__invoke_impl<void, void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&>(std::__invoke_memfun_deref, void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&) /usr/include/c++/11/bits/invoke.h:74 (kea-dhcp4+0xba3c9)
#4 std::__invoke_result<void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&>::type std::__invoke<void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&>(void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&) /usr/include/c++/11/bits/invoke.h:96 (kea-dhcp4+0xba3c9)
#5 void std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>::__call<void, , 0ul, 1ul>(std::tuple<>&&, std::_Index_tuple<0ul, 1ul>) /usr/include/c++/11/functional:420 (kea-dhcp4+0xba3c9)
#6 void std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>::operator()<, void>() /usr/include/c++/11/functional:503 (kea-dhcp4+0xba3c9)
#7 void std::__invoke_impl<void, std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&>(std::__invoke_other, std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&) /usr/include/c++/11/bits/invoke.h:61 (kea-dhcp4+0xba3c9)
#8 std::enable_if<is_invocable_r_v<void, std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&>, void>::type std::__invoke_r<void, std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&>(std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&) /usr/include/c++/11/bits/invoke.h:111 (kea-dhcp4+0xba3c9)
#9 std::_Function_handler<void (), std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)> >::_M_invoke(std::_Any_data const&) /usr/include/c++/11/bits/std_function.h:290 (kea-dhcp4+0xba3c9)
#10 std::function<void ()>::operator()() const /usr/include/c++/11/bits/std_function.h:590 (libkea-util.so.80+0x3ef83)
#11 isc::util::ThreadPool<std::function<void ()>, std::deque<boost::shared_ptr<std::function<void ()> >, std::allocator<boost::shared_ptr<std::function<void ()> > > > >::run() ../../../src/lib/util/thread_pool.h:599 (libkea-util.so.80+0x3ef83)
Thread T6 (tid=95149, running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:969 (libtsan.so.0+0x605b8)
#1 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) <null> (libstdc++.so.6+0xdc328)
#2 isc::dhcp::ControlledDhcpv4Srv::processCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::shared_ptr<isc::data::Element const>) /home/marcin/devel/kea/src/bin/dhcp4/ctrl_dhcp4_srv.cc:861 (kea-dhcp4+0x666f8)
#3 isc::dhcp::ControlledDhcpv4Srv::loadConfigFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/marcin/devel/kea/src/bin/dhcp4/ctrl_dhcp4_srv.cc:163 (kea-dhcp4+0x6732b)
#4 isc::dhcp::ControlledDhcpv4Srv::init(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/marcin/devel/kea/src/bin/dhcp4/ctrl_dhcp4_srv.cc:99 (kea-dhcp4+0x677fb)
#5 main /home/marcin/devel/kea/src/bin/dhcp4/main.cc:253 (kea-dhcp4+0x507e5)
SUMMARY: ThreadSanitizer: data race ../../../../src/libsanitizer/tsan/tsan_new_delete.cpp:150 in operator delete(void*, unsigned long)
==================
```
It looks that it may be related to using references to shared pointers in the functions passed to std::bind. Removing the reference seems to solve the problem. For example:
```patch
diff --git a/src/bin/dhcp4/dhcp4_srv.cc b/src/bin/dhcp4/dhcp4_srv.cc
index 612e8aa58b..f949015c04 100644
--- a/src/bin/dhcp4/dhcp4_srv.cc
+++ b/src/bin/dhcp4/dhcp4_srv.cc
@@ -1117,7 +1117,7 @@ Dhcpv4Srv::runOne() {
}
void
-Dhcpv4Srv::processPacketAndSendResponseNoThrow(Pkt4Ptr& query) {
+Dhcpv4Srv::processPacketAndSendResponseNoThrow(Pkt4Ptr query) {
try {
processPacketAndSendResponse(query);
} catch (const std::exception& e) {
diff --git a/src/bin/dhcp4/dhcp4_srv.h b/src/bin/dhcp4/dhcp4_srv.h
index 0ed55adfe5..0507d73ab5 100644
--- a/src/bin/dhcp4/dhcp4_srv.h
+++ b/src/bin/dhcp4/dhcp4_srv.h
@@ -352,7 +352,7 @@ public:
/// methods, generates appropriate answer, sends the answer to the client.
///
/// @param query A pointer to the packet to be processed.
- void processPacketAndSendResponseNoThrow(Pkt4Ptr& query);
+ void processPacketAndSendResponseNoThrow(Pkt4Ptr query);
/// @brief Process an unparked DHCPv4 packet and sends the response.
///
```
However, we should probably go over all similar cases, not only this one. I've seen similar issues with other functions.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3195Modifying pools using the subnetX_update commands does not update statistics2024-03-27T16:11:27ZMarcin SiodelskiModifying pools using the subnetX_update commands does not update statisticsI tested the latest addition to Stork - pools management. I had a subnet without pools initially. I added some address pools to the subnet and saved the changes. It results in sending `subnet4_update` followed by `config-write`. The stat...I tested the latest addition to Stork - pools management. I had a subnet without pools initially. I added some address pools to the subnet and saved the changes. It results in sending `subnet4_update` followed by `config-write`. The statistics (in particular `total-addresses` counter) has not been changed to reflect the new pools capacity. I am able to force recounting the statistics by sending the `config-reload` command, but that's not how it is supposed to work.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3179kea fails to log to syslog if run as non-root user2024-03-22T13:43:03ZLars Wendlerkea fails to log to syslog if run as non-root userWith the following config snippet
```
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [ { "output": "syslog" } ],
"severity": "INFO",
...With the following config snippet
```
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [ { "output": "syslog" } ],
"severity": "INFO",
"debuglevel": 0
}
]
```
kea won't log to syslog service once it's being started as non-root user. Simply starting kea as root makes it successfully log to syslog.
I am using the following syslogger: [sysklogd-2.4.4](https://github.com/troglobit/sysklogd)
I have found this problem being present in kea-2.4.1 and kea-2.5.4 and only tested the dhcp4 component of kea.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3176Kea disables logging if configured without an `output-options`2023-11-30T14:32:43ZAndrei Pavelandrei@isc.orgKea disables logging if configured without an `output-options`To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dh...To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
}
```
Or set the same configuration through unix socket or kea-ctrl-agent (maybe while still preserving the control-socket, that's why it's there):
```json
{
"arguments": {
"Dhcp6": {
"control-socket": {
"socket-name": "/tmp/kea-dhcp6-ctrl.sock",
"socket-type": "unix"
},
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
},
"command": "config-set",
"service": [
"dhcp6"
]
}
```
You get this and no more logging after that.
```
log4cplus:ERROR No appenders could be found for logger (kea-dhcp6.hosts).
log4cplus:ERROR Please initialize the log4cplus system properly.
```
This contradicts the ARM which says:
> Each logger can have zero or more `output-options`.
It replicates with subloggers too. Only the sublogger is affected in that case.
You can have `interfaces-config` and `subnet6` and anything else besides it.
DHCP traffic works. Commands work. Logging does not.
It also replicates on `kea-dhcp4`.
There is the workaround of reconfiguring with `output-options`. Logging recovers after that.
Also found a typo in the ARM: `output_commands` should be `output-options`.
Suggested actions:
* [ ] Make logging work when `output-options` is not configured with the documented default of `stdout` as output option.
* [ ] Fix the typo in the ARM: `output_commands` should be `output-options`.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.6https://gitlab.isc.org/isc-projects/kea/-/issues/3040failure to start up with ppp interfaces2024-02-08T14:35:31ZJaco Kroonfailure to start up with ppp interfaces2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed...2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed to bind socket 20 to fe80::e/port=547: Cannot assign requested address
```
26: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1350 qdisc tbf state UNKNOWN group default qlen 3
inet6 fe80::14e4:139f:8862:3dfd peer fe80::e/128 scope link
valid_lft forever preferred_lft forever
```
Obviously we should bind to the local link-local, not the remote one.
kea 2.4.0. 2.5.1 segfaults on my configuration:
```
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "ppp0" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/run/kea/kea6-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"option-data": [
{
"name": "dns-servers",
"data": "2c0f:f720::..., 2c0f:f720::..."
}
],
"subnet6": [
{
"subnet": "2c0f:f720:fcf0::/44",
"pd-pools": [
{
"prefix": "2c0f:f720:fcf0::",
"prefix-len": 44,
"delegated-len": 56
}
]
}
],
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea/kea-dhcp6.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
```
Strace from a re-run (so socket number is different):
```
bind(19, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
getsockname(19, {sa_family=AF_NETLINK, nl_pid=6688, nl_groups=00000000}, [12]) = 0
sendto(19, [{nlmsg_len=20, nlmsg_type=RTM_GETLINK, nlmsg_flags=NLM_F_REQUEST|NLM_F_DUMP, nlmsg_seq=1, nlmsg_pid=0}, {ifi_family=AF_PACKET, ...}], 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
recvmsg(19, {msg_name={sa_family=AF_NETLINK ...
ifa_index=if_nametoindex("ppp0")}, [[{nla_len=20, nla_type=IFA_LOCAL}, **inet_pton(AF_INET6, "fe80::14e4:139f:8862:3dfd")], [{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "fe80::e")],** [{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=168714876, tstamp=168714876}], [{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT]]], [{nlmsg_len=72, nlmsg_type=RTM_NEWADDR, nlmsg_flags=NLM_F_MULTI, nlmsg_seq=2, nlmsg_pid=6688}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK,
...
close(19) = 0
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 19
ioctl(19, SIOCGIFINDEX, {ifr_name="ppp0", ifr_ifindex=26}) = 0
close(19) = 0
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 19
fcntl(19, F_SETFD, FD_CLOEXEC) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(19, {sa_family=AF_INET6, sin6_port=htons(547), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "**fe80::e**", &sin6_addr), sin6_scope_id=if_nametoindex("ppp0")}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
close(19) = 0
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3000DHCPv4 - 2.4.0 segfault vol22024-03-22T13:05:43ZVecínoDHCPv4 - 2.4.0 segfault vol2**Describe the bug**
The dmesg shows the segfault errors. I have already addressed this issue here: https://gitlab.isc.org/isc-projects/kea/-/issues/2997 version 2.2.0 but I switched to the newer 2.4.0 ... the error occurs less frequentl...**Describe the bug**
The dmesg shows the segfault errors. I have already addressed this issue here: https://gitlab.isc.org/isc-projects/kea/-/issues/2997 version 2.2.0 but I switched to the newer 2.4.0 ... the error occurs less frequently, but still is here. :disappointed:
```
Aug 01 07:00:25 router kernel: kea-lfc[21463]: segfault at 7f50dc000020 ip 00007f50eecaa170 sp 00007f50ed6c6db0 error 6 likely on CPU 1 (core 6, socket 0)
Aug 01 07:00:25 router kernel: Code: ee 48 89 df e8 b1 f3 06 00 85 c0 0f 85 41 01 00 00 48 8b 05 4a 71 14 00 48 83 e8 01 48 39 e8 0f 82 b5 00 00 00 66 0f 6f 0c 24 <4c> 89 6b 20 0f 11 4b 10 90 48 83 c4 18 48 89 d8 5b 5d 41 5c 41 5d
Aug 01 17:00:31 router kernel: kea-lfc[22122]: segfault at 7f22b8000020 ip 00007f22cfaaa170 sp 00007f22ce4c6db0 error 6 likely on CPU 3 (core 12, socket 0)
Aug 01 17:00:31 router kernel: Code: ee 48 89 df e8 b1 f3 06 00 85 c0 0f 85 41 01 00 00 48 8b 05 4a 71 14 00 48 83 e8 01 48 39 e8 0f 82 b5 00 00 00 66 0f 6f 0c 24 <4c> 89 6b 20 0f 11 4b 10 90 48 83 c4 18 48 89 d8 5b 5d 41 5c 41 5d
```
**Environment:**
* Kea version: 2.4.0-2 - https://archlinux.org/packages/extra-testing/x86_64/kea/
* OS: Arch Linux x64, 6.1.39-2-lts
**Debugging:**
I am very sorry to provide you with some valuable information. I tried to do the debugging - https://bbs.archlinux.org/viewtopic.php?id=287607 , but I'm an inexperienced user and don't know how to do it. I'm sorry.
https://wiki.archlinux.org/title/Debugging/Getting_traces#Getting_the_trace
[kea-dhcp4.conf](/uploads/dc7b2d987cae6ad94682e975e8428a1a/kea-dhcp4.conf)
@razvankea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2957dhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on...2024-03-22T13:05:49ZJohn W. O'Briendhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on dhcp6_server table---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the b...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the behavior:
1. Initialize a PostgreSQL database using dhcpdb_create.pgsql
2. Inspect the dhcp4_server_modification_ts index
3. See that it is associated with the dhcp6_server table
**Expected behavior**
A clear and concise description of what you expected to happen:
The dhcp4_server_modification_ts index should be associated with the dhcp4_server table.
**Environment:**
- Kea version: 2.2.0
- OS: FreeBSD 13.2-RELEASE amd64
- Compiled with pgsql backend
- Loaded hooks: pgsql_cb
**Additional Information**
```
kea=> \di dhcp4_server_modification_ts
List of relations
Schema | Name | Type | Owner | Table
--------+------------------------------+-------+-------+--------------
public | dhcp4_server_modification_ts | index | kea | dhcp6_server
(1 row)
```
This appears to have been introduced as a [copy/paste error in version 7.0 of the schema](https://gitlab.isc.org/isc-projects/kea/-/blob/Kea-2.3.8/src/share/database/scripts/pgsql/dhcpdb_create.pgsql#L1398). I could identify no correspond bug in the MySQL schema.
**Contacting you**
* SMS/Signal: (available upon request)
* GitHub/GitLab: neirbowj
* Mastodon: [@neirbowj@mastodon.online](https://mastodon.online/@neirbowj)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2863require-client-classes does not prioritize classes options2024-03-21T12:42:39ZMarcin Godzinarequire-client-classes does not prioritize classes optionsUsing `require-client-classes` does not prioritize options defined in classes.
I tried classifying clients by empty host reservations and by class test.
**Recreation:**
`00:03:00:01:f6:f5:f4:f3:f2:11` is sending Solicit and option 23 ...Using `require-client-classes` does not prioritize options defined in classes.
I tried classifying clients by empty host reservations and by class test.
**Recreation:**
`00:03:00:01:f6:f5:f4:f3:f2:11` is sending Solicit and option 23 requirements.
Kea responds with Advertise, including option 23.
I expect "2001:db8::2" in option 23, which is defined in the class, but receive "2001:db8::1" from the subnet.
Tested configs:
<details><summary>1 - using empty reservation (both with and without "only-if-required": true) </summary>
```
{
"Dhcp6": {
"subnet6": [
{
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::1-2001:db8:1::1"
}
],
"interface": "enp0s9",
"option-data": [
{
"code": 23,
"csv-format": true,
"data": "2001:db8::1",
"name": "dns-servers",
"space": "dhcp6"
}
],
"require-client-classes": [
"blocked"
]
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"client-classes": [
{
"name": "blocked",
"option-data": [
{
"name": "dns-servers",
"data": "2001:db8::2"
}
]
}
],
"reservations": [
{
"duid": "00:03:00:01:f6:f5:f4:f3:f2:11",
"client-classes": [
"blocked"
]
}
],
"reservation-mode": "global",
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"lease-database": {
"type": "memfile"
}
}
}
```
</details>
<details><summary>2 - using class test (both with and without "only-if-required": true)</summary>
```
{
"Dhcp6": {
"subnet6": [
{
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::1-2001:db8:1::1"
}
],
"interface": "enp0s9",
"option-data": [
{
"code": 23,
"csv-format": true,
"data": "2001:db8::1",
"name": "dns-servers",
"space": "dhcp6"
}
],
"require-client-classes": [
"blocked"
]
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"client-classes": [
{
"name": "blocked",
"test": "option[1].hex == 0x00030001f6f5f4f3f211",
"only-if-required": true,
"option-data": [
{
"name": "dns-servers",
"data": "2001:db8::2"
}
]
}
],
"reservations": [
{
"duid": "00:03:00:01:f6:f5:f4:f3:f2:11"
}
],
"reservation-mode": "global",
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"lease-database": {
"type": "memfile"
}
}
}
```
</details>next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2762Lease user context processing can be made more consistent2023-03-09T14:47:03ZFrancis DupontLease user context processing can be made more consistentFor instance it is possible to add using directly the API a lease user context which is not a map: with SQL backends to try to retrieve the lease throws including in a returning collection method without giving the address of the lease...For instance it is possible to add using directly the API a lease user context which is not a map: with SQL backends to try to retrieve the lease throws including in a returning collection method without giving the address of the lease...next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2736valid-lifetime and required client classes2023-01-26T14:25:43ZPeter Daviesvalid-lifetime and required client classesvalid-lifetime and required client classes:
When defining "valid-lifetime" in a client class the value takes precedence over
the global and subnet values. This does not happen when the class is defined as
"only-if-required" and...valid-lifetime and required client classes:
When defining "valid-lifetime" in a client class the value takes precedence over
the global and subnet values. This does not happen when the class is defined as
"only-if-required" and the subnet is defined with "required-client-classes"
The Kea Arm suggests that "option-data" in required classes take precedence but
no mention is made of "valid-lifetime"
Quote: Required evaluation can be used to express complex dependencies like subnet membership. It can also be used to reverse
the precedence; if option-data is set in a subnet, it takes precedence over option-data in a class. If option-data
is moved to a required class and required in the subnet, a class evaluated earlier may take precedence.
The following offers a lease time with the default value of "7200" and not "123"
for clients classifed as "Class-1"
```
{
"Dhcp4": {
"interfaces-config": { "interfaces": [ "vethserver" ] },
"control-socket": { "socket-type": "unix", "socket-name": "../sockets/kea4_command" },
"lease-database": { "type": "memfile", "name": "./kea-lease4.csv", "lfc-interval": 0, "persist": true },
"client-classes": [ {
"name": "Class-1", "test": "(pkt4.mac == 0x1e503193e1a6)", "only-if-required": true, "valid-lifetime": 123 }],
"subnet4": [ {
"subnet": "10.0.1.0/24", "id": 1,
"pools": [ { "pool": "10.0.1.5 - 10.0.1.254",
"require-client-classes": [ "Class-1" ] } ] }],
"dhcp-ddns": { "enable-updates": false },
"option-data": [ {
"name": "domain-name-servers", "code": 6, "data": "1.1.1.1" }, {
"name": "routers", "code": 3, "data": "10.0.1.1" } ],
"loggers": [ {
"name": "kea-dhcp4", "output_options": [ { "output": "./kea-dhcp4.log" } ],
"severity": "DEBUG", "debuglevel": 99 } ] }
}
```
[RT #21738](https://support.isc.org/Ticket/Display.html?id=21738)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2598sanitize generated client-class names2023-07-31T14:07:21ZFrancis Dupontsanitize generated client-class namesSome client-class names are generated for instance in the current Kea the DHCPv6 vendor-class option content xxx gives a VENDOR_CLASS_xxx class name even when xxx contains a comma or a space or the full name is longer than a reasonable l...Some client-class names are generated for instance in the current Kea the DHCPv6 vendor-class option content xxx gives a VENDOR_CLASS_xxx class name even when xxx contains a comma or a space or the full name is longer than a reasonable limit applied to configured class names.
So my proposal is: so
- limit the allowed length to configured class names which does not match a builtin prefix
- limit the character set of all class names
- provide a sanitizing class/static method which either escape illegal character or if there are too many (say more than one?) encode the argument into hexadecimal i.e. a specialized version of util::strutil::isPrintable (as it is for internal use we do not need something like the DNS name sanitizer)
- call this new method where class names are generated
For the character set I propose the same as isprint at the exception of space characters, quote characters, parentheses, brackets, commas, equal and backslash so
digits, letters and ```!#$%&*+-./:?@^_|~```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2561Wrong format of a complex DHCP option with suboptions stored in the host data...2023-07-05T10:39:18ZMarcin SiodelskiWrong format of a complex DHCP option with suboptions stored in the host databaseI am sending the reservation-add command to Kea (from Stork) with the following arguments:
```json
{ "reservation": { "hw-address": "23212345", "option-data": [ { "code": 93, "csv-format": true, "data": "1,12/12", "space": "s46-rule-opt...I am sending the reservation-add command to Kea (from Stork) with the following arguments:
```json
{ "reservation": { "hw-address": "23212345", "option-data": [ { "code": 93, "csv-format": true, "data": "1,12/12", "space": "s46-rule-options" }, { "code": 89, "csv-format": true, "data": "1,2,3,192.0.2.1,3000::/64", "space": "s46-cont-mape-options" }, { "code": 94, "csv-format": true, "space": "dhcp6" } ], "subnet-id": 1 } }
```
Next, when I get this reservation from the database.
```
"option-data": [ { "always-send": false, "code": 94, "csv-format": false, "data": "00590018010203C0000201403000000000000000005D0004010C00C0", "name": "s46-cont-mape", "space": "dhcp6" }, { "always-send": false, "code": 89, "csv-format": true, "data": "1,2,3,192.0.2.1,3000::/64", "name": "s46-rule", "space": "s46-cont-mape-options" }, { "always-send": false, "code": 93, "csv-format": true, "data": "1,12/12", "name": "s46-portparams", "space": "s46-rule-options" } ]
```
Option 94 is an empty option, but in this scenario it has a payload of `00590018010203C0000201403000000000000000005D0004010C00C0`. I presume this is the hexadecimal representation of the suboptions.
From the first look, it comes from the following function:
```
void OptionDataListParser::parse(const CfgOptionPtr& cfg,
isc::data::ConstElementPtr option_data_list) {
auto option_parser = createOptionDataParser();
BOOST_FOREACH(ConstElementPtr data, option_data_list->listValue()) {
std::pair<OptionDescriptor, std::string> option =
option_parser->parse(data);
// Use the option description to keep the formatted value
cfg->add(option.first, option.second);
cfg->encapsulate();
}
}
```
It calls `cfg->encapsulate()` which appends suboptions to the option. Next, it serializes the option with its suboptions and stores it in the database.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2339Memory leak in HA scenario with backup server down2023-09-07T14:02:26ZBranimir RajtarMemory leak in HA scenario with backup server down---
name: Memory leak in HA scenario with backup server down
about: Memory loss is created on running instances
---
**Describe the bug**
HA mode is configured with three servers (primary, secondary, backup) and is serving clients. Whe...---
name: Memory leak in HA scenario with backup server down
about: Memory loss is created on running instances
---
**Describe the bug**
HA mode is configured with three servers (primary, secondary, backup) and is serving clients. When the backup server becomes unavailable, the primary and secondary experience a continuous memory leak which is manifested as a continuous increase in RSS memory use for the isc-kea-dhcp4-server process. The size of the memory leak is in direct correlation with the number of active clients - the larger number, the greater the memory leak. Once the backup server is deleted from the configuration or it becomes active again, there is no more memory increase, but the old memory is not freed.
**To Reproduce**
Steps to reproduce the behavior:
1. Run KEA (DHCP4 only) in HA scenario with two load-balancing servers (primary and secondary) and a single backup server
2. Start serving clients (40k in our scenario) and monitoring RSS usage for the KEA server process
3. Disable backup server
4. Verify that RSS usage is increasing continuously
5. Enable backup server
6. Verify that RSS usage is stable
**Expected behavior**
The servers should not have any memory leaks.
**Environment:**
- Kea version: 1.8.2, 2.0.2
- OS: Ubuntu 18.04
- Memfile
- libdhcp_lease_cmds, libdhcp_stat_cmds, libdhcp_ha
**Additional Information**
```
{
"Dhcp4": {
"dhcp-queue-control": {
"enable-queue": true,
"queue-type": "kea-ring4",
"capacity": 256
},
"interfaces-config": {
"interfaces": [
"eth1"
],
"dhcp-socket-type": "udp"
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea-dhcp4-ctrl.sock"
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases",
"lfc-interval": 3600,
"port": 0
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 60,
"rebind-timer": 100,
"valid-lifetime": 120,
"option-data": [],
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"this-server-name": "server3",
"mode": "load-balancing",
"heartbeat-delay": 3000,
"max-response-delay": 7000,
"max-ack-delay": 7000,
"max-unacked-clients": 20,
"peers": [
{
"name": "server2",
"url": "http://<XXX>:8080/",
"role": "secondary",
"auto-failover": true
},
{
"name": "server1",
"url": "http://<YYY>:8080/",
"role": "primary",
"auto-failover": true
},
{
"name": "server3",
"url": "http://<ZZZ>:8080/",
"role": "backup",
"auto-failover": true
}
]
}
]
}
}
],
"option-def": [
{
"name": "classless-static-route",
"code": 121,
"space": "dhcp4",
"type": "record",
"array": true,
"record-types": "uint8, uint8"
}
],
"client-classes": [
// anonymized
],
"subnet4": [
// anonymized
],
"reservations": [],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "syslog"
}
],
"severity": "error",
"debuglevel": 0
}
]
}
}
```
**Contacting you**
Email/Github, telephone is available after contactnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2312ALLOC_ENGINE_Vx_ALLOC_FAIL_CLASSES message does not make sense2022-11-02T15:10:41ZFrancis DupontALLOC_ENGINE_Vx_ALLOC_FAIL_CLASSES message does not make senseThe ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES message (and soon ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES message and associated counters) is triggered by a failed allocation for a query which has at least one class. As all queries are members of the ...The ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES message (and soon ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES message and associated counters) is triggered by a failed allocation for a query which has at least one class. As all queries are members of the ALL classes this does not make sense. Same for the KNOWN and UNKNOWN classes which are commonly used as guards too.
Note that to print classes is not a bad idea, the issue is only the assumption classes are related to the allocation failure.backlog