Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[juched]

Was running Merlin 386.1.alpha4, and had an issue where a device networked in behind an AiMesh Node would see massive packet loss. Running ping from that machine to 8.8.8.8 would see 10%-20% loss over a hundred pings. I upgraded the nodes to 9.0.0.4.386_41157 beta from Asus just to see. Same issue would apply. Upgraded my router to non-merlin 41157, factory reset all nodes, clean setup and all was working fine. Started resetting up enough to get me by for a few days and it was running fine. Put the nodes back into their correct places and all was working. Turned on regular wifi (by putting in the proper access point name for my house) and turned on guest network. Tested again and sure enough ... the packet drop is back.

Finally figured out if Guest Slot 1 is enabled with Sync to all nodes, then I see packet loss. if I simply turn it to Router, no packet loss. Here is an example with sync to all nodes enabled, and then again after setting to router only and waiting 20 seconds. The loss is gone.

This example is when logged into the ssh of the router and pinging the device:

admin@router:/tmp/home/root# ping 192.168.2.95
PING 192.168.2.95 (192.168.2.95): 56 data bytes
64 bytes from 192.168.2.95: seq=1 ttl=64 time=1.073 ms
64 bytes from 192.168.2.95: seq=3 ttl=64 time=0.996 ms
64 bytes from 192.168.2.95: seq=5 ttl=64 time=1.013 ms
64 bytes from 192.168.2.95: seq=7 ttl=64 time=0.920 ms
64 bytes from 192.168.2.95: seq=9 ttl=64 time=0.997 ms
64 bytes from 192.168.2.95: seq=11 ttl=64 time=0.960 ms
^C
--- 192.168.2.95 ping statistics ---
12 packets transmitted, 6 packets received, 50% packet loss
round-trip min/avg/max = 0.920/0.993/1.073 ms

admin@router:/tmp/home/root# ping 192.168.2.95
PING 192.168.2.95 (192.168.2.95): 56 data bytes
64 bytes from 192.168.2.95: seq=0 ttl=64 time=0.996 ms
64 bytes from 192.168.2.95: seq=1 ttl=64 time=0.971 ms
64 bytes from 192.168.2.95: seq=2 ttl=64 time=0.994 ms
64 bytes from 192.168.2.95: seq=3 ttl=64 time=0.997 ms
64 bytes from 192.168.2.95: seq=4 ttl=64 time=1.019 ms
64 bytes from 192.168.2.95: seq=5 ttl=64 time=1.020 ms
64 bytes from 192.168.2.95: seq=6 ttl=64 time=0.923 ms
64 bytes from 192.168.2.95: seq=7 ttl=64 time=0.927 ms
^C
--- 192.168.2.95 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 0.923/0.980/1.020 ms

This device is a raspberry pi running home assistant and the packet loss has been creating havoc for controlling devices or even detecting if it can ping 8.8.8.8.


Setup:
RT-AX88U as router, 2xRT-AC68U as nodes. Reproduced on both nodes incase it was hardware related, it isn't.
All running RC9.

Router <--> ethernet cable <--> aimesh node <--> ethernet cable <--> raspberry pi (but also reproduced with another device).

Note: None of this setup was using the Guest Network on Slot 1, just found once it is enabled it creates this packet loss for regular network traffic behind AiMesh Node.

 

[rickygao]

I have concluded Roaming Assistant doesn't work the same way in 386 as it did in 384. No matter what RSSI threshold have set and tested, from -55 to -78, the log messages to roam a client are far and few between. Many of my IoT devices get stuck on the wrong node - even when there is a node with much better signal available in the mesh network. This is very different from my past Asus experience with RA. I had it set in 384 and it moved clients very quickly and logically. The new binding capability in 386 has mostly resolved this IoT challenge for devices that never physically move.

I also have a bunch of Apple devices that have proven they are able to roam on their own better than RA. I have added our Apple devices to the Roaming Block List. I have a number of older Windows laptops that do a bad job of roaming on their own. Those are the ones I am trying to get to be forced the closest node when they move around the house. I have put them on a 5 Ghz SSID so both the bandwidth will be higher and the signal will get weaker sooner to hopefully trigger a move.

It does NOT work here as well. @ASUSWRT_2020

 

[isr25]

Hi @ASUSWRT_2020

Using a new AX86U upgraded manually from AC86U. My ISP provides an IPTV STB connected to LAN4 with VLAN tagging 600 while WAN port is tagged with VLAN 500. I just noticed that after turning on the IPTV STB, the log will be full of the below lines, and the router CPU will get hotter by the minute - usually around 76-78C, but will rise up to 96C (ambient temp around 33C). I noticed the error logs is coming from my wireless Roku - not the IPTV device through ethernet). Not sure why the wired device error will affect the Roku though. The error will continue until I turn off the IPTV STB, then the CPU temp will gradually go down to normal temps.

Dec  4 16:10:20 kernel: wl0: random key value: 5BBF3F1EDE7F2E06772202486405A4216ED8D4B3C2F50C360A2FCB38592D30DD
Dec  4 16:10:20 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind B8:B7:F1:XX:XX:XX, status: 0, reason: Unspecified reason (1)
Dec  4 16:10:20 wlceventd: wlceventd_proc_event(505): eth6: Auth B8:B7:F1:XX:XX:XX, status: Successful (0)
Dec  4 16:10:20 wlceventd: wlceventd_proc_event(534): eth6: Assoc B8:B7:F1:XX:XX:XX, status: Successful (0)
Dec  4 16:10:24 kernel: eth1 (Ext switch port: 0) (Logical Port: 8) (phyId: 8) Link Up at 100 mbps full duplex
Dec  4 16:13:34 kernel: wl0: random key value: 040859FC1D3386B6155A0053C1444E0CF5F5480D00B209E706545CBB873BA6B7
Dec  4 16:13:34 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind C8:3A:6B:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(505): eth6: Auth C8:3A:6B:XX:XX:XX, status: Successful (0)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind C8:3A:6B:XX:XX:XX, status: 0, reason: Unspecified reason (1)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(505): eth6: Auth C8:3A:6B:XX:XX:XX, status: Successful (0)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind C8:3A:6B:XX:XX:XX, status: 0, reason: Unspecified reason (1)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(505): eth6: Auth C8:3A:6B:XX:XX:XX, status: Successful (0)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind C8:3A:6B:XX:XX:XX, status: 0, reason: Unspecified reason (1)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(505): eth6: Auth C8:3A:6B:XX:XX:XX, status: Successful (0)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind C8:3A:6B:XX:XX:XX, status: 0, reason: Unspecified reason (1)
Dec  4 16:13:41 wlceventd: wlceventd_proc_event(505): eth6: Auth C8:3A:6B:XX:XX:XX, status: Successful (0)
Dec  4 16:13:53 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind C8:3A:6B:XX:XX:XX, status: 0, reason: Unspecified reason (1)
Dec  4 16:13:53 wlceventd: wlceventd_proc_event(505): eth6: Auth C8:3A:6B:XX:XX:XX, status: Successful (0)
Dec  4 16:13:53 wlceventd: wlceventd_proc_event(534): eth6: Assoc C8:3A:6B:XX:XX:XX, status: Successful (0)
Dec  4 16:13:57 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind C8:3A:6B:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
...
...
...
...
Dec  4 16:16:06 kernel: CONSOLE: : wlc_apps_ps_enq_resp txq full, frame discarded
Dec  4 16:16:06 kernel: CONSOLE: 186754.905 wl1.0: wlc_apps_ps_enq_resp txq full, frame discarded
Dec  4 16:16:06 kernel: CONSOLE: 186754.905 wl1.0: wlc_apps_ps_enq_resp txq full, frame discarded
Dec  4 16:16:06 kernel: CONSOLE: 186754.905 wl1.0: wlc_apps_ps_enq_resp txq full, frame discarded
Dec  4 16:16:06 kernel: CONSOLE: 186754.905 wl1.0: wlc_apps_ps_enq_resp txq full, frame discarded
Dec  4 16:16:06 kernel: CONSOLE: 186754.905 wl1.0: wlc_apps_ps_enq_resp txq full, frame discarded
Dec  4 16:16:06 kernel: CONSOLE: 186754.905 wl1.0: wlc_apps_ps_enq_resp txq full, frame discarded
Dec  4 16:16:06 kernel: CONSOLE: 186754.905 wl1.0: wlc_apps_ps_enq_resp txq full, frame discarded
Dec  4 16:16:06 kernel: CONSOLE: 186754.905 wl1.0: wlc_apps_ps_enq_resp txq full, frame discarded

Appreciate any guidance/test you need from me to resolve this. Thanks.

update on my report above @ASUSWRT_2020 it seems that the Guest Network 1 is the culprit. Even just enabling the Guest Network 1 without using AiMesh will cause the errors above with the IPTV STB. Turning off Guest Network 1 will resolve the issue above.

 

[tallytr]

Is there a wireless scheduler for the AiMesh 2.0 nodes?
Its something I use for my Access Point (turns off Wi-Fi at night), would not want to miss this with AiMesh....

 

[Neil62]

I wonder if ASUS will do another RC or this current will be the last of them.....

 

[sanke1]

Strange thing I noticed is if you have set Wireless security to WAP3 Personal, and if you go to add a mesh node, it will force change security to WPA2/WPA3 Personal. You cannot have WPA3 only.

Observed on 2 RT-AX88Us. One as node and same firmware.

 

[brummygit]

Hi @ASUSWRT_2020

I have identified an issue with 5Ghz networking on my RT-AX88U. My circumstances are probably unusual so I am not sure if it can be solved.

In my network I have 1 x RT-AX88U main router in the centre, and 2 x RT-AX56U (front & rear) mesh nodes to extend coverage past the edge of the AX88U. The signal from the RT-AX88U is too strong for devices in the overlapping coverage areas and causes poorer performance when the main router and nodes are competing in the same space, therefore want to use only the radios from the RT-AX56Us. I use DFS channels and have wired backhaul for my mesh nodes.

If I turn off the 5Ghz radio on my RT-AX88U it causes the RT-AX56Us to become unstable and keep switching their wireless channels. I suspect only the RT-AX88U is doing the mandatory DFS checks and without it the nodes are struggling.

Is it possible to do one of 2 things?

1. Implement the ability to use different channels on the different devices in the mesh
2. Fix the behaviour of the 5Ghz nodes when the main router has 5Ghz turned off

Thanks

EDIT: After further investigation it seems that my 2.4Ghz nodes have unstable channels unless I enable 2.4Ghz on my main router as well.

 

[Suzib6sw]

Hi Guys and Gals @ Asus,
Great work on 386 rc2-6. It's awesome to be able to extend the guest network to the nodes now.
There's just one thing I'd like to report: my son found out he could circumvent the parental controls by connecting to the guest network. Since then, I mac filtered his devices from connecting to guest, but I'd appreciate if the parental controls could apply also to that as his friends connect to the guest network when visiting or sleeping over. So, not a worry right now as there are no sleepovers currently due to the pandemic, but hopefully in the near future.
Thank you!

It appears to be still the case that Clients connected to the Guest networks 1,2&3 are ignoring the Block AND time parental controls in 9.0.0.4.386_41157 on the RT-AX58u (Router and aimesh node) . @ASUSWRT_2020 , can these restrictions please be applied to the Guest network as well please?

 

[Hawk]

Strange thing I noticed is if you have set Wireless security to WAP3 Personal, and if you go to add a mesh node, it will force change security to WPA2/WPA3 Personal. You cannot have WPA3 only.

Observed on 2 RT-AX88Us. One as node and same firmware.

It is there for backwards compatibility, since not every node support wpa3 though asus could add check which check all node and there capabilities and if all support WPA3, enable it.

 

[prosperot]

Today my AX88 received 3.0.0.4.386.41249 via the regular update channel.
I guess this is a newer version than the RC version that is distributed in this thread?

 

[OzarkEdge]

Today my AX88 received 3.0.0.4.386.41249 via the regular update channel.
I guess this is a newer version than the RC version that is distributed in this thread?

Apparently so. I presume you were running released firmware.

OE

 

[oldguy]

3.0.0.4.386_25790

The XT8

I had an XT8 that did that, it turns out that the router had crashed, in the event that the router rebooted and the XT8 mesh node did not always reconnect to the primary XT8 router.
This happened multiple times, and at times the primary router just hung, which required a hard reboot of both XT8 units
when I added my old GT-AC5300 as a mesh node, the XT8 mesh would connect to GT-AC5300 after briefly flashing blue, indicating that the primary XT8 had crashed.
As noted previously the the primary router did not always reboot, and I have instances when the XT8 mesh node connected to the GT-AC5300 Mesh node did not reconnect to the primary XT8, which was frustrating.

I swapped the Primary and mesh XT8’s and the problem did not go away.

it seemed to me that the number of devices connected to the primary node may have been a factor, as I was not able to find any combination of settings that improved stability.

 

[AceJayce]

Just wondering if we can add a really simple feature on the Asus app and Asus web interface for the xt8. A wan cycle at the top next to reboot. I have problems with my provider and it would be great to cycle the wan to off and wait X secs and then reconnect. Similar to the mikrotik disable and enable on the wan interface. I have to power cycle the devices when it is just this that is required and by looking at alot of posts on here I think alot of the performance problems put on WiFi are actually service related.

 

[Smack Boy]

I just update RT-AX88U router to public release FW 3.0.0.4.386_41249. AiMesh node is ZenWifi AX XT8 a.k.a. RT-AX95Q public release FW 3.0.0.4.386_25790. Ethernet backhaul.

AX88U guest network is set to Sync to AiMesh Node to "All" but the guest network does not broadcast from the nodes. It only broadcasts from the router.

Previously when I ran RC2-6 beta on an XT8 router and XT8 node pair, guest network broadcast from router and node. But client connections were unreliable so I went back to public released FW. I never tried the beta FW on AX88U so I don't know if that would have worked. Has anyone successfully broadcast guest network from XT8 node connected to AX88U router - either RC2 beta or public release?

 

[mbze430]

anyone know if there is away to change the SSID on 5ghz-2 to a different name? I have an AX88U as main and AC5300 as AIMesh Node both on 2.0. Since AX88U only have 1x 2ghz 1x5ghz I can't seem to edit the 5ghz to a different SSID. I have ethernet as the backhaul

 

[mlai]

For AiMesh in AP mode (AiMesh main node in AP, and the other nodes as AiMesh nodes) with a central switch, is it required for the main node to be connected to the switch via LAN1 on the node or can I connect WAN of the main node to the switch? The reason that I am asking is because the XT8 only has 2.5G WAN port and I would like to utilize the faster speed with my multi-gig switches........

And does ethernet backhaul work on the RC9 with smart switches? I am using Netgear MS510TXPP with them......

 

[Stephen Harrington]

For AiMesh in AP mode (AiMesh main node in AP, and the other nodes as AiMesh nodes) with a central switch, is it required for the main node to be connected to the switch via LAN1 on the node or can I connect WAN of the main node to the switch?

@mlai

I can confirm for my all RC2-9 setup using 4 X RT-AC68U's (1 X Parent, 3 X Nodes, all in AP mode and connected for wired backhaul via various edge switches including a TP-Link "Smart Switch"), the main "Parent" device IS connected via the (1 G) WAN port ... so give it a go with your fancy 2.5G I'd say, should work?

 

[TheOldMan]

Does anyone have ipv6 working with 9.0.0.4 RC2-9? I'm getting the following lines...
Dec 9 22:58:15 modprobe: module ip6t_REJECT not found in modules.dep
Dec 9 22:58:15 modprobe: module ip6t_ROUTE not found in modules.dep
Dec 9 22:58:15 modprobe: module ip6t_LOG not found in modules.dep
ipv6-test.com says ipv6 not configured??? I have used ipv6 for 8 years no problems till I'm using this software.

 

[Suzib6sw]

Hi @ASUSWRT_2020

I have identified an issue with 5Ghz networking on my RT-AX88U. My circumstances are probably unusual so I am not sure if it can be solved.

In my network I have 1 x RT-AX88U main router in the centre, and 2 x RT-AX56U (front & rear) mesh nodes to extend coverage past the edge of the AX88U. The signal from the RT-AX88U is too strong for devices in the overlapping coverage areas and causes poorer performance when the main router and nodes are competing in the same space, therefore want to use only the radios from the RT-AX56Us. I use DFS channels and have wired backhaul for my mesh nodes.

If I turn off the 5Ghz radio on my RT-AX88U it causes the RT-AX56Us to become unstable and keep switching their wireless channels. I suspect only the RT-AX88U is doing the mandatory DFS checks and without it the nodes are struggling.

Is it possible to do one of 2 things?

1. Implement the ability to use different channels on the different devices in the mesh
2. Fix the behaviour of the 5Ghz nodes when the main router has 5Ghz turned off

Thanks

What happens when you turn down the Transmit power of the radios in the professional settings tab .. Both the 2.4 and 5GHz can be adjusted there

 

[brummygit]

What happens when you turn down the Transmit power of the radios in the professional settings tab .. Both the 2.4 and 5GHz can be adjusted there

Good idea I will try that, however I'm a little concerned that Smart Connect, and probably the mesh itself, act on the signal strength received from the client device, therefore I might have devices connected to my AX88U which aren't receiving a good signal back.