SQM QoS. I'm also going to try Software flow offloading enabled. Not sure if that'll help performance as well.
Software flow offloading isn't going to work with SQM, it's one or the other. I use SQM because it works great maxing out my 500/35 Mbit cable modem while having A+ bufferbloat / A+ quality results.
1 Like
For some reason I thought that was concerning HWO not necessarily SWO. Definitely want my SQM though.
Exactly, thats why I have fixed Channels for both 2.4GHz (11) and 5GHz (36) because ever since using the Linksys WRT1900ACS I had Radar Detection Issues on the 5GHz wifi with I think specially with width 80MHz and performance losses when streaming over Wifi, as described here cant-connect-to-5ghz-after-radar-is-detected-on-wrt1900acs or here 5ghz-radio-disappears-after-a-while-fritzbox-4040 for example (I was probably trying to use fixed channels in the DFS range back then). Interesting fact, can't remember ever having had those problems on my old OpenWrt 19.07 on a FritzBox 4040 though. But thats another story I guess.
My current wifi config
/etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
option htmode 'VHT80'
option cell_density '0'
option country 'FR'
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option macaddr '00:11:22:33:44:55'
option ssid 'MY_SSID_5'
option encryption 'psk2'
option key 'VERY_SECURE'
option network 'WIFI'
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
option cell_density '0'
option country 'FR'
option htmode 'HT40'
config wifi-iface 'default_radio1'
option device 'radio1'
option mode 'ap'
option macaddr '00:11:22:33:44:66'
option ssid 'MY_SSID'
option encryption 'psk2'
option key 'VERY_SECURE'
option network 'WIFI'
Still running smooth 
mostly on 5GHz (Can tell because I have min. 4h+ MS Teams calls a day 
)
1 Like
Running OpenWrt SNAPSHOT, r18470-cb85aea869 on WRT1900AC v2 for a half of month and bumped into the issue, that 5GHz wireless stops working and in logs I see:
Fri Jan 28 19:55:44 2022 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 80:xx:xx:xx:xx:8f
Fri Jan 28 19:55:44 2022 daemon.info hostapd: wlan0: STA 80:xx:xx:xx:xx:8f IEEE 802.11: disassociated due to inactivity
Fri Jan 28 19:56:04 2022 kern.err kernel: [117756.083092] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Fri Jan 28 19:56:04 2022 kern.err kernel: [117756.089773] ieee80211 phy0: return code: 0x1122
Fri Jan 28 19:56:04 2022 kern.err kernel: [117756.094488] ieee80211 phy0: timeout: 0x1122
Fri Jan 28 19:56:04 2022 kern.err kernel: [117756.098955] wlan0: failed to remove key (0, 80:xx:xx:xx:xx:8f) from hardware (-5)
Fri Jan 28 19:56:04 2022 daemon.info hostapd: wlan0: STA 80:xx:xx:xx:xx:8f IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Jan 28 19:56:04 2022 kern.debug kernel: [117756.181183] ieee80211 phy0: MACREG_REG_INT_CODE: 0x0000
Fri Jan 28 19:56:24 2022 kern.err kernel: [117776.090220] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Fri Jan 28 19:56:24 2022 kern.err kernel: [117776.096217] ieee80211 phy0: return code: 0x1111
Not all devices connected to 5GHz are affected at the beginning.
kmod-mwlwifi - 5.10.89+2020-02-06-a2fd00bb-2
mwlwifi-firmware-88w8864 - 2020-02-06-a2fd00bb-2
1 Like
This is good information. Thank you for sharing.
What log settings do I need to see those extra details? Is a special debug build required?
Previous Timeout-related issues on mwlwifi firmware often showed up after newer kernels and a few times were remedied by increasing:
#define MAX_WAIT_FW_COMPLETE_ITERATIONS 10000
Link: https://github.com/kaloz/mwlwifi/blob/111118dc2ea3b592a5f7dff18c82d57a651970e7/hif/pcie/pcie.c#L36
At one point in time that was set to 2000 milliseconds. Even after the Marvell developer increased it to 10000 milliseconds, he had suggested that it could still be increased further if necessary due to mwlwifi using mutex.
It might be interesting if someone could try testing this by compiling in driver with this set to 15000 milliseconds or even 20000 milliseconds.
I don’t have a build environment, but I would be happy to test it if someone compiles to matching 21.02.1 matching kernel driver.
I can generally reproduce the 5 GHz radio crashing approx. every 3 days on average.
1 Like
You are welcome
No, just logread command provides this logs.
1 Like
It's been about a week here. The snapshot I installed helped a lot. Network cutouts went from multiple times per hour to maybe one every few days. Still not ideal... but it is better.
Look careful, when set encryption. 802.11w should be set to disabled.
WPA2/WPA3 mixed mode does not work on MacOS with 802.11w disabled - keeps asking about password
Other people have said that WPA3 doesn't work on these routers in OpenWRT. It's a separate problem from the stability issues being tested here. See here for more discussion from a year ago: WPA3 support (maybe?) on Linksys WRT series router
2 Likes
any news regarding 21.02.2 release?
P.S. because I am thinking about downgrading to 19.07
Why not just run a snapshot? Have a 60 day uptime on my WRT32X with a snapshot from late Dec, it's been great. Yes it would be nice to see .2 released soon, but I think all the devs are focused on the move to nftables.
I have 2 issues running snapshot:
- WiFi is unstable every 2-3 days
phy0: cmd 0x9122=UpdateEncryption timed out - ARP issue between devices connected to the same WLAN interface, details: Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02 - #655 by stamak
ARP issue bothers me the most, just would like to know if 02 can fix it if not - seems downgrade is solution for me
1 Like
I had the exact same issues, reverted to 19.07 and just keeping track in this thread, but will stick it out until there is better news.
I don't see why we would have to upgrade, new stuff is interesting, but not necessary, especially when the newer version has critical issues.
Not bashing the OpenWRT community or anything, this Linksys hardware is just a hard one to support it seems.
That being said, if you have issues with 21.02.X revert to 19.07.X for the time being and your issues will be gone. As long as both still get critical updates, there is no reason not to.
1 Like
@dgilman @WildByDesign
Feel free to build and test branch gvalkov on my fork where the 5 GHz radio should work correctly. I use channel 100, 160 MHz, though my laptop only supports 80.
httpstorm/OpenWRT branch gvalkov
Or use the image I compiled
WRT3200ACM 2022-02-13.r18804 firmware
Important: before upgrade, if you choose to keep the old configuration, make sure to edit /etc/config/network, and add option device 'wan' under config interface 'wan', as well as list ports 'lan' under
config device
option name 'br-lan'
.
...although illegally in many countries
Disabling the mandatory DFS testing and going over the allowed transmit power limits is not a real solution for general usage.
I am just trying to figure out from the five commits if there is any actual fix (in addition to mangling the power table and country regdb). Possibly the few instances of patched case NL80211_CHAN_WIDTH_160 sections are actually interesting?
3 Likes
Disabling the mandatory DFS testing and going over the allowed transmit power limits is not a real solution for general usage.
@hnyman I agree with you, however I'd like to open the following question: is there any better alternative apart from selling the device? FYI WRT3200 is locked and cannot go outside regulations. There is no API to get or set TX power. Without the patch, aAny user residing in the EU but outside France is forced to use an incorrect country code. If we get strict on regulations, that's a bad thing. I share my fork, to help people understand the issue with DFS. Because WRT3200 is pretty much useless on DFS channels even when there are no radars in the area. And there is no indication in LuCI why this is the case. My solution allows the 5 GHz radio to operate correctly.
I am just trying to figure out from the five commits if there is any actual fix (in addition to mangling the power table and country regdb).
Patch DFS-free radio actually disables country reporting. When OpenWRT queries the hardware region of the radios, an error is returned, so the system thinks there is no region. Then the user is able to set their actual region. Note that otherwise region 98 EU is returned by hardware, and the driver reports this as FR, so people elsewhere cannot set their actual region. It was a dirty work from the manufacturer who also set the other radio to US. Hence OpenWRT sees a conflict and prevents usage of any DFS channels. Patch 600-g-wireless-regdb.DFS-free I optional. Indeed as you have observed it is a bit on the grey shade. It merges channels to allow 160 MHz to be used on larger set of frequencies, and disables DFS to allow users who live far from legacy radars to have a hassle free experience. Without that there would be a delay of 5 minutes, before the AP goes online. For anyone doing a lot of testing, this is not a good experience. Finally TX power does not need to be edited, it's a legacy thing, I'm too lazy to remove, and since there is no API to get or set TX power, WRT3200 will remain within regulations. In conclusion: the device will remain in spec for users who live far from radars, which is probably > 99.9% if not all users.
Unrelated patches: wrt3200acm: reverted to network switch, instead of DSA restores the switch functionality for those who need to mirror traffic. Note that with DSA, wan and lan1-4 share one physical interface. This patch separates them for better performance. Network interfaces are renamed to lan and wan, users should add them to /etc/config/network if they need to preserve their existing configuration.
1 Like
Can I use this patch on top of my build for the wrt32x? I build from master.