Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2020-06-30T17:28:11Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1282too late hook library effective unload2020-06-30T17:28:11ZFrancis Duponttoo late hook library effective unloadThe thread sanitizer shows too late effective unload of the HA hook library.The thread sanitizer shows too late effective unload of the HA hook library.kea1.7.10Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/991Build some multi-threading unit tests for lease backends.2020-12-10T19:40:56ZFrancis DupontBuild some multi-threading unit tests for lease backends.kea1.9.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/687Add the sender's address to kea-ctrl-agent log messages [ISC-support #14906]2022-04-25T13:00:37ZCathy AlmondAdd the sender's address to kea-ctrl-agent log messages [ISC-support #14906]As requested in [Support RT #14906](https://support.isc.org/Ticket/Display.html?id=14906)
(And also, this sounds like a really useful idea).
The requestor of this feature says:
For us, the source ip address is an important piece of in...As requested in [Support RT #14906](https://support.isc.org/Ticket/Display.html?id=14906)
(And also, this sounds like a really useful idea).
The requestor of this feature says:
For us, the source ip address is an important piece of information.
We would like to see in the kea-ctrl-agent log messages the received command together with the source ip address - something like this:
Jun 20 10:21:52 myserver.example.com kea-ctrl-agent[58456]: 2019-06-20 10:21:52.771 INFO [kea-ctrl-agent.commands/58456] COMMAND_RECEIVED Received command 'config-get’ from 192.0.2.25
From my perspective as an operator, it is a great advantage if the log messages contain all information related to the context.
We would like to see the source address without switching to the debug level.
How do you see this request? Is this an improvement that other users also would appreciate?kea2.1.5Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/616error msgs contain references to config file while config-backend is used2019-07-22T10:49:20ZMichal Nowikowskierror msgs contain references to config file while config-backend is usedI got an error message:
```Config reload failed:configuration error using file '/usr/local/etc/kea/kea.conf': a pool of type V4, with the following address range: 192.168.50.1-192.168.50.100...```
while this config file did not contain ...I got an error message:
```Config reload failed:configuration error using file '/usr/local/etc/kea/kea.conf': a pool of type V4, with the following address range: 192.168.50.1-192.168.50.100...```
while this config file did not contain any subnet definitions - subnets were defined over config-backend.
Error messages should not refer to config file if config is stored in config-backend.Kea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/610validation of option definitions in cb_cmds2019-07-22T10:49:12ZWlodzimierz Wencelvalidation of option definitions in cb_cmdsAt this moment using cb_cmds hook you can define new non-standard options using standard options codes. When kea will fetch this configuration it will fail. I propose to introduce validation of option codesAt this moment using cb_cmds hook you can define new non-standard options using standard options codes. When kea will fetch this configuration it will fail. I propose to introduce validation of option codesKea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/486No longer use bison is yacc emulation mode.2019-03-11T12:55:19ZFrancis DupontNo longer use bison is yacc emulation mode.The autoconf AC_PROG_YACC used in configure sets the YACC variable to "bison -y" but:
- we do not use any feature of the yacc emulation mode, in particular for output file names.
- we use a lot of bison specific features: this gives a ...The autoconf AC_PROG_YACC used in configure sets the YACC variable to "bison -y" but:
- we do not use any feature of the yacc emulation mode, in particular for output file names.
- we use a lot of bison specific features: this gives a lot of warnings with recent bison versions.
Note an alternative is to disable yacc mode warnings (-Wno-yacc) but even it requires more testing avoid the yacc mode is a far cleaner solution.Kea1.6Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/485Stricter check for flex in configure.2019-03-11T13:10:02ZFrancis DupontStricter check for flex in configure.I propose to change
```
if test "x$LEX" == "x"; then
```
into
```
if test "x$LEX" != "xflex"; then
```
in the unlikely but possible case where lex but but not flex is available as recommended in AC_PROG_LEX documentation.I propose to change
```
if test "x$LEX" == "x"; then
```
into
```
if test "x$LEX" != "xflex"; then
```
in the unlikely but possible case where lex but but not flex is available as recommended in AC_PROG_LEX documentation.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/474RADIUS with shared networks2019-05-15T12:50:03ZTomek MrugalskiRADIUS with shared networksWhen RADIUS was implemented, we didn't have shared networks support. As a result, there was a mechanism designed (subnet-reselect) to do something a bit similar to shared networks.
We need to look at the code and see:
- what is needed t...When RADIUS was implemented, we didn't have shared networks support. As a result, there was a mechanism designed (subnet-reselect) to do something a bit similar to shared networks.
We need to look at the code and see:
- what is needed to make RADIUS work with shared network
- what the limitations would be
RADIUS has some substantial limitations as a database-like system, but the basic assumption that it can return attributes that are mapped to client classes should be viable.
#403 has a discussion about current (1.5) code and its limitations.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/419subnet prefix ("subnet" parameter) ambiguity2019-07-22T10:48:11ZFrancis Dupontsubnet prefix ("subnet" parameter) ambiguityCurrently you can create two subnets with the same [begin,end) prefix as soon as the "subnet" parameter is not the same. Some customers already use this trick so create "192.0.2.0/24", "192.0.2.1/24", etc, subnets.
There are three solut...Currently you can create two subnets with the same [begin,end) prefix as soon as the "subnet" parameter is not the same. Some customers already use this trick so create "192.0.2.0/24", "192.0.2.1/24", etc, subnets.
There are three solutions:
- ignore (this is what we did not it is not a real solution!)
- make this illegal (ref #36 and #37)
- accept the trick
In the last case we should create a ticket to add unit tests (so if a code change makes it no longer to work it will be detected) and document it.
BTW the criterion to choose between to make illegal or to accept is the use of the prefix as an unique key in config backend database or things like the remote-subnet4-del-prefix CB command which makes sense only if a prefix can identify without ambiguity a subnet. So it is a design choice and IMHO it must be explicitly done.Kea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/219allow an option value to be set from an expression2019-10-25T09:31:24ZFrancis Dupontallow an option value to be set from an expressionISC DHCP has two ways to set an option value: the static one and the dynamic one where an expression is evaluated to give the value to use. Kea has the basic mechanism for expression evaluation so this feature should be implementable wit...ISC DHCP has two ways to set an option value: the static one and the dynamic one where an expression is evaluated to give the value to use. Kea has the basic mechanism for expression evaluation so this feature should be implementable without a large work.kea1.7.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/116get rid of interface-id for DHCPv42018-09-19T12:51:11ZFrancis Dupontget rid of interface-id for DHCPv4Defined in the DHCPv4 syntax but only for subnets (not shared networks as in DHCPv6) and unused.Defined in the DHCPv4 syntax but only for subnets (not shared networks as in DHCPv6) and unused.Kea1.5-beta1https://gitlab.isc.org/isc-projects/kea/-/issues/131HA hook depends on http library which is not linked with servers.2019-02-20T09:40:10ZFrancis DupontHA hook depends on http library which is not linked with servers.So kea-dhcp4 from the build directory (vs installed) fails to load the HA hook. The solution is to add the http library in the dhcp4 and dhcp6 Makefile.am files. It adds a dependency which is not used in the common case, at the other han...So kea-dhcp4 from the build directory (vs installed) fails to load the HA hook. The solution is to add the http library in the dhcp4 and dhcp6 Makefile.am files. It adds a dependency which is not used in the common case, at the other hand it is not good to dynamic load a Kea standard library with a hook.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/300Installing *messages.h files doesn't seem to be trivial2019-05-13T19:25:36ZMarcin SiodelskiInstalling *messages.h files doesn't seem to be trivialFor Kea 1.5.0 beta2 we attempted to install all *_messages.h files which contain labels of log messages used by loggers. That turned out to be a problem for `make distcheck` because it requires to compile .mes files using the message com...For Kea 1.5.0 beta2 we attempted to install all *_messages.h files which contain labels of log messages used by loggers. That turned out to be a problem for `make distcheck` because it requires to compile .mes files using the message compiler from the `$(top_builddir)` where the kea-msg-compiler is not available. At the stage where the compiler is needed the compiler is presumably available in the $(top_distdir) instead. We haven't figured out why this issue occurs when we attempt to install the files and not when we don't. Because this issue was found right before the Kea 1.5.0 beta2 release we didn't have time to investigate it and find the proper solution. We simply backed off the changes (we don't install message headers) hoping for some solution for it later.
We should also consider whether the messages files should be installed at all. It seems they will only be needed if there are any header files installed which require the message files. That could be the case if we have a template class implemented within the header file which requires logging. As far as we can tell today, we don't have such cases in the code. So, backing off the changes seemed safe for Kea 1.5.0 beta2.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/273Warn about legacy top-level entries2019-05-23T20:24:14ZFrancis DupontWarn about legacy top-level entriesAnnounce in ~~1.5~~ 1.6 release that a Dhcp6 entry in a DHCPv4 server configuration is ignored and will raise an error in the next release.Announce in ~~1.5~~ 1.6 release that a Dhcp6 entry in a DHCPv4 server configuration is ignored and will raise an error in the next release.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/956investigate scenario with two servers sharing lease database and pools2021-06-18T10:47:35ZFrancis Dupontinvestigate scenario with two servers sharing lease database and poolsClearly it is a pretty bad setup but it seems to be used by some customers so it is a bit late to say it is not supported so:
- analyze the behavior of the current code
- decide what should be the lease worst behavior
- update code an...Clearly it is a pretty bad setup but it seems to be used by some customers so it is a bit late to say it is not supported so:
- analyze the behavior of the current code
- decide what should be the lease worst behavior
- update code and documentationKea1.9-backlogRazvan BecheriuRazvan Becheriu