WRT1900ACSv2 Only One WiFi Radio is Staying Up

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi

Not sure if it's a bug but I have major problems with the wireless radios on my Linksys WRT1900ACSv2 whereby after the last client has disconnected from the AP the WiFi stops working on that radio.

If I go into Network > Wireless in LuCI and click the Restart button on the 2.4 or 5GHz radio that radio is the only radio that stays working, whereas the other one says disabled and wireless not associated.

WiFi Issues
WiFi Issues973×395 34 KB

I'm able to replicate the issue every time by going into Network > Wireless and clicking the Disconnect button against each connected client. The client is then unable to connect. If I then click the Restart button on a particular radio, clients are then able to connect to that one radio only. If I click the Restartbutton on thedisabledandwireless not associated` radio, the current working radio swaps around.

wpad-openssl = 2019-08-08-ca8c2bd2-9
hostapd-common = 2019-08-08-ca8c2bd2-9
hostapd-utils = 2019-08-08-ca8c2bd2-9

Anyone experiencing this issue?

2 Likes
2

What mwlwifi version? That was certainly a bug from a driver a long time ago if i recall.

3

mwlwifi-firmware-88w8864 = 2020-02-06-a2fd00bb-1
kmod-mwlwifi = 4.19.115+2020-02-06-a2fd00bb-1

Yes I remember the bug very well as I remember reporting it on the forum years ago. It was on v17 I remember correctly.

4

I having same problem on my Netgear R7800,snapshot r13295, restarting any of the radios disabled the other, it only gets fixed restarting the router , previous snapshot from early May was working without any issue.

Screenshot from 2020-05-20 19-02-50
Screenshot from 2020-05-20 19-02-501021×680 62.9 KB

5

Did you compile your own firmware or did you simply flash the master? v19.07.3 just came out and I might flash it without compiling it and see if the issue continues.

6

Seeing the same on a recent git snapshot. Reproducible in CLI, simply by doing a wifi up radio0 will disable radio1. Running wifi up will bring both radios up.

root@EX6400:~# opkg list-installed|grep wpad
wpad-mesh-openssl - 2020-05-20-dd2daf08-2
root@EX6400:~# opkg list-installed|grep hostapd
hostapd-common - 2020-05-20-dd2daf08-2
hostapd-utils - 2020-05-20-dd2daf08-2

Is there a bug filed for this?

7

No unfortunately. I was planning to do it but I haven't had time to write it up.

8

Here too.

9

Digging more into this it looks like the wifi script first tries to disable the radio and then re-enables it, when you do up. However the problem is that ubus brings all radios down with this command:
ubus call network.wireless down '{ "device": "radio1" }'

Then when he wifi script goes to re-enable radio1, all other radios will stay down and radio1 will start back up (as expected).

10

I'm able to replicate that exact behaviour in SSH. I originally discovered the bug in LuCI as @castillofrancodamian had pointed regarding the odd button behaviour.

11

Same here Netgear R7800 exploration (IPQ8065, QCA9984)
I fixed replacing the script, in the router is in /lib/netifd/wireless/mac80211.sh with the script from previous commit, wget and ca-certificates need to be installed.

wget -N https://raw.githubusercontent.com/openwrt/openwrt/0495324b9bd0b6a976ea731a1b4b77b26df32ee6/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh -P/lib/netifd/wireless/
12

I can confirm that script to the previous commit fixed this issue. Thank you for sharing that workaround!

13

Has someone made an official bug report on Flyspray?

UPDATE
Created bug here > https://bugs.openwrt.org/index.php?do=details&task_id=3138&order=dateopened&sort=desc

14

Should be fixed in https://github.com/openwrt/openwrt/commit/02f08056bcbc5f014894b7edcea43f2ff822fd90

2 Likes