just be aware that the mlwifi has similar noticably reduced TX power issues, if you carelessly modify the country code via LuCi at all (avoid that) or if you activate radio 2 and do not manually configure country code on command line afterwards.
1 Like
Where could I find mwlwifi driver version 10.3.8.0-20181210 commit a2fd00b for OpenWrt 19.07.8?
Thanks 
I am having trouble to compile 19.07.8 in my box; please, stay tuned!
2 Likes
Thanks for your work 
1 Like
@eduperez I have some questions (pardon my ignorance!, and I havenāt used your files yet):
(I have a WRT1200AC ver1, and a ver2 unit)
-
Do you have to use your provided firmware files (mwlwifi-firmware-...ipk) with your drivers (kmod-mwlwifi_...ipk)? Or, is it possible to mix and match either one of these with what is provided with official OpenWRT releases to see what works best?
-
If they do need to be installed together, do they have to be installed in one (the same) opkg command?
(BTW, it may be helpful to put the answers to #1 & #2 in your README.md file)
- As far as I can see, it appears as though there will be no further driver/firmware development (both official and unofficial) for these units. True? And if so, do you think this means that as OpenWRT continues developing that we may see more and more unfixable problems arise with these units in the (near) future?
Thanks so much for your help and timely compiles!!!! 
No need to apologize!
-
Not all drivers are compatible with all firmwares, you might end with a router that does not boot. In the past, when it made sense to test different combinations, I published specific packages. Besides, the firmware has not been modified for a long time. So, no, do not try it.
-
Yes, install both of them on the same command, it's safer.
-
Yes, all development is stalled. The drivers could be developed, for example to support newer kernels, but the firmware is closed source and a dead end.
The "mwifiex" drivers only drive the third radio on the WRT3200ACM, and it is usually disabled because it has a very small antenna, and causes conflicts with the drivers for the other two radios.
The Linksys WRT1200AC is sadly (I mean, I bought one of my two units only 3 years ago) end of life/abandoned and explained why in this post, and if you go to the official website and see that the latest firmware is at least 33 months old. Since arguably your router/firewall is your first and best line of defense against hackers/malware, this is, understating it: a non-ideal place to be at. A great thing about the open source community is having the possibility to keep older devices going.
However I think even using OpenWRT on these devices is essentially overā¦. Back in the v18 days, and LEDEv17 before that, everything worked great. On v19, with each consecutive release Iām having more and more WiFi problems. Version 19.07.8 is essentially unusable as my 5GHz radio wonāt stay connected to any of my devices, heck even the 2GHz radio is flaky (and I donāt have an exotic configuration). On a whim, I tried v21.02.0 (which I see as of very recently is now the official release!) and it was worse, simply unusable.
/rant
Having said all that, I rolled back a release and am glad to report that your compiled files for 19.07.7 work very well (been using for 2 days)!! I seem to be not having 5GHz disconnects/drops and my Sonos (on 2GHz band) is much more responsive. So if you @eduperez canāt keep up with the official releases (I really like keeping my firmware up to date for security fixes), or canāt compile, or the aging driver is just not able to work with the newer OpenWRT code, Iāll have to sell off my units and look elsewhere (hint: it will NOT be another Linksys). Thank you @eduperez for all your work! But for me, the clock is ticking on getting rid of these units as Iām now relying on you to keep them going (no pressure :-).
1 Like
In what way, maybe some specifics in the 21.x release thread may serve some useful purpose; I certainly find master to be very usable on a mamba and rango, but admittedly, I turned off the radios on the rango long time passing.
In short, my devices on v21 (running on a WRT1200AC v1) would disconnect from the 5GHz radio after only minutes. Also the radio would get so unhappy, the only way to see it as a hotspot again was to reboot the unit. (v19.07.8 does the same thing but seems to last for up to a couple hours before dropping and needing a reboot).
I would spend the time to troubleshoot and upload sys logs and whatnot to help get v21 working, but since both WiFi driver and kernel firmware development is long done with these units, it doesn't seem worth everyone's time as this would probably be unsolvable.
If eduperez keeps compiling, and those files keep working, that's probably the best I can hope for.
If you have dealt with the AMSDU issue, the only other things I am aware of is some iot devices causing grief (on 88W8864) as outlined in the mwlwifi issue tracked.
Certainly mwlwifi development has ceased, but kernel, I am running 5.10 and testing 5.14?
1 Like
Sorry I meant firmware (not kernel) development is done.
Yeah, now that 21.02.0 final is out, hopefully someone can figure out the cause of the issues. Some people have reported better luck with the master, while others still have problems with that on WRT3200ACM & WRT32X, too: Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02.0-rc4
Master most definitely fixed the wireless issues I had. Iām checking wireless commits on master which were not backported to 21.02. If I find the commit that fixes this, this will all end.
2 Likes
This post was sent on July 24th, thereās been changes on the master branch since this date. Iāve tested master recently. There could be newer commits on the branch which might change the behavior this user is experiencing on their device.
P.S. Please tag me if you donāt send your response as a reply to me.
Yes, I know the timelines, but you were also reporting master as working at the time that moniker tested and reported it to be broken; as per the PR you had open to revert BLOB. I am simply stating that different results are being indicated by different people testing.
But I keep coming back to the result from when we first pulled the BLOB from the OEM FW, it is probably AP related as indicated by post client.
No, I did not know about this AMSDU workaround.
Before I try this, I have 4 questions:
-
This may work for 3200 models, but I have a WRT1200AC v1, which does have the 88W8864 radio chip type, so I assume this will work for these units also?
-
Does this have the possibility of bricking my router? (It's my primary unit, I don't want it not working!
)
The commands you provide append a "0" to those 2 files.
-
Shouldn't it be a single ">" to instead overwrite the contents??
-
The current contents (on v19.07.7) of those files is "tx amsdu: enable". If we are turning it off, shouldn't it be changed to "disable" rather than just a zero in that file?
(i.e.echo "tx amsdu: disable" > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu.... )
(note the single ">")
Thanks for your help @anomeome !
- this is applicable only to the 88W8864 devices, not the venom or rango
- zero, (ha, famous last words, but about as close to 0 as one can get)
- I think you be correct (hmm, been running it with that since time immemorial, did not spot my typo, appending apparently works
- will turn it off (0 indicates disable), a bug in the 88W8864 FW (BLOB)
1 Like