Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2018-11-07T09:15:57Zhttps://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 Mrugalskihttps://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/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/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/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/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/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/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/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/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/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/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 Markwalder