Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2020-04-30T14:07:39Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1188configuration changes must be applied with MT stopped2020-04-30T14:07:39ZFrancis Dupontconfiguration changes must be applied with MT stoppedCurrently the config-set code (called by config-set command and loadConfigFile) applies MT configuration at the end of processConfig but does not protect the configuration update against MT.
We have the same problem but easier to fix as...Currently the config-set code (called by config-set command and loadConfigFile) applies MT configuration at the end of processConfig but does not protect the configuration update against MT.
We have the same problem but easier to fix as a critical section is enough for the config backend (timer and command).kea1.7.8Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1184add log message that warn user about running development version2020-05-14T13:57:11ZWlodzimierz Wenceladd log message that warn user about running development versionRight now kea is logging which version is started:
```
DHCP4_STARTED Kea DHCPv4 server version 1.7.6-git started
```
We have clear release system:
* if second number of version is odd - it's development
* if second number of version is e...Right now kea is logging which version is started:
```
DHCP4_STARTED Kea DHCPv4 server version 1.7.6-git started
```
We have clear release system:
* if second number of version is odd - it's development
* if second number of version is even - it's stable
Use simple modulo and if development version is detected - let's print out warning that running this version in production is "on your own responsibility"kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1180Document Lease Query hook lib in Kea ARM2020-05-21T09:53:36ZThomas MarkwalderDocument Lease Query hook lib in Kea ARM#978 creates the hook library in premium. This issue creates the ARM documentation for it.#978 creates the hook library in premium. This issue creates the ARM documentation for it.kea1.7.8Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1173handle congestion recovery in multi-threading mode2020-05-08T08:14:47ZFrancis Duponthandle congestion recovery in multi-threading modeCurrently when the talk queue is full the server run_one method skips the receivePacket() call and returns.
This has a bad impact on mechanisms using external sockets because they are not served.
I propose to handle the congestion reco...Currently when the talk queue is full the server run_one method skips the receivePacket() call and returns.
This has a bad impact on mechanisms using external sockets because they are not served.
I propose to handle the congestion recovery inside the multi-threading code itself:
- make the congestion recovery disabled at configuration time when multi-threading is enabled
- change the task queue (aka ThreadPool) by a ringkea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1171thread sanitizer reporting unit test in perfdhcp2020-05-06T20:07:18ZFrancis Dupontthread sanitizer reporting unit test in perfdhcpLooking the report and the code FakeScenPerfSocket should protect the access to planned_responses_ between receiveX and send methods.Looking the report and the code FakeScenPerfSocket should protect the access to planned_responses_ between receiveX and send methods.kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1170Lease Cmds addLeaseX commands return success when called more than once with...2020-05-07T16:38:00ZThomas MarkwalderLease Cmds addLeaseX commands return success when called more than once with the same leaseA user reported issuing the lease4-add command for an existing lease (i.e. more than once in a row) return success and a message stating that the lease was successfully added. In reality, the command handler calls LeaseMgr::addLease4()...A user reported issuing the lease4-add command for an existing lease (i.e. more than once in a row) return success and a message stating that the lease was successfully added. In reality, the command handler calls LeaseMgr::addLease4() but ignores the return value, which is false if the lease already exists.
This is bound to lead to confusion for the user. If the subsequent add changed values other than subnet id and address, the user might expect those values to have been updated when in fact they have not. They also could not use the result to know if a lease already exists.
It should return CONTROL_RESULT_ERROR with an explanation that it already exists. This would be consistent with other hook libraries such as subnet cmds and host cmds.kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1095thread sanitizer reporting unit test in HA2020-05-06T19:58:45ZWlodzimierz Wencelthread sanitizer reporting unit test in HAhttps://jenkins.isc.org/job/kea-1.7/job/ut-thread/3/testReport/
HAServiceStateMachineTest.waitingSyncingReadyLoadBalancing
```
Error Message
ha_service_unittest.cc:3344
Expected: HA_READY_ST
Which is: 16
To be equal to: ser...https://jenkins.isc.org/job/kea-1.7/job/ut-thread/3/testReport/
HAServiceStateMachineTest.waitingSyncingReadyLoadBalancing
```
Error Message
ha_service_unittest.cc:3344
Expected: HA_READY_ST
Which is: 16
To be equal to: service_->getCurrState()
Which is: 17
Stacktrace
ha_service_unittest.cc:3344
Expected: HA_READY_ST
Which is: 16
To be equal to: service_->getCurrState()
Which is: 17
```
failing on freebsd 12 and ubuntu 1910kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1087Logging and access to current count of 'unacked-clients' during HA heartbeat ...2020-06-26T21:36:16ZCathy AlmondLogging and access to current count of 'unacked-clients' during HA heartbeat communication failures'As suggested from questions on [Support ticket #15920](https://support.isc.org/Ticket/Display.html?id=15920) ...
1. The first question is 'how do I know that my HA peer is ready and waiting to take over if my server fails?'
Particular...As suggested from questions on [Support ticket #15920](https://support.isc.org/Ticket/Display.html?id=15920) ...
1. The first question is 'how do I know that my HA peer is ready and waiting to take over if my server fails?'
Particularly in the case of hot-standby, there's not much visibility into the readiness of the standby server to take over - for example, is it 'seeing' the client traffic that the other server is handling? The conclusion we came to was that it would be good, operationally, to either increase the server (dhcp4 and/or dhcp6) to 'see' the client packets that are being seen but dropped, or to monitor pkt4-received and pkt6-received statistics.
But it might be more helpful if the heartbeat logging (to confirm that the peers are in communication with each other) also indicated whether or not this server is 'seeing' the traffic that it is expecting its partner to handle, unless/until a peer-down state is reached.
2. The second question is 'why hasn't my HA server taken over yet from its peer?'
In most HA configurations, there are two triggers for a server to take over from its peer. The first is that the HA heartbeat has failed (receipt of and/or send of) and HA starts logging communication interrupted. If the server is also configured with non-zero max-unacked-clients, it does not take over right away, but at this point starts watching the client traffic for the other server to determine if it is responding or not.
There is no direct visibility into the status of unacked-clients while it is doing this (although clearly the server that is monitoring and counting them is keeping records). Please could this be logged (along with the HA heartbeat status) so that it's possible for sysadmins to know the full status of HA in a communications-interrupted situation and before reaching the peer-down state.kea1.7.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/999Add option(s) to make use of an additional Kea backup server (with HA) non-bl...2020-05-18T11:42:10ZCathy AlmondAdd option(s) to make use of an additional Kea backup server (with HA) non-blockingThis is from [Support ticket #15378](https://support.isc.org/Ticket/Display.html?id=15378) and is a follow-up feature request to make a Kea HA pair's operation more independent of any backup Kea server that they're also sending lease upd...This is from [Support ticket #15378](https://support.isc.org/Ticket/Display.html?id=15378) and is a follow-up feature request to make a Kea HA pair's operation more independent of any backup Kea server that they're also sending lease updates to.
The question of whether or not this would be a good idea arose during the investigation of #964 - although this request is orthogonal to the work on that issue.
The question asked was, how important is it that the active server(s) in the HA configuration, wait for an acknowledgement to their lease updates from the backup server?
Notably, the backup server does not participate in any HA monitoring - so the HA pair will not know if it becomes unreachable or goes down - they will just end up waiting indefinitely (or possibly failing on a network send) in that case. This could significantly affect the production environment.
Therefore, this is a proposal that we add a configuration 'knob' to make waiting on the acknowledgement of the lease updates to the backup server, an optional thing. (IF the system administrator prefers for the HA pair to wait, then the onus is on them to ensure the availability and reachability of the backup servers, or else...)
---
Ahem, but that then leads to another 'what if?'. What if some of the lease updates go astray? This probably doesn't matter too much - 'almost right' is going to be a better bet for recovery using a backup server (in case both of the HA pair for some reason disappear entirely), than 'nothing at all'. As part of this feature request therefore, could we also consider implementing (on the backup server) a period lease sync (as if it had just been rebooted and was coming online and starting to participate afresh)?
--- And finally, specifically for backup servers where the main HA pair are *not* waiting on acknowledgements on lease updates, should/could we also add an option to batch lease updates every x seconds (or so), to optimise the process for keeping the backup server up to date?kea1.7.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/978Implement simple DHCP Leasequery functionality (per RFC4388 and RFC5007)2020-05-18T14:22:52ZCathy AlmondImplement simple DHCP Leasequery functionality (per RFC4388 and RFC5007)Kea DHCP (up to and including 1.7.1) does not currently support Leasequery in any form.
In [Support ticket #15003](https://support.isc.org/Ticket/Display.html?id=15003) a specific use case is detailed - and it is likely that there are m...Kea DHCP (up to and including 1.7.1) does not currently support Leasequery in any form.
In [Support ticket #15003](https://support.isc.org/Ticket/Display.html?id=15003) a specific use case is detailed - and it is likely that there are many more users of Kea DHCP who would like to avail themselves of this functionality.
Here is one use case for this:
> We host an HFC (Hybrid Fiber coax) infrastructure providing internet service over DOCSIS 3.0 and 3.1. Our core infrastructure is based on Cisco CMTS. We have configured our CMTS such that when a device previously unknown in the network generates/receives IP traffic without an associated ARP entry in CMTS, the CMTS performs a DHCP leasequery to our current DHCP server. The aim is to determine whether the CPE has been given an IP from our DHCP server (versus being statically configured and connected). The CMTS uses the leased IP and the MAC address associated with it that is returned by the DHCP server.
This use case requires simple leasequery functionality.
See also #979 for bulk leasequery functionality.kea1.7.8Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/854Fix incorrect license reference2020-05-14T21:38:52ZGhost UserFix incorrect license referenceHi,
We are considering starting a new project and to use Kea as part of it. During our preliminary license check we found that there are a few files in Kea base package that have this in their license field:
```cpp
// This ...Hi,
We are considering starting a new project and to use Kea as part of it. During our preliminary license check we found that there are a few files in Kea base package that have this in their license field:
```cpp
// This Source Code Form is subject to the terms of the End User License
// Agreement. See COPYING file in the premium/ directory.
```
Above was taken from src/hooks/dhcp/lease_cmds/lease_cmds_callouts.cc
Also present in:
src/hooks/dhcp/stat_cmds/stat_cmds_callouts.cc
src/lib/dhcpsrv/cache_host_data_source.h
However, we cannot find this premium/ folder and the EULA either. Can the EULA be accessed through some other means, f.ex. in some other repo?
Thanks!
Br,
Juhani Heliƶkea1.7.8Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/767keactrl does not work on Alpine Linux: ps problem2020-05-14T12:49:18ZFrancis Dupontkeactrl does not work on Alpine Linux: ps problemThe problem is the default ps command on Alpine Linux is not a POSIX one and does not support the -p argument:
```
BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.
Usage: ps [-o COL1,COL2=HEADER]
Show list of processes
-o...The problem is the default ps command on Alpine Linux is not a POSIX one and does not support the -p argument:
```
BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.
Usage: ps [-o COL1,COL2=HEADER]
Show list of processes
-o COL1,COL2=HEADER Select columns for display
'''
Solved by installing a full ps command from the procps package.kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/662perfdhcp sends `rate` * `exit-wait-time` too many packets2020-05-22T13:46:54ZAndrei Pavelandrei@isc.orgperfdhcp sends `rate` * `exit-wait-time` too many packetsWhen running `perfdhcp` with the `-f` and `-n` parameters, perfdhcp sends `num-request` + `renew-rate` packets. Is this intended? Should it not only send `num-request` packets?
Here is the command I used.
```
perfdhcp -D 1024 -d 1024 -d...When running `perfdhcp` with the `-f` and `-n` parameters, perfdhcp sends `num-request` + `renew-rate` packets. Is this intended? Should it not only send `num-request` packets?
Here is the command I used.
```
perfdhcp -D 1024 -d 1024 -d 1024 -f 16 -n 1024 -n 1024 -r 16 -6 -R 4294967295 -W 1000000 -l ens4
```
And it resulted in:
```
***Statistics for: SOLICIT-ADVERTISE***
sent packets: 1040
```
Notice that `rate` == `renew-rate`. Could be relevant.
Could behave the same for `-F`.kea1.7.8Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/477perfdhcp should handle received malformed packets2020-05-22T15:39:04ZMichal Nowikowskiperfdhcp should handle received malformed packetsThis is in perf_socket.cc in receive[46] methods while unpacking pkt.
Perfdhcp should trace an issue with the packet at least.
Maybe store some stats about that.
See note in this review:
https://gitlab.isc.org/isc-projects/kea/merge_req...This is in perf_socket.cc in receive[46] methods while unpacking pkt.
Perfdhcp should trace an issue with the packet at least.
Maybe store some stats about that.
See note in this review:
https://gitlab.isc.org/isc-projects/kea/merge_requests/237#note_44923kea1.7.8Wlodzimierz WencelWlodzimierz Wencel