Solved RT-BE92U connections in AIMesh nodes intermittently dropped (Caused by FW 3.0.0.6 not compatible with FW 3.0.0.4 routers))

[TurboWG]

I noticed that my AIMesh nodes (wired connection) intermittently dropped all the connections and I don't have a clue what happened.
Attached are the snapshots and system log.

If someone can give me and possible solutions that will be great!
Thanks!


Nov 24 12:40:50 roamast: [EXAP]Deauth old sta in 1 2: 3A:84:C9:84:39:51
Nov 24 12:40:50 roamast: wl1.2: disconnect weak signal strength station [3a:84:c9:84:39:51]
Nov 24 12:40:50 wlceventd: wlceventd_proc_event(645): wl1.2: Deauth_ind 3A:84:C9:84:39:51, status: 0, reason: Previous authentication no longer valid (2), rssi:-77
Nov 24 12:40:50 kernel: CFG80211-ERROR) wl_cfg80211_del_station :
Nov 24 12:40:50 kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Nov 24 12:40:50 roamast: wl1.2: remove client [3a:84:c9:84:39:51] from monitor list
Nov 24 12:40:50 hostapd: wl1.2: STA 3a:84:c9:84:39:51 IEEE 802.11: disassociated
Nov 24 12:40:51 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=79.110.62.155 DST=72.80.147.185 LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=64889 PROTO=TCP SPT=49716 DPT=12742 SEQ=3770375942 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 24 12:40:51 hostapd: wl1.2: STA 3a:84:c9:84:39:51 IEEE 802.11: disassociated
Nov 24 12:40:51 wlceventd: wlceventd_proc_event(645): wl1.2: Deauth_ind 3A:84:C9:84:39:51, status: 0, reason: Previous authentication no longer valid (2), rssi:-77
Nov 24 12:43:33 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=62.210.214.174 DST=72.80.147.185 LEN=128 TOS=0x00 PREC=0x00 TTL=55 ID=36699 DF PROTO=UDP SPT=7429 DPT=6881 LEN=108 MARK=0x8000000
Nov 24 12:43:39 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=108.181.63.7 DST=72.80.147.185 LEN=68 TOS=0x08 PREC=0x20 TTL=59 ID=18238 DF PROTO=UDP SPT=45699 DPT=44180 LEN=48 MARK=0x8000000
Nov 24 12:43:39 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=192.99.7.92 DST=72.80.147.185 LEN=68 TOS=0x00 PREC=0x00 TTL=53 ID=40270 DF PROTO=UDP SPT=27757 DPT=44180 LEN=48 MARK=0x8000000
Nov 24 12:43:39 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=108.181.22.229 DST=72.80.147.185 LEN=68 TOS=0x00 PREC=0x00 TTL=56 ID=37819 DF PROTO=UDP SPT=51984 DPT=44180 LEN=48 MARK=0x8000000
Nov 24 12:43:40 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=66.23.205.130 DST=72.80.147.185 LEN=68 TOS=0x00 PREC=0x00 TTL=58 ID=42650 DF PROTO=UDP SPT=44936 DPT=38752 LEN=48 MARK=0x8000000
Nov 24 12:43:40 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=192.99.4.118 DST=72.80.147.185 LEN=68 TOS=0x00 PREC=0x00 TTL=53 ID=6239 DF PROTO=UDP SPT=31471 DPT=38752 LEN=48 MARK=0x8000000
Nov 24 12:43:40 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=64.120.2.242 DST=72.80.147.185 LEN=68 TOS=0x08 PREC=0x20 TTL=56 ID=60249 DF PROTO=UDP SPT=44219 DPT=38752 LEN=48 MARK=0x8000000
Nov 24 12:43:50 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=162.216.150.62 DST=72.80.147.185 LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=54321 PROTO=TCP SPT=56534 DPT=10019 SEQ=1701960919 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4) MARK=0x8000000
Nov 24 12:43:52 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=109.248.252.223 DST=72.80.147.185 LEN=134 TOS=0x00 PREC=0x00 TTL=115 ID=1416 PROTO=UDP SPT=14784 DPT=6881 LEN=114 MARK=0x8000000
Nov 24 12:43:59 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=108.181.63.7 DST=72.80.147.185 LEN=68 TOS=0x08 PREC=0x20 TTL=59 ID=22517 DF PROTO=UDP SPT=45699 DPT=44180 LEN=48 MARK=0x8000000
Nov 24 12:43:59 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=192.99.7.92 DST=72.80.147.185 LEN=68 TOS=0x00 PREC=0x00 TTL=53 ID=43836 DF PROTO=UDP SPT=27757 DPT=44180 LEN=48 MARK=0x8000000
Nov 24 12:43:59 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=108.181.22.229 DST=72.80.147.185 LEN=68 TOS=0x00 PREC=0x00 TTL=56 ID=40443 DF PROTO=UDP SPT=51984 DPT=44180 LEN=48 MARK=0x8000000
Nov 24 12:44:00 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=66.23.205.130 DST=72.80.147.185 LEN=68 TOS=0x00 PREC=0x00 TTL=58 ID=45345 DF PROTO=UDP SPT=44936 DPT=38752 LEN=48 MARK=0x8000000
Nov 24 12:44:00 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=192.99.4.118 DST=72.80.147.185 LEN=68 TOS=0x00 PREC=0x00 TTL=53 ID=8845 DF PROTO=UDP SPT=31471 DPT=38752 LEN=48 MARK=0x8000000
Nov 24 12:44:00 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=64.120.2.242 DST=72.80.147.185 LEN=68 TOS=0x08 PREC=0x20 TTL=56 ID=62997 DF PROTO=UDP SPT=44219 DPT=38752 LEN=48 MARK=0x8000000
Nov 24 12:44:01 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=79.124.62.126 DST=72.80.147.185 LEN=40 TOS=0x00 PREC=0x00 TTL=247 ID=59195 PROTO=TCP SPT=46927 DPT=8100 SEQ=1699769126 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 24 12:44:05 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=122.194.84.35 DST=72.80.147.185 LEN=147 TOS=0x00 PREC=0x00 TTL=116 ID=33883 PROTO=UDP SPT=15000 DPT=6881 LEN=127 MARK=0x8000000
Nov 24 12:44:10 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=167.94.145.25 DST=72.80.147.185 LEN=60 TOS=0x00 PREC=0x00 TTL=59 ID=62969 PROTO=TCP SPT=61362 DPT=5222 SEQ=1642958405 ACK=0 WINDOW=42340 RES=0x00 SYN URGP=0 OPT (020405B40402080A673B7092000000000103030A) MARK=0x8000000
Nov 24 12:44:35 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=111.49.67.3 DST=72.80.147.185 LEN=143 TOS=0x04 PREC=0x00 TTL=113 ID=21488 PROTO=UDP SPT=1373 DPT=6881 LEN=123 MARK=0x8000000
Nov 24 12:44:36 kernel: SUSPREQ 0 SUSPREQ1 0 SUSPREQ2 0
Nov 24 12:44:36 kernel: CHNSUSP_STATUS 0 CHNSUSP_STATUS1 0 CHNSUSP_STATUS2 0
Nov 24 12:44:36 kernel: FLUSHREQ 0 FLUSHREQ1 0 FLUSHREQ2 0
Nov 24 12:44:36 kernel: CHNFLUSH_STATUS 0 CHNFLUSH_STATUS1 0 CHNFLUSH_STATUS2 0
Nov 24 12:44:36 kernel: intstatus 0x0 intmask 0x10000 aqm_intstatus 0x0 aqm_intmask 0x6fffbfef
Nov 24 12:44:36 kernel: puq_idx active lmidx tid txmode 0 0x 3f 7 16384 1 raw data 0xb83f
Nov 24 12:44:36 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0xfeefbbcf
Nov 24 12:44:36 kernel: puq_idx active lmidx tid txmode 1 0x 0 0 0 0 raw data 0x0
Nov 24 12:44:36 kernel: intstatus 0x0 intmask 0x10000 aqm_intstatus 0x0 aqm_intmask 0xfffdf6fd
Nov 24 12:44:36 kernel: puq_idx active lmidx tid txmode 2 0x 0 0 0 0 raw data 0x0
Nov 24 12:44:36 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0xb7fafff9
Nov 24 12:44:36 kernel: puq_idx active lmidx tid txmode 3 0x 3f 0 16384 1 raw data 0x803f
Nov 24 12:44:36 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0xfdfeffff
Nov 24 12:44:36 kernel: puq_idx active lmidx tid txmode 4 0x 11 6 16384 1 raw data 0xb011
Nov 24 12:44:36 kernel: DROP IN=eth0 OUT= MAC=10:7c:61:ed:05:20:f4:b5:2f:05:00:ca:08:00 SRC=78.131.206.135 DST=72.80.147.185 LEN=145 TOS=0x00 PREC=0x00 TTL=121 ID=43887 PROTO=UDP SPT=29523 DPT=6881 LEN=125 MARK=0x8000000
Nov 24 12:44:36 kernel: wl0: wlc_ftm_hal_csi_buf_get:1760: hal 0000000034eabf9f
Nov 24 12:44:36 kernel: CSIMON: CSIMON[1.1.1] Initialization
Nov 24 12:44:36 kernel: CSIMON: M2M usr already registered ...

 

[Tech9]

I'm afraid no one (including Asus) can give you an answer what is happening to this mix of Broadcom, MedaTek and Intel based hardware all running different base firmware. Three are End-of-Life devices, one with no AiMesh 2.0 support and two known to be below average reliability models.

I would reduce the number of nodes as first troubleshooting step. Do you really need 5x routers in your place all fighting for airtime on the same Wi-Fi channels in AiMesh configuration? You perhaps have too much Wi-Fi and this by itself is a big issue for overall system performance and stability.

 

[TurboWG]

Thanks for the prompt response. I get it, less is more. However, signals seem to be bad in my home. I don't know if it's the walls, interference of wifi devices in overcrowded buildings here in NYC, or the combination of all above. The super outdated Blue Cave is trapped behind a heavy metal garage door 20ft away from the main building. I have many Wyze cameras around the house. Thought all the routers should work together with AiMesh 1.0/AiMesh 2.0.

 

[TurboWG]

It seems like a lot of the forum posts are addressing issues that Asus should have already anticipated and resolved.

 

[Tech9]

If the environment is really challenging you may want to explore better options including rebuilding the entire system. AiMesh doesn't scale very well and has very limited node control options. The more you mix and match the more unknowns in the equation. I would try Router + AP Mode configuration. It allows per device Tx power adjustment as well as different Wi-Fi channels. May work better for your environment.

 

[TurboWG]

Thank you for the advise. I removed the Blue Cave from AiMesh and guess what? It's been stable so far (knock on wood). So in my situation I think it's the AiMesh 1.0 device that's incompatible with the latest Wifi 7 main router.

 

[Tech9]

See how it goes. Balanced Wi-Fi links work best, but unfortunately this is hard to achieve to impossible in AiMesh. Right now you have up to 4000mW radios to 15-25mW clients. The communication from the clients back to the router has to go through the same walls. Your clients are like someone in the middle of the crowd on a Metallica concert trying to tell something to James Hetfield in front of 20kW speaker boxes blasting "Enter Sandman".

 

[TurboWG]

See how it goes. Balanced Wi-Fi links work best, but unfortunately this is hard to achieve to impossible in AiMesh. Right now you have up to 4000mW radios to 15-25mW clients. The communication from the clients back to the router has to go through the same walls. Your clients are like someone in the middle of the crowd on a Metallica concert trying to tell something to James Hetfield in front of 20kW speaker boxes blasting "Enter Sandman".

I found your answer in another post regarding the compatibility issues between firmware 3006 and 3004, which I can now confirm are causing the problems I am facing. The Guest/VLAN networks and default IoT network on the BE92U do not extend beyond the main router. When I attempted to log into the guest networks from a room out of reach of the main router, the authentication failed because firmware 3006 could not communicate with firmware 3004 to retrieve the guest network information. However, the main network (2.4Ghz & 5Ghz) synchronizes across all nodes without any issues. To mitigate this, I have switched the IoT network to the main network on the 2.4GHz band and use the 5GHz band for my iPhones, iPads, and computers. As a long-term solution, I may need to invest in another BE92U.

 

[Tech9]

The Guest/VLAN networks and default IoT network on the BE92U do not extend beyond the main router.

There is no guarantee this will work. What we know so far - it works with specific models and doesn't with others. There is no official Asus statement about Guest Network Pro compatibility. The only guaranteed solution is all main router and nodes on 3006 firmware. And even then there is no guarantee because Asuswrt is in perpetual work in progress beta stage. What works today may not work tomorrow after firmware upgrade. Test your luck.

 

[jksmurf]

What we know so far - it works with specific models and doesn't with others.

For a very small selection of examples of working models and nodes see here, post #15, post #19 and post #35.

But Tech9 is correct, it’s all quite vague from a formal perspective.