Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#499 - WiFi client mode leaves router inaccessible if upstream network goes down #5519

Open
openwrt-bot opened this issue Feb 11, 2017 · 4 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Feb 11, 2017

nick:

This bug was originally reported to the OpenWrt team and there is a [[https://lists.openwrt.org/pipermail/openwrt-devel/2017-February/042712.html|discussion of it in their mailing list]]. Luiz Angelo Daros de Luca suggested reporting here (and switching to LEDE, which I will do).

I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm using it to provide a WiFi access point to my phone/tablet while I travel, and it's acting as a WiFi client for the various hostels I visit.

If you configure it as a wifi client with a wwan interface using the LuCI scan/join wizard, and then you configure a wifi access point on the same radio, the router works as expected and when you connect to the router's AP, you get Internet via the client connection.

However, if you move out of range of the network the router is a client of, or if it goes down, when you power off the OpenWrt router and power back on, the access point won't come up.

The AP will only come up if the client network you configured is also working; so you have no way to connect to the router over wifi, and no way to reconfigure the router, if that client network is down or out of range.

This is a particular problem for a travel router because it will often move it out of range of the original upstream network, and you may only have a wifi-capable device with which to reconfigure it.

The Ethernet port on the router does remain active, so I can tell it does actually boot. It's just the radio that doesn't come up. I managed to get back in range of a network once, and the router worked as expected.

It doesn't matter whether the AP or client connection are configured first or second on the radio interface, and, unticking "bring up on boot" for the wwan interface has no effect on the behaviour.

Steps to reproduce: Connect the router to a wifi network as a client using the Join wizard. Add a wifi master-mode access point on the same radio interface. Verify you can access the Internet by joining the router's new master AP. Reboot the router with the original network it was a client of turned off. Notice the router's AP you configured never comes up.

Expected behaviour: The master access point of the router should always come up, regardless of the availability of the client network.

The OpenWRT team will not fix it, but [[https://lists.openwrt.org/pipermail/openwrt-devel/2017-February/042732.html|had some explanation as to why it is happening]]. IMO, it's still a very frustrating bug and most users would expect the behaviour I did.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jul 1, 2017

dibdot:

Hi,

I'm using the package 'travelmate' on my travel router, give it a try.
[[https://github.com/openwrt/packages/blob/master/net/travelmate/files/README.md|Travelmate description]]

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jul 25, 2018

lucize:

I stumble upon this problem too, using a ramips device, the thing is that if you configure multiple client wireless profiles it will work if one of them is connected.
I'm on OpenWrt SNAPSHOT, r7540-20c4819

Wed Jul 25 03:33:13 2018 daemon.notice netifd: radio0 (1067): command failed: Not supported (-122) Wed Jul 25 03:33:14 2018 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf Wed Jul 25 03:33:14 2018 kern.info kernel: [ 56.619556] br-lan: port 2(wlan0-1) entered blocking state Wed Jul 25 03:33:14 2018 kern.info kernel: [ 56.630700] br-lan: port 2(wlan0-1) entered disabled state Wed Jul 25 03:33:14 2018 kern.info kernel: [ 56.642342] device wlan0-1 entered promiscuous mode Wed Jul 25 03:33:14 2018 daemon.notice hostapd: wlan0-1: interface state UNINITIALIZED->COUNTRY_UPDATE Wed Jul 25 03:33:14 2018 daemon.err hostapd: Using interface wlan0-1 with hwaddr a0:f4:59:0d:2a:95 and ssid "OpenWrt-3G" Wed Jul 25 03:33:14 2018 daemon.notice hostapd: wlan0-1: interface state COUNTRY_UPDATE->ENABLED Wed Jul 25 03:33:14 2018 daemon.notice hostapd: wlan0-1: AP-ENABLED Wed Jul 25 03:33:15 2018 daemon.notice netifd: radio0 (1067): Successfully initialized wpa_supplicant Wed Jul 25 03:33:17 2018 daemon.notice netifd: Interface 'wwan' is enabled ed Jul 25 03:34:09 2018 daemon.notice hostapd: handle_probe_req: send failed Wed Jul 25 03:34:09 2018 daemon.notice hostapd: handle_probe_req: send failed Wed Jul 25 03:34:14 2018 daemon.notice hostapd: handle_probe_req: send failed Wed Jul 25 03:34:39 2018 daemon.notice hostapd: handle_probe_req: send failed Wed Jul 25 03:35:05 2018 daemon.notice hostapd: handle_probe_req: send failed Wed Jul 25 03:35:05 2018 daemon.notice hostapd: handle_probe_req: send failed Wed Jul 25 03:35:12 2018 daemon.notice hostapd: handle_probe_req: send failed root@portable-3g:~# iwinfo wlan0 ESSID: unknown Access Point: 00:00:00:00:00:00 Mode: Client Channel: unknown (unknown) Tx-Power: 30 dBm Link Quality: unknown/70 Signal: unknown Noise: unknown Bit Rate: unknown Encryption: unknown Type: nl80211 HW Mode(s): 802.11bgn Hardware: unknown [Generic MAC80211] TX power offset: unknown Frequency offset: unknown Supports VAPs: yes PHY name: phy0

wlan0-1 ESSID: "OpenWrt-3G"
Access Point: xx:xx:59:0D:2A:xx
Mode: Master Channel: 10 (2.457 GHz)
Tx-Power: 30 dBm Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jul 29, 2018

cshoredaniel:

You could also try dynapoint (luci-app-dynapoint for gui) from the packages and/or luci repos. This disables/enables wifi networks depending on the the presence/absence of an internet connection. I use it to have an admin wifi come up if the internet connection goes down.

Actually for my AP's I've even set up a uhttpd instance on the primary router so that the AP's wget/curl from it instead of internet servers, so they only do the admin interface if the main router goes down (since if the main router is up for them, I can easily access from a local network).

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Sep 14, 2020

httpstorm:

I know loosing access to your router can be quite frustrating.
My solution: did you know that the buttons on your router trigger a script where you can take any actions? You can also query how long a button has been held and trigger a different action. Example:

# /etc/rc.button/{rfkill,wps}

if [ "$SEEN" -lt 1 ]
then
# toggle: gPhone7
case "$(uci get wireless.radio0_gPhone.disabled)" in
1)
echo "gPhone.enabled" > /dev/console
logger "gPhone.enabled"
uci set wireless.radio0.noscan=0
uci set wireless.radio0_gPhone.disabled=0
uci commit
wifi
;;
*)
echo "gPhone.disabled" > /dev/console
logger "gPhone.disabled"
uci set wireless.radio0.noscan=1
uci set wireless.radio0_gPhone.disabled=1
uci commit
wifi

		/etc/init.d/network restart
		/etc/init.d/openvpn restart
	;;
esac

elif [ "$SEEN" -lt 3 ]
then
# less than 3 seconds
fi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant