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.
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.
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
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 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.
@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
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
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?
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.
@Brillie
Yes, the patch is based on master. I think you need to adapt it, but it's a very small change. Look for modifications made to the .dts files. Rango is for WRT3200. There is an equivalent for WRT32x. Apply the same changes there, and you will see the Switch appear again under Network in LuCI. You might also browse the commit history and find the commit that disabled the switch and one of the Ethernet adapters. My patch reverts that only for WRT3200.
Thanks for the info. I’m just regular user. I can only apply patches. Making changes to dts files is something I never have done.
Is it possible thad you can make a patch for the wrt32x?
I have some issues with some WiFi clienbts on WRT1900ACS: It takes minutes until they get an IP (DHCP is relayed by the OPNsense router). Is this related to the issue tracked in this thread?
