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!

Did the web UI go to a blank page after login (on GameDashboard.asp)?
It's not that widespread as it may look just by reading around here. It's just people without problems being quiet, nothing unusual.
I have been running every single beta, I did a factory reset early on this program (to make sure a cheap ECP cheapest is to blame - it wasn't, it was Asus, but they fix it quickly) but I never had a blank page.
 
That was indeed a question I had. If the config save is really only configs save then the proces "save config > factory reset > restore config" would be a correct one. Apparently there is something saved in the config that is no visible conffiguration option ? Can somebody explain whats happening under water here ? I hate a factory reset because I have to remember and manually restore every setting I had, and this seemed a nice workaround ...

The only way to do a proper factory reset is to first flash the latest firmware build you want to run, proceed with the factory reset, then configure the router from scratch. Importing a settings file will grab defaults and values that may grab old/deprecated settings values and lead to issues in the future, or carry over settings that were causing past issues. My $0.02...ASUS should include individual restore options that simply takes text metadata and imports it ensuring that deprecated settings values aren't applied. A big time-saver would be importing the network client list, which is purely cosmetic, but certainly useful for those who have wifi outlets, etc. and like to see which devices attach to which AiMesh nodes.

ASUS has made it much easier to factory reset...now you can nuke everything with one button in AiMesh.
 

Attachments

  • factory_reset.png
    factory_reset.png
    398.4 KB · Views: 232
@ASUSWRT_2020

RT-AC68U Firmware 9.0.0.4.386.41994 Beta Version released on 2021-02-01.


ASUS RT-AC68U Firmware version 9.0.0.4.386.41994 (Beta Version)

Security Fixed:
Fixed CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687, CVE-2020-25684, CVE-2020-25685, CVE-2020-25686

Please be noted this is a quick fix beta version for DNSmasq vulnerabilities. Refer to "Method 2: Update Manually" in https://www.asus.com/support/FAQ/1008000 to update this firmware.
Does this still have the issue requiring factory reset because of encryption changes -- if coming from an older Beta version?
 
Does this still have the issue requiring factory reset because of encryption changes -- if coming from an older Beta version?
That's actually a great point!
Short version would be: users should be able to understand release notes or Asus to help us for when a factory reset would be a must.
Certificates: if a certain authentication or encryption method stops being supported.
Encryption (OpenVPN or IPSec or whatever) - very much the same.
It's not trivial by all means for a random user to be able to understand what protocol is becoming dangerous (random ex: SHA1 being retired). If user is using that protocol it's either Asus that can help with a clear message, either protocol will be retired so a bunch of stuffs will stop working (a lots a people getting annoyed and complaining to support or forums).

That's a great point and whatever solution is decided by the vendor...it will be fun to watch!
 
RT-AC86U rc-2-11
Traffic monitor work for a moment,
After a while, the scale on the line changes to abnormal values.
1612210789251.png


Problem is generated by strange spike on 5GHz band
1612212753222.png
 
Last edited:
@ASUSWRT_2020

RT-AC68U Firmware 9.0.0.4.386.41994 Beta Version released on 2021-02-01.


ASUS RT-AC68U Firmware version 9.0.0.4.386.41994 (Beta Version)

Security Fixed:
Fixed CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687, CVE-2020-25684, CVE-2020-25685, CVE-2020-25686

Please be noted this is a quick fix beta version for DNSmasq vulnerabilities. Refer to "Method 2: Update Manually" in https://www.asus.com/support/FAQ/1008000 to update this firmware.

EDIT: I added links to each of CVE Security Vulnerabilities so you can read their description.
The MD5 hash does not match the website's download page.

In Windows, I coped the zipped trx file to another directory and performed the following command:

certutil -hashfile RT-AC68U_9.0.0.4_386_41994-g769f84f.trx MD5
MD5 hash of RT-AC68U_9.0.0.4_386_41994-g769f84f.trx:
75fe5cd89394e41d177f423d0d991bc2
CertUtil: -hashfile command completed successfully.

However, the download website has MD5 hash code:
5adedb74900fe1cf5958a66d18c6a8e2

Can anyone else confirm my results?
 
The MD5 hash does not match the website's download page.

In Windows, I coped the zipped trx file to another directory and performed the following command:

certutil -hashfile RT-AC68U_9.0.0.4_386_41994-g769f84f.trx MD5
MD5 hash of RT-AC68U_9.0.0.4_386_41994-g769f84f.trx:
75fe5cd89394e41d177f423d0d991bc2
CertUtil: -hashfile command completed successfully.

However, the download website has MD5 hash code:
5adedb74900fe1cf5958a66d18c6a8e2

Can anyone else confirm my results?

Confirmed... MD5s do not match.

I used WinMD5:

WinMD5 Free - Windows MD5 Utility Freeware for Windows 7/8/10

OE
 
OK, fixed now:

Power Management Configuration
Functional Block Status
CPU Wait ENABLED
Ethernet Auto Power Down ENABLED
Energy Efficient Ethernet DISABLED
Switch Deep Green Mode ENABLED (status Deactivated)

I had to reset the RC2-11 firmware to enable CPU wait. Temp is around 82C now. Will check again later. I previously swapped my two nodes around and they yield the same temps so I'm not concerned about individual router build... they are either both ok or both not ok, heatsink-wise.

The dirty upgrade bites again! :)

OE

An anomaly today...

The Wireless Log showed no 2.4 wireless backhaul entry. WiFi Analyzer showed all WLANs up as set. After a System Reboot, WiFi Analyzer showed the remote node 2.4 WLANs moved from CH 11 to CH 1 while the router 2.4 WLANs remained as set on CH 11. I restarted the remote node and all returned to normal. This was the first power cycle of the remote node since uploading RC2-11.

Someone else around here recently mentioned AiMesh using a different band channel on their remote node... which is not by design. Perhaps RC2-11 is having trouble sticking to its channel assignment(?).

Edit: I am using different SSIDs and fixed, non-DFS channels... 11 at 20 MHz and 157 at 80 MHz.

OE
 
Last edited:
An anomaly today...

The Wireless Log showed no 2.4 wireless backhaul entry. WiFi Analyzer showed all WLANs up as set. After a System Reboot, WiFi Analyzer showed the remote node 2.4 WLANs moved from CH 11 to CH 1 while the router 2.4 WLANs remained as set on CH 11. I restarted the remote node and all returned to normal. This was the first power cycle of the remote node since uploading RC2-11.

Someone else around here recently mentioned AiMesh using a different band channel on their remote node... which is not by design. Perhaps RC2-11 is having trouble sticking to its channel assignment(?).

OE
That was me - I've had it quite a few times on 5Ghz and occasionally on 2.4Ghz. The 2.4Ghz has probably only been recent on 386_41535, 386_41700 and this latest beta RC2-11. The 5Ghz behaviour has been around for most of the 386 variants and seems to be related to DFS false positives kicking a single node off channel, then because I'm using fixed channels it doesn't have the ACS service to select a correct channel and keeps flipping around the channel range.

For my own sanity, I'm glad you've reported it as I was beginning to think I was the only one.
 
An anomaly today...

The Wireless Log showed no 2.4 wireless backhaul entry. WiFi Analyzer showed all WLANs up as set. After a System Reboot, WiFi Analyzer showed the remote node 2.4 WLANs moved from CH 11 to CH 1 while the router 2.4 WLANs remained as set on CH 11. I restarted the remote node and all returned to normal. This was the first power cycle of the remote node since uploading RC2-11.

Someone else around here recently mentioned AiMesh using a different band channel on their remote node... which is not by design. Perhaps RC2-11 is having trouble sticking to its channel assignment(?).

OE

I experienced an odd anomaly this afternoon...I reset one of my 68U's that was acting up and when it restarted it came up as a main router/access point with old SSID info that it carried over from my GT-AC5300 before I factory reset everything a few days ago.

I could not get it into "AiMesh" mode through the web UI (it wasn't showing up in the SEARCH box) and I had to access the 68U independently by joining my Samsung S20 phone to the duplicate 2.4 network and an old 5G band it had carried over. Eventually holding down the WPS button and powering the 68U on got it to fully reset. It's running on RC2-11 9.0.0.4.386_41994.

While this flaky 68U decided to flip into AP mode it wreaked havoc on the network...was unable to access my main router for awhile until I brought the 68U down. It was attempting to dish out IP's to wired clients while connected (I use the WAN port for enet backhaul). After resetting it's fine, but it's the strangest behavior I've seen in awhile.
 
Anyone know if this particular message has any significance?

02-01-2021 23:34:49 User.Info 192.168.1.1 Feb 1 23:34:49 GT-AC5300-xxxxx-220D104-C kernel: protocol 0800 is buggy, dev eth7

I see it pop up repeatedly in Syslog. It's an info level debug message but it's strange to see something pop up that frequently.
 
@ASUSWRT_2020 and forum

I bought a RP-AC55 to add to my AiMesh systems AC5300 88U running 386 but
I cannot add the RP-AC55 as a AiMesh node. The RP-AC55 has the latest 384 update.

  • Extend Seamless AiMesh WiFi System - Expand your current AiMesh network to deliver powerful, seamless WiFi and robust functions on AiMesh router to your entire home

Is there any issue?


 
@ASUSWRT_2020 and forum

I bought a RP-AC55 to add to my AiMesh systems AC5300 88U running 386 but
I cannot add the RP-AC55 as a AiMesh node. The RP-AC55 has the latest 384 update.

  • Extend Seamless AiMesh WiFi System - Expand your current AiMesh network to deliver powerful, seamless WiFi and robust functions on AiMesh router to your entire home

Is there any issue?



Hi,
does your AC5300 run on any beta RC version or public release?

What exactly does not work when adding it? Do you can't see it or adding fails in the process?
(WPS is enabled?)

Can only speak for the AC68U (beta & release) + RP-AC55 where AiMesh works, and it works pretty stable ONLY with wired backhaul.

On wireless backhaul the RP messes up the network and DHCP slowly over time - till collapse and devices not connecting (not receiving an IP).
http://www.snbforums.com/threads/as...h-full-functions-aimesh-2-0.65235/post-637698

Still hoping for a 386 build for the RP-AC55.

BR
 
Last edited:
Anyone know if this particular message has any significance?

02-01-2021 23:34:49 User.Info 192.168.1.1 Feb 1 23:34:49 GT-AC5300-xxxxx-220D104-C kernel: protocol 0800 is buggy, dev eth7

I see it pop up repeatedly in Syslog. It's an info level debug message but it's strange to see something pop up that frequently.

Guest Network 1 is broken on various models, you will have to use Guest Network 2 (but lose AiMesh sharing of guest networks).
 
@chichow that model doesn't support AiMesh.
 
@chichow that model doesn't support AiMesh.
If you mean the RP model, it does support AiMesh indeed! (AiMesh 1.0 so far, 386 please!!)
It's the only RP which does it.
No other RP-AC51/53/56/66/87 - just the 55.
And you can get for like 40 bucks which is nice. :)

I have one running as node atm. If it receives AiMesh 2.0 at some point I will buy a ton and put it all over the place where a wall plug is.
 
Last edited:
@Domdus thanks for the correction. :)

You still don't want to 'buy a ton' of them though. There is such a thing as 'too much Wi-Fi' and particularly too many repeaters (which is what wireless AiMesh is).

Repeater mode = wireless AiMesh
 
Hello

Thank you for the replies. This is a screenshot of what I get when attempting to add the RP-AC55

IMG_8077.jpeg
 
Ooops I can't edit my post.

So I attempt to add the RP-AC55 using the AiMesh 2.0 interface. The interface does perform the discovery of Aimesh nodes. It then does show the RP-AC55. Finally I am allowed to select the Rp-AC55 an the percentage wheel of 1% 2% etc. starts to go. Then I end up getting the screenshot above.

Configuration is
RT-AC5300 running Asus Merlin 386.1 as Aimesh master router
RT-AC88U running Asus merlin 386.1 as Aimesh node

attempting to add
RP-AC55 running ASus stock Version 3.0.0.4.384.83130 release date 2020/10/08
please note that since the prior version Version 3.0.0.4.384.80710 with release date 2019/07/17 this model supports aimesh (release notes: first version supports AiMesh node mode, you can work with other AiMesh router.)
RP-AC55 BIOS & FIRMWARE | Networking | ASUS USA
 
From the research I have done before. I had seen that

1) If mixing Asus Merlin and Asus stock, then ensure that Asus merlin is running on the master Aimesh node. Which I have done

at this point I guess the challenge is that the RP-AC55 on the older firmware is AiMesh 1.0

some questions

1) Can I add the RP-AC55 just as a repeater? Should it have the same SID or different?
2) Do I need to have WPS on in order to add it as a AiMesh node? Is there a different way using WPS
 

Sign Up For SNBForums Daily Digest

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