What's new

386.5 Alpha1?

  • 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!

You're talking about the second Alpha release in the above?
That was the first drop of RT-AX88U Alpha. Upgrading the RT-AX86U AP now with the new Alpha 1....

EDIT: And filthy upgrade of the RT-AX86U AP is done. All good so far. Time for a coffee...
 
Last edited:
Filthy upgrades in progress now on my RT-AX88U APs... let's GOOOOOOOOOOOOO!!!!

EDIT: Upgrade looks good, Nest/IOT/TP-Link devices all seem happy for now... will monitor during the day. So far so good.

I have been patiently waiting for two things:
  1. Release of 386.5 alpha for AX88U.
  2. @shabbs to install it and report back on Nest/IoT connectivity (relative to 386.4 and 386.3) - some though not all of my Nest cameras and other IoT devices have been up and down like yoyo's since 386.4, unfortunate as everything else appears rock solid.
Previously I jumped on all the betas, occasionally an alpha too if it solved a specific issue, though recently I've taken a more relaxed "wait for final release" attitude - however in this instance, specifically due to the 386.4 Nest/IoT connectivity issues (obviously inherited from the Asus GPL of the day) I may well be tempted to move quickly to this alpha.

I look forward to your further observations, thanks :)

nb. almost certain we have been experiencing the same AX88U 386.4 issues, as I noticed the pattern of the Nest cameras bound to my AiMesh nodes (due to physical layout) running the latest stock firmware (more recent GPL) weren't having any problems whereas those connected to the AX88U Merlin 386.4 were.
 
Last edited:
So I ask which way is the right way @RMerlin, to show the IGMP entry in the routing table or not to?
No idea, I don't deal with anything related to IPTV.
 
I have been patiently waiting for two things:
  1. Release of 386.5 alpha for AX88U.
  2. @shabbs to install it and report back on Nest/IoT connectivity (relative to 386.4 and 386.3) - some though not all of my Nest cameras and other IoT devices have been up and down like yoyo's since 386.4, unfortunate as everything else appears rock solid.
I look forward to your further observations, thanks :)
LOL! Well, it's been a couple of hours and all cameras are still steady across all my APs on the new Alpha 1. With 386.4, the instability was evident very soon after the upgrade. IOT/TP-Link all steady in their apps too. I'd say give it a go!

Feels so good to be back on @RMerlin builds again. Phew.
 
All routers updated 6hrs ago & running smoothly for myself & household. Thks for the time & your skills to make this user experience all occur @RMerlin
 
Could this version fix AiMesh issues? It is weird having laptop connected to the AP on second floor while being like in 1 meter from main router!
 
Could this version fix AiMesh issues? It is weird having laptop connected to the AP on second floor while being like in 1 meter from main router!
Generally client roaming is controlled by the client itself (your laptop): it should see its available access point options and select accordingly. Sometimes this can take time, especially when moving between locations, or if the relative signal strength/quality is marginal (and also not always obvious.. although your case seems to be).

Devices sometimes become 'sticky' ie. connects to an access point which works and so doesn't try anything else, even if the environment changes (eg. you move, competing signals and blockages, another access points comes online etc) making another access point now a better option - the router does have features that can sometimes help here, but by help it's actually a primitive kicking it off the network in the hope when it reconnects it makes better connectivity choices (can't tell it which to pick, but forces its hand to at least go through the motions), yet sometimes this has negative effects on devices that don't take kindly to being kicked off the network and therefore it's sometimes recommended to disable these features.

Of course there might be something specific to the 386.4 WiFi drivers that, as well as causing the problems quite a few others have observed, is also upsetting your laptop and making it favour your access point despite being further away.. in which case maybe it will help/fix the issue. But my point being it's unlikely to be anything to do with AiMesh itself, more just your laptop not getting on with the 386.4 WiFi.

TL;DR - maybe, maybe not, give it a try if you're feeling brave!
 
Last edited:
Seems wrong link here: https://nw-dlcdnet.asus.com/plugin/productIcons/RT-AX86U-2.png
Should be: https://nw-dlcdnet.asus.com/plugin/productIcons/RT-AX86U.png

GEThttps://nw-dlcdnet.asus.com/plugin/productIcons/RT-AX86U-2.png[HTTP/2 404 Not Found 551ms]


Screenshot 2022-02-12 at 19-50-22 ASUS Wireless Router RT-AX86U - AiMesh.png
 
Still curious what the difference is other than speed.

Which is moot cause 6Ghz has such low penetration even with cheap, old walls I can barely get 1 bar from my GT-AXE11000.
The AXE16000 is a quad-band router with 1x 2.4Ghz, 2x 5Ghz, and 1x 6Ghz bands. It is also using a new Quad-Core 2Ghz CPU and has Dual 10Gbe ports.
 
Here’s what is new in GPL46065.
Version 3.0.0.4.386.46065

2022/01/27
92.84 MBytes

ASUS RT-AC68U Firmware version 3.0.0.4.386.46065

Security
- Fixed string format stacks vulnerability
- Fixed cross-site-scripting vulnerability
- Fixed informational vulnerability.
Thanks to Howard McGreehan.

-Fixed SQL injection vulnerability
-Fixed json file traversal vulnerability
-Fixed plc/port file traversal vulnerability
-Fixed stack overflow vulnerability
Thanks to HP of Cyber Kunlun Lab

-Fixed authenticated stored XSS vulnerability
Thanks to Luke Walker – SmartDCC

-Fixed LPD denial of service vulnerability
-Fixed cfgserver heap overflow vulnerability
-Fixed cfgserver denial of service vulnerability
Thanks to TianHe from BeFun Cyber Security Lab.

Added more ISP profile
Digi 1 - TM
Digi 2 - TIME
Digi 3 - Digi
Digi 4 - CTS
Digi 5 - ALLO
Digi 6 - SACOFA
Maxis - CTS
Maxis - SACOFA
Maxis - TNB/ALLO

Fixed AiMesh guest network issues.
Fixed DDNS issues where the WAN IP is IPv6
Fixed UI bugs in Administration --> feedback.
Fixed time zone error.
Is there any place to find info on changelogs of specific GPLs? Merlins releases and Asus’ own doesn’t always match up. This time Merlin 386.5 happened to coincide with an official Asus release for the AC68U
 
Especially looking forward to this "Fixed AiMesh guest network issues." found in the changelog...

Updated AX88U, AC68P to the new Alpha1 yesterday, 18hr all seems running well. Looking forward to the AC86U drop.
 
Started seeing DNS flooding again with dns.msftncsi.com on my pihole. Not sure if it was 386.4 or this 386.5 Alpha that could have triggered this but just started seeing recently after 386.4. If anyone has a quick fix without breaking the 2.5GB wan connection would appreciate it.

May have fixed myself by accident. Under Wan, Dual Wan, even though its disabled, I added dns.msftncsi.com, 131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1 in and changed the time to 99 seconds and enabled the dns query even though dual wan is disabled, applied. Seems to have stopped the flooding requests.
 
Last edited:
dirty install of alpha on ax88. all a-ok
 
Dirty install on AX86U with ZenWiFi AXMini (XT4) as AiMesh node (wired backhaul) and all seems good. Had to restart a Chromecast Audio to get it to reconnect but otherwise fine.
 
Dirty install over stock and so far so good. My Alexa app for PC was having a bit of trouble connecting but seems to have settled down now. Will test further. :)
 
Upgrade RT-AX88U & RT-AC3100 from V386.4 Final to V386.5_alpha1-gbb7ff5cb66 via dirty firmware upgrade. 40+ devices (includes gaming, streaming, downloads, many IOT devices, etc.) and all appears to be working for main AX88U & backup AC3100 routers. Still postponing adding RT-AX58U with V386.4 Final into AiMesh 2.0, until Guest Network #01 issue is fixed, as Guest network is #01, and IOT devices is #02 currently in my setup.
 
Surprised the DST end for "GMT - 5:00 Eastern Time" still reflects an end of October Sunday date and not the correct date of 1st Sunday in Nov?
 

Sign Up For SNBForums Daily Digest

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