Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2019-02-19T12:25:11Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/33CB: Add support for 'reload-subnets' command2019-02-19T12:25:11ZGhost UserCB: Add support for 'reload-subnets' commandOnce all other configuration scaling tickets are done (#3579-#3584), a command that triggers the server to reload subnet configuration would be useful.Once all other configuration scaling tickets are done (#3579-#3584), a command that triggers the server to reload subnet configuration would be useful.Kea1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/57Fixes as a result of profiling the HTTP code and control channel2018-11-15T12:24:25ZGhost UserFixes as a result of profiling the HTTP code and control channelThere are the following issues pertaining to JSONFeed and Http parsers which per my profiling tests seems to be first candidates for fixing:
* JSONFeed::postBuffer expensive because of making new allocations all the time
* JSONFeed::pop...There are the following issues pertaining to JSONFeed and Http parsers which per my profiling tests seems to be first candidates for fixing:
* JSONFeed::postBuffer expensive because of making new allocations all the time
* JSONFeed::popNextFromBuffer makes many buffer de-allocations
* JSONFeed::innerJSONHandler should not transition if the state remains the same
* HttpResponseParser body handler is inefficient as it reads characters one by one
* Connection::doTransaction should not reinitialize the parser all the time as it triggers expensive reinitialization of the state machineKea1.5-beta2https://gitlab.isc.org/isc-projects/kea/-/issues/69Global Host Reservations Task 4: Host Commands should accept global subnet id2018-11-07T17:52:34ZGhost UserGlobal Host Reservations Task 4: Host Commands should accept global subnet idHost Cmds need to accept a subnet-id value of SUBNET_ID_GLOBAL for either v4 or v6 subnet-ids, to allow manipulation of global reservations.Host Cmds need to accept a subnet-id value of SUBNET_ID_GLOBAL for either v4 or v6 subnet-ids, to allow manipulation of global reservations.Kea1.5-beta1https://gitlab.isc.org/isc-projects/kea/-/issues/158reservation is allowed for out-of-subnet address and/or non-existent subnet-id2020-05-27T08:08:16ZCathy Almondreservation is allowed for out-of-subnet address and/or non-existent subnet-idReported by a Support customer:
https://support.isc.org/Ticket/Display.html?id=13626
---
name: Bug report
about: Kea 1.4.0 P1
---
kea-dhcp4 API accepts the creation of reservations for non-existent subnet-IDs and/or for out-of-subnet ...Reported by a Support customer:
https://support.isc.org/Ticket/Display.html?id=13626
---
name: Bug report
about: Kea 1.4.0 P1
---
kea-dhcp4 API accepts the creation of reservations for non-existent subnet-IDs and/or for out-of-subnet ip addresses, tested with mysql backend for hosts.
To reproduce:
1) create a new subnet 192.0.0.0/24, with subnet id 999
REQUEST:
{
"arguments": {
"subnet4": [
{
"id": 999,
"match-client-id": true,
"option-data": [
{
"always-send": false,
"code": 3,
"csv-format": false,
"data": "c0000001",
"name": "routers",
"space": "dhcp4"
}
],
"pools": [
{
"pool": "192.0.0.2-192.0.0.254"
}
],
"rebind-timer": 2970,
"relay": {
"ip-addresses": [
"192.0.0.1"
]
},
"renew-timer": 1800,
"reservation-mode": "all",
"subnet": "192.0.0.0/24",
"valid-lifetime": 3600
}
]
},
"command": "subnet4-add",
"service": [
"dhcp4"
]
}
RESPONSE:
[ { "arguments": { "subnets": [ { "id": 999, "subnet": "192.0.0.0/24" } ] }, "result": 0, "text": "IPv4 subnet added" } ]
2) create a reservation for out-of-subnet address using 1.2.3.4 as IP and 999 as subnet-id
REQUEST:
{
"arguments": {
"reservation": {
"hw-address": "ca:fe:ca:fe:ca:fe",
"ip-address": "1.2.3.4",
"subnet-id": 999
}
},
"command": "reservation-add",
"service": [
"dhcp4"
]
}
RESPONSE:
[ { "result": 0, "text": "Host added." } ]
3) create a reservation for a non-existent subnet-id using 192.0.0.10 as IP and 123 as subnet-id
REQUEST:
{
"arguments": {
"reservation": {
"hw-address": "fa:ce:fa:ce:fa:ce",
"ip-address": "192.0.0.10",
"subnet-id": 123
}
},
"command": "reservation-add",
"service": [
"dhcp4"
]
}
RESPONSE:
[ { "result": 0, "text": "Host added." } ]
4) verify the presence of both reservations in the "hosts" tableKea1.5-beta2Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/166Kea HA load balancing setup API failed to communicate with DHCP42018-10-17T05:30:25ZGhost UserKea HA load balancing setup API failed to communicate with DHCP4Describe the bug
HA load balancing setup not working with API failed to communicate with dhcp4 server
Server 1 primary
018-10-15 06:25:57.954 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) f...Describe the bug
HA load balancing setup not working with API failed to communicate with dhcp4 server
Server 1 primary
018-10-15 06:25:57.954 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:26:08.967 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:26:19.981 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:26:30.994 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:26:42.008 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
Server 2 secondary
[root@test2 tmp]# keactrl status
DHCPv4 server: active
DHCPv6 server: active
DHCP DDNS: inactive
Control Agent: active
Kea DHCPv4 configuration file: /etc/kea/kea-dhcp4.conf
Kea DHCPv6 configuration file: /etc/kea/kea-dhcp6.conf
Kea DHCP DDNS configuration file: /etc/kea/kea-dhcp-ddns.conf
Kea Control Agent configuration file: /etc/kea/kea-ctrl-agent.conf
keactrl configuration file: /etc/kea/keactrl.conf
[root@test2 tmp]# ps -aef | grep kea
root 29062 1 0 06:27 pts/2 00:00:00 /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
root 29069 1 0 06:27 pts/2 00:00:00 /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf
root 29078 1 0 06:27 pts/2 00:00:00 /usr/sbin/kea-ctrl-agent -c /etc/kea/kea-ctrl-agent.conf
root 29131 4193 0 06:31 pts/2 00:00:00 grep --color=auto kea
-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:29:04.182 INFO [kea-ctrl-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:29:15.196 INFO [kea-ctrl-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:28:59.221 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:29:10.236 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:29:21.249 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:29:32.264 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:29:43.277 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
To Reproduce
Steps to reproduce the behavior:
Run Kea (which daemon? dhcpv4, dhcpv6, ddns, ca?) with the following config '...'
configure kea HA with load balancing setup
A client does A and sends packet B with options C,D,E via relay F that does '...'
client A sends heartbeat but client B failed to handle both clients are same
The server then '...'
See error
failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
Environment:
Kea version: which release? if it's compiled from git, which revision. Use kea-dhcp4 -V to find out.
kea-dhcp4 -V
**
1.4.0
tarball
linked with:
log4cplus 1.1.3
OpenSSL 1.0.2k-fips 26 Jan 2017
database:
MySQL backend 6.0, library 5.5.60-MariaDB
Memfile backend 2.0
**
OS: [e.g. Ubuntu 16.04 x64]
Centos 7 x64
Which features were compiled in (in particular which backends)
If/which hooks where loaded in
control agent config :
{
"Control-agent": {
"http-host": "10.25.133.13",
"http-port": 8080,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket.sock"
},
"dhcp6": {
"socket-type": "unix",
"socket-name": "/tmp/socket.sock"
}
},
"hooks-libraries": [{
"library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so"
},
{
"library": "/usr/local/lib/hooks/libdhcp_stat_cmds.so"
}
]
},
"Logging": {
"loggers": [{
"name": "kea-ctrl-agent",
"severity": "DEBUG",
"output_options": [{
"output": "/usr/local/var/log/kea-ctrl-agent.log"
}]
}]
}
}
**kea-dhcp4.conf :**
> {
> "Dhcp4": {
> "interfaces-config": {
> "interfaces": ["ens160"],
> "dhcp-socket-type": "raw"
>
> },
>
> "valid-lifetime": 60000,
> "renew-timer": 10000,
> "rebind-timer": 20000,
> "subnet4": [{
>
> "id": 2,
> "subnet": "10.25.133.0/24",
> "pools": [{
> "pool": "10.25.133.2-10.25.133.100"
> }]
>
> }],
>
> "lease-database": {
> "type": "mysql",
> "name": "kea",
> "user": "kea",
> "password": "***",
> "host": "10.25.133.13",
> "port": 3306
> },
>
> "hosts-database": {
> "type": "mysql",
> "name": "kea",
> "user": "kea",
> "password": "***",
> "host": "10.25.133.13",
> "port": 3306
> },
> "hooks-libraries": [{
> "library": "/usr/lib64/hooks/libdhcp_lease_cmds.so"
> },
>
> {
> "library": "/usr/lib64/hooks/libdhcp_stat_cmds.so"
>
> },
>
> {
> "library": "/usr/lib64/hooks/libdhcp_ha.so",
> "parameters": {
> "high-availability": [{
> "this-server-name": "test2",
> "mode": "load-balancing",
> "heartbeat-interval": 60,
> "max-response-delay": 100,
> "max-ack-delay": 100,
> "max-unacked-messages": 10,
> "peers": [{
> "name": "test3",
> "url": "http://10.25.133.13:8080/",
> "role": "primary",
> "auto-failover": true
> },
> {
> "name": "test2",
> "url": "http://10.25.133.12:8080/",
> "role": "secondary",
> "auto-failover": true
> }
> ]
> }]
> }
> }
> ]
>
> },
>
>
>
> "Logging": {
> "loggers": [{
> "name": "kea-dhcp4",
> "output_options": [{
> "output": "/var/log/kea-dhcp4.log"
> }],
> "severity": "DEBUG"
> }]
> }
> }
Note: checked firewall, both API able to talk but not able communicate with running dhcp4 daemons.
Both API receives heartbeat :
-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:29:04.182 INFO [kea-ctrl-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:29:15.196 INFO [kea-ctrl-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
anyone could have suggestions ?https://gitlab.isc.org/isc-projects/kea/-/issues/189some lease updates in HA pair failed on Kea DHCPv4 1.4.0-P12019-08-12T11:30:46ZGhost Usersome lease updates in HA pair failed on Kea DHCPv4 1.4.0-P1Hello, warnings like this observed in logfile:
2018-10-24 10:53:24.541 WARN [kea-dhcp4.ha-hooks/20371] HA_LEASE_UPDATE_FAILED [hwtype=1 34:08:04:ac:53:22], cid=[01:34:08:04:ac:53:22], tid=0xa915: lease update to server101 (http://10.58...Hello, warnings like this observed in logfile:
2018-10-24 10:53:24.541 WARN [kea-dhcp4.ha-hooks/20371] HA_LEASE_UPDATE_FAILED [hwtype=1 34:08:04:ac:53:22], cid=[01:34:08:04:ac:53:22], tid=0xa915: lease update to server101 (http://10.58.0.101:8080/) failed: body of the response must be a list
and found that caused by this:
POST / HTTP/1.1
Content-Length: 328
Content-Type: application/json
{ "arguments": { "client-id": "01:34:08:04:ac:53:22", "expire": 1540371418, "force-create": true, "fqdn-fwd": true, "fqdn-rev": true, "hostname": "D-Link\u0000", "hw-address": "34:08:04:ac:53:22", "ip-address": "10.187.15.132", "state": 0, "subnet-id": 2, "valid-lft": 120 }, "command": "lease4-update", "service": [ "dhcp4" ] }
HTTP/1.1 400 Bad Request
Content-Length: 40
Content-Type: application/json
Date: Wed, 24 Oct 2018 08:54:58 GMT
{ "result": 400, "text": "Bad Request" }
update work with "normal" hostname:
curl -X POST -H "Content-Type: application/json" -d '{ "arguments": { "client-id": "01:34:08:04:ac:53:22", "expire": 1540371418, "force-create": true, "fqdn-fwd": true, "fqdn-rev": true, "hostname": "justatest", "hw-address": "34:08:04:ac:53:22", "ip-address": "10.187.15.132", "state": 0, "subnet-id": 2, "valid-lft": 120 }, "command": "lease4-update", "service": [ "dhcp4" ] }' http://10.58.0.101:8080/
[ { "result": 0, "text": "IPv4 lease added." } ]
regards
iKea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/317Kea HA load balancing setup API failed to communicate with DHCP4 (GH #108)2019-01-25T19:26:12ZVicky Riskvicky@isc.orgKea HA load balancing setup API failed to communicate with DHCP4 (GH #108)<migrated from Github issue #108. opened there by learn3r@github.com on October 15, 2018>
Describe the bug
HA load balancing setup not working with API failed to communicate with dhcp4 server
Server 1 primary
018-10-15 06:25:57.954 WAR...<migrated from Github issue #108. opened there by learn3r@github.com on October 15, 2018>
Describe the bug
HA load balancing setup not working with API failed to communicate with dhcp4 server
Server 1 primary
018-10-15 06:25:57.954 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:26:08.967 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:26:19.981 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:26:30.994 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:26:42.008 WARN [kea-dhcp4.ha-hooks/12395] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.12:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
Server 2 secondary
[root@test2 tmp]# keactrl status
DHCPv4 server: active
DHCPv6 server: active
DHCP DDNS: inactive
Control Agent: active
Kea DHCPv4 configuration file: /etc/kea/kea-dhcp4.conf
Kea DHCPv6 configuration file: /etc/kea/kea-dhcp6.conf
Kea DHCP DDNS configuration file: /etc/kea/kea-dhcp-ddns.conf
Kea Control Agent configuration file: /etc/kea/kea-ctrl-agent.conf
keactrl configuration file: /etc/kea/keactrl.conf
[root@test2 tmp]# ps -aef | grep kea
root 29062 1 0 06:27 pts/2 00:00:00 /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
root 29069 1 0 06:27 pts/2 00:00:00 /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf
root 29078 1 0 06:27 pts/2 00:00:00 /usr/sbin/kea-ctrl-agent -c /etc/kea/kea-ctrl-agent.conf
root 29131 4193 0 06:31 pts/2 00:00:00 grep --color=auto kea
-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:29:04.182 INFO [kea-ctrl-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:29:15.196 INFO [kea-ctrl-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:28:59.221 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:29:10.236 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:29:21.249 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:29:32.264 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
2018-10-15 06:29:43.277 WARN [kea-dhcp4.ha-hooks/29062] HA_HEARTBEAT_FAILED heartbeat to (http://10.25.133.13:8080/) failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
To Reproduce
Steps to reproduce the behavior:
Run Kea (which daemon? dhcpv4, dhcpv6, ddns, ca?) with the following config '...'
configure kea HA with load balancing setup
A client does A and sends packet B with options C,D,E via relay F that does '...'
client A sends heartbeat but client B failed to handle both clients are same
The server then '...'
See error
failed: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline, error code 1
Environment:
Kea version: which release? if it's compiled from git, which revision. Use kea-dhcp4 -V to find out.
kea-dhcp4 -V
**
1.4.0
tarball
linked with:
log4cplus 1.1.3
OpenSSL 1.0.2k-fips 26 Jan 2017
database:
MySQL backend 6.0, library 5.5.60-MariaDB
Memfile backend 2.0
**
OS: [e.g. Ubuntu 16.04 x64]
Centos 7 x64
Which features were compiled in (in particular which backends)
If/which hooks where loaded in
control agent config :
{
"Control-agent": {
"http-host": "10.25.133.13",
"http-port": 8080,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket.sock"
},
"dhcp6": {
"socket-type": "unix",
"socket-name": "/tmp/socket.sock"
}
},
"hooks-libraries": [{
"library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so"
},
{
"library": "/usr/local/lib/hooks/libdhcp_stat_cmds.so"
}
]
},
"Logging": {
"loggers": [{
"name": "kea-ctrl-agent",
"severity": "DEBUG",
"output_options": [{
"output": "/usr/local/var/log/kea-ctrl-agent.log"
}]
}]
}
}
Note: checked firewall, both API able to talk but not able communicate with running dhcp4 daemons.
Both API receives heartbeat :
-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:29:04.182 INFO [kea-ctrl-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
2018-10-15 06:29:15.196 INFO [kea-ctrl-agent.commands/29078] COMMAND_RECEIVED Received command 'ha-heartbeat'
anyone could have suggestions ?https://gitlab.isc.org/isc-projects/kea/-/issues/318REST API health endpoint (GH#96)2020-06-04T22:25:20ZVicky Riskvicky@isc.orgREST API health endpoint (GH#96)<This issue was originally opened on Github as issue #96 by Smithx10@github.com on July 19, 2018>
**Describe the solution you'd like**
A Health Endpoint via the REST API that informs the user if the Kea Services are healthy and serving....<This issue was originally opened on Github as issue #96 by Smithx10@github.com on July 19, 2018>
**Describe the solution you'd like**
A Health Endpoint via the REST API that informs the user if the Kea Services are healthy and serving.
ex: localhost:8080/health
Would respond with a JSON object with some brief information about the KEA services running on the server and their health status.
**Describe alternatives you've considered**
```
status=keactrl status | grep "DHCPv4 server" | awk '{print $3}'
if [[ "${status}" == "active" ]] then;
_log "DHCP is healthy"
return 0
else
_log "DHCPv4 is not healthy"
return 1
fi
```
Related issue: #79https://gitlab.isc.org/isc-projects/kea/-/issues/394Recalculate statistics when server configuration is changed as a result of a ...2019-04-10T08:55:27ZMarcin SiodelskiRecalculate statistics when server configuration is changed as a result of a commandWhile reviewing !197 we found a general issue that statistics needs to be recalculated when incremental changes are applied to the configuration. The specific case discussed in !197 was that when new subnet is added to the database and t...While reviewing !197 we found a general issue that statistics needs to be recalculated when incremental changes are applied to the configuration. The specific case discussed in !197 was that when new subnet is added to the database and the server detects this change, it will fetch the subnet data and merge the subnet into the configuration it is currently running. Because, it bypasses the staging/commit phase, the statistics is not recalculated.
We also checked that subnet_cmds doesn't deal with this problem either. We may need to find some generic solution for it.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/405Update cb_cmds with commands to delete configuration data for DHCPv42019-01-25T22:47:56ZMarcin SiodelskiUpdate cb_cmds with commands to delete configuration data for DHCPv4The cb_cmds must be updated to support commands to delete subnets, shared networks, options, option definitions and global parameters from the database via the configuration backends, e.g. `deleteSubnet4`, `deleteAllSubnets4` etc.The cb_cmds must be updated to support commands to delete subnets, shared networks, options, option definitions and global parameters from the database via the configuration backends, e.g. `deleteSubnet4`, `deleteAllSubnets4` etc.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/406Update cb_cmds with commands to retrieve configuration data for DHCPv42019-11-26T10:34:09ZMarcin SiodelskiUpdate cb_cmds with commands to retrieve configuration data for DHCPv4We need to update the cb_cmds hooks library to support commands to retrieve configuration information from the database via the configuration backend for subnets, shared networks, global parameters, options and option definitions. The fo...We need to update the cb_cmds hooks library to support commands to retrieve configuration information from the database via the configuration backend for subnets, shared networks, global parameters, options and option definitions. The following are the examples of the corresponding backend commands: `getSubnet4`, `getModifiedSubnets4` etc.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/407Update cb_cmds with commands to manage global parameters for DHCPv62019-05-09T13:00:46ZMarcin SiodelskiUpdate cb_cmds with commands to manage global parameters for DHCPv6First part of CB DHCPv6 work: it will be divided into a premium MR reorganizing code and a second MR adding the DHCPv6 part for global parameters.
First part of CB DHCPv6 work: it will be divided into a premium MR reorganizing code and a second MR adding the DHCPv6 part for global parameters.
Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/408Update cb_cmds with commands to manage subnets for DHCPv62019-05-11T08:00:36ZMarcin SiodelskiUpdate cb_cmds with commands to manage subnets for DHCPv6Managing subnets in CB DHCPv6. Will be reuse as a skeleton for other DHCPv6 objects (shared network, option definition and data) in #409.
Managing subnets in CB DHCPv6. Will be reuse as a skeleton for other DHCPv6 objects (shared network, option definition and data) in #409.
Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/409Update cb_cmds with commands to manage other objects for DHCPv62019-05-15T15:01:03ZMarcin SiodelskiUpdate cb_cmds with commands to manage other objects for DHCPv6CB DHCPv6 code for shared networks, option definitions and option datas.
CB DHCPv6 code for shared networks, option definitions and option datas.
Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/411Merge DHCPv6 option definitions fetched from the CB into the configuration2019-04-10T18:24:14ZMarcin SiodelskiMerge DHCPv6 option definitions fetched from the CB into the configuration`SrvConfig::merge` must be updated to merge DHCPv6 option definitions into existing staging or current config.`SrvConfig::merge` must be updated to merge DHCPv6 option definitions into existing staging or current config.Kea1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/412Merge DHCPv6 options fetched from the CB into the configuration2019-04-10T18:24:32ZMarcin SiodelskiMerge DHCPv6 options fetched from the CB into the configuration`SrvConfig::merge` must be updated to merge options into existing staging or current configuration.`SrvConfig::merge` must be updated to merge options into existing staging or current configuration.Kea1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/424Update cb_cmds commands to refuse reservations in remote-subnet4-set2019-02-27T10:35:30ZFrancis DupontUpdate cb_cmds commands to refuse reservations in remote-subnet4-setIf there is a reservations entry in the subnet definition:
- throw if it is not a list
- ~~if it is not empty warn and remove it before parsing~~
- if it is not empty return an error
Please edit this and remove one of the choices whe...If there is a reservations entry in the subnet definition:
- throw if it is not a list
- ~~if it is not empty warn and remove it before parsing~~
- if it is not empty return an error
Please edit this and remove one of the choices when the list if not empty. IMHO the last one is better: drastic but do not suggest reservations were added to the database.
Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/442Update cb_cmds to handle types in global parameters2019-02-05T11:05:04ZFrancis DupontUpdate cb_cmds to handle types in global parametersCurrently global parameter values are handled as strings without any check. The idea is to extend to checked and typed representations. Or not? (so it is first a design ticket)Currently global parameter values are handled as strings without any check. The idea is to extend to checked and typed representations. Or not? (so it is first a design ticket)https://gitlab.isc.org/isc-projects/kea/-/issues/413Merge DHCPv6 global parameters fetched from the CB into the configuration2019-04-10T18:23:48ZMarcin SiodelskiMerge DHCPv6 global parameters fetched from the CB into the configuration`SrvConfig::merge` must be updated to merge global parameters into existing staging or current configuration.
After conferring with Marcin, we agreed to expand the scope of this issue to incorporate merging:
1. globals
2. options defs
...`SrvConfig::merge` must be updated to merge global parameters into existing staging or current configuration.
After conferring with Marcin, we agreed to expand the scope of this issue to incorporate merging:
1. globals
2. options defs
3. options
4. shared-networks
5. subnets
As this work is largely replicating what was done for v4.
Kea1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/507Tighten-up config-set checking so that servers more reliably roll-back and re...2020-07-27T08:51:45ZCathy AlmondTighten-up config-set checking so that servers more reliably roll-back and recover from invalid changesAs reported to us via [#14200](https://support.isc.org/Ticket/Display.html?id=14200):
We found a problem in how config-set is behaving when configuration has errors.
It is supposed to keep the old configuration, but instead the dhcp li...As reported to us via [#14200](https://support.isc.org/Ticket/Display.html?id=14200):
We found a problem in how config-set is behaving when configuration has errors.
It is supposed to keep the old configuration, but instead the dhcp listener stops responding to DHCP requests.
The scenario in which this was uncovered was pre-production system in which there's a client polling every 5 seconds, then a process reads the running configuration and changes the id of one of the subnets from:
"id": 1685525504,
to:
"id": "1685525504",
This incorrect configuration was due to a local process error but it is supposed to be handled by the config-set checking routine...
The error is logged as "invalid type specified for parameter 'id' (<wire>:0:15321)" and then the server is not receiving DHCP requests anymore, but still responds to commands from the ctrl-agent.
A restart is needed to unlock the service.
A log of the incident is available in Support ticket [#14200](https://support.isc.org/Ticket/Display.html?id=14200)kea1.7.10Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/549Implement reservation-update command2023-07-17T13:58:21ZTomek MrugalskiImplement reservation-update commandWe currently have commands that add, retrieve and delete host reservations. We're missing a command to update existing reservations.We currently have commands that add, retrieve and delete host reservations. We're missing a command to update existing reservations.kea2.3.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/565Client-Classes break KEA Config-Set API Call?2019-05-21T12:36:55ZGhost UserClient-Classes break KEA Config-Set API Call?---
name: Client-Classes break KEA Config-Set API Call?
about: Config-Set API call
---
**Describe the bug**
We've created a client-class for IP-phones in the KEA configuration. Now that we've started automating with the API we discover...---
name: Client-Classes break KEA Config-Set API Call?
about: Config-Set API call
---
**Describe the bug**
We've created a client-class for IP-phones in the KEA configuration. Now that we've started automating with the API we discovered an issue with the config-set API call, which reports a bad request.
The configuration is live, and KEA accepts it. However, even when we get the config through the API, and try to set it without changing it, it reports a "bad request".
**To Reproduce**
(Part of the) Config that works:
"shared-networks": [ ],
"client-classes": [
{
"name": "Innovaphone"
}
],
"subnet4": [
(Part of the) Config that doesn't work:
"shared-networks": [ ],
"client-classes": [
{
"name": "Innovaphone",
"test": "option[60].hex == '1.3.6.1.4.1.6666'",
"option-def": [
{
"name": "vendor-encapsulated-options",
"code": 43,
"type": "empty",
"encapsulate": "Innovaphone"
}
],
"option-data": [
{
"name": "h323-gatekeeper",
"code": 200,
"space": "Innovaphone",
"data": "10.90.249.1"
},
{
"name": "default-coder",
"code": 203,
"space": "Innovaphone",
"data": "G711A\\,20\\,k4/G711a\\,20\\,k4"
},
{
"name": "language",
"code": 204,
"space": "Innovaphone",
"data": "dut"
},
{
"name": "dialtone-type",
"code": 210,
"space": "Innovaphone",
"data": "0x2C"
},
{
"name": "update-URL",
"code": 215,
"space": "Innovaphone",
"data": "http://10.90.249.1/DRIVE/CF0/update/"
},
{
"name": "vendor-encapsulated-options",
"code": 43
}
]
}
],
"subnet4": [
**Expected behavior**
Being able to set the exact same config through the API that would work on the CLI.
**Environment:**
- Kea version: which release? KEA 1.4
- OS:Ubuntu 16.04 x64
**Contacting you**
gitlab / emailKea1.6Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/793Default port in CA config does not match default kea-shell config2019-11-25T16:27:28ZTomek MrugalskiDefault port in CA config does not match default kea-shell configThe example config that gets installed in /etc/kea/kea-ctrl-agent.conf uses port 8080, but kea-shell uses 8000 by default.
As a result, in the default configuration you need to pass extra switches, even though the software could work ou...The example config that gets installed in /etc/kea/kea-ctrl-agent.conf uses port 8080, but kea-shell uses 8000 by default.
As a result, in the default configuration you need to pass extra switches, even though the software could work out of the box.kea1.7.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/794Better handle cases of cb_cmds with control channel disabled2019-11-28T17:16:52ZTomek MrugalskiBetter handle cases of cb_cmds with control channel disabledThis config is supposed to showcase CB and CB commands, yet the control channel is disabled, so there's no way to send commands.
Couple things to consider:
- [x] change the config to use control channel (done in #804]
- [ ] cb_cmds (an...This config is supposed to showcase CB and CB commands, yet the control channel is disabled, so there's no way to send commands.
Couple things to consider:
- [x] change the config to use control channel (done in #804]
- [ ] cb_cmds (and all other command providing hooks) should warn if the control channel is disabled (only a warning, though, cb_cmds could be run on a different kea instance)
- [ ] consider that perhaps Kea should open the control channel by default and have an ability to disable it somehowhttps://gitlab.isc.org/isc-projects/kea/-/issues/836webinar request: command to trigger immediate CB update2019-10-04T20:22:54ZTomek Mrugalskiwebinar request: command to trigger immediate CB updateIn Kea 1.6 we introduced CB, a mechanism that lets Kea servers retrieve their configuration from database. They do it periodically. The interval is governed by ``config-fetch-wait-time``. During a webinar there was a request for a way to...In Kea 1.6 we introduced CB, a mechanism that lets Kea servers retrieve their configuration from database. They do it periodically. The interval is governed by ``config-fetch-wait-time``. During a webinar there was a request for a way to trigger immediate configuration retrieval.
We previously discussed a command that would do that, but were unable to implement it in 1.6 due to resources limitation. It's a good idea, so we should do it in 1.7.kea1.7.1https://gitlab.isc.org/isc-projects/kea/-/issues/910kea-ctrl-agent config-set and config-test commands not working properly2020-09-10T09:33:16ZWlodzimierz Wencelkea-ctrl-agent config-set and config-test commands not working properlyControl-agent accept almost anything as correct config while using `config-set` and `config-test` commands, it's just need to be proper JSON.
send:
```
{'arguments': {'Control-agent': {'AaAASDASDAsd': 'oijsadoeifbias'}},
'command': 'co...Control-agent accept almost anything as correct config while using `config-set` and `config-test` commands, it's just need to be proper JSON.
send:
```
{'arguments': {'Control-agent': {'AaAASDASDAsd': 'oijsadoeifbias'}},
'command': 'config-set'}
```
response:
```
{
"result": 0,
"text": "Configuration applied successfully."
}
```
send:
```
{'arguments': {'Control-agent': {'control-sockets': {'dhcp6': {'socket-name': '/tmp/control_socket',
'socket-type': 'SOMETHING'}},
'hooks-libraries': [],
'http-host': '192.168.50.252',
'http-port': 8000,
'reverse-ddns': {}}},
'command': 'config-test'}
```
response:
```
{
"result": 0,
"text": "Configuration check successful"
}
```
Kea configuration file:
```
{
"Control-agent": {
"control-sockets": {
"dhcp6": {
"socket-name": "/home/wlodek/installed/git/var/run/kea/control_socket",
"socket-type": "unix"
}
},
"http-host": "192.168.50.252",
"http-port": 8000
}
}
```
Kea/OS versions:
```
sbin/kea-ctrl-agent -V
1.7.0-git
git f07587f8c62ac1f431487cf591b2b38d08f1303f
```
```
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.11 (stretch)
Release: 9.11
Codename: stretch
```
```
Kea source configure results:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Package:
Name: kea
Version: 1.7.0-git
Extended version: 1.7.0-git (git f07587f8c62ac1f431487cf591b2b38d08f1303f)
OS Family: Linux
Prefix: /home/wlodek/installed/git
Hooks directory: /home/wlodek/installed/git/lib/kea/hooks
Premium hooks: yes
Included Hooks: forensic_log flex_id host_cmds subnet_cmds radius host_cache class_cmds cb_cmds
C++ Compiler:
CXX: ccache g++
CXX_VERSION: g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
CXX_STANDARD: 201402
DEFS: -DHAVE_CONFIG_H
CPPFLAGS: -DOS_LINUX
CXXFLAGS: -g -O2
LDFLAGS: -lpthread
KEA_CXXFLAGS: -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC
Python:
PYTHON: /usr/bin/python3
PYTHON_VERSION: 3.5
Boost:
BOOST_VERSION: 1.62
BOOST_INCLUDES:
BOOST_LIBS: -lboost_system
OpenSSL:
CRYPTO_VERSION: OpenSSL 1.0.2s 28 May 2019
CRYPTO_CFLAGS:
CRYPTO_INCLUDES:
CRYPTO_LDFLAGS:
CRYPTO_LIBS: -lcrypto
Botan: no
Log4cplus:
LOG4CPLUS_VERSION: 1.1.2
LOG4CPLUS_INCLUDES: -I/usr/include
LOG4CPLUS_LIBS: -L/usr/lib -llog4cplus
Flex/bison:
FLEX: flex
BISON: /usr/bin/bison
MySQL:
MYSQL_VERSION: 10.1.38
MYSQL_CPPFLAGS: -I/usr/include/mysql
MYSQL_LIBS: -L/usr/lib/x86_64-linux-gnu -lmariadbclient -lpthread -lz -lm -ldl -lcrypto
PostgreSQL:
PGSQL_VERSION: PostgreSQL 9.6.15
PGSQL_CPPFLAGS: -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/tcl8.6 -I/usr/include/postgresql -I/usr/include/postgresql/9.6/server
PGSQL_LIBS: -L/usr/lib/x86_64-linux-gnu -lpq
Cassandra CQL:
no
Sysrepo:
SYSREPO_VERSION: 0.7.8
SYSREPO_CPPFLAGS: -I/usr/local/include
SYSREPO_LIBS: -L/usr/local/lib -lsysrepo -L/usr/local/lib -lSysrepo-cpp
SYSREPO_REPO: /etc/sysrepo
Google Test:
no
Google Benchmark:
no
FreeRADIUS client:
FREERADIUS_INCLUDE: -I/usr/local/include
FREERADIUS_LIB: -L/usr/local/lib -lfreeradius-client
FREERADIUS_DICTIONARY: /usr/local/etc/radiusclient/dictionary
Developer:
Enable Debugging: no
Google Tests: no
Google Benchmark: no
Valgrind: found
C++ Code Coverage: no
Logger checks: no
Generate Documentation: no
Generate Parser: no
Generate Messages Files: no
Perfdhcp: yes
Kea-shell: yes, install to ${prefix}/lib/python3.5/site-packages
```https://gitlab.isc.org/isc-projects/kea/-/issues/941Incorrect handling of backslashes2020-08-01T10:38:52ZFGIncorrect handling of backslashesIn debian packages for KEA 1.6.0, the provided default config file contain the following logger:
```
"loggers": [
{
"debuglevel": 0,
"name": "kea-dhcp4",
"output_options": [
{
"out...In debian packages for KEA 1.6.0, the provided default config file contain the following logger:
```
"loggers": [
{
"debuglevel": 0,
"name": "kea-dhcp4",
"output_options": [
{
"output": "stdout",
"pattern": "%-5p %mn"
}
],
"severity": "INFO"
}
],
```
The pattern probably should be `"pattern": "%-5p %m\n"` instead. Same issue in DHCPv6 conf file.
This create unreadable logs in journald (missing line break)kea1.8.0https://gitlab.isc.org/isc-projects/kea/-/issues/1023Active status for HA servers2020-01-27T15:27:45ZPeter DaviesActive status for HA servers---
name: Active status for HA servers
about: #15534: Kea API - Statistics & HA - Inaccurate Counters and Unable to get HA
A Request to be able to retrieve via hook libraries the active/standby status of a HA server.
At present during n...---
name: Active status for HA servers
about: #15534: Kea API - Statistics & HA - Inaccurate Counters and Unable to get HA
A Request to be able to retrieve via hook libraries the active/standby status of a HA server.
At present during normal operations both servers will return status = hot-standby.kea1.7.3Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1041kea daemons could expose some runtime information for stork2021-11-30T15:47:57ZMichal Nowikowskikea daemons could expose some runtime information for storkit could be a new command: runtime-info-get or something like that
Information could include:
- pid
- start time or uptime
- current, running user
- last config reload time
- etc.it could be a new command: runtime-info-get or something like that
Information could include:
- pid
- start time or uptime
- current, running user
- last config reload time
- etc.kea1.7.3Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1106Resend DDNS entry via API call2020-03-19T15:07:13ZVicky Riskvicky@isc.orgResend DDNS entry via API callFeature request
Customer request for an api call to resend the DDNS entry in case it was lost or somehow needs to be updated.Feature request
Customer request for an api call to resend the DDNS entry in case it was lost or somehow needs to be updated.kea1.7.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1115Add an exit value argument to the command channel shutdown command2020-03-04T13:19:03ZThomas MarkwalderAdd an exit value argument to the command channel shutdown commandWith #1108, Kea servers will do a graceful shutdown if a db cannot be recovered. However, this causes an exit status of 0 rather than something non-zero (the "standard" for failed process). Some users may object to this. If we add an...With #1108, Kea servers will do a graceful shutdown if a db cannot be recovered. However, this causes an exit status of 0 rather than something non-zero (the "standard" for failed process). Some users may object to this. If we add an exit value argument to the shutdown command, we could readily set it accordingly. In addition, users could use this mechanism to customize their own operations, by assigning their own meaning to their own exit values.kea1.7.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1120Refine reverse proxy for kea2021-06-28T08:22:33ZRazvan BecheriuRefine reverse proxy for keaWhen we implemented Kea Control Agent we considered whether we should provide a built-in solution for https or not. At that time, it seemed reasonable to rely on third party HTTP servers, such as nginx to provide reverse proxy function b...When we implemented Kea Control Agent we considered whether we should provide a built-in solution for https or not. At that time, it seemed reasonable to rely on third party HTTP servers, such as nginx to provide reverse proxy function because we don't have the maintain the security critical code. The third party HTTP servers are trustworthy when it comes to security. However, we've had reports that installing such a third party software is not always possible, especially when talking about large installations.
This ticket resumes the discussion how we could possibly provide a viable alternative to third party reverse proxies and ship something with Kea that would provide similar function and would be easy to install, deploy and run.
A discussion/high level design page is here: https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent-discussionKea1.9-backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/145feature request: ability to get lease count per pool2023-07-17T13:58:21ZGhost Userfeature request: ability to get lease count per pooltoday, when using the api command - "statistic-get-all"
we are getting a lease count at the subnet level,
i'm asking to get a count at the pool level.
thank you
#huge-sorrytoday, when using the api command - "statistic-get-all"
we are getting a lease count at the subnet level,
i'm asking to get a count at the pool level.
thank you
#huge-sorrykea2.3.8Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1170Lease Cmds addLeaseX commands return success when called more than once with...2020-05-07T16:38:00ZThomas MarkwalderLease Cmds addLeaseX commands return success when called more than once with the same leaseA user reported issuing the lease4-add command for an existing lease (i.e. more than once in a row) return success and a message stating that the lease was successfully added. In reality, the command handler calls LeaseMgr::addLease4()...A user reported issuing the lease4-add command for an existing lease (i.e. more than once in a row) return success and a message stating that the lease was successfully added. In reality, the command handler calls LeaseMgr::addLease4() but ignores the return value, which is false if the lease already exists.
This is bound to lead to confusion for the user. If the subsequent add changed values other than subnet id and address, the user might expect those values to have been updated when in fact they have not. They also could not use the result to know if a lease already exists.
It should return CONTROL_RESULT_ERROR with an explanation that it already exists. This would be consistent with other hook libraries such as subnet cmds and host cmds.kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1240extend JSON files describing commands2020-09-17T14:17:29ZFrancis Dupontextend JSON files describing commandsIn application of https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent#proposal-32-extend-json-files add an access entry with read or write values to the JSON files describing commands in `doc/sphinx/ap...In application of https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent#proposal-32-extend-json-files add an access entry with read or write values to the JSON files describing commands in `doc/sphinx/api`:
- update README
- update template and generator
- update all command files
- update api2doc script
- update Makefile so these files are installedkea1.9.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1305status-get should give information about service thread count2020-08-18T20:37:25ZRazvan Becheriustatus-get should give information about service thread countkea1.8.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1391commands lease4-get-by-* returning empty parameters in not consistent way.2022-07-18T12:17:36ZWlodzimierz Wencelcommands lease4-get-by-* returning empty parameters in not consistent way.Example show lease of client that send hostname and client-id; both are returned in `lease4-get-by-* ` commands
```
{'arguments': {'hostname': 'four.hostname.com.'}, 'command': 'lease4-get-by-hostname'}
```
```
{
"arguments": {
"l...Example show lease of client that send hostname and client-id; both are returned in `lease4-get-by-* ` commands
```
{'arguments': {'hostname': 'four.hostname.com.'}, 'command': 'lease4-get-by-hostname'}
```
```
{
"arguments": {
"leases": [
{
"client-id": "00:01:02:03:04:05:06",
"cltt": 1597923930,
"fqdn-fwd": true,
"fqdn-rev": true,
"hostname": "four.hostname.com.",
"hw-address": "08:08:08:08:08:08",
"ip-address": "192.168.50.5",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv4 lease(s) found."
}
```
but when client will not send hostname nor client-id response is this:
```
{
"arguments": {
"leases": [
{
"cltt": 1597924174,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "10:10:10:10:10:10",
"ip-address": "192.168.51.10",
"state": 0,
"subnet-id": 2,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv4 lease(s) found."
}
```
parameter hostname is included but it's empty, and client-id is missing. It should also be included as an empty parameter.kea2.2.0 - a new stable branchThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/432for bad formed cmds sent over http class-cmds sometimes return dictionary in...2020-12-14T10:43:26ZMichal Nowikowskifor bad formed cmds sent over http class-cmds sometimes return dictionary instead of listthis in case of e.g.:
```json
{"command": "class-add", "arguments": {"client-classes": [{"name": "ipxe"}]}, "extra_arg": {}}
```this in case of e.g.:
```json
{"command": "class-add", "arguments": {"client-classes": [{"name": "ipxe"}]}, "extra_arg": {}}
```kea1.9.3Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1652Comments in API commands2021-04-23T18:41:31ZTomek MrugalskiComments in API commandsThere's a customer who has a nicely commented config file with many commands. He had problems when sending this as API commands. We should look at whether the API parser is able to handle the comments correctly.
the customer reported se...There's a customer who has a nicely commented config file with many commands. He had problems when sending this as API commands. We should look at whether the API parser is able to handle the comments correctly.
the customer reported seeing a 400 http error.kea1.9.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1716Expose listening socket status in status-get command or maybe add option to m...2022-06-13T14:42:04ZMike KazantsevExpose listening socket status in status-get command or maybe add option to make bind-fails fatalCurrently, when Kea DHCP daemon starts up, something like this can happen:
```
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface kea, reason: failed to bind ...Currently, when Kea DHCP daemon starts up, something like this can happen:
```
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface kea, reason: failed to bind fallback socket to address 10.67.2.1, port 67, reason: Address already in use - is another DHCP server running?
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface kea, reason: failed to bind fallback socket to address 10.67.3.1, port 67, reason: Address already in use - is another DHCP server running?
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
```
Iirc it can also not bind sockets if there's no address on the interface, which can be quite common if there's some race condition on e.g. system startup.
These are warnings which indicate that dhcp service is not working and will never work until daemon restart or reconfiguration.
Reporting these as warnings is somewhat different from how most services work on unix/linux.\
For example, if apache/nginx listening sockets are unavailable on startup, they will immediately exit instead of running in an unusable state by default.
It's understandable that multiple sockets can be defined (probably?), and binding some of these can fail, but I'd propose that expected/intuitive default behavior should still likely be to exit with a fatal error if any of sockets defined on startup are unavailable.\
And in fact, Kea already does that with e.g. control sockets - any conflict there results in an immediate exit, but not actual service sockets, which I think is confusing and unexpected default behavior, though it might be documented, and hard to change in a backwards-compatible way at this point.
But regardless of that, I'd propose that there should be at least an obvious and simple way to query Kea for "are you actually listening on any sockets, or just failed to start the service?" question.\
Maybe status-get command would be a good place to return list of listening sockets in, given that it seem to be a status of a very important daemon component.\
My use-case for such query is to check whether Kea daemon should be immediately killed and exit with error from a wrapper script, if it fails to open service sockets after start or reconfiguration.
Is there maybe some other way to check this status or instruct Kea to treat such "warnings" as proper failures that I'm just not aware of?
Don't think I'm good enough with C++ and familiar enough with Kea internals to implement it in any upstream-useful way myself, unfortunately, but wanted to suggest it as a useful feature, or at least create a thread which maybe can be found if someone else also finds this behaviour counter-intuitive, with some kind of workaround suggestion or maybe a resolution.
Thanks for consideration.kea2.1.5Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/kea/-/issues/1730HA+MT:Create config::CmdHttpListener2021-08-17T15:10:27ZThomas MarkwalderHA+MT:Create config::CmdHttpListenerThis is the first ticket in the HA+MT effort. It covers the implementation of the CmdHttpListener class as described in the HA+MT design:
https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/HA-MT-Design-for-Multi-threaded-Http-HA-t...This is the first ticket in the HA+MT effort. It covers the implementation of the CmdHttpListener class as described in the HA+MT design:
https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/HA-MT-Design-for-Multi-threaded-Http-HA-traffic.
The class will be added to the libkea-cfgclient library (i.e isc::config namespace).
At the completion of the ticket, the class should be fully functional and unit tested, but not instantiated or referenced in production runtime code.kea1.9.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1736Modify HA hook to instantiate CmdHttpListener (and enable client MT)2021-06-28T09:51:56ZTomek MrugalskiModify HA hook to instantiate CmdHttpListener (and enable client MT)This is the sixth ticket in the HA+MT effort. It covers the modifications of the HA hook to instantiate the CmdHttpListener to be able to support multiple parallel incoming connections, as described in the [HA+MT design](https://gitlab.i...This is the sixth ticket in the HA+MT effort. It covers the modifications of the HA hook to instantiate the CmdHttpListener to be able to support multiple parallel incoming connections, as described in the [HA+MT design](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/HA-MT-Design-for-Multi-threaded-Http-HA-traffic).
Once this ticket is complete, the server-side of the HA hook with become operational. However, to take advantage of it, #1735 will be required.kea1.9.7Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2209reservation-get-by-hostname: subnet-id not in response if it is in request2022-06-30T09:53:14ZAndrei Pavelandrei@isc.orgreservation-get-by-hostname: subnet-id not in response if it is in requestExpected `subnet-id` to be contained in response regardless of arguments.
This is useful when users switch between API calls and they expect the response to be the same when, for example, they parse the response or they chain API calls.Expected `subnet-id` to be contained in response regardless of arguments.
This is useful when users switch between API calls and they expect the response to be the same when, for example, they parse the response or they chain API calls.kea2.1.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2216Small errors in status-get command documentation2022-01-12T18:09:37ZMarcin GodzinaSmall errors in status-get command documentation16.15.19.5 in Kea documentation lacks **"packet-queue-statistics"** field in example response which is included if "multi-threading-enabled" is true.
For example we can add `"packet-queue-statistics": [ 0.0, 0.0, 0.0 ]` after `"packet-qu...16.15.19.5 in Kea documentation lacks **"packet-queue-statistics"** field in example response which is included if "multi-threading-enabled" is true.
For example we can add `"packet-queue-statistics": [ 0.0, 0.0, 0.0 ]` after `"packet-queue-size": 64`
18.3.13 in Kea documentation lists *thread-pool-size* and *packet-queue-size* being returned only when multi-threading is enabled but omits **packet-queue-statistics** in this list.
Issue applicable to dhcpv4 and dhcpv6kea2.1.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2233ARM shows "option-data-list" field instead of "option-data" for reservation-add2022-01-14T14:04:10ZAndrei Pavelandrei@isc.orgARM shows "option-data-list" field instead of "option-data" for reservation-addIf you try to `reservation-add` with `"option-data-list"` as the [ARM suggests](https://kea.readthedocs.io/en/latest/api.html#ref-reservation-add), you get `"unsupported configuration parameter 'option-data-list' (:0:0)"`. `"option-data"...If you try to `reservation-add` with `"option-data-list"` as the [ARM suggests](https://kea.readthedocs.io/en/latest/api.html#ref-reservation-add), you get `"unsupported configuration parameter 'option-data-list' (:0:0)"`. `"option-data"` works however.kea2.1.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2465API Reference network6-* command2022-06-30T13:32:02ZPeter DaviesAPI Reference network6-* commandAPI Reference network6-* command
The examples given in the API Reference for some network6-* commands are from network4-* commands
for example:
https://kea.readthedocs.io/en/kea-2.1.6/api.html#network6-addAPI Reference network6-* command
The examples given in the API Reference for some network6-* commands are from network4-* commands
for example:
https://kea.readthedocs.io/en/kea-2.1.6/api.html#network6-addkea2.2.0 - a new stable branchRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2471reservation-get and reservation-get-all do not return subnet-id2023-07-17T13:58:25ZMarcin Godzinareservation-get and reservation-get-all do not return subnet-idAfter implementing isc-projects/kea#2209 we have still 2 commands, that are inconsistent with others and do not return `subnet-id` when it is included in request:
```
Does NOT return `subnet-id` which is mandatory in the request:
reserva...After implementing isc-projects/kea#2209 we have still 2 commands, that are inconsistent with others and do not return `subnet-id` when it is included in request:
```
Does NOT return `subnet-id` which is mandatory in the request:
reservation-get
reservation-get-all
Always returns `subnet-id`:
reservation-get-page
reservation-get-by-hostname
reservation-get-by-id
```kea2.3.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2507Replace use of CriticalSection in stat-leaseX-get commands with Memfile_Lease...2023-07-17T13:58:24ZThomas MarkwalderReplace use of CriticalSection in stat-leaseX-get commands with Memfile_LeaseMgr mutex lockThe command handlers for stat-leaseX-get commands create CriticalSections upon entry. We should be able to replace those with simply locking the Memfile lease manager's mutex like so:
```
tmark@wild-dog:stat_cmds (master) $ git diff
dif...The command handlers for stat-leaseX-get commands create CriticalSections upon entry. We should be able to replace those with simply locking the Memfile lease manager's mutex like so:
```
tmark@wild-dog:stat_cmds (master) $ git diff
diff --git a/src/hooks/dhcp/stat_cmds/stat_cmds.cc b/src/hooks/dhcp/stat_cmds/stat_cmds.cc
index 8950bc928f..b9fe1800d2 100644
--- a/src/hooks/dhcp/stat_cmds/stat_cmds.cc
+++ b/src/hooks/dhcp/stat_cmds/stat_cmds.cc
@@ -718,7 +718,9 @@ int
StatCmds::statLease4GetHandler(CalloutHandle& handle) {
try {
LeaseStatCmdsImpl impl;
+#if 0
MultiThreadingCriticalSection cs;
+#endif
return (impl.statLease4GetHandler(handle));
} catch (const std::exception& ex) {
diff --git a/src/lib/dhcpsrv/memfile_lease_mgr.cc b/src/lib/dhcpsrv/memfile_lease_mgr.cc
index afb3259840..86f95d2cd9 100644
--- a/src/lib/dhcpsrv/memfile_lease_mgr.cc
+++ b/src/lib/dhcpsrv/memfile_lease_mgr.cc
@@ -1990,7 +1990,16 @@ Memfile_LeaseMgr::lfcExecute(boost::shared_ptr<LeaseFileType>& lease_file) {
LeaseStatsQueryPtr
Memfile_LeaseMgr::startLeaseStatsQuery4() {
LeaseStatsQueryPtr query(new MemfileLeaseStatsQuery4(storage4_));
+#if 1
+ if (MultiThreadingMgr::instance().getMode()) {
+ std::lock_guard<std::mutex> lock(*mutex_);
+ query->start();
+ } else {
+ query->start();
+ }
+#else
query->start();
+#endif
return(query);
}
```
I compiled with thread-sanitizer on Ubuntu 20.04, and ran kea-dhcp4 stand-alone in MT mode (8 threads), used traffic. I used a script to call socat locally to generate stat-lease4-get() at a rate every 100 ms. Each test started with an empty lease file and ran for sixty seconds. I tested three variations of the code 1: with CriticalSection 2: without CriticalSection or Mutex 3: With Mutex. The results are attached:
[out.txt](/uploads/98731c35c802a4d2a57c43269ba70543/out.txt)
All three versions report one or two race warnings in StringSanitizerImpl, this is known false report.
The version without CS or mutex had almost 90 race warnings emanating from alloc engine, which one would expect. The mutex-ed version is slightly faster than the CriticalSection version, and I suspect the difference would be larger if running HA+MT as a CS would cause both thread pools to pause/resume.
The stat commands do not need to create a CriticalSection and therefore should not. We might consider the same approach for the lease wipe commands.kea2.3.1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2725lease prefix-len is not checked in lease commands for PD type2023-07-17T13:58:20ZRazvan Becheriulease prefix-len is not checked in lease commands for PD typethe following UT which passes, is using a wrong prefix-length for the prefix (type PD):
```
txt =
"{\n"
" \"command\": \"lease6-add\",\n"
" \"arguments\": {"
" \"subnet-id\": 66,\n"
...the following UT which passes, is using a wrong prefix-length for the prefix (type PD):
```
txt =
"{\n"
" \"command\": \"lease6-add\",\n"
" \"arguments\": {"
" \"subnet-id\": 66,\n"
" \"ip-address\": \"2001:db8:1::1\",\n"
" \"prefix-len\": 48,\n"
" \"type\": \"IA_PD\",\n"
" \"duid\": \"1a:1b:1c:1d:1e:1f\",\n"
" \"iaid\": 1234,\n"
" \"state\": 1"
" }\n"
"}";
```
clearly a check on the prefix length is missing from the code in lease commandskea2.4.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2707ability to detect Kea config changes (config-hash-get)2023-07-17T13:58:20ZTomek Mrugalskiability to detect Kea config changes (config-hash-get)There was a [discussion in Porto](https://pad.isc.org/p/porto2022-kea-features-for-stork#L19) about detecting out of bounds configuration changes in Kea. The overall idea is that Stork should be able to detect somewhat easily if Kea's co...There was a [discussion in Porto](https://pad.isc.org/p/porto2022-kea-features-for-stork#L19) about detecting out of bounds configuration changes in Kea. The overall idea is that Stork should be able to detect somewhat easily if Kea's config has changed, e.g. by sysadmin or some external tool.
Couple ideas were discussed:
- storing timestamp of last modification
- using hash
- using monotonic counter
- using journal file or auditlog
The overall idea is that Stork (and other monitoring tools) should be able to reasonably easily answer the question whether configuration was modified or not. It is essential the question/answer should be relatively low cost as Stork and other monitoring tools tend to look at Kea's config frequently (e.g. every 15 seconds) and the config changes are typically rare events.
This requires a short ~design.kea2.4.0Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2623Add commands to [B]LQ hook2023-05-19T16:20:15ZFrancis DupontAdd commands to [B]LQ hookAdd commands to manipulate BLQ tables from the [B]LQ hook.Add commands to manipulate BLQ tables from the [B]LQ hook.outstandingFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2575Segmentation fault using REST API in DHCPv4 HA setting2023-07-18T09:27:20ZcacianoSegmentation fault using REST API in DHCPv4 HA settingHi,
This issue has been reported in the kea-users mailing list yesterday and
Andrei Pavel asked to create an issue here with a few extra details.
I am trying to configure a pair of kea servers running in high
availability mode. Howeve...Hi,
This issue has been reported in the kea-users mailing list yesterday and
Andrei Pavel asked to create an issue here with a few extra details.
I am trying to configure a pair of kea servers running in high
availability mode. However, the servers crash with segfault when I try
to use the HTTP RESP API for some commands. I figured out how to
reproduce the problem in one situation described below.
The server is a Ubuntu 22.04 LTS, running kea 2.2.0 from the repository
https://dl.cloudsmith.io/public/isc/kea-2-2/deb/ubuntu jammy main.
The server is a Xen VM with 2GB of RAM, kernel 5.15.0-43-generic
#46-Ubuntu SMP and glibc 2.35.
This following python script loads a configuration file and calls
config-set using the HTTP API.
```python
#!/usr/bin/python3
#coding: utf-8
import json, requests
with open('bug-config.json') as f:
config = json.load(f)
url = 'http://192.168.89.12:8000/'
headers = {'content-type': 'application/json'}
payload = {}
payload['command'] = 'config-set'
payload['service'] = [ 'dhcp4' ]
payload['arguments'] = config
res = requests.post(url, headers=headers, data=json.dumps(payload))
response = res.json()[0]
print('Set config: ' + response['text'])
```
The configuration file sent using the API is this one, without the
shared-networks section. The problem also happens when I send a complete
configuration, but this small one is enough to reproduce the problem.
The configuration file running in the server when I send the config-set
is the same, but has about 19000 host reservations identified by the
hw-address, distributed in 180 networks that are in 90 shared-networks.
```json
{
"Dhcp4": {
"authoritative": true,
"client-classes": [
{
"name": "718",
"option-data": [
{
"data": "192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "708",
"option-data": [
{
"data": "192.168.137.7,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "533",
"option-data": [
{
"data": "192.168.137.7,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "791",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "792",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "793",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "794",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "795",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "532",
"option-data": [
{
"data":
"192.168.148.22,192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "561",
"option-data": [
{
"data": "192.168.2.165,192.168.2.166",
"name": "domain-name-servers"
}
]
},
{
"name": "568",
"option-data": [
{
"data": "192.168.162.105, 192.168.1.52, 192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "118",
"option-data": [
{
"data": "ifch.ufrgs.br",
"name": "domain-name"
}
]
},
{
"name": "527",
"option-data": [
{
"data":
"192.168.150.20,192.168.150.23,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
}
],
"control-socket": {
"socket-name": "/tmp/kea4-ctrl-socket",
"socket-type": "unix"
},
"dhcp-ddns": {
"enable-updates": false
},
"expired-leases-processing": {
"hold-reclaimed-time": 401
},
"hooks-libraries": [
{
"library":
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_bootp.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"heartbeat-delay": 10000,
"max-unacked-clients": 20,
"min-ack-delay": 5000,
"mode": "hot-standby",
"peers": [
{
"auto-failover": true,
"name": "dhcp",
"role": "primary",
"url": "http://192.168.89.14:8000/"
},
{
"auto-failover": true,
"name": "dhcp-standby",
"role": "standby",
"url": "http://192.168.89.12:8000/"
}
],
"send-lease-updates": false,
"sync-leases": false,
"this-server-name": "dhcp-standby"
}
]
}
}
],
"host-reservation-identifiers": [
"hw-address"
],
"interfaces-config": {
"dhcp-socket-type": "udp",
"interfaces": [
"eth0/192.168.89.12"
]
},
"ip-reservations-unique": true,
"lease-database": {
"lfc-interval": 3600,
"max-row-errors": 100,
"name": "/var/lib/kea/kea-leases4.csv",
"type": "memfile"
},
"loggers": [
{
"debuglevel": 15,
"name": "kea-dhcp4",
"output_options": [
{
"maxver": 32,
"output": "/var/log/kea/kea-dhcp4-server.log"
}
],
"severity": "INFO"
}
],
"match-client-id": false,
"max-valid-lifetime": 1800,
"min-valid-lifetime": 360,
"option-def": [
{
"code": 252,
"name": "wpad",
"type": "string"
},
{
"code": 128,
"name": "option-128",
"type": "string"
},
{
"code": 129,
"name": "etherboot_options",
"type": "string"
}
],
"reservations-global": false,
"reservations-in-subnet": true,
"reservations-lookup-first": true,
"reservations-out-of-pool": true,
"sanity-checks": {
"lease-checks": "fix-del"
},
"store-extended-info": true,
"valid-lifetime": 1800
}
}
```
When the server crashes then "systemctl status" gives the following output:
```
root@keadhcp-dev-02:/etc/kea# systemctl status isc-kea-dhcp4-server.service
× isc-kea-dhcp4-server.service - Kea IPv4 DHCP daemon
Loaded: loaded (/lib/systemd/system/isc-kea-dhcp4-server.service;
enabled; vendor preset: enabled)
Active: failed (Result: core-dump) since Wed 2022-09-21 18:57:31
UTC; 16min ago
Docs: man:kea-dhcp4(8)
Process: 1231471 ExecStart=/usr/sbin/kea-dhcp4 -c
/etc/kea/kea-dhcp4.conf (code=dumped, signal=SEGV)
Main PID: 1231471 (code=dumped, signal=SEGV)
CPU: 7.494s
Sep 21 18:57:19 keadhcp-dev-02 systemd[1]: Started Kea IPv4 DHCP daemon.
Sep 21 18:57:31 keadhcp-dev-02 systemd[1]: isc-kea-dhcp4-server.service:
Main process exited, code=dumped, status=11/SEGV
Sep 21 18:57:31 keadhcp-dev-02 systemd[1]: isc-kea-dhcp4-server.service:
Failed with result 'core-dump'.
Sep 21 18:57:31 keadhcp-dev-02 systemd[1]: isc-kea-dhcp4-server.service:
Consumed 7.494s CPU time.
```
The crash file has the following data in the first lines:
```
root@keadhcp-dev-02:/etc/kea# head -n 73
/var/crash/_usr_sbin_kea-dhcp4.113.crash
ProblemType: Crash
Architecture: amd64
CrashCounter: 1
Date: Mon Sep 19 18:19:50 2022
DistroRelease: Ubuntu 22.04
ExecutablePath: /usr/sbin/kea-dhcp4
ExecutableTimestamp: 1653069600
ProcCmdline: /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
ProcMaps: Error: [Errno 13] Permission denied: 'maps'
ProcStatus:
Name: kea-dhcp4
Umask: 0022
State: S (sleeping)
Tgid: 1159118
Ngid: 0
Pid: 1159118
PPid: 1
TracerPid: 0
Uid: 113 113 113 113
Gid: 118 118 118 118
FDSize: 64
Groups: 118
NStgid: 1159118
NSpid: 1159118
NSpgid: 1159118
NSsid: 1159118
VmPeak: 213420 kB
VmSize: 184160 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 155992 kB
VmRSS: 124736 kB
RssAnon: 110380 kB
RssFile: 14356 kB
RssShmem: 0 kB
VmData: 149112 kB
VmStk: 132 kB
VmExe: 628 kB
VmLib: 17112 kB
VmPTE: 348 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 1
THP_enabled: 1
Threads: 5
SigQ: 0/7428
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000100004003
CapInh: 0000000000002400
CapPrm: 0000000000002400
CapEff: 0000000000002400
CapBnd: 000001ffffffffff
CapAmb: 0000000000002400
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: vulnerable
SpeculationIndirectBranch: always enabled
Cpus_allowed: 000f
Cpus_allowed_list: 0-3
Mems_allowed:
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 136
nonvoluntary_ctxt_switches: 304
Signal: 11
Uname: Linux 5.15.0-43-generic x86_64
UserGroups: N/A
CoreDump: base64
H4sICAAAAAAC/0NvcmVEdW1wAA==
......
```
I extracted the core dump file from the crash file with 'apport-unpack /var/crash/_usr_sbin_kea-dhcp4.113.crash test'
and the output from 'gdb /usr/sbin/kea-dhcp4 CoreDump -ex "thread apply all bt" -ex "quit"' is:
```
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/kea-dhcp4...
(No debugging symbols found in /usr/sbin/kea-dhcp4)
[New LWP 1232251]
[New LWP 1232253]
[New LWP 1232252]
[New LWP 1232254]
[New LWP 1232255]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f271676eda0 in ?? ()
[Current thread is 1 (Thread 0x7f2719375e80 (LWP 1232251))]
Thread 5 (Thread 0x7f2717b6f640 (LWP 1232255)):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555c55628350, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007f271aab0ac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555c556282d0, cond=0x555c55628328) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x555c55628328, mutex=0x555c556282d0) at ./nptl/pthread_cond_wait.c:627
#5 0x00007f271adfa77d in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2719ce2a91 in progschj::ThreadPool::emplace_back_worker(unsigned long)::{lambda()#1}::operator()() const () from /lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3
#7 0x00007f271ae2a2b3 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007f271aab1b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9 0x00007f271ab43a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 4 (Thread 0x7f2718370640 (LWP 1232254)):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555c55628350, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007f271aab0ac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555c556282d0, cond=0x555c55628328) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x555c55628328, mutex=0x555c556282d0) at ./nptl/pthread_cond_wait.c:627
#5 0x00007f271adfa77d in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2719ce2a91 in progschj::ThreadPool::emplace_back_worker(unsigned long)::{lambda()#1}::operator()() const () from /lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3
#7 0x00007f271ae2a2b3 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007f271aab1b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9 0x00007f271ab43a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 3 (Thread 0x7f2719372640 (LWP 1232252)):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555c55628350, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007f271aab0ac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555c556282d0, cond=0x555c55628328) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x555c55628328, mutex=0x555c556282d0) at ./nptl/pthread_cond_wait.c:627
#5 0x00007f271adfa77d in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2719ce2a91 in progschj::ThreadPool::emplace_back_worker(unsigned long)::{lambda()#1}::operator()() const () from /lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3
#7 0x00007f271ae2a2b3 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007f271aab1b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9 0x00007f271ab43a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 2 (Thread 0x7f2718b71640 (LWP 1232253)):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555c55628350, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007f271aab0ac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555c556282d0, cond=0x555c55628328) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x555c55628328, mutex=0x555c556282d0) at ./nptl/pthread_cond_wait.c:627
#5 0x00007f271adfa77d in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2719ce2a91 in progschj::ThreadPool::emplace_back_worker(unsigned long)::{lambda()#1}::operator()() const () from /lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3
#7 0x00007f271ae2a2b3 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007f271aab1b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9 0x00007f271ab43a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 1 (Thread 0x7f2719375e80 (LWP 1232251)):
#0 0x00007f271676eda0 in ?? ()
#1 0x00007f271b1ebed7 in isc::asiolink::IntervalTimerImpl::~IntervalTimerImpl() () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#2 0x00007f271b1f58c6 in ?? () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#3 0x00007f271b1e8f8a in ?? () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#4 0x00007f271b1ea775 in boost::asio::detail::wait_handler<std::_Bind<void (isc::asiolink::IntervalTimerImpl::*(boost::shared_ptr<isc::asiolink::IntervalTimerImpl>, std::_Placeholder<1>))(boost::system::error_code const&)>, boost::asio::execution::any_executor<boost::asio::execution::context_as_t<boost::asio::execution_context&>, boost::asio::execution::detail::blocking::never_t<0>, boost::asio::execution::prefer_only<boost::asio::execution::detail::blocking::possibly_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0> > > >::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#5 0x00007f271b1f5d3d in isc::asiolink::IOService::poll() () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#6 0x0000555c53d66501 in ?? ()
#7 0x00007f271aa46d90 in __libc_start_call_main (main=main@entry=0x555c53d658c0, argc=argc@entry=3, argv=argv@entry=0x7ffd7f3489b8) at ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x00007f271aa46e40 in __libc_start_main_impl (main=0x555c53d658c0, argc=3, argv=0x7ffd7f3489b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd7f3489a8) at ../csu/libc-start.c:392
#9 0x0000555c53d689a5 in ?? ()
```
------------------------------------------------------------------------------
The last messages in the log file /var/log/kea/kea-dhcp4-server.log are
these:
```
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.commands/1232318.139712599805568]
COMMAND_SOCKET_CONNECTION_OPENED Opened socket 26 for incoming command
connection
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer:
flush-reclaimed-leases
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.alloc-engine/1232318.139712599805568]
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed
leases expired more than 3600 seconds ago
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases
that expired more than 3600 seconds ago
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.alloc-engine/1232318.139712599805568]
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0
expired-reclaimed leases
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.dhcpsrv/1232318.139712599805568] DHCPSRV_TIMERMGR_START_TIMER
starting timer: flush-reclaimed-leases
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.commands/1232318.139712599805568] COMMAND_SOCKET_READ
Received 3597 bytes over command socket 26
2022-09-21 19:30:04.976 INFO
[kea-dhcp4.commands/1232318.139712599805568] COMMAND_RECEIVED Received
command 'config-set'
2022-09-21 19:30:04.977 INFO [kea-dhcp4.hosts/1232318.139712599805568]
HOSTS_BACKENDS_REGISTERED the following host backend types are
available: mysql postgresql
2022-09-21 19:30:04.977 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type udp
2022-09-21 19:30:04.977 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_CFGMGR_USE_ADDRESS listening on address 192.168.89.12, on
interface eth0
2022-09-21 19:30:04.977 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so successfully
closed
2022-09-21 19:30:04.978 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_bootp.so successfully closed
2022-09-21 19:30:04.978 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so successfully closed
2022-09-21 19:30:04.979 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_DEINIT_OK unloading High
Availability hooks library successful
2022-09-21 19:30:04.979 INFO
[kea-dhcp4.bootp-hooks/1232318.139712599805568] BOOTP_UNLOAD Bootp hooks
library has been unloaded
2022-09-21 19:30:04.979 INFO
[kea-dhcp4.lease-cmds-hooks/1232318.139712599805568]
LEASE_CMDS_DEINIT_OK unloading Lease Commands hooks library successful
2022-09-21 19:30:04.980 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so successfully closed
2022-09-21 19:30:04.980 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_bootp.so successfully closed
2022-09-21 19:30:04.980 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so successfully
closed
2022-09-21 19:30:04.982 INFO
[kea-dhcp4.lease-cmds-hooks/1232318.139712599805568] LEASE_CMDS_INIT_OK
loading Lease Commands hooks library successful
2022-09-21 19:30:04.982 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_LOADED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so successfully
loaded
2022-09-21 19:30:04.982 INFO
[kea-dhcp4.bootp-hooks/1232318.139712599805568] BOOTP_LOAD Bootp hooks
library has been loaded
2022-09-21 19:30:04.982 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_LOADED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_bootp.so successfully loaded
2022-09-21 19:30:04.984 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_CONFIGURATION_SUCCESSFUL
HA hook library has been successfully configured
2022-09-21 19:30:04.984 WARN
[kea-dhcp4.ha-hooks/1232318.139712599805568]
HA_CONFIG_LEASE_UPDATES_DISABLED lease updates will not be generated
2022-09-21 19:30:04.984 WARN
[kea-dhcp4.ha-hooks/1232318.139712599805568]
HA_CONFIG_LEASE_SYNCING_DISABLED lease database synchronization between
HA servers is disabled
2022-09-21 19:30:04.984 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_INIT_OK loading High
Availability hooks library successful
2022-09-21 19:30:04.984 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_LOADED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so successfully loaded
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcp4/1232318.139712599805568]
DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: no IPv4
subnets!; DDNS: disabled
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600
max-row-errors=100 name=/var/lib/kea/kea-leases4.csv type=memfile universe=4
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file
/var/lib/kea/kea-leases4.csv.2
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file
/var/lib/kea/kea-leases4.csv
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to
3600 sec
2022-09-21 19:30:04.986 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_LOCAL_DHCP_DISABLE local
DHCP service is disabled while the dhcp-standby is in the WAITING state
2022-09-21 19:30:04.986 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_SERVICE_STARTED started
high availability service in hot-standby mode as standby server
```kea2.3.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2631Modification of handling of global reservations with IP addresses set2023-07-17T13:58:22ZAlan CleggModification of handling of global reservations with IP addresses setCustomer request, ref: https://support.isc.org/Ticket/Display.html?id=21365
NOTE: Support ticket has patches that have been reviewed by Thomas and Francis and are not seen as appropriate. It would appear that the customers need is rea...Customer request, ref: https://support.isc.org/Ticket/Display.html?id=21365
NOTE: Support ticket has patches that have been reviewed by Thomas and Francis and are not seen as appropriate. It would appear that the customers need is real and that we should determine a good course forward.
-----------------------------
Ticket narrative provided below:
I would like to put in a feature request to modify the handling of global reservations with IP addresses set.
## Background ##
I'd like to detail some of our use case and the behaviors we have had to work around in our Kea implementation. We have created a self-service portal for users to register their devices to access the network. In the general case, this consists of a user giving us a MAC address and an FQDN for us to create a host reservation with, but we do allow IT administrators to reserve IP addresses as well. Even when a user requests a certain IP address, we do not necessarily restrict them from only using that network; i.e. they should be able to get a valid IP address in any network (with DDNS determined by the subnet they land in).
A few behaviors we've ran into using global host reservations:
1) Global reservations with IP addresses do no bounds checking on if the IP address is correct for a subnet.
a) If a device requests an address from a shared-network that does not contain its IP address, it will receive an address which cannot be used
b) If a device requests an address from a shared-network that does contain its IP address, but it's IP address is not a part of the subnet with the lowest ID, it will receive the correct address but incorrect options (e.g. routers).
2) Updated reservation MAC addresses may create conflicts when a lease with the old MAC address still exists (we use `match-client-id: false`)
3) I suspect that updated reservation FQDNs do not reflect when a client lease is updated, but have not verified
We have worked around issues 1b, 2, and 3 by modifying leases through the API via the self-service portal. On every create of update of a device with an IP reservation in our self-service portal, we ensure that the hostname, MAC address, and subnet-id on the lease(s) match what we expect. (1a) is still an issue for us and requires manual intervention to either move the device into the shared-network where it should exist, or change the host reservation to be in the shared-network where the device currently resides.
I understand there is a workaround: create two reservations (one global without an IP address and one inside the subnet with an IP address). This increases our complexity by adding another data store to keep in sync, and I believe could end up reducing performance due to more host lookups. It's my opinion that the current global reservation behavior is a footgun which can be easily avoided, and the requested behavior is more in line with what users of ISC DHCPd would expect.
## Feature Request ##
Kea should only hand out feasible addresses to clients and correctly match leases to subnets for global reservations with IP addresses.
Current behavior:
- if a host reservation does not have an IP address:
- defer to normal dynamic lease creation
- if a host reservation has an IP address, and the IP address overlaps with any subnet within a shared network:
- create/reuse a lease tied to the first subnet that the client class allows
- if a host reservation has an IP address, and the IP address does not overlap with any subnet in a shared network
- create/reuse a lease tied to a subnet unfit for the IP address
Requested behavior:
- if a host reservation does not have an IP address:
- defer to normal dynamic lease creation
- if a host reservation has an IP address, and the IP address overlaps with any subnet within a shared network:
- create/reuse a lease tied to the matching subnet
- if a host reservation has an IP address, and the IP address does not overlap with any subnet in a shared network
- defer to normal dynamic lease creation
I have attached a patch series to implement this behavior for both DHCPv4 and DHCPv6 IA_NA reservations. Descriptions of the patches are below:
- alloc_engine4.patch: implements requested behavior for DHCPv4 reservations
- alloc_engine_tests4.patch: implements tests for requested behavior in DHCPv4
- alloc_engine6.patch: implements requested behavior for DHCPv6 IA_NA reservations
- alloc_engine_tests6.patch: implements tests for requested behavior in DHCPv6kea2.3.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2883get lease count per pool follow-up2023-07-17T13:58:20ZRazvan Becheriuget lease count per pool follow-upThe following discussion from !1971 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1971#note_376723):
> * [ ] Pool stats documentation
> * [ ] Pool stats unit...The following discussion from !1971 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1971#note_376723):
> * [ ] Pool stats documentation
> * [ ] Pool stats unit tests in `src/lib/dhcpsrv/tests/cfgmgr_unittest.cc`
> * [ ] Pool stats unit tests in `src/lib/dhcpsrv/tests/generic_lease_mgr_unittest.cc`kea2.4.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2931Host commands fetching hosts by IP address from the backends return partial data2023-07-17T13:58:20ZMarcin SiodelskiHost commands fetching hosts by IP address from the backends return partial dataSuppose you have a host reservation that includes IPv6 addresses, prefixes and DHCP options. Now, if you send a command to fetch the host reservation by one of the IPv6 addresses, you'll get the host reservation with this IPv6 address (l...Suppose you have a host reservation that includes IPv6 addresses, prefixes and DHCP options. Now, if you send a command to fetch the host reservation by one of the IPv6 addresses, you'll get the host reservation with this IPv6 address (lacking other IPv6 addresses), without the prefixes and probably with only one of the options.
The reason for it is the invalid query that performs a simple inner join and filters by the IPv6 address. The other addresses and prefixes are ignored (filtered out) because they don't match the specified address. It seems that the correct query should run a sub-query selecting the host-id and then the main query that filters the host by this id.
The original issue was described here: https://gitlab.isc.org/isc-projects/kea/-/issues/2881#note_380311kea2.4.0Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3036Error while processing command 'config-set': invalid thread pool state change...2023-09-06T15:30:21ZSandeep GagalapallyError while processing command 'config-set': invalid thread pool state change to paused performed by worker threadHello,
I am running into this error when I try to do a `config-reload` of Kea DHCP via Management API.
I don't have issues when I issue `config-get `
Error: invalid thread pool state change to paused performed by worker thread
I hav...Hello,
I am running into this error when I try to do a `config-reload` of Kea DHCP via Management API.
I don't have issues when I issue `config-get `
Error: invalid thread pool state change to paused performed by worker thread
I have this payload in the body
```
{
"command": "config-reload"
}
```
Thank You,
Sandeep