Pre-compiled updated mwlwifi drivers for stable releases

Hi,

Sorry this is probably a dumb question, but I have a WRT3200ACM and in the /lib/firmware/mwlwifi directory I have both the 88W8864.bin and the 88W8964.bin files present. I am assuming 88W8964.bin is actually in use, though I could you explain how to figure out what is actually in use :-/

Thanks

cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info

Will give you relevant information regarding what is in play, including the version of the BLOB. You will see those two BLOBs on a default type build, if you build your own image you can utilise the per device rootfs to include / exclude things as desired (BT, FW...).

2 Likes

Thank you! Using 88W8964. Hardware version 7, which actually makes me wonder if we should report that sort of info when reporting our success/or not in using different versions of the driver.

I grabbed 21.02.0 yesterday and had issues with the 5ghz wireless (1900acs v1). What's the latest version that works well with the 1900acs radios?

I have been running 19.07.7 with eduperez's drivers for a while now with great performance.

My goal was to get the correct result code from the firmware commands, so I added a check in hif/pcie/pcie.c:

static int pcie_wait_complete(struct mwl_priv *priv, unsigned short cmd)
{
	unsigned int curr_iteration = MAX_WAIT_FW_COMPLETE_ITERATIONS;
	unsigned short int_code = 0;
	unsigned short int_result = 0;
	struct hostcmd_header *cmd_hdr = NULL;

	do {
		int_code = le16_to_cpu(*((__le16 *)&priv->pcmd_buf[0]));
		usleep_range(1000, 2000);
	} while ((int_code != cmd) && (--curr_iteration) && !priv->rmmod);

	if (curr_iteration == 0) {
		cmd_hdr = (struct hostcmd_header *)&priv->pcmd_buf[0];
		int_result = le16_to_cpu(cmd_hdr->result);
		wiphy_err(priv->hw->wiphy, "cmd 0x%04x=%s timed out\n",
			  cmd, mwl_fwcmd_get_cmd_string(cmd));
		wiphy_err(priv->hw->wiphy, "return code: 0x%04x\n", int_result);
		return -EIO;
	}

	if (priv->chip_type != MWL8997)
		usleep_range(3000, 5000);

	return 0;
}

My intention was to get a result code from the firmware, when the timeout is elapsed. But unfortunately the result code is always HOSTCMD_RESULT_OK, also when the timeout is elapsed. I have also tried to set an invalid result code (0xFFFF) for each command, before the command was send via PCIE. But the firmware from the device didn't react as desired. The result was always HOSTCMD_RESULT_NOT_SUPPORT. So all commands failed.

Without my knowledge from the usage of the firmware it's hard for me to solve these issues.

But it was worth for trying it. :slight_smile:

WiFi works for me currently, but only WPA2 and 802.11w Management Frame Protection disabled.

For the OpenWrt developers:
I think it's IMHO better to disable 802.11w in the current stable images for WRT32X by default for the first time, if it's easy to solve. Better for other users. On the current images it's optional in the default configuration, but breaks WiFi completely on this router.

2 Likes

Just a note: I needed to add this fix to resolve the issues I was seeing.

2 Likes

@eduperez would you be able to compile the older driver version for 21.02.0 release?

Similar to how you did with 21.02.0 -RC4. I feel like not enough testing or feedback came back from that. I feel like most users tried downgrading the firmware blog but I did not see any feedback on the older driver plus older firmware blog. I am willing to test if you are able to compile it.

Thank you for your time.

1 Like

I am having a bit of flaky response time on 2ghz/5ghz wifi.
Also looks like 5ghz periodically drops clients.
Is anyone of you have a stable one? If yes could you please share the setup?

//WRT1900AC v1 OpenWrt 21.02.0 r16279-5cc0535800
//AMSDU Disabled

After many testing, the router sooner or later ends with the same wifi problems...
May be you could try this, but you will get no more updates.

Now I´m using wrt1900acs-v2 with wifi OFF and a second router as wifi AP.

I have 1900ACS v1 and haven't noticed any problems running 19.07.7 (running for months with the drivers from eduperez) or 21.02.0 (running for a few weeks with stock drivers and the AMSDU fix).
Random note: I use the 5ghz radio only and the 2.4ghz one I turn off.

1 Like

I just uploaded the packages for the final release of 21.02.0, but using the older 31d93860 drivers, at:

After upgrading my machine, I cannot build packages for 19.07 any longer; I have to prepare a virtual machine, with an older version of the operating system, and this will take some time.

3 Likes

Thank you, sir.

@eduperez I just went to download the drivers for 21.02.0 and they don't seem to be there right now. I'm not sure if there was an issue and you had to take them down or not. But I figured I would let you know just in case. I would like to test them whenever they are ready. Thanks.

1 Like

Sorry... I was doing several things at the same time, and forgot to add the files before closing the browser; thanks for the heads up, the files are there now.

2 Likes

Thank you. I will install these drivers in a few hours on 21.02.0 and will reply again later if this prevents the wireless disconnects or not.

2 Likes

Hi all.

My 5 Ghz network was dropping connections and I found this posting when searching for a solution. I'm somewhat Linux proficient but new to openWRT. So took the plunge and I installed the drivers and after reboot the wireless interfaces are not associated anymore, and when I click on the Edit button I get the message Cannot read properties of undefined (reading 'value')

When checking the status of the wireless interfaces I get the status below.

Any help will be greatly appreciated.

Router is a wrt1900ACS V2 and openWRT version is 21.02.0, driver version is 10.3.8.0-20181210.

Thanks again.

cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
        option country 'US'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option macaddr '30:23:03:d8:79:fb'
        option ssid 'Hershey5'
        option key 'fre3$55aj'
        option ieee80211w '1'
        option encryption 'psk2'
        option wpa_disable_eapol_key_retries '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
        option htmode 'HT20'
        option country 'US'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option macaddr '30:23:03:d8:79:fa'
        option ssid 'Hershey2'
        option encryption 'sae-mixed'
        option key 'fre3$55aj'
        option ieee80211w '1'

If your configuration isn't complex, I think the easiest fix for you would be to re-install or re-flash then use the fix referenced above: Pre-compiled updated mwlwifi drivers for stable releases - #726 by mortac8

I put it in System->Startup->Local Startup (in LuCI)

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
logger "AMSDU Disabled"

exit 0
1 Like

Thanks :wink:

Would this work on 21.02.1 too?

@eduperez Thank you for taking your time to compile the driver/firmware packages for 21.02.0. I appreciate it.

Installation was successful. Unfortunately, however, the driver would fail to load and therefore the wireless interfaces can never initiate. It was worth a try though. I've been trying to rule out anything and everything to determine the issues going on with 21.02.0 and WRT3200/WRT32X wifi.

No, packages are specific to each kernel version; but I can build them for 21.02.1, too.

1 Like