Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[prosperot]

Agree, this is hardly a Release Candidate version.... Lots of reboots on my AX88U. Not making my family very happy with this version...

 

[ASUSWRT_2020]

In the next release, we will change the AX models to the same SDK and add RT-AX86U, RT-AX58U, RT-AX56U, TUF-AX3000, RT-AX56U

 

[ASUSWRT_2020]

The list of beta builds doesn't cover some routers that support AiMesh (eg RT-AC1900). Does anyone know what Asus's long term intention is here? Will these routers eventually get FW that supports 2.0?

RT-AC1900 is the same model as RT-AC68U, you can use the RT-AC68U firmware.

 

[ligeza]

In the next release, we will change the AX models to the same SDK and add RT-AX86U, RT-AX58U, RT-AX56U, TUF-AX3000, RT-AX56U

Will Lira trio also be updated to aimesh 2.0? I'm not talking about next release but about next few months? Or it will not get any more updates because it is discontinued?

 

[Mattias]

Will Lira trio also be updated to aimesh 2.0? I'm not talking about next release but about next few months? Or it will not get any more updates because it is discontinued?

Not sure, somewhere I heard that it wont get aimesh 2.0. But how well aimesh 1.0 it will work togheter with aimesh 2.0 not sure. Probably and hopefully it works but you will miss some of the features. Otherwise you can throw them in the trash.

 

[Deleted member 22229]

In the next release, we will change the AX models to the same SDK and add RT-AX86U, RT-AX58U, RT-AX56U, TUF-AX3000, RT-AX56U

Good news any idea when this will happen ?

 

[Jerie-]

@ASUSWRT_2020

Sorry if this has been brought up in this thread but it's quite long and I apologize should I have missed it. I have a situation where the setup consists of two Asus routers: GT-AC5300 & RT-AC68U. The GT is the main router and RT is setup as an access point. The setup is NOT using AIMESH and the devices are connected by ethernet. We do not plan on using AIMESH 2.0 but will be using a GUEST network for IOT and occasional, if any, guests. This setup however, does have DHCP disabled on the router because the setup is using two local DNS and VPN through the GT. DHCP is running on one of the DNS (main) server and is working fine prior to upgrading ASUSWRT 386 RC2/RC5. With the latest AsusWRT 386 firmware, there seems to be only one option with Guest network, disallow access to local LAN. I understand the reasoning about this change but now all IOT can not obtain an IP from the local DHCP server, hence no internet/dns resolution. Is there a work around to allow at least the local dns/dhcp (not on the router), access to guest wifi as on AsusWRT 384? We resorted to disabling DHCP/DNS on the main router since it clashes with the VPN setup.

One last thing, disabling the LEDs (with led button), does nothing on the GT. It use to turn off the LEDs on the GT, with the exception of the LAN LED.

 

[GenericITGuy]

Did the latest RC (Update 2020/09/11 386 rc2-5 (9.0.0.4_386_40018)) become the official release that was announced today (Version 3.0.0.4.386.25790) or are they completely different builds?
I still have an issue with manual DHCP and not sure which one to try tonight.

Probably should have mentioned I am running a ZenWiFi XT8 (RT-AX95Q) on 9.0.0.4_386_39348 today. Also, hoping that 40018 has the ARP fix that was mentioned in 25790 build.

 

[Deleted member 22229]

Did the latest RC (Update 2020/09/11 386 rc2-5 (9.0.0.4_386_40018)) become the official release that was announced today (Version 3.0.0.4.386.25790) or are they completely different builds?
I still have an issue with manual DHCP and not sure which one to try tonight.

They are very likely different builds. These builds here are early Beta builds with people still reporting quite a few issues. I can not see Asus releasing any of these as a final build at this time for any router model.

 

[GenericITGuy]

They are very likely different builds. These builds here are early Beta builds with people still reporting quite a few issues. I can not see Asus releasing any of these as a final build at this time for any router model.

Understood, but at some point code moves from beta "release candidate" to GA (generally available). Just not sure if these are even on same track since the forum is WRT.

 

[OzarkEdge]

Did the latest RC (Update 2020/09/11 386 rc2-5 (9.0.0.4_386_40018)) become the official release that was announced today (Version 3.0.0.4.386.25790) or are they completely different builds?
I still have an issue with manual DHCP and not sure which one to try tonight.

Probably should have mentioned I am running a ZenWiFi XT8 (RT-AX95Q) on 9.0.0.4_386_39348 today. Also, hoping that 40018 has the ARP fix that was mentioned in 25790 build.

Some earlier post suggested ZenWiFi was ahead of other routers so it may have some .386 features in the .386 beta. But the build numbers you posted do not match so I would assume the released and beta builds are not the same.

I would stick with the released build unless you want to participate in the beta uncertainty.

OE

 

[GenericITGuy]

Some earlier post suggested ZenWiFi was ahead of other routers so it may have some .386 features in the .386 beta. But the build numbers you posted do not match so I would assume the released and beta builds are not the same.

I would stick with the released build unless you want to participate in the beta uncertainty.

OE

Honestly, I prefer beta uncertainty way over official releases that don't work as expected.

 

[sanke1]

Agree, this is hardly a Release Candidate version.... Lots of reboots on my AX88U. Not making my family very happy with this version...

Interesting.... This release seems to be the best one so far on my RT-AX88U V1.1

Almost nearing 9 days stability (Since installing this firmware)

I am also using newer (purpose built) 9.0.0.4.386_40145 firmware for another RT-AX88U V1.0 at my office for debugging because Port Forwarding used to stop working within 1-2 days on it. It was provided by ASUSWRT_2020. Thankfully, whatever the wizards at Asus did, it has cured my PF problem. Big thanks to @ASUSWRT_2020

@prosperot Have you tried clearing NVRAM and setting it up as new for 9.0.0.4.386_40018 firmware?

PM me for settings.

 

[Darkje]

@ASUSWRT_2020 for now all runs quit smooth on a AC86U, i was using RMerlins version cause i think it is the best off to worlds. What i dont understand is why there is no full OpenVPN client like the way RMerlin has it implented a way you can set specific users to use the VPN or not. I use it for adblock and geo. My wife hates it so i need to turn it off again :-(

Further all is smooth but it is just a few days.

 

[OzarkEdge]

Honestly, I prefer beta uncertainty way over official releases that don't work as expected.

So get on with it... install the beta firmware and answer your own questions about it. And report here to further the test.

OE

 

[UH-60]

Here's my trip report with the latest (rc2-5) release:

Setup: 3x XT8s. Two with ethernet backhaul, one with second 5G wireless backhaul (more on this later)

Initial upgrade: Went from stock GA image to 2-5 directly, followed by a factory reset. As others have indicated, without the reset, the UI was extremely sluggish. Doing a reset by physical buttons only provided partial relief - I had to perform an nvram erase to truly reset it.

The first thing I noticed was that one of the nodes (the one with the ethernet backhaul) had started to broadcast an additional network over 5G. This was showing up in the AiMesh tab as a 5G guest network, but no configuration was set to activate this. Turns out, once the client node joined the mesh, one of the three 5G SSIDs that were assigned to the 5G-2 PHY, wl2.6, was configured differently than the other client node. I had to change many of the wl2.6_* nvram variables to match the other client, reboot, and then the open network broadcast disappeared.

At that point, I had consistent configurations across the three nodes in the mesh:

• wl2.1 - [configured SSID]_dwb, no broadcast
• wl2.5 - [configured SSID], no broadcast
• wl2.6 - [old mesh backhaul SSD (hexadecimal string)], no broadcast

I was still experiencing occasional issues with wireless clients attaching to the node that was connected via wireless backhaul. What I determined was that, while packets were being routed out through the dpsta interface on the node, and being received via the wds interface on the router, some response packets were being dropped after being sent out via the wds interface. What was odd was that ICMP messages were working just fine, but TCP (SSL) connections would lose their minds sometimes. The firewall was turned off, and so was NAT, and iptables seemed to reflect that on both router and node. Switching to a wired backhaul seemed to have resolved this problem (at least since Saturday).

The last item of note was, when I switched the one node from wireless backhaul to ethernet, now most clients are saying they are connecting to the 5G-2 network. This is probably because the SSID exists on both PHYs, but I don't see that behavior on either the main router or the other node.

Overall, I do like the ability to bind to particular nodes, and with a bunch of tweaking it seems stable enough, but certainly some more issues to work through.

 

[prosperot]

@prosperot Have you tried clearing NVRAM and setting it up as new for 9.0.0.4.386_40018 firmware?

PM me for settings.
[/QUOTE]

Well, thanks for the help. I did that last evening... This morning my AX88U was frozen again... This time the log was filled with these error messages:

Sep 24 08:44:55 kernel: mroute: pending queue full, dropping entries
Sep 24 08:45:00 kernel: mroute: pending queue full, dropping entries
Sep 24 08:46:01 kernel: mroute: pending queue full, dropping entries
Sep 24 08:46:05 kernel: mroute: pending queue full, dropping entries
Sep 24 08:46:06 kernel: mroute: pending queue full, dropping entries
Sep 24 08:46:26 kernel: mroute: pending queue full, dropping entries
Sep 24 08:46:36 kernel: mroute: pending queue full, dropping entries
Sep 24 08:46:46 kernel: mroute: pending queue full, dropping entries
Sep 24 08:47:06 kernel: mroute: pending queue full, dropping entries
Sep 24 08:48:12 kernel: mroute: pending queue full, dropping entries
Sep 24 08:48:12 kernel: mroute: pending queue full, dropping entries
Sep 24 08:49:17 kernel: mroute: pending queue full, dropping entries
Sep 24 08:50:23 kernel: mroute: pending queue full, dropping entries
Sep 24 08:51:29 kernel: mroute: pending queue full, dropping entries
Sep 24 08:52:09 kernel: mroute: pending queue full, dropping entries
Sep 24 08:52:29 kernel: mroute: pending queue full, dropping entries
Sep 24 08:52:34 kernel: mroute: pending queue full, dropping entries

I can't go back in the log earlier than 4 am, but all I can see are these same error messages. Not sure what happend or caused this. This version is definitely very troublesome!

 

[livefeed]

Here is my problem if someone can help please.

I have a GT-AX1000 and 4 RT-AX92 on firmware version 9.0.0.4.386_40018 (R5)
my last node RT-AX92 (R5) connected into a Netgear MS510TXPP 8-Port multi-gigabit smart managed switch that just will not work with it, shows up as not connected. I have to go back to firmware RT-AX92U_3.0.0.4_384_9177 for it to connect. What setting in the switch that's not wanting to work with the past 4 betas?

 

[DiMENZi0N]

Let's hope ASUS release a new RC (6) for testing soon....

and they include the rt ac5300 this time

 

[Deleted member 22229]

Likely the AC5300 is on the latest Beta. RC2-5