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.
That is clear, then the only thing telling me it should work fine, is the experience of other WRT32X and WRT3200ACM owners that reported it works fine with one of the later snapshots (either 21.02 or Master).
Only issue there is, the packages for master will probably not be around anymore if it is an older Master snapshot.
@gvalkov
I would like to put some time in learning this and am sure I can, but at the moment pretty busy with too many things to mention
And at work I kind of already have to figure out these type of things and very complex stuff since a while and will be like that for a while yet. So after work I do not really feel like diving into this at the moment.
But I am sure if it get's a bit less complex at work, will dive into this, would love to take control over building my own FWs!
@Koldur I know this feeling. It is the same with me and had to postpone fixes until I find time or if they affect my work in a critical way, make time. Good lock!
@hnyman I use WRT3200ACM on 4d1f13356196103769e610920a9681b731b089d3 and I can confirm the fix. Before that, I was on 00ce13490a181cbf411aaca76be44a04604b1fbd, and I noticed that my MBP 2019 shows as connected, but often stops communicating for a short time. The funny thing is that I noticed this issue as I moved 2 floors away from the router, so now my laptop switched to the 2.4 GHz link. I had almost no issues with the 5 GHz radio on channel 100 in the same room. After the fix it is rock solid on 2.4 two floors away.
Also, @stamak mentioned privately to me that he installed openwrt-21.02-snapshot-r16399-c67509efd7-mvebu-cortexa9-linksys_wrt1200ac-squashfs-sysupgrade.bin and had a problem
after reboot where the router did not see his configs. He said it booted in failsave mode all the time and saved nothing after reboot.
^This is the 21.02 snapshot shared up-thread. It works like a charm for me, completely as expected other than the guest network bug I mentioned above.
As an update, the wrt32x works correctly using 'Auto' on the 5ghz channel selection, just takes a few minutes to come up due to DFS channel scan. I didn't keep it on the DFS channel it landed on for more than a few minutes as the 2007 MBP doesn't support those channels (I wondered why it wouldn't connect...) so I need to use one of the other channels, thus I can't comment on stability on those channels.
Other than that, nice and boring and stable, as expected. I've not tried to implement DAWN or anything fancy; felt like I'd be pushing it given the issues others are having. Again I appreciate the work to make this hardware work well, despite linksys abandoning us.
Thanks, tried it with that version again and it seems I landed into the perfect storm of issues haha.
It is threefold:
Our baby monitor always really hampers the 2.4Ghz speed when it is turned on. Forgot about that fact, but figured that one out two years ago (and kinda forgot about it when testing this time around). Started testing the router right after the little one was asleep, so you get the picture.
Because of the testing I went on another channel, which is too crowded here and that one really stops traffic and makes the 2.4Ghz band on that channel unreliable/unusable at times. I had my other router on the previous channel so I could continue using it and testing on this router, though that proved to be the wrong way as I know now.
Concluding the issues from 1&2 are because of the software issues because I do not want to put in the time to properly check if it is actually the same because the issues look/feel so similar.
So, conclusion is, there are no issues due to the bug mentioned before, the latest Master snapshots also seem to work fine here, especially when considering the points mentioned above.
Turned off the baby monitor, full speed available, turned it on again, slow..... Switched to the previous channel, no more completely congested traffic, which I previously wrongfully assumed to be the bug after 19.7.
Thanks for sharing the exact snapshot version, luckily I had that one stored on my HDD so I could test it again, but then properly.
Hey there.
I have this trouble of intermittent wifi cutouts on my iPhone when on my wrt3200acm.
My actual version is:
OpenWrt 21.02.1 r16325-88151b8303
When I upgrade, I don’t keep settings but I keep a list of packages installed with opkg save and restore, hotplug, etc.
I wonder if this way of preserving packages will move the problem back to my new installation.
Can I just downgrade the packages instead of upgrading the whole thing. And should I put a hold on those package version so they are not upgraded later ?
Losing every settings is a pain I have wireguard, a lot of firewall customisations, etc. and I would prefer if I can just downgrade the packages instead.
Hello all, I've started bisecting OpenWRT to find the issue with DFS. I'm only getting started, but my results so far:
I started with ea91ebedce8051e4a3bf84586b589e918d1fc08c (mac80211: fix regression in SSN handling of addba tx) cherry-picked on top of ed2015c38617ed6624471e77f27fbb0c58c8c660 (mac80211: Update to version 5.8-rc2-1). 5 GHz was stable but DFS did cause issues with iPhones and others. There also may be a second bug here - my Roku was unable to find the network at all, and had previously worked fine. I will be testing that one later.
Next, I tried 600416d5c14663faa3e2eb42ff71a41d4fa8e0f6, which is the commit immediately before the ones before where mac80211 was updated. There was no cherry-pick here as it was not relevant. I started here instead of a proper bisect in order to get firm start and end points for the bisection. I did find issues with 5 GHz DFS on this branch. The Roku issue was not present.
I am currently trying the release 19.07.8 to get a lower bound on git revisions. I don't think DFS was an issue in 19.07 but I'm just covering my bases.
Excellent. I appreciate the work that you are doing and it’s great to see people still digging into issues related to the wifi on these devices.
I have been conducting a 30+ day study related to the wifi as well. Although not specifically DFS. My testing has been related to the crashing of the 5 GHz radio and thorough testing of specific channels, transmit power, etc.
I have been successful in solving the issue of the 5 GHz radio crashing on my own WRT3200. But I still have a few more days of testing before I am ready to present my findings here.
I have 16 days of uptime now without a single 5 GHz radio crash. I wouldn’t be surprised if these other underlying wifi issues with mwlwifi could also be related to the issues you have with DFS.
Honestly, the fix for almost all mwlwifi 5 GHz radio issues is to use channel 36. Channel 36 and life is golden.
All of my 5 GHz radio crashes (that required reboot) we’re on higher channels such as 149 which I had used for years.
The closed source firmware blob enforces TX Power regardless of what LuCI shows in the UI. The higher channels use 30, while the lower channels use 23, as far as I know.
I even tried channel 149 with TX Power manually set to 23 in LuCI. It still caused a 5 GHz radio crash.
But the question still remains, what could be causing the crash?
It has happened before with mwlwifi and previous releases of OpenWrt. However, with 21.02.x releases, it seems to trigger the crash much more frequently. I had experienced the crash every 2-3 days.
Except… on channel 36.
I am on 16 days uptime now with channel 36 and also did another 12 days or so earlier in testing also with no crash.
I always use it on channel 36 but recently it's got very unstable. Only reducing "Width" to 40 MHz seems to have helped in my case. Wi-Fi speed is slower because of this (~150mbps) but at least it's stable.
P.S. I just did a quick speedtest and I was able to see 300mbps, FYI.
Good afternoon, I have installed the version OpenWrt 21.02-SNAPSHOT r16473-1472a8fa42 on my linksys wrt1900ac V1, and everything works perfectly, the wifi stability problems disappeared.
Maybe I did something wrong but wrt32x, snapshot r18614-46ce629fe0 (sysupgrade from v1) and Wi-Fi is still unstable, not assigning ip on 5GhZ, disconnecting and all that trouble. Sorry for such report
I have wireguard, a lot of firewall customisations, etc. and I would prefer if I can just downgrade the packages instead.