Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[bluegrass]

Patience... and see: https://www.snbforums.com/threads/a...h-full-functions-aimesh-2-0.65235/post-630433

RC2-8 Has so far resolved my initial issues. Ai-Mesh Ethernet backhaul and uplink both are reporting correctly over my unmanaged switch. Everything seems much more stable, the flash of the RT-AX86U (node) was without incident. All devices were hard reset followed by a factory reset then configured from scratch after firmware installation.
RT-AX88U (Router) Wired speed is 925Mbps down, 935Mbps up, Wireless speeds to an RT-AX82U configured as a media bridge are 777Mbps Down, 792Mbps up, with 1ms extra latency difference from wired results .
I have not tested the inclusion of the guest networks over the Ai-Mesh yet, but will get to it over the next week. Overall very good results!

 

[Stephen Harrington]

That is the intended behavior for AP mode. Use AiMesh mode for more functionality.

@L&LD if that reply was intended for me, thanks, but I feel the need to clarify.
The units are indeed in an AiMesh, and that all works fine, but the main "Parent" unit is in "Access Point(AP) mode / AiMesh Router in AP mode" Operation Mode, rather than having the Parent unit as "Wireless router mode / AiMesh Router mode (Default)" Operation Mode as I guess most people would?

 

[L&LD]

I would guess then that you're not in AiMesh mode (sorry, this new terminology is hard)?

Unless the router it is connecting to another AiMesh router in Router mode.

From the router:

AiMesh Routers in AP mode connect to a wireless router through an Ethernet cable to extend the wireless signal to other network clients. In this mode, the firewall, IP sharing, and NAT functions are disabled by default.
You can add AiMesh nodes to form an AiMesh WiFi system to provide extra WiFi coverage.

 

[Stephen Harrington]

I would guess then that you're not in AiMesh mode (sorry, this new terminology is hard)?

@L&LD

Nope, definitely am in AiMesh Mode.
It's possible for the Parent AiMesh to be "just" an AP (as in non-Routing the 2nd option in Administration | Operation Mode list)
My main Router is actually an RT-AC86U sitting in a cupboard with Wifi turned off and no antennas attached .
I've been running like this since very early beta days of AiMesh 1.0 ... screenshots are of the main "Parent" AiMesh controller.

 

[L&LD]

Thanks @Stephen Harrington, this is an interesting twist for me (and for some of my customers).

 

[Stephen Harrington]

this is an interesting twist for me (and for some of my customers).

@L&LD

Circumstances led me to give it a go. I wanted to upgrade my actual main router to the 86U a couple of years ago (so it had a bit more grunt for a faster connection and to play with all those interesting AMTM scripts) and where it needs to live is a non-optimal spot for Wifi. Also my house construction means good coverage needs multiple AP's and I wound up through various means with a bunch of 68U's which cost me almost nothing and are perfectly adequate for the job until I need AX and 6E at some point ... I have everything hard-wired that can be anyway ... and it all works a treat. A truly isolated Guest Network distributed properly across the AiMesh even in AP Mode would just be extra icing on the cake, a "nice to have" security option if needed.

 

[Ole Vik]

I'm currently on RC2-7, and for me it has been very solid. No random reboots at all, which was my biggest aggravation with the stock fw on my three XT8's. Now, I every so often experience some slowdowns. It feels as if datatransfer suddenly halts for some time and starts up again. I started looking at the systemlogs (again), and see this recurring:

Nov 14 07:18:47 kernel: CPU: 1 PID: 4378 Comm: dcd Tainted: P O 4.1.52 #2
Nov 14 07:18:47 kernel: Hardware name: Generic DT based system
Nov 14 07:18:47 kernel: [<c0026e60>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
Nov 14 07:18:47 kernel: [<c0022c38>] (show_stack) from [<c04b9f5c>] (dump_stack+0x8c/0xa0)
Nov 14 07:18:47 kernel: [<c04b9f5c>] (dump_stack) from [<c003aaec>] (get_signal+0x490/0x558)
Nov 14 07:18:47 kernel: [<c003aaec>] (get_signal) from [<c00221d0>] (do_signal+0xc8/0x3ac)
Nov 14 07:18:47 kernel: [<c00221d0>] (do_signal) from [<c0022658>] (do_work_pending+0x94/0xa4)
Nov 14 07:18:47 kernel: [<c0022658>] (do_work_pending) from [<c001f4cc>] (work_pending+0xc/0x20)
Nov 14 07:26:44 kernel: CPU: 1 PID: 11763 Comm: dcd Tainted: P O 4.1.52 #2
Nov 14 07:26:44 kernel: Hardware name: Generic DT based system
Nov 14 07:26:44 kernel: task: d5516400 ti: ce1c8000 task.ti: ce1c8000
Nov 14 07:26:44 kernel: PC is at 0xb6c7e39c
Nov 14 07:26:44 kernel: LR is at 0x1dd14
Nov 14 07:26:44 kernel: pc : [<b6c7e39c>] lr : [<0001dd14>] psr: 600f0010
Nov 14 07:26:44 kernel: sp : bee7d9e8 ip : 000a2050 fp : b5fff024
Nov 14 07:26:44 kernel: r10: 000a23c4 r9 : b5fffca8 r8 : 000a287c
Nov 14 07:26:44 kernel: r7 : b5fffce0 r6 : 000a2876 r5 : 00000000 r4 : b5fffc8c
Nov 14 07:26:44 kernel: r3 : 00000000 r2 : 00000000 r1 : 0007d612 r0 : 00000000

This was the kind of logs that was present during the time of random reboots. I have this sneaking suspicion that they (Asus) have somehow patched the FW to not trigger a reboot when this occurs, rather than fix the underlying problem. Maybe i'm paranoid - or just have three faulty XT8's

 

[Ole Vik]

I'm currently on RC2-7, and for me it has been very solid. No random reboots at all, which was my biggest aggravation with the stock fw on my three XT8's. Now, I every so often experience some slowdowns. It feels as if datatransfer suddenly halts for some time and starts up again. I started looking at the systemlogs (again), and see this recurring:

Nov 14 07:18:47 kernel: CPU: 1 PID: 4378 Comm: dcd Tainted: P O 4.1.52 #2
Nov 14 07:18:47 kernel: Hardware name: Generic DT based system
Nov 14 07:18:47 kernel: [<c0026e60>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
Nov 14 07:18:47 kernel: [<c0022c38>] (show_stack) from [<c04b9f5c>] (dump_stack+0x8c/0xa0)
Nov 14 07:18:47 kernel: [<c04b9f5c>] (dump_stack) from [<c003aaec>] (get_signal+0x490/0x558)
Nov 14 07:18:47 kernel: [<c003aaec>] (get_signal) from [<c00221d0>] (do_signal+0xc8/0x3ac)
Nov 14 07:18:47 kernel: [<c00221d0>] (do_signal) from [<c0022658>] (do_work_pending+0x94/0xa4)
Nov 14 07:18:47 kernel: [<c0022658>] (do_work_pending) from [<c001f4cc>] (work_pending+0xc/0x20)
Nov 14 07:26:44 kernel: CPU: 1 PID: 11763 Comm: dcd Tainted: P O 4.1.52 #2
Nov 14 07:26:44 kernel: Hardware name: Generic DT based system
Nov 14 07:26:44 kernel: task: d5516400 ti: ce1c8000 task.ti: ce1c8000
Nov 14 07:26:44 kernel: PC is at 0xb6c7e39c
Nov 14 07:26:44 kernel: LR is at 0x1dd14
Nov 14 07:26:44 kernel: pc : [<b6c7e39c>] lr : [<0001dd14>] psr: 600f0010
Nov 14 07:26:44 kernel: sp : bee7d9e8 ip : 000a2050 fp : b5fff024
Nov 14 07:26:44 kernel: r10: 000a23c4 r9 : b5fffca8 r8 : 000a287c
Nov 14 07:26:44 kernel: r7 : b5fffce0 r6 : 000a2876 r5 : 00000000 r4 : b5fffc8c
Nov 14 07:26:44 kernel: r3 : 00000000 r2 : 00000000 r1 : 0007d612 r0 : 00000000

This was the kind of logs that was present during the time of random reboots. I have this sneaking suspicion that they (Asus) have somehow patched the FW to not trigger a reboot when this occurs, rather than fix the underlying problem. Maybe i'm paranoid - or just have three faulty XT8's

UPDATE: Seems to be related to AiProtection and Trend Micro. Nice. This has been a reported bug since early 2019. Promising :-(

 

[vdbseb1983]

@ASUSWRT_2020 Firmware for AC86U missing on your google drive, normal?

 

[Mattias]

AC86U

Have you checked asus official page?
It's already as a official version.

Version 3.0.0.4.386.40451
2020/10/22 60.01 MBytes
ASUS RT-AC86U Firmware version 3.0.0.4.386.40451
New features

1. AiMesh 2.0
- System optimization: one click in AiMesh to optimize the topology
- System Ethernet backhaul mode, all nodes will only connect by ethernet, all bands will be released for wireless clients.
- System factory default and reboot.
- Client device reconnect, make the device to offline and online again.
- Client device binding to specific AP.
- Guest WiFi on all Mesh nodes (all node need to upgrade to 3.0.0.4.386 firmware)
- Access nodes USB application.

Same is for rt-ac68u

 

[vdbseb1983]

Have you checked asus official page?
It's already as a official version.


Same is for rt-ac68u

Thanks, and also for AX92U, went to public .386 branch!

 

[Sebastien Bougie]

Hello @ASUSWRT_2020

I'm having the same problem ith RC8 that i had with RC7 after about 20 minutes i'm getting

Nov 14 07:08:56 dnsmasq[430]: Maximum number of concurrent DNS queries reached (max: 150)

Then no more internet I have to turn off my AC31000 then turn it back on. So I went back to the 385 version since i dont have the problem with this version

Can someone tell me if they have this problem? I have about 70 devices on my network with a mesh node (Another AC3100), alot of them are on the guest network.

Please let me know if you have any option that I can try

I forgot to mention I get this problem when the node is turn off, but not when i turn off the Guest network

 

[OzarkEdge]

Hello @ASUSWRT_2020

I'm having the same problem ith RC8 that i had with RC7 after about 20 minutes i'm getting

Nov 14 07:08:56 dnsmasq[430]: Maximum number of concurrent DNS queries reached (max: 150)

Then no more internet I have to turn off my AC31000 then turn it back on. So I went back to the 385 version since i dont have the problem with this version

Can someone tell me if they have this problem? I have about 70 devices on my network with a mesh node (Another AC3100), alot of them are on the guest network.

Please let me know if you have any option that I can try

I forgot to mention I get this problem when the node is turn off, but not when i turn off the Guest network

Sounds like one/many IoT clients on the new guest WLAN1 could be causing the issue.

OE

 

[ginny]

Have you checked asus official page?
It's already as a official version.


Same is for rt-ac68u

Hi Mattias
The official Firmware has been released on Oct 22nd for some Routers. It's based on something between RC2-6 and RC2-7. See also the Thread Asus AC86U New Firmware - 3.0.0.4.386_40451-g30f1b6c
All Routers applied with the official Firmware still follow the Beta path, as e.g. RT-AX92U.
You make a step back taking the official FW instead the latest Beta.

 

[drabisan]

Sounds like one/many IoT clients on the new guest WLAN1 could be causing the issue.

OE

It won't be trivial at all, but you need a proper DNS server in the network.
A PI, or a full Linux install, (you don't have to install it on a ssd/HDD, a USB boot will serve the purpose) or a Windows server.
You can setup a DNS server, instruct Asus to use that DNS server and find out the crazy client(s).
I'm not that skilled in Asus cli commands, but it may be possible to turn some debugging on to DNS server running on Asus. Considering the CPU, that may kill the router, that's why I would go for Linux route. It's trivial to install a DNS server and check the logs.
Another option would be a managed switch that can span a port. And capture DNS traffic into Wireshark.

You need to find that client. What you're seeing it's not a networking issue, it's a due to a faulty client.

Or push 8.8.8.8 and 8.8.4.4 directly to the clients from Asus DHCP server and your router will not be bothered. But that will not find the broken client.

 

[Sebastien Bougie]

Sounds like one/many IoT clients on the new guest WLAN1 could be causing the issue.

OE

Hello

Why i don't have the problem on the 385 version, this is why I found this weird

 

[Sebastien Bougie]

It won't be trivial at all, but you need a proper DNS server in the network.
A PI, or a full Linux install, (you don't have to install it on a ssd/HDD, a USB boot will serve the purpose) or a Windows server.
You can setup a DNS server, instruct Asus to use that DNS server and find out the crazy client(s).
I'm not that skilled in Asus cli commands, but it may be possible to turn some debugging on to DNS server running on Asus. Considering the CPU, that may kill the router, that's why I would go for Linux route. It's trivial to install a DNS server and check the logs.
Another option would be a managed switch that can span a port. And capture DNS traffic into Wireshark.

You need to find that client. What you're seeing it's not a networking issue, it's a due to a faulty client.

Or push 8.8.8.8 and 8.8.4.4 directly to the clients from Asus DHCP server and your router will not be bothered. But that will not find the broken client.

Thanks for the info, i'm already using Google dns and the problem persist...

I guest I will check how to setup DNS server and monitor it

 

[OzarkEdge]

Hello

Why i don't have the problem on the 385 version, this is why I found this weird

Agreed. I'm not saying it's a client... just suggesting that the issue appears to be related to one guest WLAN and/or its clients.

If you assume its a client, you could rename the SSID and reconnect the clients one at a time to see if that isolates a problem client. A chore that may or may not locate the issue. But if you have two identical clients and only one causes the issue, then you'd be getting somewhere.

OE

 

[Darkje]

You should be able to switch on "Ethernet Backhaul Mode" and that will release the 2nd 5GHz radio.
See the attachment. That's from a GT-AC5300.
I was able to add the second 5GHz radio to Smart Connect and this is the single most important addition 386 adds for me.
Try to find if that is an option on your Lyra.
And be aware this is causing big troubles for people using a dumb switch in between router and node - most likely because of lack of support for large MTU.

Nice color

 

[RMerlin]

@Neil62 RMerlin has it.

Download | Asuswrt-Merlin

www.asuswrt-merlin.net

No, I don't. I'm working with 386.40577 GPL code.