Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2022-11-02T15:08:43Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/52kea-dhcp4 can't offer ip reserved.2022-11-02T15:08:43ZGhost Userkea-dhcp4 can't offer ip reserved.subnet : 192.168.0.0/24
reservation1 : mac(aa:aa:aa:aa:aa:aa) ip(192.168.0.11)
reservation2 : mac(bb:bb:bb:bb:bb:bb) ip(192.168.0.12)
reservation1 has router option(3) 192.168.0.3
reservation2 has no options.
I used mysql for hosts res...subnet : 192.168.0.0/24
reservation1 : mac(aa:aa:aa:aa:aa:aa) ip(192.168.0.11)
reservation2 : mac(bb:bb:bb:bb:bb:bb) ip(192.168.0.12)
reservation1 has router option(3) 192.168.0.3
reservation2 has no options.
I used mysql for hosts reservation.
kea-dhcp4 responses to reservation1 but fail to response to reservation2 somtimes.
The Failure log is 'preparing on-wire-format of the packet to be sent failed DHCPv4 Option4AddrLst 3 is too big.At most 255 bytes are supported.'
In packets debug log, kea-dhcp4 try to response to reserve2 with router option(value is 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ....... maybe 2048~4096byte)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/86Case sensitivity discrepancy between Option4ClientFqdn and Option6ClientFqdn2018-12-04T16:21:49ZGhost UserCase sensitivity discrepancy between Option4ClientFqdn and Option6ClientFqdnThere is a discrepancy between on Option4ClientFqdn and Option6ClienFqdn when it comes to constructing them from strings. The latter uses a lib::dns::Name() constructor variant which accepts a boolean flag as to whether or not it should...There is a discrepancy between on Option4ClientFqdn and Option6ClienFqdn when it comes to constructing them from strings. The latter uses a lib::dns::Name() constructor variant which accepts a boolean flag as to whether or not it should
"downcase" the string, the former does not do this.
This means a the FQDN sent by a V4 client will have its case preserved while
one sent by a v6 client will not.
We need to determine what the proper behavior should be and proceed accordingly.Kea1.5-finalMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/257Improve doxygen for IfaceMgr2022-11-02T15:08:44ZThomas MarkwalderImprove doxygen for IfaceMgrThe class commentary for IfaceMgr is extremely terse and needs to be expanded.The class commentary for IfaceMgr is extremely terse and needs to be expanded.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/260Follow-up from "WIP: Resolve "Congestion handling - add receive thread and pa...2018-11-20T21:06:12ZMarcin SiodelskiFollow-up from "WIP: Resolve "Congestion handling - add receive thread and packet queue"The following discussions from !103 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28121): (+4 comments)
> I have some worries about this initialization pa...The following discussions from !103 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28121): (+4 comments)
> I have some worries about this initialization part being done in the thread and not really guarded from concurrent access to IfaceMgr. Although unlikely, there is a possibility that ifaces_ is modified while the thread is starting up. To mitigate this problem, the method which starts the thread should maybe wait for it to signal that it has been initialized and the for() loop has started. I mean, we should maybe revise the whole IfaceMgr to see whether something in it can be modified that is concurrently used in the thread and not allow such modification if the thread is running? Specifically, sockets and interfaces should not be touched while the thread is running because even the for() loop accesses them.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28138): (+3 comments)
> Parameters of the constructor aren't properly documented.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28180): (+4 comments)
> That deserves some comment.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28205): (+5 comments)
> I was scratching my head how is the new IfaceMgr code compatible with perfdhcp, which is also using receive4() and receive6() functions, but it doesn't (at least not explicitly) start receiver thread? On that matter, I also wonder if it shouldn't be optional to use the thread? perfdhcp probably doesn't want to drop any packets in the ring buffer?Kea1.5-beta2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/323Warning message "the interface x is down" is incomplete. (GH#95)2023-03-03T08:52:38ZVicky Riskvicky@isc.orgWarning message "the interface x is down" is incomplete. (GH#95)<This was first reported as Github issue #95, by brubbel, on July 19, 2018>
(Note: This was tested on Kea 1.1.0, but I see that this issue is still present in the latest 1.4.0 version.)
At startup, Kea may produce the following warning ...<This was first reported as Github issue #95, by brubbel, on July 19, 2018>
(Note: This was tested on Kea 1.1.0, but I see that this issue is still present in the latest 1.4.0 version.)
At startup, Kea may produce the following warning message:
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface x is down or has no usable IPv4 addresses configured
I checked interface x of course, but it was [UP] and had an IPv4 address assigned.
It turns out (from reading the source) that Kea expects interface x also being in the [RUNNING] state.
I suggest to change the warning message into "has no usable IPv4 address or is missing flags [UP] and/or [RUNNING]."
As a related question: why does isc-dhcp allow and kea-dhcp does not allow starting a server on an interface without the IFF_RUNNING flag set?
In any case, kea 1.1.0 does not work when the interface is not [RUNNING] when it was started, even when it becomes [RUNNING] afterwards. When the state goes from running->not running->running: all ok.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/343Put socket control buffer in the stack2020-03-26T08:05:01ZFrancis DupontPut socket control buffer in the stackThere is no good reason to have socket control buffers in the packet filter object: simply put them in the stack where the input/output buffer already is. This enables for instance multiple receiving threads (DHCP is over UDP so it is sa...There is no good reason to have socket control buffers in the packet filter object: simply put them in the stack where the input/output buffer already is. This enables for instance multiple receiving threads (DHCP is over UDP so it is safe, at least with a way to not receive the same query in all threads...).
fixes #1158kea1.7.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/348Small experiment improving congestion control locks2023-03-15T11:43:45ZFrancis DupontSmall experiment improving congestion control locksI propose a small experiment to see if this trivial (and recognized as correct) change makes a noticeable difference. I leave to QA the win threshold which requires inclusion in 1.5 or 1.6.
The change is here and in the attachment too.
...I propose a small experiment to see if this trivial (and recognized as correct) change makes a noticeable difference. I leave to QA the win threshold which requires inclusion in 1.5 or 1.6.
The change is here and in the attachment too.
```
diff --git a/src/lib/dhcp/packet_queue_ring.h b/src/lib/dhcp/packet_queue_ring.h
index 315e2a0375..bcaa496747 100644
--- a/src/lib/dhcp/packet_queue_ring.h
+++ b/src/lib/dhcp/packet_queue_ring.h
@@ -123,12 +123,12 @@ public:
/// @return A pointer to dequeued packet, or an empty pointer
/// if the queue is empty.
virtual PacketTypePtr popPacket(const QueueEnd& from = QueueEnd::FRONT) {
- isc::util::thread::Mutex::Locker lock(mutex_);
PacketTypePtr packet;
if (queue_.empty()) {
return (packet);
}
+ isc::util::thread::Mutex::Locker lock(mutex_);
if (from == QueueEnd::FRONT) {
packet = queue_.front();
queue_.pop_front();
```
[better-lock.diff](/uploads/0f3a20502c39e13e033d0818fd20b25c/better-lock.diff)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/417Incorrect Return Value of IfaceMgr::send2019-02-19T10:47:32ZGhost UserIncorrect Return Value of IfaceMgr::send**Describe the bug**
Precondition: PktFilterLPF or PktFilterBPF is used
If IfaceMgr::send(const Pkt4Ptr& pkt) is called, it returns false if successfull.
The Documentation and the header state:
/// @return true if sending was success...**Describe the bug**
Precondition: PktFilterLPF or PktFilterBPF is used
If IfaceMgr::send(const Pkt4Ptr& pkt) is called, it returns false if successfull.
The Documentation and the header state:
/// @return true if sending was successful
bool send(const Pkt4Ptr& pkt);
The return statement of this method looks like this:
return (packet_filter_->send(*iface, getSocket(*pkt).sockfd_, pkt));
PktFilter::send shall return 0 on success, which converts to false.
pkt_filter.h:
class PktFilter {
/// @return result of sending the packet. It is 0 if successful.
virtual int send(const Iface& iface, uint16_t sockfd,
const Pkt4Ptr& pkt) = 0;
This behavior is not reproducible if PktFilterInet is used.
The reason is that it returns the RV of sendmsg.
sendmsg returns the number of sent characters.
pkt_filter_inet.cc:
int result = sendmsg(sockfd, &m, 0);
return (result);
This means PktFilterInet::send will most likely return values larger than 0 if successfull.
PktFilterBPF performs correct, just as PktFilterLPF does.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with the default PktFilter (PktFilterLpf) on a Linux Machine
2. Register a Plugin and send a packet by calling IfaceMgr::send(const Pkt4Ptr& pkt)
**Expected behavior**
The Documentation states that the method shall return true on success. In fact it returns false.
**Environment:**
- Kea version: 1.3.0 (git 62af6072a51d2fa319268e9ca615e244506fc5ef)
But the bug is still present on the current master branch
- OS: Linux OS based on Kernel 4.14
- Which features were compiled in
Kea source configure results:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Package:
Name: kea
Version: 1.3.0
Extended version:1.3.0 (git 62af6072a51d2fa319268e9ca615e244506fc5ef)
OS Family: Linux
Using GNU sed: yes
Premium package: no
C++ Compiler:
CXX: g++
CXX_VERSION: g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
CXX_STANDARD: 201402
DEFS: -DHAVE_CONFIG_H
CPPFLAGS: -DOS_LINUX -I$(top_srcdir)/ext/coroutine -DBOOST_ASIO_HEADER_ONLY -DBOOST_ASIO_DISABLE_THREADS=1
CXXFLAGS: -g -O2
LDFLAGS: -Wl,-R/build/3.5.0.x/botan/_/usr/lib -lpthread
KEA_CXXFLAGS: -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC
Python:
PYTHON_VERSION: not needed (because kea-shell is disabled)
Boost:
BOOST_VERSION: 1.67
BOOST_INCLUDES:
BOOST_LIBS: -lboost_system
Botan:
CRYPTO_VERSION: 2.4.0
CRYPTO_CFLAGS:
CRYPTO_INCLUDES: -I/build/3.5.0.x/botan/_/usr/include/botan-2
CRYPTO_LDFLAGS: -L/build/3.5.0.x/botan/_/usr/lib
CRYPTO_LIBS: -L/build/3.5.0.x/botan/_/usr/lib -lbotan-2 -lbotan-2
OpenSSL: no
Log4cplus:
LOG4CPLUS_VERSION: 1.2.0
LOG4CPLUS_INCLUDES:
LOG4CPLUS_LIBS: -llog4cplus
Flex/bison:
FLEX: flex
BISON: bison -y
MySQL:
no
PostgreSQL:
no
Cassandra CQL:
no
Developer:
Enable Debugging: yes
Google Tests: no
Valgrind: found
C++ Code Coverage: no
Logger checks: no
Generate Documentation: no
Parser Generation: no
Kea-shell: no
- Hooks loaded: lease4_renew, lease4_select, lease6_rebind, lease6_renew, lease6_select, pkt4_receive, pkt4_send, pkt6_receive, pkt6_send
**Describe the solution you'd like**
Fix of IfaceMgr::send(const Pkt4Ptr& pkt) and
PktFilterInet::send(const Iface& iface, uint16_t sockfd,
const Pkt4Ptr& pkt)
to make them perform according to the Documentation.
**Contacting you**
Email me at matthias.stoeckl@secunet.comKea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/543Inconsistency in Pkt class2019-08-08T16:18:41ZGhost UserInconsistency in Pkt classThere are members iface_ and ifindex_ in Pkt class.
They are closely linked to each other and must be set/updated simultaneously.
Currently it is possible to set iface_ and/or ifindex_ independently of each other and get an inconsisten...There are members iface_ and ifindex_ in Pkt class.
They are closely linked to each other and must be set/updated simultaneously.
Currently it is possible to set iface_ and/or ifindex_ independently of each other and get an inconsistent object state.
Example 1:
1. There is correctly crafted object named 'packet' (iface_="eth0", ifindex_=2);
2. packet->setIface("eth1");
3. IfaceMgr->send(packet);
Result: packet sent out of eth0, but not eth1.
Example 2:
1. There is correctly crafted object named 'packet' (iface_="eth0", ifindex_=2);
2. packet->setIndex(3); // iface_="eth0"
3. IfaceMgr->send(packet);
Result: packet sent out of eth1, but not eth0.Kea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/553Speedup interface lookup2021-05-07T08:23:23ZFrancis DupontSpeedup interface lookupIn the interface code (iface_mgr.*) it is noted that the current structure (list) is not efficient for lookups (both by name and by index use a FOREACH). I suggest to switch to a multi index:
- name index should be unordered (hash shoul...In the interface code (iface_mgr.*) it is noted that the current structure (list) is not efficient for lookups (both by name and by index use a FOREACH). I suggest to switch to a multi index:
- name index should be unordered (hash should be better than RB tree according to the common naming) and unique.
- index should be ordered, unique and be the first index so iterations will use it (based on the assumption interfaces are scanned by increasing index so it should be similar to the current behavior)
Note that C library routines should be never used in place performance matters as they simply rescan the whole interface list...kea1.7.10Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/913Implement OptionAuth for use with DHCPv6 authentication and reconfiguration2019-09-19T09:52:03ZMarcin SiodelskiImplement OptionAuth for use with DHCPv6 authentication and reconfigurationThe Reconfigure mechanism requires that the server sends Authentication Option (11) to the clients to communicate the authentication key during the Solicit/Reply, Request/Reply and Information-request/Reply transactions. It also uses thi...The Reconfigure mechanism requires that the server sends Authentication Option (11) to the clients to communicate the authentication key during the Solicit/Reply, Request/Reply and Information-request/Reply transactions. It also uses this option in the Reconfigure messages. The option comprises a record of fields and can't be represented by any of the existing options. The limitation of the `OptionCustom` class is that the Auth option has the 64-bit field for Replay Detection and `OptionCustom` does not support 64-bit fields. We could extend the `OptionCustom` but in fact it is better (and cleaner) to have a dedicated class to represent Auth Option as it has very specific usage and a few convenience functions could be added to this new class to make it easy to manipulate this option. The `OptionCustom` is very generic.https://gitlab.isc.org/isc-projects/kea/-/issues/1009Provide a standard queue choice for packet queue2019-12-12T16:57:24ZFrancis DupontProvide a standard queue choice for packet queueToday we have only the ring but even with an infinite (0) capacity it is not the same than a queue.
Whether this should stay internal to the dhcp library or available to DHCP server syntaxes is still a subject for discussion.Today we have only the ring but even with an infinite (0) capacity it is not the same than a queue.
Whether this should stay internal to the dhcp library or available to DHCP server syntaxes is still a subject for discussion.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1025kea dhcp server not sending vendor option based on host reservation2020-09-21T12:26:45ZGhost Userkea dhcp server not sending vendor option based on host reservationHi,
I have defined a vendor specific option under the space "vendor-opts-space" and included it in a host reservation. However, the server only sends the IP address reserved for this host and never sends the vendor options. I have verifi...Hi,
I have defined a vendor specific option under the space "vendor-opts-space" and included it in a host reservation. However, the server only sends the IP address reserved for this host and never sends the vendor options. I have verified that through wireshark capture too.
Here is the "option-def":
```
"option-def": [
{
"name": "oran-dhcpv6",
"code": 1,
"space": "vendor-opts-space",
"type": "record",
"array": false,
"record-types": "uint8, uint8, string",
"encapsulate": ""
}
],
```
And this is the host reservation:
```
{
"duid": "0:02:0:0:0:c1:43:38:32:41:35:38:34:31:39:31",
"ip-addresses": [ "3ffe:501:ffff:100::130" ],
"option-data": [
{
"name": "oran-dhcpv6",
"space": "vendor-opts-space",
"data": "1, 4, 2C6 B9 9F 9"
},
{
//"name": "vendor-opts",
"code": 17,
// ORAN specified enterprise-number 53148 on ORAN MP spec section 3.1.4
"data": "53148"
}
]
},
```
I dont see any error or warning when I enable DEBUG mode for the kea dhcp server but don't see the options being sent. Is there something I need to specify in the dhclient's config file to request this option? I suppose not, because this is specified for this host reservation, isn't it?
Thankskea1.9.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1043Possible short coming in SharedNetworkListParserTest.iface2020-07-08T11:29:11ZFrancis DupontPossible short coming in SharedNetworkListParserTest.ifaceThe new SharedNetworkListParserTest.iface unit test uses the eth0 interface name. At least on Alpine it fails because this interface exists in the system.
A new interface should be added into iface_mgr_test_config.cc with a name which v...The new SharedNetworkListParserTest.iface unit test uses the eth0 interface name. At least on Alpine it fails because this interface exists in the system.
A new interface should be added into iface_mgr_test_config.cc with a name which very unlikely already exists in any systems and this new name used for in system not existence tests.kea1.7.10Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1084Kea does not recover from interface down when Kea starts2024-02-08T14:35:31ZRob AusteinKea does not recover from interface down when Kea startsProblem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server i...Problem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server is part of a large rack of equipment, and we have no control over the order in which things come up, not to mention various replacement and reinstall scenarios. Kea quietly fails to listen on interfaces that show no carrier at the time Kea first starts, and never notices when they come up.
So far I have not thought of anything better than a separate process which monitors link states (eg with PyRoute2) and sends a config-reload control message whenever any of the interfaces comes up. This seems kind of lame.
Is this a known issue? Note that this is not the "new interface" problem: we know all the interfaces and list them in the config file, we just can't guarantee that they'll be up (and in some cases they *can't* come up until after Kea does because they're waiting for a DHCP lease in order to install the software that will eventually bring up the other end of the link).
Is this something ISC is likely to be able to fix anytime soon? Is there a better workaround?
Thanks! (Obligatory note: on the whole I'm very happy with Kea as a replacement for isc-dhcpd, don't think I'm complaining about the new thing... I just need to find a solution to this problem.)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1117Mix of physical and virtual interfaces (VLAN) does not work2024-03-14T10:45:38ZTalkaboutMix of physical and virtual interfaces (VLAN) does not work**Describe the bug**
Setting up KEA DHCP server on a system to listen to a physical interface and one or multiple virtual interfaces causes wrong IP pools to be assigned.
**To Reproduce**
Steps to reproduce the behavior:
1. Set up a vir...**Describe the bug**
Setting up KEA DHCP server on a system to listen to a physical interface and one or multiple virtual interfaces causes wrong IP pools to be assigned.
**To Reproduce**
Steps to reproduce the behavior:
1. Set up a virtual interface as VLAN interface connected to a physical interface
2. Configure KEA DHCP server to listen to physical interface and virtual interface in "raw" mode
3. Try to request an IP from the pool assigned to the VLAN
4. KEA DHCP server gets confused and handles the request on both devices advertising different ips
**Expected behavior**
Proper IP pools should be assigned. VLAN requests must not be handled on physical device.
**Environment:**
- Kea version: 1.6.1
- OS: Debian 10
- Which features were compiled in (in particular which backends): mysql
- If/which hooks where loaded in: libdhcp_stat_cmds.so, libdhcp_ha.so, libdhcp_lease_cmds.so
**Additional Information**
Config file:
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth0", "eth0.30", "eth0.50", "eth0.100" ],
"dhcp-socket-type": "raw"
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"lease-database": {
…
},
"hosts-database": {
…
},
"sanity-checks": {
"lease-checks": "fix-del"
},
"valid-lifetime": 28800,
"rebind-timer": 21600,
"subnet4": [
{
"pools": [
{
"pool": "192.168.20.100-192.168.20.200"
}
],
"id": 1,
"subnet": "192.168.20.0/24",
"interface": "eth0",
"option-data": [
…
]
},
{
"pools": [
{
"pool": "192.168.30.100-192.168.30.200"
}
],
"id": 30,
"subnet": "192.168.30.0/24",
"interface": "eth0.30",
"option-data": [
…
]
},
{
"pools": [
{
"pool": "192.168.50.100-192.168.50.200"
}
],
"id": 50,
"interface" : "eth0.50",
"subnet": "192.168.50.0/24",
"option-data": [
…
]
},
{
"pools": [
{
"pool": "192.168.100.100-192.168.100.200"
}
],
"id": 100,
"subnet": "192.168.100.0/24",
"interface": "eth0.100",
"option-data": [
…
]
}
],
"hooks-libraries": [
…
],
"loggers": [
…
]
}
}
```
Currently I have a temporary solution in place by creating a "macvlan" device (also virtual) to handle traffic from the physical device. But this is not an optimal solution.
**Contacting you**
talk.about@gmx.deoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1195external socket list is not multi-thread safe.2020-04-23T15:36:26ZFrancis Dupontexternal socket list is not multi-thread safe.Related to #1095. Note that here the multi-thread safety must be interpreted as generic, i.e. not the MultiThreadingMgr, and the bug fix should IMHO be back ported to 1.6.Related to #1095. Note that here the multi-thread safety must be interpreted as generic, i.e. not the MultiThreadingMgr, and the bug fix should IMHO be back ported to 1.6.https://gitlab.isc.org/isc-projects/kea/-/issues/1215Pkt<4/6>::getName() should support all message type names2020-05-13T14:33:40ZThomas MarkwalderPkt<4/6>::getName() should support all message type namesNotably missing from Pkt4::getName() are the lease query related message types. It would be handy if we returned labels for all the types, not just those we handle.Notably missing from Pkt4::getName() are the lease query related message types. It would be handy if we returned labels for all the types, not just those we handle.kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1532rawip interface support2020-11-26T16:59:22ZFrancis Dupontrawip interface supportA patch (https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/66) was proposed for ISC DHCP to add support for interfaces using the rawip ARP hardware type. I propose when the ISC DHCP part will be ready to do the same for Kea.
(tr...A patch (https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/66) was proposed for ISC DHCP to add support for interfaces using the rawip ARP hardware type. I propose when the ISC DHCP part will be ready to do the same for Kea.
(triage proposal: put it in 1.x and re-triage it when the ISC DHCP part will be ready)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1640OptionDataDef uses raw pointers (should be strings or smartptrs)2023-07-31T12:45:46ZTomek MrugalskiOptionDataDef uses raw pointers (should be strings or smartptrs)The following structures use raw pointers in `src/lib/dhcp/option_data_types.h`:
```
struct OptionDefParams {
const char* name; // option name
uint16_t code; // option code
cons...The following structures use raw pointers in `src/lib/dhcp/option_data_types.h`:
```
struct OptionDefParams {
const char* name; // option name
uint16_t code; // option code
const char* space; // option space
OptionDataType type; // data type
bool array; // is array
const OptionDataType* records; // record fields
size_t records_size; // number of fields in a record
const char* encapsulates; // option space encapsulated by the
// particular option.
};
/// @brief Encapsulation of option definition parameters and the structure size.
struct OptionDefParamsEncapsulation {
const struct OptionDefParams* optionDefParams; // parameters structure
const int size; // structure size
const char* space; // option space
};
```
Those structures should be converted to a safer approach - either plain std::string or a smartptr if some data sharing is needed.backlog