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/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/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/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/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/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/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.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1738Improve VLAN filtering for raw sockets2024-03-14T10:45:38ZTomek MrugalskiImprove VLAN filtering for raw socketsThere were several reports of users struggling with mixed VLAN setups: some interfaces are physical and some are tagged:
* https://lists.isc.org/pipermail/kea-users/2020-February/002619.html (the discussion is long)
The goal of this ti...There were several reports of users struggling with mixed VLAN setups: some interfaces are physical and some are tagged:
* https://lists.isc.org/pipermail/kea-users/2020-February/002619.html (the discussion is long)
The goal of this ticket is to extend the LPF/BPF code to better handle tagged packets.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2755Cache essential standard option definitions2023-06-20T12:30:08ZFrancis DupontCache essential standard option definitionsIn a lot of place in the code we fetch the definition of a standard option. This raises two points:
- it is not very efficient even the number of standard options is both small and bound for v4
- each time it is not possible to assume ...In a lot of place in the code we fetch the definition of a standard option. This raises two points:
- it is not very efficient even the number of standard options is both small and bound for v4
- each time it is not possible to assume the pointer to the option defition is not null
The idea is to create some static methods in lindhcp++ returning a static pointer to the definition. The initialization code checks that there is no missing definitions. Both more efficient and safer...next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2776Kea fails to open socket2023-08-10T13:18:25ZNeil RomigKea fails to open socketKea sometimes fails to bind to socket when starting. This can happen at boot or when restarting the dhcp server, and all other network functions appear normal.
This issue does not always occur, and I am new to Kea so may need some help ...Kea sometimes fails to bind to socket when starting. This can happen at boot or when restarting the dhcp server, and all other network functions appear normal.
This issue does not always occur, and I am new to Kea so may need some help to provide relevant info.
Steps to reproduce the behavior:
1. Start the DHCP4 server. Check system logs. An instance of failure is shown below.
```
2023-02-18 20:24:07.082 INFO [kea-dhcp4.hosts/484.140130011339840] HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql
2023-02-18 20:24:07.083 INFO [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_CFGMGR_ADD_IFACE listening on interface enp2s0
2023-02-18 20:24:07.083 INFO [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type raw
2023-02-18 20:24:07.083 INFO [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 192.168.92.0/24 with params: t1=900, t2=1800, valid-lifetime=3600
2023-02-18 20:24:07.084 INFO [kea-dhcp4.commands/484.140130011339840] COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea4-ctrl-socket
2023-02-18 20:24:07.084 INFO [kea-dhcp4.dhcp4/484.140130011339840] DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: added IPv4 subnets: 1; DDNS: disabled
2023-02-18 20:24:07.084 INFO [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600 type=memfile universe=4
2023-02-18 20:24:07.086 INFO [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv.2
2023-02-18 20:24:07.086 INFO [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv
2023-02-18 20:24:07.095 INFO [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
2023-02-18 20:24:07.095 WARN [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface enp2s0 is not running
2023-02-18 20:24:07.095 INFO [kea-dhcp4.dhcp4/484.140130011339840] DHCP4_OPEN_SOCKETS_FAILED maximum number of open service sockets attempts: 0, has been exhausted without success
2023-02-18 20:24:07.095 WARN [kea-dhcp4.dhcpsrv/484.140130011339840] DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
2023-02-18 20:24:07.095 WARN [kea-dhcp4.dhcp4/484.140130011339840] DHCP4_MULTI_THREADING_INFO enabled: no, number of threads: 0, queue size: 0
2023-02-18 20:24:07.095 INFO [kea-dhcp4.dhcp4/484.140130011339840] DHCP4_STARTED Kea DHCPv4 server version 2.2.0 started
```
**Expected behavior**
A successful startup as shown below:
```
2023-02-01 16:46:38.527 INFO [kea-dhcp4.dhcp4/85444.139972960083008] DHCP4_SHUTDOWN server shutdown
2023-02-01 16:46:38.639 INFO [kea-dhcp4.hosts/94778.140528916364352] HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql
2023-02-01 16:46:38.640 INFO [kea-dhcp4.dhcpsrv/94778.140528916364352] DHCPSRV_CFGMGR_ADD_IFACE listening on interface enp2s0
2023-02-01 16:46:38.640 INFO [kea-dhcp4.dhcpsrv/94778.140528916364352] DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type raw
2023-02-01 16:46:38.640 INFO [kea-dhcp4.dhcpsrv/94778.140528916364352] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 192.168.92.0/24 with params: t1=900, t2=1800, valid-lifetime=3600
2023-02-01 16:46:38.641 INFO [kea-dhcp4.commands/94778.140528916364352] COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea4-ctrl-socket
2023-02-01 16:46:38.641 INFO [kea-dhcp4.dhcp4/94778.140528916364352] DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: added IPv4 subnets: 1; DDNS: disabled
2023-02-01 16:46:38.641 INFO [kea-dhcp4.dhcpsrv/94778.140528916364352] DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600 type=memfile universe=4
2023-02-01 16:46:38.641 INFO [kea-dhcp4.dhcpsrv/94778.140528916364352] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv
2023-02-01 16:46:38.642 INFO [kea-dhcp4.dhcpsrv/94778.140528916364352] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
2023-02-01 16:46:38.670 WARN [kea-dhcp4.dhcp4/94778.140528916364352] DHCP4_MULTI_THREADING_INFO enabled: no, number of threads: 0, queue size: 0
2023-02-01 16:46:38.670 INFO [kea-dhcp4.dhcp4/94778.140528916364352] DHCP4_STARTED Kea DHCPv4 server version 2.2.0 started
```
**Environment:**
- Kea version: 2.2.0
- OS: Arch Linux 6.1.12-arch1-1 x86_64
**Additional Information**
Not sure what else to include for the developers - please advise.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3037Kea / hostapd conflict2023-09-21T17:55:21ZThomas KöllerKea / hostapd conflictI am currently migrating my DHCP server setup from dhcpd to kea. While doing so, I came across a problem that so far I have been unable to solve.
There are three network interfaces on my system that are relevant here, namely lan_wifi (3...I am currently migrating my DHCP server setup from dhcpd to kea. While doing so, I came across a problem that so far I have been unable to solve.
There are three network interfaces on my system that are relevant here, namely lan_wifi (3), lan_ether (4), and a bridge interface br_lan (6), of which these two are slaves:
```
[thomas@sarkovy ~]$ networkctl list
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp38s0 ether off unmanaged
3 lan_wifi ether enslaved configured
4 lan_ether ether enslaved configured
5 eth_cable ether routable configured
6 br_lan bridge routable configured
6 links listed.
```
In my existing dhcpd-based setup, there is an instance of the hostapd daemon running on the lan_wifi interface:
```
[root@sarkovy kea]# lsof -i udp:67
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
hostapd 18322 root 5u IPv4 288312 0t0 UDP *:bootps
dhcpd 19279 dhcpd 8u IPv4 312588 0t0 UDP *:bootps
```
Both these daemons apparently co-exist just fine. If, however, I try to replace dhcpd with kea-dhcp4, a conflict arises:
```
Aug 31 11:57:18 sarkovy kea-dhcp4[19308]: 2023-08-31 11:57:18.970 WARN [kea-dhcp4.dhcpsrv/19308.140339384615296] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface br_lan, reason: failed to bind fallback socket to address 192.168.0.1, port 67, reason: Address already in use - is another DHCP server running?
Aug 31 11:57:18 sarkovy kea-dhcp4[19308]: 2023-08-31 11:57:18.970 INFO [kea-dhcp4.dhcp4/19308.140339384615296] DHCP4_OPEN_SOCKETS_FAILED maximum number of open service sockets attempts: 0, has been exhausted without success
```
I have to stop hostapd in order to be able to start kea-dhcp4. Unfortunately, I need both of them. My kea configuration includes the following "interfaces-config" section:
```
"interfaces-config": {
"interfaces": [ "br_lan/192.168.0.1" ],
"dhcp-socket-type": "raw",
"service-sockets-require-all": true
},
```
Is there anything I can do to resolve this conflict?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3040failure to start up with ppp interfaces2024-02-08T14:35:31ZJaco Kroonfailure to start up with ppp interfaces2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed...2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed to bind socket 20 to fe80::e/port=547: Cannot assign requested address
```
26: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1350 qdisc tbf state UNKNOWN group default qlen 3
inet6 fe80::14e4:139f:8862:3dfd peer fe80::e/128 scope link
valid_lft forever preferred_lft forever
```
Obviously we should bind to the local link-local, not the remote one.
kea 2.4.0. 2.5.1 segfaults on my configuration:
```
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "ppp0" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/run/kea/kea6-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"option-data": [
{
"name": "dns-servers",
"data": "2c0f:f720::..., 2c0f:f720::..."
}
],
"subnet6": [
{
"subnet": "2c0f:f720:fcf0::/44",
"pd-pools": [
{
"prefix": "2c0f:f720:fcf0::",
"prefix-len": 44,
"delegated-len": 56
}
]
}
],
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea/kea-dhcp6.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
```
Strace from a re-run (so socket number is different):
```
bind(19, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
getsockname(19, {sa_family=AF_NETLINK, nl_pid=6688, nl_groups=00000000}, [12]) = 0
sendto(19, [{nlmsg_len=20, nlmsg_type=RTM_GETLINK, nlmsg_flags=NLM_F_REQUEST|NLM_F_DUMP, nlmsg_seq=1, nlmsg_pid=0}, {ifi_family=AF_PACKET, ...}], 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
recvmsg(19, {msg_name={sa_family=AF_NETLINK ...
ifa_index=if_nametoindex("ppp0")}, [[{nla_len=20, nla_type=IFA_LOCAL}, **inet_pton(AF_INET6, "fe80::14e4:139f:8862:3dfd")], [{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "fe80::e")],** [{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=168714876, tstamp=168714876}], [{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT]]], [{nlmsg_len=72, nlmsg_type=RTM_NEWADDR, nlmsg_flags=NLM_F_MULTI, nlmsg_seq=2, nlmsg_pid=6688}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK,
...
close(19) = 0
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 19
ioctl(19, SIOCGIFINDEX, {ifr_name="ppp0", ifr_ifindex=26}) = 0
close(19) = 0
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 19
fcntl(19, F_SETFD, FD_CLOEXEC) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(19, {sa_family=AF_INET6, sin6_port=htons(547), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "**fe80::e**", &sin6_addr), sin6_scope_id=if_nametoindex("ppp0")}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
close(19) = 0
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3062Any interface created while retrying sockets are used unfiltered2024-02-08T14:35:31ZEfe Can İçözAny interface created while retrying sockets are used unfiltered
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in conf...
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in configuration file.
**To Reproduce**
Steps to reproduce the behavior:
1. Set a dummy interface and ensure that it's down.
`ip link add dummy0 type dummy`
`ip addr add 192.168.1.1/24 dev dummy0`
`ip link set dummy0 down`
2. Run Kea dhcp4 server with the following config
{
"Dhcp4": {
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"interfaces-config": {
"interfaces": [ "dummy0/192.168.1.1" ],
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 1000
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/dhcp4.leases"
},
"subnet4": [
{
"subnet": "192.168.1.0/24",
"interface": "dummy0",
"pools": [
{
"pool": "192.168.1.4 - 192.168.1.254",
}
]
}
]
}
}
3. At this point Kea will print `DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface dummy0 is down` messages.
4. Add another interface with
`ip link add dummy1 type dummy`
`ip addr add 10.10.1.1/24 dev dummy1`
`ip link set dummy1 up`
5. Set dummy0 online to let Kea run
`ip link set dummy1 up`
6. Check open sockets by Kea
`netstat -tulpan | grep kea` which is
udp 0 0 192.168.1.1:67 0.0.0.0:* 694387/kea-dhcp4
udp 0 0 10.10.1.1:67 0.0.0.0:* 694387/kea-dhcp4
**Expected behavior**
Server should only listen _dummy0_ interface.
**Environment:**
- Kea version: 2.2.0
- OS: Ubuntu 22.04.3 x64
**Additional Information**
This issue happened also on our custom yocto build on imx8qxp with aarch64next-stable-2.6https://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.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/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/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/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.6