Services: Kea: DHCPv4/6: Add type system with validation and encoding for supported DHCP options
This adds a type framework using MAPS extracted from data inside the KEA documentation.
Most flat options have a validator and encoder added. Users are guided via validation messages which types are correct choices for each code selection.
Advanced options (structured, nested, encapsulated) do not have an own validator or encoder yet, they fall back to hex.
Unknown options that are valid in the IANA lists, but maybe not inside KEA yet, also fallback to hex.
The user can always bail out of the type system and always use hex instead for any option.
Services: Kea: DHCPv4/v6: Add single client_class support to DHCP options (#9988)
Enhances the DHCP option MVP introduced in:
https://github.com/opnsense/core/commit/8350fcb73b9dd44e8b1e00d2ea03ced71e0f71achttps://github.com/opnsense/core/commit/b67a8fdc931936f768b3d6a2eea1e179320f257a
An single client_class can be attached to a DHCP option. This client_class contains a test. Right now a single test is possible, matching a DHCP option code, and the payload inside of it. A common example is matching option 93 to send different boot files to different client architectures.
A client_class is optional input, if none is given, the option will always be sent out as before.
system: validate monitor uniqueness based on the host route presence #9844
This is a little tricky to get right but that should be it:
If the host route is disabled we allow the same monitor IP to be used
in several gateways. Dpinger uses -B to bind the source address which
should make this work as per the ticket. We still need to make sure
that although the gateway in question disables the host route feature
another gateway may still have it enabled so we also need to fail in
that case. Tested the combinations and looks ok also looking at:
# pluginctl -r host_routes
Would still consider this an experiment.
(cherry picked from commit 1156faee1df99f4d010520ac0f074cb6266864a6)
dnsmasq: remove a too-strict validation
When adding ranges from setaddr.php we do not use the model so
one can input ::1000 etc and then Dnsmasq migration will fail
due to it not setting a constructor. We still validate :: prefix
for constructor use but now take :: prefix verbatim which
doesn't interfere with Dnsmasq service start.
Discussed-with: @monviech
(cherry picked from commit a5773fe71f5703426761b9965bd49e468366de27)
dnsmasq: remove a too-strict validation
When adding ranges from setaddr.php we do not use the model so
one can input ::1000 etc and then Dnsmasq migration will fail
due to it not setting a constructor. We still validate :: prefix
for constructor use but now take :: prefix verbatim which
doesn't interfere with Dnsmasq service start.
Discussed-with: @monviech
