pfSense

Log snippet

INFO [kea-dhcp4.leases.0x258e04c17b00] DHCP4_INIT_REBOOT [hwtype=1 MYDEVICEMAC], cid=[no info], tid=0x13de032f: client is in INIT-REBOOT state and requests address SOME-OTHER-IP
# ...
WARN [kea-dhcp4.alloc-engine.0x258e04c17b00] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 MYDEVICEMAC], cid=[no info], tid=0xfb49dbf6: conflicting reservation for address DESIRED-IP with existing lease Address: DESIRED-IP Valid life: 7200 Cltt: 1735627163 Hardware addr: MYDEVICEMAC Client id: (none) Subnet ID: 1 Pool ID: 0 State: default Relay ID: (none) Remote ID: (none)

The INFO line is interesting -- makes it sound like my device is asking for a different address.

i just ran into the same problem, under different circumstances, i change mac addresses on a static assignment using kea(that had been working), hard restarted kea, deleted readded assignment, raspi would always boot with random dhcp from the pool.
went into pfsense setting change from kea to isc, hit save rebooted the raspi device and it respected the static assignment.
switched back to kea, reboot raspi, ignored static assignment again got the same ip from the pool.
id imagine it would work when the lease on the pool expires, wish there was a button to expire a lease or something? who knows!

Ran into the same issue. I have no way to reproduce it. I changed the assigned static ip to another ip address, unplugged the device and it was working again. Definitely something going on here.

Experienced an issue adjacent to this that I'm not 100% convinced is really a bug but it was enough to make me scratch my head for about an hour and researching it led me to this bug report.
I had a windows 10 client which was initially connected to the network via a wifi adapter, on the same system, i disconnected it from wifi, connected it via ethernet, noted it's mac address from the dynamic pool mapping it got, and gave it a static one. No amount of `ipconfig /release` or disconnecting ethernet or rebooting would let it get its static IP.
The logs did helpfully report what might be obvious at this point:
```
WARN [kea-dhcp4.alloc-engine.0xaa337a15f00] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 2c:f0:5d:a2:b8:22], cid=[01:2c:f0:5d:a2:b8:22], tid=0x5dbf529d: conflicting reservation for address 192.168.1.31 with existing lease Address: 192.168.1.31 Valid life: 7200 Cltt: 1754954942 Hardware addr: c8:15:4e:a8:b5:51 Client id: 01:c8:15:4e:a8:b5:51 Subnet ID: 4 Pool ID: 0 State: default Relay ID: (none) Remote ID: (none) User context: { "Netgate": { "option-data": { "domain-name": "lan.mydomain.com" } } }
```
Fixing that involved reconnecting the client via wifi (using the same card, not that we took it out, just worth noting), manually running an `ipconfig /release`, and then that finally freed the static mapping to bind to the new mac address when ethernet was reconnected.
Like I said, don't think this was a bug, but it was certainly confusing, nothing other than the logs indicated anything was wrong, the dhcp status page didn't even list the old mac address as holding on to the old IP, it in fact listed the static mapping as it was presently configured, with the new IP address, and had the link marked "online".
Whether any of that should be changed is not something I'm opinionated at all, I'll leave that to others to decide, just posting here in case it helps any in the future.