Changing the MAC address on a Kea static lease does not work
-
I think this is a bug but I'm conflicted whether it's Kea's bug or pfSense's bug.
I recently installed a new network card in one of my machines that currently has a static lease in Kea for the old network card. I grabbed the MAC address of the new card, edited my static lease in pfSense to change it to the new MAC address, and then moved the cable from the old network card to the new network card. I was then served a new DHCP lease from Kea from the available addresses in the pool, not my static lease. Tried restarting Kea, no difference.
My lease configuration contains a MAC address, an IP address and hostname only. No client identifier (I thought that was the problem at first, turned out not to be as asking Kea to ignore client identifiers also made no difference).
Consulting the Kea log, I saw:
WARN [kea-dhcp4.alloc-engine.0x218397417400] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 30:13:8b:79:56:af], cid=[01:30:13:8b:79:56:46], tid=0x65b2ee64: conflicting reservation for address 10.6.0.4 with existing lease Address: 10.6.0.4 Valid life: 7200 Cltt: 1752320340 Hardware addr: e0:73:e7:c6:6a:24 Client id: 01:e0:73:e7:c6:6a:31 Subnet ID: 1 Pool ID: 0 State: default Relay ID: (none) Remote ID: (none)So Kea wouldn't serve 10.6.0.4 to me because it thought it was still active as it hadn't expired yet.
I stopped Kea (not sure if required or not, but belt and braces), edited/var/lib/kea/dhcp4.leasesto remove the two entries for 10.6.0.4 referencing the old MAC, started Kea again and then finally got the expected address served from DHCP.Not sure whether the bug here is in Kea or in pfSense.
On one hand, Kea's static lease config now says $newMAC should be served 10.6.0.4. There's an active lease on $oldMAC to 10.6.0.4. This IP is outside the pool so will only have been given out from a static lease. That old static lease no longer exists in it's config, so why wouldn't Kea clear the active lease and hand out the IP to the new MAC? The sysadmin has changed the static lease config and so if they do so while the old MAC is online and thus cause an IP conflict, how is this any different to the sysadmin setting a static IP on both systems, plugging them into the network and causing an IP conflict? Don't do that.
On the other hand, if I'm changing a static lease, maybe from Kea's perspective it's reasonable to also clear the active lease from the leases file. In which case as I'm using pfSense, not managing Kea directly myself, I would expect pfSense to remove reservations matching the old MAC/IP pair from the leases file when I modified the static lease in the UI to change the MAC address. By editing the reservation, it's clear I want it to take effect now, instead of waiting for the lease to expire. I don't think having to SSH in and manually edit system files the 'right' way to do things in pfSense.
-
Running into this exact same problem today on the very latest 25.11.1-RELEASE. I had an existing static DHCP entry that I wanted to modify. I edited the old MAC address to the MAC address of the new device. The new device would not get an IP address no matter what. Got the same kind of
ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICTerror as @jamie above. I switched from Kea to ISC and then it worked just fine. -
@jamie said in Changing the MAC address on a Kea static lease does not work:
So Kea wouldn't serve 10.6.0.4 to me because it thought it was still active as it hadn't expired yet.
I stopped Kea (not sure if required or not, but belt and braces), edited /var/lib/kea/dhcp4.leases to remove the two entries for 10.6.0.4 referencing the old MAC, started Kea again and then finally got the expected address served from DHCP.Not sure whether the bug here is in Kea or in pfSense.
Neither
Everything is respecting the RFC here.
Let's say it's the admin .... ;)When you install a new NIC, connect it and you'll see it will get a lease (IP) out of the DHCP pool.
No static MAC lease will be used , as the MAC has changed. For pfSense (kea) : this is another device.
Now you can see the current lease in the pool, you can see the new mac.
Copy the MAC, and edit the static lease setting of this device -and paste there the new MAC.You might have to visit Status >DHCP Leases and see if you can delete leases that are related to the old and new MAC (device).
Worse case scenario, it has happened I did this : first stop kea, and then delete the /var/lib/kea/dhcp4.leases file (and the backup file in the same folder).
Start kea.
Done ^^The 'perfect' way to handle changing NIC == changing MAC address :
Open the box with the new NIC.
Note down MAC and or copy paste into the existing MAC dhcpv4 lease setting in pfSense (kea).
Power down the device, swap the NIC, power up and connect.
You'll see : the device will get the same IP as before. -
@Gertjan said in Changing the MAC address on a Kea static lease does not work:
You might have to visit Status >DHCP Leases and see if you can delete leases that are related to the old and new MAC (device).
Worse case scenario, it has happened I did this : first stop kea, and then delete the /var/lib/kea/dhcp4.leases file (and the backup file in the same folder).
Start kea.
Done ^^This is the core issue and where a bug clearly exists, either in Kea or in pfSense. One should never have to manually delete the leases file for a simple operation like this. Leases ought to be fully controllable from the UI.
-
Example :
these are 3 ordinary 'pool' leases.
The last one is, according to pfSense (kea) not active right. To be more precise : pfSense doesn't have a valid ARP info in it's cache, so this device didn't communicate with pfSense for the last ... 20 minutes or so ?
In that case, the waste bin (most right) is shown to delete the lease.The first two leases are active (== ARP info exists) so that lease can't be deleted.
Remember : DHCP, ones a lease is created, it has to go to its end. Neither the server or the client can DE-ALLOCATE (delete) a lease.Static MAC leases can be deleted on the Status > DHCP Leases page, but you can delete or edit them here :
so, imho, everything is there to deal with the issue.
I mentioned the "Worse case scenario" as I've nearly always an SSH connection open to pfSense, and things can be forced 'with a keyboard' 'way faster'.
The GUI permits you to do the same thing.
Important is : things have to be done in the right order.Something I haven't tested :
If a device with a static MAC lease has been set up, and a lease has been allocated, what happens when you change the MAC in the static lease setting ?
The device with the new MAC comes online, and the dhcp server will allocate the static lease, but ... it has already an outstanding lease (se the leases file) with that same IP, using another (the previous MAC).
I can image kea will refuse, as the IP is already allocated.
A lease delay time out will deal with the situation, but maybe you don't want to wait that long
And again, a DHCP server can't abort a lease.So, still me thinking out loud, maybe you have an issue - and it happens when you use static mac leases and change NICs.
=> How often does that happen IRL ? -
@Gertjan said in Changing the MAC address on a Kea static lease does not work:
So, still me thinking out loud, maybe you have an issue - and it happens when you use static mac leases and change NICs.
=> How often does that happen IRL ?We actually do this relatively frequently! Some client devices have static DHCP assignments. When those users get a new device, we update the MAC address in the static DHCP entry and their new device gets that IP. I suspect this is not an uncommon practice. We've been doing this for nearly two decades now with pfSense using ISC. It is only when switching to Kea that this problem presented itself.
-
@Gertjan I disagree, I think there are a few reasons this is a bug:
- undesirable behaviour change between ISC and Kea, which admins are not expecting (two perfect examples here in this thread)
- editing/deleting a file manually over SSH on a firewall for something as trivial as updating a DHCP lease should not be required, I do not know of any other firewall vendor that requires their admins to do that
- the trash icon on a DHCP lease takes some time to show after the old MAC goes offline, assuming the old MAC does indeed go offline
- the trash icon would never appear if you were swapping the reservation from one NIC to another on the same machine
-
@jamie said in Changing the MAC address on a Kea static lease does not work:
undesirable behaviour ...
I'm not there to defend 'kea', or imply ISC DHCP is better/worse
kea and ISC DHCP have the same author, written by the same guys.
Without proof, I think that ISC wouldn't rewrite ISC DHCP into kea and break existing RFCs.
They needed to rewrite - see their own web site for the exact motivation, because ISC DHCP became 'a mess'.@jamie said in Changing the MAC address on a Kea static lease does not work:
editing/deleting a file manually over SSH
I fully agree with that. If deleting that file is/was the only solution, then there should be a pfSense GUI DHCP server button that stops the server, deletes the leases file, and starts the server again. This lease file is the persistent 'memory' of the DHCP server.
That said, deleting the DHCP server database file is something that isn't limited to kea.
I have the forum to proof it : it was always some sort of 'last' resort solution - also for ISC DHCP.
Again, not a clean solution, I get that.It becomes 'deletable' as soon as the reference of the IP is remove from the local pfSense ARP cache. This is a (pfSense) system setting.
Let me get back on :
Changing the MAC address on a Kea static lease does not work
A scenario that happened to me a couple of weeks ago :
My wive decided that I needed a "new" iPhone. My "12"was working just fine, but she decided otherwise. So, I got a "14".
When I came @work, there where I have pfSense, before I connected the phone to the local Wifi, I edited the static mac lease of my "12", convert it to the MAC "14" info.
Because the local work wifi network is for me a trusted network, I switched the wifi setting for this network to "Private Wifi network" to "No" (I guess this was already set like that as I copied the phone's setting for the 12 to the 14.
So I saw the MAC of the "14", and entered that into the static lease info.
I connected the phone's wifi.
It connected and got my usual 'static' IP.Recap : I changed the MAC of a device (this like changing a NIC of a client) and the static DHCP IP assignment worked as before.
( and I also had to change the Static IPv6 static info as that is what most devices use these days ^^ .... )
-
I hit this today on 26.03 beta, swapping one switch for another and wanting to keep the IP reservation the same.
This thread is a bit thick so please forgive me if I didn't read every word, but... Is the guidance still that this is not considered a bug, and that the expected solution is to ssh in and hand-edit
/var/db/kea/dhcp4.leases? That seems somewhat insane. -
I'm not seeing an entry on redmine.pfsense.org... one of you might post it there, at this point.
-
I've raised an issue in Redmine, https://redmine.pfsense.org/issues/16719
Interestingly the switch swapping case is probably a very common way to hit this, changing a NIC in a machine is a bit rare.
-
I may have missed it above, did someone try deleting and re-adding the reservation instead of editing it?
There are a handful of other ways to hit this that I can think of. Not terribly common perhaps but possible.
- replace PC/server, keep IP for existing port forwards or DNS resolution or firewall rules
- replace 3CX SBC (essentially, an on-premises proxy) and keep the IP to keep phones connected
- etc.
- [edit: replace downstream router]
-
@SteveITS, yes I also tried this approach (deleting and re-adding the reservation) and the problem still occurred.
-
The following patch attempts to clear the old Kea lease when either the MAC (IPv4) or DUID (IPv6) is changed on a static mapping, as well as when the static mapping is deleted.
diff --git a/src/etc/inc/system.inc b/src/etc/inc/system.inc index 86b97cb4dd1818d4b67c9ca0b23996a2eff9ba31..607256a9a49296bb878fd62deee95314c705b212 100644 --- a/src/etc/inc/system.inc +++ b/src/etc/inc/system.inc @@ -893,7 +893,55 @@ function system_clear_all_kea4leases() { socket_close($fd); } -function system_del_kea4lease(string $ip) { +/** + * Returns the Kea subnet ID for given an interface identity. + * @param string $interface The interface identity, e.g. opt1. + * @param int $address_family IP address family, AF_INET or AF_INET6. + * @return string|null The subnet ID, or null if none found. + */ +function get_keasubnetid_from_interface(string $interface, int $address_family = AF_INET): string|null { + $subnet_id = null; + $path = ($address_family == AF_INET) ? 'dhcpd' : 'dhcpdv6'; + foreach (array_keys(config_get_path($path, [])) as $idx => $if) { + if ($if == $interface) { + $subnet_id = $idx + 1; + break; + } + } + return strval($subnet_id); +} + +/** + * Deletes a single IPv4 lease from Kea. + * @param string $lease IP address, MAC address, or client ID. + * @param string|null $subnet_id The subnet ID for the lease. + * Only required when $lease is a MAC address or client ID. + * @return void + */ +function system_del_kea4lease(string $lease, string|null $subnet_id = null) { + if (strlen($lease) < 1) { + return; + } + if (is_ipaddrv4($lease)) { + $cmdjson = json_encode([ + 'command' => 'lease4-del', + 'arguments' => [ + 'ip-address' => $lease + ] + ]); + } elseif (is_numericint($subnet_id)) { + $cmdjson = json_encode([ + 'command' => 'lease4-del', + 'arguments' => [ + 'identifier' => $lease, + 'identifier-type' => is_macaddr($lease) ? 'hw-address' : 'client-id', + 'subnet-id' => intval($subnet_id) + ] + ]); + } else { + return; + } + $socket_path = g_get('varrun_path') . '/kea/kea4-ctrl-socket'; $rbuf = NULL; @@ -911,13 +959,6 @@ function system_del_kea4lease(string $ip) { return; } - $cmdjson = json_encode([ - 'command' => 'lease4-del', - 'arguments' => [ - 'ip-address' => $ip - ] - ]); - socket_send($fd, $cmdjson, strlen($cmdjson), 0); /* Kea sends status that we are not really interested in, so just eat it */ @@ -954,7 +995,40 @@ function system_clear_all_kea6leases() { socket_close($fd); } -function system_del_kea6lease(string $ip, string $type = 'IA_NA') { +/** + * Deletes a single IPv6 lease from Kea. + * @param string $lease IPv6 address or client DUID. + * @param string $type Lease type, e.g. "IA_NA" or "IA_PD". + * Only required when $lease is an IP address. + * @param string|null $subnet_id The subnet ID for the lease. + * Only required when $lease is the client DUID. + * @return void + */ +function system_del_kea6lease(string $lease, string $type = 'IA_NA', string|null $subnet_id = null) { + if (strlen($lease) < 1) { + return; + } + if (is_ipaddrv6($lease)) { + $cmdjson = json_encode([ + 'command' => 'lease6-del', + 'arguments' => [ + 'ip-address' => $lease, + 'type' => $type + ] + ]); + } elseif (is_numericint($subnet_id)) { + $cmdjson = json_encode([ + 'command' => 'lease6-del', + 'arguments' => [ + 'identifier' => $lease, + 'identifier-type' => 'duid', + 'subnet-id' => intval($subnet_id) + ] + ]); + } else { + return; + } + $socket_path = g_get('varrun_path') . '/kea/kea6-ctrl-socket'; $rbuf = NULL; @@ -972,16 +1046,6 @@ function system_del_kea6lease(string $ip, string $type = 'IA_NA') { return; } - $ip_parts = explode('/', trim($ip)); - - $cmdjson = json_encode([ - 'command' => 'lease6-del', - 'arguments' => [ - 'ip-address' => $ip_parts[0], - 'type' => $type - ] - ]); - socket_send($fd, $cmdjson, strlen($cmdjson), 0); /* Kea sends status that we are not really interested in, so just eat it */ diff --git a/src/usr/local/www/services_dhcp.php b/src/usr/local/www/services_dhcp.php index 15b512b0cafd3b856b817c43a8d76557417b2018..ed920736093caf0e09eca4ecf7c4b0876bcade3c 100644 --- a/src/usr/local/www/services_dhcp.php +++ b/src/usr/local/www/services_dhcp.php @@ -859,10 +859,11 @@ if ($act == "delpool") { } if ($act == "del") { - if (config_get_path("dhcpd/{$if}/staticmap/{$_POST['id']}") !== null) { + $lease_to_delete = config_get_path("dhcpd/{$if}/staticmap/{$_POST['id']}"); + if (!is_null($lease_to_delete)) { /* Remove static ARP entry, if necessary */ - if (config_get_path("dhcpd/{$if}/staticmap/{$_POST['id']}/arp_table_static_entry") !== null) { - mwexec("/usr/sbin/arp -d " . escapeshellarg(config_get_path("dhcpd/{$if}/staticmap/{$_POST['id']}/ipaddr"))); + if (isset($lease_to_delete['arp_table_static_entry'])) { + mwexec("/usr/sbin/arp -d " . escapeshellarg($lease_to_delete['ipaddr'])); } config_del_path("dhcpd/{$if}/staticmap/{$_POST['id']}"); write_config("DHCP Server static map deleted"); @@ -873,6 +874,19 @@ if ($act == "del") { } } + if (dhcp_is_backend('kea')) { + if (!function_exists('system_del_kea4lease')) { + require_once('system.inc'); + } + if (is_ipaddrv4($lease_to_delete['ipaddr'])) { + system_del_kea4lease($lease_to_delete['ipaddr']); + } elseif (!empty($lease_to_delete['mac'])) { + system_del_kea4lease($lease_to_delete['mac'], get_keasubnetid_from_interface($if)); + } elseif (isset($lease_to_delete['cid']) && (strlen($lease_to_delete['cid']) > 0)) { + system_del_kea4lease($lease_to_delete['cid'], get_keasubnetid_from_interface($if)); + } + } + header("Location: services_dhcp.php?if={$if}"); exit; } diff --git a/src/usr/local/www/services_dhcp_edit.php b/src/usr/local/www/services_dhcp_edit.php index 15fe9b10c8e57d72f89165096ce49dbe88cfa7cf..0193a6091537c0df196a76c5699083b7caf55cd0 100644 --- a/src/usr/local/www/services_dhcp_edit.php +++ b/src/usr/local/www/services_dhcp_edit.php @@ -498,6 +498,22 @@ if ($_POST['save']) { mwexec("/usr/sbin/arp -d " . escapeshellarg($mapent['ipaddr']) . " >/dev/null", true); } + if (dhcp_is_backend('kea') && ($this_map_config['mac'] != $mapent['mac'])) { + /* Remove the lease for the old mapping. Do this on edit to + * avoid leaving stray leases on the lease file; e.g. if the + * system is rebooted before changes are applied. */ + if (!function_exists('system_del_kea4lease')) { + require_once('system.inc'); + } + if (is_ipaddrv4($this_map_config['ipaddr'])) { + system_del_kea4lease($this_map_config['ipaddr']); + } elseif (!empty($this_map_config['mac'])) { + system_del_kea4lease($this_map_config['mac'], get_keasubnetid_from_interface($if)); + } elseif (isset($this_map_config['cid']) && (strlen($this_map_config['cid']) > 0)) { + system_del_kea4lease($this_map_config['cid'], get_keasubnetid_from_interface($if)); + } + } + header("Location: services_dhcp.php?if={$if}"); exit; } diff --git a/src/usr/local/www/services_dhcpv6.php b/src/usr/local/www/services_dhcpv6.php index c14ac1e3217f19ea78dac280fee320cf2d88efac..2a66f427c154fff976ffed3d765dd8ffdfbe4dde 100644 --- a/src/usr/local/www/services_dhcpv6.php +++ b/src/usr/local/www/services_dhcpv6.php @@ -614,7 +614,8 @@ if ($act == "delpool") { } if ($_POST['act'] == "del") { - if (config_get_path("dhcpdv6/{$if}/staticmap/{$_POST['id']}")) { + $lease_to_delete = config_get_path("dhcpdv6/{$if}/staticmap/{$_POST['id']}"); + if ($lease_to_delete) { config_del_path("dhcpdv6/{$if}/staticmap/{$_POST['id']}"); write_config("DHCPv6 server static map deleted"); if (config_path_enabled("dhcpdv6/{$if}")) { @@ -623,6 +624,18 @@ if ($_POST['act'] == "del") { mark_subsystem_dirty('hosts'); } } + + if (dhcp_is_backend('kea')) { + if (!function_exists('system_del_kea6lease')) { + require_once('system.inc'); + } + if (is_ipaddrv6($lease_to_delete['ipaddrv6'])) { + system_del_kea6lease($lease_to_delete['ipaddrv6']); + } elseif (!empty($lease_to_delete['duid'])) { + system_del_kea6lease($lease_to_delete['duid'], get_keasubnetid_from_interface($if)); + } + } + header("Location: services_dhcpv6.php?if={$if}"); exit; } diff --git a/src/usr/local/www/services_dhcpv6_edit.php b/src/usr/local/www/services_dhcpv6_edit.php index d6afb43208f9b43b9902cf81ce5c5e6a48ae031b..ea43fc33d1c04ae4f7c50effb9baa991a9c85971 100644 --- a/src/usr/local/www/services_dhcpv6_edit.php +++ b/src/usr/local/www/services_dhcpv6_edit.php @@ -221,6 +221,20 @@ if ($_POST['save']) { } + if (dhcp_is_backend('kea') && ($this_map_config['duid'] != $mapent['duid'])) { + /* Remove the lease for the old mapping. Do this on edit to + * avoid leaving stray leases on the lease file; e.g. if the + * system is rebooted before changes are applied. */ + if (!function_exists('system_del_kea6lease')) { + require_once('system.inc'); + } + if (is_ipaddrv6($this_map_config['ipaddrv6'])) { + system_del_kea6lease($this_map_config['ipaddrv6']); + } elseif (!empty($this_map_config['duid'])) { + system_del_kea6lease($this_map_config['duid'], get_keasubnetid_from_interface($if, AF_INET6)); + } + } + header("Location: services_dhcpv6.php?if={$if}"); exit; } diff --git a/src/usr/local/www/status_dhcp_leases.php b/src/usr/local/www/status_dhcp_leases.php index 0a1aa2530f89d74f42fe5a6522c9508b3ec6c570..6ab92bc72e3f13cf27b9b9150f75247f71e2cda5 100644 --- a/src/usr/local/www/status_dhcp_leases.php +++ b/src/usr/local/www/status_dhcp_leases.php @@ -81,8 +81,11 @@ if (($_POST['deleteip']) && (is_ipaddr($_POST['deleteip']))) { endif; /* dhcp_is_backend('isc') */ if (dhcp_is_backend('kea')): -if (($_POST['deleteip']) && (is_ipaddr($_POST['deleteip']))) { - system_del_kea4lease($_POST['deleteip']); +if ($_POST['deleteip']) { + $_POST['deleteip'] = trim($_POST['deleteip']); + if (is_ipaddrv4($_POST['deleteip'])) { + system_del_kea4lease($_POST['deleteip']); + } } endif; /* dhcp_is_backend('kea') */ diff --git a/src/usr/local/www/status_dhcpv6_leases.php b/src/usr/local/www/status_dhcpv6_leases.php index d0c515b7be9e168c1db3d46634252a509a9c7cae..183f041210b977e45dadcf7d26172ad410bd008a 100644 --- a/src/usr/local/www/status_dhcpv6_leases.php +++ b/src/usr/local/www/status_dhcpv6_leases.php @@ -93,14 +93,23 @@ if ($_POST['cleardhcpleases']) { endif; /* dhcp_is_backend('isc') */ if (dhcp_is_backend('kea')): -if ($_POST['deleteip'] && is_ipaddrv6($_POST['deleteip'])) { - system_del_kea6lease($_POST['deleteip']); - header("Location: status_dhcpv6_leases.php?all={$_REQUEST['all']}"); +if ($_POST['deleteip']) { + $_POST['deleteip'] = trim($_POST['deleteip']); + if (is_ipaddrv6($_POST['deleteip'])) { + system_del_kea6lease($_POST['deleteip']); + header("Location: status_dhcpv6_leases.php?all={$_REQUEST['all']}"); + } } if ($_POST['deletepd']) { - system_del_kea6lease($_POST['deletepd'], 'IA_PD'); - header("Location: status_dhcpv6_leases.php?all={$_REQUEST['all']}"); + $_POST['deletepd'] = trim($_POST['deletepd']); + if (is_subnetv6($_POST['deletepd'])) { + list($_POST['deletepd']) = explode('/', $_POST['deletepd']); + } + if (is_ipaddrv6($_POST['deletepd'])) { + system_del_kea6lease($_POST['deletepd'], 'IA_PD'); + header("Location: status_dhcpv6_leases.php?all={$_REQUEST['all']}"); + } } if ($_POST['cleardhcpleases']) {If you can reproduce the issue please test out the patch using the System Patches package. I only tested it on 26.03-BETA.
-
@jamie Are you able to test the patch and confirm it fixes the issue for you?
-
This patch is still ok/ needed on 26.03 release, right?
-
@luckman212 said in Changing the MAC address on a Kea static lease does not work:
This patch is still ok/ needed on 26.03 release, right?
Yes. I've just updated it to be the same as what's been committed in devel.
-
Sorry have been slow to come back. I've not applied a patch to pfSense before so I may have done it wrong, but I can't get it to apply.
Version: 2.8.1-RELEASE
- Installed System_Patches package
- Navigated to System -> Patches
- Add new patch, set a description and paste content from above comment into "Patch Contents", left all other options as default, saved.
- Pressed debug and got the following error
Patch does not apply cleanly (detail) Patch does not revert cleanly (detail) Debug Result: Fail This patch does not apply or revert cleanly. The patch settings may be incorrect, the patch content may not be relevant to this version, or the patch may depend upon another separate patch which must be applied first.I pressed debug as the only options I see are "View" and "Debug", the docs suggest there should be an apply button, but I don't see one. This is what I see:
I can share the detail output when I press debug if that's useful, let me know.
I also tried checking auto apply but that didn't seem to do anything.
-
@jamie said in Changing the MAC address on a Kea static lease does not work:
I can't get it to apply.
Version: 2.8.1-RELEASE
-> "I only tested it on 26.03-BETA."
2.8.1 is probably just a bit behind on Kea code.
