Release Asuswrt-Merlin 388.1 is now available for all supported Wifi 6 models

[BliteKnight]

TLDR; I have gone back to 386.7_2 to keep my network stable.

This has been my experience so far...I rarely have any issues with merlin's firmware updates, but this time was different.
I have three Asus routers in AiMesh mode: RT-AX68U (388.1) + 2 nodes (RT-AC68P upgraded to 386.10 from 386.9) - 1 node is 1gig connected to the main, the other is connected on the 5GHz to the main.

When I initially went from 386.7_2 to 388.1 the upgrade went well and everything seemed fine - this was in January...Then several times a week while working from home my internet would disconnect on my 1Gig connection from my main PC to my switch that the main router is connected to. The interupption would last several seconds to a full minute, but it would always come back...so I just chucked it up to my ISP having issues. This went on for weeks but I just lived with it. The my wife started saying she was loosing Wi-Fi connections on his iPhone and I just thought it was an iPhone issue cause my Android phone worked fine.

I decided to switch ISPs to try T-Mobile's at home internet (TM5G) which came with its own gateway and wifi - so I unplugged my previous ISP (cable modem) from the RT-AX68U WAN port and plugged in the TM5G....then the following events happened that led me to me conclusion:

1. WyzeCamera and TV keeps loosing connection from one specific room, so I bound them to the closest node to see if it would help...it did not
2. The node they were bound to would drop connection also (it had 1Gig ethernet backhaul connection - so this was strange. I thought it could be the firmware, so I downgraded to 386.9, then 386.7_2 but it kept happening
3. Changed Wifi channel in case it was interuption from the TMobile gateway...still kept dropping and losing connection
4. Removed all nodes, hard reset the RT-AX68U, switched back to previous ISP so no wifi interruption and I still kept dropping wifi connections
5. I looked at the logs but could not see anything that stood out to me except the re-authentication that would happen when the wifi would drop

So I hard reset the RT-AX68U back to 386.7_2 and kept the nodes on 386.10 and now my connections are back to being stable with no drops on any of my devices or nodes.

Here is an example log from the RT-AX68U when the disconnects would happen...not sure if it helps

Mar 24 06:16:43 kernel: wl0: random key value: 7C32423C9E6F4AB34AAE0352EFB6BC0521B43C0AA64705CCCFD77D3D7E324549
Mar 24 06:16:43 wlceventd: wlceventd_proc_event(508): eth5: Disassoc CC:F7:35:8B:97:0C, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 24 06:16:43 wlceventd: wlceventd_proc_event(508): eth5: Disassoc CC:F7:35:8B:97:0C, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 24 06:16:43 hostapd: eth5: STA cc:f7:35:8b:97:0c IEEE 802.11: disassociated
Mar 24 06:16:43 hostapd: eth5: STA cc:f7:35:8b:97:0c IEEE 802.11: disassociated
Mar 24 06:16:43 wlceventd: wlceventd_proc_event(527): eth5: Auth DA:81:82:90:0D:C9, status: Successful (0), rssi:0
Mar 24 06:16:44 hostapd: eth5: STA da:81:82:90:0d:c9 IEEE 802.11: associated
Mar 24 06:16:44 wlceventd: wlceventd_proc_event(537): eth5: ReAssoc DA:81:82:90:0D:C9, status: Successful (0), rssi:-76
Mar 24 06:16:44 hostapd: eth5: STA da:81:82:90:0d:c9 RADIUS: starting accounting session 2FBA660DB3B6F286
Mar 24 06:16:44 hostapd: eth5: STA da:81:82:90:0d:c9 WPA: pairwise key handshake completed (RSN)
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(527): eth5: Auth CC:F7:35:8B:97:0C, status: Successful (0), rssi:0
Mar 24 06:16:45 hostapd: eth5: STA cc:f7:35:8b:97:0c IEEE 802.11: associated
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(556): eth5: Assoc CC:F7:35:8B:97:0C, status: Successful (0), rssi:-61
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(527): eth5: Auth 3E:C7:E5:53:BA:0C, status: Successful (0), rssi:0
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(537): eth5: ReAssoc 3E:C7:E5:53:BA:0C, status: Successful (0), rssi:-82
Mar 24 06:16:45 hostapd: eth5: STA 3e:c7:e5:53:ba:0c IEEE 802.11: associated
Mar 24 06:16:45 hostapd: eth5: STA cc:f7:35:8b:97:0c RADIUS: starting accounting session 91CAF682187FA788
Mar 24 06:16:45 hostapd: eth5: STA cc:f7:35:8b:97:0c WPA: pairwise key handshake completed (RSN)
Mar 24 06:16:45 hostapd: eth5: STA 3e:c7:e5:53:ba:0c RADIUS: starting accounting session 7CB994F38E7AC3F9
Mar 24 06:16:45 hostapd: eth5: STA 3e:c7:e5:53:ba:0c WPA: pairwise key handshake completed (RSN)
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(527): eth6: Auth 24:4C:E3:8A:92:16, status: Successful (0), rssi:-65
Mar 24 06:16:45 hostapd: eth6: STA 24:4c:e3:8a:92:16 IEEE 802.11: associated
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(556): eth6: Assoc 24:4C:E3:8A:92:16, status: Successful (0), rssi:0
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 24:4C:E3:8A:92:16, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 24:4C:E3:8A:92:16, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 24 06:16:45 hostapd: eth6: STA 24:4c:e3:8a:92:16 IEEE 802.11: disassociated
Mar 24 06:16:45 hostapd: eth6: STA 24:4c:e3:8a:92:16 IEEE 802.11: disassociated
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(527): eth6: Auth 24:4C:E3:8A:92:16, status: Successful (0), rssi:0
Mar 24 06:16:45 hostapd: eth6: STA 24:4c:e3:8a:92:16 IEEE 802.11: associated
Mar 24 06:16:45 wlceventd: wlceventd_proc_event(556): eth6: Assoc 24:4C:E3:8A:92:16, status: Successful (0), rssi:-66
Mar 24 06:16:45 hostapd: eth6: STA 24:4c:e3:8a:92:16 RADIUS: starting accounting session 9D2C4D820C3821D9
Mar 24 06:16:45 hostapd: eth6: STA 24:4c:e3:8a:92:16 WPA: pairwise key handshake completed (RSN)
Mar 24 06:16:46 dnsmasq-dhcp[10484]: DHCPREQUEST(br0) 192.168.0.225 24:4c:e3:8a:92:16
Mar 24 06:16:46 dnsmasq-dhcp[10484]: DHCPACK(br0) 192.168.0.225 24:4c:e3:8a:92:16 amazon-f0f72bcd3
Mar 24 06:16:46 dnsmasq-dhcp[10484]: DHCPREQUEST(br0) 192.168.0.19 cc:f7:35:8b:97:0c
Mar 24 06:16:46 dnsmasq-dhcp[10484]: DHCPACK(br0) 192.168.0.19 cc:f7:35:8b:97:0c amazon-43ac62a17
Mar 24 06:16:49 dnsmasq-dhcp[10484]: DHCPREQUEST(br0) 192.168.0.19 cc:f7:35:8b:97:0c
Mar 24 06:16:49 dnsmasq-dhcp[10484]: DHCPACK(br0) 192.168.0.19 cc:f7:35:8b:97:0c amazon-43ac62a17
Mar 24 06:16:49 dnsmasq-dhcp[10484]: DHCPREQUEST(br0) 192.168.0.225 24:4c:e3:8a:92:16
Mar 24 06:16:49 dnsmasq-dhcp[10484]: DHCPACK(br0) 192.168.0.225 24:4c:e3:8a:92:16 amazon-f0f72bcd3
Mar 24 06:16:51 dnsmasq-dhcp[10484]: DHCPDISCOVER(br0) cc:f7:35:8b:97:0c
Mar 24 06:16:51 dnsmasq-dhcp[10484]: DHCPOFFER(br0) 192.168.0.19 cc:f7:35:8b:97:0c
Mar 24 06:16:53 wlceventd: wlceventd_proc_event(527): eth5: Auth D0:3F:27:1C:2D:C9, status: Successful (0), rssi:0
Mar 24 06:16:54 wlceventd: wlceventd_proc_event(556): eth5: Assoc D0:3F:27:1C:2D:C9, status: Successful (0), rssi:-54
Mar 24 06:16:54 hostapd: eth5: STA d0:3f:27:1c:2d:c9 IEEE 802.11: associated
Mar 24 06:16:54 hostapd: eth5: STA d0:3f:27:1c:2d:c9 RADIUS: starting accounting session 7BA142B41E8F65E1
Mar 24 06:16:54 hostapd: eth5: STA d0:3f:27:1c:2d:c9 WPA: pairwise key handshake completed (RSN)
Mar 24 06:16:54 dnsmasq-dhcp[10484]: DHCPDISCOVER(br0) cc:f7:35:8b:97:0c
Mar 24 06:16:54 dnsmasq-dhcp[10484]: DHCPOFFER(br0) 192.168.0.19 cc:f7:35:8b:97:0c
Mar 24 06:16:54 dnsmasq-dhcp[10484]: DHCPDISCOVER(br0) d0:3f:27:1c:2d:c9
Mar 24 06:16:54 dnsmasq-dhcp[10484]: DHCPOFFER(br0) 192.168.0.193 d0:3f:27:1c:2d:c9
Mar 24 06:16:54 dnsmasq-dhcp[10484]: DHCPREQUEST(br0) 192.168.0.193 d0:3f:27:1c:2d:c9
Mar 24 06:16:54 dnsmasq-dhcp[10484]: DHCPACK(br0) 192.168.0.193 d0:3f:27:1c:2d:c9 WYZE_CAKP2JFUS-D03F271C2DC9

 

[Shonk]

Are LEDs disabled? If so, that disables Aurora RGB control as well.

Yes
Yes they are

 

[visortgw]

Yes
Yes they are

1. Enable LEDs.
2. Set Aurora RGB as desired.
3. Use lc within amtm to disable LEDs.

 

[Shonk]

1. Enable LEDs.
2. Set Aurora RGB as desired.
3. Use lc within amtm to disable LEDs.

I did this and Aurora RGB is still on

1. Enable LEDs.
2. Set Aurora RGB Enabled
3. Disable LEDs.

Aurora RGB is locked to off but its still on

 

[BliteKnight]

Final follow up - all is good with this firmware, it was my own fault.

Switched to T-Mobile internet from Cox and updated my Asus routers firmware at the same time. (1 Main, 2 nodes)
However, I found out that T-Mobile blocked all ports on my network, causing DNS entries to my home server to be blocked on my new public IP.

So I hosted a VPN on an external server to tunnel into their home network - it partially worked and I went one with life.

Then I started getting the random disconnects.

I tried various solutions, including downgrading firmware, changing ISP back to Cox, and using different mesh nodes - but I still got the disconnects

I seriously thought someone in the neighborhood had a Wi-Fi killer and was messing with me...then I discovered that one of their VPN connections was causing the network disconnects.

I had tried to create a bridge on this server to the external VPN but this caused it to get the IP address of the router when it tried to do this and caused the disconnects.

It would periodically do this so I always thought it was a Wi-Fi issue.

Just posting this in case someone every experiences the same thing and might have a VPN connection setup, it could be wrecking your network.