Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[Vispen74]

Since changing to this beta firmware I notice that the lawn mover has difficulties to connect to WiFi, as if the WiFi coverage has been worse in the garden...? Still good WiFi reception on my phone on the same places though. No other changes has been made except flashing firmware and reset of all routers.
Using:
2 x rt-ac86u
1 x rt-ac66u b1

 

[user77]

Since changing to this beta firmware I notice that the lawn mover has difficulties to connect to WiFi, as if the WiFi coverage has been worse in the garden...? Still good WiFi reception on my phone on the same places though. No other changes has been made except flashing firmware and reset of all routers.

I did a dirty upgrade from RC5 to RC6, and I also noticed the coverage is worst. The connection between nodes display RSSI values as if the nodes were further away now.
I’m using gt-11000 and 92u routers.

 

[thc]

https://sourceforge.net/projects/asuswrt-merlin/files/RT-AC87U/Release/
hi, why no 87 ?

 

[OzarkEdge]

https://sourceforge.net/projects/asuswrt-merlin/files/RT-AC87U/Release/
hi, why no 87 ?

This thread is for beta testing new stock Asuswrt firmware. It may not ever support the 87. And it is not third party Asuswrt-Merlin firmware.

OE

 

[OzarkEdge]

Another issue noticed since switching to Smart Connect and same SSIDs...

Both guest WLANs were changed from OE-24 Guest and OE-50 Guest to the same OE Guest. Many hours later I noticed that the remote node was still broadcasting OE-50 Guest. I then performed a system reboot and that appears to have corrected the remote node 5.0 broadcast to OE Guest.

It would appear that the 5.0 guest WLAN SSID setting did not sync to the remote node after selecting Apply.

OE

I have not enjoyed the same level of connection stability for my 2.4 mobile client while working around the property, now and before I switched to using Smart Connect. TuneIn regularly stops streaming with a connection error when normally it does not. If feels like RC2-6 has a connection management issue.

Here's an abbreviated snip from the General Log:

Oct 18 12:06:15 kernel: D84:3C:0A:7A:A4 not mesh client, can't update it's ip
Oct 18 12:06:15 kernel: pgd = ffffffc011703000
Oct 18 12:06:15 kernel: [f6953510] *pgd=0000000011758003, *pud=0000000011758003, *pmd=00000000153c1003, *pte=0000000000000000
Oct 18 12:06:15 kernel: CPU: 0 PID: 31262 Comm: amas_lib Tainted: P O 4.1.27 #2
Oct 18 12:06:15 kernel: Hardware name: Broadcom-v8A (DT)
Oct 18 12:06:15 kernel: task: ffffffc01e86a080 ti: ffffffc013ef0000 task.ti: ffffffc013ef0000
Oct 18 12:06:15 kernel: PC is at 0xf6998a58
Oct 18 12:06:15 kernel: LR is at 0xf6996728
Oct 18 12:06:15 kernel: pc : [<00000000f6998a58>] lr : [<00000000f6996728>] pstate: 600f0010
Oct 18 12:06:15 kernel: sp : 00000000f69534f8
Oct 18 12:06:15 kernel: x12: 0000000000000000
Oct 18 12:06:15 kernel: x11: 00000000f6955ad4 x10: 0000000000000002
Oct 18 12:06:15 kernel: x9 : 00000000f6d82c92 x8 : 00000000f6a91000
Oct 18 12:06:15 kernel: x7 : 00000000f6955b20 x6 : 00000000f6a91cc0
Oct 18 12:06:15 kernel: x5 : 00000000f6a91cc0 x4 : 00000000f69535c0
Oct 18 12:06:15 kernel: x3 : 00000000000f7db0 x2 : 00000000f6955ae8
Oct 18 12:06:15 kernel: x1 : 00000000f6d82c92 x0 : 00000000fbad8004
<snip>
Oct 18 12:07:08 rc_service: amas_lib 31300:notify_rc restart_firewall
Oct 18 12:58:03 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link DOWN.
Oct 18 12:58:06 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link UP 1000 mbps full duplex
Oct 18 13:15:09 roamast: determine candidate node [D4:5D:64:7B:5F:61](rssi: -52dbm) for client [90:C78:90:85:59](rssi: -68dbm) to roam
Oct 18 13:15:09 roamast: Roam a client [90:C78:90:85:59], status [0]
Oct 18 13:15:10 wlceventd: wlceventd_proc_event(469): eth5: Deauth_ind 90:C78:90:85:59, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct 18 13:15:10 wlceventd: wlceventd_proc_event(486): eth5: Disassoc 90:C78:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 18 13:23:31 wlceventd: wlceventd_proc_event(505): eth5: Auth 90:C78:90:85:59, status: Successful (0)
Oct 18 13:23:31 wlceventd: wlceventd_proc_event(534): eth5: Assoc 90:C78:90:85:59, status: Successful (0)
Oct 18 13:26:48 wlceventd: wlceventd_proc_event(486): eth5: Disassoc 90:C78:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 18 13:26:48 wlceventd: wlceventd_proc_event(505): eth5: Auth 90:C78:90:85:59, status: Successful (0)
Oct 18 13:26:48 wlceventd: wlceventd_proc_event(534): eth5: Assoc 90:C78:90:85:59, status: Successful (0)
Oct 18 13:26:48 kernel: 90:C78:90:85:59 not mesh client, can't update it's ip
Oct 18 13:26:48 kernel: pgd = ffffffc0117a6000
Oct 18 13:26:48 kernel: [f77cf510] *pgd=0000000009e0d003, *pud=0000000009e0d003, *pmd=000000001163b003, *pte=0000000000000000
Oct 18 13:26:48 kernel: CPU: 0 PID: 18021 Comm: amas_lib Tainted: P O 4.1.27 #2
Oct 18 13:26:48 kernel: Hardware name: Broadcom-v8A (DT)
Oct 18 13:26:48 kernel: task: ffffffc017671480 ti: ffffffc010d4c000 task.ti: ffffffc010d4c000
Oct 18 13:26:48 kernel: PC is at 0xf6f2ca58
Oct 18 13:26:48 kernel: LR is at 0xf6f2a728
Oct 18 13:26:48 kernel: pc : [<00000000f6f2ca58>] lr : [<00000000f6f2a728>] pstate: 600f0010
Oct 18 13:26:48 kernel: sp : 00000000f77cf4f8
Oct 18 13:26:48 kernel: x12: 0000000000000000
Oct 18 13:26:48 kernel: x11: 00000000f77d1ad4 x10: 0000000000000002
Oct 18 13:26:48 kernel: x9 : 00000000f7316c92 x8 : 00000000f7025000
Oct 18 13:26:48 kernel: x7 : 00000000f77d1b20 x6 : 00000000f7025cc0
Oct 18 13:26:48 kernel: x5 : 00000000f7025cc0 x4 : 00000000f77cf5c0
Oct 18 13:26:48 kernel: x3 : 00000000000f7db0 x2 : 00000000f77d1ae8
Oct 18 13:26:48 kernel: x1 : 00000000f7316c92 x0 : 00000000fbad8004
<snip>
Oct 18 13:54:01 rc_service: amas_lib 18035:notify_rc restart_firewall

I've made bold some suspicious entries... the first D84:3C:0A:7A:A4 is a SONY AVR wired to the root node... the second 90:C78:90:85:59 is my 2.4 mobile client. There is only one weak 2.4 ch9 20MHz WiFi signal overlapping my ch11 signals.

OE

 

[Thermaltake]

anyone know when is stable 386 plan to be released ?

 

[OzarkEdge]

anyone know when is stable 386 plan to be released ?

No.

OE

 

[JWoo]

anyone know when is stable 386 plan to be released ?

Good question. Most of the newer routers including ZenWiFi XT8, ZenWiFi XD4, RT-AX86U, RT-AX82U, RT-AX58U, TUF-AX3000, RT-AX56U are not yet supported due to the unstable SDK issue presumably caused by unstable drivers from Broadcom. @ASUSWRT_2020 please take these questions as a show of interest from enthusiasts & testers. Getting out my "I love firmware" t-shirt which my wife hates.

 

[BeeJayVee]

Last Saturday I upgraded my AiMesh network from the latest released ASUS firmware to RC2-6. I have a GT-AC5300 as my main router plus additional GT-AC5300, RT-AC5300, and RT-AC86U nodes, totaling nine routers. The three-band routers are connected wirelessly using dedicated wireless backhaul, and the RT-AC86U nodes are each connected to one of the three-band routers via Cat 6E Ethernet cable for backhaul. Effectively, the three-band routers comprise the “backbone” of the network, and the RT-AC86U nodes provide additional coverage. I have found that manually setting channels results in a much more stable network; otherwise, almost all of the other settings are default.

Here is the problem I am seeing: The three-channel routers are set to use their 5G-1 radios on channel 36 for fronthaul and their 5G-2 radios on channel 149 as backhaul, whereas all three RT-AC86U nodes are using channel 149 for fronthaul (set automatically, presumably by the main router). So, the backhaul channel for the three-band routers is the fronthaul channel for the RT-AC86U routers. I was expecting that the AiMesh system would set all nodes to use the same channel for fronthaul, especially since all of the RT-AC86U nodes are connected to the AiMesh system by Ethernet cabling for backhaul.

This was also a problem with the released ASUS firmware. Before performing the firmware upgrade, I tried to explain this issue to an ASUS technician via the chat feature on the ASUS website, but the person I was chatting with “didn’t quite get it.” I was hoping that this was fixed in AiMesh 2.0, but it is not (yet?).

I was wondering if any others out there are using a mixture of two-band and multiple three-band routers in AiMesh (so that dedicated wireless backhaul is employed) and having the same problem. I have not been running the test firmware long enough to otherwise judge its stability, but so far it seems okay.

@ASUSWRT_2020, I would like to see a feature where all two-band nodes use the same fronthaul channel as the three-band nodes, at least when the two-band nodes are using Ethernet backhaul.

 

[OzarkEdge]

Last Saturday I upgraded my AiMesh network from the latest released ASUS firmware to RC2-6. I have a GT-AC5300 as my main router plus additional GT-AC5300, RT-AC5300, and RT-86U nodes, totaling nine routers. The three-band routers are connected wirelessly using dedicated wireless backhaul, and the RT-86U nodes are each connected to one of the three-band routers via Cat 6E Ethernet cable for backhaul. Effectively, the three-band routers comprise the “backbone” of the network, and the RT-86U nodes provide additional coverage. I have found that manually setting channels results in a much more stable network; otherwise, almost all of the other settings are default.

Here is the problem I am seeing: The three-channel routers are set to use their 5G-1 radios on channel 36 for fronthaul and their 5G-2 radios on channel 149 as backhaul, whereas all three RT-86U nodes are using channel 149 for fronthaul (set automatically, presumably by the main router). So, the backhaul channel for the three-band routers is the fronthaul channel for the RT-86U routers. I was expecting that the AiMesh system would set all nodes to use the same channel for fronthaul, especially since all of the RT-86U nodes are connected to the AiMesh system by Ethernet cabling for backhaul.

This was also a problem with the released ASUS firmware. Before performing the firmware upgrade, I tried to explain this issue to an ASUS technician via the chat feature on the ASUS website, but the person I was chatting with “didn’t quite get it.” I was hoping that this was fixed in AiMesh 2.0, but it is not (yet?).

I was wondering if any others out there are using a mixture of two-band and multiple three-band routers in AiMesh (so that dedicated wireless backhaul is employed) and having the same problem. I have not been running the test firmware long enough to otherwise judge its stability, but so far it seems okay.

@ASUSWRT_2020, I would like to see a feature where all two-band nodes use the same fronthaul channel as the three-band nodes, at least when the two-band nodes are using Ethernet backhaul.

Presumably the remote nodes use the same channel 149 that the root node dictates for wireless backhauls so that they can failover to wireless backhaul.

Perhaps a remote node management setting for 'Ethernet backhaul only' could allow the remote node fronthaul to be the same as the root node fronthaul... or even allow setting each remote node fronthaul to a different channel to keep the purists happily busy.

OE

 

[drabisan]

Presumably the remote nodes use the same channel 149 that the root node dictates for wireless backhauls so that they can failover to wireless backhaul.

Perhaps a remote node management setting for 'Ethernet backhaul only' could allow the remote node fronthaul to be the same as the root node fronthaul... or even allow setting each remote node fronthaul to a different channel to keep the purists happily busy.

OE

Nope, it doesn't.
I'm using "Ethernet backhaul only", I don't want any failover over wifi and it will be heavily counter-productive for me as routers can see eachother only over 2.4. And still, the 2 radio node uses the same 5GHz channel as second 5GHz or router, not the same one 1st 5GHz radio uses.
And that's a higher power channel and potentially more CCI if they see eachother.
It was the same on AiMesh1 even though back then second 5GHz radio could not be part of Smart Connect (it was crazy, one SSID on that channel from router and another SSID from the node). I did reset both units at one time while using this beta so it's a decision, not something inherited from official firmware.

 

[OzarkEdge]

Nope, it doesn't.
I'm using "Ethernet backhaul only", I don't want any failover over wifi and it will be heavily counter-productive for me as routers can see eachother only over 2.4. And still, the 2 radio node uses the same 5GHz channel as second 5GHz or router, not the same one 1st 5GHz radio uses.

Yes, this was so reported above. I was seconding the suggestion to make it operate as was suggested, if feasible.

OE

 

[Jayce Ooi]

Just installed rc2-6 on both AX88U and AC86U. Working great so far.

 

[Maverick009]

Ok so trying out RC2-6 for a 2nd go around with the Asus GT-AX11000 and RT-AC3100 routers. This time I did more fine controlling and did a clean firmware install. Everything seems to be much better this time. I have the 5Ghz channels locked at 80Mhz channels right now, as I was noticing some stuttering on TV playback with the once HDHomeRun Prime 3 device I have. Not all devices support 160Mhz channels or AX wireless and the ASUS RT-3100 is also not an AC Wave 2 router, so could not go all out in full potential bandwidth/ Even at 80Mhz Channel for the 2nd 5ghz channel that is the dedicated backhaul, I get Transmit Rate 585Mbps and Receive Rate 702Mbps maxing out around 877.5Mbps. I also have 2 Apple TV 4 Gen devices on the backhaul 5Ghz Channel too, as I was keeping mainly the Streaming devices together, with only exception right now being the Nvidia Shield 2019 connected the main 5Ghz channel with the rest of the devices, due to its latest update giving a few minor issues and I was troubleshooting stuttering with Channels App, from the HDHomeRun.

So far everything is working nicely this go around with a few minor hiccups, such as the AiMesh Node (RT-AC3100) connects to the AX11000 on the 2.4Ghz channel after maybe a reboot or major configuration and eventually finds its way back the dedicated 5Ghz backhaul. I have also moved DHCP duties to my Ubuntu VOIP Server, as of tonight, and everything is ticking along nicely. My Main gaming computer, is running on the 2.5Gbps jack at the moment too, and I have Link Aggregation turned on for both the WAN/LAN4 for my Netgear MultiGig Modem, allowing be to even go slightly beyond the 1Gbps internet speed I get with Comcast, hitting around 1.175Gbps (I have noticed slight issues here and there with WAN Link Aggregation, where once I reboot the router, I get full speed again. Very rare, but looks like a minor bug), and Link Aggregation/Bonding of LAN Port 1 and 2 going to my 24 Port TD-Link T1600G-28TS Switch.

Everything so far seems to be working and AiMesh 2.0 may be the real gem this go around, as it gives more fine control over the nodes, and allows you to see connections speeds and more. The other parts of the routers, seems to be more bug fixes and consistency updates. There may be other updates to the RC that I am missing, that may help with speed/stability/performance, but this update is shaping to be real nice. I do recommend a clean wipe/use Recue Mode to update firmware and make sure nothing carries over from previous firmware that may cause issues.

 

[Neil62]

@ASUSWRT_2020

Here is another problem, I have this client blocked but internet access is not blocked:

I might also add in this case, its part of the new IOS 14, privacy function, issuing a fake mac addresses, if that helps at all. Should Not make anything difference at all though, as according to MAC address and IP address this client should be blocked from internet access. But it is not.

Pi Hole showing this client is still able to access the internet:

Can anyone please check and confirm this functionality is working? Blocked internet access by client.

I did check with the device and yes internet functionality was still available. The device should be blocked 100% how are queries still going out to the internet, they should be blocked at the router level, not even being forwarded to Pi Hole which is setup as the DNS server.

 

[OzarkEdge]

@ASUSWRT_2020

Here is another problem, I have this client blocked but internet access is not blocked:

View attachment 27017

I might also add in this case, its part of the new IOS 14, privacy function, issuing a fake mac addresses, if that helps at all. Should Not make anything difference at all though, as according to MAC address and IP address this client should be blocked from internet access. But it is not.

Pi Hole showing this client is still able to access the internet:

View attachment 27018

Can anyone please check and confirm this functionality is working? Blocked internet access by client.

I did check with the device and yes internet functionality was still available. The device should be blocked 100% how are queries still going out to the internet, they should be blocked at the router level, not even being forwarded to Pi Hole which is setup as the DNS server.

Using the AiMesh section, I blocked a wired Roku in use and nothing happened for many minutes. So then I performed a system reboot and the Roku lost Internet access and would not connect. I unblocked the Roku and it immediately connected to a streaming service... no reboot required.

Appeared to work if you reboot.

OE

 

[NSNE]

Just an update to my own RC2-β6 experience: I now have—knock on wood—4+ days of uptime with the following config: GT-AC5300 (main), RT-AC68U (wired node), Blue Cave (wireless node). I've got 60+ devices on my local network and all four family members putting it to the test with heavy daily work/school/recreation usage. Download speeds are consistently 920+ down, 40 up on my 1Gbps connection with Xfinity.

The GT-AC5300 has many of its features enabled, including custom DNS, dynamic DNS, port forwarding, MAC/IP binding, Traffic Analyzer, parental controls and VPN Fusion on select devices. Wireless settings are all at defaults.

Three minor issues that I've noticed are:

1. Some Wi-Fi finickiness with a KEiID W02 (kind of like a Sonos). But that was showing some finickiness with a previous router. Might be an issue with the unit itself.
2. Devices aggregating on a node that's more physically distant than another (i.e., connecting to the 68U rather than the Blue Cave, even though the Blue Cave is only a few feet away). But that could be because the Blue Cave isn't running RC-6 and/or the devices are being steered to the more robust wired node.
3. GUI glitches that have already been reported in this thread.

On the whole, I'm finding RC2-β6 to be release-worthy.

 

[mmacedo]

@ASUSWRT_2020

Here is another problem, I have this client blocked but internet access is not blocked:

View attachment 27017

I might also add in this case, its part of the new IOS 14, privacy function, issuing a fake mac addresses, if that helps at all. Should Not make anything difference at all though, as according to MAC address and IP address this client should be blocked from internet access. But it is not.

Pi Hole showing this client is still able to access the internet:

View attachment 27018

Can anyone please check and confirm this functionality is working? Blocked internet access by client.

I did check with the device and yes internet functionality was still available. The device should be blocked 100% how are queries still going out to the internet, they should be blocked at the router level, not even being forwarded to Pi Hole which is setup as the DNS server.

It works for me, except when a device connects to the guest network, as I had reported before.

 

[mbze430]

Just out of curiosity, does AIMesh 2.0 passthrough "guest wifi network" information to other nodes?

I believe currently, if you have a "guest wifi network" say on 5GHz-1 with primary SSID is "SSID-1" and "guest wifi network" SSID "Guest-1" and others (Guest-2, and so on) it doesn't pass that "Guest-1" SSID to the AIMesh nodes

I was told early this year that AIMesh 2.0 would now push "guest wifi network" to all AIMesh nodes.

 

[drabisan]

Yes. You can have guest only on router or on both router and all nodes.