Master network goes down if Wireless client can't connect

Installing and Using OpenWrt
1

Hi,

I'm using one of my Openwrt devices as a Wireless Client to extend range into my garage.

INTERNET router ---wifi--- Wireless Client ----wifi---- Garage

The device has been put in the middle and there is no ethernet connection. All works fine and I'm able to access internet from my garage where previously wireless signal was too poor

One day I changed WPA PSK on my internet router and I went to my Wireless Client to update the password there as well. But I could no longer connect to it. Hotspot went down. Rebooting did not help. So I physically detached the device and used ethernet cable to update the password.

Since physical access to that device is problematic I would like to ensure that in future I would not need to detach it in order to update WPA PSK.

The issue is reproducible locally. Just create a Wireless Client and a Master wireless networks (for a clean test use different ESSID and passwords). As soon as you change the upstream WPA PSK - Master network will go down too. The log shows this loop:

Sun Jun 30 12:00:51 2019 daemon.notice wpa_supplicant[14058]: wlan0: SME: Trying to authenticate with ee:08:6b:e8:15:2f (SSID='gst' freq=2437 MHz)
Sun Jun 30 12:00:51 2019 kern.info kernel: [ 5834.274691] wlan0: authenticate with ee:08:6b:e8:15:2f
Sun Jun 30 12:00:51 2019 kern.info kernel: [ 5834.349472] wlan0: send auth to ee:08:6b:e8:15:2f (try 1/3)
Sun Jun 30 12:00:51 2019 kern.info kernel: [ 5834.366015] wlan0: authenticated
Sun Jun 30 12:00:51 2019 daemon.notice wpa_supplicant[14058]: wlan0: Trying to associate with ee:08:6b:e8:15:2f (SSID='gst' freq=2437 MHz)
Sun Jun 30 12:00:51 2019 kern.info kernel: [ 5834.445381] wlan0: associate with ee:08:6b:e8:15:2f (try 1/3)
Sun Jun 30 12:00:51 2019 kern.info kernel: [ 5834.513309] wlan0: RX AssocResp from ee:08:6b:e8:15:2f (capab=0x31 status=0 aid=3)
Sun Jun 30 12:00:51 2019 kern.info kernel: [ 5834.529818] wlan0: associated
Sun Jun 30 12:00:51 2019 daemon.notice netifd: Network device 'wlan0' link is up
Sun Jun 30 12:00:51 2019 daemon.notice netifd: Interface 'wwan' has link connectivity
Sun Jun 30 12:00:51 2019 daemon.notice netifd: Interface 'wwan' is setting up now
Sun Jun 30 12:00:51 2019 daemon.notice wpa_supplicant[14058]: wlan0: Associated with ee:08:6b:e8:15:2f
Sun Jun 30 12:00:51 2019 daemon.notice wpa_supplicant[14058]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Sun Jun 30 12:00:52 2019 daemon.notice netifd: wwan (14224): udhcpc: started, v1.31.0
Sun Jun 30 12:00:52 2019 daemon.notice netifd: wwan (14224): udhcpc: sending discover
Sun Jun 30 12:00:55 2019 kern.info kernel: [ 5838.463980] wlan0: deauthenticated from ee:08:6b:e8:15:2f (Reason: 2=PREV_AUTH_NOT_VALID)
Sun Jun 30 12:00:55 2019 daemon.notice netifd: Network device 'wlan0' link is down
Sun Jun 30 12:00:55 2019 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Sun Jun 30 12:00:55 2019 daemon.notice wpa_supplicant[14058]: wlan0: CTRL-EVENT-DISCONNECTED bssid=ee:08:6b:e8:15:2f reason=2
Sun Jun 30 12:00:55 2019 daemon.notice wpa_supplicant[14058]: wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
Sun Jun 30 12:00:55 2019 daemon.notice wpa_supplicant[14058]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="gst" auth_failures=3 duration=30 reason=WRONG_KEY
Sun Jun 30 12:00:55 2019 daemon.notice netifd: wwan (14224): udhcpc: sending discover
Sun Jun 30 12:00:55 2019 daemon.notice netifd: wwan (14224): udhcpc: received SIGTERM
Sun Jun 30 12:00:55 2019 daemon.notice netifd: Interface 'wwan' is now down
Sun Jun 30 12:00:55 2019 daemon.notice netifd: Interface 'wwan' is disabled
Sun Jun 30 12:00:55 2019 daemon.notice netifd: Interface 'wwan' is enabled
Sun Jun 30 12:01:06 2019 daemon.notice hostapd: handle_probe_req: send failed
Sun Jun 30 12:01:08 2019 daemon.notice hostapd: handle_probe_req: send failed
Sun Jun 30 12:01:16 2019 daemon.notice hostapd: handle_probe_req: send failed
Sun Jun 30 12:01:18 2019 daemon.notice hostapd: handle_probe_req: send failed
Sun Jun 30 12:01:18 2019 daemon.notice hostapd: handle_probe_req: send failed
Sun Jun 30 12:01:23 2019 daemon.notice hostapd: handle_probe_req: send failed
Sun Jun 30 12:01:24 2019 daemon.notice hostapd: handle_probe_req: send failed

My question: is there a way to resolve this so my Master network remains up regardless of the upstream Wireless Client connection?

Thank you

2

This is a known shortcoming of this configuration.
Luckily a package has been developed to make this a lot more friendly. Search for "travelmate"

2 Likes
3

When you're doing a reconfiguration that will temporarily break the connection, change it in the client router first, then in the main router.

4

If I first change the Client WPA configuration then network goes down, the browser disconnects, LUCI fails to verify the settings and reverts everything back

5

If this is causing you confusion, just make the changes while connected via Ethernet.

6

did you find a workaround :wink:

its been 4 years, I know, curious

I have a similar wonder... if wifi client goes down, wifi master goes down, wondering if there is a way to isolate the two or rather make them independent and client can retry in the background

1 Like
7

@redchilis - In the case of a single radio acting as both a client (sta mode) and an AP, it is necessary for the sta mode connection to be established first because the upstream AP determines the channel that must be used for the radio in the downstream device (for both sta and AP modes). Because of this, if the upstream connection cannot be established, the AP cannot start.

There is a very good workaround, thouhg -- check out Travelmate which is designed exactly for this situatoin.

5 Likes
8

thank you

I was confused, the wording 'travelmate' threw me off, was looking at 'wlan3', multiwan as an option :confused:

reading your post, understanding the terminology ('sta mode connection', specifically), it is in tandem with 'travelmate' terminology and now makes complete sense, thank you