Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[RMerlin]

RMerlin is there an easy way ti check what client cloud be doing that? My DNS setting seems to work properly it must be something else

Thanks for your help

Maybe check with netstat on each of your clients, see who is generating a lot of outbound connections to port 53.

 

[BeeJayVee]

Well, although I really like some of the new features of RC2-6, I'm going to have to revert back to the released firmware for now. I'm getting too many instances of laptop and phone clients both getting dropped, and I also found that even though I manually set the channels for all bands, one time I found that the 2.4 band and the 5G-1 band either had some nodes (5G-1) or all nodes (2.4G) on the wrong channel (don't know if that is related to the clients being dropped). In addition, it's hard to change settings in the GUI, because in many cases a settings change causes the GUI to crash, requiring a main router reboot, so it takes forever to set up the network the way I want to.

But when the next build is made available I'll consider trying it. The new features are too good not to try.

Well, I said I was going back to stock firmware from RC2-6, but as I was writing that it turned out that RC2-7 was in the process of being released. So I tried it with a full, clean installation on all nine routers and set up my AiMesh network from scratch. There is much improvement of the features and functionality, but I still had too many instances of clients being dropped (requiring a NIC reset to fix), and the issue of the two-channel routers using the three-channel routers' backhaul (dwb) channel for fronthaul is still present (although I wasn't really expecting this issue to be fixed so soon after I reported it), so after a few days I went back to the latest released firmware.

A side note on the "fronthaul on the backhaul channel" issue: The AiMesh 2.0 FW does have the feature in that I could disable the 5GHz radios on the RC-AC86U routers individually so that they wouldn't cause interference on the dwb channel, but this is only of limited usefulness, as speeds on 2.4GHz are slow compared to 5GHz. If the ASUS team ends up not fixing this issue with AiMesh 2.0 I'll probably just sell off the RT-AC86U routers and stick with the three-channel routers (GT-AC5300 and RT-AC5300) only. Network stability using only three-channel routers is actually pretty good with wireless backhaul.

 

[Swiftnc]

So with RC6, even after a clean


So I tried a full reset, and that did not solve the issue. I then upgraded to RC7, same issue. I have moved DHCP back to the ASUS router to see if that resolves the issue.

Even with DHCP back on my Asus Router, the issue remains. After a day or so you are unable to get an DHCP IP from the mesh node until you reboot all routers (including primary). Anyone else having this issue?

 

[OzarkEdge]

Even with DHCP back on my Asus Router, the issue remains. After a day or so you are unable to get an DHCP IP from the mesh node until you reboot all routers (including primary). Anyone else having this issue?

Nope. After a clean install and when it should just work normally and doesn't, then I tend to suspect failing hardware. But if a previous firmware still works fine, then maybe not hardware.

OE

 

[basia]

rc2-7 for clarify.

I try upload via my master mesh - ax88 and directly login in ax55. It's possible to rc2-7 is broken for ax55? I recive new ax55 from amazon and may return it..... Please check...

 

[Slawek P]

Hi, does anybody know more about correct settings of wl1_wmf_bss_enable and its meaning. I noticed my AiMesh router has 0 while my AiMesh node has 1. Not even sure where WebUI is for this setting. Might have to do do factory reset on both..

 

[yamvmax]

So I like the firmware thus far on my GT-AX11000 and RT-AX92U, great work guys. Would it be possible to request an AiMesh timed/scheduled access function?

For example, I want a specific device to be on Node 1 from 10PM to 11AM and then on Node 2 from 11:01AM to 9:59PM. My house is just big and small enough that I can be sitting two feet in front of Node 2 (AX92U) with my phone and still be connected to Node 1, I basically want to force it between the two on a schedule (upstairs by Node 2 during the day in the office, on Node 1 at night/morning in the bedroom which is closer to Node 1).

I set mine up to disconnect anything lower than 65db, and my clients reconnect to the higher node instantly

 

[livefeed]

I set mine up to disconnect anything lower than 65db, and my clients reconnect to the higher node instantly

Would you mind posting a pic of your settings for that?

 

[yamvmax]

Would you mind posting a pic of your settings for that?

Roaming assist, do it on both wifi frequencies.

 

[dsring]

For those of you that have it flashed to the RT-AX86U, how is this firmware performing compared to the .384 series firmware?

 

[bones5050]

For those of you that have it flashed to the RT-AX86U, how is this firmware performing compared to the .384 series firmware?

Been rock solid... Much better wifi and overall stability. There a still a few minor bugs but overall a nice improvement over .384

 

[KrispiL]

First major issue I've had with RC2-7 on an AX88U (main router) with AX92U (mesh node via 5G backhaul).

Lost all connectivity to router and WAN light was red, had to reboot which fixed the issue. The logs are full of these errors for when the problem happened:

Oct 29 16:58:39 kernel: ^[[0;33;41m[ERROR pktrunner] runnerL2Ucast_refresh_pathstat,301: runnerL2Ucast_refresh_pathstat: Could not get pathIdx<13> stats, rc -5^[[0m
Oct 29 16:58:39 kernel: ^[[0;33;41m[ERROR pktrunner] runnerRefreshPathStat,336: Could not get pathIdx<13> stats, rc -5^[[0m
Oct 29 16:58:39 kernel: ^[[0;33;41m[ERROR pktrunner] runnerL2Ucast_refresh_pathstat,301: runnerL2Ucast_refresh_pathstat: Could not get pathIdx<6> stats, rc -5^[[0m
Oct 29 16:58:39 kernel: ^[[0;33;41m[ERROR pktrunner] runnerRefreshPathStat,336: Could not get pathIdx<6> stats, rc -5^[[0m
Oct 29 16:58:39 kernel: ^[[0;33;41m[ERROR pktrunner] runnerL2Ucast_refresh_pathstat,301: runnerL2Ucast_refresh_pathstat: Could not get pathIdx<5> stats, rc -5^[[0m
Oct 29 16:58:39 kernel: ^[[0;33;41m[ERROR pktrunner] runnerRefreshPathStat,336: Could not get pathIdx<5> stats, rc -5^[[0m
Oct 29 16:58:39 kernel: ^[[0;33;41m[ERROR pktrunner] runnerL2Ucast_refresh_pathstat,301: runnerL2Ucast_refresh_pathstat: Could not get pathIdx<11> stats, rc -5^[[0m
Oct 29 16:58:39 kernel: ^[[0;33;41m[ERROR pktrunner] runnerRefreshPathStat,336: Could not get pathIdx<11> stats, rc -5^[[0m
Oct 29 16:58:40 kernel: ERR: read_stat_from_hw#387: status:Internal error can't read RDD port 'wan0' PM counters, error = 120
Oct 29 16:58:40 kernel: port_runner_rdp_drop_stats_get:L1250 can not get stat port port_0:3 eth0

Not sure if it's firmware related or an issue with the WAN link (uses PPPoE) but I've not seen these errors before when the WAN link has gone down.

 

[Moabdave]

Edit: I added "custom_clientlist" that maps USER DEFINE DEVICE NAME to MAC ADDRESS, whereas the "dhcp_staticlist" maps MAC ADDRESS to USER ASSIGNED IP ADDRESS.

Thank you for this, as the custom client list does not carry across when using the GUI export and import config tool, so even if I give up on beta testing, this is a good thing I can use.

 

[Andy1932]

Been rock solid... Much better wifi and overall stability. There a still a few minor bugs but overall a nice improvement over .384

QOS seems to be broken for me with RC2-7. Also with the latest stable release(3.0.0.4.384.9318).
EDIT -- RT-AX86u

 

[ginny]

@ASUSWRT_2020

I see on the official download page from ASUS the AiMesh 2 build Version 3.0.0.4.386.40451 from Oct. 22nd 2020. The latest RC2-7 has with 386.40577 a higher build number. From which Beta 386.xxxx version is the official firmware derived?

Further I see not all routers which where supported within the 386 rc2-7 Beta stream where applied with the official 386 Firmware. E.g. the Router RT-AC5300 is missing and has still the 384 Firmware in the official download page. is an update onto an official 386 build planned for all models which were supported in the 386 Beta stream?

 

[TheJesus]

I set mine up to disconnect anything lower than 65db, and my clients reconnect to the higher node instantly

I did try that, but kept having other clients drop when I didn't want them to. I'll give it another shot.

 

[drabisan]

@ASUSWRT_2020

I see on the official download page from ASUS the AiMesh 2 build Version 3.0.0.4.386.40451 from Oct. 22nd 2020. The latest RC2-7 has with 386.40577 a higher build number. From which Beta 386.xxxx version is the official firmware derived?

Further I see not all routers which where supported within the 386 rc2-7 Beta stream where applied with the official 386 Firmware. E.g. the Router RT-AC5300 is missing and has still the 384 Firmware in the official download page. is an update onto an official 386 build planned for all models which were supported in the 386 Beta stream?

384 is not derived from 386. 386 is another branch and it's currently in beta.
Check the first post of this topic. There's a link and images for all models that are supported, including RT-AC5300.
Yes, at one moment in the future 386 will become an official release and it will be published on official support page for each router. It's not known when that will happen. So for now it's in beta.

 

[VANT]

384 is not derived from 386. 386 is another branch and it's currently in beta.
Check the first post of this topic. There's a link and images for all models that are supported, including RT-AC5300.
Yes, at one moment in the future 386 will become an official release and it will be published on official support page for each router. It's not known when that will happen. So for now it's in beta.

No drabsan, 3.0.0.4.386.40451 is official fw for AT-AC86u and AX92U

 

[Ravnasa]

I updated both my ZenWiFi XT8 a while back with rc4 linked here and have been looking to update the firmware again when this forum deemed a new version more stable, because I have had a lot of problems with disconnections etc like many others.
I updated the main unit this morning without issue, but when I want to update the other mesh unit it won't let me connect to it.

I login via my browser and go to the firmware update page, and when I choose to manually update the firmware for the secondary unit a popup window shows that the connection is refused, so I don't even get far enough along to select which firmware file I want to try to update it with.
I thought that maybe this was because I updated the main unit first to rc7 and then somehow they couldn't cooperate properly longer, so I downgraded the main unit back to rc4 with the plan to update the secondary unit first to rc7.
However this didn't change anything, I still can't select a file to update the secondary unit with.
I've also tried updating the main unit with the latest official firmware but this didn't change anything either.
I've tried rebooting both units, no change.

I see that the secondary unit is working as normally though and connecting units, allowing them network and internet access so besides from not being able to update the firmware it is working as expected.
So, it definitely backhauls properly to the main unit and they seem to work together in all aspects.

Any idea on what I can do next to update the firmware on the secondary unit?

 

[drabisan]

No drabsan, 3.0.0.4.386.40451 is official fw for AT-AC86u and AX92U

I see! Possibly Asus believes we're getting very close for 386 to become official release.
And I tend to agree. My setup is as stable as it was on 384 plus additional features added by 386