Connection issues with RT-AX86U

[srudin]

I am using 2 AX86U routers as AiMesh (connected by Ethernet-Backhaul cable) and I have around 30 clients (notebooks, mobiles, smart home devices).

I have disabled Smart Connect and set 2 different SSIDs. I use 20MHz/CH11 for 2.4GHz and 80MHz/CH161 for 5GHz. There are no other Wifi networks within 250m of our house and internet connection is fast and stable. I also disabled Agile Multiband, Roaming Assistant, Beanforming. Palette Snooping and most other fancy features that are reported to cause problems sometimes. (Of course this was only done to eliminate possible causes of the problem, I don't intend to keep the settings like this.)

Then I connected my notebook (Windows 11, Wifi 6) to either 2.4 or 5GHz. Everything works fine and I can see my notebook is connected to AiMesh #1. After some random time (let's say something between 1min and 5h) the connection drops for a few seconds, then reconnects. I can now see my notebook connected to AiMesh #2. The switching goes on like that forth and back even my notebook does not move an inch.

Here are some log entries from the system log that I believe are related. My log is FULL of stuff like this for all my devices:

Nov 3 17:46:02 wlceventd: wlceventd_proc_event(530): eth7: Auth XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:0
Nov 3 17:46:02 kernel: br0: received packet on eth7 with own address as source address
Nov 3 17:46:02 wlceventd: wlceventd_proc_event(540): eth7: ReAssoc XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:-88
Nov 3 17:48:04 wlceventd: wlceventd_proc_event(511): eth7: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 3 17:48:04 wlceventd: wlceventd_proc_event(511): eth7: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 3 17:51:41 wlceventd: wlceventd_proc_event(530): eth7: Auth XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:0
Nov 3 17:51:41 kernel: br0: received packet on eth7 with own address as source address
Nov 3 17:51:41 wlceventd: wlceventd_proc_event(540): eth7: ReAssoc XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:-83
Nov 3 17:51:56 wlceventd: wlceventd_proc_event(511): eth7: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 3 17:51:56 wlceventd: wlceventd_proc_event(511): eth7: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

(Note: All log entries have the same real mac.)

Question 1: Is it normal that switching from one mesh node to the other causes an interruption? This is causing issues whenever a constant connection is required, say when having a meeting call or using a remote desktop connection. I would assume that the interruption is a few milliseconds only and not a few seconds.

Question 2: Why is the switching happening at all? I don't move my notebook so no need to switch I think? This also happens with most other devices even they are plugged into an outlet and never move. Can I configure this somehow similar to the smart connection rules? I know I can lock a device to a specific mesh node but I do move my notebook sometimes and then I want it to switch so a permanent binding is not really the solution I'm looking for; I rather like to reduce sensitivity of the switching trigger.

AiMesh is not really helpful that way. Does it work better when I use one router as a repeater instead of an AiMesh node? Any other suggestions?

[ChrisAlbertson]

This happens even if you have just one router and no AiMesh.   So I doubt it s related to  AiMesh.   I have just one Asus router and my logs are flooded with wlceventd events.   

This is a new router and it looks like the only solution is to replace the Asus router with a different brand.   Do a Google search on "wlceventd" and you can see it is a common problem that has been going on for some time.  I doubt it will ever be fixed.

[jzchen]

The RT-AX86U Pro is new.  Before giving up the boat I highly suggest you try the latest firmware 3.0.0.4.388.23285 that was just released 2023/05/15.

My single RT-AX86U is a node in my network and I was happy prior, and am currently happy with it’s performance…

[ChrisAlbertson]

The firmware is the latest.   I unboxed the router last week and updated the firmware before placing it into service.

This Asus router replaced a very old Linksys WiFi 5 (ac) router that never had this problem

The practical issue is that I'm using an Apple Homepod mini as a "border router" to bridge a Thread "fabric" (aka network) to the LAN.   A solution might be to use multiple border routers.  Thread allows this.

Thread is the new home automation network.  It is inherently "mesh" and is based on IP v6.  If it goes down for even a second, then things lke light bulbs and heating stop working.  I might have to retun the Asus router and go with something with better reliabilty and also have redundent border routers.     It is very bad to get up and night and find the lights stop working for minutes at a time.   Also need to find an Ethernet connected border router.  I just need to design a system that still works even after a couple failures.  So I'm buying and testing stuff.   I was shocked at this router's unreliabilry.   

I've found other bugs in the curruent firmware.  Like failing to list all clients on the LAN.

[srudin]

I am now struggling with WAN access. These routers are a big disappointment and a constant hassle. I totally agree about the unreliablity statement above.

Do not buy Asus routers unless you want to spend hundreds of hours analyzing problems.