I've been using my build for a week, never had that happen. Let's see how it goes for you on the long run.
In order to eliminate as many variables as possible, I would suggest it might be better to use a soft link as per script in post. That way all things remain the same, the only change being the BLOB in play with your image, based on where the link is pointing.
Is there a changelog for the firmware that shows what was changed/fixed in the revisions? Also does the kernel driver version have to pair with the FW revision?
Thanks for your input, I'd like to state that everything except the firmware blob already remains the same.
If you can check what my commit changes:
Between these commits (removed one is what OpenWrt 21.02 uses at the moment) at mwlwifi repository, only the 9.3.2.6 firmware blob was replaced with 9.3.2.12.
There's no room for other variables already. I can also simply push a pull request to the main repository after rebasing to openwrt-21.02 branch.
Looks like there's a lot of people who have stated they were having Wi-Fi stability issues on OpenWrt 21.02 on the post you referred to. I'm going to quote a few and put it on my pull request to get it merged. Thanks for leading me there.
mwlwifi repository is not really explanatory with their commits about the changes on firmware upgrade:
Also does the kernel driver version have to pair with the FW revision?
It looks like it doesn't necessarily have to but there are fixes on the kernel driver which makes the firmware work for newer kernel versions.
@ByteEnable no, it was just extracted from a new OEM FW that was issued, see the original thread, also issue 378.
@arinc9 your FW was not my issue, people will be comparing 21.x / master for the new BLOB, and then some other FW to test the last BLOB. Not exactly apple to apples.
I don't quite understand what you're trying to say. Can we agree that, by your terms, FW = BLOB?
In context FW was a reference to your OpenWrt image offered above, BLOB is a reference to that for which this thread exists and is currently being pointed at as causing a problem.
If people test one, and only one, image (does not matter which image), and change just the BLOB in play, all other things remain constant.
Everything else is already constant with my image compared to official 21.02.0-rc3 image. Only the firmware blob is different. I explained it above.
I've been using the 0x09030206 version of the driver on my WRT3200ACM with a divested build for a few days after having wifi issues and it seems to have helped.
1 Like
just want to put an update here,
after the second time of the radios crashing, and also settings not staying after reboot I flashed back to stock (running for a day so far no issues). what I would like to do is flash your build (or any other build using the older radio FW if someone has one) and see if that truly fixes it, could you provide me a .img of your build since I cant use a sysupgrade from stock?
does the whole reboot wipes settings thing happen for you?
Device: WRT32x
Can confirm this version sorted my instability issue.
Device: 32x
1 Like
Do you mean the radios become disabled, like it shuts down, stops advertising the SSID, and you have to reboot the router to solve it?
My release already has squashfs-factory image, use it.
No, never had that happen.
Can you edit your comment and add your device? I'm going to link it to my pull request.
Do you mean the radios become disabled, like it shuts down, stops advertising the SSID, and you have to reboot the router to solve it?
yes ive noticed this happens when all clients have disconnected, itll go down and the webgui shows disabled and the radios show the generic radios turning it back on does nothing and hangs the device
will flash the image and report back with more info
Oh yeah, I had this issue. I had to remove all of the wireless interfaces and add them from scratch. I had to do this only once, after upgrading with my older configuration.
Just realised mine is resetting to default config on reboot also. Annoying 
EDIT: I've rolled back to 19.07 and its still defaulting on reboot. Any ideas?
You’re not using initramfs-kernel images, are you?
Thank you for creating this thread, firmware downgrade PR, and in general for helping to bringing awareness to this issue. I appreciate it.
On your Github commit for the downgrade you said:
Avoid 88W8964 firmware 9.3.2.12 for Wi-Fi instabilities it causes on Linksys WRT3200ACM & WRT32X until fixes on master branch are backported to openwrt-21.02
-
Does that mean that there are already fixes on master branch that are successful in mitigating this issue for WRT3200ACM and WRT32X devices?
-
If yes, could you please link to the commit(s)? I am just curious to learn a bit more about it since this issue has affected me as well with my WRT3200ACM.
-
Also, if there are successful patches on master branch, do you know if those fixes will be backported to openwrt-21.02 branch before it leaves release candidate stage?
Cheers!
Thank you very much.
Yes there are, rmandrad on the github PR pointed it out and I confirmed it’s fixed by compiling master branch and testing it out.
I have no idea what’s the fix on master.
I’m pretty sure it will be backported but I don’t know if it’s going to catch up to the 21.02.0 release.
P.S. That’s where my patch comes to help. It’s a hotfix until changes on master are backported. If we get this patch on the trunk before the final release, it’s good enough.