LUCI & CLI enabled options discrepency

If you manually set enabled=1 for a firewall rule using the CLI and then committed the changes using uci commit firewall, the enabled=1 option is indeed reflected in the CLI output.

However, the behavior in LUCI, where it displays a message indicating the removal of the enabled section (uci del firewall.cfg103837.enabled), seems weird. It suggests that LUCI did not recognize the enabled=1 option set in the CLI and attempted to remove it.

This discrepancy between LUCI and the CLI could be due to several reasons, such as a synchronization issue between the CLI and LUCI, or a bug in the specific version.
Even after rebooting (after committing the changes on CLI), it still wants to try remove that enabled rule when you click apply&save.

Is this behavior intended?
Is this also the same behavior in the latest OpenWRT versions?

tested only on OpenWRT 21.02. Please see screenshot below:

The default state for a fireawll rule is that if it is listed, it is enabled. Therefore, enabled=1 is functionally the same as omitting the enabled line. In order to disable a rule, enabled=0 needs to be explicitly included in the UCI/config.

In many cases, LuCI will simply not include a given configuration item if omitting it achieves the same functional result. Another example of this would be setting static routes -- the route type unicast is the functional default, so if unicast is selected in the LuCI interface, it is actually not written to the config file. If another type is selected, it would be included in the file.

3 Likes

The default for a rule is enabled. So yes this is intended behavior.

I observed another setting that does the same (i.e. removes extra stanzas that would be the default).

2 Likes

And this behaviour persists through to 22.03. Here is an example showing the CLI effect of modifying the rule in LUCI:

Rule disabled in LUCI:
uci:

firewall.cfg0592bd=rule
firewall.cfg0592bd.name='Allow-DHCP-Renew'
firewall.cfg0592bd.src='wan'
firewall.cfg0592bd.proto='udp'
firewall.cfg0592bd.dest_port='68'
firewall.cfg0592bd.target='ACCEPT'
firewall.cfg0592bd.family='ipv4'
firewall.cfg0592bd.enabled='0'

/etc/config/network:

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'
        option enabled '0'

Rule enabled in LUCI:
uci:

firewall.cfg0592bd=rule
firewall.cfg0592bd.name='Allow-DHCP-Renew'
firewall.cfg0592bd.src='wan'
firewall.cfg0592bd.proto='udp'
firewall.cfg0592bd.dest_port='68'
firewall.cfg0592bd.target='ACCEPT'
firewall.cfg0592bd.family='ipv4'

/etc/config/network:

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

Ok i understand that. But what's bothersome is the fact that LUCI still has "unresolved" or rather unsaved changes if you save & commit the enabled=1 in CLI. Even after rebooting, it still has unsaved changes, until you save&apply that setting (like in the screenshot) will annoy you.

Can you elaborate on the specific sequence of events that leads to this annoyance in the LuCI web interface? Please make it a step-by-step so that others may try to replicate.

ok to get to that screen of unsaved changes or to replicate the issue:

  1. Disable a firewall rule in CLI & commit changes.
  2. Refresh LUCi, see that the rule has indeed been disabled. If you click on save&apply, it will report "nothing to save", ok cool.
  3. Enable the firewall rule in CLI & commit changes.
  4. Refresh LUCi, see that the rule has indeed been enabled. If you click on save only, it will show you there are unsaved changes. Meanwhile you have already committed the firewall in CLI. I think its just trying to remove the enabled line since you say that it is implied that it is enabled by default. But until you click save&apply, those changes will linger in LUCI. They wont immediately show at the top right in LUCi, until you click Save only.

Ok... so I am able to replicate your issue. And I can see why this is a bit confusing. I don't know if I'd call it a bug, but you could certainly write a bug report and ask for this to be addressed...
I'm pretty sure that the underlying "problem" will not be changed -- LuCI is likely coded to remove extraneous lines from the config when possible and I highly doubt that the devs would change this to leave the enabled line in there when enabled = 1. However, in my mind, the question is why does it pick up the extra line only when save is clicked and not save & apply -- if you click the latter, it should see the extraneous line, delete it and commit the firewall and restart the firewall.

I did another test.
After step 3 above...
a) refresh LuCI firewall page
b) Add/delete/edit different firewall rule
c) hit save & apply
d) Note that the rule in question remains enabled
e) click save
f) note that there are no pending changes (i.e. the change was picked up in the save and apply operation

or...
at step c, instead of save and apply just hit save instead. In this case, the enabled line will be picked up and you'll have n+1 changes queued (where n was the number of changes associated with your firewall changes in LuCI). You need to hit the save and apply anyway to clear those.

All that said, this seems to be a corner case of likely low priority... I would posit that users making changes on the command line are not likely to be bouncing between the CLI and web interfaces like this, and then clicking the LuCI save button after making CLI canges (but none in LuCI) seems entirelly unnecessary. If changes are made in LuCI, the enabled line will be picked up and included in the changes there. So it is really not affecting anything here.

Beyond all that, the firewall is still working as expected and this isn't blocking or breaking anything other than a UI annoyance.

But now that you know that the default behavior is enabled when enabled is absent, you could simply adjust your syntax to be like this:

uci del firewall.@rule[x].enabled
2 Likes