Keav4: Allow setting option 43 data for subnets#9860
Keav4: Allow setting option 43 data for subnets#9860Holladiewal wants to merge 4 commits intoopnsense:masterfrom
Conversation
This allows setting a raw data value for the IPv4 DHCP option 43 There is minimal validation in place (it must look like a hex string) There will be no help encoding the value, we expect a fully compliant TLV-String
|
Preferably I need some people to test this before merging, @Holladiewal can you ask people in the other PR to test yours? I'll keep this open for a bit to collect feedback. |
Kea seems to be quite picky about the suboptions being in order. This is most likely an issue, since we do not use the kea interface to build up the option, but rather specifying the data ourselves. For now, there is a hint in the help text reminding the operator.
This reverts commit f3b062e. Actually, kea is smart enough to figure it out and reorders the options, so they are in order. I do not see anything in the RFC mention they _have_ to be in order, but it makes everybodies job easier in parsing if they are.
If we can set the option for the subnet, we should also be able to set it for a reservation.
|
Had the chance to do some testing of my own: Contrary to most things, Kea actually seems to be quite content with getting some malformed data in its config. Options that are too short are not sent: Options that are longer than specified are truncated to the proper length: Options specified out of order are being reordered (config order is "f1, f3, f2" and options are sent as "f1,f2,f3"): So far, I haven't found a way to make Kea not start up based on the user input. |
|
@Holladiewal The hint about We might be able to solve the whole subset of problems with such an approach, but since KEA is weird we also might not. But I will investigate this here: |
3 participants
This idea is based on #7361, and I am aware of concerns and issues regarding complexity and client-classes raised in that PR.
However I think offering the ability to set option 43 data is still important, even if there is no hand-holding by the UI to get the right values and not caring about client-classes.
If a client wants some option 43 data, there is only on set of data to choose from per subnet.
This PR allows just that: Setting the value delivered to the clients.
Nothing more, nothing less.
This could be expanded by offering help encoding values (for example encoding an ASCII-String into a hex-string).
Below is a picture of config and outcome (I had to set "always-send" so ubuntu would get the option. That should probably be exposed as a checkbox to the user):
