ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-07-31T14:10:43Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2698iapd prefix not released in time for next advertise2023-07-31T14:10:43ZMarcin Godzinaiapd prefix not released in time for next advertiseOn jenkins, and on slow systems, Kea is unable to release prefix in time for incoming Solicit. \
The problem exists only when releasing prefix.
Problem observed on test: `tests/dhcp/v6/test_prefix_delegation.py::test_prefix_delegation_n...On jenkins, and on slow systems, Kea is unable to release prefix in time for incoming Solicit. \
The problem exists only when releasing prefix.
Problem observed on test: `tests/dhcp/v6/test_prefix_delegation.py::test_prefix_delegation_noprefixavail_release`
1. Test starts Kea
2. Forge sends Solicit with IA-PD and client id and waits for advertise with option 25.
3. Forge Sends Request with IA-PD and client id and waits for reply with option 26 in 25.
4. Forge second Solicit with IA-PD and client id and waits for advertise with option 25.
5. Forge sends Request with IA-PD and client id and waits for reply with option 26 in 25.
6. Both available prefixes are assigned
7. Forge third Solicit with IA-PD and client id and waits for advertise with no lease available.
8. Forge sends Release with client id and waits for reply with confirmation.
9. Forge fourth Solicit with IA-PD and client id and waits for advertise with option 26 in 25
On local VM test passes - Kea can release prefix in a timely manner.
On Jenkins and local VM with CPU slowed down to 2%, the test fails.
It looks like releasing prefix takes over 200ms after log message on slower machine.
Test run with failure:
https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/tarball-system-tests/235/
Test run with introduced delay after release passes:
https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/tarball-system-tests/234/
```
2022-12-22 23:00:12.726 DEBUG [kea-dhcp6.packets/2570743.140676907595328] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::21b:2cff:fe00:99]:546
msgtype=7(REPLY), transid=0xa596df
type=00001, len=00014: 00:01:00:01:63:a4:e1:76:00:1b:2c:00:00:99
type=00002, len=00014: 00:01:00:01:2b:37:9d:f8:86:32:67:b7:f6:87
type=00013, len=00041: Success(0) "Summary status for all processed IA_NAs"
type=00025(IA_PD), len=00063: iaid=36171, t1=0, t2=0,
options:
type=00013, len=00047: Success(0) "Lease released. Thank you, please come again."
No relays traversed.
(...)
2022-12-22 23:00:12.862 DEBUG [kea-dhcp6.dhcpsrv/2570743.140676915988032] DHCPSRV_CFGMGR_SUBNET6_IFACE selected subnet 3000::/64 for packet received over interface enp0s9
(...)
2022-12-22 23:00:12.862 WARN [kea-dhcp6.alloc-engine/2570743.140676915988032] ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET duid=[00:01:00:01:63:a4:e1:76:00:1b:2c:00:00:99], tid=0xa596df: failed to allocate an IPv6 lease in the subnet 3000::/64, subnet-id 1, shared network (none)
```
[kea.log](/uploads/95e0d4cdcc89f28c008e545ccdb63061/kea.log)[kea-dhcp6.conf](/uploads/dbde869ba021c196bf52b92c18149ba0/kea-dhcp6.conf)[leases.csv](/uploads/3e14a6a860d8c28af5b9cac6a35d3daf/leases.csv)[test-steps.txt](/uploads/0b0093adeb71b819eb4e6f72add19f01/test-steps.txt)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2676[ kea-dhcp4.options] EVAL_RESULT Expression unreserved_class evaluated to 12023-07-31T14:10:04ZPPEQ[ kea-dhcp4.options] EVAL_RESULT Expression unreserved_class evaluated to 1I am testing the matching class function in kea dhcp version 2.2.0. The configuration is as follows:
____________________________________________________________________________________________________
//设置终端匹配类,授权控制策略
"client-classe...I am testing the matching class function in kea dhcp version 2.2.0. The configuration is as follows:
____________________________________________________________________________________________________
//设置终端匹配类,授权控制策略
"client-classes": [
{
"name": "reserved_class"
},
{
"name": "unreserved_class",
"test": "not member('reserved_class')"
}
],
//地址保留分配
"reservation-mode": "global", //设置全局预留
"reservations": [ //预留的地址
{
"hostname": "host-one",
"hw-address": "01:bb:cc:dd:ee:ff"
},
{
"hostname": "host-two",
"hw-address": "02:bb:cc:dd:ee:ff"
},
{
"hw-address": "aa:bb:cc:dd:ee:fe",
"client-classes": [ "reserved_class" ]
},
{
"hostname": "test-one",
"hw-address": "00:0c:29:e9:00:07",
//"client-classes": [ "reserved_class" ]
}
//{
// "hw-address": "00:0c:29:e9:00:07",
// "client-classes": [ "reserved_class" ]
//}
],
"shared-networks": [{
"name": "mytest111",
"subnet4": [
{
"reservations-global": true, //全局预留生效
"reservations-in-subnet": true, //子网预留生效
"reservations-out-of-pool": false, //地址池域名不生效
"subnet": "192.168.100.0/24",
"pools": [
{
"pool": "192.168.100.10-192.168.100.200",
"client-class": "reserved_class"
}
],
"option-data": [
{
"name": "routers",
"data": "192.168.100.1"
},
{
"name": "domain-name-servers",
"data": "223.5.5.5, 223.6.6.6"
}
]
},
{
"subnet": "192.168.101.0/24",
"valid-lifetime": 40, //默认租期
"min-valid-lifetime":40, //最小租期
"max-valid-lifetime":40, //最大租期
"pools": [
{
"pool": "192.168.101.10-192.168.101.200",
"client-class": "unreserved_class"
}
],
"option-data": [
{
"name": "routers",
"data": "192.168.101.1"
},
{
"name": "domain-name-servers",
"data": "192.168.100.183"
}
]
}
]
}],
___________________________________________________________________________________________________
![image](/uploads/f50b39a0f4b8a509dcd3f3c1ca56a625/image.png)
But I found a fatal error. The DHCP service was deployed and the configuration check passed normally. However, the log output found that there would be an error about the option, and it would follow every log requesting an IP address. If there were thousands of terminal devices in the network, the log storage would be impossible to estimate.
So, please help me to deal with this matter and see if it is the reason for my configuration or if it is true.
thank you!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2666some lease commands don't leave a corresponding forensic log message2023-07-31T14:08:52ZAndrei Pavelandrei@isc.orgsome lease commands don't leave a corresponding forensic log message`lease-add`, `lease-update`, `lease-del` have corresponding forensic log messages:
```
Administrator added a lease of [...]
Administrator updated information on the lease of [...]
Administrator deleted the lease for [...]
```
`lease-wi...`lease-add`, `lease-update`, `lease-del` have corresponding forensic log messages:
```
Administrator added a lease of [...]
Administrator updated information on the lease of [...]
Administrator deleted the lease for [...]
```
`lease-wipe` and `lease6-bulk-apply` do not log anything.
If logging each deleted lease in the wipe command is considered too verbose, there could be a single line mentioning the wipe.
For the argument that `lease6-bulk-apply` command is only used by HA, it's worth mentioning that forensic logs appear for peer lease updates as well.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2659Update UML diagrams in the Kea ARM2023-07-31T13:34:54ZVicky Riskvicky@isc.orgUpdate UML diagrams in the Kea ARMThe flow diagrams in the appendix to the Kea ARM are very helpful in understanding how addresses are allocated and in identifying more performant configurations. The existing diagrams reflect Kea 1.8.0. It would be good to update these i...The flow diagrams in the appendix to the Kea ARM are very helpful in understanding how addresses are allocated and in identifying more performant configurations. The existing diagrams reflect Kea 1.8.0. It would be good to update these in more recent ARM versions.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2641Kea 2.0.3 - Error to build custom options when set config with data from data...2023-07-31T14:08:36Zpablitobckpbl.mendez@gmail.comKea 2.0.3 - Error to build custom options when set config with data from database (Config Backend)When we set custom options from Ctrl Agent config-set end-point (server-tag empty), by example:
```json
{
"option-def": [{
"array": false,
"code": 1,
"encapsulate": "",
"name": "primar...When we set custom options from Ctrl Agent config-set end-point (server-tag empty), by example:
```json
{
"option-def": [{
"array": false,
"code": 1,
"encapsulate": "",
"name": "primary-dhcp-server",
"record-types": "",
"space": "cablelabs-client-configuration",
"type": "ipv4-address"
},
{
"array": false,
"code": 2,
"encapsulate": "",
"name": "secondary-dhcp-server",
"record-types": "",
"space": "cablelabs-client-configuration",
"type": "ipv4-address"
},
{
"array": false,
"code": 122,
"encapsulate": "cablelabs-client-configuration",
"name": "cablelabs-client-configuration",
"record-types": "",
"space": "dhcp4",
"type": "empty"
}
]
}
```
```json
{
"shared-networks": [{
"calculate-tee-times": true,
"client-class": "CM-63",
"name": "CM-63",
"next-server": "10.0.2.8",
"option-data": [{
"always-send": true,
"code": 1,
"csv-format": true,
"data": "10.0.0.123",
"space": "cablelabs-client-configuration"
},
{
"always-send": true,
"code": 2,
"csv-format": true,
"data": "10.0.0.216",
"space": "cablelabs-client-configuration"
},
{
"always-send": false,
"code": 122,
"csv-format": false,
"data": "",
"space": "dhcp4"
}]
}
]
}
}
```
When we execute a config-get, we receive same like this, work fine, and send option 122.1 and 122.2 to Cable Modem:
```json
{
"shared-networks": [{
"calculate-tee-times": true,
"client-class": "CM-63",
"name": "CM-63",
"next-server": "10.0.2.8",
"option-data": [{
"always-send": true,
"code": 1,
"csv-format": true,
"data": "10.0.0.123",
"name": "primary-dhcp-server",
"space": "cablelabs-client-configuration"
},
{
"always-send": true,
"code": 2,
"csv-format": true,
"data": "10.0.0.216",
"name": "secondary-dhcp-server",
"space": "cablelabs-client-configuration"
},
{
"always-send": false,
"code": 122,
"csv-format": false,
"data": "01040A00007B02040A0000D8",
"name": "cablelabs-client-configuration",
"space": "dhcp4"
}
]
}]
}
```
But if we set parameters by config backend with same data (on config-set set server-tag = "KEA" to indicate to build from database config), server not send 122.1 and 122.2 to Cable Modem whe this put option 122 on require list on Discover.
Config-get return this:
```json
{
"shared-networks": [
{
"calculate-tee-times": true,
"client-class": "CM-63",
"name": "CM-63",
"next-server": "10.0.2.8",
"option-data": [
{
"always-send": true,
"code": 1,
"csv-format": true,
"data": "10.0.0.123",
"space": "cablelabs-client-configuration"
},
{
"always-send": true,
"code": 2,
"csv-format": true,
"data": "10.0.0.216",
"space": "cablelabs-client-configuration"
},
{
"always-send": false,
"code": 122,
"csv-format": false,
"data": "",
"space": "dhcp4"
}
]
}
```
**Problems:**
- option 122 -> parameter data is not present, and parameter name is not present
- option 122.1 and 122.2 -> parameter name is not present
**Note:** When we insert configuration on database config backend, whe use Auditrevision to inform Kea the config are changed.
I thinks Kea build bad config when load this from database, and build Ok when we set by config-set and not set any server-tag.
**Any suggestions?**next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2627Dynamic DNS in options are not in example DHCPv4 configuration file2023-07-31T13:34:54ZMichael CasadevallDynamic DNS in options are not in example DHCPv4 configuration file**Describe the bug**
Options relating to DDNS in DHCPv4 are not present in the included examples. To get DDNS working with Kea, I had to manually look up and add options like this
```
"dhcp-ddns": {
"enable-updates": true,
...**Describe the bug**
Options relating to DDNS in DHCPv4 are not present in the included examples. To get DDNS working with Kea, I had to manually look up and add options like this
```
"dhcp-ddns": {
"enable-updates": true,
},
"ddns-qualifying-suffix": "ddns.restless.systems",
```
DDNS is methoded in other places, but none of the actual config stanzas appear to be in the file, nor is there a conscience guide showing which flags need to be set, as well as having clients. Furthermore, default behavior is not well documented. For instance, without ddns-qualifying-suffix, my client sent a hostname of "kali", and Kea DHCP attempted to do a UPDATE with that hostname as is.
That could easily leave to unexpected behavior, and security concerns and should be clearly documented.
**Expected behavior**
- Clearer documentation on what must be set in DHCP4 (and 6) for DDNS
- Better documentation on default behaviors
**Environment:**
- Kea version: which release? if it's compiled from git, which revision. Use kea-dhcp4 -V to find out.
- OS: [e.g. Ubuntu 16.04 x64]
- Which features were compiled in (in particular which backends)
- If/which hooks where loaded in
**Environment:**
- Kea version: 2.2.0, compiled from tarball on site
- Ubuntu 22.04.1
**Additional Information**
This was done as part of a livestream learning how to use Kea, documenting this behavior.
**Contacting you**
GitLab is fine, can provide more ways if needed.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2618Wshadow warnings2023-09-26T14:30:24ZAndrei Pavelandrei@isc.orgWshadow warningsI wasted time on figuring out why a test fails just to see that the wrong variable with the same name declared in a nested scope was used. Since then, I'm passing `-Wshadow` to my compilation flags to detect such situations beforehand. I...I wasted time on figuring out why a test fails just to see that the wrong variable with the same name declared in a nested scope was used. Since then, I'm passing `-Wshadow` to my compilation flags to detect such situations beforehand. I would like to reduce the noise outputted by these warnings throughout the Kea code. There are several. Here is one of them:
```
data.cc: In member function ‘virtual void isc::data::MapElement::toJSON(std::ostream&) const’:
data.cc:900:51: warning: declaration of ‘m’ shadows a member of ‘isc::data::MapElement’ [-Wshadow]
900 | const std::map<std::string, ConstElementPtr>& m = mapValue();
| ^
In file included from data.cc:9:
../../../src/lib/cc/data.h:702:44: note: shadowed declaration is here
702 | std::map<std::string, ConstElementPtr> m;
|
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2611extend ddns statistics2023-07-31T14:07:46ZWlodzimierz Wencelextend ddns statisticsWe should consider adding new statistics to kea ddns that would track how many of queue overflows kea ddns encountered and/or how many updates were dropped from queue due to it's overflow (error log message `DHCP_DDNS_QUEUE_MGR_QUEUE_FUL...We should consider adding new statistics to kea ddns that would track how many of queue overflows kea ddns encountered and/or how many updates were dropped from queue due to it's overflow (error log message `DHCP_DDNS_QUEUE_MGR_QUEUE_FULL application request queue has reached maximum number of entries 1024`)
I've run some tests on in the perf lab, ddns works stable but there are plenty of those error messages in the logs.next-stable-2.6https://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/2598sanitize generated client-class names2023-07-31T14:07:21ZFrancis Dupontsanitize generated client-class namesSome client-class names are generated for instance in the current Kea the DHCPv6 vendor-class option content xxx gives a VENDOR_CLASS_xxx class name even when xxx contains a comma or a space or the full name is longer than a reasonable l...Some client-class names are generated for instance in the current Kea the DHCPv6 vendor-class option content xxx gives a VENDOR_CLASS_xxx class name even when xxx contains a comma or a space or the full name is longer than a reasonable limit applied to configured class names.
So my proposal is: so
- limit the allowed length to configured class names which does not match a builtin prefix
- limit the character set of all class names
- provide a sanitizing class/static method which either escape illegal character or if there are too many (say more than one?) encode the argument into hexadecimal i.e. a specialized version of util::strutil::isPrintable (as it is for internal use we do not need something like the DNS name sanitizer)
- call this new method where class names are generated
For the character set I propose the same as isprint at the exception of space characters, quote characters, parentheses, brackets, commas, equal and backslash so
digits, letters and ```!#$%&*+-./:?@^_|~```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2570Buffer overflow with more than 500 interfaces2023-10-26T12:01:37ZThomas WindtBuffer overflow with more than 500 interfacesWe are currently trying to switch from isc-dhcp to kea for our dhcp server. In our specific use-case we have the need for about 520 subnets / vlans. Each vlan is connection via its own network interface to the server. Unfortunately, Kea ...We are currently trying to switch from isc-dhcp to kea for our dhcp server. In our specific use-case we have the need for about 520 subnets / vlans. Each vlan is connection via its own network interface to the server. Unfortunately, Kea crashes if you add a few more interfaces beyond 500.
We already tried increasing the file descriptors, but the underlying issue appears to be related to some coded socket limit, as far as we can tell.
Is it possible to run a single kea instance with more than 500+ interfaces and subnets? Is this a known issue / a way to fix this on our end?
## Some more details:
Kea Version: `2.2.0-1`
Crash:
> INFO [kea-dhcp4.dhcp4.139733613603264] DHCP4_STARTED Kea DHCPv4 server version 2.2.0 started
> kea-dhcp4[692861]: *** buffer overflow detected ***: terminated
This issue might be related to #908, but we weren't able to find any suitable fix.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2561Wrong format of a complex DHCP option with suboptions stored in the host data...2023-07-05T10:39:18ZMarcin SiodelskiWrong format of a complex DHCP option with suboptions stored in the host databaseI am sending the reservation-add command to Kea (from Stork) with the following arguments:
```json
{ "reservation": { "hw-address": "23212345", "option-data": [ { "code": 93, "csv-format": true, "data": "1,12/12", "space": "s46-rule-opt...I am sending the reservation-add command to Kea (from Stork) with the following arguments:
```json
{ "reservation": { "hw-address": "23212345", "option-data": [ { "code": 93, "csv-format": true, "data": "1,12/12", "space": "s46-rule-options" }, { "code": 89, "csv-format": true, "data": "1,2,3,192.0.2.1,3000::/64", "space": "s46-cont-mape-options" }, { "code": 94, "csv-format": true, "space": "dhcp6" } ], "subnet-id": 1 } }
```
Next, when I get this reservation from the database.
```
"option-data": [ { "always-send": false, "code": 94, "csv-format": false, "data": "00590018010203C0000201403000000000000000005D0004010C00C0", "name": "s46-cont-mape", "space": "dhcp6" }, { "always-send": false, "code": 89, "csv-format": true, "data": "1,2,3,192.0.2.1,3000::/64", "name": "s46-rule", "space": "s46-cont-mape-options" }, { "always-send": false, "code": 93, "csv-format": true, "data": "1,12/12", "name": "s46-portparams", "space": "s46-rule-options" } ]
```
Option 94 is an empty option, but in this scenario it has a payload of `00590018010203C0000201403000000000000000005D0004010C00C0`. I presume this is the hexadecimal representation of the suboptions.
From the first look, it comes from the following function:
```
void OptionDataListParser::parse(const CfgOptionPtr& cfg,
isc::data::ConstElementPtr option_data_list) {
auto option_parser = createOptionDataParser();
BOOST_FOREACH(ConstElementPtr data, option_data_list->listValue()) {
std::pair<OptionDescriptor, std::string> option =
option_parser->parse(data);
// Use the option description to keep the formatted value
cfg->add(option.first, option.second);
cfg->encapsulate();
}
}
```
It calls `cfg->encapsulate()` which appends suboptions to the option. Next, it serializes the option with its suboptions and stores it in the database.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2547How is TLS configured for the Control Agent when not in HA?2023-07-31T13:34:54Zvps-ericHow is TLS configured for the Control Agent when not in HA?In section [23.1.2 TLS/HTTPS Configuration](https://kea.readthedocs.io/en/latest/arm/security.html#tls-https-configuration) of the Kea ARM version 2.2.0, it is stated that the `trust-anchor` option specifies a path to the certificate aut...In section [23.1.2 TLS/HTTPS Configuration](https://kea.readthedocs.io/en/latest/arm/security.html#tls-https-configuration) of the Kea ARM version 2.2.0, it is stated that the `trust-anchor` option specifies a path to the certificate authority certificate of the [HA] peer, and that this setting must be specified along with `cert-file` and `key-file` to enable TLS.
Confusingly, the "Security considerations" of the [Kea documentation of 2.1.7-git](https://reports.kea.isc.org/dev_guide/d7/dc0/controlAgent.html#CtrlAgentSecurity) states that you will
> ...not implement the secure layer [TLS] within Kea...
and that
> ...a reverse HTTP proxy can be setup[sic] using one of the third party HTTP server implementations...
These things seem to conflict. Back to the original point, though, is my confusion about how to enable TLS for the control agent when not in HA (and also when in HA with one or more backup servers, when there would be more than one peer). Why is it necessary to configure the peer's certificate authority certificate in the control agent configuration when the system has its own certificate authority certificate store?next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2529patching query options core hook2023-08-10T13:23:02ZFrancis Dupontpatching query options core hookThe idea is to clone the flex option core hook into a similar hook patching the query vs the response. It should be simpler (no client class) and will solve a lot of customer problems including the RAI link selector one.
The only not ea...The idea is to clone the flex option core hook into a similar hook patching the query vs the response. It should be simpler (no client class) and will solve a lot of customer problems including the RAI link selector one.
The only not easy point (code and doc can be reused at a very high level) is to pick a name for it!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2522Using special characters in expressions is not documented.2023-07-05T10:39:18ZMarcin GodzinaUsing special characters in expressions is not documented.Using special characters in expressions is not documented.
For example to use `'` (single quote) as delimiter for `split` expression you need to use it's ASCI value:
`split(option[39].text, 0x27, 1)`Using special characters in expressions is not documented.
For example to use `'` (single quote) as delimiter for `split` expression you need to use it's ASCI value:
`split(option[39].text, 0x27, 1)`next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2495Kea uses predictable filenames for sockets in /tmp2023-07-05T10:39:19ZParide LegoviniKea uses predictable filenames for sockets in /tmpDebian maintainer of the Kea package here; this is a forward of Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014929 and Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/1863100.
---
The default Kea con...Debian maintainer of the Kea package here; this is a forward of Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014929 and Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/1863100.
---
The default Kea configuration files place control sockets under `/tmp`, e.g.:
```
+---
| "control-socket": {
| "socket-type": "unix",
| "socket-name": "/tmp/kea4-ctrl-socket"
| },
+---[ /etc/kea/kea-dhcp4.conf ]
```
This can be a security issue, especially given that the socket have fixed names, as any use can create a file/socket with that name under `/tmp`. Please move the control sockets to `/run/kea`. Thanks!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2490logged messages in Dhcpv4Srv::selectSubnet4o6 use the same name as those in D...2023-07-05T10:39:18ZRazvan Becheriulogged messages in Dhcpv4Srv::selectSubnet4o6 use the same name as those in Dhcpv4Srv::selectSubnetnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2480Documentation - Update KB Article Understanding Client Classification2023-07-31T13:34:54ZPeter DaviesDocumentation - Update KB Article Understanding Client Classification**Update KB Article Understanding Client Classification**
The early-global-reservations-lookup for classed was implemented in release 2.1.4 see #2249
This optionally changes the phases of subnet selection and host reservation.
It need...**Update KB Article Understanding Client Classification**
The early-global-reservations-lookup for classed was implemented in release 2.1.4 see #2249
This optionally changes the phases of subnet selection and host reservation.
It needs to be explained in the KB article:
https://kb.isc.org/docs/understanding-client-classificationnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2479Documentation - upgrading Kea servers with a common DB backend2023-07-31T13:34:54ZPeter DaviesDocumentation - upgrading Kea servers with a common DB backend**Documentation - upgrading Kea servers with a common DB backend**
Kea implementations where servers do not share common databases Kea may be upgraded individually.
In this way the down time of dhcp services may be limited.
Some u...**Documentation - upgrading Kea servers with a common DB backend**
Kea implementations where servers do not share common databases Kea may be upgraded individually.
In this way the down time of dhcp services may be limited.
Some users employ a common database backend for leases and/or configuration data.
As Kea software upgrades normally increment database schema versions, individual upgrades may have unfortunate side effects.
We would like advice regarding this type of upgrade added to:
4.3.2.2 Upgrading a MySQL Database From an Earlier Version of Kea
4.3.3.3 Upgrading a PostgreSQL Database From an Earlier Version of Keanext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2446Update the flow charts in the documentation, esp for HR lookup sequence2023-07-31T13:34:54ZVicky Riskvicky@isc.orgUpdate the flow charts in the documentation, esp for HR lookup sequenceThe flow charts in the documentation represent the sequence of operations for Kea 1.8. It would be useful to add new charts that show how this has changed in 2.1, particularly for the HR lookup behavior.The flow charts in the documentation represent the sequence of operations for Kea 1.8. It would be useful to add new charts that show how this has changed in 2.1, particularly for the HR lookup behavior.next-stable-2.6