ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-01-25T14:54:51Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3219Implement RFC9527: Homenet DHCPv6 options2024-01-25T14:54:51ZTomek MrugalskiImplement RFC9527: Homenet DHCPv6 optionsA new set of three DHCPv6 options are being published in [RFC9527](https://www.rfc-editor.org/authors/rfc9527.html). If this link no longer works, it means the RFC is published.
The options' formats are reasonably simple (a 16-bits long...A new set of three DHCPv6 options are being published in [RFC9527](https://www.rfc-editor.org/authors/rfc9527.html). If this link no longer works, it means the RFC is published.
The options' formats are reasonably simple (a 16-bits long bit field + fqdn) and are DHCPv6 only. There's no special processing - normal ORO stuff, although the server will likely keep some values user specific (so will be used mainly as host reservation options).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3218Kea dhcp v4 server ip reservation configuration using uuid-guid (dhcp option ...2024-03-26T13:17:34ZBenoit SansoniKea dhcp v4 server ip reservation configuration using uuid-guid (dhcp option 97; rfc 4578)Hi,
I would like to set a dhcp v4 reservation ip using "uuid-guid" (that correspond to dhcp option 97 / RFC 4578).
This is my current kea server configuration using an hardware address that works fine :
"reservations": [...Hi,
I would like to set a dhcp v4 reservation ip using "uuid-guid" (that correspond to dhcp option 97 / RFC 4578).
This is my current kea server configuration using an hardware address that works fine :
"reservations": [
{
"hostname": "board",
"hw-address": "01:02:03:04:05:06",
"ip-address": "192.168.0.2",
"option-data": [
{
"name": "boot-file-name",
"data": "file.bin"
}
]
},
When I replaced in this configuration the hw-address by "uuid-guid", the "uuid-guid" filed is not expected by kea dhcp server.
In the documentation I can see that the default host reservation identifiers are:
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ]
Is the "uuid-guid" is supported for IP reservation ?
Is it a feature that will be developped in the future ?
If the reservation with "uuid-guid" identifier is supported, What should configuration need to be applied ?
Thanks in advance for your help
Benoitoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3217Neighbor discovery for dhcpv62024-02-19T21:40:42ZVaclav MichalekNeighbor discovery for dhcpv6This is a request to implement IPv6 neighbor discovery mechanism (rfc4861) in DHCPv6 server to obtain MAC hardware addresses.
The method is also suggested in [related issue](https://gitlab.isc.org/isc-projects/kea/-/issues/1729 "Feature...This is a request to implement IPv6 neighbor discovery mechanism (rfc4861) in DHCPv6 server to obtain MAC hardware addresses.
The method is also suggested in [related issue](https://gitlab.isc.org/isc-projects/kea/-/issues/1729 "Feature request: DHCPv6 - use real MAC address from dhcp6 request (mac-sources=raw)").
**Is your feature request related to a problem? Please describe.**
The feature is needed for reliable host-based reservations and identification of DHCPv6 clients.
**Describe the solution you'd like**
Two new mac-source methods (query OS neighbor cache, neighbor discovery) are to be implemented.
```plaintext
"mac-sources": [ "neigh-cache", "neigh-discovery" ]
```
**Describe alternatives you've considered** At this time, there is no practical alternative.
**Funding its development** No funding.
**Participating in development** I am planning to write the code (though with no experience with Kea developement).
**Contacting you** ... E-mail in my profile.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1276github-friendly security policy2024-01-16T14:41:55ZTomek Mrugalskigithub-friendly security policyThis is mostly to check off some extra check boxes on github.
Something similar as we have in Kea: [Kea security policy](https://github.com/isc-projects/kea/security/policy).
This is just writing down what we already have spread out in...This is mostly to check off some extra check boxes on github.
Something similar as we have in Kea: [Kea security policy](https://github.com/isc-projects/kea/security/policy).
This is just writing down what we already have spread out in several places, condensed and formatted in github friendly format. No specific process changes proposed.1.16Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3216Setting YANG list elements with singlequotes in key values is not possible in...2024-01-18T14:58:00ZAndrei Pavelandrei@isc.orgSetting YANG list elements with singlequotes in key values is not possible in our unit testing frameworkOur internal NETCONF test framework in the form of `YangRepr`, particularly the `YangRepr::set` functionality does not support setting list elements that have singlequotes in the value of a key. This is because setting a node is done by ...Our internal NETCONF test framework in the form of `YangRepr`, particularly the `YangRepr::set` functionality does not support setting list elements that have singlequotes in the value of a key. This is because setting a node is done by providing the xpath as a plain string and singlequotes are used to delimit the value of the key, so upon finding a singlequote in the value, the libyang parser thinks the value ends sooner than it actually does and does not know what to do with the rest of the xpath.
This is not a problem in production code, because production code has no need for setting YANG nodes, but instead is only concerned with retrieving them from the sysrepo datastore.
The issue may become more prevalent if issue 3198 gets merged as it was written at the time this issue was created. It makes `data` a key which is more likely to contain a singlequote than other keys, which is also why this issue became obvious there. The issue occurred in unit tests.
```
[ RUN ] ConfigTestKeaV4.examples4
libyang[0]: Invalid character 0x73 ('s'), perhaps "'Error: here'" is supposed to be a function call.
config_unittests.cc:332: Failure
Failed
json = loadFile(path) threw type: N3isc4yang12NetconfErrorE, what: setting item 'nullopt' at '/kea-dhcp4-server:config/option-data[code='56'][space='dhcp4'][data='Error: here's a DHCPNAK!']': Session::setItem: Couldn't set '/kea-dhcp4-server:config/option-data[code='56'][space='dhcp4'][data='Error: here's a DHCPNAK!']': SR_ERR_INVAL_ARG
Google Test trace:
config_unittests.cc:330:
* Tested file: /home/andrei/work/isc/kea-3198-vivso-suboptions-not-properly-supported-in-netconf/doc/examples/kea4/all-options.json
[ FAILED ] ConfigTestKeaV4.examples4 (509 ms)
```
This change was done to avoid it:
```diff
diff --git a/doc/examples/kea4/all-options.json b/doc/examples/kea4/all-options.json
index 5e7d7ccbc7..f52105691b 100644
--- a/doc/examples/kea4/all-options.json
+++ b/doc/examples/kea4/all-options.json
@@ -691,3 +691,3 @@
"code": 56,
- "data": "Error: here's a DHCPNAK!",
+ "data": "Error: here is a DHCPNAK!",
"name": "dhcp-message"
```
One may think of encoding the singlequote as Kea does with the commas in user-context under the lease CSV files. That is not ideal, if even possible, since the singlequote would need to be decoded in get unctionality which means it has an effect on production code, but moreover it might not be compatible with setting outside `YangRepr`, via e.g. sysrepocfg.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/1275Password change fails with character '+' that form states is allowable2024-01-16T14:41:07ZBaxil (aka Horizon)Password change fails with character '+' that form states is allowable
**Description**
Stork will refuse to validate passwords using the plus sign, one of the characters the password change screen explicitly states is an allowed special character.
**To Reproduce**
1. visit /profile/password page for passw...
**Description**
Stork will refuse to validate passwords using the plus sign, one of the characters the password change screen explicitly states is an allowed special character.
**To Reproduce**
1. visit /profile/password page for password change
2. In both password and confirm password boxes type: abc+123
3. Password box will error out with an allowed characters message and confirm box will error out stating passwords don't match
![20240109-stork-passwords](/uploads/76d84e097f9c19cc31850f9bc204c36e/20240109-stork-passwords.png)
**Expected behavior**
Any characters which cause password processing errors should be removed from acceptable character lists.
**Environment:**
- Stork: 1.14.0
- OS: unknown, my apologies (I'm an end user)
- Kea version: unknown
- BIND9 version: unknown
**Additional Information**
This is possibly related to issue #1246 if the db password is processed in the same fashion.1.16https://gitlab.isc.org/isc-projects/stork/-/issues/1274Hub and spoke configuration monitoring2024-03-28T12:21:12ZMarcin SiodelskiHub and spoke configuration monitoringWe have added the hub-and-spoke configuration support in Kea. It means that a HA-enabled server can now have multiple relationships. We need to rework the Stork backend and UI to support it.We have added the hub-and-spoke configuration support in Kea. It means that a HA-enabled server can now have multiple relationships. We need to rework the Stork backend and UI to support it.1.16Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3213Feature request: statistics-get-all-global command to get all of the global s...2024-03-27T12:51:29ZCathy AlmondFeature request: statistics-get-all-global command to get all of the global stats without any of the subnet stats---
name: statistics-get-all-global command
about: `statistics-get-all-global` command (or similar) to get all of the global statistics without any of the subnet statistics
---
It would also be useful to have something like "statistics...---
name: statistics-get-all-global command
about: `statistics-get-all-global` command (or similar) to get all of the global statistics without any of the subnet statistics
---
It would also be useful to have something like "statistics-get-all-global" command to get all of the global stats but not all of the subnet (or pool if they get added) stats. We have scenarios with multiple 100s of subnets and for those "get-all" can get unwieldy.
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0https://gitlab.isc.org/isc-projects/dhcp/-/issues/1020The dhclient cannot parse the IAID successfully,when it is written as string ...2024-01-09T02:44:49ZMingshuai Renrenmingshuai@huawei.comThe dhclient cannot parse the IAID successfully,when it is written as string which contains '"' characterAs we all know, the IAID values in lease is written as quoted strings with the default format.
Generally, the dhclient can successfully parse the IAID value from the IAID string in the lease, but fails to parse the IAID value from the IA...As we all know, the IAID values in lease is written as quoted strings with the default format.
Generally, the dhclient can successfully parse the IAID value from the IAID string in the lease, but fails to parse the IAID value from the IAID string which contains '"'.
The reason is that when the dhclient parses the IAID character string, the character '“' is used as the end of the string.
Modifying the condition for writing the IAID value as a string rather than modifying the code for parsing leases is a better way to solve this problem.
```
diff --git a/common/print.c b/common/print.c
index ebe985d..536e8b4 100644
--- a/common/print.c
+++ b/common/print.c
@@ -427,7 +427,7 @@ void print_hex_or_string (len, data, limit, buf)
return;
for (i = 0; (i < (limit - 3)) && (i < len); i++) {
- if (!isascii(data[i]) || !isprint(data[i])) {
+ if (!isascii(data[i]) || !isprint(data[i]) || (data[i] == '"')) {
print_hex_only(len, data, limit, buf);
return;
}
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4525bind acl doesn't respect interface identifier (in ipv6 link local address)2024-01-09T06:15:55Zelmaimbobind acl doesn't respect interface identifier (in ipv6 link local address)### Summary
Although BIND allows you to configure an IPv6 address with an interface identifier (e.g. fe80::1%ne0) in an "acl" statement, when it tests if an address satisfies the acl, it seems to only look at the address and ignores the...### Summary
Although BIND allows you to configure an IPv6 address with an interface identifier (e.g. fe80::1%ne0) in an "acl" statement, when it tests if an address satisfies the acl, it seems to only look at the address and ignores the interface identifier when performing the check.
### BIND version affected
```
# named -V
BIND 9.18.18-0ubuntu2-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-UHPUkp/bind9-9.18.18=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/bind9-UHPUkp/bind9-9.18.18=/usr/src/bind9-1:9.18.18-0ubuntu2 -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 13.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.55.1
linked to libnghttp2 version: 1.55.1
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.17
linked to json-c version: 0.17
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
These steps require access to two machines, each having an IPv6 link-local address on a shared network segment. One of the machines needs to have an operational installation of BIND. The other machine needs the dig utility, or a similar tool that allows a DNS query to be sent to a specific IPv6 address.
1. On the BIND machine (server A), run `ip -6 address` and verify that the server has a loopback interface (lo) with IPv6 address `::1`, and at least one other network interface that has a link-local address `fe80::xxxx:xxxx:xxxx:xxxx/64`. Make a note of the name of the interface name and the link-local address.
2. On the other machine (server B), run `ip -6 address` and make a note of the interface name that is on the same network as the BIND machine.
3. Verify connectivity between the servers by pinging from server B to the link-local address of server A -- including server B's interface identifier. E.g.: `ping fe80::1e69:7aff:fe6c:2ab0%eno1`
4. On server A, edit the BIND configuration and add `acl testing { fe80::/64; };`, and also include "testing;" at the start of both `allow-query` and `allow-recursion` options. Run `rndc reload` to apply the configuration changes.
5. On server B, verify that you can use dig (or similar) to successfully query a DNS name using the the same link-local address used in the ping test above. E.g.: `dig google.com @fe80::1e69:7aff:fe6c:2ab0%eno1`
6. Now change the "acl testing" block to `acl testing { !fe80::%lo/64; fe80::/64; };`. The idea here is that we are disallowing queries coming from link-local addresses on the loopback interface. In theory this should make no difference to our test, since our query isn't coming in the loopback interface. Run `rndc reload` to apply the configuration changes.
7. Repeat the "dig" test, and you will find that the BIND server will now refuse the request. This shows that BIND considers that the request satisfies "!fe80::%lo/64;" when in fact it shouldn't because it doesn't originate from the loopback interface.
### What is the current *bug* behavior?
BIND seems to ignore the interface identifier for IPv6 addresses when applying acls.
### What is the expected *correct* behavior?
BIND should observe the interface identifier as described in the [documentation](https://bind9.readthedocs.io/en/latest/reference.html#term-ipv6_address). Please note that interface identifiers may also contain VLAN IDs - e.g. "eno1.20".
### Relevant configuration files
FYI I am trying to use ACLs similar to the following, to differentiate between requests originating on link-local addresses from different interfaces, so that the queries are handled by different views:
```
acl trusted-networks {
127.0.0.0/8;
::1;
fe80::%eno1.20/64;
fe80::%eno1.160/64;
fe80::%tun1/64;
};
acl dmz-networks {
fe80::%eno1.192/64;
};
```
### Relevant logs
All my logs show is that the wrong view is being used, due to this bug.Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/3206subnet-get commands should fetch leases for selected subnets with pagination2024-03-22T13:15:53ZMarcin Siodelskisubnet-get commands should fetch leases for selected subnets with paginationIn HA, we use lease commands to synchronize the database. The lease commands fetch all leases with pagination. However, in the hub-and-spoke model it would be useful to fetch the leases only for selected subnets because the relationships...In HA, we use lease commands to synchronize the database. The lease commands fetch all leases with pagination. However, in the hub-and-spoke model it would be useful to fetch the leases only for selected subnets because the relationships are partitioned by subnet. Today, all leases have to be fetched by each relationship and those that do not belong to the relationship are discarded. This is inefficient. One thing to consider is that subnet identifiers are listed explicitly in the commands.next-stable-3.0https://gitlab.isc.org/isc-projects/bind9/-/issues/4523dnstap support for new transport protocols2024-03-08T09:03:02ZPeter Daviesdnstap support for new transport protocols### Description
Feature Request: dnstap support for new transport protocols
### Request
Currently, BIND's dnstap implementation distinguishes between UDP and TCP based
dns traffic.
With BIND's support for DNS over TLS ...### Description
Feature Request: dnstap support for new transport protocols
### Request
Currently, BIND's dnstap implementation distinguishes between UDP and TCP based
dns traffic.
With BIND's support for DNS over TLS and DNS over HTTPS, users may wish to
differentiate between these transports in dnstap output.
### Links / references
The current dnstap protobuf lists support for DoT, DoH:
see https://github.com/dnstap/dnstap.pb/blob/master/dnstap.protoAydın MercanAydın Mercanhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/60Some tweeks to "Define Subnets"2024-01-03T21:40:20ZDarren AnkneySome tweeks to "Define Subnets"- Move the + to "Pool" from "client-class" line. I had previously moved it because client-class is part of pool. I find it confusing now, so I should move it back.
- Rename "client-class" to "Pool client-class" if it will fit somehow (...- Move the + to "Pool" from "client-class" line. I had previously moved it because client-class is part of pool. I find it confusing now, so I should move it back.
- Rename "client-class" to "Pool client-class" if it will fit somehow (I hope).0.3https://gitlab.isc.org/isc-projects/bind9/-/issues/4517dnssec-verify reports errors in NSEC3 chain2024-02-24T07:53:57ZLibor Peltandnssec-verify reports errors in NSEC3 chain### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the f...### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Bad NSEC3 record for fadb1aa3f.6DA7ffbF, bit map mismatch
Expected and found NSEC3 chains not equal
Break in NSEC3 chain at: VKGD3TE5QRGB6S0KJH6UV3FKS9FUMRIV
Expected: 01EAMK8ES71TN6TKHOK512LQMCORC5O9
Found: 0R6S95GSLHH7HT7MFN2N1NJGNFS7Q2CQ
DNSSEC completeness test failed (failure).
```
I'd say that the NSEC3 chain is however correct.
Some notes:
- opt-out is not used
- `fadb1aa3f.6da7ffbf.` -> `01eamk8es71tn6tkhok512lqmcorc5o9.6da7ffbf.` (first NSEC3 lexicographically, but this probably doesnt care)
- `427e09.owa.6da7ffbf.` -> `vkgd3te5qrgb6s0kjh6uv3fks9fumriv.6da7ffbf.` (last NSEC3 lexicographically)
- node `fadb1aa3f.6da7ffbf.` is "weird" in the way that it's a delegation with non-authoritative data: MX and even DNSKEY(!), but this shouldn't influence the chaining of NSEC3, moreover, it relates to the bitmap at 01EAMK... and not VKGD3T...
### BIND version affected
```
$ dnssec-verify -V
dnssec-verify 9.18.18-0ubuntu0.22.04.1-Ubuntu
```
### Steps to reproduce
Use faketime as the RRSIGs are expired already. It doesn't matter since the errors are related to NSEC3s and not signatures.
The zone file in question is attached.
Just call `$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone`
### What is the current *bug* behavior?
Verify reports errors in the attached zone's NSEC3 chain.
### What is the expected *correct* behavior?
No errors reported.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/3203DHCPINFORM is only logged on DEBUG level2024-03-27T13:50:18ZBernhard SchmidtDHCPINFORM is only logged on DEBUG level**Describe the bug**
I'm currently working on a project to migrate a Windows DHCP server environment to Kea. Right now both are active and I'm looking at logs and tcpdump captures while fiddling with the config.
I got confused because ...**Describe the bug**
I'm currently working on a project to migrate a Windows DHCP server environment to Kea. Right now both are active and I'm looking at logs and tcpdump captures while fiddling with the config.
I got confused because there were DHCPACK messages originated by the Kea server while there was not a single log entry visible. Increasing the logging verbosity to DEBUG shows a large number of messages, all with severity DEBUG.
Kea should not interact with clients over the network without logging.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with a logging config like https://gitlab.isc.org/isc-projects/kea/-/blob/master/doc/examples/kea4/single-subnet.json?ref_type=heads
2. have a client send DHCPINFORM while running tcpdump
3. observe a DHCPACK being generated in tcpdump with Kea not logging a single line
**Expected behavior**
At least one line should be logged on INFO level when Kea is receiving and answering a DHCPINFORM request.
**Environment:**
- Kea version: 2.4.1
- OS: Debian Bookworm
**Additional Information**
```
2024-01-02 20:14:36.523 DEBUG [kea-dhcp4.packets/1.140376903606784] DHCP4_BUFFER_RECEIVED received buffer from 10.1.0.142:68 to 255.255.255.255:67 over interface ens19
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS No RAI options found to use for subnet selection.
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS Relay address (giaddr) in client packet is empty.
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_BY_INTERFACE_NO_MATCH No subnet matches interface: ens19
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.1.0.0/16 for packet received by matching address 10.1.4.1
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.packets/1.140376869664512] DHCP4_SUBNET_SELECTED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: the subnet with ID 10001000 was selected for client assignments
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.packets/1.140376869664512] DHCP4_PACKET_RECEIVED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: DHCPINFORM (type 8) received from 10.1.0.142 to 255.255.255.255 on interface ens19
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS No RAI options found to use for subnet selection.
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS Relay address (giaddr) in client packet is empty.
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_SUBNET4_SELECT_BY_INTERFACE_NO_MATCH No subnet matches interface: ens19
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcpsrv/1.140376869664512] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.1.0.0/16 for packet received by matching address 10.1.4.1
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.packets/1.140376869664512] DHCP4_SUBNET_SELECTED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: the subnet with ID 10001000 was selected for client assignments
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 0, identified by hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=EEBD63C37393, found 1 host(s)
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 0 and identifier hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 0, identified by client-id=01EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01EEBD63C37393, found 0 host(s)
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 0 and identifier client-id=01EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 10001000, identified by hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=EEBD63C37393
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=EEBD63C37393, found 1 host(s)
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.hosts/1.140376869664512] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST using subnet id 10001000 and identifier hwaddr=EEBD63C37393, found host: hwaddr=EEBD63C37393 ipv4_subnet_id=10001000 hostname=(empty) ipv4_reservation=10.1.0.142 siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none)
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcp4/1.140376869664512] DHCP4_CLASS_ASSIGNED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: client packet has been assigned to the following class(es): KNOWN
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.dhcp4/1.140376869664512] DHCP4_CLASS_ASSIGNED [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_MSFT 5.0, KNOWN
dhcp4_1 | 2024-01-02 20:14:36.524 DEBUG [kea-dhcp4.packets/1.140376869664512] DHCP4_PACKET_SEND [hwtype=1 ee:bd:63:c3:73:93], cid=[01:ee:bd:63:c3:73:93], tid=0xfe6e0c6f: trying to send packet DHCPACK (type 5) from 10.1.4.1:67 to 10.1.0.142:68 on interface ens19
```kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3202Mismatch in Kea DHCP Subnet Configuration: Unexpected Vendor Class Returned2024-01-25T14:52:06ZSandeep GagalapallyMismatch in Kea DHCP Subnet Configuration: Unexpected Vendor Class ReturnedWhen I create a subnet in Kea DHCP Database with client class as Vendor_C for the subnet 10.x.x.65/28. It should return the
Vendor_C class but I see data of Vendor_N returned everytime.
In other words I am expecting the DHCP server to ...When I create a subnet in Kea DHCP Database with client class as Vendor_C for the subnet 10.x.x.65/28. It should return the
Vendor_C class but I see data of Vendor_N returned everytime.
In other words I am expecting the DHCP server to return data sftp://ftp-server:password@ip_address/configs/Vendor_ztp_cen.xml
to the DHCP client but it is returning sftp://ftp-server:password@ip_address/configs/Vendor_ztp_ned.xml which is defined under Vendor_N.
## My Client classes Configuration defined on the DHCP server.
"client-classes": [
{
"name": "Vendor_N",
"test": "substring(option[60].hex,0,9) == 'Vendor'",
"option-data": [
{
"name": "boot-file-name",
"data": "sftp://ftp-server:password@ip_address/configs/Vendor_ztp_ned.xml"
},
{
"name": "domain-name-servers",
"data": "x.x.x.x,x.x.x.x"
}
]
},
{
"name": "Vendor_C",
"test": "substring(option[60].hex,0,9) == 'Vendor'",
"option-data": [
{
"name": "boot-file-name",
"data": "sftp://ftp-server:password@ip_address/configs/Vendor_ztp_cen.xml"
},
{
"name": "domain-name-servers",
"data": "x.x.x.x,x.x.x.x"
}
]
},
{
"name": "Vendor_W",
"test": "substring(option[60].hex,0,9) == 'Vendor'",
"option-data": [
{
"name": "boot-file-name",
"data": "sftp://ftp-server-pnp:password@ip_address/configs/Vendor_ztp_wst.xml"
},
{
"name": "domain-name-servers",
"data": "x.x.x.x,x.x.x.x"
}
]
}
]
## My Payload when adding a subnet##
{
"command": "remote-subnet4-set",
"service": ["dhcp4"],
"arguments": {
"subnets": [
{
"id": 12345,
"subnet": 10.x.x.65/28,
"shared-network-name": "",
"pools": [
{
"pool": "10.x.x.67- 10.x.x.79",
"require-client-classes": ["Vendor_C"]
} for pool in pools
],
"option-data": [
{
"name": "routers",
"data": 10.x.x.65
}
]
}
],
"remote": {
"type": "mysql"
},
"server-tags": ["all"]
}
}
# DHCP4 log messages
```
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string 'Vendor'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_EQUAL Popping 0x44726976654E657473 and 0x44726976654E657473 pushing result 'true'
2024-01-02 10:58:30.387 INFO [kea-dhcp4.dhcpsrv/4457.140027448874752] EVAL_RESULT Expression Vendor_N evaluated to 1
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_OPTION Pushing option 60 with value 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '0'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '9'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_SUBSTRING Popping length 9, start 0, string 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137 pushing result 0x44726976654E657473
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string 'Vendor'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_EQUAL Popping 0x44726976654E657473 and 0x44726976654E657473 pushing result 'true'
2024-01-02 10:58:30.387 INFO [kea-dhcp4.dhcpsrv/4457.140027448874752] EVAL_RESULT Expression Vendor_C evaluated to 1
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_OPTION Pushing option 60 with value 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '0'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '9'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_SUBSTRING Popping length 9, start 0, string 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137 pushing result 0x44726976654E657473
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string 'Vendor'
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_EQUAL Popping 0x44726976654E657473 and 0x44726976654E657473 pushing result 'true'
2024-01-02 10:58:30.387 INFO [kea-dhcp4.dhcpsrv/4457.140027448874752] EVAL_RESULT Expression Vendor_W evaluated to 1
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.packets/4457.140027448874752] DHCP4_PACKET_RECEIVED [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: DHCPREQUEST (type 3) received from 10.x.x.37 to 100.91.x.x on interface ens160
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.packets/4457.140027448874752] DHCP4_QUERY_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5, packet details: local_address=100.x.x.226:67, remote_address=10.x.x.37:68, msg_type=DHCPREQUEST (3), transid=0x758adfb5,
options:
type=012, len=015: "WKY1C7VH0001AP2" (string)
type=053, len=001: 3 (uint8)
type=055, len=015: 1(uint8) 121(uint8) 3(uint8) 6(uint8) 12(uint8) 15(uint8) 28(uint8) 33(uint8) 51(uint8) 54(uint8) 58(uint8) 59(uint8) 66(uint8) 67(uint8) 119(uint8)
type=057, len=002: 8972 (uint16)
type=060, len=041: "Vendor-Ufi_Space_S9710-76D-R-18.2.0.17" (string)
type=061, len=020: 00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32
type=124, len=21, enterprise id=0xc24b, data-len0=16, vendor-class-data0='Vendor-BaseOS'
type=145, len=001: 01
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS No RAI options found to use for subnet selection.
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS Relay address (giaddr) in client packet is empty.
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.28.16.33/28 for packet received by matching address 10.x.x.37
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.packets/4457.140027448874752] DHCP4_SUBNET_SELECTED [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: the subnet with ID 2406630306 was selected for client assignments
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.packets/4457.140027448874752] DHCP4_SUBNET_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: the selected subnet details: 10.28.16.33/28
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 2406630306, identified by hwaddr=8440761A7A39
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=8440761A7A39
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=8440761A7A39, found 0 host(s)
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 2406630306 and identifier hwaddr=8440761A7A39
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 2406630306, identified by client-id=006E63632D574B59314337564830303031415032
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=006E63632D574B59314337564830303031415032
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=006E63632D574B59314337564830303031415032, found 0 host(s)
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 2406630306 and identifier client-id=006E63632D574B59314337564830303031415032
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcp4/4457.140027448874752] DHCP4_CLASS_ASSIGNED [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: client packet has been assigned to the following class(es): UNKNOWN
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcp4/4457.140027448874752] DHCP4_CLASS_ASSIGNED [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: client packet has been assigned to the following class(es): ALL, HA_prod-kea-1, VENDOR_CLASS_Vendor-Ufi_Space_S9710-76D-R-18.2.0.17, Vendor_N, Vendor_C, Vendor_W, UNKNOWN
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.ddns/4457.140027448874752] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: processing client's Hostname option
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.ddns/4457.140027448874752] DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: client sent Hostname option: WKY1C7VH0001AP2
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.ddns/4457.140027448874752] DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: client sent Hostname option: WKY1C7VH0001AP2
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.ddns/4457.140027448874752] DHCP4_RESPONSE_HOSTNAME_DATA [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: including Hostname option in the server's response: wky1c7vh0001ap2
2024-01-02 10:58:30.387 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_MYSQL_GET_CLIENTID obtaining IPv4 leases for client ID 00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 2406630306 and IPv4 address 10.x.x.37
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.x.x.37
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.x.x.37, found 0 host(s)
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.hosts/4457.140027448874752] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 2406630306 and address 10.x.x.37
2024-01-02 10:58:30.461 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 10.x.x.37
2024-01-02 10:58:30.535 DEBUG [kea-dhcp4.alloc-engine/4457.140027448874752] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: extending lifetime of the lease for address 10.x.x.37
2024-01-02 10:58:30.535 DEBUG [kea-dhcp4.dhcpsrv/4457.140027448874752] DHCPSRV_MYSQL_UPDATE_ADDR4 updating IPv4 lease for address 10.x.x.37
2024-01-02 10:58:30.611 INFO [kea-dhcp4.leases/4457.140027448874752] DHCP4_LEASE_ALLOC [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: lease 10.x.x.37 has been allocated for 43200 seconds
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_OPTION Pushing option 60 with value 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '0'
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string '9'
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_SUBSTRING Popping length 9, start 0, string 0x44726976654E6574732D5566695F53706163655F53393731302D3736442D522D31382E322E302E3137 pushing result 0x44726976654E657473
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_STRING Pushing text string 'Vendor'
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.eval/4457.140027448874752] EVAL_DEBUG_EQUAL Popping 0x44726976654E657473 and 0x44726976654E657473 pushing result 'true'
2024-01-02 10:58:30.611 INFO [kea-dhcp4.dhcp4/4457.140027448874752] EVAL_RESULT Expression Vendor_C evaluated to 1
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.callouts/4457.140027448874752] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.callouts/4457.140027448874752] HOOKS_CALLOUT_CALLED hooks library with index 8 has called a callout on hook leases4_committed that has address 0x7f5ab16500f0 (callout duration: 0.034 ms)
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.callouts/4457.140027448874752] HOOKS_CALLOUTS_COMPLETE completed callouts for hook leases4_committed (total callouts duration: 0.034 ms)
2024-01-02 10:58:30.611 DEBUG [kea-dhcp4.options/4457.140027448874752] DHCP4_PACKET_PACK [hwtype=1 84:40:76:1a:7a:39], cid=[00:6e:63:63:2d:57:4b:59:31:43:37:56:48:30:30:30:31:41:50:32], tid=0x758adfb5: preparing on-wire format of the packet to be sent
2024-01-02 10:55:29.629 DEBUG [kea-dhcp4.packets/4457.140027482445568] DHCP4_RESPONSE_DATA [hwtype=1 84:c4:21:1e:c0:fc], cid=[00:63:6c:75:73:74:65:72:2d:57:4b:59:31:43:38:56:4e:30:30:30:31:38:50:32:5f:77:61], tid=0x2252e631: responding with packet DHCPACK (type 5), packet details: local_address=100.91.x.x:67, remote_address=10.28.x.x:68, msg_type=DHCPACK (5), transid=0x2252e631,
options:
type=001, len=004: 4294967280 (uint32)
type=003, len=004: 10.x.x.33
type=006, len=008: x.x.x.x x.x.x.x
type=051, len=004: 43200 (uint32)
type=053, len=001: 5 (uint8)
type=054, len=004: 100.x.x.x
type=058, len=004: 21600 (uint32)
type=059, len=004: 32400 (uint32)
type=061, len=027: 00:63:6c:75:73:74:65:72:2d:57:4b:59:31:43:38:56:4e:30:30:30:31:38:50:32:5f:77:61
type=067, len=075: "sftp://ftp-server:password@ip_address/configs/vendor_ztp_ned.xml" (string)
```
Thanks,
Sandeepoutstandinghttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/59remove debug output before 0.3 release2024-01-02T15:56:26ZDarren Ankneyremove debug output before 0.3 releaseremove these debug messages of the `_GET` and `_POST` content
```
Tue Jan 2 10:02:03 2024] [::1]:57852 [200]: POST /?validate=true&form=ReservationSetupForm
[Tue Jan 2 10:02:03 2024] [::1]:57852 Closing
[Tue Jan 2 10:36:33 2024] [::1]...remove these debug messages of the `_GET` and `_POST` content
```
Tue Jan 2 10:02:03 2024] [::1]:57852 [200]: POST /?validate=true&form=ReservationSetupForm
[Tue Jan 2 10:02:03 2024] [::1]:57852 Closing
[Tue Jan 2 10:36:33 2024] [::1]:58130 Accepted
_GET:
Array
(
[validate] => true
[form] => SharedNetworkSetupForm
)
_POST:
Array
(
[ConfType] => dhcp4
)
[Tue Jan 2 10:36:33 2024] [::1]:58130 [200]: POST /?validate=true&form=SharedNetworkSetupForm
[Tue Jan 2 10:36:33 2024] [::1]:58130 Closing
[Tue Jan 2 10:36:34 2024] [::1]:58131 Accepted
_GET:
Array
(
[validate] => true
[form] => SubnetSetupForm
)
_POST:
Array
(
[ConfType] => dhcp4
)
[Tue Jan 2 10:36:34 2024] [::1]:58131 [200]: POST /?validate=true&form=SubnetSetupForm
[Tue Jan 2 10:36:34 2024] [::1]:58131 Closing
[Tue Jan 2 10:36:35 2024] [::1]:58132 Accepted
_GET:
Array
(
[validate] => true
[form] => LoggerSetupForm
)
_POST:
Array
(
[ConfType] => dhcp4
)
[Tue Jan 2 10:36:35 2024] [::1]:58132 [200]: POST /?validate=true&form=LoggerSetupForm
[Tue Jan 2 10:36:35 2024] [::1]:58132 Closing
[Tue Jan 2 10:36:38 2024] [::1]:58133 Accepted
[Tue Jan 2 10:36:38 2024] [::1]:58133 [200]: POST /?SHOWCONF=true
[Tue Jan 2 10:36:38 2024] [::1]:58133 Closing
```0.3https://gitlab.isc.org/isc-projects/kea/-/issues/3201Allow static leases by hostname like in the old ISC dhcpd2024-01-18T14:52:27ZLuigi BaldoniAllow static leases by hostname like in the old ISC dhcpd---
name: Allow reservations by hostname
about: Allow creating reservations by hostname like in the old ISC dhcp server
---
**Describe the solution you'd like**
In the old ISC dhcpd one could add entries like:
```
host myhost {
hard...---
name: Allow reservations by hostname
about: Allow creating reservations by hostname like in the old ISC dhcp server
---
**Describe the solution you'd like**
In the old ISC dhcpd one could add entries like:
```
host myhost {
hardware ethernet 08:00:aa:bb:cc:dd;
fixed-address myhost;
}
```
Kea allows this:
```
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"ip-address": "192.0.2.10"
}
]
```
Would it be possible to implement this feature in Kea so to have something like:
```
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"hostname-address": "myhost"
}
]
```
?
**Describe alternatives you've considered**
I am aware of the possibility of using ddns and RFC2136 to supply data to a domain name server.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3200Kea unable to remove pid file on exit when installed via rpm2024-03-28T12:35:45ZWlodzimierz WencelKea unable to remove pid file on exit when installed via rpmjournal:
```
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO HOSTS_BACKENDS_REGISTERED the following host backend ...journal:
```
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCP6_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always perfo>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: 2001:db8:1::/64 with params: t1=1000, >
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea6-ctrl-socket
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_CONFIG_COMPLETE DHCPv6 server has completed configuration: added IPv6 subnets: 1; DDNS: disabled
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600 type=memfile universe=6
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases6.csv
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_BUILD_EXTENDED_INFO_TABLES6 building extended info tables saw 0 leases, extended info sanity ch>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_USING_SERVERID server is using server-id 00:01:00:01:2d:21:94:f1:0e:90:95:e1:82:d1 and stores in the file>
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_NA leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_TA leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for IA_PD leases in subnet 2001:db8:1::/64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: WARN DHCP6_MULTI_THREADING_INFO enabled: yes, number of threads: 4, queue size: 64
Dec 29 14:32:17 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_STARTED Kea DHCPv6 server version 2.5.5 started
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal systemd[1]: Stopping kea-dhcp6.service - Kea DHCPv6 Service...
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: INFO DHCP6_SHUTDOWN server shutdown
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: terminate called after throwing an instance of 'isc::util::PIDFileError'
Dec 29 14:34:21 ip-10-10-0-170.ec2.internal kea-dhcp6[2900]: what(): Unable to delete PID file '/run/kea/kea-dhcp6.kea-dhcp6.pid'
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=dumped, status=6/ABRT
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'core-dump'.
Dec 29 14:34:22 ip-10-10-0-170.ec2.internal systemd[1]: Stopped kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12118]: kea-dhcp6.service: Failed to set up special execution directory in /run: Permission denied
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12118]: kea-dhcp6.service: Failed at step RUNTIME_DIRECTORY spawning /usr/sbin/kea-dhcp6: Permission denied
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=exited, status=233/RUNTIME_DIRECTORY
Dec 29 14:34:54 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'exit-code'.
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: Started kea-dhcp6.service - Kea DHCPv6 Service.
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12857]: kea-dhcp6.service: Failed to set up special execution directory in /run: Permission denied
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal (ea-dhcp6)[12857]: kea-dhcp6.service: Failed at step RUNTIME_DIRECTORY spawning /usr/sbin/kea-dhcp6: Permission denied
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Main process exited, code=exited, status=233/RUNTIME_DIRECTORY
Dec 29 14:37:43 ip-10-10-0-170.ec2.internal systemd[1]: kea-dhcp6.service: Failed with result 'exit-code'.
```
probably packaging issue but it's up for investigation.kea2.6.0https://gitlab.isc.org/isc-projects/bind9/-/issues/4505Implement kTLS support in BIND2024-02-14T17:13:53ZArtem BoldarievImplement kTLS support in BIND
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user sp...
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user space, including offloading TLS encryption to the NICs that support that (e.g. [NVIDIA Mellanox ConnectX-6 Dx](https://www.nvidia.com/en-us/networking/ethernet/connectx-6-dx/)), almost completely freeing the CPU from this task, because even in the case of hardware acceleration of encryption within the CPU, it still requires some cycles from it. Also, using it might reduce memory copying in some cases.
Of course, kernel space encryption is more limited compared to the one provided by OpenSSL and its derivatives in the user space: these limitations are imposed by hardware - e.g. NICs might not support anything but AES 128 (aka `TLS_AES_128_GCM_SHA256`), as it is the only cipher mandatory for TLS v1.3). If it is good enough for WEB servers, it should be good enough for DNS, too.
Even when kTLS is used, the handshake itself happens in the user space (e.g. using OpenSSL) with negotiated parameters passed to the kernel using `setsockopt()` calls on a TCP socket descriptor.
OpenSSL provides support for kTLS encryption natively since version 3.X (see `SSL_OP_ENABLE_KTLS` [option](https://www.openssl.org/docs/manmaster/man3/SSL_set_options.html)) but, as far as I understand it, it does so only when OpenSSL manages the underlying TCP socket file descriptor natively: not our case, as we are using LibUV for that. However, considering that the idea of kTLS is that with it enabled, we are supposed to pass unencrypted data to `send()` and `recv()`, that is kTLS-enabled socket from the higher level perspective works (mostly) as a TCP socket, we might try the following approach to implement kTLS, that *might* work:
1. We use our existing code (`tlsstream.c`) to handle handshake, just like we do now;
2. After completing the handshake, we pass the negotiated information to the kernel. OpenSSL might have some interfaces for that. In the worst case, we might need to do that by hand using. `setsockopt()`;
3. Then, we add new code paths to `tlsstream.c` to bypass TLS connection objects (`isc_tls_t`) and use the underlying TCP connection directly, which, by now, works in "kTLS-mode", providing transparent TLS encryption;
4. Control messages, like TLS shutdown, will require additional care.
That is how I see the initial plan that might or might not work. There can (and, likely, will) be unforeseen obstacles that might turn out to overcomplicate the code base so much that it might make it unfeasible to implement, like adding a kTLS-only transport. Furthermore, that might require some assistance from LibUV. That will require some trial and error.
That is mostly written with Linux in mind. If the kTLS interface in FreeBSD is similar enough (it seems so at the first glance), we should support both platforms.
The issue is created mostly to dump the information from my mind and keep kTLS under our radar: we might want to do that, as at least `dnsdist` has experimental support for it. It will be even more important in the future, as it seems now that encrypted DNS transport will be even more important to the point of replacing the good ol' Do53 at some point.
For sure, it is not a 9.20 material - rather 9.21-9.22 if we are lucky, as it is a big feature. Also, I foresee a similar concept eventually appearing for QUIC, too (kQUIC?). Also, I am aquiet certain that we *will* need #3504 for this (implemented here: !8576).
See also:
1. https://docs.kernel.org/networking/tls.html
2. https://man.freebsd.org/cgi/man.cgi?query=ktls&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html
3. https://delthas.fr/blog/2023/kernel-tls/ - mostly discusses it in the context of HTTP and `sendfile()` acceleration, but contains many references on the topic.
4. https://docs.nvidia.com/networking/display/ofedv512580/kernel+transport+layer+security+(ktls)+offloadsLong-termArtem BoldarievArtem Boldariev