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?
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.
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.
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! )
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 ">")
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 :-/
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...).
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.
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.
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.
@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.
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?
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.
)