My brother reported reduced range as well compared to driver from June. I haven't noticed anything but I haven't looked into it myself busy with other things. I build images for him, config hasn't changed for him... He doesn't follow this forum but he did bring this up reduced range with me and then I saw these recent notes... I said same thing as you, maybe neighbours network...
Finally, something interesting (at least in appearance) for us:
- Modified the code to protect TX queues (for 88W8864 and 88W8997).
Files available at https://github.com/eduperez/mwlwifi_LEDE/releases/tag/ccdb4fa.
kaloz has just released some more changes:
- Fixed crash problem when module is removed.
- Added vendor events.
- Removed unnecessary firmware settings.
- Upgrade 88W8997 firmware to 18.104.22.168.
- Change driver version to 10.3.8.0-20181022.
Files available at https://github.com/eduperez/mwlwifi_LEDE/releases/tag/fac1da8.
Hi worth updating for a 88W8864?. To say the truth i'm very happy with the 20180906 update. Very stable and very good throughput and range.
I haven't seen any announcement about new features or relevant bug fixes lately... You probably do not need to update, unless interested in helping by testing for regressions.
What does this mean?
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.
@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.
@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...
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.
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.