Nope. Even with the config changes it’s still not working well. I am seriously considering rolling back to 19.07.
1 Like
I live in a house with large garden. Only one neighbor uses the 5 GHz close enough for me to catch a hint of his Wi-Fi: I am sure I am the only one in my frequency, so that should not be the issue.
Can you share the system log?
Thanks. I had better hold off too otherwise I will get grief from the Mrs....!!
Do you know whether a formal bug has been opened to track this issue?
No clue if a bug report has been made. And yes the complains from the Mrs are a big incentive making me roll back!
Sure. Am out of home for a week, but will share when I’m back.
I have updated my build for OpenWrt 21.02.0-rc4.
Do you only do this on the 5ghz radio? I am also having trouble with the 2.4ghz devices dropping off and losing their connection. Thanks
Yes you can use for both radio's.
1 Like
To be sure that we are all having the exact same issue @arinc9 's firmware downgrade would help, are there specific commands (netstat, etc.) that would point the finger at the radio firmware instead of, say, a faulty DHCP server or something else on the router? (21.02 has a ton of changes from 19.07, hence my question).
@arinc9 , @ByteEnable --- are there any diagnostic commands we can run to confirm all on this thread are experiencing the same problem? (e.g., can ping google from router, can't ping google from wifi-connected client. anything more specific?)
When I realize the cut-out happening, I ping my router gateway IP address to make sure there’s an issue with wireless, not the internet connection.
The one test I do most often is to check on a second client connected to the same Wi-Fi if the internet works. It’s always the case: client 1 is connected to Wi-Fi but no internet and for client 2 I’ll works.
The following describes the issue for Android devices and low ack disconnects:
option disassoc_low_ack '0'
The "max_inactivity" option increases timeout from 5 minutes to 12 hours which decreases the disconnect frequency when Android sleeps. So say you are using your phone and set it down, Android sleeps the screen, say 15 minutes later you pick up the phone, the phone is disconnected from AP with the following message:
IEEE 802.11: deauthenticated due to inactivity (timer DEA
UTH/REMOVE)
There is a third issue with Android that I have experienced where all the issues above are resolved with the work-arounds as noted I still experience an issue where I cannot access the Internet. Android says I am connected. OpenWRT log says I am connected but I cannot access any site on the Internet. If I leave it alone it will resolve itself after some minutes. I am impatient so I turn off then on the Android wireless and all is good (reestablish the connection). I also have hostapd loglevel set to 1 and I do not see anything in the log either.
Another distinguishing feature is that I am using "Force CCMP/AES" with WPA2-PSK due to the hackability of TKIP. Also I have no issue with wired LAN when the WiFi is acting up with my Android 11 device.
1 Like
Chiming in just to add me to the list of those having wifi problems with WRT3200acm and 21.02.0. I use a WRT3200ACM as main router and WAN connection and I also have a WRT1900ACv2 cabled in as another AP. Both run great with 19.07.8 and the WRT1900ACv2 seems OK with 21.02.0-rc4 but the WRT3200ACM is to unstable using 21.02.0-rc4 to continue with. I'm nowhere near your levels of talent with these units but my setup problems have me following this thread. Another quirk that I don't think I saw mentioned is that I add an additional WiFi network setup. It allows me to to disable WMM for a few older IOT's that need it off.
config wifi-iface 'wifinet3'
option encryption 'psk2'
option device 'radio1'
option mode 'ap'
option key 'xxxxxxxx'
option wmm '0'
option ssid 'IOT24'
option network 'lan
This has worked with 19.7.8 on both routers and continues to function on the WRT1900ACv2 running 21.02.0-rc4 but has never worked on the WRT3200ACM running any -rc version of 21.02.0. Don't know if this would be related or not.
Thanks for listening to me.
This is exactly the issue I’m having on my WRT32X.
option disassoc_low_ack '0'
From my perpective, this might even be a more general issue. I had the issue on WRT32X and on Mediatek MT76.
I currently have this issue for one IoT device recently joined to WiFi and the issue is also there on V19.07, if this option is on (it is default on on OpenWRT images). Picky devices do not seem to like this option being on. Took me quite a while to identify the cause.
I tend to say this option should be made default-off on all routers in future OpenWRT deployments, to make OpenWRT more user friendly out of the box.
This option seems like a feature made for professional environments to get rid of lazy clients early, to free some mem, but I do not understand at all the advantage of this feature being default-on in home environment.
I can find quite some threads when searching where this is recommended as fix.
2 Likes
WRT32X here too, I've had the issue on 21.02-rc's where I have to turn on/off wifi on my iPhone for the internet to respond. This doesn't happen on my ThinkPad, just iPhone. There is definitely a bug/problem in 21.02. Every other aspect of this firmware is phenomial except this but it's a dealbreaker because of how annoying it is.
@arinc9 i read through your post here: https://github.com/openwrt/openwrt/pull/4381 very interesdting findings.
Update: been running a Master snapshot for 1 week uptime now, this wifi stalling issue does not occur. Everything has been basically flawless. Sticking with Master for now.
3 Likes
Master branch, I suspect, has a proper fix to this so there’s no need to downgrade the firmware. I initially planned on backporting the fixes on the main branch to 21.02 branch but I can’t make up time to work on it.
1 Like
@phinn @arinc9 Another option worth trying is @eduperez was nice enough to create driver/firmware packages for RC4 specifically. I believe that it is compiled with the previous firmware blog and also a slightly older driver version. I have not tried it yet though.
Link: Pre-compiled updated mwlwifi drivers for stable releases - #696 by eduperez
1 Like
You say that master has a suspected fix for this, but I'm running the Divested build on Divested-WRT SNAPSHOT r17276+9-b1bff5cb57, and I'm seeing wifi issues that seem in line with this.
You can see my original message about it here in the Divested thread, with my follow up post here that describes seeing deauthenticated due to inactivity (timer DEAUTH/REMOVE) messages.
I'll admit that the issue does seem rare, sometimes I go a full 24 hours without seeing it and other days I've seen it at least twice in one day.
Is it worth trying your downgrade patch, or should I try something else?