.
...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?
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.
Can I use this patch on top of my build for the wrt32x? I build from master.
@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?
With DSA one can port-mirror, and if multi CPU port is a concern there is PR4982 allowing one to patch that in to a build.
Hi,
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?
Best,
wrter
No.
This thread was about frequent silent breaking of connectivity, and that bug was solved a few months ago...
OpenWrt 21.02.2 images which fix the issue are live on the firmware selector. I've updated the links on the main post.
Just to add my experience here… I’ve seen the frequent WiFi disconnects disappear since the fix by nbd. However I am after 3-4 days seeing the WiFi crash completely on both 5ghz and 2.4ghz the only way to restore is a reboot of the device using a master build. Looking at the comments others appear to be having the same problem.
Additionally I can not get channel 149 to work at all the 5ghz WiFi doesn’t come up for me on that channel using a WRT32X. How are others getting this channel working? I am able to use channel 100 @ VHT160
I have also been using the “free DFS patch” for a while on the httpstorm branch as well.
21.02.2 is working great on my WRT3200 and, without a doubt, resolves the original issue from this thread regarding wireless dropouts.
I am wondering: is it time to close this thread now?
There are other issues with mwlwifi such as 5 GHz radio crashing at times and requiring a reboot. Other issues as well. But none are related to the original issue from this thread and that bug has been successfully fixed.
I figure we can always create new threads for these separate issues if necessary.
Have you seen any pattern in the crashing? I was seeing the same thing when I last tested, and just ended up going back to 19 train code because I didn't feel like dealing with the issue, or rather my kids didn't feel like dealing with it, and I didn't feel like dealing with them not wanting to deal with it LOL. I do have one device that I may try upgrading on as there are other devices close enough to not be too impactful if the wireless radio crashes.
Unfortunately not much of a pattern. Although it often happens around the 3rd day after boot, it also sometimes happens after as little as 12 hours or even as much as 10 days. No useful logging either.
I can totally relate. I ended up switching my kids devices, their school Chromebooks, and my wife’s devices over to 2.4 GHz as a temporary solution for the past few months. Their devices have had zero interruptions at all since that time even with 8+ hours of Google Meet per day.
I have kept my devices only on the 5 GHz radio to continue testing in hopes of reproducing the crash and getting clues or patterns. Also, I can tolerate the random bits of downtime much more compared to my kids.
I don’t hold up much hope for fixes to any remaining mwlwifi wireless issues. However, I will never give up trying and continue digging in.
I used to be able to reproduce the 5 GHz radio crash (chipset crash) approx. once every 3 days on average. It always required rebooting the router to bring the 5 GHz radio back up.
This may be a coincidence, but since ditching irqbalance, I have not been able to reproduce a single occurrence of the 5 GHz crash in a little over 30 days now.
21.02.2 seems to have solved wifi. BUT a 'new' problem is reboots locking up the device. The 3200 would try the patience of a saint! I typically swap to OEM partition before ul factory Openwrt images. Then at least the '3-switch partition switch' can get you working fast, if on OEM. ChargerDad understands why, lol!. Shame - bc OEM configuration is dreadful. The 3200 has consumed 'a lifetime' to 'debug' - imo bc of the closed 'unsupported' firmware! Now? It's an expensive dumb OEM AP - shame bc better AP options are available at less cost. 'Important stuff' is now on a Openwrt x86 mini-pc - works perfectly for the same price, serious processing power and still draw only in the 'watts range'. My advice to anyone making this move (hence my posting) is, make sure you understand 'partition swaps' and the recovery methods - you will need them!
Thanks for confirming this - I was just about to do a fresh build of 21.02.2 on my router and I wasn't sure if I still needed the patch or not.
No luck here.. I fresh installed 21.02.02 on WRT3200ACM and setup 2 firewall zones (lan and guest) both forwarding to wan (with port rule for DHCP and DNS for guest). The interfaces with static ip on different subnets with DHCP enabled. I did not create Bridge VLAN filtering at first.
Then I enabled radio0 and 1 for both zones:
I restarted the OS and router many times, but on 5ghz wifi lights are blinking and some of my devices can't authenticate (my desktop can). After I create 2 VLANs and enable VLAN filtering for br-lan, change it on the interfaces of lan and guest nothing changes. Still problem with auth. Any idea?