Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-02-01T14:54:13Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3232Include JSONs from doc/examples in the ARM2024-02-01T14:54:13ZAndrei Pavelandrei@isc.orgInclude JSONs from doc/examples in the ARMThe configurations in `doc/examples` are mainly aimed at helping administrators, yet they are not included in the ARM with the exception of a few complex HA examples.
Some of the configurations are mentioned through path without linking...The configurations in `doc/examples` are mainly aimed at helping administrators, yet they are not included in the ARM with the exception of a few complex HA examples.
Some of the configurations are mentioned through path without linking anywhere. Furthermore, the path matches the location in the Kea sources, but not in the Kea installation. An administrator would have to git-clone to find them.
I suggest adding a section to the ARM which includes all of them. This would be done programmatically as opposed to hardcoding each file. Ideally, the directory hierarchy would also be respected and displayed in the ARM section.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3228Add monitoring instrumentation around `dhcp-disable` state.2024-02-01T14:49:57ZTomek MrugalskiAdd monitoring instrumentation around `dhcp-disable` state.For details, see [github PR#133](https://github.com/isc-projects/kea/pull/133).For details, see [github PR#133](https://github.com/isc-projects/kea/pull/133).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3226HA lease updates do not create an accounting entry in v62024-01-25T15:00:10ZAndrei Pavelandrei@isc.orgHA lease updates do not create an accounting entry in v6In v6, HA lease updates are done with the `lease6-bulk-apply` command which is not handled in the `command_processed` RADIUS callout.
This is unlike v4 which does create accounting entries for HA lease updates sent via `lease4-update`.In v6, HA lease updates are done with the `lease6-bulk-apply` command which is not handled in the `command_processed` RADIUS callout.
This is unlike v4 which does create accounting entries for HA lease updates sent via `lease4-update`.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3223kea v4 returns status-get 0 when not connected to database2024-02-21T09:17:05ZMarcin Godzinakea v4 returns status-get 0 when not connected to databaseDuring the missing lease database connection process, we send 'status-'get' to Kea.
Kea v6 returns:
```
{
"result": 1,
"text": "Error during command processing: no current lease manager is available"
}
```
Kea v4 returns norm...During the missing lease database connection process, we send 'status-'get' to Kea.
Kea v6 returns:
```
{
"result": 1,
"text": "Error during command processing: no current lease manager is available"
}
```
Kea v4 returns normal status:
```
{
"arguments": {
"multi-threading-enabled": true,
(...)
"uptime": 4
},
"result": 0
}
```
Getting result 0 on kea4 is misleading when there is no database connection.
**These features should be included in tests `tests/dhcp/test_database.py::test_db_retry*`. Please inform QA about the merging solution for this issue.**next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3221Minor doc update: server limitations update after ping-check2024-03-20T11:29:29ZTomek MrugalskiMinor doc update: server limitations update after ping-checkThe section 8.12 (DHCPv4 server limitations) still claims this:
> _The DHCPv4 server does not verify that an assigned address is unused. According to RFC 2131, the allocating server should verify that an address is not used by sending a...The section 8.12 (DHCPv4 server limitations) still claims this:
> _The DHCPv4 server does not verify that an assigned address is unused. According to RFC 2131, the allocating server should verify that an address is not used by sending an ICMP echo request._
This is no longer true after ping-check was implemented.kea2.6.0https://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/3194fix UTs when Kea is configured with botan without TLS2024-02-23T18:26:02ZRazvan Becheriufix UTs when Kea is configured with botan without TLSnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3188Support hot plugging network interfaces2024-02-01T10:52:48ZJakub OkońskiSupport hot plugging network interfaces---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` i...---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` is not present when Kea starts.
I want to be able to declare subnets & definitions for a USB adapter that I sometimes hotplug to the gateway. Without support from Kea, I'd need to keep two different configs and reload Kea at appropriate times. I assume it's also going to fail when a network interface it's listening on disappears.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3176Kea disables logging if configured without an `output-options`2023-11-30T14:32:43ZAndrei Pavelandrei@isc.orgKea disables logging if configured without an `output-options`To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dh...To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
}
```
Or set the same configuration through unix socket or kea-ctrl-agent (maybe while still preserving the control-socket, that's why it's there):
```json
{
"arguments": {
"Dhcp6": {
"control-socket": {
"socket-name": "/tmp/kea-dhcp6-ctrl.sock",
"socket-type": "unix"
},
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
},
"command": "config-set",
"service": [
"dhcp6"
]
}
```
You get this and no more logging after that.
```
log4cplus:ERROR No appenders could be found for logger (kea-dhcp6.hosts).
log4cplus:ERROR Please initialize the log4cplus system properly.
```
This contradicts the ARM which says:
> Each logger can have zero or more `output-options`.
It replicates with subloggers too. Only the sublogger is affected in that case.
You can have `interfaces-config` and `subnet6` and anything else besides it.
DHCP traffic works. Commands work. Logging does not.
It also replicates on `kea-dhcp4`.
There is the workaround of reconfiguring with `output-options`. Logging recovers after that.
Also found a typo in the ARM: `output_commands` should be `output-options`.
Suggested actions:
* [ ] Make logging work when `output-options` is not configured with the documented default of `stdout` as output option.
* [ ] Fix the typo in the ARM: `output_commands` should be `output-options`.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3170Feature request: Add regex classification expression2023-11-30T14:29:47ZottoreiFeature request: Add regex classification expressionIt would be a huge improvement for client classification to have the possibility of using regular expressions. That way even more complex inputs could be handled with ease.It would be a huge improvement for client classification to have the possibility of using regular expressions. That way even more complex inputs could be handled with ease.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3167BLQ: query-by-link-address and shared networks2024-03-21T13:20:14ZTomek MrugalskiBLQ: query-by-link-address and shared networksThis is a continuation of #3149. It was brought to our attention that the `QUERY_BY_LINK_ADDRESS` does not return PD leases properly in some circumstances. The algorithm we came up with is as follows:
Proposed algorithm for QUERY_BY_LIN...This is a continuation of #3149. It was brought to our attention that the `QUERY_BY_LINK_ADDRESS` does not return PD leases properly in some circumstances. The algorithm we came up with is as follows:
Proposed algorithm for QUERY_BY_LINK_ADDRESS:
1. select subnet for specified address, pick its subnet-id
2. (if shared network is used, select all subnet-ids for all subnets in the shared network) - this behavior should be configurable (extra parameter that governs if this step should be done or not).
3. return all leases (NA, PD) with the matching subnet-id
Steps 1 and 3 are to be implemented in #3149. This ticket is about extending the code with shared network scenario. Once implemented, it should be configurable if the leases from shared network should be returned or not. The parameter could be global.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3162Kea does not look at all IP addresses on an interface when attempting to matc...2023-11-23T14:57:47Zmpratik-aristaKea does not look at all IP addresses on an interface when attempting to match incoming packet with subnetSay that Kea has started a DHCPv4 server instance and the interface (on which Kea is listening) has multiple IP addresses configured on it (say using `sudo ip addr add ADDR/MASK dev IFACE`). Now if Kea receives a packet from a directly c...Say that Kea has started a DHCPv4 server instance and the interface (on which Kea is listening) has multiple IP addresses configured on it (say using `sudo ip addr add ADDR/MASK dev IFACE`). Now if Kea receives a packet from a directly connected client on the interface, the Kea code appears to fetch the first available address on the interface, specifically the code here -> https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/lib/dhcp/iface_mgr.cc#L225. This IP address is then used during subnet selection.
In the example (which is also our setup) below, the interface on which kea is listening is vlan42. The primary IP address configured on the interface is 152.44.134.1/16 (configured earlier) and the secondary IP Address configured on the interface is 169.254.4.3/16 (configured later). I see the following traces ->
```
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.dhcpsrv/23369.139809668667520] DHCPSRV_PRINT_ATTR Attribute: iface.address = 152.44.134.1 (I added this log where I printed the IP address that Kea selected for subnet matching)
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.packets/23369.139809668667520] DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 56:83:3f:7a:76:07], cid=[no info], tid=0xb02e9d17: failed to select subnet for the client
2023-11-09 12:27:39.167 DEBUG [kea-dhcp4.bad-packets/23369.139809668667520] DHCP4_PACKET_DROP_0002 [hwtype=1 56:83:3f:7a:76:07], cid=[no info], tid=0xb02e9d17, from interface vlan42: no suitable subnet configured for a direct client
```
I verified that Kea successfully adds both the primary and secondary IP address in the Netlink::ipaddrs_get function for vlan42. My expectation was that Kea would look at all the IP addresses active on the interface and then check if any subnet configured in the Kea config file matches these IPs
The Kea config only had a subnet associated with the secondary IP 169.254.4.3/16 so understandably the packet could not be matched to any subnet. We want to be able to provide addresses from the subnet 169.254.0.0 to the clients who are sending their Discover packets on vlan42.
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with the attached config and configure an interface with two IP addresses so that Kea is listening on this interface using both these IPs.
2. Let a directly connected client does A send a Discover packet to the interface that Kea listens on
3. The server will not be able to provide an IP back to the client as it will not match a subnet.
4. This same behavior is seen regardless of whether I add the following block of code.
```
"interfaces-config": {
"interfaces": [
"vlan42/169.254.4.3"
]
}
```
Expected behavior:
The client would have obtained IP address 169.254.5.5 (first available IP from the subnet 169.254.0.0/16 as specified in the Kea config file) since the IP address is getting added to the interface's address list.
We used Kea-2.0.0 for this experiment[kea-dhcp4-default.conf.rtf](/uploads/b771e974c2c29aa7357bbc6e4e9de553/kea-dhcp4-default.conf.rtf)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3159ThreadSanitize: SEGSV complain on dhcp4 UT when postgresql isn't running2023-11-23T14:46:57ZThomas MarkwalderThreadSanitize: SEGSV complain on dhcp4 UT when postgresql isn't runningThis ism ore of an inconvenience than anything else but it might be a sign of something else too. When postgresql is compiled in but server is not running, kea-dhcp4 builtin for TSAN, UT throws the following error:
```
[----------] 2 t...This ism ore of an inconvenience than anything else but it might be a sign of something else too. When postgresql is compiled in but server is not running, kea-dhcp4 builtin for TSAN, UT throws the following error:
```
[----------] 2 tests from DORAPgSQLTest
[ RUN ] DORAPgSQLTest.multiStageBoot
wipePgSQLData failed:[export PGPASSWORD=keatest; sh /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/wipe_data.sh 19.0 --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null ]
runPgSQLSchema failed: export PGPASSWORD=keatest; cat < /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/dhcpdb_drop.pgsql | psql --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null
unknown file: Failure
C++ exception with description "runPgSQLSchema failed: export PGPASSWORD=keatest; cat < /home/tmark/labs/build/keadev/open/git.3084/kea/src/share/database/scripts/pgsql/dhcpdb_drop.pgsql | psql --set ON_ERROR_STOP=1 -A -t -h localhost -q -U keatest -d keatest 2>/dev/null " thrown in the test fixture's constructor.
ThreadSanitizer:DEADLYSIGNAL
==71954==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55d4686f55bf bp 0x000000000000 sp 0x7ffd8d3170e0 T71954)
==71954==The signal is caused by a READ memory access.
==71954==Hint: address points to the zero page.
#0 testing::Test::DeleteSelf_() /opt/googletest-release-1.8.0/googletest/include/gtest/gtest.h:453 (dhcp4_unittests+0x7735bf)
#1 void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2402 (dhcp4_unittests+0x781869)
#2 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2438 (dhcp4_unittests+0x781869)
#3 testing::TestInfo::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2661 (dhcp4_unittests+0x76f514)
#4 testing::TestCase::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2774 (dhcp4_unittests+0x76f871)
#5 testing::internal::UnitTestImpl::RunAllTests() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:4649 (dhcp4_unittests+0x76ff25)
#6 bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2402 (dhcp4_unittests+0x781fa9)
#7 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /opt/googletest-release-1.8.0/googletest/src/gtest.cc:2438 (dhcp4_unittests+0x781fa9)
#8 testing::UnitTest::Run() /opt/googletest-release-1.8.0/googletest/src/gtest.cc:4257 (dhcp4_unittests+0x7704a5)
#9 RUN_ALL_TESTS() /opt/googletest-release-1.8.0/googletest/include/gtest/gtest.h:2233 (dhcp4_unittests+0x18f59b)
#10 main /home/tmark/labs/build/keadev/open/git.3084/kea/src/bin/dhcp4/tests/dhcp4_unittests.cc:23 (dhcp4_unittests+0x18f59b)
#11 __libc_start_main ../csu/libc-start.c:308 (libc.so.6+0x24082)
#12 _start <null> (dhcp4_unittests+0x1c66dd)
```
Of course if postgresql is running it's not an issue.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3151Reject RADIUS config with multiple default NAS ports2023-11-23T14:42:38ZAndrei Pavelandrei@isc.orgReject RADIUS config with multiple default NAS portsA default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accor...A default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accordingly.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3144redetect-interfaces command2024-02-08T14:35:31ZTomek Mrugalskiredetect-interfaces commandThe idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is tha...The idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is that Kea could be told that some new interfaces appeared or disappeared (VLAN, PPP, some other tunnel etc.) and Kea should redetect them. For an added bonus, there should be a way to tell Kea to open sockets on those new interfaces. This can be done either by telling Kea to open the on any newly detected interfaces or perhaps return a list of interfaces and have a dedicated call `open-socket` or something similar? Anyway, this would be useful to have a mini-design for.
This problem is not new and there are many requests in this problem space:
- A [nicely described use case in #3040](https://gitlab.isc.org/isc-projects/kea/-/issues/3040#note_414899)
- #1084
- #3062
- possibly couple morenext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3135DHCPv4 V-I Vendor Class option data-len is treated as part of opaque-data string2024-01-25T06:40:06ZErik FlinkDHCPv4 V-I Vendor Class option data-len is treated as part of opaque-data string**Describe the bug**
The [OptionVendorClass](src/lib/dhcp/option_vendor_class.h#L42) encapsulates both DHCPv6 Vendor Class and DHCPv4 V-I Vendor Class options, but for DHCPv4 V-I Vendor Class options the first byte of vendor-class-data...**Describe the bug**
The [OptionVendorClass](src/lib/dhcp/option_vendor_class.h#L42) encapsulates both DHCPv6 Vendor Class and DHCPv4 V-I Vendor Class options, but for DHCPv4 V-I Vendor Class options the first byte of vendor-class-data is treated as part of the opaque-data string even though it is a data-len as specified in [RFC 3925 section 3](https://datatracker.ietf.org/doc/html/rfc3925#section-3).
**Expected behavior**
For both DHCPv6 Vendor Class and DHCPv4 V-I Vendor Class options, the tuple collection should consist of tuples of opaque-data and corresponding length field.
**Actual behavior**
- For DHCPv6 Vendor Class option, the tuple collection consists of tuples of opaque-data and corresponding length as expected.
- For DHCPv4 V-I Vendor Class option, the tuple collection consists of tuples containing vendor-class-data and corresponding length.
**Additional Information**
The actual behavior can been observed by enabling Kea debug logs and observing logs of incoming packets containing DHCPv4 V-I Vendor Class options, or by implementing a Kea hook that inspects the option. It can also be confirmed by comparing implementations of [`OptionVendorClass::pack`](src/lib/dhcp/option_vendor_class.cc#L38) and [`OptionVendorClass::unpack`](src/lib/dhcp/option_vendor_class.cc#L58) functions with RFC specifications.
DHCPv6 Vendor Class option is specified in [RFC 8415 section 21.16](https://datatracker.ietf.org/doc/html/rfc8415#section-21.16)
DHCPv4 V-I Vendor Class option is specified in [RFC 3925 section 3](https://datatracker.ietf.org/doc/html/rfc3925#section-3)
DHCPv6 Vendor Class option contains one or more instances of vendor-class-data corresponding to a single Enterprise Number, while DHCPv4 V-I Vendor Class option contains information corresponding to one or more Enterprise Numbers and one or more corresponding instances of vendor-class-data corresponding to each Enterprise Number. This difference is not handled by Kea, as also mentioned in #2521.
A related bug was recently reported and solved in Wireshark ([DHCPv4 Option 124 parsing is incorrect (#18970) · Issues · Wireshark Foundation / Wireshark · GitLab](https://gitlab.com/wireshark/wireshark/-/issues/18970)). It caused Wireshark to parse DHCPv4 V-I Vendor Class option incorrectly and not flag packets as malformed if the data-len field inside the vendor-class-data field was set incorrectly, such as if the whole vendor-class-data field was treated as opaque-data like Kea does.
**Contact**
erik.flink@ericsson.comnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3134Kea tries to open sockets on wrong interfaces when using "service-sockets-req...2024-02-08T14:34:25ZYannikKea tries to open sockets on wrong interfaces when using "service-sockets-require-all"I am using kea with this `interfaces-config`:
```
"interfaces": ["enp88s0.140"],
"service-sockets-require-all": true,
"service-sockets-max-retries": 100000
```
For some reason, kea tries to open sockets on other interfaces than the spe...I am using kea with this `interfaces-config`:
```
"interfaces": ["enp88s0.140"],
"service-sockets-require-all": true,
"service-sockets-max-retries": 100000
```
For some reason, kea tries to open sockets on other interfaces than the specified `enp88s0.140`. According to the docs, `The “service-sockets-require-all” option makes Kea require all sockets to be successfully bound.`. As far as I understand that, it means that it will retry opening sockets for the specified interfaces until they are successfully bound. However, it does not mean binding sockets for all interfaces (that would make `interfaces` useless).
I noticed this issue because some interfaces on this system do not have ip adresses asssigned, which results in kea logging the following errors over and over:
```
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap0 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap1 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap2 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap3 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap4 has no usable IPv4 addresses configured
Nov 01 10:25:07 nuc kea-dhcp4[1306]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface macvtap5 has no usable IPv4 addresses configured
```
Here is the list of configured interfaces on this host:
```
$ ip link show |grep -v ether
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
3: enp88s0.20@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
4: enp88s0.140@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
5: enp88s0.160@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
6: enp88s0.300@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
7: enp88s0.310@enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
8: macvtap0@enp88s0.20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
9: macvtap1@enp88s0.300: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
10: macvtap2@enp88s0.300: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
11: macvtap3@enp88s0.300: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
12: macvtap4@enp88s0.140: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
13: macvtap5@enp88s0.160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3113Don't seem to be able to skip subnet/lease selection in a hook2024-03-28T08:10:19ZAndrew ForgueDon't seem to be able to skip subnet/lease selection in a hookWhat's the proper way to skip lease/subnet selection and delegate _everything_ to a hook library? I'm trying to hook kea up to a custom IPAM system.
The best I can tell is that you implement `pkt4_receive`/`pkt4_send` and tell `lease4_...What's the proper way to skip lease/subnet selection and delegate _everything_ to a hook library? I'm trying to hook kea up to a custom IPAM system.
The best I can tell is that you implement `pkt4_receive`/`pkt4_send` and tell `lease4_select` and `subnet4_select` as `setStatus(CalloutHandle::NEXT_STEP_SKIP)`.
The hook documentation for lease4_select says:
> Next step status: If any callout installed on the "lease4_select" hook sets the next step action to SKIP, the server will not assign any lease and the callouts become responsible for the lease assignment. If the callouts fail to provide a lease, the packet processing will continue, but client will not get an address.
I'm confused as to which (other) callouts should "provide a lease" if I'm skipping lease4_select? Should I be overwriting the lease4 argument in `lease4_select` instead, and setting `NEXT_STATUS_CONTINUE`? If I do this, how do I prevent Kea from recording the lease? Do I need to SKIP `lease4_*` callouts too?
The only subnet is one from `0.0.0.0` - `255.255.255.255`
```
int pkt4_receive(CalloutHandle &handle) {
... business logic here ...
}
int pkt4_send(CalloutHandle &handle) {
... business logic here ...
}
int lease4_select(CalloutHandle &handle) {
handle.setStatus(CalloutHandle::NEXT_STEP_SKIP);
return 0;
}
int subnet4_select(CalloutHandle &handle) {
handle.setStatus(CalloutHandle::NEXT_STEP_SKIP);
return 0;
}
```
Kea 2.4 seems to drop the packet after DHCP4_PACKET_NAK_0003 (even though pkt4_send will eventually fill in everything), the client never receives anything:
```
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610219676288] DHCP4_BUFFER_RECEIVED received buffer from 127.1.2.3:6671 to 127.0.0.1:6672 over interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.options/657887.140610166056640] DHCP4_BUFFER_UNPACK parsing buffer received from 127.1.2.3 to 127.0.0.1 over interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_PACKET_RECEIVED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: DHCPDISCOVER (type 1) received from 127.1.2.3 to 127.0.0.1 on interface lo
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_QUERY_DATA [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1, packet details: local_address=127.0.0.1:6672, remote_address=127.1.2.3:6671, msg_type=DHCPDISCOVER (1), transid=0x
1,
options:
type=053, len=001: 1 (uint8)
type=060, len=015: "HTTPClient::7::" (string)
type=082, len=012:,
options:
type=001, len=004: 65:74:68:30
type=005, len=004: 172.16.42.1 (ipv4-address)
type=093, len=002: 0(uint16)
2023-10-17 06:44:16.759 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_GENERIC Carbide: type=082, len=012:,
options:
type=001, len=004: 65:74:68:30
type=005, len=004: 172.16.42.1 (ipv4-address)
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_PKT4_RECEIVE: CIRCUIT ID [eth0] in packet
2023-10-17 06:44:16.759 INFO [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_GENERIC Carbide: type=060, len=015: "HTTPClient::7::" (string)
2023-10-17 06:44:16.759 ERROR [kea-dhcp4.myhooklib-callouts/657887.140610166056640] LOG_MYHOOKLIB_PKT4_RECEIVE: Missing option [93] in packet
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7fe25b9f3ae3 (callout duration: 87.199 ms)
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 87.199 ms)
2023-10-17 06:44:16.846 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 0.0.0.0/0 for packet received by matching address 172.16.42.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_SUBNET_SELECTED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: the subnet with ID 1 was selected for client assignments
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.packets/657887.140610166056640] DHCP4_SUBNET_DATA [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: the selected subnet details: 0.0.0.0/0
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=020000000001, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier hwaddr=020000000001
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier circuit-id=65746830, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 1 and identifier circuit-id=65746830
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcp4/657887.140610166056640] DHCP4_CLASS_ASSIGNED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: client packet has been assigned to the following class(es): UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcp4/657887.140610166056640] DHCP4_CLASS_ASSIGNED [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_HTTPClient::7::, UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.ddns/657887.140610166056640] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: processing client's Hostname option
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 02:00:00:00:00:01
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 0.0.0.1, found 0 host(s)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.hosts/657887.140610166056640] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 1 and address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 0.0.0.1
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_BEGIN begin all callouts for hook lease4_select
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook lease4_select that has address 0x7fe25b9f4647 (callout duration: 0.007 ms)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.callouts/657887.140610166056640] HOOKS_CALLOUTS_COMPLETE completed callouts for hook lease4_select (total callouts duration: 0.007 ms)
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.dhcpsrv/657887.140610166056640] DHCPSRV_HOOK_LEASE4_SELECT_SKIP Lease4 creation was skipped, because of callout skip flag.
```
... not sure what's supposed to happen at this point to prevent the WARN/ERROR of not having a lease ...
Then:
```
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to allocate an IPv4 lease in the subnet 0.0.0.0/0, subnet-id 1, shared network (none)
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to allocate an IPv4 address after 1 attempt(s)
2023-10-17 06:44:16.847 WARN [kea-dhcp4.alloc-engine/657887.140610166056640] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: Failed to allocate an IPv4 address for client with classes: ALL, VENDOR_CLASS_HTTPClient::7
::, UNKNOWN
2023-10-17 06:44:16.847 DEBUG [kea-dhcp4.bad-packets/657887.140610166056640] DHCP4_PACKET_NAK_0003 [hwtype=1 02:00:00:00:00:01], cid=[no info], tid=0x1: failed to advertise a lease, client sent ciaddr 0.0.0.0, requested-ip-address (no address)
```
... no further output here ...kea2.6.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3103RADIUS realm config entry does nothing2023-11-09T15:41:47ZFrancis DupontRADIUS realm config entry does nothingFour possible solutions:
- to nothing (or put the ticket in Outstanding)
- add a note in ARM saying it is not yet supported
- remove it from the config
- implement it (i.e. adding @<realm> to all User-Name attributes)Four possible solutions:
- to nothing (or put the ticket in Outstanding)
- add a note in ARM saying it is not yet supported
- remove it from the config
- implement it (i.e. adding @<realm> to all User-Name attributes)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3102Possible bug for not pure option containers2023-10-13T23:32:53ZFrancis DupontPossible bug for not pure option containersHere the word pure means empty type, and container an option with sub-options. This ticket is from a dicussion in #2881 which fixed pure option containers.
The goal is to verify that toElement o parse gives back cvs-format and data entr...Here the word pure means empty type, and container an option with sub-options. This ticket is from a dicussion in #2881 which fixed pure option containers.
The goal is to verify that toElement o parse gives back cvs-format and data entries. If it is not the case Option::toBinary should be extended with a new parameter to not include sub-options.next-stable-2.6Razvan BecheriuRazvan Becheriu