Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2018-11-20T21:06:12Zhttps://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/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/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/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/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/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/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/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/1825dhcp pkt getIndex() and setIndex() should use int64_t instead of uint32_t typ...2023-03-30T02:33:46Zbglsriramdhcp pkt getIndex() and setIndex() should use int64_t instead of uint32_t type for ifindex
**Describe the bug**
https://github.com/isc-projects/kea/commit/2a453ec2f66ea4681283df5a4d9e99410a974507 modified ifindex_ to int64_t from an earlier int type and introduced methods: resetIndex() which sets ifindex_ to -1 and indexSet()...
**Describe the bug**
https://github.com/isc-projects/kea/commit/2a453ec2f66ea4681283df5a4d9e99410a974507 modified ifindex_ to int64_t from an earlier int type and introduced methods: resetIndex() which sets ifindex_ to -1 and indexSet() which checks if ifindex_ is greater than equal to 0
However, the getIndex() and setIndex() methods still work with a uint32_t ifindex and this causes ifindex to be truncated for the users of these 2 methods.
So, if a resetIndex() is followed either by getIndex() OR setIndex()[for example - copying of pkt], indexSet() invocation on the same pkt will return true.
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4
2. Install a pkt4_receive() kea dhcp library hook which does a query4/pkt->resetIndex()
3. IfaceMgr::getIface(const PktPtr& pkt) will return an invalid interface.
**Expected behavior**
If a resetIndex() is followed either by getIndex() OR setIndex()[for example - copying of pkt], indexSet() invocation on the same pkt should return false.
**Environment:**
- Kea version: 1.8.2
- OS: Ubuntu 16.04 x64
- Which features were compiled in (in particular which backends): Stock features enabled in the Makefile.
- If/which hooks where loaded in: libdhcp_ha.so, libdhcp_lease_cmds.so, libdhcp_stat_cmds.so and a custom hook to reproduce the issue by installing a pkt4_receive() kea dhcp library hook which does a query4/pkt->resetIndex()
**Additional Information**
**Contacting you**
bglsriram@gmail.comkea1.9.11Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1682suboptions defined in vendor-encapsulated-options-space are not included to o...2022-05-10T10:20:31ZWlodzimierz Wencelsuboptions defined in vendor-encapsulated-options-space are not included to option 43Based on [ARM - 8.2.13. DHCPv4 Vendor-Specific Options](https://jenkins.isc.org/job/Kea_doc/KeaAdministratorReferenceManual/index.html#dhcpv4-vendor-specific-options)
example configuration should work:
```
"client-classes": [
...Based on [ARM - 8.2.13. DHCPv4 Vendor-Specific Options](https://jenkins.isc.org/job/Kea_doc/KeaAdministratorReferenceManual/index.html#dhcpv4-vendor-specific-options)
example configuration should work:
```
"client-classes": [
{
"option-def": [
{
"code": 43,
"type": "empty",
"name": "vendor-encapsulated-options"
}
],
"name": "VENDOR_CLASS_339",
"option-data": [
{
"name": "vendor-encapsulated-options"
},
{
"always-send": true,
"data": "123",
"name": "vlanid",
"space": "vendor-encapsulated-options-space"
},
{
"always-send": true,
"data": "sdlp://192.0.2.11:18443",
"name": "dls",
"space": "vendor-encapsulated-options-space"
}
]
}
],
"option-data": [],
"option-def": [
{
"code": 2,
"name": "vlanid",
"space": "vendor-encapsulated-options-space",
"type": "uint32",
"record-types": "",
"array": false,
"encapsulate": ""
},
{
"code": 3,
"name": "dls",
"space": "vendor-encapsulated-options-space",
"type": "string",
"record-types": "",
"array": false,
"encapsulate": ""
}
],
```
and in if client send option 60 with vendor id `339` it should respond with option 43 that contain both defined suboptions, but it sends empty option 43 (class is evaluated correctly). I'm not sure if it's bug or it's documentation issue.kea2.1-backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2211Set broadcast mac in dhcpv4 reply packets when dst. ip is broadcast2023-07-17T13:58:25ZSergey FominSet broadcast mac in dhcpv4 reply packets when dst. ip is broadcastWhen a DHCPv4 client sends messages with the broadcast flag enabled, kea-dhcp4 server correctly responds with a packets destined to the broadcast IP (255.255.255.255), however, the dst. mac address is still set as a client's unicast addr...When a DHCPv4 client sends messages with the broadcast flag enabled, kea-dhcp4 server correctly responds with a packets destined to the broadcast IP (255.255.255.255), however, the dst. mac address is still set as a client's unicast address.
According to rfc2131 (section 4.1), broadcast mac should be used instead:
> A server or relay agent sending or relaying a DHCP message directly
> to a DHCP client (i.e., not to a relay agent specified in the
> 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
> field. **If this bit is set to 1, the DHCP message SHOULD be sent as
> an IP broadcast using an IP broadcast address (preferably 0xffffffff)
> as the IP destination address and the link-layer broadcast address as
> the link-layer destination address.** If the BROADCAST bit is cleared
> to 0, the message SHOULD be sent as an IP unicast to the IP address
> specified in the 'yiaddr' field and the link-layer address specified
> in the 'chaddr' field. If unicasting is not possible, the message
> MAY be sent as an IP broadcast using an IP broadcast address
> (preferably 0xffffffff) as the IP destination address and the link-
> layer broadcast address as the link-layer destination address.
**Environment:**
- Kea version: 2.1.0
- OS: Ubuntukea2.3.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2694Extend getOptions(type) from pkt6 to pkt4.2023-07-17T13:58:23ZFrancis DupontExtend getOptions(type) from pkt6 to pkt4.Currently the method to get all options from a packet object for a given option type/code is specific to v6: this ticket moves it to the generic packet header so it will be available for v4 too. Required for #1518 and #719.Currently the method to get all options from a packet object for a given option type/code is specific to v6: this ticket moves it to the generic packet header so it will be available for v4 too. Required for #1518 and #719.kea2.3.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1922missing references in option code points2023-07-17T13:58:22ZFrancis Dupontmissing references in option code pointsThere is inconsistency in comments for DHCPv4 and DHCPv6 Option codes - `enum DHCPOptionType` in `dhcp4.h` and `enum DHCPv6OptionType` in `dhcp6.h` respectively.
In comments, there are references to RFCs for each Option. Some references ...There is inconsistency in comments for DHCPv4 and DHCPv6 Option codes - `enum DHCPOptionType` in `dhcp4.h` and `enum DHCPv6OptionType` in `dhcp6.h` respectively.
In comments, there are references to RFCs for each Option. Some references are missing and some are not up to date.
For instance the DHCPv4 option 146 DHO_RDNSS_SELECT has no comment giving its source (RFC 6731) and the last source does not apply (option 145 DHO_FORCERENEW_NONCE_CAPABLE RFC 5859).
BTW sources are available in the IANA option code directory [https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options]
Even it is in the code (vs doc directory) it is clearly a documentation issue.kea2.3.6Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3017[kea_2.4.0]New monitor interface added in kea conf but dhcp4 server can't det...2023-11-28T09:30:37Zchen sijie[kea_2.4.0]New monitor interface added in kea conf but dhcp4 server can't detect the new added interface---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT REPORT IT HERE. Please use https://www.isc.org/community/report-bug/...---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to security-office(at)isc(dot)org.
**Describe the bug**
New monitor interface added in kea conf file but dhcp4 server can't detect the new added interface.
**To Reproduce**
In our project we used kea as our dhcp server and did some second develop work. Below test scenario
failed after upgrade kea from 2.2.0 to 2.4.0.
Steps to reproduce the behavior:
1. Prepare kea conf file and until waiting one running interface to start dhcp4 server.
In this place we can find fhmintbre in RUNNING state and dhcp4server also startup normally.
2. After step1, a new interface fhmintbrc become running,then our service prepare one new conf file, in this file
interface parameter with both fhmintbre and fhmintbrc.
3. Because kea conf file update in our code logical, we need to reload dhcp4server, after reload the dhcp4server can't start.
the log info as "Failed to selecnterface: interface 'fhmintbrc' doesn't exist in the system (/tmp/kea-dhcp4.conf:42:17)"
Seems dhcp4server still used the old conf file didn't get the new conf with fhmintbrc info.
This scenario case work normally in kea 2.2.0. Can you help to check this issue?
**Expected behavior**
dhcp4server startup should use the latest kea-dhcp.conf file after new running interface added, but now we found
dhcp4server still used the old copy.
**Environment:**
- Kea version: kea 2.4.0
- OS: [e.g. Ubuntu 16.04 x64]
- Which features were compiled in (in particular which backends)
- If/which hooks where loaded in
**Additional Information**
Log info print in our env:
```
<14>1 2023-08-22T15:23:36.905286+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - Send dhcp readiness ack: status(SUCCESS):0, hoste: nescran6-dhcp-server-0
<15>1 2023-08-22T15:23:38.584740+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - Readiness fd reveived (IN) callback.
<15>1 2023-08-22T15:23:38.584831+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - hwinfoprovider data provider callback, path: [/na-hwinfo:hwinfo], request_xpath: [/nokia-hwinfo:hwinfo], module: [nokia-hwinfo]
<14>1 2023-08-22T15:23:38.584865+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - hwinfoprovider data provider: [{"nokia-hwinfo:hwo":{"readiness":[{"owner":"nescran6-dhcp-server-0","check-list":[0,1,2],"states":[{"type":2,"last-updated":"2023-08-22T23:23:36.900+08:00"}]}]}}]
<14>1 2023-08-22T15:26:18.863022+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintune0, index:6) upd event. flags:4098
<14>1 2023-08-22T15:26:18.863130+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintune0, index:6) upd event. flags:4098
<14>1 2023-08-22T15:26:18.970545+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintune0, index:6) upd event. flags:69699
<14>1 2023-08-22T15:26:19.305565+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbre, index:7) updaevent. flags:4098
<14>1 2023-08-22T15:26:19.879863+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintune0, index:6) upd event. flags:69699
<14>1 2023-08-22T15:26:19.879984+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintune0, index:6) upd event. flags:69699
<14>1 2023-08-22T15:26:19.880041+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbre, index:7) updaevent. flags:4098
<14>1 2023-08-22T15:26:19.880094+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbre, index:7) updaevent. flags:4098
<14>1 2023-08-22T15:26:19.880160+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbre, index:7) updaevent. flags:4098
<14>1 2023-08-22T15:26:20.473274+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: ip address(iface index:7) update event.ags:128
<14>1 2023-08-22T15:26:21.205540+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbre, index:7) updaevent. flags:69635
<14>1 2023-08-22T15:26:21.205630+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbre, index:7) updaevent. flags:69699
<14>1 2023-08-22T15:26:21.205691+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - Interface index(7) sate change to RUNNING
<14>1 2023-08-22T15:26:22.908112+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - DHCP server inactive.
<14>1 2023-08-22T15:26:23.005806+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - Start dhcp4 server success with cmd: genapiloggeat --ident dhcp4server -- /usr/sbin/kea-dhcp4 -c /tmp/kea-dhcp4.conf &
<14>1 2023-08-22T15:26:23.905870+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.905 INFO [kea-dhcp4.dhcp43.140102015412096] DHCP4_STARTING Kea DHCPv4 server version 2.4.0 (stable) starting
<14>1 2023-08-22T15:26:23.907140+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.907 INFO [kea-dhcp4.hosts3.140102015412096] HOSTS_BACKENDS_REGISTERED the following host backend types are available: postgresql
<14>1 2023-08-22T15:26:23.907517+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.907 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_ADD_IFACE listening on interface fhmintbre
<14>1 2023-08-22T15:26:23.907550+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.907 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type raw
<14>1 2023-08-22T15:26:23.908007+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.907 INFO [kea-dhcp4.hooks3.140102015412096] HOOKS_LIBRARY_CLOSED hooks library /usr/lib64/libkea4hook.so successfully closed
<14>1 2023-08-22T15:26:23.908186+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.908 WARN [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CONFIGURED_SUBNET_WITHOUT_ID a subnet was configured without an id: 50.50.0.0/24
<14>1 2023-08-22T15:26:23.908205+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.908 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 50.50.0.0/24 with params: valid-liime=300
<14>1 2023-08-22T15:26:23.908328+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.908 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 50.50.1.0/24 with params: valid-liime=300
<14>1 2023-08-22T15:26:23.908421+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.908 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 50.50.2.0/24 with params: valid-liime=300
<14>1 2023-08-22T15:26:23.908511+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:23.908 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 50.50.3.0/24 with params: valid-liime=300
<14>1 2023-08-22T15:26:24.005271+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.005 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 50.50.4.0/24 with params: valid-liime=300
<14>1 2023-08-22T15:26:24.005454+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.005 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 50.50.5.0/24 with params: valid-liime=300
<14>1 2023-08-22T15:26:24.005638+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.005 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 50.50.6.0/24 with params: valid-liime=300
<14>1 2023-08-22T15:26:24.005809+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.005 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 60.60.1.0/24 with params: valid-liime=300
<14>1 2023-08-22T15:26:24.006040+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.006 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
<14>1 2023-08-22T15:26:24.006528+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.006 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_ADD_IFACE listening on interface fhmintbre
<14>1 2023-08-22T15:26:24.006563+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.006 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type raw
<14>1 2023-08-22T15:26:24.007242+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.007 INFO [kea-dhcp4.hooks3.140102015412096] HOOKS_LIBRARY_LOADED hooks library /usr/lib64/libkea4hook.so successfully loaded
<14>1 2023-08-22T15:26:24.007270+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.007 INFO [kea-dhcp4.dhcp43.140102015412096] DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: added IPv4 subnets: 8; DDNS: disabled
<14>1 2023-08-22T15:26:24.107592+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.107 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600 max-row-errors=100 name=/var/log/kleasesdb/kea-leases4.csv persist=true type=memfile universe=4
<14>1 2023-08-22T15:26:24.207168+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.207 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/log/kea-leasesdb/kea-leases4.csv
<14>1 2023-08-22T15:26:24.229966+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.229 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4 extracting extended info saw 0 leases, extended info sanity checks mfied 0 / updated 0 leases and 0 leases have relay or remote id
<14>1 2023-08-22T15:26:24.229991+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.229 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
<14>1 2023-08-22T15:26:24.313526+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 50.50.0.0/24
<14>1 2023-08-22T15:26:24.313558+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 50.50.1.0/24
<14>1 2023-08-22T15:26:24.313576+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 50.50.2.0/24
<14>1 2023-08-22T15:26:24.313590+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 50.50.3.0/24
<14>1 2023-08-22T15:26:24.313604+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 50.50.4.0/24
<14>1 2023-08-22T15:26:24.313618+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 50.50.5.0/24
<14>1 2023-08-22T15:26:24.313639+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 50.50.6.0/24
<14>1 2023-08-22T15:26:24.313654+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 INFO [kea-dhcp4.dhcps463.140102015412096] DHCPSRV_CFGMGR_USE_ALLOCATOR using the iterative allocator for V4 leases in subnet 60.60.1.0/24
<14>1 2023-08-22T15:26:24.314034+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.313 WARN [kea-dhcp4.dhcp43.140102015412096] DHCP4_MULTI_THREADING_INFO enabled: no, number of threads: 0, queue size: 0
<14>1 2023-08-22T15:26:24.314114+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.314 INFO [kea-dhcp4.dhcp43.140102015412096] DHCP4_STARTED Kea DHCPv4 server version 2.4.0 started
<14>1 2023-08-22T15:26:24.314292+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.314 ERROR [kea-dhcp4.packe463.140102015412096] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Truncated DHCPv4 packet (len=55) received, atast 236 is expected.
<14>1 2023-08-22T15:26:24.314346+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.314 ERROR [kea-dhcp4.packe463.140102015412096] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Truncated DHCPv4 packet (len=108) received, aeast 236 is expected.
<14>1 2023-08-22T15:26:24.314430+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.314 ERROR [kea-dhcp4.packe463.140102015412096] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Truncated DHCPv4 packet (len=32) received, atast 236 is expected.
<14>1 2023-08-22T15:26:24.314487+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:24.314 ERROR [kea-dhcp4.packe463.140102015412096] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Truncated DHCPv4 packet (len=12) received, atast 236 is expected.
<14>1 2023-08-22T15:26:35.569350+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintunc0, index:8) upd event. flags:4098
<14>1 2023-08-22T15:26:35.569495+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintunc0, index:8) upd event. flags:4098
<14>1 2023-08-22T15:26:35.672859+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintunc0, index:8) upd event. flags:69699
<14>1 2023-08-22T15:26:35.977884+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbrc, index:9) updaevent. flags:4098
<14>1 2023-08-22T15:26:36.505480+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbrc, index:9) updaevent. flags:69699
<14>1 2023-08-22T15:26:36.505604+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - Interface index(9) sate change to RUNNING
<14>1 2023-08-22T15:26:37.270782+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintunc0, index:8) upd event. flags:69699
<14>1 2023-08-22T15:26:37.305261+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintunc0, index:8) upd event. flags:69699
<14>1 2023-08-22T15:26:37.305334+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbrc, index:9) updaevent. flags:69699
<14>1 2023-08-22T15:26:37.305384+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbrc, index:9) updaevent. flags:69699
<14>1 2023-08-22T15:26:37.305439+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbrc, index:9) updaevent. flags:69699
<14>1 2023-08-22T15:26:37.305482+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: interface(name:fhmintbrc, index:9) updaevent. flags:69699
<14>1 2023-08-22T15:26:37.965480+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - netlink: ip address(iface index:9) update event.ags:128
dhcpmanager[9]: INFO/keactrl: Reloading kea-dhcp4...
<14>1 2023-08-22T15:26:38.907204+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:38.907 INFO [kea-dhcp4.dhcp43.140102015412096] DHCP4_DYNAMIC_RECONFIGURATION initiate server reconfiguration using file: /tmp/kea-dhcp4.conf, after receivinIGHUP signal or config-reload command
<14>1 2023-08-22T15:26:38.907997+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:38.907 INFO [kea-dhcp4.hosts3.140102015412096] HOSTS_BACKENDS_REGISTERED the following host backend types are available: postgresql
<14>1 2023-08-22T15:26:39.005586+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:39.005 ERROR [kea-dhcp4.dhcp43.140102015412096] DHCP4_PARSER_FAIL failed to create or run parser for configuration element interfaces-config: Failed to selecnterface: interface 'fhmintbrc' doesn't exist in the system (/tmp/kea-dhcp4.conf:42:17) (/tmp/kea-dhcp4.conf:40:13)
<14>1 2023-08-22T15:26:39.005683+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:39.005 FATAL [kea-dhcp4.dhcp43.140102015412096] DHCP4_CONFIG_UNRECOVERABLE_ERROR DHCPv4 server new configuration failed with an error which cannot be recover
<14>1 2023-08-22T15:26:39.005752+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:39.005 ERROR [kea-dhcp4.dhcp43.140102015412096] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /tmp/kea-dhcp4.conf, reason: Failed to select interfacinterface 'fhmintbrc' doesn't exist in the system (/tmp/kea-dhcp4.conf:42:17) (/tmp/kea-dhcp4.conf:40:13)
<14>1 2023-08-22T15:26:39.005943+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:39.005 FATAL [kea-dhcp4.dhcp43.140102015412096] DHCP4_DYNAMIC_RECONFIGURATION_FAIL dynamic server reconfiguration failed with file: /tmp/kea-dhcp4.conf
dhcpmanager[9]: INFO/keactrl: kea-dhcp6 isn't running.
dhcpmanager[9]: INFO/keactrl: kea-dhcp-ddns isn't running.
dhcpmanager[9]: INFO/keactrl: kea-ctrl-agent isn't running.
<14>1 2023-08-22T15:26:40.007603+08:00 nescran6-dhcp-server-0 dhcpmanager 9 - - Reload dhcp4 server success with cmd: /usr/sbin/ctrl reload -c /tmp/keactrl.conf
dhcpmanager[9]: INFO/keactrl: Reloading kea-dhcp4...
<14>1 2023-08-22T15:26:43.008206+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:43.008 INFO [kea-dhcp4.dhcp43.140102015412096] DHCP4_DYNAMIC_RECONFIGURATION initiate server reconfiguration using file: /tmp/kea-dhcp4.conf, after receivinIGHUP signal or config-reload command
<14>1 2023-08-22T15:26:43.009047+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:43.008 INFO [kea-dhcp4.hosts3.140102015412096] HOSTS_BACKENDS_REGISTERED the following host backend types are available: postgresql
<14>1 2023-08-22T15:26:43.105606+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:43.105 ERROR [kea-dhcp4.dhcp43.140102015412096] DHCP4_PARSER_FAIL failed to create or run parser for configuration element interfaces-config: Failed to selecnterface: interface 'fhmintbrc' doesn't exist in the system (/tmp/kea-dhcp4.conf:42:17) (/tmp/kea-dhcp4.conf:40:13)
<14>1 2023-08-22T15:26:43.105632+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:43.105 FATAL [kea-dhcp4.dhcp43.140102015412096] DHCP4_CONFIG_UNRECOVERABLE_ERROR DHCPv4 server new configuration failed with an error which cannot be recover
<14>1 2023-08-22T15:26:43.205210+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:43.105 ERROR [kea-dhcp4.dhcp43.140102015412096] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /tmp/kea-dhcp4.conf, reason: Failed to select interfacinterface 'fhmintbrc' doesn't exist in the system (/tmp/kea-dhcp4.conf:42:17) (/tmp/kea-dhcp4.conf:40:13)
<14>1 2023-08-22T15:26:43.205239+08:00 nescran6-dhcp-server-0 dhcp4server 455 - - 2023-08-22 15:26:43.105 FATAL [kea-dhcp4.dhcp43.140102015412096] DHCP4_DYNAMIC_RECONFIGURATION_FAIL dynamic server reconfiguration failed with file: /tmp/kea-dhcp4.conf
dhcpmanager[9]: INFO/keactrl: kea-dhcp6 isn't running.
dhcpmanager[9]: INFO/keactrl: kea-dhcp-ddns isn't running.
dhcpmanager[9]: INFO/keactrl: kea-ctrl-agent isn't running.
```
**Contacting you**
sijie.chen@nokia-sbell.com
Andrei: edited the **Additional Information** section to be readable.kea2.5.3Razvan BecheriuRazvan Becheriuhttps://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/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/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/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 Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3100Support array of OPT_RECORD_TYPE for Option definition2024-01-09T11:40:57ZPiotrek ZadrogaSupport array of OPT_RECORD_TYPE for Option definitionWhile working on #3074 it occurred to me that it would be very useful to be able to define new Option as an array of OPT_RECORD_TYPE.
We could consider implementing that in Kea.While working on #3074 it occurred to me that it would be very useful to be able to define new Option as an array of OPT_RECORD_TYPE.
We could consider implementing that in Kea.next-stable-2.6