What's new

Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Just out of curiosity and trying to improve performance/experiment, I tried to disable "Optimize AMPDU Aggregation”. That didn't go so well with my Solaredge inverters wifi, so I had to turn it back to enable again.
My question is, what does "AMPDU RTS", affect, and what to gain to disable it? I searched G but didn't get a clear answer. On my 5Ghz I already have it disabled.
Sure!

First of all, most of these tweaks you’re playing with have everything to do with the coverage size required and degree of congestion in your network. Turning them on or off won’t kill anyone, but they may variously affect how accurate your router is at recognizing and excluding what it perceives as erroneous data blocks—improving transmission and connection stability at the expense of speed. The whole AMPDU, WMM and beamforming sections are error-checking services pertinent to three respective aspects of your network configuration: number of devices, type of data involved, and distance from the router, in that order.

“AMPDU RTS” and “Optimize AMPDU Aggregation” go together—“RTS” stands for “Request to Send”, and there are adjustable thresholds that appear below it when it is turned on (and please don’t bother going there). “Optimize Aggregation” subsequently activates the overhead scanning and error checking features of AMPDU itself.

Think of the former as turning on the block error checking function and activation thresholds required for crowded bandwidth situations, and the latter as actually instructing the router whether to acknowledge or ignore the extra blocks found. So having one on without the other really accomplishes nothing—either turn them both off or both on, depending on the environmental factors I mentioned previously.

“WMM No Acknowledgement” (WMM stands for Wireless Multimedia Extensions) tells the router to ignore another means of error checking specific to handling data from media streaming services, such as internet television and VoIP signals. Since you’ve already enabled WMM itself, turning on “No Acknowledgement” simply tells the router to proceed with transmitting the signal without waiting for the error data confirmation to return. If you experience problems with this, then it means you are generating enough multimedia transmitter crosstalk to warrant the extra layer of error checking.

Finally, enabling Universal Beamforming benefits folks with medium to large sized houses. It enables the router to estimate channel availability and subsequently steer the signal to weaker areas a certain distance beyond the router antennae location. I leave it on—if you have plenty of coverage for your network size, try keeping it off.

Hope that explains what all these layers of error-reduction technology do. And to be honest, I think the best approach is to start with a guesstimate based on all the network factors above you’re asking your mesh network to handle—and then start flicking the switches that complement each other logically until you get to your sweet spot. And then when a friend buys you another smart device, be prepared to adjust again! A mesh network is a big oceanic ecosystem, and little ripple on one side can cause tsunamis when they reach the other...
 
Last edited:
Since upgrading both XT8s to the latest RC2 I just cannot seem to find my node. Even when I fall-back to the release firmware I still cannot find it.
 
For those people which are using the current RC10 (41535) on an RT-AC86U, have you noticed any speed drop off, for/via clients connected to Wi-Fi, across both main and node routers? I put this finding out there (See/click on link below), when I took the current RC for a spin, haven't seen any traffic from/to those (if any), that are using the RT-AC86U on this current RC.

My boredom, I suppose, just keen to keep playing with new/newer firmware versions.

My apologies in advance, if this seems like a duplicate posting to my original.

 
Last edited:
Dear @ASUSWRT_2020 - any luck with super slow Ookla tests while using TrendMicro? Opting out from TrendMicro privacy solves the problem.
Latest revisions appear to still have this issue.
 
For those people which are using the current RC10 (41535) on an RT-AC86U, have you noticed any speed drop off, for/via clients connected to Wi-Fi, across both main and node routers?

Given all of the negative posts about RC2-10, I avoided it. A beta test doesn't require us to suffer overly flawed firmware.

OE
 
Hello , i have Asus RT AX92U and after upgrading to firmware 9.0.0.4.386.41535 i receive quite significant speed drop . Something like this :
Screenshot_2222.png


From my ISP i receive 300/300 , and after upgrading to newer firmware its not even 100 . It was tested on PC which connected to router via ethernet cable , on wi fi the result is more lower . Does anyone know are they going to solve the problem with speed drop ? Or i should downgrade to previous version through restore mode ?

Big #thanks_ for_ asus which do not tested newer firmware before published it
 
Firmware beginning with '9.0.0...' is Beta firmware. You're testing it to report problems with it, not get a stable router out of it, today. :)
 
Hello , i have Asus RT AX92U and after upgrading to firmware 9.0.0.4.386.41535 i receive quite significant speed drop . Something like this :
View attachment 29228

From my ISP i receive 300/300 , and after upgrading to newer firmware its not even 100 . It was tested on PC which connected to router via ethernet cable , on wi fi the result is more lower . Does anyone know are they going to solve the problem with speed drop ? Or i should downgrade to previous version through restore mode ?

Big #thanks_ for_ asus which do not tested newer firmware before published it

Don't install beta test firmware if you don't want to experience beta firmware defects.

OE
 
The IP address for rescue mode depends on the router model and the firmware version on it. Some default to 192.168.1.1, some default to 192.168.50.1. Try both, and see which one works if you aren't sure which one is the correct one for your specific case.
RMerlin,
Thanks for your reply ... I tried both Router IP 192.168.50.1 and 192.168.1.1, and confirm that when using Mac based Asus Firmware Restoration version 1.1.12 found in AppStore. We should just simply follow the instructions in the App. Specifically, manually configure IPv4 on Mac as follows:
  • Configure IPv4: Manually
  • IP address: 192.168.1.12
  • Subnet Mask: 255.255.255.0
  • Router: 192.168.1.1
PS: (Warning for other owners of RT-AX88U, Hardware Version: A 1, Purchased: September 2019), For my case after upgrading to current RC2-10 Firmware 9.0.0.4_386_41535-g1caa24a, any attempt to upload same firmware or downgrade to Merlin's 386.1 beta3 will fail. The only way to workaround is via Rescue Mode using Asus Firmware Restoration tool. I am now back to 386.1 beta3.
 
Given all of the negative posts about RC2-10, I avoided it. A beta test doesn't require us to suffer overly flawed firmware.

OE
I am the only one with zero issues with this RC2-10 with 2 RT-AX88Us in mesh? Most of my DDNS issues were fixed by replacing Asus own DDNS service with more reliable No-IP premium service.
 
PS: (Warning for other owners of RT-AX88U, Hardware Version: A 1, Purchased: September 2019), For my case after upgrading to current RC2-10 Firmware 9.0.0.4_386_41535-g1caa24a, any attempt to upload same firmware or downgrade to Merlin's 386.1 beta3 will fail. The only way to workaround is via Rescue Mode using Asus Firmware Restoration tool. I am now back to 386.1 beta3.
I experienced the same on Hardware Version A1.1 and resorted to the same downgrade method.
 
I am the only one with zero issues with this RC2-10 with 2 RT-AX88Us in mesh? Most of my DDNS issues were fixed by replacing Asus own DDNS service with more reliable No-IP premium service.

Same experience here.
9 days uptime so far.
 
Neither do I, my RT-AX58U works great, in mesh with a Lyra. Just looking forward to the 386 firmware for the Lyra.
 
Hello , i have Asus RT AX92U and after upgrading to firmware 9.0.0.4.386.41535 i receive quite significant speed drop . Something like this :
View attachment 29228

From my ISP i receive 300/300 , and after upgrading to newer firmware its not even 100 . It was tested on PC which connected to router via ethernet cable , on wi fi the result is more lower . Does anyone know are they going to solve the problem with speed drop ? Or i should downgrade to previous version through restore mode ?

Big #thanks_ for_ asus which do not tested newer firmware before published it

41535 was removed. Install previous version 3.0.0.4.386.40451 and speed will restore.
 
Hi all,

Tried 9.0.0.4.386.41535 as a last resort on my CT8. Long story short, client devices closer to the node kept connecting to the router and not the node, resulting is really poor connections. Last resort because if I could use the "assign" node function, the CT8 would not need to be returned...and my return period is up here in 2 weeks. 41535 was the only firmware released for the CT8 that I could find that had the assign node function...previous RC's didn't include the CT8.

On the positive side: 41535 and its assign function work fine! I can actually separate where things connect and things are much better. No range or other slowdowns noticed.

Only negative: the 5GHZ-2 backhaul drops to 2.4GHZ after a day or so being up, even though the 5GHZ-2 connection is flagged as 63dbm RSSI and "Great" the whole time.

Just thought I'd report, since I didn't see anyone comment with a CT8 and this problem.

Thanks!
 
I can confirm that with 41535 on my AX88u and two ac68u aimesh nodes if I enable a guest network which has no intranet access and sync to all nodes then devices on those nodes will drop many packets. Changing to not sync to aimesh nodes fixed it. (Reboot of nodes needed this time). Ethernet backhaul is enabled.

Believe from chatting with others that this is only happening with ac68u nodes.

AX88u as indicated still spams log with buggy protocol error and Speedtest on device is slow.

Edit: The message from this release “Fixed packet loop problem in ethernet backhaul” made me think to try the same setup but with Ethernet backhaul disabled. I disabled Ethernet backhaul, turn on sync to all and set connection priority to 1G WAN for bother aimesh nodes. Rebooted the entire system. Now I am seeing minimal packet loss (not the 40-60%) I was seeing. But still see 0.5% to 1%.
 
Last edited:
I totally gave up on RC2 and just reinstalled the release firmware on both XT8s. I am using them in media bridge config with 160Mhz dedicated backhaul because that's the only way I'm able to get a fast, stable wireless connection on the backhaul. AiMesh just keeps falling back to 2.4 and "Weak".
 
I totally gave up on RC2 and just reinstalled the release firmware on both XT8s. I am using them in media bridge config with 160Mhz dedicated backhaul because that's the only way I'm able to get a fast, stable wireless connection on the backhaul. AiMesh just keeps falling back to 2.4 and "Weak".
yeah me too.. since I dont use XT8 as my main router and change to AX86U, I also can't use RC2 anymore as the second XT8 will only connect using 2.4GHz only.

If only use both XT8 without third router, I can use this RC2 without having any 2.4GHz problem.
 
AX86U RC10
Adding iptables rules are not used. AppDB rules work fine.
Trying to tweak manual speeds in qos has no effect on trying to help with bufferbloat.
 
Thought I would give an update to some of my testing. I have spent countless hours testing and have taken copious notes. Maybe Asus and a few on the forum will find this useful. Every setup is different, so your mileage may vary.

I have 2 86u routers currently setup in AI Mesh 2.0, using the the latest non RC firmware. I went all the way back to 5717 to present including RC and Merlin to see if the problems I am having on the Beta and Live would happen on earlier firmware. I have 50+ devices with 30 or so small IOT switches. The rest are phones, tablets, echo devices, roku's, game consoles, etc. My goal was to put ALL of the IOT's on a guest network. In EVERY firmware past to present including Beta/RC-10 and Live, that many devices overloaded the guest network. It was fine with a handful, but once I crossed a certain threshold of devices, the 2.4 would drop and devices would go offline and the network would become unresponsive. This also happened with my devices in AP mode and not Aimesh. A reboot would bring the network back to stable for maybe 1-2 hours. I even tried putting the devices on the 2nd Guest network like someone suggested earlier and experienced the same problems. What I have not tried, and if anyone is up for it (I am a little tired at the moment, and my classes start back tomorrow), I would like to try using ALL 3 guest networks and putting 10 devices on each one to balance the load. Currently ALL of my IOT's are on the normal NON Guest 2.4 network with the rest on the 5G. Runs perfectly stable in Aimesh 2.0 with absolutely no problems! Of course, this is not ideal but doable. Maybe there is a hard limit on the guest network that I didn't dig deep enough to uncover? Maybe the guest network was not meant to handle this kind of load?


Either way, Aimesh 2.0 is amazing and definitely worth the Beta testing!

Thank you for your time!
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top