Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-12-31T00:31:42Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1362Collect vendor-specific option definitions2023-12-31T00:31:42ZVicky Riskvicky@isc.orgCollect vendor-specific option definitionsThis ticket is a placeholder for people who have working option definitions and wish to share them, to add them. We at ISC do not have a variety of devices, so we cannot build a library of these definitions, but if users contribute them,...This ticket is a placeholder for people who have working option definitions and wish to share them, to add them. We at ISC do not have a variety of devices, so we cannot build a library of these definitions, but if users contribute them, we can provide a file of contributed examples, or a document with contributed examples.
For example, I found this one in my notes, it came from a post on the list a while back, but there are no comments about what the device is or what version of Kea it works with....
``` "option-data": [
{
"name": "syslog-servers",
"space": "vendor-4491",
"data": "2607:f249::3a"
},
{
"name": "config-file",
"space": "vendor-4491",
"data": "cm/012345678.cfg"
},
{
"name": "time-offset",
"space": "vendor-4491",
"data": "-25200"
},
{
"name": "tftp-servers",
"space": "vendor-4491",
"data": "2607:f249:20:1::5"
},
{
"name": "time-servers",
"space": "vendor-4491",
"data": "2607:f249::33,2607:f249::34"
}
]
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3114Second Device Unique ID (duid) on DHCP6-Server2023-12-21T14:31:57ZschniefiSecond Device Unique ID (duid) on DHCP6-ServerI would like to reserve an IPv6 address in a multi-boot system for both the first DUID (Linux) and the second DUID (Windows).\
Is it possible to specify a second DUID in one IPv6 reservation? So as in the following example:
`{ "command"...I would like to reserve an IPv6 address in a multi-boot system for both the first DUID (Linux) and the second DUID (Windows).\
Is it possible to specify a second DUID in one IPv6 reservation? So as in the following example:
`{ "command": "reservation-add", "service": [ "dhcp6" ], "arguments": { "reservation": { "subnet-id": 123, "hostname": "xyz", "ip-addresses": ["1999:123:56a:1800::123"], "duid": "11:11:11:11:11:11", "duid2": "22:22:22:22:22:22" } } }`
When searching for the IPv6 reservation, both the duid and duid2 should be possible inputs:
`{ "command": "reservation-get", "service": [ "dhcp6" ], "arguments": { "subnet-id": 123, "identifier-type": "duid", "identifier": "11:11:11:11:11:11" } }`\
or\
`{ "command": "reservation-get", "service": [ "dhcp6" ], "arguments": { "subnet-id": 123, "identifier-type": "duid2", "identifier": "22:22:22:22:22:22" } }`
For differentiation, the IPv6 reservations should adhere to the following uniqueness criteria:
* unique("ip-address","subnet-id","duid")
* unique("ip-address","subnet-id","duid2")outstandinghttps://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/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/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.6https://gitlab.isc.org/isc-projects/kea/-/issues/3160Too many nullable fields in DB schema?2023-11-23T14:48:53ZDavid KraeutmannToo many nullable fields in DB schema?I'm writing an admin tool for the Kea DB and noticed that a lot of fields in lease4/lease6 are nullable even when they shouldn't be. This adds a lot of handling overhead.
For example, in lease4, most of the columns are nullable, but onl...I'm writing an admin tool for the Kea DB and noticed that a lot of fields in lease4/lease6 are nullable even when they shouldn't be. This adds a lot of handling overhead.
For example, in lease4, most of the columns are nullable, but only relay_id and remote_id are actually possibly set to NULL in the Kea code.
What is the design decision behind that?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3159ThreadSanitize: SEGSV complain on dhcp4 UT when postgresql isn't running2023-11-23T14:46:57ZThomas MarkwalderThreadSanitize: SEGSV complain on dhcp4 UT when postgresql isn't runningThis ism ore of an inconvenience than anything else but it might be a sign of something else too. When postgresql is compiled in but server is not running, kea-dhcp4 builtin for TSAN, UT throws the following error:
```
[----------] 2 t...This ism ore of an inconvenience than anything else but it might be a sign of something else too. When postgresql is compiled in but server is not running, kea-dhcp4 builtin for TSAN, UT throws the following error:
```
[----------] 2 tests from DORAPgSQLTest
[ RUN ] DORAPgSQLTest.multiStageBoot
wipePgSQLData failed:[export PGPASSWORD=keatest; sh /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/wipe_data.sh 19.0 --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null ]
runPgSQLSchema failed: export PGPASSWORD=keatest; cat < /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/dhcpdb_drop.pgsql | psql --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null
unknown file: Failure
C++ exception with description "runPgSQLSchema failed: export PGPASSWORD=keatest; cat < /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/dhcpdb_drop.pgsql | psql --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null " thrown in the test fixture's constructor.
ThreadSanitizer:DEADLYSIGNAL
==71954==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55d4686f55bf bp 0x000000000000 sp 0x7ffd8d3170e0 T71954)
==71954==The signal is caused by a READ memory access.
==71954==Hint: address points to the zero page.
#0 testing::Test::DeleteSelf_() /opt/googletest-release-1.8.0/googletest/include/gtest/gtest.h:453 (dhcp4_unittests+0x7735bf)
#1 void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2402 (dhcp4_unittests+0x781869)
#2 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2438 (dhcp4_unittests+0x781869)
#3 testing::TestInfo::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2661 (dhcp4_unittests+0x76f514)
#4 testing::TestCase::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2774 (dhcp4_unittests+0x76f871)
#5 testing::internal::UnitTestImpl::RunAllTests() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:4649 (dhcp4_unittests+0x76ff25)
#6 bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2402 (dhcp4_unittests+0x781fa9)
#7 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2438 (dhcp4_unittests+0x781fa9)
#8 testing::UnitTest::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:4257 (dhcp4_unittests+0x7704a5)
#9 RUN_ALL_TESTS() /opt/googletest-release-1.8.0/googletest/include/gtest/gtest.h:2233 (dhcp4_unittests+0x18f59b)
#10 main /home/tmark/labs/build/keadev/open/git.3084/kea/src/bin/dhcp4/tests/dhcp4_unittests.cc:23 (dhcp4_unittests+0x18f59b)
#11 __libc_start_main ../csu/libc-start.c:308 (libc.so.6+0x24082)
#12 _start <null> (dhcp4_unittests+0x1c66dd)
```
Of course if postgresql is running it's not an issue.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3151Reject RADIUS config with multiple default NAS ports2023-11-23T14:42:38ZAndrei Pavelandrei@isc.orgReject RADIUS config with multiple default NAS portsA default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accor...A default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accordingly.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3137Audit revision conflicts between IPv4 and IPv6 due to shared session variable2023-11-23T14:37:03ZMaurice MakaayAudit revision conflicts between IPv4 and IPv6 due to shared session variable**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_rev...**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_revision_id`. These session variables tightly couple the two paths, which can lead to conflicts.
**To Reproduce**
Here's an example scenario for a conflict:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, ok
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, fail
```
Because the global revision id now points at 2, but only `dhcp6_audit` with id 1 exists, we get:
```
ERROR: insert or update on table "dhcp6_audit" violates foreign key constraint "fk_dhcp6_audit_revision"
DETAIL: Key (revision_id)=(2) is not present in table "dhcp6_audit_revision".
CONTEXT: SQL statement "INSERT INTO dhcp6_audit (object_type, object_id, modification_type, revision_id)
VALUES (object_type_val, object_id_val,
(SELECT id FROM modification WHERE modification_type = modification_type_val),
audit_revision_id)"
PL/pgSQL function createauditentrydhcp6(character varying,bigint,character varying) line 11 at SQL statement
SQL statement "SELECT createAuditEntryDHCP6('dhcp6_client_class', NEW.id, 'create')"
PL/pgSQL function func_dhcp6_client_class_ains() line 4 at PERFORM
```
In this case, the INSERT breaks, because the DHCP6 audit record points to a non-existent `dhcp6_audit_revision` id.
Another scenario is possible, where coincidentally the incorrect revision id does exist. In that case, the audit will be assigned to an old revision in the audit trail, changing history. An example scenario for this one:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('one'); -- uses audit_revision_id = 1, ok
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('two'); -- uses audit_revision_id = 2, ok
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 1, ok
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('three'); -- uses audit_revision_id = 1, fail
```
**Expected behavior**
The audit revisions should be independent and use their own specific session variables, instead of shared ones.
When running the first scenario from the reproduction scenario:
- It must not fail
- The DHCP6 change must be logged in `dhcp6_audit` with `revision_id` = 1
- The DHCP4 change must be logged in `dhcp4_audit` with `revision_id` = 2
When running the second scenario:
- DHCP4 client class 'one' must be related to `dhcp4_audit' with `revision_id` = 1
- DHCP4 client class 'two' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP4 client class 'three' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP6 client class 'something' must be related to `dhcp6_audit' with `revision_id` = 1
**Environment:**
- Kea version: 2.5.3 and before
- Affects both MySQL and PostgreSQL
**Work-around**
To prevent issues with the current database schema, make sure that DHCP4 and DHCP6 updates are separated in the query sequence:
- create DHCP4 audit revision
- perform all DHCP4 updates
- create DHCP6 audit revision
- perform all DHCP6 updates
**Contacting you**
You can reach me at account-gitlab-isc@makaay.nloutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1027Database reconnect settings ignored during startup2023-11-18T09:34:42ZChrisDatabase reconnect settings ignored during startup**Describe the bug**
During startup if the database is unreachable (which is easily possible during boot since there is, understandably, no dependency/ordering on sql servers in the default systemd unit) kea-server will immediately shut...**Describe the bug**
During startup if the database is unreachable (which is easily possible during boot since there is, understandably, no dependency/ordering on sql servers in the default systemd unit) kea-server will immediately shut down despite reconnect settings.
Since there is a chance for the SQL database to be available after kea is being started this can lead to kea not running after boot despite being expected to.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure Kea with mysql leases/reservations including reconnect options ("max-reconnect-tries": 10,"reconnect-wait-time": 1000)
2. Stop and start kea + mysql, kea before mysql
```
service isc-kea-dhcp4-server stop; service mysql stop; service isc-kea-dhcp4-server start; service mysql start; sleep 1; service isc-kea-dhcp4-server status;
```
3. See that no reconnect attempts were made
**Expected behavior**
Kea to use the reconnect options during startup
**Environment:**
- Kea version: 1.6.0
- OS: Ubuntu 18.04 x64
- From ISC Kea repository
- If/which hooks where loaded in: lease-commands, haoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3005ddns CHG_ADD before CHG_REMOVE2023-11-16T18:46:52Zphilip-smartbitddns CHG_ADD before CHG_REMOVE---
name: ddns add nsupdate before remove nsupdate
---
**Describe the bug**
we updated kea to 2.4.0 and set ddns-update-on-renew to true. Since the update we noticed that some hosts lost their dns records (but had a correct lease). fr...---
name: ddns add nsupdate before remove nsupdate
---
**Describe the bug**
we updated kea to 2.4.0 and set ddns-update-on-renew to true. Since the update we noticed that some hosts lost their dns records (but had a correct lease). from around 13:00 07/aug/2023 until now we had 6 hosts losing their dns record. we updated to kea 2.4.0 on 13:00 07/aug/2023
In the kea ddns log we noticed that the problem hosts all showed a CHG_ADD before a CHG_REMOVE:
2023-08-07 18:07:36.634 INFO [kea-dhcp-ddns.d2-to-dns/1587] DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [host01.internal.]
IP Address: [10.20.30.40]
DHCID: [000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3]
Lease Expires On: 20230807161112
Lease Length: 216
Conflict Resolution: no
2023-08-07 18:07:36.674 INFO [kea-dhcp-ddns.d2-to-dns/1587] DHCP_DDNS_REMOVE_SUCCEEDED DHCP_DDNS Request ID 000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3: successfully removed the DNS mapping addition for this request: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [host01.internal.]
IP Address: [10.20.30.40]
DHCID: [000201B0E0B8DAF410D5E089236F7462BDCB78A628FBA03A6D38ADF43A848AF348D3F3]
Lease Expires On: 20230807154204
Lease Length: 216
Conflict Resolution: no
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcp4 with the following settings enabled:
"ddns-update-on-renew": true,
"ddns-use-conflict-resolution": false
2. A few hunderd vm's doing a renew every 1800 seconds
3. wait and randomly some hosts lose their dns record's
4. See error above
**Expected behavior**
we expect that kea ddns *always* does a CHG_REMOVE before a CHG_ADD
**Environment:**
- Kea version: 2.4.0 with default multithreading on, package installed via cloudsmith debian repo
- OS: Debian 11
- ha is enabled with default multithreading on, hot-standby
- auth dns server is powerdns 4.8.1
**Additional Information**
we only use dhcp4, no dhcp6
we configured powerdns with distributor-threads=1 and reuseport=no
The kea and (power)dns vm's didn't have high cpu usage or iowait, they weren't overload in any way.
**Contacting you**
contact via gitlab or emailnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2525Support multiple vendor options in flex_option hook2023-11-13T22:36:40ZFrancis DupontSupport multiple vendor options in flex_option hookCurrently the code assumes there is at most one instance of a vendor option and ignore vendor class options even it knows vendor IDs.Currently the code assumes there is at most one instance of a vendor option and ignore vendor class options even it knows vendor IDs.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2996implement draft-ietf-dhc-addr-notification2023-11-10T11:53:16ZVicky Riskvicky@isc.orgimplement draft-ietf-dhc-addr-notificationImplement https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/, once there is a client implementation to test with, possibly Android from Google.
Also known as "Registering Self-generated IPv6 Addresses using DHCPv6" this...Implement https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/, once there is a client implementation to test with, possibly Android from Google.
Also known as "Registering Self-generated IPv6 Addresses using DHCPv6" this draft implements a message from the DHCPv6 client to a DHCPv6 server to log the address the client is using. This enables the server administrator to better troubleshoot issues related to DHCP, because there is a centralized record of addresses associated with the clients using them.
The requirements in the draft include accepting the registration message from the client, returning an appropriately formed acknowledgement, logging a lease in the lease db, and retiring the address after the preferred lifetime has elapsed without a refresh.
[ [ After receiving this ADDR-REG-INFORM message, the address
registration server SHOULD verify that the address being registered
is "appropriate to the link" as defined by [RFC8415]. If the server
believes that address being registered is not appropriate to the
link [RFC8415], it MUST drop the message, and SHOULD log this fact.
If the address is appropriate, the server:
- [ ] SHOULD register or update a binding between the provided Client
Identifier and IPv6 address in its database;
- [ ] SHOULD log the address registration information (as is done
normally for clients which have requested an address), unless
configured not to do so;
- [ ] SHOULD mark the address as unavailable for use and not include it
in future ADVERTISE messages.
- [ ] SHOULD send back an ADDR-REG-REPLY message.
- [ ] If the address registration server does not receive such a refresh
after the preferred lifetime has passed, it SHOULD remove the record
of the Client-Identifier-to-IPv6-address binding.
There aren't any specific requirements in the draft about how to facilitate finding or monitoring these 'leases' so that is all implementation-specific. We might want to log receipt of these messages, if we can't mark the leases to indicate it was reported by the client, rather than a 'regular' dynamic lease from the DHCPv6 server.
- consider some indication on the lease record that this is self-assigned that would facilitate filtering and locating just this kind of lease records
- consider some log message indicating this was a self-assigned address reported by the clientbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2932Kea HA issue with terminating connection2023-11-10T09:50:24ZNick HahnKea HA issue with terminating connectionWe recently migrated our DHCP setup from dhcpd to Kea. It runs on
two servers with hot standby and a memfile backend for the leases. Kea
assigns IP addresses for around 7000 pools.
Over the past few months the HA connection terminated...We recently migrated our DHCP setup from dhcpd to Kea. It runs on
two servers with hot standby and a memfile backend for the leases. Kea
assigns IP addresses for around 7000 pools.
Over the past few months the HA connection terminated in random intervals.
From looking at the logs on the passive node I can see a lot of
'ResourceBusy: IP address ... could not be updated' warnings prior to
the connection terminating. Since multithreading is enabled I suspected
this may be due to the threads encountering a resource lock on the memfile.
I suppose after the lease update fails a few times, the connection is terminated.
Is the 'ResourceBusy' warning the cause for the terminating HA connection and
is there any way to fix the underlying issue? Any ideas on the issue are greatly
appraciated.
Here are the logs from the primary server:
```
Jun 12 15:04:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1, cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:04:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:04:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:04:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:04:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:04:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:04:45 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.ha-hooks.139625718580992] HA_LEASE_UPDATE_CONFLICT [hwtype=1], cid=[], tid=0x0: lease update to standby-dhcp (http://dhcp-2:8001/) returned conflict status code: ResourceBusy: IP address:123.123.123.123 could not be updated. (error code 4)
Jun 12 15:04:56 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:04:56 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:04:56 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:05:28 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:05:28 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:05:28 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:05:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625752151808] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:05:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625752151808] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:05:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625752151808] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:05:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.ha-hooks.139625701795584] HA_LEASE_UPDATE_CONFLICT [hwtype=1], cid=[], tid=0x0: lease update to standby-dhcp (http://dhcp-2:8001/) returned conflict status code: ResourceBusy: IP address:123.123.123.123 could not be updated. (error code 4)
Jun 12 15:05:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.ha-hooks.139625718580992] HA_LEASE_UPDATE_CONFLICT [hwtype=1], cid=[], tid=0x0: lease update to standby-dhcp (http://dhcp-2:8001/) returned conflict status code: ResourceBusy: IP address:123.123.123.123 could not be updated. (error code 4)
Jun 12 15:05:39 dhcp-1 kea-dhcp4[564812]: ERROR [kea-dhcp4.ha-hooks.139625718580992] HA_LEASE_UPDATE_REJECTS_CAUSED_TERMINATION too many rejected lease updates cause the HA service to terminate
Jun 12 15:05:39 dhcp-1 kea-dhcp4[564812]: ERROR [kea-dhcp4.ha-hooks.139625718580992] HA_TERMINATED HA service terminated due to an unrecoverable condition. Check previous error message(s), address the problem and restart!
```
Here are the logs from the standby server:
```
Mar 12 19:25:06 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670034884352] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678688706, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 2907, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:25:06 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670009706240] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678688706, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 2907, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:27:28 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670009706240] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678688848, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 3812, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:32:05 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670018098944] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678689125, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 274, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:32:34 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670009706240] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678689154, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 113, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:32:36 dhcp-2 kea-dhcp4[203037]: ERROR [kea-dhcp4.ha-hooks.139670104323840] HA_TERMINATED HA service terminated due to an unrecoverable condition. Check previous error message(s), address the problem and restart!
Mar 12 22:11:09 dhcp-2 kea-dhcp4[203037]: ERROR [kea-dhcp4.packets.139670138794688] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Truncated DHCPv4 packet (len=0) received, at least 236 is expected.
```
The relevant config is the following on both hosts, differing only in the "this-server-name" property.
```
"hooks-libraries": [{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "standby-dhcp",
"mode": "hot-standby",
"heartbeat-delay": 10000,
"max-response-delay": 60000,
"max-ack-delay": 5000,
"max-unacked-clients": 5,
"peers": [{
"name": "primary-dhcp",
"url": "http://dhcp-1:8001/",
"role": "primary",
"auto-failover": true
}, {
"name": "standby-dhcp",
"url": "http://dhcp-2:8001/",
"role": "standby",
"auto-failover": true
}]
}]
}
}]
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3103RADIUS realm config entry does nothing2023-11-09T15:41:47ZFrancis DupontRADIUS realm config entry does nothingFour possible solutions:
- to nothing (or put the ticket in Outstanding)
- add a note in ARM saying it is not yet supported
- remove it from the config
- implement it (i.e. adding @<realm> to all User-Name attributes)Four possible solutions:
- to nothing (or put the ticket in Outstanding)
- add a note in ARM saying it is not yet supported
- remove it from the config
- implement it (i.e. adding @<realm> to all User-Name attributes)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2878Host Commands require subnet-id to add or manage host reservation2023-11-07T13:04:00ZMarcin GodzinaHost Commands require subnet-id to add or manage host reservationRecently empty host reservations were made valid (containing only hardware address), but Host Command still require providing a `subnet-id` to add or manage leases.
Empty host reservations were added here https://gitlab.isc.org/isc-proj...Recently empty host reservations were made valid (containing only hardware address), but Host Command still require providing a `subnet-id` to add or manage leases.
Empty host reservations were added here https://gitlab.isc.org/isc-projects/kea/-/issues/2723next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2953migrate hammer installations from mysql to mariadb2023-11-07T10:25:44ZWlodzimierz Wencelmigrate hammer installations from mysql to mariadbhammer install mysql in ubuntu and debian systems, change it for mariadbhammer install mysql in ubuntu and debian systems, change it for mariadbnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2521Change v4 vivco-suboptions definition2023-11-02T13:20:23ZFrancis DupontChange v4 vivco-suboptions definitionChange the Vendor-Identifying Vendor class option (name "vivco-suboptions", code 124) from uint32 + binary to uint32 + uint8 + tuple array. Even if the RFC 3925 layout is more an array of records we have a trouble with multiple vendor id...Change the Vendor-Identifying Vendor class option (name "vivco-suboptions", code 124) from uint32 + binary to uint32 + uint8 + tuple array. Even if the RFC 3925 layout is more an array of records we have a trouble with multiple vendor id (the uint32 field): either a second vendor id is different and parsing uses the same value without reading it which is incorrect, or the second id is the same and it is not allowed by the RFC. See also #2520 about arrays and record types.
RFC 3925 layout is:
```
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ |
/ vendor-class-data1 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | optional
+-+-+-+-+-+-+-+-+ | |
/ vendor-class-data2 / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
...
The vendor-class-data comprises a series of separate items, each of
which describes some characteristic of the client's hardware
configuration or capabilities. Examples of vendor-class-data
instances might include the version of the operating system the
client is running or the amount of memory installed on the client.
Each instance of the vendor-class-data is formatted as follows:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len | |
+-+-+-+-+-+-+-+-+ opaque-data |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
Note this includes a rewrite of the OptionVendorClass code in simpler (only one set of tuples, only the check of the data-len (uint8 / second field) to add) and **must** be considered when #1518 will be merged.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2032RADIUS hook support for expressions in accounting messages2023-10-30T21:17:57ZVicky Riskvicky@isc.orgRADIUS hook support for expressions in accounting messagesThe ARM states that expressions are supported in RADIUS, but apparently they are not supported in accounting messages. Can we add this into the accounting messages?
A user who purchased this hook on-line ran across this limitation.The ARM states that expressions are supported in RADIUS, but apparently they are not supported in accounting messages. Can we add this into the accounting messages?
A user who purchased this hook on-line ran across this limitation.backlog