Pre-compiled updated mwlwifi drivers for stable releases

Sorry these are the default wireless packages in 18.06.2 ... I thought this thread was it...

I restarted teh router and it hasn't happened again will file a bug report if it happens again thnx so much

Should I be seeing repeated and continuous messages like:

Thu Feb 7 22:19:52 2019 kern.debug kernel: [ 1565.170589] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:19:52 2019 kern.debug kernel: [ 1565.224031] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:19:52 2019 kern.debug kernel: [ 1565.264026] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:19:52 2019 kern.debug kernel: [ 1565.304036] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:19:52 2019 kern.debug kernel: [ 1565.344032] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:19:52 2019 kern.debug kernel: [ 1565.384033] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:19:52 2019 kern.debug kernel: [ 1565.424033] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:19:52 2019 kern.debug kernel: [ 1565.464039] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:19:53 2019 kern.debug kernel: [ 1565.504040] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1586.777635] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1586.835126] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1586.875120] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1586.915119] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1586.955123] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1586.995124] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1587.035133] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1587.075134] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1587.115131] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1587.155145] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:20:14 2019 kern.debug kernel: [ 1587.195135] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:24:12 2019 kern.debug kernel: [ 1824.908947] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41
Thu Feb 7 22:24:47 2019 kern.debug kernel: [ 1859.556165] ieee80211 phy1: Mac80211 start BA f2:9f:c2:aa:a7:41

When I have a client AP set up? I'm seeing my connection going up and down regularly and didn't not see these continuous messages in 18.06.1

No, that does not seem right.

There's been quite a bit of changes between 18.06.1 and 18.06.2 with regards to power saving features and AMPDU (which is part of the BA/Block Acknowledgement stream you're seeing). This commit on the driver might be relevant to you:

It is a correction of when "start BA" should be printed on the log and a change of its behavior.

This may also be relevant given that it changes the way BAs are stopped.

At least with my experience of this log spam, OSX and iOS clients cause a stream of those errors (similar to your 1565.xx and 1586.xx spam) only when the client has low SNR (due to distance from AP, walls in the way of the AP, or electronic interference between client and AP).

For example, quoting from this:

Chuck_Lukaszewski: "A lot of mobile clients including iOS devices behave in ways that make it difficult for the infrastructure to manage them, especially around power save behavior. We have various optimizations to "nudge" the client to interact with us to maintain state. One of those is that we will send Block Ack Requests to a weak or disappeared client under certain conditions. This can appear as a BAR storm."

From your MAC address I am hazarding a guess that it is a UniFi device from the f2:9f:c2 OUI. I don't know if that AP employs any power saving measures (when working as a client). Perhaps you could try and revert the two commits I listed to see if it can bring you back to a working state similar to 18.06.1. However, reverting these two commits may break other things. Whilst I'm not experiencing frequent disconnections or serious problems like that with the latest driver, I am experiencing the log spam - but that can be ignored.

Apparently this was caused by a bad configuration after upgrade. So problem between keyboard and chair.

I didn't realize that I shouldn't simply apply the update and further didn't initially realize that travelmate and openvpn had been removed though the configuration files remained behind.

I had two disabled wifi clients that had been managed by travelmate and once I removed them, my connection to the current client has been solid and I'm only seeing a few stops and starts over the course of an hour rather than dozens

could you help how i can make new build on 18.06.1?
now makefile contains :
PKG_SOURCE_DATE:=2018-06-15
PKG_MIRROR_HASH:=69cd9f7c79564e444edf423133b13dcfbba9f66c051516606049087fa1973a20

where can I take this fields?
thanks

You need to edit the variables that I commented in my post.

Current latest OpenWrt 18.06.2 mwlwifi on WRT1900AC v1 mamba has problem with slow 2.4GHz throughput which is not stable (getting max 20Mbps on auto ch11 and for some manual channels max up to 33Mbps unstable. While on ch5 throughput is terrible 0.3Mbps. Although setting channel width 20vs40MHz does not affect throughput the problem, but when I enable in Advanced " Force 40MHz mode", I get ~58Mbps on ch3!? which is why I am running it despite saying that this does not comply with IEEE 802.11n-2009! which tells me this it just a hack and not a solution.)
This is NOT an issue with channel congestion, since I have tried and used few other routers that fully saturate 2.4GHz N at all channels.
So far I did not notice any problems with 5GHz although did not run any extensive tests there yet but so far all of more than dozen devices show good 5GHz performance.
Versions of mwlwifi are:
kmod-mwlwifi - 4.14.95+2018-11-14-81413aa9-1 - Marvell 88W8864/88W8897/88W8964/88W8997 wireless driver
mwlwifi-firmware-88w8864 - 2018-11-14-81413aa9-1 - Marvell 88W8864 firmware

Question/ask: What mwlwifi is known to be stable without such problems? (or when this will be released or how could this be set up to work well or is davidc502 or eduperez which has older build better,..?)

I finally managed to find the time to sit down and upgrade both my router and my build environment to 18.06.2. This release contains a fix for some time-out errors and improve the stability on WRT1900ACS devices.

Files available at https://github.com/eduperez/mwlwifi_LEDE/releases/tag/31d9386.

5 Likes

Thank you, sir.

1 Like

I just tried your last build:
opkg list_installed|grep mwlwifi
kmod-mwlwifi - 4.14.95+10.3.8.0-20181210-31d9386-31d93860-1
mwlwifi-firmware-88w8864 - 10.3.8.0-20181210-31d9386-31d93860-1

Result is that it behaves the same as original boundled with 18.06.2 giving slow unstable 2.4GHz ~20Mbps

I have same issue as you, did you find the fix or maybe older driver that can work better, also I realized that on Legacy mode thay are more stable but the speed is same around 20Mbps.

The development of these drivers is pretty much stalled... without the proper documentation about the firmware (that Marvell refuses to release), it is almost impossible to work on the drivers, and either Marvell has lost interest, or they consider it's good enough.

I do not think we are going to see any big changes...

Maybe there are older releases that are better for 2.4ghz ... you are working on this for more then 2 years maybe you remember any... Thanks.

Marvell, with two Ls

1 Like

Fixed, thanks!

My experience with the WRT3200 is that each version has been better than the previous one almost always, so I cannot recommend an older release.

However, many owners of the WRT1900 do complain about drivers getting worse, but I cannot remember if any particular version being specially good, either.

What I can do for you is compile any older version of the driver against the current version of OpenWrt.

If I would only know which version, when I installed Openwrt 17 I had the same issue... maybe to try one before WRT3200 was introduced, you don't have any problems with 2.4Ghz on WRT3200 ?
Thanks.

I think if I'll try LEDE 17.01.3 it should contain old enough driver without 88W8887 or maybe I'm wrong, will try.

Yes, the hard part is finding a version that works for you... Support for the WRT3200 was not introduced, all devices where supported from the beginning.