Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-05-31T19:56:05Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2716reversing the priority of allocated resources in client classes would allow t...2023-05-31T19:56:05ZAndrei Pavelandrei@isc.orgreversing the priority of allocated resources in client classes would allow template-spawned inheritanceThe current behavior for client classes is that any resource (lease times, option data, v4 option definitions, v4 fields) defined in a client class is taken from the first matching class. In the following example (don't worry about its u...The current behavior for client classes is that any resource (lease times, option data, v4 option definitions, v4 fields) defined in a client class is taken from the first matching class. In the following example (don't worry about its uselessness, it's only there to prove a point), the valid lifetime of 100 is always given to clients.
```json
{
"Dhcp6": {
"client-classes": [
{
"name": "foo",
"test": "0 == 0",
"valid-lifetime": 100
},
{
"name": "bar",
"test": "0 == 0",
"valid-lifetime": 200
}
]
}
}
```
Since template classes always need to be defined first relative to their spawned class, that means that template classes always have priority over spawned classes. If a user wanted to have a value overwritten in the spawned class, they cannot do it. Having values overwritten for a more specific set of clients is a legitimate reason. Furthermore, it matches the inheritance priority in other parts of the configuration, see the `global - shared network - subnet` relationship. To exemplify, in the following configuration, nobody would ever get valid lifetime 200.
```json
{
"Dhcp6": {
"client-classes": [
{
"name": "oui-vendor",
"template-test": "hexstring(substring(option[1].hex, 4, 3), ':')",
"valid-lifetime": 100
},
{
"name": "SPAWN_oui-vendor_01:02:03",
"valid-lifetime": 200
}
]
}
}
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2714RFE: HA plugin ability to detect partner inabilty to receive client requests ...2023-07-31T14:12:57ZKevin FlemingRFE: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'---
name: Feature request
about: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'
---
**Some initial questions**
- Are you sure your feature is not already implemented in the l...---
name: Feature request
about: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on kea-users or kea-dev mailing lists? Yes
**Is your feature request related to a problem? Please describe.**
(This issue was created as a result of an extensive thread on kea-users)
When the HA plugin is being used in either hot-standby or load-balancing mode, Kea peers are able to notice some forms of communications failures and force the other peers to the 'partner-down' state in order to provide service to clients supported by the other peer.
However, in a situation where client requests are not being delivered to a peer, but it is otherwise fully operational including the peer-to-peer communications link, clients supported by that peer will not be serviced, but the other peer(s) care unable to notice the issue and take action to correct it. This situation could arise when the Kea peers are using separate network links for client traffic and HA traffic, or when the Kea peers are receiving client traffic via a DHCP relay and the relay configuration is incorrect.
**Describe the solution you'd like**
One (or more) opt-in mechanisms that the Kea admin can choose to enhance the ability to detect peer failures to service clients, even when the peer's Kea daemon is otherwise fully operational.
**Describe alternatives you've considered**
Some discussions about external monitoring solutions have occurred, and that is certainly an option which some admins could choose.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? Yes
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? Yesnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2712STARTTLS support2023-02-09T14:57:38ZFrancis DupontSTARTTLS supportActive Lease Query for v4 and v6 specify a mechanism to switch from TCP to TLS using a 'STARTTLS' message. Details differ but currently if the TCP server code in Kea supports TLS in does not support to switch from TCP to TLS mainly becau...Active Lease Query for v4 and v6 specify a mechanism to switch from TCP to TLS using a 'STARTTLS' message. Details differ but currently if the TCP server code in Kea supports TLS in does not support to switch from TCP to TLS mainly because we do not have a "peek" operation.
This ticket proposes to design such support.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2708HA pool rebalancing2023-02-02T14:23:33ZTomek MrugalskiHA pool rebalancingThis idea is not new. It was recently brought up by @cathya in Porto (see [notes](https://pad.isc.org/p/porto2022-kea-features-for-stork#L58). The overall concept is to design and implement a mechanism similar to the one in ISC DHCP. Whe...This idea is not new. It was recently brought up by @cathya in Porto (see [notes](https://pad.isc.org/p/porto2022-kea-features-for-stork#L58). The overall concept is to design and implement a mechanism similar to the one in ISC DHCP. When there are two servers in load-balancing, it is possible that one of them will run out of addresses while the other one still has many.
Couple random comments:
- The pool rebalancing would somehow make both partners negotiate the pools and rebalance them.
- Using a hysteresis approach with high/low threshold would prevent the mechanism to go crazy when running out of addresses. We don't want it to go crazy when there's one or two addresses left.
- The pool dynamism would add extra complexity as the modified pool range would need to be stored somewhere that would survive crashes/reboots etc.
This requires a ~design. It's a complicated feature request with a high potential for endless tweaks, conflicting tuning requests etc.
We will do it one day, but this would require a lot of design, testing and tuning.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2705host-cmds without databases2023-01-26T16:58:14ZTomek Mrugalskihost-cmds without databases`host-cmds` is one of the most popular hooks. It has one major limitation: it is not able to edit running configuration and it needs a database.
Modification of a config-file based configuration is rather easy technically. The reluctanc...`host-cmds` is one of the most popular hooks. It has one major limitation: it is not able to edit running configuration and it needs a database.
Modification of a config-file based configuration is rather easy technically. The reluctance to implement this was based on the grounds that the modified config has to be written (`config-write`) or the changes would be lost after restart/reconfiguration.
This was discussed in Porto and we decided this kind of functionality would be useful for Stork. We can mitigate the concern raised above by properly documenting it and perhaps returning something in the API response that config-write is highly recommended (but not mandatory - there are valid use cases where tweaking HR data is desired to be temporary).
This is a follow-up for `Stork roadmap and backlog` discussion in Porto.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2703unit tests failure with mysql 5.7.39 and freebsd 12.2023-01-26T16:10:46ZWlodzimierz Wencelunit tests failure with mysql 5.7.39 and freebsd 12.unit test failures:
* https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/lastCompletedBuild/testReport/(root)/MySqlConfigBackendDHCPv6Test/run_tests___freebsd_12_1_amd64___freebsd_12_1_amd64_results___globalOptions6WithServerTagsTes...unit test failures:
* https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/lastCompletedBuild/testReport/(root)/MySqlConfigBackendDHCPv6Test/run_tests___freebsd_12_1_amd64___freebsd_12_1_amd64_results___globalOptions6WithServerTagsTest/
* https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/lastCompletedBuild/testReport/(root)/MySqlConfigBackendDHCPv6Test/run_tests___freebsd_12_1_amd64___freebsd_12_1_amd64_results___globalOptions6WithServerTagsTest/
* https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/lastCompletedBuild/testReport/(root)/MySqlConfigBackendDHCPv6Test/run_tests___freebsd_12_1_amd64___freebsd_12_1_amd64_results___unassignedSubnet6Test/
```
19:27:28 MySQL:
19:27:28 MYSQL_VERSION: 5.7.39
19:27:28 MYSQL_CPPFLAGS: -I/usr/local/include/mysql
19:27:28 MYSQL_LIBS: -L/usr/local/lib/mysql -lmysqlclient -lpthread -lm -lrt -lexecinfo -lssl -lcrypto -lssl -lcrypto
```
test report: https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/957/testReport/
Most of systems we are using at the build farm are using mysql version 8 or higher. Except centos 7 (5.5.68) and ubuntu 18.04 (5.7.39) but tests are not failing there.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2700HA Load-Balancing Network issue detection between Relay and Kea2023-01-26T15:22:15ZMathias AichingerHA Load-Balancing Network issue detection between Relay and KeaHi,
I have already tried to resolve this issue with the kea users community, but it seems not many are using HA Load Balancing.
I have the following problem.
Scenario:
Multiple DHCP-Relays at different sites with both KEA-Servers as DH...Hi,
I have already tried to resolve this issue with the kea users community, but it seems not many are using HA Load Balancing.
I have the following problem.
Scenario:
Multiple DHCP-Relays at different sites with both KEA-Servers as DHCP-Servers. Both servers are available and the load balancing shifts the requests between the two servers.
Incident: Because of a network issue Kea 1 is not available from the clients. The network connection between Kea 1 and Kea 2 still works, so no partner-down state.
Expected behaviour: Kea 2 sees the unacked clients of Kea 1 and sets Kea 1 in partner-down state and handles all requests.
Experienced behaviour: Kea 2 still reports HA_BUFFER4_RECEIVE_NOT_FOR_US and does not handle the requests. Unacked clients is not counted.
Is there a misunderstanding or configuration mistake on my side?
```
{
"library": "/usr/local/lib/kea//hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"this-server-name": "server2",
"mode": "load-balancing",
"heartbeat-delay": 10000,
"max-response-delay": 60000,
"max-ack-delay": 10000,
"max-unacked-clients": 1,
"delayed-updates-limit": 100,
"peers": [
{
"name": "server1",
"url": "http://192.168.248.1:8080/",
"role": "primary",
"auto-failover": true
},
{
"name": "server2",
"url": "http://192.168.248.2:8080/",
"role": "secondary",
"auto-failover": true
}
]
}
]
}
}
```
Thank you,
Mathiasbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2699Kea Compilation Time Problem2023-01-26T15:17:19ZcaglarkarahanKea Compilation Time ProblemKea compilation time takes too long. I tried couple of things when running ./configure script to optimize/improve compilation time. I additionally try make with -j option to make it in parallel. My question is,
1. Is there any configure...Kea compilation time takes too long. I tried couple of things when running ./configure script to optimize/improve compilation time. I additionally try make with -j option to make it in parallel. My question is,
1. Is there any configure option to disable service like kea-dhcp6, ddns etc.? (I just want to consider dhcp4 service)
2. Will the disabling service options be helpful to improve compilation time?outstandinghttps://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/2697if require-client-certs is false than cert-file and key-file should not be ne...2023-02-22T14:42:36Zjbbjarnasonif require-client-certs is false than cert-file and key-file should not be necessary---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? _No, I am running version `2.2.0-isc20220726061131`_
- A...---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? _No, I am running version `2.2.0-isc20220726061131`_
- Are you sure what you would like to do is not possible using some other mechanisms? _It is possible but wrong._
- Have you discussed your idea on kea-users or kea-dev mailing lists? _No_
**Is your feature request related to a problem? Please describe.**
If you configure `require-client-certs` as false in high availability hooks, you should not be required to declare `cert-file` and `key-file`
It is very important to describe what you would like to do and why?
Why? It doesn't make sense for remote Kea server to require client certificate from other Kea server when it is already configured as non-required.
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Example config**
From high availability hook,
```json
"peers": [
{
"auto-failover": true,
"name": "kea-dhcpremote-2.kea-dhcpremote.default.svc.cluster.local.",
"role": "primary",
"url": "http://10.244.0.7:8000/"
},
{
"auto-failover": true,
"cert-file": "/certs/kea-client.crt",
"key-file": "/certs/kea-client.key",
"name": "kea-dhcpremote-1.kea-dhcpremote.default.svc.cluster.local.",
"require-client-certs": false,
"role": "standby",
"trust-anchor": "/certs/ca.crt",
"url": "https://10.244.0.5:8000/"
},
{
"auto-failover": true,
"name": "kea-dhcpremote-0.kea-dhcpremote.default.svc.cluster.local.",
"role": "backup",
"url": "http://10.244.0.10:8000/"
}
]
```
From the above config snippet, the `cert-file` and `key-file` should not be needed.
**Describe alternatives you've considered**
The alternative is to generate a bogus client certificate file and client key file and point to it, **Note** the files do not need to be the correct ones since it is not used.
**Additional context**
Add any other context about the feature request here.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? _No sorry_
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? _I would have to ask my employer_
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
_jon.bjarni@menandmice.com_backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2695Regression: configure --with-sysrepo was changed to 4 different arguments.2023-01-19T14:59:24ZFrancis DupontRegression: configure --with-sysrepo was changed to 4 different arguments.The request is to be able to configure libyang and sysrepo with cpp using only one argument, either sysrepo to keep backward compatibility or a new one as --with-netconf (proposed by @andrei)The request is to be able to configure libyang and sysrepo with cpp using only one argument, either sysrepo to keep backward compatibility or a new one as --with-netconf (proposed by @andrei)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2686Minor: MultiThreadingMgr::[gs]etMode are not MT safe.2023-01-19T14:45:45ZFrancis DupontMinor: MultiThreadingMgr::[gs]etMode are not MT safe.TSAN reports a race on enabled_ in MultiThreadingMgr::getMode and MultiThreadingMgr::setMode. It is only an issue if we want the code to be race free i.e. TSAN no longer reporting any race.TSAN reports a race on enabled_ in MultiThreadingMgr::getMode and MultiThreadingMgr::setMode. It is only an issue if we want the code to be race free i.e. TSAN no longer reporting any race.outstandinghttps://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/2671Some header files are missing header guards2023-01-12T14:49:43ZAndrei Pavelandrei@isc.orgSome header files are missing header guardsI suggest a CI step involving a python script that checks for missing header guards.
By convention, all or most header files should have a header guard to prevent including their content twice which can result in unforeseen errors that ...I suggest a CI step involving a python script that checks for missing header guards.
By convention, all or most header files should have a header guard to prevent including their content twice which can result in unforeseen errors that are difficult to figure out.
Here's a low-effort (and not entirely correct) attempt at determining which files are missing the header guards.
```
$ find . -type f -name '*.h' | xargs grep -L ifndef
./premium/src/hooks/dhcp/lease_query/tests/blq_utils.h
./premium/src/hooks/dhcp/forensic_log/subnets_user_context.h
./premium/src/hooks/dhcp/subnet_cmds/tests/subnet_cmds_unittest.h
./premium/src/hooks/dhcp/ddns_tuning/libloadtests/callout_unittests.h
./src/hooks/dhcp/lease_cmds/tests/lease_cmds_unittest.h
./src/hooks/dhcp/high_availability/tests/ha_test.h
./src/bin/dhcp6/tests/callout_library_common.h
./src/bin/dhcp4/tests/callout_library_common.h
./src/lib/util/tests/memory_segment_common_unittest.h
./src/lib/util/unittests/interprocess_util.h
./src/lib/asiodns/logger.h
./src/lib/dns/rdata/any_255/tsig_250.h
./src/lib/dns/rdata/template.h
./src/lib/dns/rdata/in_1/aaaa_28.h
./src/lib/dns/rdata/in_1/srv_33.h
./src/lib/dns/rdata/in_1/a_1.h
./src/lib/dns/rdata/in_1/dhcid_49.h
./src/lib/dns/rdata/ch_3/a_1.h
./src/lib/dns/rdata/generic/ptr_12.h
./src/lib/dns/rdata/generic/hinfo_13.h
./src/lib/dns/rdata/generic/tkey_249.h
./src/lib/dns/rdata/generic/rp_17.h
./src/lib/dns/rdata/generic/mx_15.h
./src/lib/dns/rdata/generic/spf_99.h
./src/lib/dns/rdata/generic/ns_2.h
./src/lib/dns/rdata/generic/nsec3param_51.h
./src/lib/dns/rdata/generic/dlv_32769.h
./src/lib/dns/rdata/generic/soa_6.h
./src/lib/dns/rdata/generic/caa_257.h
./src/lib/dns/rdata/generic/cname_5.h
./src/lib/dns/rdata/generic/rrsig_46.h
./src/lib/dns/rdata/generic/tlsa_52.h
./src/lib/dns/rdata/generic/dname_39.h
./src/lib/dns/rdata/generic/nsec_47.h
./src/lib/dns/rdata/generic/nsec3_50.h
./src/lib/dns/rdata/generic/ds_43.h
./src/lib/dns/rdata/generic/dnskey_48.h
./src/lib/dns/rdata/generic/naptr_35.h
./src/lib/dns/rdata/generic/txt_16.h
./src/lib/dns/rdata/generic/afsdb_18.h
./src/lib/dns/rdata/generic/opt_41.h
./src/lib/dns/rdata/generic/sshfp_44.h
./src/lib/dns/rdata/generic/minfo_14.h
./src/lib/dns/rdata/hs_4/a_1.h
./src/lib/cryptolink/openssl_common.h
./src/lib/cryptolink/botan_common.h
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2670renew-timer and rebind-timer in client classes2023-03-03T11:49:51ZPeter Daviesrenew-timer and rebind-timer in client classesFor some users, it may be useful to be able to define "renew-timer" and "rebind-timer"
within client class definitions.
[RT #21543](https://support.isc.org/Ticket/Display.html?id=21543)For some users, it may be useful to be able to define "renew-timer" and "rebind-timer"
within client class definitions.
[RT #21543](https://support.isc.org/Ticket/Display.html?id=21543)backloghttps://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/2637Regular expressions in Stork2023-04-06T12:02:30ZPeter DaviesRegular expressions in StorkTo enable the use of regular expression is Stork
see: https://gitlab.isc.org/isc-projects/stork/-/issues/901
It may be necessary to change the behaviour of leaseX-get-* commandsTo enable the use of regular expression is Stork
see: https://gitlab.isc.org/isc-projects/stork/-/issues/901
It may be necessary to change the behaviour of leaseX-get-* commandsbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2628CI step missing-git-attribute doesn't detect if the .gitattribute file is mis...2023-01-26T18:25:44ZAndrei Pavelandrei@isc.orgCI step missing-git-attribute doesn't detect if the .gitattribute file is missing entirelyAt least it checks the contents correctly when the file exists.
But if the file is missing, it should be reported.
This [patch](https://gitlab.isc.org/isc-projects/kea/uploads/f8b68c012b2b1969593676e32dc51c7f/a.patch) was suggested as ...At least it checks the contents correctly when the file exists.
But if the file is missing, it should be reported.
This [patch](https://gitlab.isc.org/isc-projects/kea/uploads/f8b68c012b2b1969593676e32dc51c7f/a.patch) was suggested as a fix in another issue.outstanding