Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[KingBravery]

I tried the latest RC on an AC3100, AC1900P (68U), and an AC68U. I could not get it to work and reverted to the latest Merlin release.

Routing on our network is done by a pfSense box with IPv4 DHCP and IPv6 RA. I could not get wireless clients to get IPv4 addresses via DHCP using the RC firmware and the IPv6 addresses they did receive seemed akin to automatic private addresses (i.e. they didn't allow internet connectivity).

I tried enabling guest networks on 2.4 and 5GHz to see if it would improve matters (as suggested in this thread). But it did not.

The AC1900P paired easily over a wired connection for AiMesh, the AC68U took two attempts. After pairing, AC68U kept losing its connection despite having Ethernet selected.

We have a Cisco switch in the center of the network, FYI.

I hope the situation improves as I'm looking forward to using AiMesh with a guest network on the nodes.

You can help Asus by sending feedback thru router feedback page for each problem including all required logs there. They need logs to repair the broken codes.

 

[Kiwipaul]

is it planned to support the dsl ac68u?

 

[SBSTNGRSS]

Just sharing if this helps to improve and appreciate the beta + the thread and comments here!!!


So a few more details on my setup -> 2 RT-AC88U

AiMesh - Master: latest beta revision : 9.0.0.4.386_39179-gb0f610c
AiMesh Node: 9.0.0.4.386_38936-gab07b3f

This setup kind of works stable on my end as I faced after upgrading the Mesh Node to 9.0.0.4.386_39179-gb0f610c the same 5Ghz connection issue.

And yesterday I had a failure on one of the network ports on the AiMesh Master:

Aug 1 22:14:01 syslog: wlceventd_proc_event(486): wl0.1: Disassoc 00:24:E4:1A:C8:7A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Aug 1 22:15:40 kernel: rtk_port_linkStatus_get() fail, err: 10
Aug 1 22:15:44 rtl_fail: rtkswitch fail access, restart.
Aug 1 22:15:44 kernel: rtk_port_linkStatus_get() fail, err: 10
Aug 1 22:15:46 kernel: rtl8365mbrtl8365mb initialized(0)(retry:0)
Aug 1 22:15:47 kernel: rtk port_phyEnableAll ok
Aug 1 22:15:47 kernel: txDelay_user: 1
Aug 1 22:15:47 kernel: # txDelay - TX delay value, 1 for delay 2ns and 0 for no-delay
Aug 1 22:15:47 kernel: EXT_PORT:16 new txDelay: 1, rxDelay: 1
Aug 1 22:15:47 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 1
Aug 1 22:15:47 kernel: rxDelay_user: 4
Aug 1 22:15:47 kernel: # rxDelay - RX delay value, 0~7 for delay setupEXT_PORT:16 new txDelay: 1, rxDelay: 4
Aug 1 22:15:47 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 4
Aug 1 22:40:33 syslog: wlceventd_proc_event(505): eth1: Auth 58:1F:AA:E6:0B:45, status: Successful (0)
Aug 1 22:40:33 syslog: wlceventd_proc_event(534): eth1: Assoc 58:1F:AA:E6:0B:45, status: Successful (0)


Have a great Sunday everyone!

 

[drabisan]

I decided to give a try to this release.
Install it on top of the working setup. I had to create a guest network over 5GHz to the node to have both 2.4 and 5 working on the node. Same issue as everyone else, not working IPv4 DHCP on node. I can live with that for a week.

Minutes after installing, my 84:f3:eb:83:9f:b3 device was kicked off the network by inactivity issue.
I created a guest network on 2.4, on router only. And configure that device to connect to this SSID. 2 days later device is working properly. I don't know what to say...maybe AiMesh2 tries to roam this device to node? There are no logs saying that. I have no clue why it doesn't work on "normal" SSID, but it works on a guest that offers no roaming.
If, after the next release, things are looking good, I'll try to extend this 2.4 guest to node too and see if roaming is the cause of "inactivity".

 

[--Manu--]

The bug with DHCP should actually have priority for ASUS.

What I also noticed during testing. I have an RT-AX88U with wireless backhaul (5GHz-2) to an RT-AX92U. The only LAN device connected to the RT-AX92U is a Synology NAS (DS 218+).
The Synology NAS "disappears" at shorter, irregular intervals and is no longer accessible. The logs show nothing at all, but the NAS is officially no longer part of my network.
And suddenly ... it is back and fully functional.

Minutes after installing, my 84:f3:eb:83:9f:b3 device was kicked off the network by inactivity issue.
I created a guest network on 2.4, on router only. And configure that device to connect to this SSID. 2 days later device is working properly. I don't know what to say...maybe AiMesh2 tries to roam this device to node? There are no logs saying that. I have no clue why it doesn't work on "normal" SSID, but it works on a guest that offers no roaming.
If, after the next release, things are looking good, I'll try to extend this 2.4 guest to node too and see if roaming is the cause of "inactivity".

This may also be the DHCP problem again ... but if it only affects a single client in this case.
The client connects and wants to get its IP address ... but it is not assigned. No assigned IP address -> no traffic -> AIMesh assumes an inactive client !?

 

[LimJK]

The bug with DHCP should actually have priority for ASUS.

What I also noticed during testing. I have an RT-AX88U with wireless backhaul (5GHz-2) to an RT-AX92U. The only LAN device connected to the RT-AX92U is a Synology NAS (DS 218+).
The Synology NAS "disappears" at shorter, irregular intervals and is no longer accessible. The logs show nothing at all, but the NAS is officially no longer part of my network.
And suddenly ... it is back and fully functional.



This may also be the DHCP problem again ... but if it only affects a single client in this case.
The client connects and wants to get its IP address ... but it is not assigned. No assigned IP address -> no traffic -> AIMesh assumes an inactive client !?

I think there is a fix coming in the next few days according to this post
https://www.snbforums.com/threads/a...h-full-functions-aimesh-2-0.65235/post-606873

 

[LimJK]

Hi ASUS,

Can you consider to include bandwidth Information for each of the wireless client under the new AiMesh GUI.

Reason: While current Graphical icon UI provides some information on signal strength. On some configuration I discovered that my 5GHz bandwidth drops from the usual 80MHz to 20MHz. I have no way of tell this except to use WiFi Explorer on my MacBookPro.

I have sent suggestions via feedback just a moment ago.

 

[LimJK]

Further Observation: Note the changed of MacAddress of 5.0GHz (BSSID) on AiMesh Node, not sure if it has anything to do with devices not having internet access on 5.0GHz AiMesh Nodes.

Working scenario WITH 5.0GHz Wifi Guest Enabled (Have internet access for 5.0GHz devices on AiMesh Node)

AiMesh Node 1 (RT-AC86U)
xx:xx:xx:xx:62:D0 -> 5.0GHz BSSID (*)
xx:xx:xx:xx:62:D1 -> 2.4GHz BSSID
xx:xx:xx:xx:62:D5 -> 5.0GHz BSSID of Guest

AiMesh Node 2 (RT-AC86U)
xx:xx:xx:xx:A9:D8 -> 5.0GHz BSSID (*)
xx:xx:xx:xx:A9:D9 -> 2.4GHz BSSID
xx:xx:xx:xx:A9:DD -> 5.0GHz BSSID of Guest

Failed Scenario WITHOUT 5.0GHz Wifi Guest Enabled (NO internet access for 5.0GHz devices on AiMesh Node)

AiMesh Node 1 (RT-AC86U)
xx:xx:xx:xx:62:D1 -> 2.4GHz BSSID
xx:xx:xx:xx:62:D4 -> 5.0GHz BSSID (*)

AiMesh Node 2 (RT-AC86U)
xx:xx:xx:xx:A9:D9 -> 2.4GHz BSSID
xx:xx:xx:xx:A9:DC -> 5.0GHz BSSID (*)

Hi ASUS,

BSSID MacAddress Bug

Further to my referenced post: additional information of wrong MacAddress of 5.0GHz (BSSID) on AiMesh Node when 5.0GHz Guest Wifi Enabled:

WITH 5.0GHz Wifi Guest Enabled (Have internet access for 5.0GHz devices on AiMesh Node)

AiMesh Node 1 (RT-AC86U)
xx:xx:xx:xx:62:D0 -> 5.0GHz BSSID (*)
xx:xx:xx:xx:62:D1 -> 2.4GHz BSSID
xx:xx:xx:xx:62:D5 -> 5.0GHz BSSID of Guest

WITHOUT 5.0GHz Wifi Guest Enabled (NO internet access for 5.0GHz devices on AiMesh Node)

AiMesh Node 1 (RT-AC86U)
xx:xx:xx:xx:62:D1 -> 2.4GHz BSSID
xx:xx:xx:xx:62:D4 -> 5.0GHz BSSID (*)

In AiMesh Node GUI with 5.0GHz Wifi Guest Enabled:

 

[drabisan]

Hi ASUS,

Can you consider to include bandwidth Information for each of the wireless client under the new AiMesh GUI.

Reason: While current Graphical icon UI provides some information on signal strength. On some configuration I discovered that my 5GHz bandwidth drops from the usual 80MHz to 20MHz. I have no way of tell this except to use WiFi Explorer on my MacBookPro.

I have sent suggestions via feedback just a moment ago.

You can find channel width on logs, under wireless logs, per each radio.
I also prefer a wifi analyzer, but information is presented in the interface.

 

[LimJK]

You can find channel width on logs, under wireless logs, per each radio.
I also prefer a wifi analyzer, but information is presented in the interface.

drabisan,
Thanks. However, the wireless log only shows logs of AiMesh Router, Not available for both my AiMesh Nodes. I thought ASUS could simply add the bandwidth information right on the side of the Wifi icon

 

[drabisan]

drabisan,
Thanks. However, the wireless log only shows logs of AiMesh Router, Not available for both my AiMesh Nodes. I thought ASUS could simply add the bandwidth information right on the side of the Wifi icon

Yeah, indeed. That's why I'm sending syslog to a Synology. And I can't find any reference from a roaming attempt from router to node.
They do add in network map the speed device is using with router/node. Not channel spacing info though. And arguably makes sense: you already "know" channel width from router perspective. Clients will use up to that amount, if they can&need.

 

[grifo]

Hi There,

Here we have new 386 rc2 beta for public test(so the old links are removed).
link: https://drive.google.com/drive/folders/1wvyQ240bX1m2zoP7fFIetofNyh2zp9CF?usp=sharing

Support models:
RT-AC68U -> your are right, this models, this old model, we still support it.

We are also right when we say that it is wrong that you stopped supporting RMerlin for the RT-AC87U which is a newer product than the RT-AC68U, with higher specifications and price, and was sold brand new by Amazon until last year.

We are not asking you to port the new features to it if the hardware can't support them, we are just asking you to provide RMerlin with the binary blobs needed for him to continue supporting it with his firmware, as the stock firmware on its own is of little use to many of us.

We don't expect it to be much effort for you since you have a dedicated team developing the firmware. If RMerlin can do it on his own in his free time then your full time team can too. You are still supporting the RT-AC87U with your stock firmware so it isn't an end of life product and it can't be since people were still buying it new only last year.

By continuing to support RMerlin with RT-AC87U binary blobs, Asus could show their respect for their Merlin customers, the Merlin project and its support forum, which are of substantial value to your company. Let me remind you that for the past several months RMerlin had to come up with workarounds and maintain a separate branch to continue supporting the RT-AC87U and the RT-AC3200 as he couldn't get your support, so that we now are at Merlin version 384.13_10 for these two models.

He is doing this work on his free time and you are the biggest beneficiary of it in terms of dollars, don't you think that the least you could do for him is to fully support him? Instead this is what is going to go down on the Merlin firmware records:

384.13_10 (28-June-2020)
This release will most likely be the last release for the
RT-AC87U and RT-AC3200, due to limited upstream support.

Also please note that the alternative for a lot of us isn't to buy a new Asus router but a Chinese x86 mini PC and run OpenWRT, pfSense or OPNsense on it. Once we've switched to one of those, chances are we're not going to come back to Asus routers.

 

[rickygao]

I have my AX11000, AX92U all updated to this version, reset the factory default, re-setup AIMesh, i have noticed below issues:
1. AX92U cannot add to AX11000 as the AIMesh node in "AIMESH" menu, tried a few times, always unsuccessful.
2. As a result, I have to add AX92U in the "Network Map" menu, it stuck at 0% for a while, and then quickly up to 100%, successful.
3. The AX92U node keep dropping down to 2.4Ghz AIMesh connection after a few hours. reboot back to 5Ghz, and then 2.4Ghz again.
4. 5GHz band keep dropping internet every a few mintues.
5. AP Isolation doesn't work on any of the band.

 

[RMerlin]

We are also right when we say that it is wrong that you stopped supporting RMerlin for the RT-AC87U which is a newer product than the RT-AC68U, with higher specifications and price, and was sold brand new by Amazon until last year.

They did not stop to support me. They simply support the RT-AC87U with a different code base, and I lack the time and motivation to support a separate code base in addition to everything else. And I can't properly support a model that is on a separate release frequency. Asus are not going to change their own business plan just to accommodate me.

Technically, the RT-AC87U is not a newer model. The RT-AC66U_B1 was released only a couple of years ago.

Anyway, this is off-topic.

 

[grifo]

They did not stop to support me. They simply support the RT-AC87U with a different code base, and I lack the time and motivation to support a separate code base in addition to everything else. And I can't properly support a model that is on a separate release frequency. Asus are not going to change their own business plan just to accommodate me.

I see. Then perhaps the "due to limited upstream support" part on the release notes should be changed.

Technically, the RT-AC87U is not a newer model. The RT-AC66U_B1 was released only a couple of years ago.

Anyway, this is off-topic.

The fact that there is an upgraded version of an older model, with a different model number, doesn't make the older model newer.

I guess this is the end of the RT-AC87U for Merlin firmware then. It's off to pfSense for me.

/OT

 

[RMerlin]

Then perhaps the "due to limited upstream support" part on the release notes should be changed.

The changelog is accurate. Upstream support for this model is limited, as it no longer receive as frequent updates as newer models. It`s support toward the model, not support toward me.

The fact that there is an upgraded version of an older model, with a different model number, doesn't make the older model newer.

But it does make this model still more relevant in terms of popularity and market share. Look at the firmware download counts to see why Asus still provides more active support for the RT-AC68U than the RT-AC87U, from the last week:

Marketing-wise, you provide support for your most popular products - it's just common sense. Also, the RT-AC87U has numerous technical limitations that do not apply to the RT-AC68U, due to its Quantenna implementation. This prevents for instance supporting newer features like AiMesh, it also limits other features like guest client support. And Quantenna itself has EOLed their own support for the chip, which further limits Asus' ability to support that model.

Note that Netgear's own Quantenna-based model lost COMPLETE support about three years ago. In that period, Asus has released many RT-AC87U firmware updates, the latest being only a few months old. They still support that model, to the extent of what they are able to do.

And that support just isn't usable for my very special needs, hence I had to completely drop it, after keeping it on life support for so long. Myself and an Asus engineer did actively TRY to continue supporting it, by providing me with specially compiled components. It just didn't work properly, our respective code bases are too different now to be compatible, so rather than me devoting more time into this 7 years old model, I decided to focus on other things.

 

[grifo]

OK. My understanding from both the changelog (the "lack of upstream support" and the "most likely the last release" bits) plus some of your previous posts was that you weren't getting updated binary blobs from Asus as the engineer who had previously done them for you no longer had the time to do them.

If you're now saying that you both tried but it wasn't technically possible so you decided to drop the model for good that's a pretty different story.

 

[RMerlin]

Threaded cleaned up. Please move on, and stick to this thread's topic, namely Asus's beta firmware.

 

[Ryu Connor]

Just sharing if this helps to improve and appreciate the beta + the thread and comments here!!!


So a few more details on my setup -> 2 RT-AC88U

AiMesh - Master: latest beta revision : 9.0.0.4.386_39179-gb0f610c
AiMesh Node: 9.0.0.4.386_38936-gab07b3f

This setup kind of works stable on my end as I faced after upgrading the Mesh Node to 9.0.0.4.386_39179-gb0f610c the same 5Ghz connection issue.

And yesterday I had a failure on one of the network ports on the AiMesh Master:

Aug 1 22:14:01 syslog: wlceventd_proc_event(486): wl0.1: Disassoc 00:24:E4:1A:C8:7A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Aug 1 22:15:40 kernel: rtk_port_linkStatus_get() fail, err: 10
Aug 1 22:15:44 rtl_fail: rtkswitch fail access, restart.
Aug 1 22:15:44 kernel: rtk_port_linkStatus_get() fail, err: 10
Aug 1 22:15:46 kernel: rtl8365mbrtl8365mb initialized(0)(retry:0)
Aug 1 22:15:47 kernel: rtk port_phyEnableAll ok
Aug 1 22:15:47 kernel: txDelay_user: 1
Aug 1 22:15:47 kernel: # txDelay - TX delay value, 1 for delay 2ns and 0 for no-delay
Aug 1 22:15:47 kernel: EXT_PORT:16 new txDelay: 1, rxDelay: 1
Aug 1 22:15:47 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 1
Aug 1 22:15:47 kernel: rxDelay_user: 4
Aug 1 22:15:47 kernel: # rxDelay - RX delay value, 0~7 for delay setupEXT_PORT:16 new txDelay: 1, rxDelay: 4
Aug 1 22:15:47 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 4
Aug 1 22:40:33 syslog: wlceventd_proc_event(505): eth1: Auth 58:1F:AA:E6:0B:45, status: Successful (0)
Aug 1 22:40:33 syslog: wlceventd_proc_event(534): eth1: Assoc 58:1F:AA:E6:0B:45, status: Successful (0)


Have a great Sunday everyone!

That error log is eerily similar to my AC88U router and media bridge failings.

 

[888Jay]

I have an AC88U in which the 2.4 GHz radio died about 15 minutes after the warranty expired. Still, I liked it so much that I bought a second unit and put the old one on the shelf as an emergency backup.

If I set up the one with the dead 2.4 radio as the main router in the basement server room, and the fully functional unit as an AiMesh 2.0 node (with Ethernet backhaul) in my wife's ground floor office, that should work fine in spite of the dead radio, right? My goal is to have an accessible USB port on the node for connecting to an SSD backup drive in the gun safe (which is next to her office).

TIA