It's one of the chipsets present in the devices supported by these drivers. Have a look at https://openwrt.org/toh/linksys/wrt_ac_series?s[]=wrt3200acm to see which one uses your device.
Thanks for steering me in the right direction.
Im test driving commit "fac1da8d" as of today, will let you know if how I get on.
So both radios went down shortly after flash and subsequent reboot... but then after another reboot, haven't had an issue since.
Been up a day now without issues, works well!
I installed both kmod-mwlwifi_4.14.63+10.3.8.0-20181022-fac1da8d-1_arm_cortex-a9_vfpv3.ipk and mwlwifi-firmware-88w8964_10.3.8.0-20181022-fac1da8d-1_arm_cortex-a9_vfpv3 on my new (used) WRT3200ACM running Openwrt 18.06.1, in the hopes that they would fix the inability of the wifi radios to function for longer than 20 seconds. But no luck. The network is up for maybe 20 or 30 seconds, and then the wifi radios go offline and dmesg shows me a bunch of messages like:
[ 857.133146] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
[ 857.139010] ieee80211 phy0: return code: 0x001d
[ 857.143582] ieee80211 phy0: timeout: 0x001d
[ 877.154077] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
[ 877.159957] ieee80211 phy0: return code: 0x001d
[ 877.164507] ieee80211 phy0: timeout: 0x001d
[ 897.174978] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
[ 897.180841] ieee80211 phy0: return code: 0x001d
[ 897.185399] ieee80211 phy0: timeout: 0x001d
[ 917.196047] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
[ 917.201914] ieee80211 phy0: return code: 0x001d
[ 917.206464] ieee80211 phy0: timeout: 0x001d
[ 937.218832] ieee80211 phy0: cmd 0x8127=SetInformationElements timed out
[ 937.225479] ieee80211 phy0: return code: 0x0127
[ 937.230040] ieee80211 phy0: timeout: 0x0127
[ 960.244911] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
[ 960.251036] ieee80211 phy0: return code: 0x1122
[ 960.255594] ieee80211 phy0: timeout: 0x1122
[ 960.259800] wlan0: failed to remove key (0, 6c:40:08:ac:cd:2c) from hardware (-5)
I fully admit I'm not an openwrt maven and am not certain that's pertinent info. I also don't know if the problems I'm encountering are related to the fact that I removed wpad-mini and installed wpad during initial setup so that I could use 802.11r fast transition (to other openwrt access points around the house). I'd remove wpad and install wpad-mini again, but can't keep the thing on the net long enough to finish that task (which again, might not be related to anything).
When the radios go down, luci's wireless pages hang.
This device is working quite well for most of us. I would understand that you could have throuble with some specific client or a weird configuration. But radios just going down after a few seconds is something completely different.
I would go back to stock OpenWrt, do the basic configuration, and let it run for a while. If it fails again, I would start thinking about a hardware failure. Or perhaps I would try Linksys' firmware first, to be sure.
That's good to know. I may try a snapshot build as per diizzy's suggestion. I've already tried one of davidc502's custom builds and ran into the same problem. Probably spent 8 hours yesterday flashing and configuring and refreshing and configuring.
All I do when setting up is to set the SSID's, the radio channels (trying to avoid DFS issues), 802.11r with pmk push, lan static ip address, 4 port forwards, 18 static DHCP leases, ddns service with 4 domains, and openvpn service. I think that's all pretty standard stuff that shouldn't cause issues except maybe 802.11r is a more recent feature than the rest.
I have just released packages for version 10.3.8.0-20181027-4da6ee2 of the mwlwifi drivers. There seem to be some changes to add debugging capabilities, and not much more.
Files available at https://github.com/eduperez/mwlwifi_LEDE/releases/tag/4da6ee2.
New release available:
- Added code to correctly parse EAPOL and forbidden packet out.
- Shorten the time to check command timeout.
- Corrected print out message for 'dump_hostcmd'
- Change driver version to 10.3.8.0-20181029.
Finally, it looks like there are some changes that may me interesting for all or us, not related to debugging or the 88W8997 chipset. Files available at 10.3.8.0-20181029-382700c.
1 Like
@eduperez Running smooth here and problem free thus far with 10.3.8.0-20181029. Thank you, sir.
You've done a great job for the community keeping up with releases as the commits come in. As always, it is very much appreciated.
1 Like
@WildByDesign Thanks for your kind words! The truth is, now that I have got the process mostly automated, it does not take me more than five minutes to build and publish the packages for each new release. And I have some brave users to test the packages before I install them myself... 
2 Likes
There are a couple of open bugs at kaloz's repo (https://github.com/kaloz/mwlwifi/issues) about performance and stability, where he has asked for feedback using the latest version of these drivers (382700c).
If you are experiencing performance and / or stability issues, I think it is worth giving a try to the latest packages, and reporting your findings in one of those bug reports.
1 Like
Had the dreaded issue with clients not getting an IP address on connect with 382700c, so I've reverted to the previous build. I hope Kaloz releases a new one soon.
Thanks for keeping us updated @eduperez!
I tried those packages on 18.06.1 and they added 20 ms delay on 5 GHz in Client mode. Going back to OpenWrt's stock drivers fixed the issue.
Hi @eduperez
I wold like to know what you think.
Do you ''advise'' to update the firmware on WRT1900ACS and WRT3200ACM to one of your compilation, versus the ''original one from june? Both were running 18.06.1., but i did put back stock on on the WRT3200ACM two months ago because it was acting weird.
The WRT3200ACM is in charge of the dhcp, and the wrt1900acs is an access point.
I would do what works best for you... if stock drivers work for your gadgets and use case, stay with them; if you encounter bugs, try an updated version. I do not remember any "must have" features or bugfixes in any release after the latest stable.
I have just uploaded several new releases that where merged to the upstream repo recently; some of them only contain changes relevant to the 88W8997 chipset, some contain debugging enhancements, some might contain bugfixes...
- 10.3.8.0-20181103
- Upgrade 88W8997 firmware to 24.5.4.1
- 10.3.8.0-20181105
- Upgrade 88W8997 firmware to 8.4.4.2
- 10.3.8.0-20181106
- Added debugfs file heartbeat
- 10.3.8.0-20181109
- Added code to avoid some packets to do AMSDU
- Added debugfs file dump_probe
- 10.3.8.0-20181112
- Enabled uAPSD
Files available at https://github.com/eduperez/mwlwifi_LEDE/releases.
Do you have a typo for 20181103 and 20181105? The firmware versions are very different for the same chipset. If it's correct can you please explain why they have very different versions?
uAPSD is involved with WMM. Makes me wonder if this is an attempt to fix the ESP devices that only connect with WMM disabled.
Thanks for pointing that out, but it is not a typo... looks like Marvell does weird things with the firmware versions, have a look at https://github.com/kaloz/mwlwifi/commits/master and see for yourself.
Well, that is easy to test... give me a few hours and I will try it.
1 Like