ITADN

os-kea: expose allocator field in DHCPv4 model (parity with DHCPv6)

#5450Closedmdella 创建于 2026-05-18
incomplete
M
mdellacommented
## What The `os-kea` plugin's GUI/API surface exposes `allocator` selection for **DHCPv6** (`KeaDhcpv6.xml`) but not for **DHCPv4** (`KeaDhcpv4.xml`). Both Kea DHCPv4 and DHCPv6 daemons have supported the `allocator` field at the global scope since Kea 2.5.0, and we're running Kea 3.0.3 on our deployment (which fully supports `iterative` / `random` / `flq` for v4). Requesting parity: add `allocator` to the v4 model + form so it can be set from the GUI/API alongside the v6 control already shipping. ## Why Sites that benefit from `random` (default-deviation lease distribution, address-prediction reduction, hot-spot avoidance on the low-pool-end) currently have to maintain a local patch to `KeaDhcpv4.php::generateConfig()` to inject `'allocator' => 'random'` between the `loggers` and `subnet4` keys of the rendered `Dhcp4` block. The patch survives until the next `os-kea` upgrade, then needs reapplying. Plugin-level support would eliminate that. ## Suggested change In `models/OPNsense/Kea/KeaDhcpv4.xml`, add an `allocator` `OptionField` mirroring whatever lives in `KeaDhcpv6.xml` today (default `iterative`, options `iterative`, `random`, `flq`). In `KeaDhcpv4.php::generateConfig()`, emit the chosen value into `$cnf['Dhcp4']['allocator']` at the appropriate point. A subnet-level override would be a nice-to-have but is secondary; the global setting covers most use cases. For reference, the v6 generator already does the equivalent — same pattern can be cloned. ## Environment - OPNsense 26.1.x - os-kea 1.52 - Kea daemon 3.0.3 - Use case: fleet of multi-VPC firewalls; uniformity between v4 and v6 management surfaces (Filed as a parity request, not a bug — daemon supports the field; only the plugin surface lacks the knob.)
关闭于 2026-05-18 1 条评论