[ 388.2 alpha Build(s) ] Testing available build(s)

[zaquintar]

Running 388.2_alpha2-g099892a1cf on AXE16000. Can confirm issue with 2.4ghz and 6ghz radio is gone (prev, devices connecting to the 2.4ghz radio would have no exit to internet). Had already seen it work in stock image, glad to see the gpl merge brought the fix to Merlin.

OpenVPN to connect clients to the router seems to work fine without any changes to the config.

Now I also see the 10sec delay to load aiMesh stats and also a weird UI issue where clicking on the Add-ons menu at the bottom opens up the Firewall page instead. Can't access spdmerlin through the GUI because of this, although it is fine through amtm.

 

[Spc]

ASUS RT-AX86U (Original version):
Firmware:388.2_alpha2-g099892a1cf
Mode: WiFi 6 access point with LACP enabled.

This new alpha release fixed channel bandwidth for me.
388.1 had an issue where i would select channel 36/160 and it would stay at 36/160 for few hours, after this it switched to 36/80 and unless i restarted the router did not go back to 160MHz.
I also had forced it to 160MHz only in 5GHz settings.
Even after restart it stayed again on 80MHz after few hours.
Channel 36/160 was also always cleared for radar but at the same time while cleared for radar was showing 36/160 channel already switched to 36/80.

HR also did not help this issue on 388.1

This new alpha release is good because it always stays at 160MHz ( 36/160 in both, cleared for radar and actual channel).

 

[spykos]

This as nothing to do with this alpha2 version but is caused by the latest Entware packages update made available yesterday. Therefore I am assuming that you have Entware running on your router.

yes this is correct. Did not notice at the time of upgrading. Will wait for Entware to fix then.

 

[XIII]

Works for me. I configured IPSEC on a GT-AX6000 running 388.2 alpha, entered a pre-shared key, added a user, then I configured the connection on my Samsung tablet. It connected without any problem. Try configuring it with a different browser.

Thanks for testing!

So far I have been using Firefox on a Windows 10 PC to do this.

I will try Safari on macOS Ventura this weekend and report back.

 

[Damit1]

LOL.
Just reset my AiMesh Nodes after a full network breakdown, the ASUS app stuck in AiMesh page, takes way longer than should to watch client list.

I hope this bug is not in the GPL itself, so it can be fixed by @RMerlin
If not, I hope ASUS can send a patch that could fix it prior Beta.

 

[RMerlin]

So far I have been using Firefox on a Windows 10 PC to do this.

I was also using Firefox for my test (I believe - I do most within-lan testing with Firefox due to Chrome's broken handling of self-signed cert).

You can try opening the browser console before loading the page to see if there`s any JS error preventing it from saving. Also make sure the /jffs partition isn't full, as that's where the IPSEC settings are stored. You could try resetting IPSEC settings by deleting the /jffs/nvram/ipsec* files, as well as the content of /jffs/ca_files/ .

 

[RMerlin]

I hope this bug is not in the GPL itself, so it can be fixed by @RMerlin

Anything related to the mobile app is outside of my control, since it's a separate application.

The webui delay is already fixed on my end, it was the webpage failing to validate the firmware version of nodes (a function from general.js was no longer being correctly imported by the AiMesh topology page).

 

[jsmiddleton4]

RT-AX86U_388.2_alpha2-g099892a1cf

Running great. Previous 388 versions I had wireless drops. Two days on this alpha and not one drop.

 

[DJones]

ASUS RT-AX86U (Original version):
Firmware:388.2_alpha2-g099892a1cf
Mode: WiFi 6 access point with LACP enabled.

This new alpha release fixed channel bandwidth for me.
388.1 had an issue where i would select channel 36/160 and it would stay at 36/160 for few hours, after this it switched to 36/80 and unless i restarted the router did not go back to 160MHz.
I also had forced it to 160MHz only in 5GHz settings.
Even after restart it stayed again on 80MHz after few hours.
Channel 36/160 was also always cleared for radar but at the same time while cleared for radar was showing 36/160 channel already switched to 36/80.

HR also did not help this issue on 388.1

This new alpha release is good because it always stays at 160MHz ( 36/160 in both, cleared for radar and actual channel).

View attachment 48625

Is LACP (link aggregation 802.3ad) actually working for you? When I used it on 388.2 alpha 2 on my GT-AX11000 it wasn’t actually working beyond one Ethernet functioning in a non LACP bonded state. Might be a device specific issue not sure, but LACP works fine on 388.1.

 

[FLA_NL]

Dirty upgrade on RT-AX86U from 388.1 to 388.2_alpha2-g099892a1cf everything seems to be working. No reconfiguring and no issues with OpenVPN Client/Server after upgrade.

 

[chris.at]

Bandwidth Monitor stops working on AX86U shortly after reboot (stays at 0). This was already the case with 388.1 but still persists.

 

[Samuel_1975]

Well, I wonder when the alpha2 will come for the rt ax86u Pro, as I don't see it on the website yet, but the regular one is available for the rt ax86u

Just want to know as it works fine on rt ax86u but don't have it on Pro yet

Maybe get to the beta version instead but just wondering

Have a good evening

 

[RMerlin]

Asus put an engineer on the case of AiMesh wireless node discovery, which they troubleshooted and provided me with a solution. It will now work for all models (while previously it was only working for some).

 

[eclp]

Bandwidth Monitor stops working on AX86U shortly after reboot (stays at 0). This was already the case with 388.1 but still persists.

View attachment 48631

The dcd tainted error is probably responsible for this. Check the log.

 

[chris.at]

No TrendMicro stuff enabled if you mean this with your hint? Also nothing found in logs (I don't use entware, flexqos, etc...)

 

[XIII]

I was also using Firefox for my test (I believe - I do most within-lan testing with Firefox due to Chrome's broken handling of self-signed cert).

You can try opening the browser console before loading the page to see if there`s any JS error preventing it from saving. Also make sure the /jffs partition isn't full, as that's where the IPSEC settings are stored. You could try resetting IPSEC settings by deleting the /jffs/nvram/ipsec* files, as well as the content of /jffs/ca_files/ .

I tried these:

• Firefox on Windows 10
• Safari on macOS Ventura
• Firefox on macOS Ventura
• DuckDuckGo on iPadOS

They all fail (without anything useful in the console). Key is empty after counter reaches 100%.

I then tried a super simple key ("test1234") instead of the strong key I have been using in the 386 firmware on my AC86u (and which I saved in a password manager).

That one worked immediately...

Did ASUS disallow any characters in 388, or is this a bug of not properly handing special (ASCII) characters?

(the UI does not complain about that key; it actually shows a green bar below it to show it's good)

 

[Tech9]

Asus put an engineer on the case of AiMesh wireless node discovery, which they troubleshooted and provided me with a solution. It will now work for all models (while previously it was only working for some).

This is excellent news @RMerlin, but when I was talking about Wi-Fi stability issues and AiMesh wireless node discovery issues there was a total denial defensive reaction plus I was called names by the fans around and my findings were swept under the carpet. Later we got fixed by Asus firmware with better Wi-Fi and now we have an Asus engineer looking for AiMesh wireless node discovery solution. I really hope the time I've spend in testing and reporting was not totally wasted and contributed somehow to this fixing process and the final result will make users' life a bit easier. This was the goal to begin with and the quote above is an excellent answer to your own question "What do you want from me?"... you did more than I wanted or expected.

Thank you!

 

[RMerlin]

This is excellent news @RMerlin, but when I was talking about Wi-Fi stability issues and AiMesh wireless node discovery issues there was a total denial defensive reaction

My answer at the time was that these were things outside of my control, and therefore there was nothing I could do about them. And that still holds true. Wifi issue were just resolved by an updated version that came out later. And for the AiMesh onboarding issue, it's because someone at Asus decided to go beyond my own expectations and looked into it, going as far as providing the solution. Constantly pushing me about these issues by refusing to accept my answer that "I can't do anything about them" only serves in annoying me, especially after the 100th time I get the same complain.

BTW, the AiMesh onboarding issue only happened with some model combinations, and it happens that in the past, every time I created an AiMesh network to work on something related to it (usually the handling of FW updates for nodes), it was working just fine for me. Also: there is a switch to enable debugging in AiMesh's onboarding process, but it requires recompiling the closed source components, which I cannot do...

So again: constantly asking me to look into something and rejecting my reply that "I can't" will accomplish nothing beside increase my level of frustration. And I have enough things already frustrating me relative to this project, I don't need additional stuff piling up on top of it.

 

[jrichard326]

Dirty Upgrade from alpha1 to alpha 2 on RT-AX86U. When the GUI came back up after the upgrade the RT-AX86U was now in Access Point (AP) Mode. Before the upgrade it had been in Wireless Router Mode. I reset my main router, RT-AX86U to Wireless Router Mode, but now my RT-N66 that I use as a repeater was not available anymore. During these upgrades am I supposed to disconnect the repeater before the upgrade? I had to reset the RT-N66 via webUI and all is well again. Thank you for all the work that goes into this project.

 

[RMerlin]

That one worked immediately...

Did ASUS disallow any characters in 388, or is this a bug of not properly handing special (ASCII) characters?

(the UI does not complain about that key; it actually shows a green bar below it to show it's good)

No idea if they changed anything there, but some special characters have always been tricky with Asuswrt's webui in general. I would avoid any characters that carry a special meaning in an HTML context, such as %$<>.

I guess the page could do a better job at validating that field. Which characters were you trying to use?