Asus RT-AC3100 WiFi stability issues

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

WindyT

Occasional Visitor
I am having major issues with WiFi stability - devices are randomly disconnected and/or have a very low performance. Single router no mash setup.

Syslog shows a lot of auth/deauth msgs - these devices should not be disconnecting - they are Wyze security cameras. But even a laptop or a smartphone will connect fine, then it will lose connectivity to internet and after manual reconnect the performance can be slow.

I have tried to reset and do settings manually again to no change. Firmware rollback - to what?

Currently on 3.0.0.4.386_41700
SmartConnect is OFF (2 separate networks for 2.4 and 5 GHz)
All default settings for wireless at this moment (after the reset)

Syslog:
May 5 14:13:38 syslog: wlceventd_proc_event(526): eth1: Auth F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:13:38 syslog: wlceventd_proc_event(555): eth1: Assoc F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:14:14 syslog: wlceventd_proc_event(490): eth1: Deauth_ind F0:03:8C:8E:E0:69, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:0
May 5 14:14:16 syslog: wlceventd_proc_event(526): eth1: Auth F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:14:16 syslog: wlceventd_proc_event(555): eth1: Assoc F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:14:39 kernel: [Wed May 5 14:14:39 DST 2021] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
May 5 14:14:39 kernel: [Wed May 5 14:14:39 DST 2021] Could not get nonce, let's try again.
May 5 14:14:52 syslog: wlceventd_proc_event(490): eth1: Deauth_ind F0:03:8C:8E:E0:69, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:0
May 5 14:14:55 syslog: wlceventd_proc_event(526): eth1: Auth F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:14:55 syslog: wlceventd_proc_event(555): eth1: Assoc F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:15:32 syslog: wlceventd_proc_event(490): eth1: Deauth_ind F0:03:8C:8E:E0:69, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:0
May 5 14:15:34 syslog: wlceventd_proc_event(526): eth1: Auth F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:15:34 syslog: wlceventd_proc_event(555): eth1: Assoc F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:15:42 kernel: [Wed May 5 14:15:42 DST 2021] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
May 5 14:15:42 kernel: [Wed May 5 14:15:42 DST 2021] Could not get nonce, let's try again.
May 5 14:16:11 syslog: wlceventd_proc_event(490): eth1: Deauth_ind F0:03:8C:8E:E0:69, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:0
May 5 14:16:14 syslog: wlceventd_proc_event(526): eth1: Auth F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:16:14 syslog: wlceventd_proc_event(555): eth1: Assoc F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:16:45 kernel: [Wed May 5 14:16:45 DST 2021] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
May 5 14:16:45 kernel: [Wed May 5 14:16:45 DST 2021] Could not get nonce, let's try again.
May 5 14:16:50 syslog: wlceventd_proc_event(490): eth1: Deauth_ind F0:03:8C:8E:E0:69, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:0
May 5 14:16:52 syslog: wlceventd_proc_event(526): eth1: Auth F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:16:52 syslog: wlceventd_proc_event(555): eth1: Assoc F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:17:03 syslog: wlceventd_proc_event(490): eth1: Deauth_ind 34:6F:92:0A:58:03, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:0
May 5 14:17:04 syslog: wlceventd_proc_event(526): eth1: Auth 34:6F:92:0A:58:03, status: Successful (0), rssi:0
May 5 14:17:04 syslog: wlceventd_proc_event(555): eth1: Assoc 34:6F:92:0A:58:03, status: Successful (0), rssi:0
May 5 14:17:28 syslog: wlceventd_proc_event(490): eth1: Deauth_ind F0:03:8C:8E:E0:69, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:0
May 5 14:17:30 syslog: wlceventd_proc_event(526): eth1: Auth F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:17:30 syslog: wlceventd_proc_event(555): eth1: Assoc F0:03:8C:8E:E0:69, status: Successful (0), rssi:0
May 5 14:17:47 kernel: [Wed May 5 14:17:47 DST 2021] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
May 5 14:17:47 kernel: [Wed May 5 14:17:47 DST 2021] Could not get nonce, let's try again.
 

bbunge

Part of the Furniture
Use fixed channels for both 2.4 and 5 GHZ. Use dual band smart connect if available. Disable Airtime fairness and universal beamforming.
2.4 GHZ at 20 MHZ channel 1, 6 or 11
5 GHZ at 80 MHZ on channel 36 or 149. Avoid DFS channels.
 

bsdsource

Regular Contributor
I've had an RT-AC3100 for several years with 20+ clients connecting to it daily without any issues. Fixed channels as bbunge mentioned have proven to be more stable than using auto (dynamic). You should also upgrade your firmware to 9.0.0.4.386_41994 since several exploits have been fixed with this version. I've attached screenshots of my 2.4 and 5 Ghz Wireless --> Professional settings.

1.png2.png
 

WindyT

Occasional Visitor
Thanks guys, I have updated the settings per your recommendation - let's see how it performs (fairness and airbeaming was enabled, channels were auto - all changed)

I seen the 41994 FW but it was beta and I did not want to add another vairable. Will update as soon as they are done with the testing.

THX!
 

WindyT

Occasional Visitor
Did the reset, used exactly the same setting and I am still having issue. Ping from my Mac to the router:

PING 192.168.9.1 (192.168.9.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
64 bytes from 192.168.9.1: icmp_seq=1 ttl=64 time=1389.676 ms
64 bytes from 192.168.9.1: icmp_seq=2 ttl=64 time=1667.701 ms
Request timeout for icmp_seq 4
64 bytes from 192.168.9.1: icmp_seq=3 ttl=64 time=2225.177 ms
64 bytes from 192.168.9.1: icmp_seq=4 ttl=64 time=1744.027 ms
64 bytes from 192.168.9.1: icmp_seq=6 ttl=64 time=292.840 ms
Request timeout for icmp_seq 8
64 bytes from 192.168.9.1: icmp_seq=9 ttl=64 time=200.270 ms


You can see the dropped connetions - mac and with 1B is my Macbook:

May 17 10:27:08 syslog: wlceventd_proc_event(526): eth1: Auth A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 10:27:24 syslog: wlceventd_proc_event(526): eth1: Auth A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 10:27:53 syslog: wlceventd_proc_event(526): eth1: Auth A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 10:29:15 syslog: wlceventd_proc_event(526): eth1: Auth A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 10:29:18 syslog: wlceventd_proc_event(526): eth1: Auth A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 10:29:18 syslog: wlceventd_proc_event(555): eth1: Assoc A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 11:19:47 kernel: SHN Release Version: 2.0.1 f45bb18
May 17 11:19:47 kernel: UDB Core Version: 0.2.20
May 17 11:19:48 kernel: sizeof forward pkt param = 192
May 17 18:19:48 BWDPI: fun bitmap = 3
May 17 11:30:12 syslog: wlceventd_proc_event(507): eth1: Disassoc A0:78:17:74:80:1B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
May 17 11:30:16 syslog: wlceventd_proc_event(526): eth1: Auth A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 11:30:16 syslog: wlceventd_proc_event(555): eth1: Assoc A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 11:35:52 syslog: wlceventd_proc_event(526): eth2: Auth A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 11:35:52 syslog: wlceventd_proc_event(536): eth2: ReAssoc A0:78:17:74:80:1B, status: Successful (0), rssi:0
May 17 11:36:25 syslog: wlceventd_proc_event(490): eth1: Deauth_ind A0:78:17:74:80:1B, status: 0, reason: Disassociated due to inactivity (4), rssi:0

May 17 11:36:25 syslog: wlceventd_proc_event(507): eth1: Disassoc A0:78:17:74:80:1B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Do I need to go and replace the router?
 

bsdsource

Regular Contributor
I would not use dual band smart connect. You don't want your wireless device to roam between 2 separate bands right now. Try connecting your apple device to the 2.4 GHz SSID only which will probably give you better reception unless you run into significant wireless interference. Also, Apple has recently added a security feature which randomizes the MAC address of your wireless Apple device. Disable it and restart the Apple device.

I have found that although I've disabled smart connect, and I'm not using AiMesh, there are 5 instances of roamast running on my RT-AC3100 router. From the console, I've killed all the roamast processes but they immediately restart. I do believe this process running in the background could possibly be the culprit.

On my RT-AX88U, I'm using the exact same settings I provided you with. I checked all the running processes and there is only 1 roamast process running vs the 5 that are running on my RT-AC3100.

The "status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0" event is not only happening on the RT-AC3100, it's happening on several other ASUS wireless routers as well. The RT-AC3100 is still a good router and I wouldn't necessarily buy a new router unless you can't get this sorted out and due to it probably reaching end of life sometime soon (completely conjecture on my part).

Some users have reported that setting up a guest network and connecting to it has resolved the issue you are experiencing. This is obviously a workaround until ASUS is able to isolate and fix this issue for good.
 

WindyT

Occasional Visitor
I disabled SmartConnect - the problem is still there. Up to the point I can't do any conf calls as the audio gets dropped. I am connected to the 2.4 Ghz and there is jitter, connections dropped etc. When I am next to the router - less than 5 feet it gets better, but 20 feet plus it's unusable.

if there would be confirmation Asus is working on this and can solve the issue great, but I need a reliable connection. If you are correct and the AC3100 is going to be EOL, what are the chances of getting this fixed? I spend so much time on this in the last 5 months, it's getting really frustrating.
 

bsdsource

Regular Contributor
Well sorry to hear that things are still not working out. Good news though, ASUS just released the following new firmware today:

ASUS RT-AC3100 Firmware version 3.0.0.4.386.43129
(2021/05/18)
1.
Fixed the FragAttack vulnerability.
2. Fixed DoS vulnerability. Thanks for Tsinghua University NISL's contribution.
3. Improved system stability.
4. Fixed GUI bugs.
5. Security Fixed: CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687, CVE-2020-25684, CVE-2020-25685, CVE-2020-25686

Fixes a bunch of vulnerabilities and "Improved system stability"! I'll be installing this version later tonight. You might want to give this version a try to see if things improve before moving on.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top