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

[Tech9]

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.

You are the only one in position to ask Asus upstream what changes in your firmware may cause AiMesh issues. The fact someone recognized the issue now and is working on a fix is much better than "works for me" and "outside of my control". Let's forget the heated conversations and move forward. Don't take issues reports as complaints. At the end of the day the entire community benefits from the better firmware. Looking forward to 388.2 release.

 

[bluepoint]

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

Just turn Apps analysis on.

 

[XIII]

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?

I will experiment to find out which character it is, but can’t do that today or this weekend.

I hope to report back later next week.

 

[Deleted member 84281]

Just updated to the new 388.2 A2 AX86S. Working very well. Thank You @Merlin

 

[Damit1]

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).

@RMerlin , Latest Alpha 388.2_alpha2-g099892a1cf is installed on all nodes, and even checked myself again, tested 3 different browsers and 3 different PCs.
Just to make 100% sure- reset my router, and all nodes to make certain no cache from 388.1 is left.
Still same issue with AiMesh page...

Would appreciate if you run another check-up about it.

 

[kernol]

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).

@RMerlin , Latest Alpha 388.2_alpha2-g099892a1cf is installed on all nodes, and even checked myself again, tested 3 different browsers and 3 different PCs.
Just to make 100% sure- reset my router, and all nodes to make certain no cache from 388.1 is left.
Still same issue with AiMesh page...

Would appreciate if you run another check-up about it.

I think you have misunderstood @RMerlin when he says

The webui delay is already fixed on my end,

He means he has patched HIS code to fix the issue - but that does not mean he has re-complied and released a fixed version yet. You are still testing the Alpha 2 BEFORE he fixed it on HIS system. Patience ... and rest assured that the issue will be fixed when the next RELEASE version is made available .

 

[ZANGIEF]

The delay on the AiMesh page is fixed in this commit.
It is html, so you may be able to connect via SSH and edit it with vi.
/www/aimesh/aimesh_topology.html

 

[Damit1]

I think you have misunderstood @RMerlin when he says


He means he has patched HIS code to fix the issue - but that does not mean he has re-complied and released a fixed version yet. You are still testing the Alpha 2 BEFORE he fixed it on HIS system. Patience ... and rest assured that the issue will be fixed when the next RELEASE version is made available .

I trully misunderstood, I thought it was on his latest Alpha, my bad!
Thank you for explaining, I thought Im missing something here.

Thanks!

 

[matthew johnson]

Correct. Yellow, in general, means connected speed is less than router port max speed.

Question: If your modem port is "only" 2.5 Gbps, why don't you connect it directly to the GT-AXE16000 2.5 Gbps WAN port (default) as opposed to reconfiguring one of the 10 Gbps ports (which, of course, will only connect at 2.5 Gbps)?

Basically because of where the wires are laid out in my area where the router and modem is

 

[kernol]

You are the only one in position to ask Asus upstream what changes in your firmware may cause AiMesh issues. The fact someone recognized the issue now and is working on a fix is much better than "works for me" and "outside of my control". Let's forget the heated conversations and move forward. Don't take issues reports as complaints. At the end of the day the entire community benefits from the better firmware. Looking forward to 388.2 release.

Just for the record - this "AiMesh issue" does NOT exist in Asus stock code 3.0.0.4.388_22525 . I am running Asus Stock on both my RT-AX86U's under AiMesh with zero problems. Also worth noting that under stock code my WiFi 6 devices stick at 160MHz with consistent speeds of 2402M - great for inter-LAN backups and file syncs.

I am really pleased that Asus has released a stable version 388.22525 across most, if not all, of the AX Routers supported by @RMerlin. This provides a far better foundation for him to ad his wizardry - and will no doubt result in a super steady final release much like his version 386.5_2 which was also based on a consistent stock version across most models.

Looking forward to 388.3 Release Version so I can return to my favourite add-ons [Diversion and Skynet} and re-deploy VPN Director.

 

[Tech9]

Just for the record - this "AiMesh issue" does NOT exist in Asus stock code 3.0.0.4.388_22525

The issue I was talking about for a long time is wireless node discovery in Asuswrt-Merlin firmware. This is what wasn't working properly since AiMesh 2.0 introduction in 386 firmware released >2 years ago. Finally someone is looking into it and perhaps a fix is coming with future Asuswrt-Merlin versions. 388_22525 is better base, but still has some broken features like Traditional QoS and Bandwidth Limiter with IPv6 enabled. Asus says Client List is fixed as well, but I recently played with AdGuard Home on x86 mini-ITX board running Ubuntu server and static IP assigned - it shows briefly and disappears until next router reboot. But this is something I've seen before with static IP devices. Something is off around Instant Guard as well - it doesn't always connect. OpenVPN Server doesn't have this issue. I have nothing to test WireGuard with yet. GUI bug in Wireless Professional, Tx Power slider is also still there. Internet Speed Test is still crashing. Traffic Analyzer stopped working once already during relatively short uptime. So... yeah - better, but needs work.

 

[RMerlin]

It is html, so you may be able to connect via SSH and edit it with vi

Firmware partition is read-only.

 

[RMerlin]

Looking forward to 388.3 Release Version

What makes you think that something will be wrong with 388.2?

 

[kernol]

What makes you think that something will be wrong with 388.2?

I thought your .2 releases were test/alpha/beta ones with .odd numbers being reserved for full "Release" versions - wrong asuumption I guess. Not really fussed what numbering conventions may [or may not] be used. Just looking forward to your next full release.

 

[RMerlin]

I thought your .2 releases were test/alpha/beta ones with .odd numbers being reserved for full "Release" versions - wrong asuumption I guess. Not really fussed what numbering conventions may [or may not] be used. Just looking forward to your next full release.

No. The "beta" status is indicated on the extended version, not the point release

Major.Minor_ExtendedVersion

388.2_alpha2, followed by 388.2_beta1, which will be finalized as 388.2_0 (the router will hide the _0 to keep things simpler).

If I need an extra point release for bugfixes, then I start using an odd extended_version (388.2_1), which will be followed by a 388.2_2 final. This is because I cannot have, say, 388.2_2-beta1

All of this will probably have to be thrown out of the window at some point this year when Asus moves from 3.0.0.4.388_xxxxx to 3.0.0.6.110_xxxxxx. I visibly can't go from, say, 388.5 to 110.1. Not quite sure I feel like going back to Asus' own numbering scheme with 3.0.0.6.110_1 either. Because it's long and hard to remember (which was why I dropped it years ago), and also how will users know if 3.0.0.6.110_1 is older or newer than 388.1.

I could stop following their numbering scheme and jump to 400.1. But then some software components might not recognize that Major version number, causing other issues.

Who would have thought that version numbering schemes could be such a headache...

 

[JIPG]

I thought your .2 releases were test/alpha/beta ones with .odd numbers being reserved for full "Release" versions - wrong asuumption I guess. Not really fussed what numbering conventions may [or may not] be used. Just looking forward to your next full release.

I think you were confused with the minor versión numbering (like 386.8_2 or 388.2_4 ), where only even number are used for final releases.

 

[chris.at]

Just turn Apps analysis on.

Never turned on before, also displaying values right after a reboot.

Nobody else with AX86U seeing permanent 0 on bandwidth monitor after a while? Traffic Analyzer and Network Map both present up and down values the whole time.

QoS enabled with cake, nothing else tweaked.

No real priority on this. Just wanted to report a bug that maybe could get fixed.

 

[brummygit]

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).

Does this mean that running your firmware on the nodes will be preferred until Asus stock catches up, or is it only relevant on the main router?

 

[Mvn39]

No. The "beta" status is indicated on the extended version, not the point release

Major.Minor_ExtendedVersion

388.2_alpha2, followed by 388.2_beta1, which will be finalized as 388.2_0 (the router will hide the _0 to keep things simpler).

If I need an extra point release for bugfixes, then I start using an odd extended_version (388.2_1), which will be followed by a 388.2_2 final. This is because I cannot have, say, 388.2_2-beta1

All of this will probably have to be thrown out of the window at some point this year when Asus moves from 3.0.0.4.388_xxxxx to 3.0.0.6.110_xxxxxx. I visibly can't go from, say, 388.5 to 110.1. Not quite sure I feel like going back to Asus' own numbering scheme with 3.0.0.6.110_1 either. Because it's long and hard to remember (which was why I dropped it years ago), and also how will users know if 3.0.0.6.110_1 is older or newer than 388.1.

I could stop following their numbering scheme and jump to 400.1. But then some software components might not recognize that Major version number, causing other issues.

Who would have thought that version numbering schemes could be such a headache...

Since Asus' nomenclature is moving up from 3.0.0.4.xxx to 3.0.0.6.xxx, maybe you can consider just adapting one number prior for your future releases. Can move from 388.2_xx to 6.110_xxx when they migrate to that scheme later. The "6" in front can help identify it to be a later release than the 388.2_xx and previous ones. Even if they keep going to 3.0.0.7.xxx, you are okay as well. If they rehash it to something completely new in the future, no need to worry about it again until then.

I hope this makes sense and can help you manage Asus' very inefficient numbering scheme somehow. You do great work and need not be bother by this...

 

[bluepoint]

Never turned on before, also displaying values right after a reboot.

Nobody else with AX86U seeing permanent 0 on bandwidth monitor after a while? Traffic Analyzer and Network Map both present up and down values the whole time.

QoS enabled with cake, nothing else tweaked.

No real priority on this. Just wanted to report a bug that maybe could get fixed.

It isn't a bug. That default value of being off started since 388. If you were upgrading on top of previous versions the App analysis stays to its present settings. The default off will present itself once you set the router to factory defaults.