Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-27T12:51:29Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3213Feature request: statistics-get-all-global command to get all of the global s...2024-03-27T12:51:29ZCathy AlmondFeature request: statistics-get-all-global command to get all of the global stats without any of the subnet stats---
name: statistics-get-all-global command
about: `statistics-get-all-global` command (or similar) to get all of the global statistics without any of the subnet statistics
---
It would also be useful to have something like "statistics...---
name: statistics-get-all-global command
about: `statistics-get-all-global` command (or similar) to get all of the global statistics without any of the subnet statistics
---
It would also be useful to have something like "statistics-get-all-global" command to get all of the global stats but not all of the subnet (or pool if they get added) stats. We have scenarios with multiple 100s of subnets and for those "get-all" can get unwieldy.
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3206subnet-get commands should fetch leases for selected subnets with pagination2024-03-22T13:15:53ZMarcin Siodelskisubnet-get commands should fetch leases for selected subnets with paginationIn HA, we use lease commands to synchronize the database. The lease commands fetch all leases with pagination. However, in the hub-and-spoke model it would be useful to fetch the leases only for selected subnets because the relationships...In HA, we use lease commands to synchronize the database. The lease commands fetch all leases with pagination. However, in the hub-and-spoke model it would be useful to fetch the leases only for selected subnets because the relationships are partitioned by subnet. Today, all leases have to be fetched by each relationship and those that do not belong to the relationship are discarded. This is inefficient. One thing to consider is that subnet identifiers are listed explicitly in the commands.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3203DHCPINFORM is only logged on DEBUG level2024-03-27T13:50:18ZBernhard SchmidtDHCPINFORM is only logged on DEBUG level**Describe the bug**
I'm currently working on a project to migrate a Windows DHCP server environment to Kea. Right now both are active and I'm looking at logs and tcpdump captures while fiddling with the config.
I got confused because ...**Describe the bug**
I'm currently working on a project to migrate a Windows DHCP server environment to Kea. Right now both are active and I'm looking at logs and tcpdump captures while fiddling with the config.
I got confused because there were DHCPACK messages originated by the Kea server while there was not a single log entry visible. Increasing the logging verbosity to DEBUG shows a large number of messages, all with severity DEBUG.
Kea should not interact with clients over the network without logging.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with a logging config like https://gitlab.isc.org/isc-projects/kea/-/blob/master/doc/examples/kea4/single-subnet.json?ref_type=heads
2. have a client send DHCPINFORM while running tcpdump
3. observe a DHCPACK being generated in tcpdump with Kea not logging a single line
**Expected behavior**
At least one line should be logged on INFO level when Kea is receiving and answering a DHCPINFORM request.
**Environment:**
- Kea version: 2.4.1
- OS: Debian Bookworm
**Additional Information**
```
2024-01-02 20:14:36.523 DEBUG [kea-dhcp4.packets/1.140376903606784] DHCP4_BUFFER_RECEIVED received buffer from 10.1.0.142:68 to 255.255.255.255:67 over interface ens19
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS No RAI options found to use for subnet selection.
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS Relay address (giaddr) in client packet is empty.
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_BY_INTERFACE_NO_MATCH No subnet matches interface: ens19
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.1.0.0/16 for packet received by matching address 10.1.4.1
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.packets/1.140376869664512] DHCP4_SUBNET_SELECTED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: the subnet with ID 10001000 was selected for client assignments
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.packets/1.140376869664512] DHCP4_PACKET_RECEIVED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: DHCPINFORM (type 8) received from 10.1.0.142 to 255.255.255.255 on interface ens19
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS No RAI options found to use for subnet selection.
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS Relay address (giaddr) in client packet is empty.
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_BY_INTERFACE_NO_MATCH No subnet matches interface: ens19
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.1.0.0/16 for packet received by matching address 10.1.4.1
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.packets/1.140376869664512] DHCP4_SUBNET_SELECTED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: the subnet with ID 10001000 was selected for client assignments
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 0, identified by hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=EEBD63C37393, found 1 host(s)
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 0 and identifier hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 0, identified by client-id=01EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01EEBD63C37393, found 0 host(s)
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 0 and identifier client-id=01EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 10001000, identified by hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=EEBD63C37393, found 1 host(s)
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST using subnet id 10001000 and identifier hwaddr=EEBD63C37393, found host: hwaddr=EEBD63C37393 ipv4_subnet_id=10001000 hostname=(empty) ipv4_reservation=10.1.0.142 siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none)
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcp4/1.140376869664512] DHCP4_CLASS_ASSIGNED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: client packet has been assigned to the following class(es): KNOWN
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcp4/1.140376869664512] DHCP4_CLASS_ASSIGNED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_MSFT 5.0, KNOWN
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.packets/1.140376869664512] DHCP4_PACKET_SEND [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: trying to send packet DHCPACK (type 5) from 10.1.4.1:67 to 10.1.0.142:68 on interface ens19
```kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3202Mismatch in Kea DHCP Subnet Configuration: Unexpected Vendor Class Returned2024-01-25T14:52:06ZSandeep GagalapallyMismatch in Kea DHCP Subnet Configuration: Unexpected Vendor Class ReturnedWhen I create a subnet in Kea DHCP Database with client class as Vendor_C for the subnet 10.x.x.65/28. It should return the
Vendor_C class but I see data of Vendor_N returned everytime.
In other words I am expecting the DHCP server to ...When I create a subnet in Kea DHCP Database with client class as Vendor_C for the subnet 10.x.x.65/28. It should return the
Vendor_C class but I see data of Vendor_N returned everytime.
In other words I am expecting the DHCP server to return data sftp://ftp-server:password@ip_address/configs/Vendor_ztp_cen.xml
to the DHCP client but it is returning sftp://ftp-server:password@ip_address/configs/Vendor_ztp_ned.xml which is defined under Vendor_N.
## My Client classes Configuration defined on the DHCP server.
"client-classes": [
{
"name": "Vendor_N",
"test": "substring(option[60].hex,0,9) == 'Vendor'",
"option-data": [
{
"name": "boot-file-name",
"data": "sftp://ftp-server:password@ip_address/configs/Vendor_ztp_ned.xml"
},
{
"name": "domain-name-servers",
"data": "x.x.x.x,x.x.x.x"
}
]
},
{
"name": "Vendor_C",
"test": "substring(option[60].hex,0,9) == 'Vendor'",
"option-data": [
{
"name": "boot-file-name",
"data": "sftp://ftp-server:password@ip_address/configs/Vendor_ztp_cen.xml"
},
{
"name": "domain-name-servers",
"data": "x.x.x.x,x.x.x.x"
}
]
},
{
"name": "Vendor_W",
"test": "substring(option[60].hex,0,9) == 'Vendor'",
"option-data": [
{
"name": "boot-file-name",
"data": "sftp://ftp-server-pnp:password@ip_address/configs/Vendor_ztp_wst.xml"
},
{
"name": "domain-name-servers",
"data": "x.x.x.x,x.x.x.x"
}
]
}
]
## My Payload when adding a subnet##
{
"command": "remote-subnet4-set",
"service": ["dhcp4"],
"arguments": {
"subnets": [
{
"id": 12345,
"subnet": 10.x.x.65/28,
"shared-network-name": "",
"pools": [
{
"pool": "10.x.x.67- 10.x.x.79",
"require-client-classes": ["Vendor_C"]
} for pool in pools
],
"option-data": [
{
"name": "routers",
"data": 10.x.x.65
}
]
}
],
"remote": {
"type": "mysql"
},
"server-tags": ["all"]
}
}
# DHCP4 log messages
```
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string 'Vendor'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_EQUAL Popping 0x44726976654E657473 and 0x44726976654E657473 pushing result 'true'
2024-01-02 10:58:30.387 INFO [kea-dhcp4.dhcpsrv/4457.140027448874752] EVAL_RESULT Expression Vendor_N evaluated to 1
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_OPTION Pushing option 60 with value 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '0'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '9'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_SUBSTRING Popping length 9, start 0, string 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137 pushing result 0x44726976654E657473
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string 'Vendor'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_EQUAL Popping 0x44726976654E657473 and 0x44726976654E657473 pushing result 'true'
2024-01-02 10:58:30.387 INFO [kea-dhcp4.dhcpsrv/4457.140027448874752] EVAL_RESULT Expression Vendor_C evaluated to 1
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_OPTION Pushing option 60 with value 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '0'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '9'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_SUBSTRING Popping length 9, start 0, string 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137 pushing result 0x44726976654E657473
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string 'Vendor'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_EQUAL Popping 0x44726976654E657473 and 0x44726976654E657473 pushing result 'true'
2024-01-02 10:58:30.387 INFO [kea-dhcp4.dhcpsrv/4457.140027448874752] EVAL_RESULT Expression Vendor_W evaluated to 1
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.packets/4457.140027448874752] DHCP4_PACKET_RECEIVED [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: DHCPREQUEST (type 3) received from 10.x.x.37 to 100.91.x.x on interface ens160
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.packets/4457.140027448874752] DHCP4_QUERY_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5, packet details: local_address=100.x.x.226:67, remote_address=10.x.x.37:68, msg_type=DHCPREQUEST (3), transid=0x758adfb5,
options:
type=012, len=015: "WKY1C7VH0001AP2" (string)
type=053, len=001: 3 (uint8)
type=055, len=015: 1(uint8) 121(uint8) 3(uint8) 6(uint8) 12(uint8) 15(uint8) 28(uint8) 33(uint8) 51(uint8) 54(uint8) 58(uint8) 59(uint8) 66(uint8) 67(uint8) 119(uint8)
type=057, len=002: 8972 (uint16)
type=060, len=041: "Vendor-Ufi_Space_S9710-76D-R-18.2.0.17" (string)
type=061, len=020: 00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32
type=124, len=21, enterprise id=0xc24b, data-len0=16, vendor-class-data0='Vendor-BaseOS'
type=145, len=001: 01
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS No RAI options found to use for subnet selection.
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS Relay address (giaddr) in client packet is empty.
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.28.16.33/28 for packet received by matching address 10.x.x.37
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.packets/4457.140027448874752] DHCP4_SUBNET_SELECTED [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: the subnet with ID 2406630306 was selected for client assignments
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.packets/4457.140027448874752] DHCP4_SUBNET_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: the selected subnet details: 10.28.16.33/28
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 2406630306, identified by hwaddr=8440761A7A39
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=8440761A7A39
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=8440761A7A39, found 0 host(s)
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 2406630306 and identifier hwaddr=8440761A7A39
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 2406630306, identified by client-id=006E63632D574B59314337564830303031415032
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=006E63632D574B59314337564830303031415032
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=006E63632D574B59314337564830303031415032, found 0 host(s)
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 2406630306 and identifier client-id=006E63632D574B59314337564830303031415032
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcp4/4457.140027448874752] DHCP4_CLASS_ASSIGNED [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: client packet has been assigned to the following class(es): UNKNOWN
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcp4/4457.140027448874752] DHCP4_CLASS_ASSIGNED [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: client packet has been assigned to the following class(es): ALL, HA_prod-kea-1, VENDOR_CLASS_Vendor-Ufi_Space_S9710-76D-R-18.2.0.17, Vendor_N, Vendor_C, Vendor_W, UNKNOWN
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.ddns/4457.140027448874752] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: processing client's Hostname option
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.ddns/4457.140027448874752] DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: client sent Hostname option: WKY1C7VH0001AP2
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.ddns/4457.140027448874752] DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: client sent Hostname option: WKY1C7VH0001AP2
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.ddns/4457.140027448874752] DHCP4_RESPONSE_HOSTNAME_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: including Hostname option in the server's response: wky1c7vh0001ap2
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_MYSQL_GET_CLIENTID obtaining IPv4 leases for client ID 00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 2406630306 and IPv4 address 10.x.x.37
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.x.x.37
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.x.x.37, found 0 host(s)
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 2406630306 and address 10.x.x.37
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 10.x.x.37
2024-01-02 10:58:30.535 DEBUG [kea-dhcp4.alloc-engine/4457.140027448874752] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: extending lifetime of the lease for address 10.x.x.37
2024-01-02 10:58:30.535 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_MYSQL_UPDATE_ADDR4 updating IPv4 lease for address 10.x.x.37
2024-01-02 10:58:30.611 INFO [kea-dhcp4.leases/4457.140027448874752] DHCP4_LEASE_ALLOC [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: lease 10.x.x.37 has been allocated for 43200 seconds
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_OPTION Pushing option 60 with value 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '0'
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '9'
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_SUBSTRING Popping length 9, start 0, string 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137 pushing result 0x44726976654E657473
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string 'Vendor'
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_EQUAL Popping 0x44726976654E657473 and 0x44726976654E657473 pushing result 'true'
2024-01-02 10:58:30.611 INFO [kea-dhcp4.dhcp4/4457.140027448874752] EVAL_RESULT Expression Vendor_C evaluated to 1
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.callouts/4457.140027448874752] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.callouts/4457.140027448874752] HOOKS_CALLOUT_CALLED hooks library with index 8 has called a callout on hook leases4_committed that has address 0x7f5ab16500f0 (callout duration: 0.034 ms)
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.callouts/4457.140027448874752] HOOKS_CALLOUTS_COMPLETE completed callouts for hook leases4_committed (total callouts duration: 0.034 ms)
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.options/4457.140027448874752] DHCP4_PACKET_PACK [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: preparing on-wire format of the packet to be sent
2024-01-02 10:55:29.629 DEBUG [kea-dhcp4.packets/4457.140027482445568] DHCP4_RESPONSE_DATA [hwtype=1 84:c4:21:1e:c0:fc], cid=[00:63:6c:75:73:74:65:72:2d:57:4b:59:31:43:38:56:4e:30:30:30:31:38:50:32:5f:77:61], tid=0x2252e631: responding with packet DHCPACK (type 5), packet details: local_address=100.91.x.x:67, remote_address=10.28.x.x:68, msg_type=DHCPACK (5), transid=0x2252e631,
options:
type=001, len=004: 4294967280 (uint32)
type=003, len=004: 10.x.x.33
type=006, len=008: x.x.x.x x.x.x.x
type=051, len=004: 43200 (uint32)
type=053, len=001: 5 (uint8)
type=054, len=004: 100.x.x.x
type=058, len=004: 21600 (uint32)
type=059, len=004: 32400 (uint32)
type=061, len=027: 00:63:6c:75:73:74:65:72:2d:57:4b:59:31:43:38:56:4e:30:30:30:31:38:50:32:5f:77:61
type=067, len=075: "sftp://ftp-server:password@ip_address/configs/vendor_ztp_ned.xml" (string)
```
Thanks,
Sandeepoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3201Allow static leases by hostname like in the old ISC dhcpd2024-01-18T14:52:27ZLuigi BaldoniAllow static leases by hostname like in the old ISC dhcpd---
name: Allow reservations by hostname
about: Allow creating reservations by hostname like in the old ISC dhcp server
---
**Describe the solution you'd like**
In the old ISC dhcpd one could add entries like:
```
host myhost {
hard...---
name: Allow reservations by hostname
about: Allow creating reservations by hostname like in the old ISC dhcp server
---
**Describe the solution you'd like**
In the old ISC dhcpd one could add entries like:
```
host myhost {
hardware ethernet 08:00:aa:bb:cc:dd;
fixed-address myhost;
}
```
Kea allows this:
```
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"ip-address": "192.0.2.10"
}
]
```
Would it be possible to implement this feature in Kea so to have something like:
```
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"hostname-address": "myhost"
}
]
```
?
**Describe alternatives you've considered**
I am aware of the possibility of using ddns and RFC2136 to supply data to a domain name server.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3200Kea unable to remove pid file on exit when installed via rpm2024-03-28T12:35:45ZWlodzimierz WencelKea unable to remove pid file on exit when installed via rpmjournal:
```
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO HOSTS_BACKENDS_REGISTERED the following host backend ...journal:
```
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCP6_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always perfo>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: 2001:db8:1::/64 with params: t1=1000, >
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea6-ctrl-socket
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_CONFIG_COMPLETE DHCPv6 server has completed configuration: added IPv6 subnets: 1; DDNS: disabled
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600 type=memfile universe=6
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases6.csv
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_BUILD_EXTENDED_INFO_TABLES6 building extended info tables saw 0 leases, extended info sanity ch>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_USING_SERVERID server is using server-id 00:01:00:01:2d:21:94:f1:0e:90:95:e1:82:d1 and stores in the file>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_NA leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_TA leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_PD leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCP6_MULTI_THREADING_INFO enabled: yes, number of threads: 4, queue size: 64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_STARTED Kea DHCPv6 server version 2.5.5 started
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal systemd[1]: Stopping kea-dhcp6.service - Kea DHCPv6 Service...
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_SHUTDOWN server shutdown
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: terminate called after throwing an instance of 'isc::util::PIDFileError'
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: what(): Unable to delete PID file '/run/kea/kea-dhcp6.kea-dhcp6.pid'
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=dumped, status=6/ABRT
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'core-dump'.
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: Stopped kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12118]: kea-dhcp6.service: Failed to set up special execution directory in /run: Permission denied
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12118]: kea-dhcp6.service: Failed at step RUNTIME_DIRECTORY spawning /usr/sbin/kea-dhcp6: Permission denied
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=exited, status=233/RUNTIME_DIRECTORY
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'exit-code'.
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12857]: kea-dhcp6.service: Failed to set up special execution directory in /run: Permission denied
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12857]: kea-dhcp6.service: Failed at step RUNTIME_DIRECTORY spawning /usr/sbin/kea-dhcp6: Permission denied
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=exited, status=233/RUNTIME_DIRECTORY
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'exit-code'.
```
probably packaging issue but it's up for investigation.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3197tftp-server-name (option 66) and boot-file-name (option 67)2024-01-11T14:56:42ZGavin McKeetftp-server-name (option 66) and boot-file-name (option 67)Hi,
Kea DHCPv4 server version 2.5.4
I am trying to provide a list of tftp servers and boot file names according to the ZTP requirements of MLXOS (Nvidia Infiniband switches)
https://docs.nvidia.com/networking/display/mlnxosv3111014/ge...Hi,
Kea DHCPv4 server version 2.5.4
I am trying to provide a list of tftp servers and boot file names according to the ZTP requirements of MLXOS (Nvidia Infiniband switches)
https://docs.nvidia.com/networking/display/mlnxosv3111014/getting+started#src-138809553_GettingStarted-RunningDHCP-ZTP
They state, that I must provide options in the following format.
```
option tftp-server-name "<image server url>, <config server url>, <docker container server url>";
option bootfile-name "<image file>, <config file>, <docker container file>";
```
When I define the Option config as follows
```
"option-data": [
{
// For each IPv4 subnet you most likely need to specify at
// least one router.
"name": "routers",
"data": "172.25.40.1"
},
{
"name": "domain-name-servers",
"data": "8.8.8.8"
},
{
"name": "cumulus-provision-url",
"data": "http://172.25.43.23:8080/scripts/nvue-ztp.py"
},
{
"name": "tftp-server-name",
"csv-format": true,
"data": "http://172.25.43.23:8080/mlxos,http://172.25.43.23:8080/configs/ib/,",
"space": "dhcp4"
},
{
"name": "boot-file-name",
"csv-format": true,
"data": "image-X86_64-3.11.1014.img,ib-config.conf,",
"space": "dhcp4"
}
]#
```
I only ever see the following offer on the wire, i.e the first URL and first file name.
![image](/uploads/1d85bf46828cc9fdcc58d3215ede969b/image.png)
I've exhasuitvely to override the Option definition, trying with type=record and record-types="string,string,string" nothing I do works.
Can someone advise if this is a bug? Or if there is a way to do this in Kea.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3196Thread sanitizer warnings with std::bind2024-03-22T13:39:27ZMarcin SiodelskiThread sanitizer warnings with std::bindI ran a DHCPv4 server compiled with a thread sanitizer, and I got the following sporadic failure:
```
==================
WARNING: ThreadSanitizer: data race (pid=95142)
Write of size 8 at 0x7b0c0000c220 by main thread:
#0 operator ...I ran a DHCPv4 server compiled with a thread sanitizer, and I got the following sporadic failure:
```
==================
WARNING: ThreadSanitizer: data race (pid=95142)
Write of size 8 at 0x7b0c0000c220 by main thread:
#0 operator delete(void*, unsigned long) ../../../../src/libsanitizer/tsan/tsan_new_delete.cpp:150 (libtsan.so.0+0x8e878)
#1 std::_Function_base::_Base_manager<std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)> >::_M_destroy(std::_Any_data&, std::integral_constant<bool, false>) /usr/include/c++/11/bits/std_function.h:175 (kea-dhcp4+0xbe1ab)
#2 std::_Function_base::_Base_manager<std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)> >::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation) /usr/include/c++/11/bits/std_function.h:203 (kea-dhcp4+0xbe1ab)
#3 std::_Function_handler<void (), std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)> >::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation) /usr/include/c++/11/bits/std_function.h:282 (kea-dhcp4+0xbe1ab)
#4 std::_Function_base::~_Function_base() /usr/include/c++/11/bits/std_function.h:244 (kea-dhcp4+0xbccd2)
#5 std::function<void ()>::~function() /usr/include/c++/11/bits/std_function.h:334 (kea-dhcp4+0xbccd2)
#6 boost::detail::sp_ms_deleter<std::function<void ()> >::destroy() /usr/include/boost/smart_ptr/make_shared_object.hpp:59 (kea-dhcp4+0xbccd2)
#7 boost::detail::sp_ms_deleter<std::function<void ()> >::operator()(std::function<void ()>*) /usr/include/boost/smart_ptr/make_shared_object.hpp:93 (kea-dhcp4+0xbccd2)
#8 boost::detail::sp_counted_impl_pd<std::function<void ()>*, boost::detail::sp_ms_deleter<std::function<void ()> > >::dispose() /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:169 (kea-dhcp4+0xbccd2)
#9 boost::detail::sp_counted_base::release() /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_atomic.hpp:120 (kea-dhcp4+0x5420a)
#10 boost::detail::shared_count::~shared_count() /usr/include/boost/smart_ptr/detail/shared_count.hpp:432 (kea-dhcp4+0xb845a)
#11 boost::shared_ptr<std::function<void ()> >::~shared_ptr() /usr/include/boost/smart_ptr/shared_ptr.hpp:335 (kea-dhcp4+0xb845a)
#12 isc::dhcp::Dhcpv4Srv::runOne() /home/marcin/devel/kea/src/bin/dhcp4/dhcp4_srv.cc:1113 (kea-dhcp4+0xb845a)
#13 isc::dhcp::Dhcpv4Srv::run() /home/marcin/devel/kea/src/bin/dhcp4/dhcp4_srv.cc:1023 (kea-dhcp4+0xb87b7)
#14 main /home/marcin/devel/kea/src/bin/dhcp4/main.cc:282 (kea-dhcp4+0x5082a)
Previous read of size 8 at 0x7b0c0000c220 by thread T6:
#0 boost::shared_ptr<isc::hooks::CalloutHandle> isc::dhcp::getCalloutHandle<boost::shared_ptr<isc::dhcp::Pkt4> >(boost::shared_ptr<isc::dhcp::Pkt4> const&) ../../../src/lib/dhcpsrv/callout_handle_store.h:50 (kea-dhcp4+0xb7f7d)
#1 isc::dhcp::Dhcpv4Srv::processPacketAndSendResponse(boost::shared_ptr<isc::dhcp::Pkt4>&) /home/marcin/devel/kea/src/bin/dhcp4/dhcp4_srv.cc:1139 (kea-dhcp4+0xb7f7d)
#2 isc::dhcp::Dhcpv4Srv::processPacketAndSendResponseNoThrow(boost::shared_ptr<isc::dhcp::Pkt4>&) /home/marcin/devel/kea/src/bin/dhcp4/dhcp4_srv.cc:1122 (kea-dhcp4+0xb88c7)
#3 void std::__invoke_impl<void, void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&>(std::__invoke_memfun_deref, void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&) /usr/include/c++/11/bits/invoke.h:74 (kea-dhcp4+0xba3c9)
#4 std::__invoke_result<void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&>::type std::__invoke<void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&>(void (isc::dhcp::Dhcpv4Srv::*&)(boost::shared_ptr<isc::dhcp::Pkt4>&), isc::dhcp::Dhcpv4Srv*&, boost::shared_ptr<isc::dhcp::Pkt4>&) /usr/include/c++/11/bits/invoke.h:96 (kea-dhcp4+0xba3c9)
#5 void std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>::__call<void, , 0ul, 1ul>(std::tuple<>&&, std::_Index_tuple<0ul, 1ul>) /usr/include/c++/11/functional:420 (kea-dhcp4+0xba3c9)
#6 void std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>::operator()<, void>() /usr/include/c++/11/functional:503 (kea-dhcp4+0xba3c9)
#7 void std::__invoke_impl<void, std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&>(std::__invoke_other, std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&) /usr/include/c++/11/bits/invoke.h:61 (kea-dhcp4+0xba3c9)
#8 std::enable_if<is_invocable_r_v<void, std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&>, void>::type std::__invoke_r<void, std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&>(std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)>&) /usr/include/c++/11/bits/invoke.h:111 (kea-dhcp4+0xba3c9)
#9 std::_Function_handler<void (), std::_Bind<void (isc::dhcp::Dhcpv4Srv::*(isc::dhcp::Dhcpv4Srv*, boost::shared_ptr<isc::dhcp::Pkt4>))(boost::shared_ptr<isc::dhcp::Pkt4>&)> >::_M_invoke(std::_Any_data const&) /usr/include/c++/11/bits/std_function.h:290 (kea-dhcp4+0xba3c9)
#10 std::function<void ()>::operator()() const /usr/include/c++/11/bits/std_function.h:590 (libkea-util.so.80+0x3ef83)
#11 isc::util::ThreadPool<std::function<void ()>, std::deque<boost::shared_ptr<std::function<void ()> >, std::allocator<boost::shared_ptr<std::function<void ()> > > > >::run() ../../../src/lib/util/thread_pool.h:599 (libkea-util.so.80+0x3ef83)
Thread T6 (tid=95149, running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:969 (libtsan.so.0+0x605b8)
#1 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) <null> (libstdc++.so.6+0xdc328)
#2 isc::dhcp::ControlledDhcpv4Srv::processCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::shared_ptr<isc::data::Element const>) /home/marcin/devel/kea/src/bin/dhcp4/ctrl_dhcp4_srv.cc:861 (kea-dhcp4+0x666f8)
#3 isc::dhcp::ControlledDhcpv4Srv::loadConfigFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/marcin/devel/kea/src/bin/dhcp4/ctrl_dhcp4_srv.cc:163 (kea-dhcp4+0x6732b)
#4 isc::dhcp::ControlledDhcpv4Srv::init(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/marcin/devel/kea/src/bin/dhcp4/ctrl_dhcp4_srv.cc:99 (kea-dhcp4+0x677fb)
#5 main /home/marcin/devel/kea/src/bin/dhcp4/main.cc:253 (kea-dhcp4+0x507e5)
SUMMARY: ThreadSanitizer: data race ../../../../src/libsanitizer/tsan/tsan_new_delete.cpp:150 in operator delete(void*, unsigned long)
==================
```
It looks that it may be related to using references to shared pointers in the functions passed to std::bind. Removing the reference seems to solve the problem. For example:
```patch
diff --git a/src/bin/dhcp4/dhcp4_srv.cc b/src/bin/dhcp4/dhcp4_srv.cc
index 612e8aa58b..f949015c04 100644
--- a/src/bin/dhcp4/dhcp4_srv.cc
+++ b/src/bin/dhcp4/dhcp4_srv.cc
@@ -1117,7 +1117,7 @@ Dhcpv4Srv::runOne() {
}
void
-Dhcpv4Srv::processPacketAndSendResponseNoThrow(Pkt4Ptr& query) {
+Dhcpv4Srv::processPacketAndSendResponseNoThrow(Pkt4Ptr query) {
try {
processPacketAndSendResponse(query);
} catch (const std::exception& e) {
diff --git a/src/bin/dhcp4/dhcp4_srv.h b/src/bin/dhcp4/dhcp4_srv.h
index 0ed55adfe5..0507d73ab5 100644
--- a/src/bin/dhcp4/dhcp4_srv.h
+++ b/src/bin/dhcp4/dhcp4_srv.h
@@ -352,7 +352,7 @@ public:
/// methods, generates appropriate answer, sends the answer to the client.
///
/// @param query A pointer to the packet to be processed.
- void processPacketAndSendResponseNoThrow(Pkt4Ptr& query);
+ void processPacketAndSendResponseNoThrow(Pkt4Ptr query);
/// @brief Process an unparked DHCPv4 packet and sends the response.
///
```
However, we should probably go over all similar cases, not only this one. I've seen similar issues with other functions.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3195Modifying pools using the subnetX_update commands does not update statistics2024-03-27T16:11:27ZMarcin SiodelskiModifying pools using the subnetX_update commands does not update statisticsI tested the latest addition to Stork - pools management. I had a subnet without pools initially. I added some address pools to the subnet and saved the changes. It results in sending `subnet4_update` followed by `config-write`. The stat...I tested the latest addition to Stork - pools management. I had a subnet without pools initially. I added some address pools to the subnet and saved the changes. It results in sending `subnet4_update` followed by `config-write`. The statistics (in particular `total-addresses` counter) has not been changed to reflect the new pools capacity. I am able to force recounting the statistics by sending the `config-reload` command, but that's not how it is supposed to work.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3194fix UTs when Kea is configured with botan without TLS2024-02-23T18:26:02ZRazvan Becheriufix UTs when Kea is configured with botan without TLSnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3192Allow `perfdhcp` to behave like an endpoint client2024-01-11T14:52:45ZChrisPortmanAllow `perfdhcp` to behave like an endpoint client---
name: perfdhcp DHCPv4 not as a relay
about: Support for perfdchp DHCPv4 Operation as a normal client (not relay)
---
**Is your feature request related to a problem? Please describe.**
I would like to be able to use perfdhcp to test...---
name: perfdhcp DHCPv4 not as a relay
about: Support for perfdchp DHCPv4 Operation as a normal client (not relay)
---
**Is your feature request related to a problem? Please describe.**
I would like to be able to use perfdhcp to test a dhcp implementation including the ability to process DORA over broadcast.
**Describe the solution you'd like**
An option that enabled perfdhcp to act as an end client as opposed to a relay, which means using broadcast traffic, not setting
giaddr and binding to port 68 and not 67.
**Additional context**
I'm specifically trying to tests a DHCP application on the same host. This means that the dhcp process binds on 67 and the current behaviour of perfdhcp is to also bind on 67 which fails. If perfdhcp can function as a normal client, it can use 68.
**Funding its development**
Unfortunately no, but see next section
**Participating in development**
I have a patch ready to submit via a MR once I can get permission to fork.
**Contacting you**
Please reach out via github. I can provide email via a direct message if required.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3189Follow-up on #3019: limits are incompatbile with retry-on-startup2024-03-28T14:56:49ZAndrei Pavelandrei@isc.orgFollow-up on #3019: limits are incompatbile with retry-on-startupThe limits library needs the lease manager initialized in dhcpX_srv_configured in order to check for JSON support and to do some recounting. When `retry-on-startup` is configured for the lease database, and a retry is triggered, the leas...The limits library needs the lease manager initialized in dhcpX_srv_configured in order to check for JSON support and to do some recounting. When `retry-on-startup` is configured for the lease database, and a retry is triggered, the lease manager is not yet available, so an exception is thrown and the reconfiguration aborts, instead of actually retrying.
We should make limits compatible with retry-on-startup. Through some lazy recounting mechanism. @razvan's idea was a callback in `LeaseMgrFactory` that gets called on instantiation.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3188Support hot plugging network interfaces2024-02-01T10:52:48ZJakub OkoĊskiSupport hot plugging network interfaces---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` i...---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` is not present when Kea starts.
I want to be able to declare subnets & definitions for a USB adapter that I sometimes hotplug to the gateway. Without support from Kea, I'd need to keep two different configs and reload Kea at appropriate times. I assume it's also going to fail when a network interface it's listening on disappears.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3179kea fails to log to syslog if run as non-root user2024-03-22T13:43:03ZLars Wendlerkea fails to log to syslog if run as non-root userWith the following config snippet
```
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [ { "output": "syslog" } ],
"severity": "INFO",
...With the following config snippet
```
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [ { "output": "syslog" } ],
"severity": "INFO",
"debuglevel": 0
}
]
```
kea won't log to syslog service once it's being started as non-root user. Simply starting kea as root makes it successfully log to syslog.
I am using the following syslogger: [sysklogd-2.4.4](https://github.com/troglobit/sysklogd)
I have found this problem being present in kea-2.4.1 and kea-2.5.4 and only tested the dhcp4 component of kea.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3176Kea disables logging if configured without an `output-options`2023-11-30T14:32:43ZAndrei Pavelandrei@isc.orgKea disables logging if configured without an `output-options`To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dh...To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
}
```
Or set the same configuration through unix socket or kea-ctrl-agent (maybe while still preserving the control-socket, that's why it's there):
```json
{
"arguments": {
"Dhcp6": {
"control-socket": {
"socket-name": "/tmp/kea-dhcp6-ctrl.sock",
"socket-type": "unix"
},
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
},
"command": "config-set",
"service": [
"dhcp6"
]
}
```
You get this and no more logging after that.
```
log4cplus:ERROR No appenders could be found for logger (kea-dhcp6.hosts).
log4cplus:ERROR Please initialize the log4cplus system properly.
```
This contradicts the ARM which says:
> Each logger can have zero or more `output-options`.
It replicates with subloggers too. Only the sublogger is affected in that case.
You can have `interfaces-config` and `subnet6` and anything else besides it.
DHCP traffic works. Commands work. Logging does not.
It also replicates on `kea-dhcp4`.
There is the workaround of reconfiguring with `output-options`. Logging recovers after that.
Also found a typo in the ARM: `output_commands` should be `output-options`.
Suggested actions:
* [ ] Make logging work when `output-options` is not configured with the documented default of `stdout` as output option.
* [ ] Fix the typo in the ARM: `output_commands` should be `output-options`.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3170Feature request: Add regex classification expression2023-11-30T14:29:47ZottoreiFeature request: Add regex classification expressionIt would be a huge improvement for client classification to have the possibility of using regular expressions. That way even more complex inputs could be handled with ease.It would be a huge improvement for client classification to have the possibility of using regular expressions. That way even more complex inputs could be handled with ease.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3167BLQ: query-by-link-address and shared networks2024-03-21T13:20:14ZTomek MrugalskiBLQ: query-by-link-address and shared networksThis is a continuation of #3149. It was brought to our attention that the `QUERY_BY_LINK_ADDRESS` does not return PD leases properly in some circumstances. The algorithm we came up with is as follows:
Proposed algorithm for QUERY_BY_LIN...This is a continuation of #3149. It was brought to our attention that the `QUERY_BY_LINK_ADDRESS` does not return PD leases properly in some circumstances. The algorithm we came up with is as follows:
Proposed algorithm for QUERY_BY_LINK_ADDRESS:
1. select subnet for specified address, pick its subnet-id
2. (if shared network is used, select all subnet-ids for all subnets in the shared network) - this behavior should be configurable (extra parameter that governs if this step should be done or not).
3. return all leases (NA, PD) with the matching subnet-id
Steps 1 and 3 are to be implemented in #3149. This ticket is about extending the code with shared network scenario. Once implemented, it should be configurable if the leases from shared network should be returned or not. The parameter could be global.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3164RFC3442 support case when client requests the Classless Static Routes option ...2023-11-23T15:00:13ZPiotrek ZadrogaRFC3442 support case when client requests the Classless Static Routes option and also requests either or both of the Router option and the Static Routes optionAs per RFC3442:
```
DHCP Server Administrator Responsibilities
Many clients may not implement the Classless Static Routes option.
DHCP server administrators should therefore configure their DHCP
servers to send both a Router o...As per RFC3442:
```
DHCP Server Administrator Responsibilities
Many clients may not implement the Classless Static Routes option.
DHCP server administrators should therefore configure their DHCP
servers to send both a Router option and a Classless Static Routes
option, and should specify the default router(s) both in the Router
option and in the Classless Static Routes option.
When a DHCP client requests the Classless Static Routes option and
also requests either or both of the Router option and the Static
Routes option, and the DHCP server is sending Classless Static Routes
options to that client, the server SHOULD NOT include the Router or
Static Routes options.
```
This should be discussed if Kea should follow this once support of Classless Static Routes is implemented.
Source: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2135#note_414489backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3163unstable unit tests2024-03-20T11:23:33ZAndrei Pavelandrei@isc.orgunstable unit testsThe following tests failed irregularly in the past fortnight:
* `AllocEngine6Test.reservedAddressInPoolReassignedOther` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/AllocEngine6Test/all___debian_1...The following tests failed irregularly in the past fortnight:
* `AllocEngine6Test.reservedAddressInPoolReassignedOther` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/AllocEngine6Test/all___debian_11_amd64___debian_11_amd64_results___reservedAddressInPoolReassignedOther/
```
test_utils.cc:88
Expected equality of these values:
first->cltt_
Which is: 1700075018
second->cltt_
Which is: 1700075019
```
* `HttpClientTest.unreachable` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1273/testReport/junit/(root)/HttpClientTest/all___alpine_3_16_amd64___alpine_3_16_amd64_results___unreachable/
```
server_client_unittests.cc:437
Failed
Timeout occurred while running the test!
```
* `MemfileLeaseQueryImpl6ProcessTest.queryByClientIdActiveLeases` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1274/testReport/junit/(root)/MemfileLeaseQueryImpl6ProcessTest/all___debian_12_amd64___debian_12_amd64_results___queryByClientIdActiveLeases/
```
lease_query_impl6_unittest.cc:1783
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `MySQLBulkLeaseQuery6ProcessTest.queryByClientIdActiveLeases` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1280/testReport/junit/(root)/MySQLBulkLeaseQuery6ProcessTest/all___freebsd_13_0_amd64___freebsd_13_0_amd64_results___queryByClientIdActiveLeases/
```
bulk_lease_query6_unittest.cc:458
Expected equality of these values:
lease->valid_lft_ - elapsed
Which is: 3500
iaaddr_opt->getValid()
Which is: 3499
```
* `MySQLLeaseQueryImpl6ProcessTest.makeClientOptionSingleLink` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1265/testReport/junit/(root)/PgSQLLeaseQueryImpl6ProcessTest/all___alpine_3_15_amd64___alpine_3_15_amd64_results___makeClientOptionSingleLink/
```
lease_query_impl6_unittest.cc:880
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `MySQLLeaseQueryImpl6ProcessTest.queryByClientIdActiveLeases` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/MySQLLeaseQueryImpl6ProcessTest/all___debian_10_amd64___debian_10_amd64_results___queryByClientIdActiveLeases/
```
lease_query_impl6_unittest.cc:1783
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `MySQLLeaseQueryImpl6ProcessTest.queryByIpAddressActiveLease` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/MySQLLeaseQueryImpl6ProcessTest/all___ubuntu_20_04_amd64___ubuntu_20_04_amd64_results___queryByIpAddressActiveLease/
```
lease_query_impl6_unittest.cc:1581
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `PgSQLBulkLeaseQuery6ProcessTest.queryByClientIdActiveLeases` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1275/testReport/junit/(root)/PgSQLBulkLeaseQuery6ProcessTest/all___fedora_38_amd64___fedora_38_amd64_results___queryByClientIdActiveLeases/
```
bulk_lease_query6_unittest.cc:458
Expected equality of these values:
lease->valid_lft_ - elapsed
Which is: 3500
iaaddr_opt->getValid()
Which is: 3499
```
* `PgSQLLeaseQueryImpl6ProcessTest.makeClientOptionSingleLink` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1276/testReport/junit/(root)/PgSQLLeaseQueryImpl6ProcessTest/all___fedora_38_amd64___fedora_38_amd64_results___makeClientOptionSingleLink/
```
lease_query_impl6_unittest.cc:880
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```
* `PgSQLLeaseQueryImpl6ProcessTest.queryByIpAddressActiveLease` https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1270/testReport/junit/(root)/PgSQLLeaseQueryImpl6ProcessTest/all___rhel_9_amd64___rhel_9_amd64_results___queryByIpAddressActiveLease/
```
lease_query_impl6_unittest.cc:1581
Expected equality of these values:
100
cltt_opt->getValue()
Which is: 101
```kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3162Kea does not look at all IP addresses on an interface when attempting to matc...2023-11-23T14:57:47Zmpratik-aristaKea does not look at all IP addresses on an interface when attempting to match incoming packet with subnetSay that Kea has started a DHCPv4 server instance and the interface (on which Kea is listening) has multiple IP addresses configured on it (say using `sudo ip addr add ADDR/MASK dev IFACE`). Now if Kea receives a packet from a directly c...Say that Kea has started a DHCPv4 server instance and the interface (on which Kea is listening) has multiple IP addresses configured on it (say using `sudo ip addr add ADDR/MASK dev IFACE`). Now if Kea receives a packet from a directly connected client on the interface, the Kea code appears to fetch the first available address on the interface, specifically the code here -> https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/lib/dhcp/iface_mgr.cc#L225. This IP address is then used during subnet selection.
In the example (which is also our setup) below, the interface on which kea is listening is vlan42. The primary IP address configured on the interface is 152.44.134.1/16 (configured earlier) and the secondary IP Address configured on the interface is 169.254.4.3/16 (configured later). I see the following traces ->
```
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.dhcpsrv/23369.139809668667520] DHCPSRV_PRINT_ATTR Attribute: iface.address = 152.44.134.1 (I added this log where I printed the IP address that Kea selected for subnet matching)
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.packets/23369.139809668667520] DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 56:83:3f:7a:76:07], cid=[no info], tid=0xb02e9d17: failed to select subnet for the client
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.bad-packets/23369.139809668667520] DHCP4_PACKET_DROP_0002 [hwtype=1 56:83:3f:7a:76:07], cid=[no info], tid=0xb02e9d17, from interface vlan42: no suitable subnet configured for a direct client
```
I verified that Kea successfully adds both the primary and secondary IP address in the Netlink::ipaddrs_get function for vlan42. My expectation was that Kea would look at all the IP addresses active on the interface and then check if any subnet configured in the Kea config file matches these IPs
The Kea config only had a subnet associated with the secondary IP 169.254.4.3/16 so understandably the packet could not be matched to any subnet. We want to be able to provide addresses from the subnet 169.254.0.0 to the clients who are sending their Discover packets on vlan42.
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with the attached config and configure an interface with two IP addresses so that Kea is listening on this interface using both these IPs.
2. Let a directly connected client does A send a Discover packet to the interface that Kea listens on
3. The server will not be able to provide an IP back to the client as it will not match a subnet.
4. This same behavior is seen regardless of whether I add the following block of code.
```
"interfaces-config": {
"interfaces": [
"vlan42/169.254.4.3"
]
}
```
Expected behavior:
The client would have obtained IP address 169.254.5.5 (first available IP from the subnet 169.254.0.0/16 as specified in the Kea config file) since the IP address is getting added to the interface's address list.
We used Kea-2.0.0 for this experiment[kea-dhcp4-default.conf.rtf](/uploads/b771e974c2c29aa7357bbc6e4e9de553/kea-dhcp4-default.conf.rtf)next-stable-2.6