Kea DHCPv4 not saving 'DHCP option data' when creating new subnet (first save)

[ETES-Stuttgart]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

When creating a new Subnet in Kea DHCPv4 in Services -> Kea DHCP [new] -> Kea DHCPv4 -> Subnets, after clicking "Save", all my settings under "DHCP option data" vanish (this means all, except the first ones "Subnet" and "Pools"). The fields are empty after clicking the edit-button of the entry.

To Reproduce

Steps to reproduce the behavior:

1. Go to 'Kea DHCPv4 in Services -> Kea DHCP [new] -> Kea DHCPv4 -> Subnets'
2. Fill in some of the options in 'DHCP option data'
3. Click on 'Save'
4. Click on 'Edit' of the created Subnet
5. See no data in 'DHCP option data'
6. Fill in the options in "DHCP option data' again
7. Click on 'Save'
8. Click on 'Edit' of the created Subnet
9. The data is now saved

Expected behavior

The options in "'DHCP option data' should be saved the first time I click on 'Save'

Screenshots

Creating a new Subnet with some options in 'DHCP option data': After clicking on 'Save' and then editing the created Subnet again:

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 24.4_8 (amd64). AMD EPYC 3101 4-Core Processor (4 cores, 4 threads)

--

Thank you in advance & kind regards Patrick

[Monviech]

First thoughts

Maybe it has to do with the option_data_autocollect

Not all of the option fields have that style set to hide them when it is 1.

I'm not sure, but maybe these fields aren't supposed to be able to be used when that option is 1, and that style has been forgotten to be added to them. (just a thought.)

https://github.com/opnsense/core/blob/dac769feeb818ffb183578a8bcb79772ca4a2b74/src/opnsense/mvc/app/controllers/OPNsense/Kea/forms/dialogSubnet4.xml#L19

https://github.com/opnsense/core/blob/dac769feeb818ffb183578a8bcb79772ca4a2b74/src/opnsense/mvc/app/controllers/OPNsense/Kea/forms/dialogSubnet4.xml#L42

Disabling "option_data_autocollect" makes all fields able to save.

Some troubleshooting:

Log if the POST Data of addSubnetAction contains the option_data on first save:

[11-Jun-2024 13:09:19 Etc/UTC] Action: addSubnet
POST Data:
Array
(
    [subnet4] => Array
        (
            [subnet] => 192.168.29.0/24
            [pools] => 
            [option_data_autocollect] => 1
            [option_data] => Array
                (
                    [routers] => 
                    [static_routes] => 
                    [domain_name_servers] => 
                    [domain_name] => 
                    [domain_search] => domain.tld
                    [ntp_servers] => 
                    [time_servers] => 192.168.1.1
                    [tftp_server_name] => 
                    [boot_file_name] => 
                )
        )
)

• Looks like it.

[AdSchellevis]

https://github.com/opnsense/core/blob/0487802a4b9255bd3084eaffc993ad30c050d9ff/src/opnsense/mvc/app/controllers/OPNsense/Kea/forms/dialogSubnet4.xml#L22

[Monviech]

@AdSchellevis

Though shouldn`t the option_data_autocollect only matter for these?

https://github.com/opnsense/core/blob/0487802a4b9255bd3084eaffc993ad30c050d9ff/src/opnsense/mvc/app/models/OPNsense/Kea/KeaDhcpv4.php#L61-L64

[AdSchellevis]

@Monviech yes, they should. If the form behaves the same on your end, I’ll change the tag and take a look when I am back at the office.

[ETES-Stuttgart]

Disabling "option_data_autocollect" makes all fields able to save.

Unfortunatelly it doesn't. Even when it's disabled, nothing in 'DHCP option data' is saved when saving for the first time. Although, disabling 'option_data_autocollect' makes more options visible. So those which will not be saved, when 'option_data_autocollect' is enabled aren't visible in that case anyway.

So the behaviour is the same as described:

• create new subnet:
  
• click save
• click edit on the newly created subnet:
• the settings are gone

[AdSchellevis]

Can you check which information is exchanged on save? (json request and response)

[Monviech]

@AdSchellevis If you can give me a tip where I should look I can spend some time trying to troubleshoot this.

Here's the json requests:

Request URL: https://172.16.0.123:4444/api/kea/dhcpv4/add_subnet/
Request Method: POST
Status Code: 200 OK
Remote Address: 172.16.0.123:4444
Referrer Policy: same-origin

{"subnet4":{"subnet":"192.168.29.0/24","pools":"","option_data_autocollect":"0","option_data":{"routers":"192.168.1.1","static_routes":"","domain_name_servers":"192.168.1.1","domain_name":"domain.example.com","domain_search":"example.com","ntp_servers":"192.168.1.1","time_servers":"192.168.1.1","tftp_server_name":"","boot_file_name":""}}}

{"result":"saved","uuid":"65b0b78f-0f01-467b-9751-aa2d344f35f2"}

Request URL: https://172.16.0.123:4444/api/kea/dhcpv4/get_subnet/65b0b78f-0f01-467b-9751-aa2d344f35f2
Request Method: GET
Status Code: 200 OK
Remote Address: 172.16.0.123:4444
Referrer Policy: same-origin

{
    "subnet4": {
        "subnet": "192.168.29.0\/24",
        "option_data_autocollect": "0",
        "option_data": {
            "domain_name_servers": {
                "": {
                    "value": "",
                    "selected": 1
                }
            },
            "domain_search": {
                "": {
                    "value": "",
                    "selected": 1
                }
            },
            "routers": {
                "": {
                    "value": "",
                    "selected": 1
                }
            },
            "static_routes": "",
            "domain_name": "",
            "ntp_servers": {
                "": {
                    "value": "",
                    "selected": 1
                }
            },
            "time_servers": {
                "": {
                    "value": "",
                    "selected": 1
                }
            },
            "tftp_server_name": "",
            "boot_file_name": ""
        },
        "pools": ""
    }
}

[AdSchellevis]

@Monviech if it behaves the same on your end, let’s label this a bug. I’m not sure where too look yet to be honest, all of this is pretty generic, I think the only out of the ordinary is the nesting of these items (they live in a container inside an ArrayField). I am pretty sure I could save items earlier while testing this.

[Monviech]

@AdSchellevis when I was developing my plugin I tried to put an array field into an array field and the backend complained that its not allowed. Since I see array in array here too maybe thats the problem?

[AdSchellevis]

@Monviech It’s not a repeating item, but support for these types was added last year (otherwise it would complain an not do anything). If some of the data is not stored, we need to figure out when that is, likely not always as that would probably trigger more issues. Next question is, when did it stop working (assuming it once worked under the circumstances specified)