OpenWrt Forum Archive

Topic: [Howto](AAP) Automated Wifi network change if the current fails

The content of this topic has been archived between 1 Sep 2014 and 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

dabyd64 wrote:

Reboot and it will check again, or mod the script as you like.
It won't check the wifi while being connected because it will break internet everytime.
It only checks when it fails, then if WiFi1 is found it will connected to it.

thank your reply, dabyd64
but i'm not well in linux's script. can you help me? add one more script for me, it check curent SSID for every hours if not SSID1 then execute scanning with your's script (without checking network status)!
sorry, i'm not well english

(Last edited by phantnang on 6 Nov 2015, 09:20)

I'll mod the current wifimgr script if that helps you.
Now it will scan using the wlan0 interface, meaning that it will not cut internet when scanning, but I've not tested it thoroughly.

But keep in mind, that if the preferred network is enabled and not giving internet, everytime it scans, it will switch to that network, fail the internet checks and set a working network.
So, in that condition, it will give a short cut everytime it checks.
But if the network just dissapears, it will work silently.
Just replace your current wifiMgr.sh with this one: Download

(Last edited by dabyd64 on 6 Nov 2015, 15:37)

it can't change to SSID2 when SSID1 down but could reconnect SSID1 when it's up. Could you test and fix it for me? I propose one alternative is: adding another script, it execute 'wifiMgr.sh --force' when current SSID not SSID1, 'Scheduled Tasks' will execute this script for every hours with command '0 * * * * ./this_script'. but i don't know the syntax for this!
sorry my bad english
thank for your's all replies!

(Last edited by phantnang on 8 Nov 2015, 16:30)

Post the logs of your tests
Logread | grep wifiMgr

(Last edited by dabyd64 on 8 Nov 2015, 18:10)

shucks!!! the first test with wifimgr.sh is ok but after testing with openvpn i'm renew config and it fail. i'll test it again when free time. thank you very much, dabyd64.

(Last edited by phantnang on 10 Nov 2015, 03:35)

wifiMgrsh_1.0b not work! it' not change to preferred networks.

*my config file:
net1_ssid="15A3"
net1_encrypt="psk2"
net1_key="internet"

net2_ssid="15A2"
net2_encrypt="psk2"
net2_key="internet"

net3_ssid="OpenWifi"
net3_encrypt="psk2"
net3_key="internet"

*the log is here:
Nov 16 02:04:46 OpenWrt user.notice root: WifiMgr: Network OK, preferred network not found.
Nov 16 02:05:46 OpenWrt user.notice root: WifiMgr: Checking network...
Nov 16 02:05:50 OpenWrt user.info sysinit: sh: missing ]
Nov 16 02:05:53 OpenWrt user.notice root: WifiMgr: Network OK, preferred network not found.
Nov 16 02:06:53 OpenWrt user.notice root: WifiMgr: Checking network...
Nov 16 02:06:57 OpenWrt user.info sysinit: sh: missing ]
Nov 16 02:06:59 OpenWrt user.notice root: WifiMgr: Network OK, but switching to preferred network.
Nov 16 02:06:59 OpenWrt user.notice root: WifiMgr: WifiMgr: Searching available networks...
Nov 16 02:06:59 OpenWrt user.notice root: WifiMgr: OpenWifi network found. Applying settings..\

p/s: how to edit your's script?? i only change 'google.es' to 'google.com', it's fail!

(Last edited by phantnang on 16 Nov 2015, 03:23)

phantnang wrote:

wifiMgrsh_1.0b not work! it' not change to preferred networks.
p/s: how to edit your's script?? i only change 'google.es' to 'google.com', it's fail!

Try this, I think I had done a small error smile :
https://dl.dropboxusercontent.com/u/239 … r_1.0b.zip

Also, now you can change your ping target, just edit "PingTarget" inside config wink

(Last edited by dabyd64 on 19 Nov 2015, 21:27)

very thank you, dabyd64! it work well !!!!
but there's still "google.es" in script and "PingTarget" is not in config! it does not matter to me but I want more: suppose ssid1 is the first preferred network, ssid2 is 2nd, ssid3 is 3th....can you help me one more time. big_smile

(Last edited by phantnang on 19 Nov 2015, 18:10)

dabyd64 wrote:

Try this, I think I had done a small error smile :
https://dl.dropboxusercontent.com/u/239 … r_1.0b.zip

Also, now you can change your ping target, just edit "PingTarget" inside config wink

I have tested it thoroughly, it work. however it still bugs in a few situations. perhaps i must make by myself! can you give me some resources about scripts on openwrt.

dabyd64 wrote:

Oops, I forgot to upload the corrected version! tongue
Try now!
https://dl.dropboxusercontent.com/u/239 … r_1.0b.zip

it don't work, can't change next wifi when current ssid down!
my log:
Nov 20 13:51:50 OpenWrt user.notice root: WifiMgr: Checking network...
Nov 20 13:52:04 OpenWrt user.notice root: WifiMgr: Network failed. Starting network change...
Nov 20 13:52:04 OpenWrt user.notice root: WifiMgr: Netchange return
Nov 20 13:52:04 OpenWrt user.notice root: WifiMgr: WifiMgr: Searching available networks...
Nov 20 13:53:05 OpenWrt user.notice root: WifiMgr: Checking network...
Nov 20 13:53:20 OpenWrt user.info sysinit: ping: can't create raw socket: Address family not supported by protocol
Nov 20 13:53:20 OpenWrt user.notice root: WifiMgr: Network failed. Starting network change...
Nov 20 13:53:20 OpenWrt user.notice root: WifiMgr: Netchange return
Nov 20 13:53:20 OpenWrt user.notice root: WifiMgr: WifiMgr: Searching available networks...
Nov 20 13:54:20 OpenWrt user.notice root: WifiMgr: Checking network...
Nov 20 13:54:50 OpenWrt user.info sysinit: ping: bad address 'google.com'
Nov 20 13:54:50 OpenWrt user.notice root: WifiMgr: Network failed. Starting network change...
Nov 20 13:54:50 OpenWrt user.notice root: WifiMgr: Netchange return
Nov 20 13:54:50 OpenWrt user.notice root: WifiMgr: WifiMgr: Searching available networks...
Nov 20 13:55:35 OpenWrt daemon.info hostapd: wlan0: STA 9c:2a:70:1e:5e:1d IEEE 802.11: authenticated
Nov 20 13:55:35 OpenWrt daemon.info hostapd: wlan0: STA 9c:2a:70:1e:5e:1d IEEE 802.11: associated (aid 1)
Nov 20 13:55:35 OpenWrt daemon.info hostapd: wlan0: STA 9c:2a:70:1e:5e:1d WPA: pairwise key handshake completed (RSN)
Nov 20 13:55:35 OpenWrt daemon.info dnsmasq-dhcp[1464]: DHCPREQUEST(br-lan) 192.168.1.249 9c:2a:70:1e:5e:1d
Nov 20 13:55:35 OpenWrt daemon.info dnsmasq-dhcp[1464]: DHCPACK(br-lan) 192.168.1.249 9c:2a:70:1e:5e:1d PHONGVAN0304FTE
Nov 20 13:55:38 OpenWrt daemon.info dnsmasq-dhcp[1464]: DHCPINFORM(br-lan) 192.168.1.249 9c:2a:70:1e:5e:1d
Nov 20 13:55:38 OpenWrt daemon.info dnsmasq-dhcp[1464]: DHCPACK(br-lan) 192.168.1.249 9c:2a:70:1e:5e:1d PHONGVAN0304FTE
Nov 20 13:55:50 OpenWrt user.notice root: WifiMgr: Checking network...

(Last edited by phantnang on 20 Nov 2015, 16:58)

Edit: I saw the problem now.
I have to make different methods,  when the ssid goes down, and when it's ok and we just  want to check if the preferred network is available.
If the ssid goes down, also does the client interface, it breaks and no longer scans networks, so I have to disable the client mode in that case.
I think now it will work, redownload and try smile

(Last edited by dabyd64 on 21 Nov 2015, 13:57)

dabyd64 wrote:

Edit: I saw the problem now.
I have to make different methods,  when the ssid goes down, and when it's ok and we just  want to check if the preferred network is available.
If the ssid goes down, also does the client interface, it breaks and no longer scans networks, so I have to disable the client mode in that case.
I think now it will work, redownload and try smile

great! it seems to have worked perfectly! could you try another method for multi preferred SSID?

Just put your preferred ssids as ssid1,ssid2...
It will check always if you are on ssid1, if not, it will check if ssid1 is available and try to connect.
If ssid1 doesn't work, it will try the next preferred network, ssid2,ssid3, and so on.

dabyd64 wrote:

Just put your preferred ssids as ssid1,ssid2...
It will check always if you are on ssid1, if not, it will check if ssid1 is available and try to connect.
If ssid1 doesn't work, it will try the next preferred network, ssid2,ssid3, and so on.

can you write for me? and fixing not connect to hidden SSID!

(Last edited by phantnang on 23 Nov 2015, 06:12)

I don't know how to that, sorry...

dabyd64 wrote:
cabsandy wrote:
dabyd64 wrote:

No problem chaging that. I thought it would be the same as my wdr4900.
About the cronjob, it's easier that the current method, easy fix.
About the dual/single band compatibility, not that easy.
First, usually Broadcom and Ralink chipset give too many headaches, so this will be Atheros only...
Second, WiFi devices can have different names, ex.: wlan0 ath0 wlan1..I have to investigate how to detect this.
Let me check it out,
Cheers

Thanks for that-I think the 3600 is Ralink-I think! Dont give yourself too much hassle, can always go back to a standalone unit! :-)


Nope, it has Atheros AR9344! wink
http://wiki.openwrt.org/toh/tp-link/tl-wdr3600

Ok, I've done it different.
Just "config" and "ApScan.sh". Edit the config file and run ApScan.sh everytime you want to perform a scan, from cronjob or any other method you want to use.

I gave up on trying to detect the device, it probably would cause problems and give a lot of work.
So, different scripts for 2.4G only and dual band.
For 2.4G only devices, wlan0 is used.
For dual band WDR3600, wlan0 for 2.4G and wlan1 for 5G.
For dual band WDR4900, wlan1 for 2.4G and wlan0 for 5G.

ApScan 1.0b

Regards wink

Hi there- Happy New Year!

Been away for a while but finally found a spare unit to test this on-using the Apscan.sh from the WDR3600 folder, the script runs through the 2.4G scan and finds, and pings, the 2 networks in the config file. But it cannot find the 5G networks I have-I know the AP can see them, as when you do a manual scan from the Luci web interface, it see's the 5G SSID no problem.
Is there any logs or info I can supply that would help in troubleshooting this?

##Update 17-01-2015-looks like the 5G IS working now, in a different physical location! Not sure why, maybe my bad :-). Great little script.##

cheers

cabs

(Last edited by cabsandy on 17 Jan 2016, 12:07)

Hi, I dropped the ball and did not select the subscribe checkbox so I missed your reply.
https://forum.openwrt.org/viewtopic.php … 79#p295179

I do really need the ability to wirelessly access the device if there is no STA\Client available.  It carries a USB data device for sharing and the router would not be usable with this tool of there is no WAN, and as a result LAN. 

I currently have the device setup with a button action to delete the STA config section completely when the STA goes away.  I use the script from here in the button event, as opposed to the original intent of a startup script.  https://forum.openwrt.org/viewtopic.php … 30#p278230 

If the function runs and finds no STA what would it do?

If I connect to a station not in the list, I am of the opinion, as it just pings and gets a success, it will leave all alone.

Additionally, are there any restrictions on the SSIDs and keys for characters?  Specifically can one use other than A-Z and 0-9 in the SSID.

How difficult would it be to write the happenings to a log file in tmp.  This post then makes it real easy to show the content on a tab in Luci. https://forum.openwrt.org/viewtopic.php?id=58715

Is this tested on CC 15.05?

(Last edited by RangerZ on 10 Jan 2016, 02:50)

I took the plunge and installed the tool, but having some issues.

In my case, the wireless file has the AP section before the STA section, and the tool is updating the AP section instead of the STA. 

It also seems to have modified my firewall and network sections, removing the WAN from the network.  I do not see a difference in the firewall, but the date and time are changed.

The big problem is I can not stop the program.

I tried /etc/init.d/wifiMgr stop and I get a response of "no wifiMgr.sh found; none killed".
The controls in Luci also do not terminate the program.
I renamed the files to *off and seems to be back in control.

If I switch around the two wifi-iface sections, the tool appears to update the first wifi-iface, now for the STA.  I think because my other tool removes the STA, when a new wifi-iface is created it's added after.  I am guessing that you are not checking if you are updating the AP or the STA, and updating the first section in the file.

I am running CC15.05 on a GLI Ar-150.

RangerZ wrote:

Hi, I dropped the ball and did not select the subscribe checkbox so I missed your reply.
https://forum.openwrt.org/viewtopic.php … 79#p295179

I do really need the ability to wirelessly access the device if there is no STA\Client available.  It carries a USB data device for sharing and the router would not be usable with this tool of there is no WAN, and as a result LAN. 

I currently have the device setup with a button action to delete the STA config section completely when the STA goes away.  I use the script from here in the button event, as opposed to the original intent of a startup script.  https://forum.openwrt.org/viewtopic.php … 30#p278230 

If the function runs and finds no STA what would it do?

If I connect to a station not in the list, I am of the opinion, as it just pings and gets a success, it will leave all alone.

Additionally, are there any restrictions on the SSIDs and keys for characters?  Specifically can one use other than A-Z and 0-9 in the SSID.

How difficult would it be to write the happenings to a log file in tmp.  This post then makes it real easy to show the content on a tab in Luci. https://forum.openwrt.org/viewtopic.php?id=58715

Is this tested on CC 15.05?

This scripts doesn't search "stations" or clients. Only Access points, tries to connect to them, and will loop endlessly if none are good.
It's very easy to write the script logs, just like:

 logread | grep "WifiMgr" >/tmp/wifiMgr.log

That will paste all the wifiMgr related output in that file. Yes, it's tested on 15.05.
I have tested only on Atheros hardware, I won't try on other devices that I don't have.








RangerZ wrote:

I took the plunge and installed the tool, but having some issues.

In my case, the wireless file has the AP section before the STA section, and the tool is updating the AP section instead of the STA. 

It also seems to have modified my firewall and network sections, removing the WAN from the network.  I do not see a difference in the firewall, but the date and time are changed.

The big problem is I can not stop the program.

I tried /etc/init.d/wifiMgr stop and I get a response of "no wifiMgr.sh found; none killed".
The controls in Luci also do not terminate the program.
I renamed the files to *off and seems to be back in control.

If I switch around the two wifi-iface sections, the tool appears to update the first wifi-iface, now for the STA.  I think because my other tool removes the STA, when a new wifi-iface is created it's added after.  I am guessing that you are not checking if you are updating the AP or the STA, and updating the first section in the file.

I am running CC15.05 on a GLI Ar-150.

If you are mixing different scripts, check them all. If I understand correctly, you have two wlan interfaces on a single radio device, in ap+sta (repeater) mode?
If so, make sure that the file /etc/config/wireless has the STA first, before the AP interface.
It just touches "wireless.@wifi-iface[0]".
To check it, just type "uci show wireless" and paste the results, I guess that wifi-iface[0] is AP and wifi-iface[1] is STa in your case.
If so, just put them in reverse order in the config file.
The script doesn't have any action when it doesn't find the APs, it just searches until one works, that what it was created for.

(Last edited by dabyd64 on 19 Jan 2016, 16:42)

Thanks for the followup.  I have learned a bit since my post.  There is one each WWAN and WLAN.  I currently have the code removed, and will try to test again in a few days.

I am using a GLI AR150 with a button on it and currently have a button action to remove the STAtion (WWAN) on demand.  This moves the WLAN to wifi-iface[0].  I (think) I need this as I have found that I can not connect wirelessly to the WLAN if the WWAN (STA\client) is unavailable.  I do not write code and not sure if changing the disabled from 0 to1 would do the same.

Regarding the tool set, I am of the opinion that if no WWAN (STA/client) is found in the list, that the existing config is left as is, and the WLAN will be unavailable, but have not been able to test this.  I still want to use the device to share media even when there is no WWAN.  This means that I need a cable to connect to the LAN side, and that does not work for phones or tablets (in a car for example).  The button action addresses this.

Understanding this should I be able to change the wifi-iface[0] to wifi-iface[1] to remove the second entry?  I expect so.

Also, if setting the disabled flag from 0 to 1 address the WLAN availability issue, then is it reasonable to have this as a step after the last entry in the list is found to be unavailable.  It would also mean the disabled flag would need to be set to 0 when you replace the SSID, key and encryption?  Will this still allow you to scan?

If this concept works, then I could replace the button function, but if I can keep it that's better.  The inability to access the device is critical when there is not WWAN, and the backup is reassuring.  What happens if there is no wifi-iface[1]?

(Last edited by RangerZ on 20 Jan 2016, 15:06)

Considering the script of dabyd64 with it's looping method which handles recovery from association failures, finding a definitive source for network topology changes became the goal. That was found in the ubus service.

Scripting to detect and recover from all failures, e.g., incorrect password or SSID, loss of association with a remote AP, etcetera, was written once the basics of ubus and the JSON scripting library, jshn.sh, were understood.

Herewith the steps and code:

Create a fallback 'AP-only' configuration -

cp /etc/config/wireless /etc/config/wireless_AP

Edit /etc/config/wireless_AP, delete the wifi-interface section containing the STA definition, and save.
Edit /etc/config/wireless adding a new section and save -

    config wifi-repeater 'STA_name'
    option interface wwan # this is also the value of 'option network XXXX' in the STA section
    option wait 15

Create a directory for the script -

mkdir /usr/local/bin

Place the script in /usr/local/bin/revert_to_AP.sh -

#!/bin/sh
# Restore wireless access to the local AP for STA (Client) failures (association or login) with a remote AP (revert to 'AP-only') configuration.
. /usr/share/libubox/jshn.sh
local _rc _sta_err
let _sta_err++
json_init
json_load $(ubus -S call network.interface."$2" status)
json_get_var _rc up
while  [ $_rc = 0 ] || [ $ACTION = ifdown -a $_rc = 0 ]
    do
        if [ $((_sta_err * 3)) -ge $1 ]; then
            cp /etc/config/wireless /etc/config/wireless_AP+STA
            cp /etc/config/wireless_AP /etc/config/wireless
            wifi down
            wifi up
            sleep 3
            mv -f /etc/config/wireless_AP+STA /etc/config/wireless
            break
        fi
        sleep 3
        json_load $(ubus -S call network.interface."$2" status)
        json_get_var _rc up
        let ++_sta_err
    done
json_cleanup

N.B. the script will unconditionally restore the AP + STA configuration because it detects and recovers from all failures.

Place this filter script in /etc/hotplug.d/net/99-recover-STA -

#!/bin/sh
logger -t DEBUG -s "hotplug (net): action='$ACTION' devicename='$DEVICENAME' devname='$DEVNAME' devpath='$DEVPATH' product='$PRODUCT' type='$TYPE' interface='$INTERFACE'"

. /usr/share/libubox/jshn.sh
local _wwan _wait _device _up
_wwan=$(uci -q get wireless.STA_name.interface)
[ -z "$_wwan" ] && _wwan=wwan # <-- a popular name for 'repeater STAs'
_wait=$(uci -q get wireless.STA_name.wait)
[ -z "$_wait" ] && _wait=15
json_init
# the interface is known but not the device
json_load $(ubus -S call network.interface."$_wwan" status)
# the update to the ubus object might be delayed...
json_get_var _up up
[ "$_up" = 0 ] && sleep $_wait && json_load $(ubus -S call network.interface."$_wwan" status)
# extract the device that is hosting the STA interface
json_get_var _device device
json_cleanup
if [ $_device -a "$ACTION" = add -a "$INTERFACE" = "$_device" ]; then
    /bin/sh /usr/local/bin/revert_to_AP.sh $_wait $_wwan
fi

Place this filter script in /etc/hotplug.d/iface/99-recover-STA -

#!/bin/sh
logger -t DEBUG "hotplug (iface): action='$ACTION' devicename='$DEVICENAME' devname='$DEVNAME' devpath='$DEVPATH' product='$PRODUCT' type='$TYPE' interface='$INTERFACE'"

local _wwan _wait
_wwan=$(uci -q get wireless.STA_name.interface)
[ -z "$_wwan" ] && _wwan=wwan # <-- a popular name for 'repeater STAs'
_wait=$(uci -q get wireless.STA_name.wait)
[ -z "$_wait" ] && _wait=15
if [ "$ACTION" = ifdown -a "$INTERFACE" = "$_wwan" ]; then
    /bin/sh /usr/local/bin/revert_to_AP.sh $_wait $_wwan
fi

N.B. the logger commands in the filter scripts can safely be removed but are useful with

logread -e DEBUG

EDIT: replaced calls to network_is_up (returns 0 when the target is unavailable) with json calls
EDIT: placed comments in 99-recover-STA
EDIT: jow explained the operation of network_is_up and network_flush_cache here and closed the ticket 'worksforme'

Max, thanks for your reply.  I have to admit the code is beyond my skill set, so I would like to make sure I understand a few things that may be obvious to others.  I do most of my work with WinSCP to edit and create files/folders/permissions.  Let me know if this causes and issues. 

You are asking me to add a 4th section to the wireless file as follows

config wifi-device 'radio0'
....

config wifi-iface
    option network 'lan'
    ....

config wifi-iface 'sta'
    option network 'wan'
    ....

config wifi-repeater' 'STA_[mynamehere]'   (should match the 'sta' above?)
    option interface wwan
    option wait 15

I have the "STA" as wan, not wwan.  Can I replace the wwan with wan?  If I recall correctly, when I manually, in LuCi, connect to a new STAtion, the defaults would have me ending up with both a wan and wwan and one had no config.  Don't remember and can not test right now, but want to avoid this when I manually config a new station NOT in the list of stations file.

Create a new directory structure under /usr called /loacl/bin and add the file revert_to_AP.sh
What permissions do I want on the folders and files? 0755?

Similar with 99-recover-STA to the respective hotplug.d sub-directories.  No *.sh on the files.  Same question on permissions please?

Do I run logread -e DEBUG from putty CLI?

Do I need to install something for the usbus service?

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?

I have a new device on the way and will test on that.  I have a working VPN client and don't want to mess that up (again).  It will be a few days at least until I can tackle this.

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.

@Max Hopper

I have tried to implement your solution, however have not been able to make it work. 

I configured the components and worked with a know functioning AP which I could easily power off.  I ran this for a while and had the wireless file wifi-iface configured both with and without (I think the correct way) a name (STA_name).  When I removed power from the configured AP, in neither case did the code create the wireless_AP+STA file or make any changes to the wireless file.  I have included my configs and logreads.  Maybe they will be of value or identify a configuration error on my side.

With the STA_name
wireless

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path '10180000.wmac'
    option htmode 'HT20'
    option txpower '20'
    option country 'US'
    option channel '7'

config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'MLGW2'
    option network 'lan'
    option encryption 'psk2'
    option key 'password'
    option disabled '0'

config wifi-iface 'STA_name'
    option network 'wwan'
    option encryption 'psk2'
    option device 'radio0'
    option mode 'sta'
    option ssid 'Galactica'
    option key 'password'
    option disabled '0'

config wifi-repeater 'STA_name'
        option interface wwan # this is also the value of 'option network XXXX' in the STA section
        option wait 15

wireless_AP

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path '10180000.wmac'
    option htmode 'HT20'
    option txpower '20'
    option country 'US'
    option channel '7'

config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'MLGW2'
    option network 'lan'
    option encryption 'psk2'
    option key 'password'
    option disabled '0'
/etc/hotplug.d/iface$ logread -e DEBUG
Thu Feb 11 20:56:25 2016 user.notice DEBUG: hotplug (net): action='add' devicename='br-lan' devname='' devpath='/devices/virtual/net/br-lan' product='' type='' interface='br-lan' 
Thu Feb 11 20:56:25 2016 user.notice DEBUG: hotplug (net): action='add' devicename='eth0.1' devname='' devpath='/devices/virtual/net/eth0.1' product='' type='' interface='eth0.1' 
Thu Feb 11 20:56:26 2016 user.notice DEBUG: hotplug (net): action='remove' devicename='wlan0' devname='' devpath='/devices/10180000.wmac/net/wlan0' product='' type='' interface='wlan0' 
Thu Feb 11 20:56:27 2016 user.notice DEBUG: hotplug (net): action='add' devicename='wlan0' devname='' devpath='/devices/10180000.wmac/net/wlan0' product='' type='' interface='wlan0' 
Thu Feb 11 20:56:29 2016 user.notice DEBUG: hotplug (iface): action='ifup' devicename='' devname='' devpath='' product='' type='' interface='lan' 
Thu Feb 11 20:56:30 2016 user.notice DEBUG: hotplug (iface): action='ifup' devicename='' devname='' devpath='' product='' type='' interface='loopback'

Without the STA_name
wireless

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path '10180000.wmac'
    option htmode 'HT20'
    option txpower '20'
    option country 'US'
    option channel '7'

config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'MLGW2'
    option network 'lan'
    option encryption 'psk2'
    option key 'password'
    option disabled '0'

config wifi-iface 
    option network 'wwan'
    option encryption 'psk2'
    option device 'radio0'
    option mode 'sta'
    option ssid 'Galactica'
    option key 'password'
    option disabled '0'

config wifi-repeater 'STA_name'
        option interface wwan # this is also the value of 'option network XXXX' in the STA section
        option wait 15
/etc/config$ logread -e DEBUG
Thu Feb 11 21:14:50 2016 user.notice DEBUG: hotplug (net): action='add' devicename='br-lan' devname='' devpath='/devices/virtual/net/br-lan' product='' type='' interface='br-lan' 
Thu Feb 11 21:14:50 2016 user.notice DEBUG: hotplug (net): action='add' devicename='eth0.1' devname='' devpath='/devices/virtual/net/eth0.1' product='' type='' interface='eth0.1' 
Thu Feb 11 21:14:50 2016 user.notice DEBUG: hotplug (net): action='remove' devicename='wlan0' devname='' devpath='/devices/10180000.wmac/net/wlan0' product='' type='' interface='wlan0' 
Thu Feb 11 21:14:52 2016 user.notice DEBUG: hotplug (net): action='add' devicename='wlan0' devname='' devpath='/devices/10180000.wmac/net/wlan0' product='' type='' interface='wlan0' 
Thu Feb 11 21:14:52 2016 user.notice DEBUG: hotplug (net): action='add' devicename='wlan0-1' devname='' devpath='/devices/10180000.wmac/net/wlan0-1' product='' type='' interface='wlan0-1' 
Thu Feb 11 21:14:55 2016 user.notice DEBUG: hotplug (iface): action='ifup' devicename='' devname='' devpath='' product='' type='' interface='lan' 
Thu Feb 11 21:14:55 2016 user.notice DEBUG: hotplug (iface): action='ifup' devicename='' devname='' devpath='' product='' type='' interface='loopback' 
Thu Feb 11 21:16:08 2016 user.notice DEBUG: hotplug (iface): action='ifup' devicename='' devname='' devpath='' product='' type='' interface='wwan' 

after a few minutes i reran the log read

/etc/config$ /etc/config$ logread -e DEBUG
-ash: /etc/config$: not found

after rebooting the AP the logread returned no results or errors.

/etc/config$ /etc/config$ logread -e DEBUG

I neglected to note exactly when, but at one point I looked at the Luci WiFi and found both wireless connections showing as disabled, but the config file said "Status 0".  Did not make any real sense to me.  It's contradictory.

I am of the opinion that this solution does not meet the functional requirement I seek, and offered by the author of this post.  It recovers a single AP, and I am not capable of enhancing it to validate the additional APs as you suggest.

@dabyd64

I have made a few modifications to your code and happy to say that I can now recover from a lost AP.  I have added a line to set the wifi-iface status to 1 and back to 0 when enabled.

To help survive after adding a manual AP (via Luci Wifi Scan) I have also added a line to remove the BSSID.

There is now a variable which let the user set his own choice of location to ping against.

Finally I have added a sleep variable just before the first scan.  I was finding that the search was frequently starting before the wireless was  available and then one would need to wait an additional minute to find an AP.  This finds an AP faster.

I have written a modified LuCi status page and directed the logs to this page.  It's a simple copy and replace to implement.

I have added the package luci-app-commands to my router.  This package lets one create a set of user defined buttons to execute shell functions.  I created a button for each of the major APs I use with the force command.  No need to leave the GUI and start a shell.

I have two issues. 
1 - Reboot - It appears that the reboot function in LuCi does not work when this code is in place.  If I remove the file in the init.d folder and restart all works well.  I have solved this with the luci-app-commands and created a button for "reboot -f"
2 - I have been doing much of my testing with a Ethernet cable to my devices LAN port so I could use the wireless to manage the various test APs.  I have noticed that many times the device's Ethernet times out, and that I need to enable the devices WLAN.

The first is somehow related to the code as it appears removing the file fixes the boot issue.  I am unclear if the Reboot -f is somehow driving the second issue or if it is otherwise device related.

I am not sure either is will be a real issue in practice, as it's a travel router and will mostly get turned on and off with the power button.

I have posted the modified code here.  http://www.gl-inet.com/forums/topic/wif … post-11953

The code functions and has the reboot issue on both an AR71xx and MT7620N .

(Last edited by RangerZ on 14 Feb 2016, 00:13)