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/2826Options with space dont get encapsulated from hosts database2023-07-17T13:58:20ZRichard KojedzinszkyOptions with space dont get encapsulated from hosts database**Describe the bug**
I have static option-definitions for ipxe namespace, from https://gitlab.isc.org/isc-projects/kea/-/issues/2366#note_284084. Then, I have a few records for my host reservation in postgresql database, as the dump sho...**Describe the bug**
I have static option-definitions for ipxe namespace, from https://gitlab.isc.org/isc-projects/kea/-/issues/2366#note_284084. Then, I have a few records for my host reservation in postgresql database, as the dump shows:
```
COPY public.dhcp4_options (option_id, code, value, formatted_value, space, persistent, dhcp_client_class, dhcp4_subnet_id, host_id, scope_id, user_context, shared_network_name, pool_id, modification_ts) FROM stdin;
18 175 \N \N \N f \N \N 4 3 \N \N \N 2023-04-01 13:15:54.656377+00
21 190 \\x69736373692d626f6f74 \N ipxe f \N \N 4 3 \N \N \N 2023-04-01 14:24:30.740714+00
22 191 \\x694b454d65784e6961663364 \N ipxe f \N \N 4 3 \N \N \N 2023-04-01 14:24:39.73297+00
23 203 \\x69716e2e323032322d30342e636c6f75642e6b776562733a6666 \N \N f \N \N 4 3 \N \N \N 2023-04-01 14:26:14.582959+00
24 17 \\x69736373693a3139322e3136382e382e36353a3a3a3a69716e2e323030352d31302e6f72672e667265656e61732e63746c3a69736373692d626f6f74 \N \N f \N \N 4 3 \N \N \N 2023-04-01 14:29:07.290341+00
25 176 \\x01 \N ipxe f \N \N 4 3 \N \N \N 2023-04-01 14:31:35.581516+00
\.
```
Howewer, options in space `ipxe` dont get added, encapsulated.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with debug logging
2. Start up a vm with kvm without disk to boot with pxe
3. Observe debug output
**Expected behavior**
Expected the same behavior with the following static configuration snippet:
4. See that option 170 is requested, howewer the response contains an empty value for that option.
```
"reservations": [
{
"hw-address": "00:11:...",
"option-data": [
{
"code": 175
},
{
"code": 190,
"space": "ipxe",
"data": "iscsi-boot"
}
...
]
}
]
```
**Environment:**
- Kea version: 2.2.0
- OS: Debian 11
- Compiled with postgresql backend
- No hook libraries
**Additional Information**
Seems that this little patch would fix my issue:
```
diff --git a/src/lib/dhcpsrv/pgsql_host_data_source.cc b/src/lib/dhcpsrv/pgsql_host_data_source.cc
index a1251be692..5c438aac17 100644
--- a/src/lib/dhcpsrv/pgsql_host_data_source.cc
+++ b/src/lib/dhcpsrv/pgsql_host_data_source.cc
@@ -2530,6 +2530,11 @@ PgSqlHostDataSourceImpl::getHostCollection(PgSqlHostContextPtr& ctx,
<< tagged_statements[stindex].name);
}
}
+
+ for (auto& host : result) {
+ boost::const_pointer_cast<Host>(host)->getCfgOption4()->encapsulate();
+ boost::const_pointer_cast<Host>(host)->getCfgOption6()->encapsulate();
+ }
}
ConstHostPtr
```kea2.4.0Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2494doc: Invalid JSON in DHCP6 Server configuration examples2023-07-17T13:58:22ZKevin Flemingdoc: Invalid JSON in DHCP6 Server configuration examplesTwo of the configuration examples in the DHCP6 Server 'host reservations' section of the ARM include invalid JSON. Opening this issue to provide a number for the soon-to-be-created MR :-)Two of the configuration examples in the DHCP6 Server 'host reservations' section of the ARM include invalid JSON. Opening this issue to provide a number for the soon-to-be-created MR :-)kea2.3.5Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2404Actual GSS-TSIG rekey interval is longer than rekey-interval value2022-07-21T20:34:27ZPeter DaviesActual GSS-TSIG rekey interval is longer than rekey-interval valueWe've noticed that rekeying of GSS-TSIG key almost always involves additional
retry-interval seconds after the value specified in rekey-interval
For details, kea-dhcp-ddns config and a suggested patch see: [RT 20794](https://supp...We've noticed that rekeying of GSS-TSIG key almost always involves additional
retry-interval seconds after the value specified in rekey-interval
For details, kea-dhcp-ddns config and a suggested patch see: [RT 20794](https://support.isc.org/Ticket/Display.html?id=20794)kea2.2.0 - a new stable branchRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2276Disable DHCID2024-02-21T15:33:39ZPeter DaviesDisable DHCIDDisable DHCID:
It has been requested that there be configurable options in the kea-dhcp-ddns configuration file that could:
1) Disable the creation of DHCID records. Perhaps on the domain-name level.
2) Require a DHCID to exist but n...Disable DHCID:
It has been requested that there be configurable options in the kea-dhcp-ddns configuration file that could:
1) Disable the creation of DHCID records. Perhaps on the domain-name level.
2) Require a DHCID to exist but not require its value to match that of the new entry.
[RT #20029 ](https://support.isc.org/Ticket/Display.html?id=20029)
see also https://gitlab.isc.org/isc-projects/kea/-/issues/455kea2.5.0Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2262keactrl exits with an error without definitions for netconf2022-02-14T16:22:43ZJinmei Tatuyakeactrl exits with an error without definitions for netconf**Describe the bug**
I'm trying Kea 2.0.1 (which is built without kea-netconf). If I try to start Kea servers using `keactrl` with the following configuration:
```
prefix=/home/keadist
kea_dhcp4_config_file=${prefix}/etc/kea/kea-dhcp4...**Describe the bug**
I'm trying Kea 2.0.1 (which is built without kea-netconf). If I try to start Kea servers using `keactrl` with the following configuration:
```
prefix=/home/keadist
kea_dhcp4_config_file=${prefix}/etc/kea/kea-dhcp4.conf
kea_dhcp6_config_file=${prefix}/etc/kea/kea-dhcp6.conf
kea_dhcp_ddns_config_file=${prefix}/etc/kea/kea-dhcp-ddns.conf
kea_ctrl_agent_config_file=${prefix}/etc/kea/kea-ctrl-agent.conf
exec_prefix=${prefix}
dhcp4_srv=${exec_prefix}/sbin/kea-dhcp4
dhcp6_srv=${exec_prefix}/sbin/kea-dhcp6
dhcp_ddns_srv=${exec_prefix}/sbin/kea-dhcp-ddns
ctrl_agent_srv=${exec_prefix}/sbin/kea-ctrl-agent
dhcp4=yes
dhcp6=no
dhcp_ddns=no
ctrl_agent=no
kea_verbose=no
```
then the servers start up but keactrl exits with a non-0 status:
```
# /home/keadist/sbin/keactrl start -c $PWD/keactrl.conf && echo OK
/home/keadist/sbin/keactrl: 467: /home/keadist/sbin/keactrl: netconf: parameter not set
INFO/keactrl: Starting /home/keadist/sbin/kea-dhcp4 -c /home/keadist/etc/kea/kea-dhcp4.conf
INFO/keactrl: Starting /home/keadist/sbin/kea-dhcp-ddns -c /home/keadist/etc/kea/kea-dhcp-ddns.conf
/home/keadist/sbin/keactrl: 488: /home/keadist/sbin/keactrl: netconf_srv: parameter not set
```
(Note that "OK" isn't emitted)
Same for `keactrl stop`.
The cause of this looks like the following check:
```
# Exit with error if commands exit with non-zero and if undefined variables are
# used.
set -eu
```
and the fact that the `keactrl.conf` file doesn't define `netconf_srv`. So the execution of `keactrl` triggers an error at line 488:
```
run_conditional "netconf" "start_server ${netconf_srv} -c ${kea_netconf_config_file} \
${args}" 1
```
(I initially thought the same thing could happen on line 467, but probably because of the use of a pipe it somehow avoids this failure mode).
**To Reproduce**
See above.
**Expected behavior**
I would expect `keactrl` exits normally (with the exit status of 0) when Kea is built without the support of netconf. One might argue that the configuration should have netconf related definitions, but it doesn't make sense to me if Kea isn't build its support (so `netconf_srv` should be set to some placeholder value, which would look awkward). Besides, `keactrl` already seems to try avoiding this failure mode in some places, e.g.:
```
if ${have_netconf}; then
printf "Kea Netconf configuration file: %s\n" "${kea_netconf_config_file}"
fi
```
Addressing the essentially same glitch in place but not for other places is inconsistent.
**Environment:**
- Kea version: 2.0.1
- OS: Ubuntu 18.04.4 x64
- Build option: `--disable-static --enable-generate-messages --with-gtest-source`. I don't think it matters for this issue, but I'd note that libyang etc wasn't detected and `kea-netconf` wasn't built.
- No hook is used (again, though, I don't think it matters)kea2.1.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1934Dual stack DDNS2022-01-13T16:24:34Zjohn dickinsonDual stack DDNS---
name: Dual stack DDNS
about: Documentation and feature request regarding Dual stack DDNS
---
Testing with kea 1.9.8 and Ubuntu 20.04 as dhcp client.
I find the documentation regarding ddns in dual stacked networks a bit confusing. 8...---
name: Dual stack DDNS
about: Documentation and feature request regarding Dual stack DDNS
---
Testing with kea 1.9.8 and Ubuntu 20.04 as dhcp client.
I find the documentation regarding ddns in dual stacked networks a bit confusing. 8.2.21. Using Client Identifier and Hardware Address https://downloads.isc.org/isc/kea/1.9.8/doc/html/arm/dhcp4-srv.html#using-client-identifier-and-hardware-address talks about the need for matching identifiers and gives the distinct impression that it works in Kea. However, 13.1.3. Dual-Stack Environments https://downloads.isc.org/isc/kea/1.9.8/doc/html/arm/ddns.html#dual-stack-environments clearly says that Kea does not currently support this feature.
Please could you add a Note to the 8.2.21 section saying that this is not supported or better yet could you add this functionality.
If you just do the doc update them you also need to fix the text referring to RFC4703 to be RFC4361 in section 13.1.3 (the link is of it's just the text that is wrong).
As for adding this feature, I have seen a couple of messages on kea-users related to this that have no response.
From what I can see with wireshark all the information needed to do this is provided in a v4 client identifier and is identical to that in v6. Here is a hexdump of the Client Identifier option in both v4 and v6:
```
v4
0000 3d 13 ff 5d e2 6c 15 00 02 00 00 ab 11 9a 57 20 =..].l........W
0010 95 71 61 bd d0 .qa..
v6
0000 00 01 00 0e 00 02 00 00 ab 11 9a 57 20 95 71 61 ...........W .qa
0010 bd d0 ..
```
As you can see both contain 00 02 00 00 ab 11 9a 57 20 95 71 61 bd d0 and in v4 the third octet is ff (255) as specified in RFC4361 6.1
If you are going to add this feature please could you give some idea of timescale? If this is not a priority, let me know I could try and find some time to hack together a fix :)kea2.1.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1918Kea 1.9.8 is not working with Dell X10522022-09-01T14:36:29ZTommyKea 1.9.8 is not working with Dell X1052---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug:**
Kea does not work with Dell X1052 switch. While having no issues with old dhcpd or any other dhcp server.
**To Reproduce**
Steps to reproduce the...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug:**
Kea does not work with Dell X1052 switch. While having no issues with old dhcpd or any other dhcp server.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea (dhcpv4) with the configuration that is provided below.
2. A client sends `DISCOVER` packet.
3. Kea answers with `OFFER`.
4. Client does not follow with `REQUEST`.
**Expected behavior:**
The client is supposed to send back `REQUEST` packet.
**Environment:**
- Kea version: 1.9.8
- OS: Ubuntu 20.04.2 LTS
- If/which hooks where loaded in: libdhcp_lease_cmds.so, libdhcp_stat_cmds.so, libdhcp_ha.so. But, as I mentioned, tried it with the default configuration and result was the same.
**Additional Information**
Configuration:
```
{
"Dhcp4": {
"next-server": "10.5.255.254",
"boot-file-name": "/dev/null",
"echo-client-id": false,
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea/dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"valid-lifetime": 300,
"max-valid-lifetime": 300,
"interfaces-config": {
"interfaces": [
"eno1/10.5.255.254"
]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/tmp/kea-ipv4-leases.csv",
"lfc-interval": 600
},
"option-data": [
{
"space": "dhcp4",
"name": "domain-name-servers",
"code": 6,
"data": "8.8.8.8"
}
],
"shared-networks": [
{
"name": "test",
"subnet4": [
{
"subnet": "10.5.0.0/16",
"pools": [
{
"pool": "10.5.20.100 - 10.5.40.100"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "10.5.0.1"
}
]
}
]
}
]
}
}
```
Kea debug output:
```
2021-06-07 21:26:36.579 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.5.0.0/16 for packet received by matching address 10.5.255.254
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.packets/736980.140690847578560] DHCP4_SUBNET_SELECTED [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: the subnet with ID 1 was selected for client assignments
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.packets/736980.140690847578560] DHCP4_SUBNET_DATA [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: the selected subnet details: 10.5.0.0/16
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by hwaddr=684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=684F64BE59E3, found 0 host(s)
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier hwaddr=684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by client-id=01684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01684F64BE59E3
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01684F64BE59E3, found 0 host(s)
2021-06-07 21:26:36.580 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier client-id=01684F64BE59E3
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcp4/736980.140690847578560] DHCP4_CLASS_ASSIGNED [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: client packet has been assigned to the following class(es): UNKNOWN
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcp4/736980.140690847578560] DHCP4_CLASS_ASSIGNED [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_X1052, UNKNOWN
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.ddns/736980.140690847578560] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: processing client's Hostname option
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:68:4f:64:be:59:e3
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 68:4f:64:be:59:e3
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.alloc-engine/736980.140690847578560] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed
2021-06-07 21:26:36.581 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.5.20.163
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.dhcpsrv/736980.140690847578560] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.5.20.164
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 10.5.20.164
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.5.20.164
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.5.20.164, found 0 host(s)
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.hosts/736980.140690847578560] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 1 and address 10.5.20.164
2021-06-07 21:26:36.582 INFO [kea-dhcp4.leases/736980.140690847578560] DHCP4_LEASE_ADVERT [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: lease 10.5.20.164 will be advertised
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.options/736980.140690847578560] DHCP4_PACKET_PACK [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: preparing on-wire format of the packet to be sent
2021-06-07 21:26:36.582 DEBUG [kea-dhcp4.packets/736980.140690847578560] DHCP4_PACKET_SEND [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: trying to send packet DHCPOFFER (type 2) from 10.5.255.254:67 to 255.255.255.255:68 on interface eno1
2021-06-07 21:26:36.583 DEBUG [kea-dhcp4.packets/736980.140690847578560] DHCP4_RESPONSE_DATA [hwtype=1 68:4f:64:be:59:e3], cid=[01:68:4f:64:be:59:e3], tid=0x9d0e4aed: responding with packet DHCPOFFER (type 2), packet details: local_address=10.5.255.254:67, remote_address=255.255.255.255:68, msg_type=DHCPOFFER (2), transid=0x9d0e4aed,
options:
type=001, len=004: 4294901760 (uint32)
type=003, len=004: 10.5.0.1
type=006, len=004: 8.8.8.8
type=051, len=004: 300 (uint32)
type=053, len=001: 2 (uint8)
type=054, len=004: 10.5.255.254
type=061, len=007: 01:68:4f:64:be:59:e3
```
PCAP when DELL x1052 is trying to get dhcp from Kea (not working):
[kea.pcap](/uploads/8ffbf576932a58e56aa46b81218a349c/kea.pcap)
PCAP when DELL x1052 is trying to get dhcp from dhcpd (working as expected):
[dhcpd.pcap](/uploads/5d884c3cdf13b3902bf147f5bc20f04f/dhcpd.pcap)
- There are no errors or related logs in X1052 switch.
- If offer is sent from any other dhcp server Dell switch accepts it and sends `REQUEST` back as expected. Then you can start Kea and it will continue to work with Kea as well, as the `offer` part is already 'done' and `REQUEST` packets are being sent from Dell.
- Working on this with Dell support as well, but no results at the moment.
- If anyone has any insights of what could be tested to change this behaviour - please let me know.
If you need more details - just let me know and I will provide it.
**Contacting you:**
Send a message in GitLab.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1839gcc11 patch2021-05-20T10:48:41ZTomek Mrugalskigcc11 patchThere's a [report on github](https://github.com/isc-projects/kea/pull/120) that Kea fails to build with gcc11. While gcc11 is not available as a default compiler in any distros I'm aware of **yet**, this will change soon.
There's a patc...There's a [report on github](https://github.com/isc-projects/kea/pull/120) that Kea fails to build with gcc11. While gcc11 is not available as a default compiler in any distros I'm aware of **yet**, this will change soon.
There's a patch provided and it seems both small and reasonable. Normal review regime needs to be followed, though.kea1.9.8https://gitlab.isc.org/isc-projects/kea/-/issues/1584NAK sent while authoritative=false2021-12-04T11:48:04ZJoost BekkersNAK sent while authoritative=false
**Describe the bug**
When two dhcp servers are serving the same subnet. Kea can receive a REBIND from a client which currently has a lease issued by the other server. Kea notices this and reports ALLOC_ENGINE_V4_REQUEST_OUT_OF_POOL and ...
**Describe the bug**
When two dhcp servers are serving the same subnet. Kea can receive a REBIND from a client which currently has a lease issued by the other server. Kea notices this and reports ALLOC_ENGINE_V4_REQUEST_OUT_OF_POOL and DHCP4_PACKET_NAK_0004. The NAK is sent even though the subnet has authoritative set to false.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4 (S1) and a second dhcp server (S2) in the same subnet with non-overlapping pools.
Both servers should be configured as 'not authoritative'.
2. Have a client obtain a lease from S2
3. Have that client perform a REBIND for that lease
4. Observe S1 send a NAK for the valid lease
**Expected behavior**
The server should only send a NAK if either it is authoritative, or the ciaddr/requested-ip-address belongs to its own pool/reservations.
**Environment:**
- Kea version: 1.8.0
- OS: FreeBSD 12.2
- MySQL backend was compiled in, but not configured
- Hooks: flex-option, stats
**Additional Information**
```
DEBUG [kea-dhcp4.packets/38691.0x80173a000] DHCP4_BUFFER_RECEIVED received buffer from 10.2.175.149:68 to 255.255.255.255:67 over interface vmx1
DEBUG [kea-dhcp4.options/38691.0x80173a000] DHCP4_BUFFER_UNPACK parsing buffer received from 10.2.175.149 to 255.255.255.255 over interface vmx1
DEBUG [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS1 evaluated to 0
DEBUG [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS2 evaluated to 0
DEBUG [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS3 evaluated to 0
INFO [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS4 evaluated to 1
DEBUG [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS5 evaluated to 0
INFO [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS6 evaluated to 1
INFO [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS7 evaluated to 1
DEBUG [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS8 evaluated to 0
INFO [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS9 evaluated to 1
INFO [kea-dhcp4.options/38691.0x80173a000] EVAL_RESULT Expression USER_CLASS10 evaluated to 1
DEBUG [kea-dhcp4.dhcpsrv/38691.0x80173a000] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.2.0.0/16 for packet received by matching address 10.2.0.8
DEBUG [kea-dhcp4.packets/38691.0x80173a000] DHCP4_SUBNET_SELECTED [hwtype=1 34:e3:80:13:a5:60], cid=[ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60], tid=0x5d0d759e: the subnet with ID 167903232 was selected for client assignments
DEBUG [kea-dhcp4.packets/38691.0x80173a000] DHCP4_PACKET_RECEIVED [hwtype=1 34:e3:80:13:a5:60], cid=[ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60], tid=0x5d0d759e: DHCPREQUEST (type 3) received from 10.2.175.149 to 255.255.255.255 on interface vmx1
DEBUG [kea-dhcp4.dhcpsrv/38691.0x80173a000] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.2.0.0/16 for packet received by matching address 10.2.0.8
DEBUG [kea-dhcp4.packets/38691.0x80173a000] DHCP4_SUBNET_SELECTED [hwtype=1 34:e3:80:13:a5:60], cid=[ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60], tid=0x5d0d759e: the subnet with ID 167903232 was selected for client assignments
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 167903232, identified by hwaddr=34E38013A560
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=34E38013A560
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=34E38013A560, found 0 host(s)
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 167903232 and identifier hwaddr=34E38013A560
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 167903232, identified by duid=0003000134E38013A560
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: duid=0003000134E38013A560
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier duid=0003000134E38013A560, found 0 host(s)
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 167903232 and identifier duid=0003000134E38013A560
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 167903232, identified by circuit-id=011630352D33362D5350302D303030343137352D31303230
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: circuit-id=011630352D33362D5350302D303030343137352D31303230
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier circuit-id=011630352D33362D5350302D303030343137352D31303230, found 0 host(s)
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 167903232 and identifier circuit-id=011630352D33362D5350302D303030343137352D31303230
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 167903232, identified by client-id=FF000100010003000134E38013A560
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=FF000100010003000134E38013A560
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=FF000100010003000134E38013A560, found 0 host(s)
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 167903232 and identifier client-id=FF000100010003000134E38013A560
DEBUG [kea-dhcp4.dhcp4/38691.0x80173a000] DHCP4_CLASS_ASSIGNED [hwtype=1 34:e3:80:13:a5:60], cid=[ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60], tid=0x5d0d759e: client packet has been assigned to the following class(es): UNKNOWN
DEBUG [kea-dhcp4.dhcp4/38691.0x80173a000] DHCP4_CLASS_ASSIGNED [hwtype=1 34:e3:80:13:a5:60], cid=[ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60], tid=0x5d0d759e: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_geneos-lunar-3.13.1-R,lunar,platinum-7840,dslforum.org, USER_CLASS4, USER_CLASS6, USER_CLASS7, USER_CLASS9, USER_CLASS10, UNKNOWN
DEBUG [kea-dhcp4.ddns/38691.0x80173a000] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 34:e3:80:13:a5:60], cid=[ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60], tid=0x5d0d759e: processing client's Hostname option
DEBUG [kea-dhcp4.dhcpsrv/38691.0x80173a000] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60
DEBUG [kea-dhcp4.dhcpsrv/38691.0x80173a000] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 34:e3:80:13:a5:60
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 167903232 and IPv4 address 10.2.175.149
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.2.175.149
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.2.175.149, found 0 host(s)
DEBUG [kea-dhcp4.hosts/38691.0x80173a000] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 167903232 and address 10.2.175.149
DEBUG [kea-dhcp4.dhcpsrv/38691.0x80173a000] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.2.175.149
DEBUG [kea-dhcp4.alloc-engine/38691.0x80173a000] ALLOC_ENGINE_V4_REQUEST_OUT_OF_POOL client [hwtype=1 34:e3:80:13:a5:60], cid=[ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60], tid=0x5d0d759e, which doesn't have a reservation, requested address 10.2.175.149 out of the dynamic pool
DEBUG [kea-dhcp4.bad-packets/38691.0x80173a000] DHCP4_PACKET_NAK_0004 [hwtype=1 34:e3:80:13:a5:60], cid=[ff:00:01:00:01:00:03:00:01:34:e3:80:13:a5:60], tid=0x5d0d759e: failed to grant a lease, client sent ciaddr 10.2.175.149, requested-ip-address (no address)
```
**Contacting you**
j.bekkers at e-quest dot nlkea2.1.0Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1445Forensic logging should cover DECLINE and RELEASE2020-10-22T17:18:24ZTomek MrugalskiForensic logging should cover DECLINE and RELEASEIt was reported (see [support#17179](https://support.isc.org/Ticket/Display.html?id=17179)) that the forensic logging could handle the situation better when:
* client sends DECLINE
* client sends RELEASE
See patch attached in the suppo...It was reported (see [support#17179](https://support.isc.org/Ticket/Display.html?id=17179)) that the forensic logging could handle the situation better when:
* client sends DECLINE
* client sends RELEASE
See patch attached in the support ticket.kea1.9.1Tomek MrugalskiTomek Mrugalskihttps://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/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/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)outstandinghttps://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/181reallocate IPv6-Addr with one Host and different DUIDs not working2023-09-19T15:24:09ZGeorg W.reallocate IPv6-Addr with one Host and different DUIDs not working---
name: Bug report
about: Reallocate IPv6-Address not working properly with PXE (or multiple OS)
---
I've tried to get some help using the kea-users mailing list months ago but I didn't get a solution to this problem. For now, I comp...---
name: Bug report
about: Reallocate IPv6-Address not working properly with PXE (or multiple OS)
---
I've tried to get some help using the kea-users mailing list months ago but I didn't get a solution to this problem. For now, I compiled myself a workaround into the code to get the IPv6 leases by hw-addr and not by duid. Details following:
***Description***
The Kea dhcp6 daemon doesn't reallocate (active) IPv6-leases for an OS after a successful PXE IPv6 address allocation.
***Configuration***
(configuration file is attached)
- lease-database: postgresql
- hosts-database: postgresql
- mac-sources: client-link-addr-option only
- host-reservation-identifiers: hw-address only
***To Reproduce***
Steps to reproduce the behavior:
1. Run Kea dhcpv6-daemon with: ```"mac-sources": ["client-link-addr-option"]``` and ```"host-reservation-identifiers": ["hw-address"]``` and an IPv6 host reservation with hw-address as the specific reservation-id-type
2. boot the PXE-System (or the first OS) first, everything works fine
3. boot another OS (e.g. Debian) with this host, daemon answers with "Sorry, no address could be allocated."
***Expected behavior***
In the configuration file exists a parameter called "host-reservation-identifiers". Kea uses only these specific identifier types to get host reservations from the host database. To get all active Leases of a hostsystem, Kea should use the same Method like in the reservation procedure.
If the host boots up the first time with PXE, kea gets a request, gets the host-reservation and allocate this IPv6 with its hw-address. Now the host boots up with its real OS (e.g. Debian) and kea should search for a lease like it was searching for a host-reservation.
In our case:
Kea gets the mac-address from the clients client-link-addr-option and so Kea should search for active leases by the mac-address, because of the host-reservation-identifiers option.
***Environment***
- Kea version: 1.4.0 (from gitlab)
- OS: debian stretch
- used database back-end: postgresql
- no hooks were used
Atachements
***kea-dhcp6.conf***
```
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "eth0/2001:db8::8d:37:c0:f6" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea-dhcp6-ctrl.sock"
},
"lease-database": {
"type": "postgresql",
"name": "kea",
"user": "keauser",
"password": "xxxxxx",
"host": "localhost",
"port": 5432
},
"hosts-database": {
"readonly": true,
"type": "postgresql",
"name": "kea",
"user": "keauser",
"password": "xxxxxx",
"host": "localhost",
"port": 5432
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 1800,
"rebind-timer": 2880,
"valid-lifetime": 3600,
"mac-sources": ["client-link-addr-option"],
"host-reservation-identifiers": [ "hw-address" ],
"subnet6": [
{
"subnet": "2001:db8:0:24::/64",
"id": 24,
"reservations": [
]
}
]
},
// Logging configuration starts here. Kea uses different loggers to log various
// activities. For details (e.g. names of loggers), see Chapter 18.
"Logging":
{
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea/kea-dhcp6.log",
"maxsize": 26214400,
"maxver": 8
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
```
***hosts-table***
| host_id | dhcp_identifier | dhcp_identifier_type | ... |
| -------- | -------- | -------- | -------- |
| 01 | 0x00163e01c01f | 0 | ... |
| 02 | 0x... | ... | ... |
***ipv6_reservations***
| reservation_id | address | prefix_len | type | dhcp_iaid | host_id |
| -------- | -------- | -------- | -------- | -------- | -------- |
| 01 | 2001:db8:0:24::ff | 128 | 0 | (null) | 01 |
| 02 | ... | ... | ... | ... | ... |
***Remarks***
I can push my short workaround, if you want o have a look at.kea2.5.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/162potential syntax error in keactrl2019-02-25T11:24:55ZAdam Osuchowskipotential syntax error in keactrlThe original description was "typo in documentation", but it covered more than that. The typo is fixed already, so let's focus on the other aspect of fixing potential syntax error in keactrl.
The cleaned up, rebased code is on !241.The original description was "typo in documentation", but it covered more than that. The typo is fixed already, so let's focus on the other aspect of fixing potential syntax error in keactrl.
The cleaned up, rebased code is on !241.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/61errors in kea-admin script and related scripts2018-11-07T09:15:57ZGhost Usererrors in kea-admin script and related scriptsReported via a Kea support customer:
Found annoying error in kea-admin, the $prefix environment variable is set but not exported so it cannot be used by scripts in $prefix/share/kea/scripts/mysql/*.sh.
Also there are errors in $pre...Reported via a Kea support customer:
Found annoying error in kea-admin, the $prefix environment variable is set but not exported so it cannot be used by scripts in $prefix/share/kea/scripts/mysql/*.sh.
Also there are errors in $prefix/share/kea/scripts/admin-utils.sh at lines 25 and 39, where the --host="${db_host}" parameter is missing so the mysql commands are always attempted towards the local database even if -h or --host parameter is used in kea-admin calls.
I suspect the same problems could be in other backends as well but I didn't check them.
He attached his proposed corrections to admin-utils.sh and kea-admin.Kea1.5-beta1Tomek MrugalskiTomek Mrugalski