Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-28T08:10:19Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3113Don't seem to be able to skip subnet/lease selection in a hook2024-03-28T08:10:19ZAndrew ForgueDon't seem to be able to skip subnet/lease selection in a hookWhat's the proper way to skip lease/subnet selection and delegate _everything_ to a hook library? I'm trying to hook kea up to a custom IPAM system.
The best I can tell is that you implement `pkt4_receive`/`pkt4_send` and tell `lease4_...What's the proper way to skip lease/subnet selection and delegate _everything_ to a hook library? I'm trying to hook kea up to a custom IPAM system.
The best I can tell is that you implement `pkt4_receive`/`pkt4_send` and tell `lease4_select` and `subnet4_select` as `setStatus(CalloutHandle::NEXT_STEP_SKIP)`.
The hook documentation for lease4_select says:
> Next step status: If any callout installed on the "lease4_select" hook sets the next step action to SKIP, the server will not assign any lease and the callouts become responsible for the lease assignment. If the callouts fail to provide a lease, the packet processing will continue, but client will not get an address.
I'm confused as to which (other) callouts should "provide a lease" if I'm skipping lease4_select? Should I be overwriting the lease4 argument in `lease4_select` instead, and setting `NEXT_STATUS_CONTINUE`? If I do this, how do I prevent Kea from recording the lease? Do I need to SKIP `lease4_*` callouts too?
The only subnet is one from `0.0.0.0` - `255.255.255.255`
```
int pkt4_receive(CalloutHandle &handle) {
... business logic here ...
}
int pkt4_send(CalloutHandle &handle) {
... business logic here ...
}
int lease4_select(CalloutHandle &handle) {
handle.setStatus(CalloutHandle::NEXT_STEP_SKIP);
return 0;
}
int subnet4_select(CalloutHandle &handle) {
handle.setStatus(CalloutHandle::NEXT_STEP_SKIP);
return 0;
}
```
Kea 2.4 seems to drop the packet after DHCP4_PACKET_NAK_0003 (even though pkt4_send will eventually fill in everything), the client never receives anything:
```
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610219676288] DHCP4_BUFFER_RECEIVED received buffer from 127.1.2.3:6671 to 127.0.0.1:6672 over interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.options/657887.140610166056640] DHCP4_BUFFER_UNPACK parsing buffer received from 127.1.2.3 to 127.0.0.1 over interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_PACKET_RECEIVED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: DHCPDISCOVER (type 1) received from 127.1.2.3 to 127.0.0.1 on interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_QUERY_DATA [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1, packet details: local_address=127.0.0.1:6672, remote_address=127.1.2.3:6671, msg_type=DHCPDISCOVER (1), transid=0x
1,
options:
type=053, len=001: 1 (uint8)
type=060, len=015: "HTTPClient::7::" (string)
type=082, len=012:,
options:
type=001, len=004: 65:74:68:30
type=005, len=004: 172.16.42.1 (ipv4-address)
type=093, len=002: 0(uint16)
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_GENERIC Carbide: type=082, len=012:,
options:
type=001, len=004: 65:74:68:30
type=005, len=004: 172.16.42.1 (ipv4-address)
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_PKT4_RECEIVE: CIRCUIT ID [eth0] in packet
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_GENERIC Carbide: type=060, len=015: "HTTPClient::7::" (string)
2023-10-17 06:44:16.759 ERROR [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_PKT4_RECEIVE: Missing option [93] in packet
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7fe25b9f3ae3 (callout duration: 87.199 ms)
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 87.199 ms)
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 0.0.0.0/0 for packet received by matching address 172.16.42.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_SUBNET_SELECTED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: the subnet with ID 1 was selected for client assignments
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_SUBNET_DATA [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: the selected subnet details: 0.0.0.0/0
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=020000000001, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier circuit-id=65746830, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcp4/657887.140610166056640] DHCP4_CLASS_ASSIGNED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: client packet has been assigned to the following class(es): UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcp4/657887.140610166056640] DHCP4_CLASS_ASSIGNED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_HTTPClient::7::, UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.ddns/657887.140610166056640] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: processing client's Hostname option
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 02:00:00:00:00:01
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 0.0.0.1, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 1 and address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_BEGIN begin all callouts for hook lease4_select
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook lease4_select that has address 0x7fe25b9f4647 (callout duration: 0.007 ms)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_COMPLETE completed callouts for hook lease4_select (total callouts duration: 0.007 ms)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_HOOK_LEASE4_SELECT_SKIP Lease4 creation was skipped, because of callout skip flag.
```
... not sure what's supposed to happen at this point to prevent the WARN/ERROR of not having a lease ...
Then:
```
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to allocate an IPv4 lease in the subnet 0.0.0.0/0, subnet-id 1, shared network (none)
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to allocate an IPv4 address after 1 attempt(s)
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: Failed to allocate an IPv4 address for client with classes: ALL, VENDOR_CLASS_HTTPClient::7
::, UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.bad-packets/657887.140610166056640] DHCP4_PACKET_NAK_0003 [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to advertise a lease, client sent ciaddr 0.0.0.0, requested-ip-address (no address)
```
... no further output here ...kea2.6.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3035Expose interface-id in dhcpv6 hook points2023-09-21T13:22:34ZSorin EsanuExpose interface-id in dhcpv6 hook pointsHello!
I see useful to expose option18 (interface id) and, eventually, option37 (remote id) to dhcpv6 hook points, in a similar way that option82 is sent in dhcpv4 hook points (QUERY4_OPTION_82 or QUERY4_OPTION_82_SUB_OPTION_1).
Thank you!Hello!
I see useful to expose option18 (interface id) and, eventually, option37 (remote id) to dhcpv6 hook points, in a similar way that option82 is sent in dhcpv4 hook points (QUERY4_OPTION_82 or QUERY4_OPTION_82_SUB_OPTION_1).
Thank you!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3012ping-check-hook-task-1 Implement skeleton of new hook.2023-09-26T07:46:06ZThomas Markwalderping-check-hook-task-1 Implement skeleton of new hook.Create the necessary premium sub directories and basic infrastructure for new ping-check hook library. The skeleton hook should load and unload and provide NOP C callout functions.Create the necessary premium sub directories and basic infrastructure for new ping-check hook library. The skeleton hook should load and unload and provide NOP C callout functions.kea2.5.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2984Add support for Delegated-IPv6-Prefix to RADIUS hook2024-03-27T12:55:24ZDarren AnkneyAdd support for Delegated-IPv6-Prefix to RADIUS hookCurrently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to cr...Currently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to create a reservation for a prefix based on the content of delegated-ipv6-prefix (https://www.rfc-editor.org/rfc/rfc4818) in the access-accept response.
[RT22056](https://support.isc.org/Ticket/Display.html?id=22056)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2982Missing subnet4-update message2023-08-16T14:41:34ZPeter DaviesMissing subnet4-update messageMissing subnet4-update message:
In Kea 2.4.0:
The subnet commands hooks libraries generate a the following message on successfull
completion of a "subnet4-get" command:
```
SUBNET_CMDS_SUBNET_GET successfully retrieved sub...Missing subnet4-update message:
In Kea 2.4.0:
The subnet commands hooks libraries generate a the following message on successfull
completion of a "subnet4-get" command:
```
SUBNET_CMDS_SUBNET_GET successfully retrieved subnet ...
```
However no message is generated on completion of a "subnet4-update" command.
[RT #22374](https://support.isc.org/Ticket/Display.html?id=22374)kea2.5.1Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/2918ISC DHCP log emulation2023-10-06T17:12:30ZPeter DaviesISC DHCP log emulation---
name: ISC DHCP log emulation
about: Kea to generate logging similar ISC DCHP.
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Kea's forensic logging hooks library ...---
name: ISC DHCP log emulation
about: Kea to generate logging similar ISC DCHP.
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Kea's forensic logging hooks library can be configured generate messages that look
like ISC DHCP logging but DHCPDISCOVER/DHCPOFFER and SOLICIT/ADVERTISE
packets are not logged.
**Is your feature request related to a problem? Please describe.**
As a help to folks who are planning to migrate from ISC DCHP to Kea it may be helpful if
Kea could be induced to produce logging that approximate those generated by ISC DCHP.
**Describe the solution you'd like**
There appear to be two ways forward:
1) Enhance Kea's forensic logging hooks library.
2) Generate new logging messages at severity INFO
**Additional context**
See [RT #22155](https://support.isc.org/Ticket/Display.html?id=22155)kea2.5.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2781[ISC-support #21874] Request to implement "ping before offer"2023-11-23T13:05:40ZEverett Fulton[ISC-support #21874] Request to implement "ping before offer"https://support.isc.org/Ticket/Display.html?id=21874
A Support customer is requesting that Kea has an option to use ICMP pings as a test for an existing host before an offer is provided to a request, as is done in ISC dhcpd.https://support.isc.org/Ticket/Display.html?id=21874
A Support customer is requesting that Kea has an option to use ICMP pings as a test for an existing host before an offer is provided to a request, as is done in ISC dhcpd.kea2.5.4Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2743Document update (hooks for CA)2024-01-22T07:56:32ZPeter DaviesDocument update (hooks for CA)From: https://kea.readthedocs.io/en/kea-2.3.4/arm/hooks.html#available-hook-libraries
Warning
While the Kea Control Agent includes the "hooks" functionality, (i.e. hook libraries can be loaded by this process), none of ISC's curre...From: https://kea.readthedocs.io/en/kea-2.3.4/arm/hooks.html#available-hook-libraries
Warning
While the Kea Control Agent includes the "hooks" functionality, (i.e. hook libraries can be loaded by this process), none of ISC's current hook libraries should be loaded by the Control Agent.
This is no longer correct - the RBAC hooks libraries are loaded on the CAkea2.3.6Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2693Obsolete or fix libreload2023-07-17T13:58:23ZFrancis DupontObsolete or fix libreloadMany hook library code look at the staging config but this is defeated when load is called by libreload vs during (re)config.
Some possible solutions:
- obsolete the libreload command
- add a reload entry (feasible but far to be easy)...Many hook library code look at the staging config but this is defeated when load is called by libreload vs during (re)config.
Some possible solutions:
- obsolete the libreload command
- add a reload entry (feasible but far to be easy)
- find a standard way to detect the case (hint: enforce the staging config to be empty in libreload)
Of course the first solution is the easiest...kea2.3.4Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2622`run_script` hook should contain all DHCP options2022-12-01T14:53:51Zvps-eric`run_script` hook should contain all DHCP optionsI propose that the `run_script` hook be expanded to include all (or more) options of the DHCPv4 packet. As it stands, [only option 82 is returned](https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/hooks/dhcp/run_script/run_script...I propose that the `run_script` hook be expanded to include all (or more) options of the DHCPv4 packet. As it stands, [only option 82 is returned](https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/hooks/dhcp/run_script/run_script.cc#L373-383):
```
RunScriptImpl::extractOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
prefix, suffix);
RunScriptImpl::extractSubOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
RAI_OPTION_AGENT_CIRCUIT_ID,
prefix, suffix);
RunScriptImpl::extractSubOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
RAI_OPTION_REMOTE_ID,
prefix, suffix);
```
Not having looked in-depth, this seems like a place to add a loop over all the option constants, and additionally over each suboption (if applicable). This might be completely unrealistic, however.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2619update hooks_unittests in v4 and v6 to address #2548 review comments2023-07-17T13:58:23ZRazvan Becheriuupdate hooks_unittests in v4 and v6 to address #2548 review commentskea2.3.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2602Do not place libdir location in .conf files2023-07-05T10:39:18ZAlexander KanavinDo not place libdir location in .conf files/etc/kea/kea-ctrl-agent.conf and /etc/kea/kea-dhcp4.conf carry a reference to a library directory in their comments. This is problematic on multilib systems where there can be multiple library locations (e.g. 32 and 64 bit), but only one.../etc/kea/kea-ctrl-agent.conf and /etc/kea/kea-dhcp4.conf carry a reference to a library directory in their comments. This is problematic on multilib systems where there can be multiple library locations (e.g. 32 and 64 bit), but only one set of config files. Yocto project carries a patch to remove libdir references:
https://git.yoctoproject.org/poky/tree/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch
and we'd like to submit it as a merge request here.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2557Long MAC address in reservation crashes KEA when using reservation-get*2023-07-17T13:58:24ZMarcin GodzinaLong MAC address in reservation crashes KEA when using reservation-get*When reservation is added by `reservation-add` with too long MAC address, KEA is not able to retrieve this reservation using `reservation-get*` commands.
Reservation is added to the database with long address.
**To Reproduce**
1. Run K...When reservation is added by `reservation-add` with too long MAC address, KEA is not able to retrieve this reservation using `reservation-get*` commands.
Reservation is added to the database with long address.
**To Reproduce**
1. Run Kea dhcpv4 with host_cmds hook
2. Make a reservation using `reservation-add` command with too long MAC address. Example:
```
"reservation": {
"hw-address": "11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff",
"ip-address": "192.168.50.100",
"subnet-id": 1
}
```
3. Server returns:
```
{
"result": 0,
"text": "Host added."
}
```
4. You can check database contents, long MAC is added to the database.
5. Try to get reservation by any of the `reservation-get*` commands. Example:
```
"arguments": {
"subnet-id": 1
},
"command": "reservation-get-all"
```
6. Kea exits with exception like `HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook $reservation_get_all registered by library with index 1 (callout address 0x7f8675052580): address vector size exceeds MAX_HWADDR_LEN`
**Expected behavior**
Kea should **either** not accept too long MAC address in the `reservation-add` command **or** return the whole long MAC with `reservation-get*`
Links: \
Bug discovered by @tomek here: https://gitlab.isc.org/isc-projects/stork/-/issues/771#note_289578 \
Systems test request: isc-private/qa-dhcp#326kea2.3.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2497deleting sunet with subnetX-del while checking if packet is being rate limite...2022-07-21T13:41:33ZAndrei Pavelandrei@isc.orgdeleting sunet with subnetX-del while checking if packet is being rate limited by the subnet being deleted causes crashThis is consistently reproducible.
1. Start a kea-dhcp4 with a single subnet configured. Multi-threading should help in reproducing.
2. Start a perfdhcp with a reasonably high rate to keep kea-dhcp4 busy enough to reproduce the crash. `p...This is consistently reproducible.
1. Start a kea-dhcp4 with a single subnet configured. Multi-threading should help in reproducing.
2. Start a perfdhcp with a reasonably high rate to keep kea-dhcp4 busy enough to reproduce the crash. `perfdhcp -r 100` is good enough but mileage may vary.
3. Issue a subnet4-del with the configured subnet ID. Crash should happen immediately.
```
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook subnet4_select
kea-dhcp4: /usr/include/boost/smart_ptr/shared_ptr.hpp:786: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = isc::dhcp::Subnet4; typename boost::detail::sp_member_access<T>::type = isc::dhcp::Subnet4*]: Assertion `px != 0' failed.
Thread 54 "kea-dhcp4" received signal SIGABRT, Aborted.
```
```
#0 isc::limits::LimitManager::subnet_select<(isc::util::DhcpSpace)0> (this=0x7ffff30adde0 <isc::limits::LimitManager::instance()::instance>, handle=...)
at ../../../../../premium/src/hooks/dhcp/limits/limit_manager.h:244
#1 0x00007ffff3061c2c in isc::limits::subnet4_select (handle=...) at dhcpv4_callouts.cc:65
#2 0x00007ffff63b3a6c in isc::hooks::CalloutManager::callCallouts (this=0x55555587d360, hook_index=17, callout_handle=...) at callout_manager.cc:168
#3 0x00007ffff63bc025 in isc::hooks::HooksManager::callCalloutsInternal (this=0x7ffff63fa2e0 <isc::hooks::HooksManager::getHooksManager()::manager>, index=17, handle=...)
at hooks_manager.cc:72
#4 0x00007ffff63bc050 in isc::hooks::HooksManager::callCallouts (index=17, handle=...) at hooks_manager.cc:77
#5 0x00005555556bbdc1 in isc::dhcp::Dhcpv4Srv::selectSubnet (this=0x7fffffffdc50, query=..., drop=@0x7ffff12ca6cf: false, sanity_only=false) at dhcp4_srv.cc:773
#6 0x00005555556cd640 in isc::dhcp::Dhcpv4Srv::processDiscover (this=0x7fffffffdc50, discover=..., context=...) at dhcp4_srv.cc:3230
#7 0x00005555556c0a8a in isc::dhcp::Dhcpv4Srv::processDhcp4Query (this=0x7fffffffdc50, query=..., rsp=..., allow_packet_park=true) at dhcp4_srv.cc:1376
#8 0x00005555556bfb05 in isc::dhcp::Dhcpv4Srv::processPacket (this=0x7fffffffdc50, query=..., rsp=..., allow_packet_park=true) at dhcp4_srv.cc:1326
#9 0x00005555556beb9f in isc::dhcp::Dhcpv4Srv::processPacketAndSendResponse (this=0x7fffffffdc50, query=...) at dhcp4_srv.cc:1148
#10 0x00005555556bea25 in isc::dhcp::Dhcpv4Srv::processPacketAndSendResponseNoThrow (this=0x7fffffffdc50, query=...) at dhcp4_srv.cc:1136
```kea2.2.0 - a new stable branchAndrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2496The same hook library loaded multiple times potentially results in unintended...2023-07-31T13:53:23ZAndrei Pavelandrei@isc.orgThe same hook library loaded multiple times potentially results in unintended behaviorMultiple loads of the same hook library is currently possible, but may result in unintended behavior.
For example, here is a case where a CB command gets the wrong response:
1. Configure a Kea server with the same `libdhcp_class_cmds.so...Multiple loads of the same hook library is currently possible, but may result in unintended behavior.
For example, here is a case where a CB command gets the wrong response:
1. Configure a Kea server with the same `libdhcp_class_cmds.so` loaded twice.
2. Configure a class with `remote-class4-set`.
3. Delete the class with `remote-class4-del`. The delete is successful as can be seen by packets not being classified with the deleted class. But the response to the delete command is:
```json
{
"arguments": {
"count": 0
},
"result": 3,
"text": "0 DHCPv4 client class(es) deleted."
}
```
Logs show that one entry is deleted in the first callout, and no entry is deleted in the second callout. What probably happens is that the response to the first deletion gets discarded and the given response corresponds to the second deletion.
```log
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $remote_class4_del
DEBUG MYSQL_CB_DELETE_CLIENT_CLASS4 delete client class: foo
DEBUG DATABASE_MYSQL_START_TRANSACTION starting new MySQL transaction
DEBUG DATABASE_MYSQL_COMMIT committing to MySQL database
DEBUG MYSQL_CB_DELETE_CLIENT_CLASS4_RESULT deleted: 1 entries
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook $remote_class4_del that has address 0x7f875611843c (callout duration: 8.716 ms)
DEBUG MYSQL_CB_DELETE_CLIENT_CLASS4 delete client class: foo
DEBUG DATABASE_MYSQL_START_TRANSACTION starting new MySQL transaction
DEBUG DATABASE_MYSQL_COMMIT committing to MySQL database
DEBUG MYSQL_CB_DELETE_CLIENT_CLASS4_RESULT deleted: 0 entries
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 8 has called a callout on hook $remote_class4_del that has address 0x7f875611843c (callout duration: 1.972 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $remote_class4_del (total calloutsduration: 10.688 ms)
```current-stable-2.4https://gitlab.isc.org/isc-projects/kea/-/issues/2482add unit tests for lease limits2022-07-21T13:41:20ZAndrei Pavelandrei@isc.orgadd unit tests for lease limitsUnit tests for lease limits were neglected. This issue was spun off #2448 which was merged so that we can be more agile with system testing the feature. Here are some pointers.
* [ ] `src/hooks/dhcp/limits/libloadtests/limits_unit_tests_...Unit tests for lease limits were neglected. This issue was spun off #2448 which was merged so that we can be more agile with system testing the feature. Here are some pointers.
* [ ] `src/hooks/dhcp/limits/libloadtests/limits_unit_tests_load_unload.cc` is a bit more focused on the loading and unloading of libraries, but it also has tests that check if a packet is dropped or not according to the configure rate limit. Tests for lease limiting could follow in these footsteps and be added to the same file.
* [x] Create `src/hooks/dhcp/limits/tests/limits_unit_tests_lease_limiting.cc` and get inspiration from `src/hooks/dhcp/limits/tests/limits_unit_tests_rate_limiting.cc` for unit test ideas, and don't necessarily stop there.kea2.2.0 - a new stable branchAndrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2473Race condition in HA+MT2022-07-08T10:41:16ZTomek MrugalskiRace condition in HA+MTAs reported by a customer in [support#20887](https://support.isc.org/Ticket/Display.html?id=20887), Kea 2.0.2 can crash under heavy load under certain conditions.
@marcin investigated this an found the root cause of the problem. See sup...As reported by a customer in [support#20887](https://support.isc.org/Ticket/Display.html?id=20887), Kea 2.0.2 can crash under heavy load under certain conditions.
@marcin investigated this an found the root cause of the problem. See support#20887 for details.
Summary:
Marcin suspected there is a race condition between parking packet after lease-update was scheduled in one thread and the lease response being received and packet processing continues in another thread. To simulate it more reliably, Marcin modified HA code to only pretend the lease update is being sent. With this modification, the code crashed on the first packet.
Marcin was able to reproduce this on unmodified code on VM after couple minutes.kea2.2.0 - a new stable branchRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2449atomic lease limits2022-08-11T11:51:44ZAndrei Pavelandrei@isc.orgatomic lease limitsMake the checking of lease limits atomic to the lease allocation process, and thus resulting in a hard limit cap, as outlined below:
* [ ] Add the limits to the lease candidate's user context under path `ISC.limits` in the `leaseX_selec...Make the checking of lease limits atomic to the lease allocation process, and thus resulting in a hard limit cap, as outlined below:
* [ ] Add the limits to the lease candidate's user context under path `ISC.limits` in the `leaseX_select` callout.
* [ ] Add before-event triggers on the lease tables in MySQL and PostgreSQL that check the limits and prevent the subsequent INSERT or UPDATE statement if a limit is exceeded. If the INSERT or UPDATE is carried out, `ISC.limits` is removed from the user context.
* [ ] Signal the event of reaching a limit to the lease manager which logs its details.
* [ ] Make sure the event is properly handled as a frequent application logic event in the calling contexts (e.g. allocation engine, HA service, lease_cmds), as opposed to a technical failure which can disrupt the usual service or can be costly in terms of performance.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2448limits library extensions for lease limiting2022-07-08T13:51:02ZAndrei Pavelandrei@isc.orglimits library extensions for lease limitingAdd lease limiting capabilities to the limits hook library as outlined below:
* [x] Add the ability to configure lease limits.
* [x] Add the packet's client classes to the lease candidate's user context under path `ISC.client-classes` i...Add lease limiting capabilities to the limits hook library as outlined below:
* [x] Add the ability to configure lease limits.
* [x] Add the packet's client classes to the lease candidate's user context under path `ISC.client-classes` in the `leaseX_select` callout.
* [x] Use the `LeaseMgr::checkLimitsX()` functions in the `leaseX_select` callout. Set `NEXT_STEP_DROP` if the limit is exceeded.kea2.2.0 - a new stable branchAndrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2443DHCPv6 relay agent remote-id option as identifier2022-11-25T14:02:20ZPeter DaviesDHCPv6 relay agent remote-id option as identifier**DHCPv6 relay agent remote-id option as identifier**:
Specific clients may need to be offered a lease on the same IPv6 address.
The UID and the IAID values of a client might not remain unchanged over time.
It may therefore be usef...**DHCPv6 relay agent remote-id option as identifier**:
Specific clients may need to be offered a lease on the same IPv6 address.
The UID and the IAID values of a client might not remain unchanged over time.
It may therefore be useful to users that the relay agent “remote-id” option
alone could be used as a lease identifier.
A hook that performed this operation would need to ensure that Kea "remembers"
the original UID and IAID values so they may be returned correctly to the
client in replies
[RT #20662](https://support.isc.org/Ticket/Display.html?id=20662)kea2.3.3Razvan BecheriuRazvan Becheriu