Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-28T10:34:28Zhttps://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/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/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/3020Post audit: investigate if basic auth with http could be discouraged2023-09-21T10:09:47ZTomek MrugalskiPost audit: investigate if basic auth with http could be discouragedAnother [report by @manu](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). The overall idea is to strongly discourage people from running basic auth o...Another [report by @manu](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). The overall idea is to strongly discourage people from running basic auth over plain HTTP. It's insecure, but maybe in some experiments it might be useful, so we probably shouldn't forcibly abort.
But perhaps print a warning with a link to ARM section explaining why it's wrong would do?next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2974New localize DHCP server command2023-09-01T14:23:21ZFrancis DupontNew localize DHCP server commandThe idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.The idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2940return hash in config-set response from CA2023-06-29T13:33:06ZTomek Mrugalskireturn hash in config-set response from CAThe #2707 introduced hash being returned by `config-set` response for DHCPv4, DHCPv6 and D2. This ticket is about adding the same functionality for Ctrl Agent. This is a completion of the task started in #2707.The #2707 introduced hash being returned by `config-set` response for DHCPv4, DHCPv6 and D2. This ticket is about adding the same functionality for Ctrl Agent. This is a completion of the task started in #2707.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3225when applying MT settings from CB the libs compatibility is not rechecked2024-03-27T13:50:40ZRazvan Becheriuwhen applying MT settings from CB the libs compatibility is not recheckedMT disabled -\> check libs (success) -\> load libs -\> CB load config -\> MT enabled -\> no checking of libs -\> could end up with non MT compatible libs loaded and used in MTMT disabled -\> check libs (success) -\> load libs -\> CB load config -\> MT enabled -\> no checking of libs -\> could end up with non MT compatible libs loaded and used in MTnext-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/776Add a command to get back command line arguments2022-11-02T15:10:19ZFrancis DupontAdd a command to get back command line argumentsThe new command command-line-get will return the list of arguments, i.e. the `argv` tables including the first item and of course the configuration file. Perhaps it should be useful to add the current directory?The new command command-line-get will return the list of arguments, i.e. the `argv` tables including the first item and of course the configuration file. Perhaps it should be useful to add the current directory?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3224CB commands should use processDhcp[4|6]Config to validate content of global p...2024-02-01T14:46:08ZRazvan BecheriuCB commands should use processDhcp[4|6]Config to validate content of global parameterssetting global parameters using CB commands does not check if values are valid. They are merged into the current config with no check. this could have an undesired effect on the running server.
global scalar parameters v4:
```plaintext...setting global parameters using CB commands does not check if values are valid. They are merged into the current config with no check. this could have an undesired effect on the running server.
global scalar parameters v4:
```plaintext
if ( (config_pair.first == "renew-timer") ||
(config_pair.first == "rebind-timer") ||
(config_pair.first == "valid-lifetime") ||
(config_pair.first == "min-valid-lifetime") ||
(config_pair.first == "max-valid-lifetime") ||
(config_pair.first == "decline-probation-period") ||
(config_pair.first == "dhcp4o6-port") ||
(config_pair.first == "echo-client-id") ||
(config_pair.first == "match-client-id") ||
(config_pair.first == "authoritative") ||
(config_pair.first == "next-server") ||
(config_pair.first == "server-hostname") ||
(config_pair.first == "boot-file-name") ||
(config_pair.first == "server-tag") ||
(config_pair.first == "reservation-mode") ||
(config_pair.first == "reservations-global") ||
(config_pair.first == "reservations-in-subnet") ||
(config_pair.first == "reservations-out-of-pool") ||
(config_pair.first == "calculate-tee-times") ||
(config_pair.first == "t1-percent") ||
(config_pair.first == "t2-percent") ||
(config_pair.first == "cache-threshold") ||
(config_pair.first == "cache-max-age") ||
(config_pair.first == "hostname-char-set") ||
(config_pair.first == "hostname-char-replacement") ||
(config_pair.first == "ddns-send-updates") ||
(config_pair.first == "ddns-override-no-update") ||
(config_pair.first == "ddns-override-client-update") ||
(config_pair.first == "ddns-replace-client-name") ||
(config_pair.first == "ddns-generated-prefix") ||
(config_pair.first == "ddns-qualifying-suffix") ||
(config_pair.first == "ddns-update-on-renew") ||
(config_pair.first == "ddns-use-conflict-resolution") ||
(config_pair.first == "ddns-conflict-resolution-mode") ||
(config_pair.first == "ddns-ttl-percent") ||
(config_pair.first == "store-extended-info") ||
(config_pair.first == "statistic-default-sample-count") ||
(config_pair.first == "statistic-default-sample-age") ||
(config_pair.first == "early-global-reservations-lookup") ||
(config_pair.first == "ip-reservations-unique") ||
(config_pair.first == "reservations-lookup-first") ||
(config_pair.first == "parked-packet-limit") ||
(config_pair.first == "allocator") ||
(config_pair.first == "offer-lifetime") ) {
CfgMgr::instance().getStagingCfg()->addConfiguredGlobal(config_pair.first,
config_pair.second);
continue;
}
```
global scalar parameters v6:
```plaintext
if ( (config_pair.first == "renew-timer") ||
(config_pair.first == "rebind-timer") ||
(config_pair.first == "preferred-lifetime") ||
(config_pair.first == "min-preferred-lifetime") ||
(config_pair.first == "max-preferred-lifetime") ||
(config_pair.first == "valid-lifetime") ||
(config_pair.first == "min-valid-lifetime") ||
(config_pair.first == "max-valid-lifetime") ||
(config_pair.first == "decline-probation-period") ||
(config_pair.first == "dhcp4o6-port") ||
(config_pair.first == "server-tag") ||
(config_pair.first == "reservation-mode") ||
(config_pair.first == "reservations-global") ||
(config_pair.first == "reservations-in-subnet") ||
(config_pair.first == "reservations-out-of-pool") ||
(config_pair.first == "calculate-tee-times") ||
(config_pair.first == "t1-percent") ||
(config_pair.first == "t2-percent") ||
(config_pair.first == "cache-threshold") ||
(config_pair.first == "cache-max-age") ||
(config_pair.first == "hostname-char-set") ||
(config_pair.first == "hostname-char-replacement") ||
(config_pair.first == "ddns-send-updates") ||
(config_pair.first == "ddns-override-no-update") ||
(config_pair.first == "ddns-override-client-update") ||
(config_pair.first == "ddns-replace-client-name") ||
(config_pair.first == "ddns-generated-prefix") ||
(config_pair.first == "ddns-qualifying-suffix") ||
(config_pair.first == "ddns-update-on-renew") ||
(config_pair.first == "ddns-use-conflict-resolution") ||
(config_pair.first == "ddns-conflict-resolution-mode") ||
(config_pair.first == "ddns-ttl-percent") ||
(config_pair.first == "store-extended-info") ||
(config_pair.first == "statistic-default-sample-count") ||
(config_pair.first == "statistic-default-sample-age") ||
(config_pair.first == "early-global-reservations-lookup") ||
(config_pair.first == "ip-reservations-unique") ||
(config_pair.first == "reservations-lookup-first") ||
(config_pair.first == "parked-packet-limit") ||
(config_pair.first == "allocator") ||
(config_pair.first == "pd-allocator") ) {
CfgMgr::instance().getStagingCfg()->addConfiguredGlobal(config_pair.first,
config_pair.second);
continue;
}
```
lists might not be complete. need to check.
only few parameters are checked - one is valid-lifetime:
```plaintext
void
sanityChecks(const SrvConfigPtr& cfg, const ConstElementPtr& global) {
/// Global lifetime sanity checks
cfg->sanityChecksLifetime("valid-lifetime");
/// Shared network sanity checks
const SharedNetwork4Collection* networks = cfg->getCfgSharedNetworks4()->getAll();
if (networks) {
sharedNetworksSanityChecks(*networks, global->get("shared-networks"));
}
}
```
some are not checked even by processDhcp\[4|6\]Config:
```plaintext
if (allow_packet_park) {
// Get the parking limit. Parsing should ensure the value is present.
uint32_t parked_packet_limit = 0;
data::ConstElementPtr ppl = CfgMgr::instance().getCurrentCfg()->
getConfiguredGlobal(CfgGlobals::PARKED_PACKET_LIMIT);
if (ppl) {
parked_packet_limit = ppl->intValue();
}
if (parked_packet_limit) {
auto const& parking_lot =
ServerHooks::getServerHooks().getParkingLotPtr(hook_label);
if (parking_lot && (parking_lot->size() >= parked_packet_limit)) {
// We can't park it so we're going to throw it on the floor.
LOG_DEBUG(packet4_logger, DBGLVL_PKT_HANDLING, parking_lot_full_msg)
.arg(parked_packet_limit)
.arg(query->getLabel());
isc::stats::StatsMgr::instance().addValue("pkt4-receive-drop",
static_cast<int64_t>(1));
rsp.reset();
return;
}
}
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2884add commands in stat hook library for statistics by Pool ID (by subnet ID/sub...2023-06-15T13:45:24ZRazvan Becheriuadd commands in stat hook library for statistics by Pool ID (by subnet ID/subnet range/pool ID/pool range)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2563Refactor exceptions in libdhcp-cc library2023-04-06T12:02:31ZMarcin SiodelskiRefactor exceptions in libdhcp-cc libraryI have a use case related to #2408, where I intend to modify the control results returned by the ``lease_cmds`` hook library. The #2408 introduces the conflict status code returned when the new or updated lease is in conflict with the se...I have a use case related to #2408, where I intend to modify the control results returned by the ``lease_cmds`` hook library. The #2408 introduces the conflict status code returned when the new or updated lease is in conflict with the server's configuration. However, there is also another class of errors that could be distinguished - errors returned for bad arguments. Hook libraries make use of the Kea parsers that generally throw ``DhcpConfigError``. The ``lease_cmds`` hook can also throw ``BadValue`` or ``InvalidParameter``. They all can mean similar things. We could use ``DhcpConfigError`` everywhere, but its comment says it is to be removed in favor or the ``ConfigError`` exception. I also think that ``DhcpConfigError`` shouldn't be used for the commands that do not attempt to modify the configuration. There are tons of commands that only read the data but can still trigger the ``DhcpConfigError``. Overall, our use of the exceptions and the hierarchy makes it quite hard to differentiate between various error conditions.
In my opinion, we should have a ``BadCommandArguments`` type of exception returned by the DHCP parsers. The hook libraries like ``lease_cmds`` could also internally throw this error. Finally, when catching this exception, we could return a dedicated status code in the command response.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2260minor bugs in lease4 commands2022-11-02T15:10:41ZMarcin Godzinaminor bugs in lease4 commands1. `lease4-get` error states "duid" and not "client-id"
```shell
{"command": "lease4-get",
"arguments": {"identifier": "ff:01:02:03:ff:05",
"identifier-type": "something",
"sub...1. `lease4-get` error states "duid" and not "client-id"
```shell
{"command": "lease4-get",
"arguments": {"identifier": "ff:01:02:03:ff:05",
"identifier-type": "something",
"subnet-id": 1}}
```
Should return: `"Incorrect identifier type: something, the only supported values are: address, hw-address, client-id"`
Returns: `"Incorrect identifier type: something, the only supported values are: address, hw-address, duid"`
2. `lease4-get-by-client-id` error states "duid" and not "client-id"
```shell
{"command": "lease4-get-by-client-id",
"arguments": {"client-id": ""}}
```
Should return: `"Empty client-id is not allowed"`
Returns: `"Empty DUIDs are not allowed"`
3. `lease4-get-all` accepts negative numbers as subnet number
Not necessary a problem.
```shell
{"command": "lease4-get-all",
"arguments": {"subnets": [-1]}}
```
4. `lease6-get` accepts `"subnet-id"` and `"identifier"` and `"identifier-type": "duid"` without `"iaid"`
but returns 0 leases found without complaining about lack of `iaid`
example:
```shell
{"command": "lease4-get",
"arguments": {"subnet-id": 1, "identifier": "1a:1b:1c:1d:1e:1f:20:21:22:23:24", "identifier-type": "duid"}}
```
will always return 0 leases found.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2731Remove dead code in command processing2023-02-09T14:18:22ZTomek MrugalskiRemove dead code in command processingWhile reviewing #2693, @andrei discovered that adding log messages in ControlledDhcpv4Srv::processCommand() section that handles libreload doesn't actually gets triggered when the command are sent over CA or directly over UNIX socket. Th...While reviewing #2693, @andrei discovered that adding log messages in ControlledDhcpv4Srv::processCommand() section that handles libreload doesn't actually gets triggered when the command are sent over CA or directly over UNIX socket. This should be investigated further. Perhaps processCommand() is no longer needed?
See background and details here: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1895?commit_id=877d1cfad37bd41d7d7db105ff6de0b83ca710e2#note_345720outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2802Implement `bundle` command2023-04-11T11:07:55ZTomek MrugalskiImplement `bundle` commandThe idea for this API call came from @marcin. Here's the discussion: https://pad.isc.org/p/stork-cb-migration#L64
The overall long term goal is to have a command that could include multiple other commands and run them one after another ...The idea for this API call came from @marcin. Here's the discussion: https://pad.isc.org/p/stork-cb-migration#L64
The overall long term goal is to have a command that could include multiple other commands and run them one after another as one change-set. Couple scenarios where this might be useful:
- changing subnet and all host reservations in it
- deleting subnet and all leases associated
- reservation migration from config file to database
This mechanism, if implemented correctly, will be very powerful.
One important feature of this new command is the ability to rollback changes if configurable number of errors is reached. It's important to acknowledge that full rollback in generic case is not possible, so this rollback should be limited to DB operations _for now_. We hope to expand the rollback in the future to maybe cover some other commands, but it will never be possible to rollback everything.
Since there are many ways how this could be implemented, I think the first step would be come up with a mini-design. Couple paragraphs in the ticket or on wiki should do the trick.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2217How to delete unused host reservations2023-04-05T13:27:33ZjujuHow to delete unused host reservationsI made some changes to my host reservations and now have a bunch of them that are not going to be used anymore. I can't figure out how to delete them. I see them in stork but don't have an idea how to permanently remove them. I have an ...I made some changes to my host reservations and now have a bunch of them that are not going to be used anymore. I can't figure out how to delete them. I see them in stork but don't have an idea how to permanently remove them. I have an HA setup with 2 kea servers and store the data in a postgresdb. I searched around but cant find any info on how to clean up the host reservations.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1125rebuild statistic-get-all response2021-10-19T07:37:07ZWlodzimierz Wencelrebuild statistic-get-all responseAt this point this is what kea is sending back:
```
{
"command": "statistic-get-all",
"arguments": {
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386733" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-3...At this point this is what kea is sending back:
```
{
"command": "statistic-get-all",
"arguments": {
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386733" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386735" ] ],
"reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386736" ] ],
"subnet[1].assigned-addresses": [ [ 0, "2019-07-30 10:04:28.386740" ] ],
"subnet[1].declined-addresses": [ [ 0, "2019-07-30 10:04:28.386743" ] ],
"subnet[1].reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386745" ] ],
"subnet[1].reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386747" ] ],
"subnet[1].total-addresses": [ [ 200, "2019-07-30 10:04:28.386719" ] ]
},
"result": 0
}
```
I want to focus on a prat with subnets, which is really hard to parse. Biggest issue is that subnet id is in key name, not as value. And this is completely flat.
I am proposing to return statistics like that:
```
{
"command": "statistic-get-all",
"arguments": {
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386733" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386735" ] ],
"reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386736" ] ],
"subnets": { [
"subnet-id": 1,
"assigned-addresses": [ [ 0, "2019-07-30 10:04:28.386740" ] ],
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386743" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386745" ] ],
"reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386747" ] ],
"total-addresses": [ [ 200, "2019-07-30 10:04:28.386719" ] ]
],
[
"subnet-id": 2,
"assigned-addresses": [ [ 0, "2019-07-30 10:04:28.386740" ] ],
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386743" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386745" ] ],
"reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386747" ] ],
"total-addresses": [ [ 200, "2019-07-30 10:04:28.386719" ] ]
]
}
},
"result": 0
}
```
I came up on this issue while working recently with performance testing of a setup with ~500 subnets.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/723Missing CB entry for deleting all global options2021-10-20T09:47:17ZFrancis DupontMissing CB entry for deleting all global optionsObviously either we have to add a deleteAllOptions4 or remove `remote-option4-global-del-all` from the design. Note as the CB command is starred this should be postponed...Obviously either we have to add a deleteAllOptions4 or remove `remote-option4-global-del-all` from the design. Note as the CB command is starred this should be postponed...outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/598forbid using empty string as value of shared-network-name parameter in remote...2021-10-20T09:44:18ZWlodzimierz Wencelforbid using empty string as value of shared-network-name parameter in remote-subnet4-set commandright now values that are allowed are:
- non empty string
- empty string
- null
And two of them have the same result, I propose forbidding `"shared-network-name": ""` to avoid misusing this parameter.right now values that are allowed are:
- non empty string
- empty string
- null
And two of them have the same result, I propose forbidding `"shared-network-name": ""` to avoid misusing this parameter.outstanding