Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-27T15:17:48Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3279ddns[46]_update documented argument names incorrect2024-03-27T15:17:48ZPatrick Armitageddns[46]_update documented argument names incorrectsrc/bin/dhcp[46]/dhcp[46]_hooks.dox document arguments _fwd_update_, _rev_update_ and _ddns_params_. Using these parameter names causes an exception to be thrown:
```
ERROR HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook ddns...src/bin/dhcp[46]/dhcp[46]_hooks.dox document arguments _fwd_update_, _rev_update_ and _ddns_params_. Using these parameter names causes an exception to be thrown:
```
ERROR HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook ddns4_update registered by library with index 1 (callout address 0x7fff875b8ffc): unable to find argument with name fwd_update
```
The names for these arguments in the code are _fwd-update_, _rev-update_ and _ddns-param_, i.e. the _'s should be -'s.
The following patch corrects the issue:
```
commit 67063ae09d2c1f924586404eea2fa85a328bccb5 (HEAD -> master)
Author: Quentin Armitage <quentin@armitage.org.uk>
Date: Thu Feb 29 17:44:38 2024 +0000
Fix documentation for ddns[46]_update hooks
The documented argument names fwd_update, rev_update and ddns_params
should be fwd-update, rev_update and ddns-params.
Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
diff --git a/src/bin/dhcp4/dhcp4_hooks.dox b/src/bin/dhcp4/dhcp4_hooks.dox
index ae6c903ff9..ed0620e035 100644
--- a/src/bin/dhcp4/dhcp4_hooks.dox
+++ b/src/bin/dhcp4/dhcp4_hooks.dox
@@ -260,9 +260,9 @@ called before "subnet4_select".
- name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in</b>
- name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
- name: @b hostname, type: std::string, direction: <b>in/out</b>
- - name: @b fwd_update, type: bool, direction: <b>in/out</b>
- - name: @b rev_update, type: bool, direction: <b>in/out</b>
- - name: @b ddns_params, type: isc::dhcp::DdnsParamsPtr, direction: <b>in</b>
+ - name: @b fwd-update, type: bool, direction: <b>in/out</b>
+ - name: @b rev-update, type: bool, direction: <b>in/out</b>
+ - name: @b ddns-params, type: isc::dhcp::DdnsParamsPtr, direction: <b>in</b>
- @b Description: this callout is executed after the server has selected
a lease and has formed a host name to associate with the lease and/or use
@@ -272,17 +272,17 @@ called before "subnet4_select".
host name as well as whether or not forward and/or reverse updates are
enabled.
- Upon entry into the callout, the arguments <b>hostname</b>,<b>fwd_update</b>,
- and <b>rev_update</b> have been set by the server based on the client packet,
+ Upon entry into the callout, the arguments <b>hostname</b>,<b>fwd-update</b>,
+ and <b>rev-update</b> have been set by the server based on the client packet,
and various configuration values (e.g host reservations, DDNS behavioral
parameters, etc). Upon return from the callout, any changes to these
values will be applied as follows:
- If <b>hostname</b> has changed it will be used to update the outbound
host name (option 12) if it exists, the output FQDN option (option 81)
if it exists, and used as the FQDN sent in DNS updates
- - Forward DNS update(s) will be done if <b>fwd_update</b> is true (and
+ - Forward DNS update(s) will be done if <b>fwd-update</b> is true (and
<b>kea-dhcp-ddns</b> connectivity is enabled)
- - Reverse DNS update(s) will be done if <b>rev_update</b> is true (and
+ - Reverse DNS update(s) will be done if <b>rev-update</b> is true (and
<b>kea-dhcp-ddns</b> connectivity is enabled)
- <b>Next step status</b>: Not applicable, its value will be ignored.
```
There appears to be no tests for the ddns[46]_update hooks. Should some be added?kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3228Add monitoring instrumentation around `dhcp-disable` state.2024-02-01T14:49:57ZTomek MrugalskiAdd monitoring instrumentation around `dhcp-disable` state.For details, see [github PR#133](https://github.com/isc-projects/kea/pull/133).For details, see [github PR#133](https://github.com/isc-projects/kea/pull/133).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/321Make it possible to start the server without all the configured interfaces re...2024-02-08T14:36:54ZVicky Riskvicky@isc.orgMake it possible to start the server without all the configured interfaces ready (GH#91)<Originally reported on Github as issue #91 by karaluh on July 6, 2018>
Dibbler has an "inactive-mode" option, which works like this, according to the official docs:
During normal startup, client tries to bind all interfaces defined in...<Originally reported on Github as issue #91 by karaluh on July 6, 2018>
Dibbler has an "inactive-mode" option, which works like this, according to the official docs:
During normal startup, client tries to bind all interfaces defined in a configuration file. If such attempt
fails, client reports an error and gives up. Usually that is best action. However, in some cases it is possible that interface is not ready yet, e.g. WLAN interface did not complete association. Dibbler attempt to detect link-local addresses, bind any sockets or initiate any kind of communication will fail. To work around this disadvantage, a new mode has been introduced in the 0.6.0RC4 version. It is possible to modify client behavior, so it will accept downed and not running interfaces. To do so, inactive-mode
keyword must be added to client.conf file. In this mode, client will accept inactive interfaces, will add
them to inactive list and will periodically monitor its state. When the interface finally goes on-line, client
will try to configure it."
My use case is PD over PPP interfaces which come and go as they please during the server process lifetime and mostly aren't there when the server starts.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/269client_encoding in PostgreSQL connection2022-11-02T15:08:44ZGhost Userclient_encoding in PostgreSQL connection---
name: client_encoding in PostgreSQL connection
about: Make connection's client_encoding configurable
---
**Related problem**
Sometimes it is impossible to execute lease{4,6}_{update,insert} SQLs in configuration with PostgreSQL dat...---
name: client_encoding in PostgreSQL connection
about: Make connection's client_encoding configurable
---
**Related problem**
Sometimes it is impossible to execute lease{4,6}_{update,insert} SQLs in configuration with PostgreSQL database created with default UTF8 encoding and default server's encoding set to UTF8. This is because some DHCP clients are not fully compatible with RFC1035 and are using 8-bit ASCII codes in hostname options. This, in case, results in errors like '2018-11-12 23:36:44.762 ERROR [kea-dhcp4.alloc-engine/30224] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 a0:f3:c1:9d:33:d5], cid=[01:a0:f3:c1:9d:33:d5], tid=0x55527316: error during attempt to allocate an IPv4 address: Statement exec failed: for: update_lease4, status: 7sqlstate:[ 22021], reason: ERROR: invalid byte sequence for encoding "UTF8": 0xc0 0x90'
**Solution**
One possible solution is to change "client_encoding" connection parameter to "latin1" value. This eliminates problem of PostgreSQL's parsing such problematic string as UTF8 string and makes it possible to store hostname value "as is".
To make this connection parameter configurable, I've added configuration parameter "client-encoding" visible in LEASE_DATABASE, HOSTS_DATABASE and CONFIG_DATABASE scopes.
I've attached the patch against today's master branch of repo.
I can also make a pull request, if you need it
Also, I can backport this patch to 1.4.0 and 1.5.0 version, because it fixes some possible problems
[client_encoding_master.patch](/uploads/db18cf7ffa25ca65bbfaa1a825cf73ca/client_encoding_master.patch)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/695use a subnet's domain-name as a qualifying suffix for DDNS (trac #5048)2020-08-27T11:53:01ZGhost Useruse a subnet's domain-name as a qualifying suffix for DDNS (trac #5048)https://github.com/isc-projects/kea/pull/106
Proposed fix for:
https://oldkea.isc.org/ticket/5048
"Kea servers should be able to use a subnet's domain-name as a qualifying suffix for DDNS"
https://lists.isc.org/pipermail/kea-users/2017...https://github.com/isc-projects/kea/pull/106
Proposed fix for:
https://oldkea.isc.org/ticket/5048
"Kea servers should be able to use a subnet's domain-name as a qualifying suffix for DDNS"
https://lists.isc.org/pipermail/kea-users/2017-January/000776.html
https://lists.isc.org/pipermail/kea-users/2017-February/000813.html
This fix is against KEA 1.4.0
https://github.com/isc-projects/kea/pull/106
UPDATE:
Uploaded patch against 1.5.0
Opening issue so it stays on your radar.
Can I ask you to open an issue there, so this fix is on Kea engineers' radars? We don't look at github too often...outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/348Small experiment improving congestion control locks2023-03-15T11:43:45ZFrancis DupontSmall experiment improving congestion control locksI propose a small experiment to see if this trivial (and recognized as correct) change makes a noticeable difference. I leave to QA the win threshold which requires inclusion in 1.5 or 1.6.
The change is here and in the attachment too.
...I propose a small experiment to see if this trivial (and recognized as correct) change makes a noticeable difference. I leave to QA the win threshold which requires inclusion in 1.5 or 1.6.
The change is here and in the attachment too.
```
diff --git a/src/lib/dhcp/packet_queue_ring.h b/src/lib/dhcp/packet_queue_ring.h
index 315e2a0375..bcaa496747 100644
--- a/src/lib/dhcp/packet_queue_ring.h
+++ b/src/lib/dhcp/packet_queue_ring.h
@@ -123,12 +123,12 @@ public:
/// @return A pointer to dequeued packet, or an empty pointer
/// if the queue is empty.
virtual PacketTypePtr popPacket(const QueueEnd& from = QueueEnd::FRONT) {
- isc::util::thread::Mutex::Locker lock(mutex_);
PacketTypePtr packet;
if (queue_.empty()) {
return (packet);
}
+ isc::util::thread::Mutex::Locker lock(mutex_);
if (from == QueueEnd::FRONT) {
packet = queue_.front();
queue_.pop_front();
```
[better-lock.diff](/uploads/0f3a20502c39e13e033d0818fd20b25c/better-lock.diff)outstanding