Upgrades break AiMesh RT-AC86U primary and two RT-AC1900P nodes

[semigator]

I like AiMesh in my home despite the headaches and lack of standards. Recently, I've been forced to stay at lower firmware levels on my primary RT-AC86U with 3.0.0.4.384_45717 and two RT-AC1900P nodes at 3.0.0.4.384_45149 for different reasons. Both nodes are connected to the primary via Ethernet as the preferred connection method. I'm looking for suggestions to fix the isuses below:

I tried RT-AC86U 81049 (plus the recent dud that froze the UI) and have an issue shown in other threads where there are frequent disassociation messages. This upgrade is not allowing my Honeywell thermostats to connect to the wifi network without throwing error messages from Honeywell. Therefore I downgraded to 45717.

On my two 1900P nodes (real, not TM), if I upgrade beyond 45149 I experience acsd scan messages every 15 minutes that change my fixed 2.4 and 5 GHz wifi channels to a different channel, drop all the clients on the node, then changes back to my fixed channels. I have seen this discussed in other threads, plus I reported this to Asus and was told it would be fixed in 3 months. That was a couple months ago, so I tried 81049 and the acsd messages with channel changes and client drops are back. So I am stuck at 45149 on the nodes.

Both are issues that seem to be happening to other users. I have wiped both AiMesh nodes multiple times to re-added them to AiMesh, but that doesn't help. Now that Merlin has AiMesh, will moving to it resolve either issue? Any other suggestions on fixing these problems?

 

[OzarkEdge]

I like AiMesh in my home despite the headaches and lack of standards. Recently, I've been forced to stay at lower firmware levels on my primary RT-AC86U with 3.0.0.4.384_45717 and two RT-AC1900P nodes at 3.0.0.4.384_45149 for different reasons. Both nodes are connected to the primary via Ethernet as the preferred connection method. I'm looking for suggestions to fix the isuses below:

I tried RT-AC86U 81049 (plus the recent dud that froze the UI) and have an issue shown in other threads where there are frequent disassociation messages. This upgrade is not allowing my Honeywell thermostats to connect to the wifi network without throwing error messages from Honeywell. Therefore I downgraded to 45717.

On my two 1900P nodes (real, not TM), if I upgrade beyond 45149 I experience acsd scan messages every 15 minutes that change my fixed 2.4 and 5 GHz wifi channels to a different channel, drop all the clients on the node, then changes back to my fixed channels. I have seen this discussed in other threads, plus I reported this to Asus and was told it would be fixed in 3 months. That was a couple months ago, so I tried 81049 and the acsd messages with channel changes and client drops are back. So I am stuck at 45149 on the nodes.

Both are issues that seem to be happening to other users. I have wiped both AiMesh nodes multiple times to re-added them to AiMesh, but that doesn't help. Now that Merlin has AiMesh, will moving to it resolve either issue? Any other suggestions on fixing these problems?

Smart post!

So, maybe we are still waiting for the 3 month fix for channel scanning... I hope. I am surprised that you have channel changes when apparently using fixed channels i.e., no Smart Connect and separate SSIDs. I have not seen that... fixed channels stick here with no scanning/changes.

My experience with 45149 is that Trend Micro crashes, and with 45713,7 it consumes memory, so I Withdrew under Administration\Privacy. Maybe if you use any of its features, it could be causing system/memory-related issues at large. So maybe disabling TM stuff would allow you to get all to 45717. Maybe.

Asuswrt-Merlin 384.13 is currently using 45717 and the AiMesh code is closed by ASUS, so it is not going to fixed these AiMesh gowing pains, imo.

OE

 

[semigator]

Below is one of my 1900P node syslogs from ssh. You can get a sense of how unhappy it is on 81049. I use channel 1/20 for 2.4 GHz and 48/80 for 5 Ghz. Every channel change drops all the stations on the node. The 000:2D:xx:xx:xx stations can't stay connected on this build. I do use Trend Micro on the primary 86U, but haven't seen it crash.


Sep 6 12:41:37 acsd: scan in progress ...
Sep 6 12:41:37 acsd: scan in progress ...
Sep 6 12:41:37 acsd: scan in progress ...
Sep 6 12:41:37 acsd: scan in progress ...
Sep 6 12:41:38 acsd: scan in progress ...
Sep 6 12:41:38 acsd: scan in progress ...
Sep 6 12:41:38 acsd: scan in progress ...
Sep 6 12:41:38 acsd: scan in progress ...
Sep 6 12:41:39 acsd: selected channel spec: 0xe39b (161/80)
Sep 6 12:41:39 acsd: Adjusted channel spec: 0xe39b (161/80)
Sep 6 12:41:39 acsd: selected DFS-exit channel spec: 0xe39b (161/80)
Sep 6 12:41:40 acsd: wl1.1: NONACSD channel switching to channel spec: 0xd095 (149)
Sep 6 12:41:55 acsd: wl1.1: NONACSD channel switching to channel spec: 0xe32a (48/80)
Sep 6 12:42:40 syslog: WLCEVENTD wlceventd_proc_event(420): wl1.1: Auth C4:84:66:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:40 syslog: WLCEVENTD wlceventd_proc_event(420): wl1.1: Auth C4:84:66:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:40 syslog: WLCEVENTD wlceventd_proc_event(420): wl1.1: Auth C4:84:66:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:40 syslog: WLCEVENTD wlceventd_proc_event(430): wl1.1: ReAssoc C4:84:66:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:41 syslog: WLCEVENTD wlceventd_proc_event(420): wl0.1: Auth 000:2D:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:41 syslog: WLCEVENTD wlceventd_proc_event(430): wl0.1: ReAssoc 000:2D:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:46 syslog: WLCEVENTD wlceventd_proc_event(386): wl1.1: Deauth_ind C4:84:66:xx:xx:xx, status: 0, reason: 4-way handshake timeout (f)
Sep 6 12:42:47 roamast: wl1.1: disconnect weak signal strength station [c4:84:66:xx:xx:xx]
Sep 6 12:42:47 roamast: wl1.1: remove client [c4:84:66:xx:xx:xx] from monitor list
Sep 6 12:42:54 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind C4:01:00:xx:xx:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep 6 12:42:54 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind 4C:A1:61:xx:xx:xx, status: 0, reason: Class 3 frame received from nonassociated station (7)
Sep 6 12:42:54 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind 000:2D:xx:xx:xx, status: 0, reason: Class 3 frame received from nonassociated station (7)

 

[OzarkEdge]

Below is one of my 1900P node syslogs from ssh. You can get a sense of how unhappy it is on 81049. I use channel 1/20 for 2.4 GHz and 48/80 for 5 Ghz. Every channel change drops all the stations on the node. The 000:2D:xx:xx:xx stations can't stay connected on this build. I do use Trend Micro on the primary 86U, but haven't seen it crash.


Sep 6 12:41:37 acsd: scan in progress ...
Sep 6 12:41:37 acsd: scan in progress ...
Sep 6 12:41:37 acsd: scan in progress ...
Sep 6 12:41:37 acsd: scan in progress ...
Sep 6 12:41:38 acsd: scan in progress ...
Sep 6 12:41:38 acsd: scan in progress ...
Sep 6 12:41:38 acsd: scan in progress ...
Sep 6 12:41:38 acsd: scan in progress ...
Sep 6 12:41:39 acsd: selected channel spec: 0xe39b (161/80)
Sep 6 12:41:39 acsd: Adjusted channel spec: 0xe39b (161/80)
Sep 6 12:41:39 acsd: selected DFS-exit channel spec: 0xe39b (161/80)
Sep 6 12:41:40 acsd: wl1.1: NONACSD channel switching to channel spec: 0xd095 (149)
Sep 6 12:41:55 acsd: wl1.1: NONACSD channel switching to channel spec: 0xe32a (48/80)
Sep 6 12:42:40 syslog: WLCEVENTD wlceventd_proc_event(420): wl1.1: Auth C4:84:66:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:40 syslog: WLCEVENTD wlceventd_proc_event(420): wl1.1: Auth C4:84:66:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:40 syslog: WLCEVENTD wlceventd_proc_event(420): wl1.1: Auth C4:84:66:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:40 syslog: WLCEVENTD wlceventd_proc_event(430): wl1.1: ReAssoc C4:84:66:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:41 syslog: WLCEVENTD wlceventd_proc_event(420): wl0.1: Auth 000:2D:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:41 syslog: WLCEVENTD wlceventd_proc_event(430): wl0.1: ReAssoc 000:2D:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Sep 6 12:42:46 syslog: WLCEVENTD wlceventd_proc_event(386): wl1.1: Deauth_ind C4:84:66:xx:xx:xx, status: 0, reason: 4-way handshake timeout (f)
Sep 6 12:42:47 roamast: wl1.1: disconnect weak signal strength station [c4:84:66:xx:xx:xx]
Sep 6 12:42:47 roamast: wl1.1: remove client [c4:84:66:xx:xx:xx] from monitor list
Sep 6 12:42:54 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind C4:01:00:xx:xx:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep 6 12:42:54 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind 4C:A1:61:xx:xx:xx, status: 0, reason: Class 3 frame received from nonassociated station (7)
Sep 6 12:42:54 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind 000:2D:xx:xx:xx, status: 0, reason: Class 3 frame received from nonassociated station (7)

So, you wait for that 3 months fix... and consider using AP mode.

OE

 

[Domdus]

Hi,

what is your wireless mode set to for both bands?
In case it's on 'Auto' please try to set it to 'N only' (2.4 ghz) and 'N/AC mixed' (5 ghz). See if that helps.

I think I saw nodes scanning when channels are fixed, but the wireless mode wasn't.

BR

 

[semigator]

Hi,

what is your wireless mode set to for both bands?
In case it's on 'Auto' please try to set it to 'N only' (2.4 ghz) and 'N/AC mixed' (5 ghz). See if that helps.

I think I saw nodes scanning when channels are fixed, but the wireless mode wasn't.

BR

Thanks for the suggestion, however I am already set to N Only and N/AC mixed.

 

[semigator]

Just a quick update: 81351 seems to have resolved the 15 minute wifi disconnects on my two ethernet connected 1900P AiMesh nodes. 81351 on my 86u is stable, and my two thermostats work, but the syslog shows frequent disconnect and reconnects. I'm planning to stay at this level. Has anyone resolved these messages that appear every minute or two?

Nov 27 12:05:44 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind 000:2D:xx:xx:xx, status: 0, reason: Disassociated due to inactivity (4)
Nov 27 12:05:44 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 000:2D:xx:xx:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Nov 27 12:05:51 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind 000:2D:xx:xx:xx, status: 0, reason: Class 3 frame received from nonassociated station (7)
Nov 27 12:05:55 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth 000:2D:xx:xx:xx, status: 0, reason: d11 RC reserved (0)
Nov 27 12:05:55 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc 000:2D:xx:xx:xx, status: 0, reason: d11 RC reserved (0)

 

[semigator]

Just a quick update: 81351 seems to have resolved the 15 minute wifi disconnects on my two ethernet connected 1900P AiMesh nodes. 81351 on my 86u is stable, and my two thermostats work, but the syslog shows frequent disconnect and reconnects. I'm planning to stay at this level.

False Alarm - I had to revert back due to the same issues.