What's new

Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0 (continued)

  • 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!

Solved my problems with 2.4Ghz on AX82U when running their last firmware available on site - 3.0.0.4.386.41700
Now with this beta version RC2 build 10, i am able to get my clients in 2.4Ghz network, with AX disabled, but i guess it's a kernel driver issue.
 

Attachments

  • AX82u stock 3.0.0.4.386.41700.png
    AX82u stock 3.0.0.4.386.41700.png
    28.9 KB · Views: 168
  • ax82 beta rc2 build10.png
    ax82 beta rc2 build10.png
    428.2 KB · Views: 188
Just want verification on this one...

GT-AC5300 on firmware RC2-10 (9.0.0.4.386_41535)...
* Clients on the former "5G-1" band seem to only connect to the main router, clients on this band do NOT roam between AiMesh nodes at all, nor do they connect to any AiMesh nodes on the network.
* Clients on the former "5G-2" back-haul band connect to and roam between AiMesh nodes as expected (works fine), dependent on signal strength, RSSI value, etc.
* I'm making these presumptions based on Ethernet backhaul mode being enabled (which I use because all of my AiMesh nodes are connected via Star topology Cat6 gigabit to the main router). It seems that leaving Ethernet backhaul mode off and setting each AiMesh node's connection priority to "1G WAN Only" avoids this whole issue.
* Clients connected to the "5G-2" band are labeled as "5G-1" within the 5300's web UI, even though the client is clearly connected to 5G-2...probably just a bug/cosmetic flaw

Why do clients that are joined 5G-1 only connect to the main router (can't imagine this is expected/normal behavior)? Clients joined to 5G-2 roam between AiMesh nodes, but the router's web UI clearly shows them on 5G-1 when viewing them from the network map list. Note that I am using Ethernet backhaul mode in the AiMesh System Settings. Clients can connect to 5G-1 and connectivity is fine, but again, none of the AiMesh nodes will pick up clients on the 5G-1 band. 5G-2 works just fine roaming between AiMesh nodes. Odd bug...from my reading of past threads it seems that Ethernet backhaul mode causes this behavior.
 
Last edited:
Update again on 2021/1/21
We are patching DNSmasq vulnerability disclosed by JSOF and will start to put beta firmware on ASUS support site for this issue.

---------------------------------------------------------------------------------------------------------------------------------
Status update on 2021/1/21

386 rc2 formal released models
GT-AX11000 3.0.0.4.386.41700
RT-AX88U 3.0.0.4.386.41700
RT-AX86U 3.0.0.4.386.41535
RT-AX82U 3.0.0.4.386.41700
RT-AC86U 3.0.0.4.386.41634
TUF-AX3000 3.0.0.4.386.41700

ZenWiFi XD4 3.0.0.4.386.41535
RT-AC88U 3.0.0.4.386.41700
RT-AC3100 3.0.0.4.386.41700
RT-AC68U 3.0.0.4.386.40558

Under testing models
ZenWiFi XT8
GT-AC2900
RT-AC86U (to solve high CPU utilization issue)
RT-AX92U
RT-AX58U
RT-AX55



--------------------------------------------------------------------------------------------------------------------------------
Update 2020/12/31 (9.0.0.4.386.41535)

This version includes
ZenWiFi XT8, XD4, CT8
GT series: GT-AX11000, GT-AC5300, GT-AC2900
RT series: RT-AX88U, RT-AX92U, RT-AX86U, RT-AX82U, RT-AX58U, TUF-AX3000, RT-AX56U, RT-AX55
RT series: RT-AC5300, RT-AC88U, RT-AC3100, RT-AC86U, RT-AC68U


Due to compile problem, not in this version
ZenWiFi CD6, Lyra, Lyra mini, Lyra trio


Change log
- Fixed Let's encrypt register issue.
- Fixed packet loop problem in ethernet backhaul.
- To improve security, RT-AC68U starts to encrypt the NVRAM from this version.
Known issue: RT-AC68U needs to be reset to default to resolve the login problem after upgrading to this beta version.
If you want to downgrade to the previous version, you need to do it with rescue mode.
We are looking for a solution to this problem if you worry about this known issue, please wait for a further version and not update to this version.

Happy new year!

------------------------------------------------------------------------------------------------------------------------
Update 2020/12/01(9.0.0.4.386.41157)
https://drive.google.com/drive/folders/1D4X3k9GXxkiRQkaO1huQGnCAsQeIvokC?usp=sharing

This version inclouds
ZenWiFi: XT8(RT-AX95Q), XD4(RT-AX56U_XD4), CD6(RT-AC59_CD6)
GT series: GT-AX11000, GT-AC5300, GT-AC2900
RT series: RT-AX88U, RT-AX92U, RT-AX86U, RT-AX82U, RT-AX58U, TUF-AX3000, RT-AX56U, RT-AX55
RT series: RT-AC5300, RT-AC88U, RT-AC3100, RT-AC86U, RT-AC68U

Change log
1. Fixed WAN LED bug.
2. Fixed WiFi onboarding issues.
3. Fixed mac filter issue bugs.
4. Fixed time schedule bugs.
5. Fixed RT-AC88U/3100 ethernet backhaual bugs.


------------------------------------------------------------------------------------------------------------------------
Update 2020/11/12 (9.0.0.4.386.40947)
https://drive.google.com/drive/folders/1UHZwR1buG-nei8fne9d9OktOS2gZy6Hs?usp=sharing

This version includes 19 models:
ZenWiFi: XT8(RT-AX95Q), XD4(RT-AX56U_XD4), CD6(RT-AC59_CD6)
GT series: GT-AX11000,GT-AC5300, GT-AC2900
RT series: RT-AX88U, RT-AX92U, RT-AX86U, RT-AX82U, RT-AX58U, TUF-AX3000, RT-AX56U, RT-AX55
RT series: RT-AC5300, RT-AC88U, RT-AC3100, RT-AC86U, RT-AC68U

Change log
  1. Fixed Ethernet backhaul through switch issue
  2. RT-AX86 and GT-AX11000 support 2.5G port as ethernet backhaul
  3. Fixed RT-AX55 firmware update issue.
  4. Fixed speedtest issue for android app.
  5. Fixed mesh node guest network internet connection issue.
  6. Fixed ap mode guest network issue.
  7. Added security patch
  8. Fixed repeater mode UI bug.


------------------------------------------------------------------------------------------------------------------------
Update 2020/10/22 (9.0.0.4.386.40577)

This version includes 18 models:
ZenWiFi: XT8(RT-AX95Q), XD4(RT-AX56U_XD4)
GT series: GT-AX11000,GT-AC5300, GT-AC2900
RT series: RT-AX88U, RT-AX92U, RT-AX86U, RT-AX82U, RT-AX58U, TUF-AX3000, RT-AX56U, RT-AX55
RT series: RT-AC5300, RT-AC88U, RT-AC3100, RT-AC86U, RT-AC68U

Change log
1. Changed SDK and support more AX models.
2. You can see the speed test at the router app with firmware 386.40477 and the latest app on the app store/google play. Speed test page is at router app Settings tab --> QoS --> Internet Speed
3. Fixed Speedtest UI bugs
4. Enhance backhaul optimization algorithm


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Update 2020/10/08
If you want to test the new feature, Instant Guard.
Please check this thread https://www.snbforums.com/threads/asus-instant-guard-ios-public-beta.66814/

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Update 2020/10/06 386 rc2-6 (9.0.0.4_386_40322)

This version includes GT-AX11000, RT-AX92U, RT-AX88U, GT-AC5300, RT-AC5300, RT-AC88U, RT-AC3100, RT-AC86U, GT-AC2900, RT-AC86U, and RT-AC68U

Because of the SDK integration issue, this version does not include ZenWiFi XT8, ZenWiFi XD4, RT-AX86U, RT-AX82U, RT-AX58U, TUF-AX3000, RT-AX56U

Change logs:

- Fixed wireless backhaul retry issue after set the ethernet backhaul mode.
- Fixed slow web UI problem.
- Fixed UI problem in network map --> view list --> interface --> guest network
- Adjusted prefer AP connection mechanism.
- Fixed stack overflow vulnerability.

New Family interface in ASUS router App.
router firmware greater or equal to 9.0.0.4_386_40322
ASUS Router App greater or equal to iOS v1.0.0.5.75
Android greater or equal to v1.0.0.5.74

View attachment 26693





------------------------------------------------------------------------------------------------------------------------------------
Update 2020/09/11 386 rc2-5 (9.0.0.4_386_40018)
https://drive.google.com/drive/folders/1Sqzva4uK7DTrp7oV93__LR6FZoDOckrN?usp=sharing

Change logs:
1. Add important patches for AiMesh backhaul and there are two FAQs for ethernet backhaul
What is Ethernet Backhaul Mode/connection priority in AiMesh system and how to set up in different scenarios?
[Wireless] How to setup ASUS AiMesh or ZenWiFi Mesh Ethernet backhaul under different conditions (Advanced setup with network switch)?

2. Clients which connect to the guest network can be viewed in the network map -->view list --> interface
Most of the routers have three sets of guest network and each set has 2.4G and 5G-1 (triband model has 5G-2)
View attachment 26147



3. Support IPSec IKE v1 and IKE v2, and you can use Windows 10 native VPN client program to connect to the router's IPSec VPN server.
The Windows 10 new FAQ is in https://www.asus.com/support/FAQ/1033576



4. Fixed stack overflow, File Traversal, XSS vulnerabilities.

Support models:
GT-AX11000
GT-AC5300
GT-AC2900
RT-AX92U
RT-AX88U
RT-AC86U
RT-AC68U
RT-AC3100
ZenWiFi XT8 (RT-AX95Q)

RT-AC5300 and RT-AC88U had some errors and we are going to fix it. The firmware will upload to the same link after fixed the problem





======================================================================================


Update 2020/08/14
https://drive.google.com/drive/folders/1twgcnXo_ywSZG2GU67V6Zl_T0RAyiBvb

Change logs:
1. Fix AiMesh page Tx/Rx 0 issue.
2. Add more wifi stability patches.
3. Apply new backhaul optimization mechanism.
4. Apply new client device recognize rules.

Now node which supports team port (link aggregation) can be enabled here:
View attachment 25411

In AiMesh client list, click the "chain" icon, you will be able to select a preferable AP for this device. (* note: it's prefer ap, not bind)
View attachment 25412




Update 2020/08/06

386 rc2-3 firmware is in this link
https://drive.google.com/drive/folders/154vHdrYh_rGP_qFooHgAkzXSJchge7Ue?usp=sharing

Change log:
1. Fixed node 5G connection problem (lots of complaints about this bug)
2. Improved IoT compatibility


known issues
1. Tx and Rx rate is still 0 in AiMesh Network fronthaul/backhaul information. We will fix this in the next build.
2. No RT-AX88U and RT-AX92U in this release. We are going to fix the build error problem.
3. Firmware extension numbers are different for different models. The range is from 386_39339 to 386_39348

Current Support models:
GT-AX11000
GT-AC5300
GT-AC2900
ZenWiFi XT8 (RT-AX95Q)
RT-AC5300
RT-AC88U
RT-AC3100
RT-AC86U
RT-AC68U
Thanks @ASUSWRT_2020 , I assume the same dnsmasq fix will be released for AX86u as well, right?
How about performance issues in 9.0.0.4_386_41535, is there hope for those too?
 
802.11k/v roaming between AiMesh nodes are still unreliable (GT-AX11000 + RT-AX86U) .

Slow roams and inconsistent triggering on 802.11k/v supported iOS devices.

Is 802.11k/v enabled for band steering?
 
For anyone that may be stuck trying to get the Asus GT-AX11000 Wireless Router to upgrade from the RC10 Beta software to the RTM firmware and running into an update failure pop-up, I suggest putting the router in rescue mode, and plug the ethernet into port 4 (All the other ports would not respond in rescue mode). I had the same issue and once I plugged an ethernet cable into port 4 and ran rescue mode, the router finally responded and updated to the RTM 386 firmware. I believe it may of been a small bug, but big enough pain in the RC10 Beta firmware. Hope this helps anyone else that was experiencing similar problems.
Exactly what I had to do and working perfect now on RTM version.
 
I ran into the Web UI "failure to login" issue again. After adding a new DHCP IP assignment and applying the settings, the GT-AC5300 restarted and I could not login beyond the initial prompt. Note that when this happens, everything works fine except for the web UI...wireless clients connect, WAN connection is fine, no issues with connectivity, just the web interface. I can SSH into the router using its base IP as well...running the command "service restart_httpd" restarts the web service so that the initial login page shows up, but it does NOT get the web UI working. Rebooting/powering the router off and on also does not resolve it.

If anyone runs into this problem, I did figure out a workaround...

(1) Power off GT-AC5300
(2) Power off ALL AiMesh nodes
(3) Disconnect WAN cable from GT-AC5300
(4) Power on GT-AC5300
(5) Login to Web UI (it should now work)
(6) Reconnect WAN cable to GT-AC5300
(7) Power ON all AiMesh nodes

Web UI resumes normal function after following the above steps. Seems like a bug in the RC2 firmware (haven't run into this issue previously on stable/public firmware). Used the feedback page within the web UI to report the issue to ASUS. I understand the Beta firmwares are for testing and are not stable, but gaining the AiMesh 2.0 features have made the Beta worth it, IMO.
I got to try this after the AX92U firmware release today. Thanks for saving me from the headache of resetting. Very strange bug.

edit: Wouldn't you know it, rebooting the GT-AC5300 brings it back to the WebGUI login failure. :(
 
Last edited:
I got to try this after the AX92U firmware release today. Thanks for saving me from the headache of resetting. Very strange bug.

edit: Wouldn't you know it, rebooting the GT-AC5300 brings it back to the WebGUI login failure. :(

Right...any time the GT-AC5300 is rebooted, the initial login failure can reoccur. It seems random. If you pull the wan cable, then reboot the GT-AC5300 (either from SSH or just press the power button on/off), and wait a few minutes for it to come back up (with the WAN cable disconnected), you should be able to login once it's up. After that point, you can plug the WAN cable back in and bring your AiMesh nodes back up.

Factory resets are a pain...takes time to manually re-add the AiMesh nodes, redoing the config from scratch...having to add those manual IP assignments/port forwarding rules (if you use them) can take a substantial amount of time. I also have to spend a lot of time renaming all the clients on my client list...lots of Wifi power outlets that I name based on their location inside the house. It would be nice if ASUS would let you pick and choose the settings you want to Restore in order to avoid restoring deprecated or invalid config settings. I understand that some features or configs may not exist (or change substantially) between firmware releases that can cause the new firmware to blow up and not function as a result of a "dummy" restore that restores everything. For example, being able to selectively restore client names would be nice. You wouldn't think importing meta data (that is purely cosmetic) would cause problems. I can understand that restoring other configs such as forwarding rules or WiFi settings might cause issues due to logical changes in the firmware itself. Imports are nice but can get complicated. The firmware needs to have built-in logical checks, normalization/validation of data, and must account for a multitude of use cases or the Restore function is useless. I'm sure the current ASUS Restore does some of this, but it's clearly lacking because ASUS seems to recommend reconfiguring from scratch after a factory reset. Seems they don't trust their own Restore function.

I'm not sure what triggers the UI login initially, or why pulling the WAN cable suddenly allows the web UI to function again. When you're experiencing the login problem - If you open up a web browser, and login with your admin account, you'll notice the browser hangs on a blank page - if you login to the router via SSH and restart the httpd service while your browser is hanging, you'll see the GameDashboard.asp page load briefly then bounce back out to the login screen. Very odd, but clearly some process is hanging up the loading of the elements within the ASP page.

It's nice having the benefits of AiMesh 2.0 among some other new features in RC2-10, but the UI login problem is nearly a deal-breaker. From what I've read, the login problem doesn't happen on previous RC2 beta's...but we all know it's no fun running older beta's since they're usually missing some new features and under-the-hood improvements. Sometimes beta's can be one step forward and two steps back. Hopefully ASUS reads these posts and can more quickly find ways to fix the problems we're seeing on the beta firmwares.
 
Last edited:
Has anyone tried to have rt-ax58u and add another as aimesh with the latest beta wireless? It does not work. It only works with Ethernet cable and using the new aimesh gui not the old. Really strange... Via wireless it does not find anything. With cable on the old way it always fails around 100%.

But with the old aimesh 1.0 it worked. Both has been rest to factory settings.

After it has been added then you can use wireless backhaul.
 
Right...any time the GT-AC5300 is rebooted, the initial login failure can reoccur. It seems random. If you pull the wan cable, then reboot the GT-AC5300 (either from SSH or just press the power button on/off), and wait a few minutes for it to come back up (with the WAN cable disconnected), you should be able to login once it's up. After that point, you can plug the WAN cable back in and bring your AiMesh nodes back up.

Factory resets are a pain...takes time to manually re-add the AiMesh nodes, redoing the config from scratch...having to add those manual IP assignments/port forwarding rules (if you use them) can take a substantial amount of time. I also have to spend a lot of time renaming all the clients on my client list...lots of Wifi power outlets that I name based on their location inside the house. It would be nice if ASUS would let you pick and choose the settings you want to Restore in order to avoid restoring deprecated or invalid config settings. I understand that some features or configs may not exist (or change substantially) between firmware releases that can cause the new firmware to blow up and not function as a result of a "dummy" restore that restores everything. For example, being able to selectively restore client names would be nice. You wouldn't think importing meta data (that is purely cosmetic) would cause problems. I can understand that restoring other configs such as forwarding rules or WiFi settings might cause issues due to logical changes in the firmware itself. Imports are nice but can get complicated. The firmware needs to have built-in logical checks, normalization/validation of data, and must account for a multitude of use cases or the Restore function is useless. I'm sure the current ASUS Restore does some of this, but it's clearly lacking because ASUS seems to recommend reconfiguring from scratch after a factory reset. Seems they don't trust their own Restore function.

I'm not sure what triggers the UI login initially, or why pulling the WAN cable suddenly allows the web UI to function again. When you're experiencing the login problem - If you open up a web browser, and login with your admin account, you'll notice the browser hangs on a blank page - if you login to the router via SSH and restart the httpd service while your browser is hanging, you'll see the GameDashboard.asp page load briefly then bounce back out to the login screen. Very odd, but clearly some process is hanging up the loading of the elements within the ASP page.

It's nice having the benefits of AiMesh 2.0 among some other new features in RC2-10, but the UI login problem is nearly a deal-breaker. From what I've read, the login problem doesn't happen on previous RC2 beta's...but we all know it's no fun running older beta's since they're usually missing some new features and under-the-hood improvements. Sometimes beta's can be one step forward and two steps back. Hopefully ASUS reads these posts and can more quickly find ways to fix the problems we're seeing on the beta firmwares.
What were the significant improvements released on RC10 vs RC9. I'm debating on trying the beta. I have 4 RT-AC5300 as nodes and 1 GT-AC5300 as the main router. Any recommendations?
 
First page of thread covers the changes in RC10. I don't know anything beyond what's stated in that first post. If you decide to try the beta, expect some instability and other problems. The GT-AC5300 has login problems with the admin web UI in the latest beta, and you will need to go through a number of steps to gain access to your UI when it surfaces, based on the steps I outlined earlier. Not saying it's always going to happen 100% of the time, but it seems to be an issue for at least a handful of GT-AC5300 owners on here.
 
GT-AC5300 Released Firmware!


CC
 
Let's hope the RC2-10 bugs are all fixed.

Anyone have a direct link for the new GT-AC5300 firmware? I'm not seeing it on the Router support page and the web UI update is not showing anything new.
 
Let's hope the RC2-10 bugs are all fixed.

Anyone have a direct link for the new GT-AC5300 firmware? I'm not seeing it on the Router support page and the web UI update is not showing anything new.
Adapt your link to the previous (zip) download with the correct version number and you'll probably succeed. That's how I got mine for RT-AX92U when I had same problem...
Let's hope the RC2-10 bugs are all fixed.

Anyone have a direct link for the new GT-AC5300 firmware? I'm not seeing it on the Router support page and the web UI update is not showing anything new.
 
Let's hope the RC2-10 bugs are all fixed.

Anyone have a direct link for the new GT-AC5300 firmware? I'm not seeing it on the Router support page and the web UI update is not showing anything new.

Select driver and tools then for OS select others.
 
What about the RT-AC5300? No news about his 386 Firmware?
It seems Merlin's beta 5 has included 386_41700 for RT-AC5300.
"5e9564e6bf Merge 386_41700 binary blobs for RT-AC88U/RT-AC3100/RT-AC5300"​

I trust Asus will release it soon.
 
It seems Merlin's beta 5 has included 386_41700 for RT-AC5300.
"5e9564e6bf Merge 386_41700 binary blobs for RT-AC88U/RT-AC3100/RT-AC5300"​

I trust Asus will release it soon.
Thanks for the info.
I tried using Merlin with AiMesh 2.0 on my RT-AC5300 with RT-AC68U setup but I was unsuccessful. I will try again later.
 
Summary of 3.0.0.4.386.41793 released today for GT-AC5300 (compared to RC2-10):

(1) Traffic stats have been fixed - they're no longer off by a factor of 10 or more
(2) Can be dirty flashed over RC2-10.

** If you were having the web UI login issue (where the browser window would go blank after logging in), this problem will reoccur after flashing to 3.0.0.4.386.41793 and restarting. I did a factory reset (initialized all logs, etc.) from the web UI - Administration > Restore/Save/Upload Setting > tick the box to initialize all settings for a complete reset. I have restarted the GT-AC5300 a few times while re-doing the config from scratch and the web UI problem has NOT resurfaced (so far).

(3) Issues with the 5G-1 and 5G-2 bands seem to have carried over to AiMesh where any clients connected to 5G-1 only bind to the main router and not to AiMesh nodes. Any clients on 5G-2 will bind to AiMesh nodes and roam as expected. Also, the GT-AC5300, in Network Map, will show that all 5G clients are connected to 5G-1, even if they are connected to 5G-2. Cosmetic but confusing.

(4) Bandwidth monitor in traffic stats area seems to be off. Cosmetic issue

(5) DDNS working fine (I'm personally using no-ip.com's premium services)

(6) Connectivity seems stable for Wireless clients on 2.4G and 5G. External and internal bandwidth testing show clients reaching their expected speeds.
 
Last edited:
3 is happening because a 2 band node will choose the channel used by the 2nd 5GHz radio of a 3 band router.
I would expect to work more predictable if node is a 3 radio model.
I think we can happily live with that.
 
3 is happening because a 2 band node will choose the channel used by the 2nd 5GHz radio of a 3 band router.
I would expect to work more predictable if node is a 3 radio model.
I think we can happily live with that.

Ah, makes sense now. My nodes are 68U's and one 86U, all dual-band nodes. So 5G-1 more or less becomes a dedicated band, direct to the main router (since it's the first channel of the 5Ghz band).
 
Last edited:

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