Release ASUS RT-AX86 Series(RT-AX86U/RT-AX86S) Firmware version 3.0.0.4.388.22068

[RMinNJ]

Hey guys,

I have just upgraded to 388.1 and it looked amazing. However, when I logged out of the router I lost all access to it when attempting to log back in. I've tried factory reset, as described in the official Asus page after a new firmware update. Also, I do have a security certificate issued under DDNS, but I am unsure if this is the case.

router.asus.com - only works after factory reset

(myddnspage).asuscomm.com:8443 - does not load

192.168.10.1 - does not load

Factory reset..should be 192.168.50.1 ?

 

[ErmoX]

Factory reset..should be 192.168.50.1 ?

Appreciate the reply, but it doesn't matter because every model seems to offer a different private IP address tho

 

[jsz]

It's working for me now, but I only have 1 device which can take advantage of it. Connecting it shows it is connected at 160Mhz while the rest of my devices including my iphone 14 Pro Max only show at 80Mhz.

There's no practical use case or incentive for companies like Apple, Sony, etc to support over 80mhz, at least on the WIFI 6 AX generation.

Maybe that changes with WIFI7, but there are too many clear advantages for 80mhz bonding on AX, especially on mobile devices that factor battery life as a key selling point.

 

[SeriousFamily]

Hey guys,

I have just upgraded to 388.1 and it looked amazing. However, when I logged out of the router I lost all access to it when attempting to log back in. I've tried factory reset, as described in the official Asus page after a new firmware update. Also, I do have a security certificate issued under DDNS, but I am unsure if this is the case.

router.asus.com - only works after factory reset

(myddnspage).asuscomm.com:8443 - does not load

192.168.10.1 - does not load

http://www.asusrouter.com is the default new link on updated firmware's.

192.168.1.1 works but defaults to the above link when used.

 

[ErmoX]

http://www.asusrouter.com is the default new link on updated firmware's.

192.168.1.1 works but defaults to the above link when used.

Thank you very much, but I still can't access the router through the log in page, regardless.

 

[bbunge]

Thank you very much, but I still can't access the router through the log in page, regardless.

192.168.50.1 is pretty much the default for AX routers as well as many others. If you are having trouble with Merlin firmware I suggest you take your issues to the correct forum area. This thread is for Asus factory firmware for the AX86U. Thank you.

 

[SwampKracker]

HTTP or HTTPS?

Both. This is a first for me. Firefox is reporting javascript errors when trying to render some pages. The status page with live updates just fails.

Maybe I will try the Feedback page, if it works.

Update: was able to send something via the Feedback page after some effort.

Installed the previous firmware, 3.0.0.4.388.21709, and the web interface works properly again.

If 3.0.0.4.388.22608 was meant to fix wireless issues, it broke the web interface in the process.

 

[aex.perez]

This is similar to what i'm experiencing. I went back to the previous firmware and haven't had these issues.

especially this:
This version of firmware has the devices bouncing from one AP to another, even though they are bound to the physically nearest AP (same room in most cases).

Rolled back to the previous version (3.0.0.4.388.21709) on the AX86 Mesh nodes, leaving 388.1 on the AX88 - back to stability/predictability. Still, more often that not, getting better WiFi throuput connected over the AX86 Mesh nodes (wired backhaul) vs the AX88 but still much more bandwidth than is needed by any one specific device at any given time. Have the 2.4 and 5Ghz radio on specific channels, setup for 160Mhz, 802.1ax, SmartConnect(default settings) - all of it healthy again. Cameras and Tablets that monitor them have not lost connectivity or moved (even thought bound to a specific AP) to another AP since the downgrade. 5Ghz radio's on the AX86's much more stable, with as strong or stronger signal than the 2.4Ghz radio (based on Android Tablet having 2.4Ghz & 5Ghz with the Wifi Analyzer app). Devices that support both frequencies gravitate and stay on the 5Ghz radio again.

Just after the post I made, things went bonkers again - AX86 dissappearing, devices losing connectivity and moving around, devices dropping connectivity. But with everyone/everything online the quickest way to quasi normalcy was to down grade the mesh nodes. I did notice that while I have the 5Ghz fixed on Channel 36 on the AX88, and it's cleared for Radar (36/160) - at some point it switched to 44/80. A quick restart of the 5Ghz (Channelhog/scMerlin - either) fixed it (on the AX88, don't know if AX86s switched as well), still odd it switched with it fixed (rarely get radar interference, unless Police flying overhead, also rare).

While still not a 100% perfect, it's stable enough for the family not to complain and IoT devices staying online, more importantly I haven't had to touch it since. Thinking I'll stay with this setup for awhile...

 

[Paliv]

Anyone update and stable that has AiProtection enabled with 2.5Gb hardware connected? My GT-AX6000 with 2.5Gb modem and 2.5Gb switch connected to the 2.5Gb ports goes into reboot loop on .388.21617 with AiProtection enabled. If I disable AiProtection, works great. If I unplug 2.5Gb ports, doesn't reboot but I only have wi-fi....

I'm just looking for hope

I’ve been running AiProtection since the update and use the 2.5 Gb port for my WAN. No issues with that setup.

On another note, I have not noticed any sluggishness in the gui or stability issues. But, no VPN and no mesh.

 

[L&LD]

What makes you say that?

These forums and the threads/responses to WG.

 

[Robinbb]

I’ve been running AiProtection since the update and use the 2.5 Gb port for my WAN. No issues with that setup.

On another note, I have not noticed any sluggishness in the gui or stability issues. But, no VPN and no mesh.

No issues here either. All pretty standard: Ai on, wired mesh to AX86S, 2.5GB to desktop. GUI has no lag at all (HTTPS)

 

[visortgw]

There's no practical use case or incentive for companies like Apple, Sony, etc to support over 80mhz, at least on the WIFI 6 AX generation.

Maybe that changes with WIFI7, but there are too many clear advantages for 80mhz bonding on AX, especially on mobile devices that factor battery life as a key selling point.

My Samsung Galaxy Z Flip4 supports 160 MHz — I'm guessing that other Samsung flagship phones of the same generation (or newer) do the same. Also, router to wireless AiMesh node performance is awesome (2-3.5 Gbps link speed)! It all depends on your particular network and devices.

 

[djjsin]

Rolled back to the previous version (3.0.0.4.388.21709) on the AX86 Mesh nodes, leaving 388.1 on the AX88 - back to stability/predictability. Still, more often that not, getting better WiFi throuput connected over the AX86 Mesh nodes (wired backhaul) vs the AX88 but still much more bandwidth than is needed by any one specific device at any given time. Have the 2.4 and 5Ghz radio on specific channels, setup for 160Mhz, 802.1ax, SmartConnect(default settings) - all of it healthy again. Cameras and Tablets that monitor them have not lost connectivity or moved (even thought bound to a specific AP) to another AP since the downgrade. 5Ghz radio's on the AX86's much more stable, with as strong or stronger signal than the 2.4Ghz radio (based on Android Tablet having 2.4Ghz & 5Ghz with the Wifi Analyzer app). Devices that support both frequencies gravitate and stay on the 5Ghz radio again.

Just after the post I made, things went bonkers again - AX86 dissappearing, devices losing connectivity and moving around, devices dropping connectivity. But with everyone/everything online the quickest way to quasi normalcy was to down grade the mesh nodes. I did notice that while I have the 5Ghz fixed on Channel 36 on the AX88, and it's cleared for Radar (36/160) - at some point it switched to 44/80. A quick restart of the 5Ghz (Channelhog/scMerlin - either) fixed it (on the AX88, don't know if AX86s switched as well), still odd it switched with it fixed (rarely get radar interference, unless Police flying overhead, also rare).

While still not a 100% perfect, it's stable enough for the family not to complain and IoT devices staying online, more importantly I haven't had to touch it since. Thinking I'll stay with this setup for awhile...

Yup. Pretty much my experience. Same situation with the family. Staying on 21709.

 

[neil0311]

My Samsung Galaxy Z Flip4 supports 160 MHz — I'm guessing that other Samsung flagship phones of the same generation (or newer) do the same.

And the point I keep making is that if the router says it supports 160 MHz and it has supported 160 MHz in past firmware versions, then not supporting 160 MHz and dropping to 80 MHz isn’t correct behavior. Call it a bug, bad QC, or whatever you want.

Other than living next to an airport or radar installation that was suddenly built last week, there is no reason I should have to deal with this crap.

 

[bbunge]

And the point I keep making is that if the router says it supports 160 MHz and it has supported 160 MHz in past firmware versions, then not supporting 160 MHz and dropping to 80 MHz isn’t correct behavior. Call it a bug, bad QC, or whatever you want.

Other than living next to an airport or radar installation that was suddenly built last week, there is no reason I should have to deal with this crap.

So good to hear you complain. How does the new firmware work for you? Or are you too afraid to try it. For a week? Remember to leave the WIFI at defaults after you reset and manually configure.

 

[Paliv]

And the point I keep making is that if the router says it supports 160 MHz and it has supported 160 MHz in past firmware versions, then not supporting 160 MHz and dropping to 80 MHz isn’t correct behavior. Call it a bug, bad QC, or whatever you want.

Other than living next to an airport or radar installation that was suddenly built last week, there is no reason I should have to deal with this crap.

Or it could be they weren’t in complete compliance with the RF regulations in the respective countries and corrected technically illegal behaviors of the router. 160MHz is pretty problematic.

 

[Tech9]

Looks like I'm going to skip entirely the testing of this firmware version. Someone to tag me when the firmware reaches 388_4xxxx version.

Merry Christmas!

 

[jsz]

My Samsung Galaxy Z Flip4 supports 160 MHz — I'm guessing that other Samsung flagship phones of the same generation (or newer) do the same. Also, router to wireless AiMesh node performance is awesome (2-3.5 Gbps link speed)! It all depends on your particular network and devices.

It's likely a Samsung issue if you're not getting 160mhz on phone, but are with alternative client.


I'm more or less making a jab that a phone doesn't need over the typical 600-800mhz 80mhz throughput limit via 2x2 client.

 

[brummygit]

I'm starting to develop a theory at the moment - might be insanity, but might also start an idea. I've posted some investigation info in a thread on the Merlin forum here https://www.snbforums.com/threads/a...w-firmware-when-downloading.82384/post-810240

I thought that using an RT-AX86U as a main router (or main AP) and with another AX86U as a node was working, but after initially connecting all my IOT devices it has been dropping them off the node and they are now mainly on the main router or offline.

My theory has been growing - I initially suspected it was the WPA/WPA2/WPA3 setting, then I started to realise that reconfiguring the WiFi settings seemed to trigger the devices to connect to the node. I then noticed that the devices eventually start dropping off again and spotted entries in my log

Dec 22 18:06:25 wlceventd: wlceventd_proc_event(530): eth6: Auth C4:5B:BE:6B:A4:00, status: Successful (0), rssi:0
Dec 22 18:06:25 wlceventd: wlceventd_proc_event(559): eth6: Assoc C4:5B:BE:6B:A4:00, status: Successful (0), rssi:-59
Dec 22 18:06:29 wlceventd: wlceventd_proc_event(494): eth6: Deauth_ind C4:5B:BE:6B:A4:00, status: 0, reason: Previous authentication no longer valid (2), rssi:-59
Dec 22 18:06:30 wlceventd: wlceventd_proc_event(494): eth6: Deauth_ind C4:5B:BE:6B:A4:00, status: 0, reason: Previous authentication no longer valid (2), rssi:-59
Dec 22 18:06:37 wlceventd: wlceventd_proc_event(530): eth6: Auth C4:5B:BE:6B:A4:00, status: Successful (0), rssi:0
Dec 22 18:06:44 wlceventd: wlceventd_proc_event(494): eth6: Deauth_ind C4:5B:BE:6B:A4:00, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-59
Dec 22 18:06:44 wlceventd: wlceventd_proc_event(530): eth6: Auth C4:5B:BE:6B:A4:00, status: Successful (0), rssi:-59
Dec 22 18:06:44 wlceventd: wlceventd_proc_event(559): eth6: Assoc C4:5B:BE:6B:A4:00, status: Successful (0), rssi:-59
Dec 22 18:07:02 kernel: wl0: random key value: 9E432008EE13DC0500A6029B115B1094626037A5AE1A03C1B6DA86A4191DD3A9
Dec 22 18:07:02 wlceventd: wlceventd_proc_event(511): eth6: Disassoc C4:5B:BE:6B:A4:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 22 18:07:02 wlceventd: wlceventd_proc_event(511): eth6: Disassoc C4:5B:BE:6B:A4:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

I'm wondering if the log entry containing "Previous authentication no longer valid (2)" is a pointer and there is an issue with WPA keys on the nodes - either key rotation, or a problem where the key information is corrupted?

I use a longer than minimum passphrase, could it be that this causes an issue that others with shorter ones don't see?

I don't have answers, just suspicions.

EDIT: I tried setting my Key Rotation Period to "0" to disable it but clients initially connect and then drop off within a minute or two still so no joy

 

[visortgw]

It's likely a Samsung issue if you're not getting 160mhz on phone, but are with alternative client.


I'm more or less making a jab that a phone doesn't need over the typical 600-800mhz 80mhz throughput limit via 2x2 client.

No, I was confirming that it works for me!