Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2022-11-02T15:08:42Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/266ISC DHCP release on roam flag2022-11-02T15:08:42ZFrancis DupontISC DHCP release on roam flag>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on t...>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on the old network and emit a log statement
similiar to the following:
"Client: <id> roamed to new network, releasing lease:
<address>"
The server will carry out all of the same steps that would nor-
mally occur when a client explicitly releases a lease. When
release-on-roam is disabled (the default) the server makes such
leases unavailable until they expire or the server is restarted.
Clients that need leases in multiple networks must supply a
unique IAID in each IA. This parameter may only be specified at
the global level.
>>>
Make sense for a moving client which for some reasons does not release its address at the previous location. Can be implemented in Kea if there is an easy and fast way to get leases by IAID+DUID only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/269client_encoding in PostgreSQL connection2022-11-02T15:08:44ZGhost Userclient_encoding in PostgreSQL connection---
name: client_encoding in PostgreSQL connection
about: Make connection's client_encoding configurable
---
**Related problem**
Sometimes it is impossible to execute lease{4,6}_{update,insert} SQLs in configuration with PostgreSQL dat...---
name: client_encoding in PostgreSQL connection
about: Make connection's client_encoding configurable
---
**Related problem**
Sometimes it is impossible to execute lease{4,6}_{update,insert} SQLs in configuration with PostgreSQL database created with default UTF8 encoding and default server's encoding set to UTF8. This is because some DHCP clients are not fully compatible with RFC1035 and are using 8-bit ASCII codes in hostname options. This, in case, results in errors like '2018-11-12 23:36:44.762 ERROR [kea-dhcp4.alloc-engine/30224] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 a0:f3:c1:9d:33:d5], cid=[01:a0:f3:c1:9d:33:d5], tid=0x55527316: error during attempt to allocate an IPv4 address: Statement exec failed: for: update_lease4, status: 7sqlstate:[ 22021], reason: ERROR: invalid byte sequence for encoding "UTF8": 0xc0 0x90'
**Solution**
One possible solution is to change "client_encoding" connection parameter to "latin1" value. This eliminates problem of PostgreSQL's parsing such problematic string as UTF8 string and makes it possible to store hostname value "as is".
To make this connection parameter configurable, I've added configuration parameter "client-encoding" visible in LEASE_DATABASE, HOSTS_DATABASE and CONFIG_DATABASE scopes.
I've attached the patch against today's master branch of repo.
I can also make a pull request, if you need it
Also, I can backport this patch to 1.4.0 and 1.5.0 version, because it fixes some possible problems
[client_encoding_master.patch](/uploads/db18cf7ffa25ca65bbfaa1a825cf73ca/client_encoding_master.patch)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/272selecting listening port by -p in dhcp4 does not work2022-11-02T15:08:42ZMichal Nowikowskiselecting listening port by -p in dhcp4 does not workbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/290Arguments/parameters for hooks and commands are not checked2023-02-25T19:27:17ZFrancis DupontArguments/parameters for hooks and commands are not checkedChild of #229 for all hooks.Child of #229 for all hooks.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/301Report a hook DSO version when it is loaded2022-11-02T15:08:41ZThomas MarkwalderReport a hook DSO version when it is loadedIt would be useful, if Hook DSO versions were emitted when they are loaded, or if they were included in response to the version report command.It would be useful, if Hook DSO versions were emitted when they are loaded, or if they were included in response to the version report command.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/304poc: replace autotools with meson2022-11-02T15:08:40ZMichal Nowikowskipoc: replace autotools with mesonbacklogMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/307queue by list of packets rather than one by one2022-11-02T15:08:44ZThomas Markwalderqueue by list of packets rather than one by oneI have created a branch which greatly simplifies the PacketQueue<> interface to provide implementations with much more latitude. Lower level functions, such as push, peek, and pop were moved down into PacketQueueRing<> (the default impl...I have created a branch which greatly simplifies the PacketQueue<> interface to provide implementations with much more latitude. Lower level functions, such as push, peek, and pop were moved down into PacketQueueRing<> (the default implementation base). It also replaces queuing a single packet, to queuing a list of packets. The latter change should reduce thread contention by enabling the receiving thread to read all ready packets and pass them into the queue in one call. Lastly, I split out the PacketQueueRing<> from dhcp/packet_queue.h into its own header, dhcp/packet_queue_ring.hbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/311Subnet selection via client class failing when using shared network2022-11-02T15:25:01ZHreidar JoelssonSubnet selection via client class failing when using shared networkHi, I have been working on a hook for KEA which purpose is to dictate from which subnet a client should get an IP lease from. My early assumptions about KEA led me to build my code around making a selection using the subnet4_select callo...Hi, I have been working on a hook for KEA which purpose is to dictate from which subnet a client should get an IP lease from. My early assumptions about KEA led me to build my code around making a selection using the subnet4_select callout but I quickly got stuck with my work as there is a mechanism in KEA that overwrites your choice if the device has already had a lease from another subnet in the same shared network. I have been told that I shouldn't be using shared network if I like to use subnet4_select callout but I do need to use this feature as the services we provide on our network can have multiple logical IP subnets on the same physical link. So I edited my code so it is using client class instead. In pkt4_receive I'm using a policy, from an external source, which tells my code if the query should be marked with the "restricted" or the "unrestricted" class. The problem now is that KEA only allows devices marked with the "restricted" class to get a lease but logs out a "DHCP4_SUBNET_SELECTION_FAILED" log message for the other class. I can't understand why this is happening because there is no real difference between these two subnet configurations in KEA. The only thing that is different is how the physical link on the Cisco switch is configured.
I'm currently using KEA 1.4.0-P1
Physical link config:
```
interface BVI101
description GR-TEST
mtu 9216
vrf GR-TEST
ipv4 address 10.206.0.3 255.255.252.0
ipv4 address 192.168.30.3 255.255.255.0 secondary
arp timeout 300
ipv4 unreachables disable
```
Partial KEA config:
```
{
"Dhcp4": {
"client-classes": [
{
"name": "restricted"
},
{
"name": "unrestricted"
}
],
"shared-networks": [
{
"match-client-id": true,
"name": "GR-Internet-AG06",
"option-data": [ ],
"reservation-mode": "all",
"subnet4": [
{
"id": 1,
"match-client-id": true,
"next-server": "0.0.0.0",
"option-data": [
{
"always-send": false,
"code": 3,
"csv-format": true,
"data": "10.206.0.1",
"name": "routers",
"space": "dhcp4"
}
],
"pools": [
{
"option-data": [ ],
"pool": "10.206.0.4-10.206.3.254"
}
],
"rebind-timer": 300,
"renew-timer": 150,
"subnet": "10.206.0.0/22",
"valid-lifetime": 600,
"client-class": "restricted"
},
{
"id": 2,
"match-client-id": true,
"next-server": "0.0.0.0",
"option-data": [
{
"always-send": false,
"code": 3,
"csv-format": true,
"data": "192.168.30.1",
"name": "routers",
"space": "dhcp4"
}
],
"pools": [
{
"option-data": [ ],
"pool": "192.168.30.4-192.168.30.248"
}
],
"rebind-timer": 300,
"renew-timer": 150,
"subnet": "192.168.30.0/24",
"valid-lifetime": 600,
"client-class": "unrestricted"
}
]
}
]
...
}
}
```
I'm adding the class in the pkt4_receive callout like so:
```
query->addClass(ClientClass("restricted"));
// or
query->addClass(ClientClass("unrestricted"));
```
kea-dhcp4.log when query is markt with "restricted" class:
```
2018-12-04 14:05:11.220 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_RECEIVED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: DHCPDISCOVER (type 1) received from 10.206.0.2 to 192.168.15.80 on interface ens33
2018-12-04 14:05:11.220 DEBUG [kea-dhcp4.packets/1] DHCP4_QUERY_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b, packet details: local_address=192.168.15.80:67, remote_address=10.206.0.2:67, msg_type=DHCPDISCOVER (1), transid=0x848b28b,
options:
type=050, len=004: 192.168.30.4 (ipv4-address)
type=053, len=001: 1 (uint8)
type=055, len=024: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8) 6(uint8) 7(uint8) 8(uint8) 9(uint8) 15(uint8) 17(uint8) 28(uint8) 42(uint8) 43(uint8) 44(uint8) 66(uint8) 67(uint8) 120(uint8) 121(uint8) 77(uint8) 250(uint8) 58(uint8) 59(uint8) 212(uint8)
type=060, len=027: "uDHCP HG659V100R001C279B010" (string)
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=077, len=002: 01:68
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
type=116, len=001: 1 (uint8)
2018-12-04 14:05:11.220 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7f8a31587723 (callout duration: 5.385 ms)
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 5.385 ms)
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.206.0.0/22 for packet received by matching address 10.206.0.2
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook subnet4_select
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook subnet4_select that has address 0x7f8a31588fbd (callout duration: 0.335 ms)
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook subnet4_select (total callouts duration: 0.335 ms)
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_SELECTED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: the subnet with ID 9060101 was selected for client assignments
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: the selected subnet details: 10.206.0.0/22
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: client packet has been assigned to the following class(es): UNKNOWN
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_uDHCP HG659V100R001C279B010, restricted, UNKNOWN
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: processing client's Hostname option
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:50:a7:2b:ea:cc:e3
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 50:a7:2b:ea:cc:e3
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.alloc-engine/1] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.5
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook lease4_select
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook lease4_select that has address 0x7f8a3158939d (callout duration: 0.387 ms)
2018-12-04 14:05:11.229 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook lease4_select (total callouts duration: 0.387 ms)
2018-12-04 14:05:11.229 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.5
2018-12-04 14:05:11.229 INFO [kea-dhcp4.leases/1] DHCP4_LEASE_ADVERT [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: lease 10.206.0.5 will be advertised
2018-12-04 14:05:11.229 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_send
2018-12-04 14:05:11.229 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_send that has address 0x7f8a31588987 (callout duration: 0.346 ms)
2018-12-04 14:05:11.230 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_send (total callouts duration: 0.346 ms)
2018-12-04 14:05:11.230 DEBUG [kea-dhcp4.options/1] DHCP4_PACKET_PACK [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: preparing on-wire format of the packet to be sent
2018-12-04 14:05:11.230 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_SEND [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: trying to send packet DHCPOFFER (type 2) from 192.168.15.80:67 to 10.206.0.2:67 on interface ens33
2018-12-04 14:05:11.230 DEBUG [kea-dhcp4.packets/1] DHCP4_RESPONSE_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: responding with packet DHCPOFFER (type 2), packet details: local_address=192.168.15.80:67, remote_address=10.206.0.2:67, msg_type=DHCPOFFER (2), transid=0x848b28b,
options:
type=001, len=004: 4294966272 (uint32)
type=003, len=004: 10.206.0.1
type=006, len=008: 192.168.0.1 192.168.0.33
type=015, len=013: "gagnaveita.is" (string)
type=051, len=004: 60 (uint32)
type=053, len=001: 2 (uint8)
type=054, len=004: 192.168.15.80
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.packets/1] DHCP4_BUFFER_RECEIVED received buffer from 10.206.0.2:67 to 192.168.15.80:67 over interface ens33
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.options/1] DHCP4_BUFFER_UNPACK parsing buffer received from 10.206.0.2 to 192.168.15.80 over interface ens33
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_RECEIVED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: DHCPREQUEST (type 3) received from 10.206.0.2 to 192.168.15.80 on interface ens33
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.packets/1] DHCP4_QUERY_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b, packet details: local_address=192.168.15.80:67, remote_address=10.206.0.2:67, msg_type=DHCPREQUEST (3), transid=0x848b28b,
options:
type=050, len=004: 10.206.0.4 (ipv4-address)
type=053, len=001: 3 (uint8)
type=054, len=004: 192.168.15.80 (ipv4-address)
type=055, len=024: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8) 6(uint8) 7(uint8) 8(uint8) 9(uint8) 15(uint8) 17(uint8) 28(uint8) 42(uint8) 43(uint8) 44(uint8) 66(uint8) 67(uint8) 120(uint8) 121(uint8) 77(uint8) 250(uint8) 58(uint8) 59(uint8) 212(uint8)
type=060, len=027: "uDHCP HG659V100R001C279B010" (string)
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2018-12-04 14:05:11.236 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7f8a31587723 (callout duration: 4.628 ms)
2018-12-04 14:05:11.236 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 4.628 ms)
2018-12-04 14:05:11.236 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.206.0.0/22 for packet received by matching address 10.206.0.2
2018-12-04 14:05:11.236 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook subnet4_select
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook subnet4_select that has address 0x7f8a31588fbd (callout duration: 0.307 ms)
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook subnet4_select (total callouts duration: 0.307 ms)
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_SELECTED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: the subnet with ID 9060101 was selected for client assignments
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: the selected subnet details: 10.206.0.0/22
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: client packet has been assigned to the following class(es): UNKNOWN
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_uDHCP HG659V100R001C279B010, restricted, UNKNOWN
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: processing client's Hostname option
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:50:a7:2b:ea:cc:e3
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 50:a7:2b:ea:cc:e3
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.4
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.alloc-engine/1] ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: trying to allocate requested address 10.206.0.4
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.4
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook lease4_select
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook lease4_select that has address 0x7f8a3158939d (callout duration: 0.441 ms)
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook lease4_select (total callouts duration: 0.441 ms)
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_ADD_ADDR4 adding IPv4 lease with address 10.206.0.4
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.4
2018-12-04 14:05:11.239 INFO [kea-dhcp4.leases/1] DHCP4_LEASE_ALLOC [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: lease 10.206.0.4 has been allocated
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
2018-12-04 14:05:11.255 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook leases4_committed that has address 0x7f8a3158a0a3 (callout duration: 15.466 ms)
2018-12-04 14:05:11.255 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook leases4_committed (total callouts duration: 15.466 ms)
2018-12-04 14:05:11.255 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_send
2018-12-04 14:05:11.255 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_send that has address 0x7f8a31588987 (callout duration: 0.298 ms)
2018-12-04 14:05:11.256 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_send (total callouts duration: 0.298 ms)
2018-12-04 14:05:11.257 DEBUG [kea-dhcp4.options/1] DHCP4_PACKET_PACK [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: preparing on-wire format of the packet to be sent
2018-12-04 14:05:11.257 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_SEND [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: trying to send packet DHCPACK (type 5) from 192.168.15.80:67 to 10.206.0.2:67 on interface ens33
2018-12-04 14:05:11.257 DEBUG [kea-dhcp4.packets/1] DHCP4_RESPONSE_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: responding with packet DHCPACK (type 5), packet details: local_address=192.168.15.80:67, remote_address=10.206.0.2:67, msg_type=DHCPACK (5), transid=0x848b28b,
options:
type=001, len=004: 4294966272 (uint32)
type=003, len=004: 10.206.0.1
type=006, len=008: 192.168.0.1 192.168.0.33
type=015, len=013: "gagnaveita.is" (string)
type=051, len=004: 60 (uint32)
type=053, len=001: 5 (uint8)
type=054, len=004: 192.168.15.80
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
```
kea-dhcp4.log when query is markt with "unrestricted" class:
```
2018-12-04 14:11:27.327 DEBUG [kea-dhcp4.packets/1] DHCP4_BUFFER_RECEIVED received buffer from 10.206.0.3:67 to 192.168.15.80:67 over interface ens33
2018-12-04 14:11:27.327 DEBUG [kea-dhcp4.options/1] DHCP4_BUFFER_UNPACK parsing buffer received from 10.206.0.3 to 192.168.15.80 over interface ens33
2018-12-04 14:11:27.328 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_RECEIVED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: DHCPDISCOVER (type 1) received from 10.206.0.3 to 192.168.15.80 on interface ens33
2018-12-04 14:11:27.329 DEBUG [kea-dhcp4.packets/1] DHCP4_QUERY_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef, packet details: local_address=192.168.15.80:67, remote_address=10.206.0.3:67, msg_type=DHCPDISCOVER (1), transid=0x5b0501ef,
options:
type=050, len=004: 192.168.30.4 (ipv4-address)
type=053, len=001: 1 (uint8)
type=055, len=024: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8) 6(uint8) 7(uint8) 8(uint8) 9(uint8) 15(uint8) 17(uint8) 28(uint8) 42(uint8) 43(uint8) 44(uint8) 66(uint8) 67(uint8) 120(uint8) 121(uint8) 77(uint8) 250(uint8) 58(uint8) 59(uint8) 212(uint8)
type=060, len=027: "uDHCP HG659V100R001C279B010" (string)
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=077, len=002: 01:68
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
type=116, len=001: 1 (uint8)
2018-12-04 14:11:27.329 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2018-12-04 14:11:27.349 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7ff7b76a8723 (callout duration: 20.561 ms)
2018-12-04 14:11:27.350 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 20.561 ms)
2018-12-04 14:11:27.350 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook subnet4_select
2018-12-04 14:11:27.351 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook subnet4_select that has address 0x7ff7b76a9fbd (callout duration: 1.099 ms)
2018-12-04 14:11:27.351 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook subnet4_select (total callouts duration: 1.099 ms)
2018-12-04 14:11:27.352 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: failed to select subnet for the client
2018-12-04 14:11:27.352 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: client packet has been assigned to the following class(es): UNKNOWN
2018-12-04 14:11:27.353 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_uDHCP HG659V100R001C279B010, unrestricted, UNKNOWN
2018-12-04 14:11:27.353 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: processing client's Hostname option
2018-12-04 14:11:27.353 ERROR [kea-dhcp4.bad-packets/1] DHCP4_PACKET_NAK_0001 [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: failed to select a subnet for incoming packet, src 10.206.0.3, type DHCPDISCOVER
```
I hope someone can shed light on this issue as it seems that I'm getting out of options using KEA as a soulution for my problem.
best regards, Hreidar.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/316Update DHCPv6 server to fully support RFC7550 (obsoleted by RFC 8415)2022-11-02T15:08:41ZMarcin SiodelskiUpdate DHCPv6 server to fully support RFC7550 (obsoleted by RFC 8415)While addressing https://gitlab.isc.org/isc-projects/kea/issues/288 I realized that DHCPv6 server logic follows rather simplified approach when it comes to Renew/Rebind processing. The following is the todo comment inserted as part of th...While addressing https://gitlab.isc.org/isc-projects/kea/issues/288 I realized that DHCPv6 server logic follows rather simplified approach when it comes to Renew/Rebind processing. The following is the todo comment inserted as part of the #288:
We should consider unification of the server behavior for address assignment and prefix delegation with respect to Rebind message processing. The RFC 8415, section 18.3.5 doesn't really differentiate between IA_NA and IA_PD in how they should be processed by the server. The intention of the spec is as follows:
- If the server finds a lease but addresses and/or prefixes are not
appropriate anymore, it sends them with zero lifetimes.
- If the server doesn't find a lease the server checks if the addresses
and/or prefixes the client sends are appropriate and sends them back
with zero lifetimes if they aren't.
- The server may choose to not respond at all, if it cannot determine
whether the addresses and/or prefixes are appropriate and it doesn't
allocate any other addresses and/or prefixes.
- If the server cannot find the leases included in the Rebind, the
server may either allocate the leases or simply return NoBinding.
The extendIA_PD function drops the Rebind message if it cannot find the client entry (as a result of not finding a subnet for the client), the extendIA_NA function sends NoBinding status code in that case. Perhaps we should introduce an "Authoritative" configuration flag which, if enabled, would cause the server to always respond, either indicating that the address/prefix is inappropriate (with zero lifetimes) or that there is no binding (NoBinding status code) for both addresses and prefixes. When the "Authoritative" flag is disabled the server would drop the Rebind for which there is neither subnet selected nor client entry found (as it could be handled by another DHCP server). If nothing else we could consider unifying the behavior of extendIA_NA and extendIA_PD with respect to Rebind processing.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/321Make it possible to start the server without all the configured interfaces re...2024-02-08T14:36:54ZVicky Riskvicky@isc.orgMake it possible to start the server without all the configured interfaces ready (GH#91)<Originally reported on Github as issue #91 by karaluh on July 6, 2018>
Dibbler has an "inactive-mode" option, which works like this, according to the official docs:
During normal startup, client tries to bind all interfaces defined in...<Originally reported on Github as issue #91 by karaluh on July 6, 2018>
Dibbler has an "inactive-mode" option, which works like this, according to the official docs:
During normal startup, client tries to bind all interfaces defined in a configuration file. If such attempt
fails, client reports an error and gives up. Usually that is best action. However, in some cases it is possible that interface is not ready yet, e.g. WLAN interface did not complete association. Dibbler attempt to detect link-local addresses, bind any sockets or initiate any kind of communication will fail. To work around this disadvantage, a new mode has been introduced in the 0.6.0RC4 version. It is possible to modify client behavior, so it will accept downed and not running interfaces. To do so, inactive-mode
keyword must be added to client.conf file. In this mode, client will accept inactive interfaces, will add
them to inactive list and will periodically monitor its state. When the interface finally goes on-line, client
will try to configure it."
My use case is PD over PPP interfaces which come and go as they please during the server process lifetime and mostly aren't there when the server starts.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/322Time of issue of ip address (permanent IP assignment)2022-11-02T15:08:43ZVicky Riskvicky@isc.orgTime of issue of ip address (permanent IP assignment)<Originally reported on Github as issue \# 90 by PBA4 on July 2, 2018.>
It is not possible to issue a permanent ip address to the user. In the RFC, it is said that the leases-time can be set to -1, thereby reserving the IP address of th...<Originally reported on Github as issue \# 90 by PBA4 on July 2, 2018.>
It is not possible to issue a permanent ip address to the user. In the RFC, it is said that the leases-time can be set to -1, thereby reserving the IP address of the user by the user, but this does not work and kea talks about the error. I store ip addresses in the mysql. How can I make the addresses reserved after the issue?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/325Implement RDM mechanism (Github#85)2022-11-02T15:08:41ZVicky Riskvicky@isc.orgImplement RDM mechanism (Github#85)<Originally opened by Tomek Mrugalski on Github as issue #85>
The RFC8415 defines Replay Detection Mechanism. We need to have this implemented in Kea.
We'll go with the simplest model possible. The RDM will be a global 64bits counter (...<Originally opened by Tomek Mrugalski on Github as issue #85>
The RFC8415 defines Replay Detection Mechanism. We need to have this implemented in Kea.
We'll go with the simplest model possible. The RDM will be a global 64bits counter (the same value for all subnets and all clients. This value must be retained between server restarts.backlog2020-02-29https://gitlab.isc.org/isc-projects/kea/-/issues/326Handle Reconfigure Accept Option #872023-05-30T11:04:20ZVicky Riskvicky@isc.orgHandle Reconfigure Accept Option #87Mayya Sunil opened on Github as issue #87 on June 1, 2018
Reconfigure Accept Option : Included in Server's Replies, Advertise message and client's Solicit, Request, Renew, Rebind, Information Request to announce support of Reconfigure f...Mayya Sunil opened on Github as issue #87 on June 1, 2018
Reconfigure Accept Option : Included in Server's Replies, Advertise message and client's Solicit, Request, Renew, Rebind, Information Request to announce support of Reconfigure feature.
This issue involves 2 tasks
Include the option in the server's outgoing message.
2)Parse the option in the client's message and generate and store the keys in the reservation if keys not available.
----------
MayyaSunil pushed a commit to MayyaSunil/kea that referenced this issue on Aug 14
[store_client_context] Stotes client info in user contexts …
a09944dnext-stable-2.62020-02-29https://gitlab.isc.org/isc-projects/kea/-/issues/328Using a model which is installed but unknown.2022-11-02T15:08:42ZFrancis DupontUsing a model which is installed but unknown.This issue is about the third case in this method called with the model for a managed server entry:
```
bool
NetconfAgent::checkModule(const string& module_name) const {
if (module_name.empty()) {
return (true);
}
auto modul...This issue is about the third case in this method called with the model for a managed server entry:
```
bool
NetconfAgent::checkModule(const string& module_name) const {
if (module_name.empty()) {
return (true);
}
auto module = modules_.find(module_name);
if (module == modules_.end()) {
LOG_ERROR(netconf_logger, NETCONF_MODULE_MISSING_ERR)
.arg(module_name);
return (false);
}
auto modrev = YANG_REVISIONS.find(module_name);
if (modrev == YANG_REVISIONS.end()) {
// Can't check revision?!
// It can happen only with a module which is not in
// YANG_REVISIONS but installed so likely on purpose.
return (true);
}
if (modrev->second != module->second) {
LOG_ERROR(netconf_logger, NETCONF_MODULE_REVISION_ERR)
.arg(module_name)
.arg(modrev->second)
.arg(module->second);
return (false);
}
return (true);
}
```
Tomek requested a warning, I added the comment after ```Can't check revision?!``` and answered:
No warning. In fact it means the module is installed but is not in yang revisions so either it is on purpose and the check was simply disabled, or it is a real error and the translator will raise a better error.
I am creating an issue in the case a better option could be found.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/329Add a verbose flag to developer YANG module check scripts.2022-11-02T15:08:43ZFrancis DupontAdd a verbose flag to developer YANG module check scripts.Add a verbose flag to `src/share/yang/modules/utils/check-{hashes, revisions}.sh`.
cf #204Add a verbose flag to `src/share/yang/modules/utils/check-{hashes, revisions}.sh`.
cf #204backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/330keactrl should better handle disabled services2022-11-02T15:24:12ZTomek Mrugalskikeactrl should better handle disabled servicesThis is a follow-up coming form #186 review.
There's a section in keactrl.conf that has flags for each daemon:
```
# Start DHCPv4 server?
dhcp4=yes
# Start DHCPv6 server?
dhcp6=yes
# Start DHCP DDNS server?
dhcp_ddns=no
# Start Contr...This is a follow-up coming form #186 review.
There's a section in keactrl.conf that has flags for each daemon:
```
# Start DHCPv4 server?
dhcp4=yes
# Start DHCPv6 server?
dhcp6=yes
# Start DHCP DDNS server?
dhcp_ddns=no
# Start Control Agent?
ctrl_agent=yes
# Start Netconf?
netconf=no
```
When a service is set to false, there's no way to start it using keactrl. For example:
```
root@billabong:/opt186# sbin/keactrl start -s netconf
root@billabong:/opt186# sbin/keactrl stop -s netconf
INFO/keactrl: kea-netconf isn't running.
```
Note the start command. It quits silently without starting the netconf service.
IMHO the flags should govern whether the service is started when ALL services are started (keactrl start). There should always be a way to start the service manually.
If you strongly disagree with this, at the very least keactrl should print out why it didn't even try to start the service.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/331kea-netconf should print out control channel being opened2022-11-02T15:08:42ZTomek Mrugalskikea-netconf should print out control channel being openedWhile reviewing !163 I've tried to start kea-netconf without dhcp4 or dhcp6 running. The error message I got was confusing. It was clear that some file is missing, but it was never said which file:
```
2018-12-10 19:40:24.202 INFO [kea...While reviewing !163 I've tried to start kea-netconf without dhcp4 or dhcp6 running. The error message I got was confusing. It was clear that some file is missing, but it was never said which file:
```
2018-12-10 19:40:24.202 INFO [kea-netconf.netconf/29469] NETCONF_STARTED Netconf (version 1.5.0-beta2-git) started
2018-12-10 19:40:24.203 INFO [kea-netconf.netconf/29469] NETCONF_GET_CONFIG_STARTED getting configuration from dhcp4 server
2018-12-10 19:40:24.203 ERROR [kea-netconf.netconf/29469] NETCONF_GET_CONFIG_FAILED getting configuration from dhcp4 server failed: config-get command failed with communication error: No such file or directory
2018-12-10 19:40:24.203 INFO [kea-netconf.netconf/29469] NETCONF_GET_CONFIG_STARTED getting configuration from dhcp6 server
2018-12-10 19:40:24.203 ERROR [kea-netconf.netconf/29469] NETCONF_GET_CONFIG_FAILED getting configuration from dhcp6 server failed: config-get command failed with communication error: No such file or directory
2018-12-10 19:40:24.203 INFO [kea-netconf.netconf/29469] NETCONF_SET_CONFIG_STARTED setting configuration to dhcp4 server
2018-12-10 19:40:24.217 DEBUG [kea-netconf.netconf/29469] NETCONF_SET_CONFIG set configuration to dhcp4 server: {
"Dhcp4": { }
}
2018-12-10 19:40:24.217 ERROR [kea-netconf.netconf/29469] NETCONF_SET_CONFIG_FAILED setting configuration to dhcp4 server failed: config-set command failed with communication error: No such file or directory
2018-12-10 19:40:24.217 INFO [kea-netconf.netconf/29469] NETCONF_SUBSCRIBE_CONFIG subscribing configuration changes for dhcp4 server with kea-dhcp4-server module
2018-12-10 19:40:24.229 INFO [kea-netconf.netconf/29469] NETCONF_SET_CONFIG_STARTED setting configuration to dhcp6 server
2018-12-10 19:40:24.243 DEBUG [kea-netconf.netconf/29469] NETCONF_SET_CONFIG set configuration to dhcp6 server: {
"Dhcp6": { }
}
2018-12-10 19:40:24.243 ERROR [kea-netconf.netconf/29469] NETCONF_SET_CONFIG_FAILED setting configuration to dhcp6 server failed: config-set command failed with communication error: No such file or directory
```
IMHO the netconf daemon should print out unix socket path/http URL on info level. This would be on par with what dhcp4/6 does, it prints the unix socket path when opening control channel:
```
COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea-dhcp4-ctrl.sock
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/332strip down version of unpack2022-11-02T15:08:42ZFrancis Dupontstrip down version of unpackIn some cases we need only the message type and not to decode all options, for instance for advanced receiver queueing or for perfdhcp.
So the idea is to have a fast clone of unpack which digs into a received query to get the message ty...In some cases we need only the message type and not to decode all options, for instance for advanced receiver queueing or for perfdhcp.
So the idea is to have a fast clone of unpack which digs into a received query to get the message type and perhaps for DHCPv6 the rapid commit option.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/333parser libraries for servers (for netconf)2022-11-02T15:24:02ZFrancis Dupontparser libraries for servers (for netconf)Build in DHCPv4 and DHCPv6 (at least) Makefiles a convenience library with the parser so a tool which just needs to parse a DHCPv4 (or DHCPv6) configuration including comments and includes can link with this library and calls a parse* me...Build in DHCPv4 and DHCPv6 (at least) Makefiles a convenience library with the parser so a tool which just needs to parse a DHCPv4 (or DHCPv6) configuration including comments and includes can link with this library and calls a parse* method to get a syntactic correct Element.
I have an use for this in netconf to port and improve a to-yang tool which translates such config to YANG and loads it to sysrepo datastore. IMHO config backend should use this too.outstanding