Do not overthink this. And do bear in mind I ask nothing of anyone regarding this freely distributed work.
the script is executed via the hotplug framework when network topology changes occur, with the filter scripts specifically targeting events concerning the STA(tion) interface (named in the option - 'interface' of the additional section - 'wifi-repeater').
config wifi-repeater 'STA_name' # a 'named' section (referenced in the filter scripts)
option interface wwan # matches value of STA configuration 'network' option
option wait 15
BTW, my preference is to use accurate names, e.g., 'wwan' to describe a 'wireless wide area network' rather than, e.g., 'wan', which is customarily cabled.
The additional UCI section is accurately named 'STA_name'. Using a UCI 'type' avoids the complication of having to iterate over each section - 'wifi-iface', which are generally 'anonymous', to discover the option - 'network' of the STA(tion) interface.
Setting permissions is unnecessary when a script is invoked with the sh(ell) command.
'logread' is a command issued in the CLI (terminal session). It is optional to employ it.
ubus
RangerZ wrote:I assume that when dabyd64's code does not find a station that this will backup the wireless file to wireless_AP+STA and replace it with the contents of wireless_AP, and I will not need to use the code snippet from post 92, and indeed should not use this.
I am not clear if I can, under the design, add a station manually. Under dabyd64's code I <b>assumed</b> that I could, and that as there was a valid ping to google nothing else would happen. I am not clear at what point your additional functions kick in. Can you please explain how these functions work in relation to the other code?
the script replaces that of dabyd64.
Regarding -
RangerZ wrote:...add a station manually.
Does this entail logging into the 'AP-only' device and manipulating its configuration? And as a consequence the dabyd64 looping solution, continuously accessing a configuration registry (/etc/config/wireless?), attempts to establish a STA(tion) association with the added (updated?) section - 'wifi-iface'?
N.B. here, one might correctly guess I have no experience with the dabyd64 looping solution.
The WLAN configuration in which the script was developed comprises 3X (remote) APs with identical SSIDs. Thus, following the loss of association with a remote AP and calling all the filter scripts found in /etc/hotplug.d/iface and /etc/hotplug.d/net via the hotplug framework, netifd attempts to re-establish the link. Finding one of the alike named APs, the STA(tion) interface is restored without intervention on the part of the script owing to the configurable option - 'wait'. Should netifd fail to restore the STA(tion) interface within the option - 'wait' period, the script restores wireless access to the AP(-only) and prepares the device for AP+STA operation at the next device initialisation.
Is it possible that netifd will attempt to associate with secondary configured STA(tion) section(s) - 'wifi-iface' with unique option - 'ssid' values?
config wifi-iface
option network wwan
option mode sta
option ssid 'remote AP0'
...
config wifi-iface
option network wwan
option mode sta
option ssid 'remote AP1'
...
config wifi-iface
option network wwan
option mode sta
option ssid 'remote AP2'
...
This scenario is untested and probably not valid without issuing an intervening ifup command which directs netifd to reload configuration information amongst which is /etc/config/wireless. Your test results are awaited.