Wifi-iface enables before I enable it/"uci commit". Bug?

I start with the wifi-device enabled and the wifi-iface disabled:

config wifi-device 'radio1'
        option disabled '0'
config wifi-iface 'default_radio1'
        option device 'radio1'
        option disabled '1'

I run the uci command to enable the wifi-iface, but I do not commit the change:

# uci set wireless.default_radio1.disabled=0
# uci changes

Without commiting the changes, I run wifi:

# wifi

Now I can detect the wifi-iface with a scan on an adjacent machine:

$ sudo iw wlo1 scan | grep OpenWrt
	SSID: OpenWrt

I thought that I had to commit the changes using uci commit before the interface would enable. Is this "Works as intended", or is it a bug?

Yes, runtime changes override persistent configuration, which can be used for testing and reverting to previous state by soft and hard means, i.e. uci revert and power reset.

I do understand what each of the component terms ("runtime changes", "override", and "persistent configuration") mean, but I do not understand what this sentence means in the context of my problem.

Given that the only change I made was uci set wireless.default_radio1.disabled=0, what runtime changes are you referring to? Do you mean the contents of /tmp/.uci ?

Any changes to the UCI configuration made by its CLI API can be considered temporary/transient/runtime before you commit them to make persistent.
This means the changes are effective only for the current system run/boot and lost on reboot, unless explicitly saved.

Yes, that's how it is implemented, provided that /tmp is using tmpfs by default, i.e. RAM.

1 Like

Ok, please bear with me, because you have just totally changed the way that I think about uci commit. I am in shock!

For approximately the last 14 years, I have thought:
<Old config>
uci set ...
<Old config> (I have not commited so /etc/config has not changed)
uci commit
<New config> (because /etc/config has now changed)

Now, I think that you are telling me:
<Old config>
uci set ...
<New config (temporary)> (uci revert will go back to old config)
uci commit
<New config (permanent)> (because I have commited).

If I have correctly understood, then I think that the wiki's page on uci is extremely misleading. (It equates the current configuration with the state of /etc/config, which is simply not true.)

I need to do some more testing, but in the meanwhile, "Thank you so much!" :pray: :pray:

1 Like

The wiki most likely explains the logic in terms of customizing the UCI config files directly by using a text editor, but the uci and ubus commands aka CLI and ubus APIs involve their own specifics.

Example number 1:

"... the file /etc/samba/smb.conf is overwritten with UCI settings from the UCI configuration file /etc/config/samba when running /etc/init.d/samba start.

No it isn't. It is overwritten with UCI settings from the UCI configuration file /etc/config/samba combined with settings from the corresponding configuration file /tmp/.uci/samba (if this latter file is non-empty) when running /etc/init.d/samba start.

uci set samba.blahdy.blah=whatever does not change /etc/config/samba.
uci set samba.blahdy.blah=whatever does change samba's configuration[*].

It's exactly that first sentence at the top that made me equate the contents of /etc/config/samba with the configuration of samba. Hence, if I haven't changed /etc/config/samba, then I haven't changed the samba configuration.

More to follow...

[*] given a following /etc/init.d/samba reload

1 Like

Example number 2:

Upon changing a UCI configuration file, whether through a text editor or the command line, the services or executables that are affected must be (re)started (or, in some cases, simply reloaded) by an init.d call, such that the updated UCI configuration is applied to them.

Wrong, wrong, wrong, wrongity-wrong. Again, it says "Upon changing a UCI configuration file..." No! You do not have to change a configuration file in order to have to restart or reload the corresponding service!

Corrected version (1st attempt only - I am not yet happy with this rewrite - it's factually accurate but still confusing! The presentation order of the ideas and consequences is not correct.):

Upon changing a UCI configuration, whether by using a text editor to modify the corresponding configuration file or by issuing a suitable uci command [1], the services or executables that are affected must be (re)started (or, in some cases, simply reloaded) by an init.d call, such that the updated UCI configuration is applied to them.

[1] uci add, uci add_list, uci delete, uci del_list, uci import, uci set and uci rename change UCI configuration and hence necessitate a reload or a restart of the relevant service. Note that these uci commands do not change UCI configuration files - it is the uci commit that you may choose to issue later which will change the relevant UCI configuration file.

I haven't done the same testing, but are you sure you're not detecting the second radio on the router?

After making uci changes (but before committing them) have you restarted wifi in any way?

100% certain. Both the second radio and its corresponding interface remained disabled during the testing.

Yes. I ran wifi. But as my understanding of how uci worked was well-and-truly borked, I expected there to be no change to my wifi configuration. ("Hey, the config file is still the same, so the config must still be the same!")

Hopefully posts 5, 7 and 8 will clear things up.

Yes, wifi picking uncommitted changes also contradicts with my impression of how it's supposed to work.

Thank you! I'm so pleased to know that it's not just me! And here's the real bonus: it's not just wifi picking uncommitted changes - it's everything!! And that's the way it's supposed to work!!

The good news is now that I've had an hour or two to wrap my head round this, it does make sense. I really do think it's the documentation which is confusing - once I had that (incorrect) mental model in my head, I didn't even think to question it.

The uci page definitely needs a rewrite, but I won't be doing it this week... :rofl:

I can reproduce on 23.05.0-rc2. Just changed the hidden status on an SSID to not being hidden with the uci without committing the change, restarted wifi and I can see SSID on other devices.

I agree, the term "configuration file" is not entirely correct, and would be best to replace with a more generic "configuration" defined as a merge of the relevant persistent config file with its uncommitted customization.

1 Like

Lol, sorry, it never occurred to me that this was not understood by everyone. I see how it can come as a shock.
It is so very useful and is used by numerous packages. This is how Luci rolls back a broken network config for example.

Or just uci revert config.

1 Like

Bootup config and runtime config perhaps....

Sorry, that wasn't a line of code with shell redirection operators (< and >), that was my crappy attempt at drawing a finite state diagram with 3 states:

  1. "Old Config",
  2. "New config (temporary)", and
  3. "New config (permanent)"

along with state transitions made out of uci commands, all drawn using only text characters. Here's a better version that I've just knocked up:

Yep, that's how it works.
The wiki definitely needs to be updated and putting this diagram at the top would be a good starting point :wink:

On second thoughts, maybe the top box should be "cli interface", middle box "runtime configuration (stored in temp location)" and the bottom box "Non-volatile Configuration file (stored in .etc/config)".

You could add a pointer showing that procd (initiated by the /etc/init.d/... script or the service ... command) operates on the contents of the middle box but checks to see if the non-volatile config file has been changed since the last time it ran and re-syncs if required.

Oh! and the uci revert arrow woud go from bottom to middle......