I just installed the stable 21.02.0 release on a WRT32X. Run into the same issue. But unfortunately firmware 9.3.2.6 didn't help. Another strange issue is, that the OpenWrt web interface is no longer accessible after a while when enabling WIFI. Has somebody noticed the same issue?
Just did a clean install of 21.02.0 and reconfigured from scratch. Will see if wifi is better or not in the next days. Do not have much hope, but with 19.07.08 stable config on the alternate partition + advanced reboot it will be a breeze to go back if any issue.
I finished setting up yesterday evening, and now about 24hrs later, I haven't seen any major issues. I have a mix of laptops with Marvell & Qualcomm chips, as well as an Android and an iPhone. I worked from home today and none of those devices had any drops.
One of my Google speakers wasn't playing music this morning and I had to restart it, but casting has always been tricky for me so I'm not ready to say the new OpenWrt caused the issue.
Just did a sysupgrade to 21.02 from 19.07.8 and started config from scratch. Can confirm that a Galaxy S10 loses internet connectivity after a certain period of time. Have reverted back to 19.08 for now in the hope it will get fixed. If not, will have to consider downgrading my WRT3200 to router/firewall only.
I was hoping it would get ironed out, but alas; looks like I'll be on Davidc502's last build for a while longer
I keep checking back periodically to see if there has been a fix.. I'm not a developer or anything, but it would seem possible since it worked on the swconfig builds (DSA shouldn't be the reason but I've had issues with all of the newer builds and kind of gave up)
Can confirm - 21.02 fails on my WRT3200ACM, just like master does.
I specifically used the firmware built by the OpenWrt team, downloaded using the firmware selector, just in case my compiling from scratch approach was causing the issue.
Same issue with iPhone - connected to WiFi, but no traffic flows. Can’t even access OpenWrt web UI.
I have the same problem with WRT1200AC, all workarounds posted here don't work. I had to revert to 19.07.
The problem is only on iPhones and with Samsung S20, all other devices seem to work just fine.
9+ days uptime on WRT1900ACS and wifi is normal. I did a fresh install of 21.02, config from scratch. FWIW I have the following packages: wireguard, vpr, sqm, adblock, and irqbalance (change 'enabled' from '0' to '1' in '/etc/config/irqbalance'.
I also added in luci > startup > local startup the following commands:
Sony Xperia XZ2 Smartphone (Chip: Don't know the builtin WiFi chip)
Lenovo ThinkPad T460p running Windows 10 (Chip: Intel Dual Band Wireless-AC 8260)
All my other devices (Desktop PC, PS4, Smart-TV) in my network are connected via LAN cable. No issues here.
After enabling WiFi on the router the devices can successfully connect for a few minutes. Then they loses the connection. A side effect is that the WebUI from OpenWrt isn't longer accessible.
No issue with these WiFi devices on 19.07.
Is there way to support the OpenWrt developer with this issue? Testing bugfixes as example? Currently I don't revert back to 19.07.
WiFi stops working at the above Kernel messages. Here I have a newbie question about the WiFi driver. The first message is printed at this lines in the driver:
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;
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) {
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_code);
return -EIO;
}
if (priv->chip_type != MWL8997)
usleep_range(3000, 5000);
return 0;
}
I don't understand, why there is a query for the command itself, not the result code form the WiFi chip and in the posted second line the FW command will be printed. IMHO this isn't the correct result code. It's the executed command itself.
Here are some result code defined in the driver:
/* Define general result code for each command */
#define HOSTCMD_RESULT_OK 0x0000
/* General error */
#define HOSTCMD_RESULT_ERROR 0x0001
/* Command is not valid */
#define HOSTCMD_RESULT_NOT_SUPPORT 0x0002
/* Command is pending (will be processed) */
#define HOSTCMD_RESULT_PENDING 0x0003
/* System is busy (command ignored) */
#define HOSTCMD_RESULT_BUSY 0x0004
/* Data buffer is not big enough */
#define HOSTCMD_RESULT_PARTIAL_DATA 0x0005
I will change the code and add a IMHO "correct" (print the command results) command wait routine for this issue and print the real response (result) code from the chip.
EDIT:
Or shortened: Why doesn't check the driver the result code, when a command is send via PCIE?
Have I misunderstood something in the driver, or read over something?
Yes. But I think it's better a few people can verify the patch. It works for me, but not sure if it fixes the other users issues.
I also didn't test WPA3 at this time.
It was only a test for getting the correct result. A side effect is, that it fixes the WiFi issue fro me, which was also on WPA2 present on my WRT-32X.
