To change wireless setting I have to (?) do the following:
uci set wireless.default_radio0.network='lan'
uci commit
/etc/init.d/network reload
Is the last command (/etc/init.d/network reload) disruptive to all network interfaces? Does it cause (brief) packet loss or latency increase on all interfaces?
If yes, is there a more targeted way to apply .network setting for particular wireless radio?
please show this command:
uci show | grep wireless
or test "wifi reload"
wifi help
Usage: /sbin/wifi [config|up|down|reconf|reload|status|isup]
enables (default), disables or configures devices not yet configured.
Output of uci show | grep wireless | cut -d = -f 1 (output up to = )
wireless.radio0
wireless.radio0.type
wireless.radio0.path
wireless.radio0.channel
wireless.radio0.band
wireless.radio0.country
wireless.radio0.cell_density
wireless.radio0.distance
wireless.radio0.htmode
wireless.default_radio0
wireless.default_radio0.device
wireless.default_radio0.mode
wireless.default_radio0.ssid
wireless.default_radio0.encryption
wireless.default_radio0.multicast_to_unicast_all
wireless.default_radio0.key
wireless.default_radio0.short_preamble
wireless.default_radio0.skip_inactivity_poll
wireless.default_radio0.disassoc_low_ack
wireless.default_radio0.network
wireless.radio1
wireless.radio1.type
wireless.radio1.path
wireless.radio1.channel
wireless.radio1.band
wireless.radio1.htmode
wireless.radio1.cell_density
wireless.radio1.country
wireless.radio1.distance
wireless.default_radio1
wireless.default_radio1.device
wireless.default_radio1.network
wireless.default_radio1.mode
wireless.default_radio1.ssid
wireless.default_radio1.encryption
wireless.default_radio1.key
wireless.default_radio1.multicast_to_unicast_all
wireless.wifinet2
wireless.wifinet2.device
wireless.wifinet2.mode
wireless.wifinet2.ssid
wireless.wifinet2.encryption
wireless.wifinet2.multicast_to_unicast_all
wireless.wifinet2.short_preamble
wireless.wifinet2.disassoc_low_ack
wireless.wifinet2.key
wireless.wifinet2.network
wireless.wifinet2.skip_inactivity_poll
wireless.wifinet3
wireless.wifinet3.device
wireless.wifinet3.mode
wireless.wifinet3.ssid
wireless.wifinet3.encryption
wireless.wifinet3.multicast_to_unicast_all
wireless.wifinet3.skip_inactivity_poll
wireless.wifinet3.disassoc_low_ack
wireless.wifinet3.key
wireless.wifinet3.network
wireless.wifinet3.hidden
UPDATE:
wifi reload radio0 works.
Interestingly, I can run the reload command before or after uci commit - probably some kind of bug.
I advise you not to modify every time with uci commit as the file is written to flash
you can create new sids by setting lan or other networks
No, it works as designed. Changes you do through uci set etc. are staged in a temporary changes directory and reflected in the output of uci get, uci show etc.
A uci commit merges these temporary staged changes back into the persistent configuration files in /etc/config/. In practice this means that you can apply config changes without having to actually modify the /etc/config/ files on flash. This is especially useful for scripted actions, e.g. button press handlers or cron jobs where committing and altering config files all the time may wear out the flash.
After a reboot, all uncommitted configuration changes are gone.
The biggest thing with this functionality that is pretty much standard in all business class network equipment is if you f..k up the new settings you just reboot and you are saved.
That is good to know - I'll stop using uci commit if I don't need a persistent change. What confused me, to the point that I though it was a bug, was that uci changes from shell were not reflected in Luci GUI. Some indication or better yet, a full list of staged changes would be nice. Something like 'show running config' in many network devices.
A followup question:
When I save a change in Luci - if I reload - will the change take effect? I note that, after saving a change in Luci I get a message "interface has 1 pending change". However, when I do the same uci change from CLI I don't get this message in Luci nor I get a list of staged changes up in the right corner.
The LuCI isn’t really the “system” monitor or control and it isn’t even needed for operation.
It is only an add-on visualization mirror with some settings functionality.
You can see luci as a linux desktop flavor. It is maybe nice to look at but it is totally worthless for the system’s wellbeing.
The only meaningful difference between Ubuntu desktop and Ubuntu server is the extra desktop package.
There is a learning curve to come from Windows to Linux with it’s terminal/cli. But once learned the desktop/luci is more and more irritating when doing something.
I think it could be a security issue (or just giving unexpected results) when Luci does not reflect system state or giving user a false representation of what is being committed.
Right now, if I don't uci commit after shell change, I have no way of knowing what commands were run from luci-app-commands. In addition, any change I commit via Luci GUI will also commit (make permanent) changes done via luci-app-commands (shell). And, will apply this change blindly, without user being aware.
LuCI uses a different delta directory pegged to the login session, in contrast to the system wide default one used by the uci command line. This is intentional and a prerequisite for user account separation.
Unsaved (= uncommitted) LuCI changes are invisible to the system and are not picked up by service reloads. When LuCI commits it's configuration, it will not commit changes done on the cli level, those remain uncommitted.
Thank you for detailed explanation.
Here's one scenario I tested: When I uci set from shell and make another, unrelated, change from Luci and 'save and apply' my shell uci set takes effect as well w/o any indication to Luci user.
Okay, when that shell uci set change ends up in /etc/config/foo while saving from LuCI then it's a bug. When the shell change remains an uncommitted change after LuCI Save & Apply then it is is expected.
LuCI should commit it's own changes while not committing shell level changes.
Config reloads (regardless of whether triggered from LuCI or elsewhere) should pick up shell changes but not uncommitted LuCI changes.
We still have the old linux saying, “Linux expect the users to know what they are doing”.
I would call this “it ain't a bug, it’s a feature”.
My recommended approach is still to choose what tool you want to use for setup and stick to it while doing the setup.
Now you are hammering the nails into the plank from both directions at the same time and hope that they will hit each other in the middle of the plank.
I suppose one solution would be for luci-app-commands to work under luci user so it's commands/changes would be reflected in luci GUI.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.