Hi,

I've set up my router as a routing client though LuCI with 2 wireless networks, one as client (wwan) and another as ap/master (all in similar way as uqbar did - https://forum.openwrt.org/viewtopic.php … #p175185).

Everything is working fine when the client is available: both my LAN and W-LAN machines can talk to each other and access the internet through WWAN (a mobile hotspot). But, when I turn off the mobile hotspot the ap network shuts down. I would like the ap network to remain up so my wireless machines can still access the wired ones (like my NAS). Is this possible?

I'm using:
TP-Link TL-WR841N/ND v8.2
OpenWrt Attitude Adjustment 12.09-beta2 / LuCI 0.11 Branch (0.11+svn9402)

When I turn off the mobile hotspot, the log shows:
Jan 12 16:14:29 OpenWrt kern.info kernel: [29825.010000] br-lan: port 2(wlan0) entered disabled state

/etc/config/wireless

config wifi-device 'radio0'
    option type 'mac80211'
    option macaddr 'a0:f3:c1:35:7f:36'
    option hwmode '11ng'
    list ht_capab 'LDPC'
    list ht_capab 'SHORT-GI-20'
    list ht_capab 'SHORT-GI-40'
    list ht_capab 'TX-STBC'
    list ht_capab 'RX-STBC1'
    list ht_capab 'DSSS_CCK-40'
    option txpower '27'
    option country 'US'
    option distance '4'
    option htmode 'HT40+'
    option channel 'auto'

config wifi-iface
    option network 'wwan'
    option ssid 'WARLESS'
    option encryption 'psk2'
    option device 'radio0'
    option mode 'sta'
    option bssid '5C:0A:5B:F0:C9:58'
    option key 'key'

config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'WARLESS-TP'
    option network 'lan'
    option encryption 'psk-mixed'
    option key 'key'

/etc/config/network

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config interface 'lan'
    option ifname 'eth1'
    option type 'bridge'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'

config interface 'wan'
    option ifname 'eth0'
    option proto 'dhcp'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 4'

config interface 'wwan'
    option proto 'dhcp'

Any help would be appreciated, thanks.

https://dev.openwrt.org/ticket/12000
https://dev.openwrt.org/ticket/12018
https://dev.openwrt.org/ticket/12300

???

Failed to spot those, thank you nebbia88!

Makes sense.

Found a sort of workaround for this.

Based on http://wiki.openwrt.org/doc/howto/hardware.button I've configured the WPS button to enable/disable the client network. When client is disabled ap works as expected. I even use the WPS led to signal which state is on

Loving OpenWrt, a big thank you to all developers and community!

(Last edited by warchild on 12 Jan 2013, 21:00)

great idea!
can you post the details of how you configured button?

Sure.

I've followed all the steps in http://wiki.openwrt.org/doc/howto/hardware.button only changing the handler on system config file, instead of:

uci set system.@button[-1].handler='logger BTN_1 pressed'

I've used:

uci set system.@button[-1].handler='/sbin/woggle'

My /sbin/woggle is inspired on the one in http://wiki.openwrt.org/doc/howto/wifitoggle. Only had to change the interface name and led path.

#!/bin/sh

case "$(uci get wireless.@wifi-iface[0].disabled)" in
    1)
        uci set wireless.@wifi-iface[0].disabled=0
        wifi
        echo 0 > /sys/class/leds/tp-link\:green\:qss/brightness
    ;;
    *)
        uci set wireless.@wifi-iface[0].disabled=1
        wifi
        echo 1 > /sys/class/leds/tp-link\:green\:qss/brightness
    ;;
esac

Thanks, this works quite well! I've used http://grade2linux.wordpress.com/2013/0 … 9_buttons/ to get the button working. Also changed the behaviour: When the led is on, I can connect to the net and vise versa.

Great, enough info.

Thanks.

Hi

I have the same problem. Before I find this post I make this video which is describing the problem.

https://www.youtube.com/watch?v=bXpmvVAo1RY

This is very important for my project to solve this bug.
User needs ability to change wifi settings even WIFI spot is not available/broken and ect.

Developers, please fix it.

------
BARRIER BREAKER (v1.0a, r40512)

warchild, great workaround!

Implementing this, I came across wifitoggle package, which is versatile script to toggle Wi-Fi with a button.

Here is my setup to toggle particular Wi-Fi interface and use QSS led to give feedback about network activity on that interface.

/etc/config/wifitoggle

config wifitoggle
    option button 'wps'
    option persistent '1'
    option timer '0'
    option led_sysfs 'tp-link:green:qss'
    option led_enable_trigger 'netdev'
    option led_enable_mode 'link tx rx'
    option led_enable_dev 'wlan0'
    option device 'ap-network'
    option wifi_type 'iface'

/etc/config/wireless

[..]
config wifi-iface 'ap-network'
    option network 'wwan'
    option ssid 'NETWORK'
    option encryption 'psk2'
    option device 'radio0'
    option mode 'sta'
    option bssid '00:11:22:33:44:55'
    option key 'passkey'
    option disabled '0'
[..]

Also I had to apply this patch on /etc/hotplug.d/button/50-wifitoggle so the script can handle specific wireless interface instead of disabling the whole radio completely.

UPDATE:

Here is the patch’s code since the original URL may not work.

--- files/wifitoggle.hotplug.ori        2012-02-11 15:21:42.637259964 +0000
+++ files/wifitoggle.hotplug    2012-02-11 15:25:05.168970488 +0000
@@ -37,7 +37,7 @@

         config_load wireless
-        config_foreach save_wireless wifi-device
+        config_foreach save_wireless wifi-$wifi_type
         wifi
 }

@@ -141,6 +141,7 @@
        config_get_bool led_disable_default $1 led_disable_default "0"
        config_get led_disable_delayon $1 led_disable_delayon
        config_get led_disable_delayoff $1 led_disable_delayoff
+       config_get wifi_type $1 wifi_type "device"

         [ "$ACTION" = "$action" -a "$BUTTON" = "$button" ] && {

@@ -149,7 +150,7 @@
                if [ "$device" = "all" ]
                then
                        config_load wireless
-                       config_foreach load_wireless wifi-device
+                       config_foreach load_wireless wifi-$wifi_type
                else
                        disabled="$(uci get wireless."$device".disabled)"
                fi

(Last edited by sersh on 21 Jan 2015, 23:33)

I'm trying to solve this problem on a GL.iNet router which only has one button.  The normal function of the button is to toggle wifi on an off with a short press.  I want to reprogram it to disable the client network.

I think the that the solutions provided above worked on the older hotplug system, but I'm not sure that they are still the best way to do it with the current procd system.

Looking at the button actions in /etc/rc.button, it looks like I should be able to modify /etc/rc.button/rfkill to fix this.  Here's the code in that file:

#!/bin/sh

[ "${ACTION}" = "released" -o -n "${TYPE}" ] || exit 0

. /lib/functions.sh

local rfkill_state=0

wifi_rfkill_set() {
    uci set wireless.$1.disabled=$rfkill_state
}

wifi_rfkill_check() {
    local disabled
    config_get disabled $1 disabled
    [ "$disabled" = "1" ] || rfkill_state=1
}

config_load wireless
case "${TYPE}" in
"switch")
    [ "${ACTION}" = "released" ] && rfkill_state=1
    ;;
*)
    config_foreach wifi_rfkill_check wifi-device
    ;;
esac
config_foreach wifi_rfkill_set wifi-device
uci commit wireless
wifi up

I get a general idea of what this is doing, but I can't figure out how to change it to toggle off the client (WAN) interface.  Can anybody give me some tips on how to do this?

openwrt_bizmail, have you read the whole thread, in particular my post above yours?

The tip might be to try to look for 'wifi-iface' instead of 'wifi-device'.

I had the idea that your code is designed to toggle a specific pre-configured ssid.  I need to be able to toggle off any ssid which happens to be in use as the repeated network.  Does that work with your code or am I missing something?

Hmm... My guess, it’s not possible since you need to know interface name to disable, otherwise all of them will be turned off.

I found a good solution for my problem.  Caveat:  This solution is specifically for the 1-button GL.iNet router. You can probably do something similar with a different router, but there might be differences.  This is working on OpenWRT Barrier Breaker.

If you want to use this solution with a different router, you will need to carefully examine the config files in /etc/rc.button to see which one is launched by a particular button, then look downstream to see what file needs to be modified.

On this router, the button is normally set up to do two different functions: a short press toggles wifi off and on and a long press resets the router back to factory settings.  I wanted to change the function for a short press without disabling the ability to reset to factory (in case something goes wrong), so this approach doesn't change that.

On this router, a button press calls up this script: '/etc/rc.button/reset'.  On a short button press this script launches '/usr/bin/wifionoff'.  I modified this file to look like this:

#!/bin/sh
# device=$(uci -q get wireless.@wifi-device[0].disabled)
mode=$(uci -q get wireless.@wifi-iface[1].mode)
if [ "$mode" = "sta" ]; then
        uci delete wireless.@wifi-iface[1]    
        uci commit wireless
        uci set network.wan.ifname=eth0    
        uci commit network
        wifi
fi

This reconfigures two different config files:
'/etc/config/wireless' is changed to remove the wan/sta interface
'/etc/config/network' is modified to add the wan interface name to the config (this keeps ethernet wan working)

After making these changes, the 'wifi' command puts everything into operation.  This approach will remove the connection to any repeated ssid without having to having to specify which one is in use in advance.

This is a simple solution that should be pretty easy to maintain after firmware updates.  Please let me know if you have any questions.

(Last edited by openwrt_bizmail on 26 Jan 2015, 13:44)

I've had the same issue with the STA network taking down the AP network. Specifically, the Zsun wifi card reader only has a wifi interface, and killing the wifi leaves no option but a reset of the configuration. So I've come up with a workaround that I've posted to the (closed, wontfix) bug. Turns out that it is possible to have a working AP network while the defunct STA network is still active. In best "have you tried turning it off and on again" fashion, I run a script that takes down the AP interface and brings it back up whenever it loses its wireless configuration. This causes it to get reconfigured and reappear on the air, without taking down the station interface. I call the script from /etc/rc.local.

/root/wifi-watchdog.sh &

You might want to run it manually and see if it works for you before you make it run automatically. Here's the /root/wifi-watchdog.sh script. Don't forget to chmod u+x /root/wifi-watchdog.sh to make it executable. AP_DEV is the interface which is in access point mode.

#!/bin/sh

AP_DEV=wlan0-1

while ( true ) ; do
  if !( iw dev $AP_DEV info | grep -q ssid ) ; then
    logger wifi-watchdog: Wifi in trouble, to the rescue...
    ifconfig $AP_DEV down;
    ifconfig $AP_DEV up;
  fi
  sleep 5
done

It's a dirty hack, but it works for me. Use at your own risk.

(Last edited by johndoe on 14 Feb 2016, 01:13)

@openwrt_bizmail 
I believe that the code you have published is that of dwonderful and which I re-posted on the GLI.net forum with reference.  Alzhao suggest attaching it to the button. 
https://forum.openwrt.org/viewtopic.php … 30#p278230
http://www.gl-inet.com/forums/topic/ar- … #post-9488

In the future please give appropriate credit to the author(s) of the code.

@RangerZ

Honestly, it's been a year ago, and I don't remember where I got the code for that.  Looking at your previous post, it looks like I probably did use your code, so I apologize for using it without giving you credit.   In any case, having that mod available has been very useful for me.

Indeed, it is just that.

Elsewhere are system event-driven solutions.

No, Max, it is not just a dirty hack. It's also a very simple script (one script, not a collection of scripts) that doesn't need a separate "fail safe" configuration. Your workaround requires the user to keep two configurations in sync except for the STA iface. My hack exhibits one other important aspect: It shows that an active but unconnected STA interface and an AP interface can coexist. It is not technically necessary to turn off the STA interface to regain access to the AP interface. The reason why I'm not doing this in a hotplug script and use a watchdog loop instead is that there is no event specific to the AP interface losing its configuration. This "just happens". It might be possible to tie the test to events on other interfaces, but that's the "dirty hack" aspect: I stopped when it worked for me. If you want to make it beautiful, be my guest.

The number of scripts is 3 and the hack requires 2.  All of the scripts are passive meaning as a system event-driven solution they consume no resources until such time as recovery is required.  As for synchronisation of two configurations, the script, as a blackbox, SMOP if you will, can be extended to recover wireless connectivity without a pre-existing fail-safe configuration.

Really? Here -

the link indicates knowledge of the interfaces' states. the hack in contrast with the script makes an assumption as to the name of the physical device, which is a maintenance detail, and uses the lower level OpenWrt ifconfig operation.  the script, on the other hand, employs the system-wide wifi operation, whereby future enhancements in the wireless space by OpenWrt development are not excluded.

Indeed, you have given fair warning yet no such disclaimer is necessary over the script.  Not a minor point.

What is your problem, Max? I'm not trying to steal your show. I've posted an alternative way of getting around a problem. I said it's a hack, but despite its hackishness it shows something interesting, namely that something we were told was impossible is actually possible: A working AP interface with a defunct but enabled STA interface. Now that I know how people around here react when alternatives to their workarounds are posted, I'm kinda glad I didn't invest the time to flesh out the hack into a clean solution. Have a nice day.

The nub is that trading in innuendo and mistruths is evil with this serving as a prima facie evidence -

and their purveyors also.  Nowhere has it been stated that an configured section - wifi-iface of type ap cannot accept associations when a section - wifi-iface of type sta is present but cannot reach it's designated remote AP.  As for the outrageous claim that the behaviour of netifd is a bug when it complies with the industry standard, and who knows better here? johndoe or several thousand developers of networking software?, it is rich when delivered by a self-confessed hack.

As for the adoption of the script?  No pride of ownership is attached.  Test it and attack it.  Improve it and giveback.

The behavior of OpenWRT is to make the AP interface unavailable on the air if for whatever reason the STA interface can't connect. There are wifi devices with repeater functionality which don't have this limitation, even on the exact same hardware. Yet, this is the reason given for the "wontfix" status of the bug:

But as demonstrated, the wiphy can be used for AP mode operation while wpa_supplicant is scanning.
Dial down the attitude, kid.

I have just applied your workaround to my ZSUN and works perfectly! Thanks
I was wondering if you could look at this other issue http://forum.openwrt.org/viewtopic.php?pid=313458
I think you would have fun as well with hostapd-wpe

Thanks!