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
Comments
dibdot: Hi, I'm using the package 'travelmate' on my travel router, give it a try. |
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.
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
|
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). |
httpstorm: I know loosing access to your router can be quite frustrating.
|
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.
The text was updated successfully, but these errors were encountered: