@slh You are right. The DFS related articles I found when I created this patch, mention that when the 5 GHz Wi-Fi was first introduced, DFS regulations were not in place. And this caused issues with weather stations. As a result, DFS was introduced, but since this cannot affect existing users, the weather stations had to be moved to use free spectrum, otherwise they malfunction. Regarding the flight radars, I'm sure they were all moved with priority for safety. It's been a long long time since and for obvious reasons new weather stations don't use the 5 GHz band anymore. While there might be a few ancient installations left, nowadays the risk of interference in most regions is close to zero.
There is also the other side of the coin: users. I've seen many complain they paid good money for a router they can't use. WRT3200 is a perfect example. Hard coding the region is a violation, because it prevents users from setting their valid region. The manufacturer got lazy and set the radios with two different regions, so OpenWRT takes the minimum allowed from FR and US, and prevents any use of the 5 GHz band. One has to disable radio2 or go through all the trouble to hack the driver to be able to set their valid region and make it all work. But then after every boot or setting change, the 5 GHz radio spends 5 minutes in scanning before it brings the AP online. What's worse, due to poor implementation, and the closed source nature of the binary driver, the radio is likely to fail and require a full system reboot. Since there are no 5 GHz weather stations around me, I would rather have this ancient feature disabled and enjoy a reliable 900 Mbit/s link on 5 GHz than use the crowded 2.4 GHz which falls as low as 30 Mbit/s, 3-4 meters away from the AP, due to interference with dozens of other APs.
As I mentioned earlier, radio0-1 on WRT3200 will not operate outside regulations, since the TX power is not accessible from software. TX power on radio2 is accessible, but limited to around 14 dBm.
I don't object loosening the region lock, as that has obviously been messed up by Linksys and is also ignored by the certified OEM firmware.
The DFS requirement is another topic though, this one is mandated by law, including the waiting times before a DFS channel might be used. It's the price you have to pay in order to use these channels. Weather radars also can't just use other frequencies because you'd like them to, they're using these frequencies exactly because of their physical features, how they reflect rain, ice and snow. These are the reason why these frequencies are used for radar and why no one else wanted them for commercial reasons (range-/ object penetration not good enough). The same reasons why we have 27, 40, 833, 2400-2482 and 5000-6000 MHz bands, not interesting for commercial users as different 'primary users' (microwave ovens and wall penetration/ radar limit their viability).
Personal beliefs aside, the regulatory requirements still insist on DFS - and the regulatory bodies can be quite 'convincing' by handing out hefty fines.
@slh Thank you for your good explanation! I think it would be nice if OpenWRT had a feature to cache the radar scan for a certain amount of time, e.g. a month. And also provide feedback via the web interface. This will greatly improve the user experience by indicating the AP is not yet online due to a scan. Currently most users don't have a clue why their AP doesn't come online. They would rather consider the 5 GHz radio broken long before the scan ends. This should also help users avoid any DFS channels in use, in the extremely rare event that anyone finds any radar. I recall radio2 was intended to be used for radar scans. Which makes me wonder if they added it, because the main radio had this feature broken and likely to crash. Eventually radio2 ended up unused, as it also has reliably issues. As a software developer, and a person who makes frequent experiments with my router I cannot simply cut-off my access to it every couple of minutes. I can however relay on knowing that there are no weather stations and radars around the place I live, which is also confirmed by the scans my router made and the people I talked to.
I did notice interference between the LTE modem on my phone, which during heavy Internet usage disturbs the link between my Logitech G900 mouse and its 2.4 GHz Unifying Receiver. The phone has its Wi-Fi off, but is around 20 cm from the mouse, and is tethered over USB to the router. There are no 2.4 GHz clients. Any idea why this happens?
There is a solution to that, not using DFS channels (36-48), yes those channels are more crowded but usable without DFS.
@slh Unfortunately these channels perform worse even without interference from other AP. The signal is weaker, and benchmarks show lower speeds and reliability. I did measure signal and ran benchmarks on all channels. Channel 100 works best and provides a stable link. I often transfer large files 20-80 GB. Thanks!
I tried the latest 21.02 snapshot, but the issue is the same for me unfortunately. The latest Master snapshot build is too unstable to try anything.
What exact build, if still available for download, are people having good results with on a WRT32X?
@Koldur I compiled an image, but it is for WRT3200ACM. What issues are you facing on master? I've been running master on my routers ever since I started building my own firmware around 2015. It works fine most of the time. I've seen a few Wi-Fi issues, and I usually contribute a fix.
Transmission doesn't find an open port, even when I made 100% sure the port is open, works fine on stable and 21 snapshot. Second, things crash when using to copy files through scripts.
@Koldur If you compile your own image, things like this are pretty easy to get around. You can checkout the stable branch, then integrate the patch if it is still missing. Or you can start on master and downgrade Transmission to whatever version is used in the stable branch. You can also uninstall Transmission and then install the official stable package manually: opkg -I package-name.ipk. Any package which is not a kernel module can be installed manually with any version which is known to work. Wait, what things crash and how do we reproduce it? Do you have any logs? The only time I got OpenWRT to crash while accessing files, was due to a faulty SD card with corrupted FAT and unreadable sectors.
I have no logs, but it isn't an issue with my HD, works completely fine with stable firmware and no problems with my WRT1200AC on the same version of the Master snapshot. So there is an issue with some package specific for the WRT32X.
Always wanted to build my own, just need to find the time lol.
Do you have any machine running Ubuntu or macOS? It takes 30-60 minutes, once you configure it. A VM will do as well. Preferably Hyper-V. VMware is rather slow.
I use Windows 10 pro on a 12700K, so should be able to set it up using Hyper-V, the issue is the time to learn how to build 
I've been using the 21.02 snapshot for a few days and my previous issues with our iphone refusing to connect to either the 2.4 or 5 Ghz bands is resolved, yay! We have 1 iphone, 1 pixel 3, 3 macbook pros (from 2007 to 2020), and a samsung tv and I'm happy to report that all are working flawlessly, unlike in the 21.02 official build, where all worked but our iPhone SE, which would randomly drop and refuse to connect.
A few things: If the 5ghz channel is set to Auto nothing will connect. Not sure yet why? If I set a channel, everything works no problem. It works on auto in 19.07.7
I use a guest network set up- when I set both it and our normal network on ether band the radio with 2 ssids will not initialize unless I add a line manually setting a MAC Address to that guest network in /etc/config/wireless. This also 'just works' in 19.07.7. I wanted to report my findings and am following this thread. Major kudos for making my shiny hardware work well on Openwrt.
What exact version of the snapshot are you using?
It's the hidden 21.02-SNAPSHOT builds. I don't know if they want people posting the link, as it's hidden, but you can find it if you google it. Also, just so you know, some people have reported that there's some sort of read-only mode set in the 21.02 snapshots (by design?) where configurations/installs don't stick? Just FYI. I haven't had the chance to try them yet and figured I'd just wait until 21.02.2.
The 21.02 snapshots are here:
https://downloads.openwrt.org/releases/21.02-SNAPSHOT/targets/mvebu/cortexa9/
I have flashed it and the latest ones at least, are not read only. Issue is, for me it didn't fix the problems with Wi-Fi.
They have never been read-only. No idea where that read-only misinformation has surfaced.
That snapshot fixes one specific upstream Linux bug, which hurt especially the mwlwifi driver.
But as the mwlwifi driver and the underlying closed-source firmware blobs are buggy and problematic in any case, and the development has been been stopped upstream, there are still problems with some configurations and client devices and will continue to be...
That is too bad, especially since the WRT1200AC works fine on the same versions of firmware and they both use the same FW. Guess I will revert to 19.x then.
The issue isn't due to configuration, that I am sure of. Even just default settings and using my WRT32X as access point, exactly the same issues as mentioned at the start of this thread and no difference whatsoever.
I am sure it is fixable, but am not competent enough to help out in fixing it, nor do I think I am entitled to a fix.
I never mind testing fixes/patches as I have the WRT1200AC as a backup. Too bad the Master snapshot just gives a lot of issues on the WRT32X, because of that I am not able to test if that version works good as AP only.
I first got into building OpenWRT in hope to find a firmware with working Wi-Fi for my old router. I realised that given two points: one which works, and the other which has some issue, I can jump between. commits and find the exact change that introduced the regression. Then I contributed my first patch. It takes time and effort, but finding an issue among 4000 commits in just 12 builds is impressive. The Binary search is very efficient: always jump in the middle. I had zero knowledge back then.
Well, wrt1200ac has the 88W8864 wifi chip, while wrt32x (and wrt3200acm) have 88W8964, so they have different firmware blobs.