What's new

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

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

I always figured that the mystery of the AX86U bricking 3.0.0.4.386.48377 firmware would come out someday. But maybe not. Nearly seems consigned to the trash bin of history at this point. It was automatically loaded on my router and didn't brick it. But I can't help but be a little curious. FYI mine was made in Vietnam in 2021.
 
Do you have any idea if the RT-AX86U was manufactured in multiple different factories

Yes, I know for sure - @bbunge AX86U is made in Vietnam, my AX86U is made in China. :)

with the possibility of some components not being of the same standard across the board?

Quite possible given the AC86U experience. The components in consumer products are usually whatever they could find matching and cheaper.

Could this have triggered the development of the RT-AX86-Pro

Mostly business decision. All popular products on one platform lowers development, supply and support cost. I'm doing it for years in many areas. Remember Gordon Ramsey in "Hell's Kitchen"? A restaurant with 10 pages menu is 10 times more likely to go under than one with 1 page menu.
 
Possible AiMesh bug/glitch with v3.0.0.4.388.21709

I have discovered an possible issue with the latest firmware and building an Asus AiMesh network.

Using a AX86U as the main router the GUI works great as expected. When I add an AiMesh node, in this case a ASUS AX56U suddenly the GUI on the main router becomes crippled with very slow response times and page timeout issues when trying to navigate within the router's GUI. The Internet connection seems fine but the router interface is a dog. It seems like the AiMesh configuration suddenly nails the CPU usage? If I power down the node the main router seems to recover after a few minutes but as soon as the node is powered back up and rebuilds the AiMesh once again navigating the main router becomes slow and unresponsive.

I have a ticket in with Asus.
 
Possible AiMesh bug/glitch with v3.0.0.4.388.21709

I have discovered an possible issue with the latest firmware and building an Asus AiMesh network.

Using a AX86U as the main router the GUI works great as expected. When I add an AiMesh node, in this case a ASUS AX56U suddenly the GUI on the main router becomes crippled with very slow response times and page timeout issues when trying to navigate within the router's GUI. The Internet connection seems fine but the router interface is a dog. It seems like the AiMesh configuration suddenly nails the CPU usage? If I power down the node the main router seems to recover after a few minutes but as soon as the node is powered back up and rebuilds the AiMesh once again navigating the main router becomes slow and unresponsive.

I have a ticket in with Asus.
Slow and erratic GUI responce has been noted before with this firmware and the prior one. Happens without adding an AiMesh node.
 
I, too, have wondered if place and date of manufacture had a bearing on success or failure of firmware. Not much has been going on in the world in the past two years ;). I've not had the issues others have had and my AX86U is a 2020 made in Vietnam.
Mine are both 2020 from Vietnam - and have generally been solid ... but don't like 388.1 as AiMesh Node.
Also under recent Merlinware - can't add Node without connecting via cable ... whereas stock works with adding via wireless or cable.
 
Update after one more hard reset...Yah, it just loves to ignore 160hz under all circumstances. The router so wants to live on channel 161 mostly when I was on auto ch. which is fooking lunacy. I ended up doing what I had before when it worked properly, chose a lower grouping with low db interference if any and landed on ch. 48, still have 20/40/80/160 and 160hz checked up....chose the least consistantly interferance channel which in this case is 48 but we livin at 80hz no matter what we do.
 
Both latest stock and Merlin have crappy wifi issues. 386.5-2 has been my landing spot for months. It will continue until Asus get their butt into gear and fix the bugs in 388.
 
386.5-2 has been my landing spot for months.

And better looking GUI as well. I was joking about ToysRUs routers and Asus decided to fit better with the GUI. :rolleyes:
 
Both latest stock and Merlin have crappy wifi issues. 386.5-2 has been my landing spot for months. It will continue until Asus get their butt into gear and fix the bugs in 388.
No WIFI bugs here. Working as it should work! A few minor GUI bugs. SpeedTest error turned out to be a fault on my ISP end. Speedtest to other sites works as it should.

My test:
First WIFI log early morning before 160 MHz clients connect:
SSID: "xxxxxx"
noise: -87 dBm Channel: 44/80
BSSID: 3C:7C:3F:E1:EB:54 Capability: ESS RRM
Supported Rates: [ 6(b) 9 12 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 42 80MHz (0xe22a)
Primary channel: 44
Interference Level: Acceptable
Mode : AP Only
DFS status: state IDLE time elapsed 0ms radar channel cleared by DFS channel 44/160 (0xEA32)
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
4C:82:CF:x9:xx:xx Yes Yes -61dBm n No Yes No No 2 40M 270M 300M 06:29:48
18:4E:CB:C4:xx:xx Yes Yes -76dBm ac Yes Yes Yes Yes 1 80M 390M 6M 10:13:19
08:AA:55:08:xx:xx Yes Yes -59dBm ac Yes Yes Yes Yes 1 80M 390M 6M 12:26:26
EC:CE:x7:35:xx:xx Yes Yes -61dBm ac No Yes No No 1 80M 433.3M 433.3M 12:31:42
F0:B5:x1:A1:xx:xx Yes Yes -52dBm n Yes Yes No No 1 40M 135M 6M 12:58:33
B8:27:EB:62:xx:xx Yes Yes -47dBm ac No Yes No No 1 80M 433.3M 24M 12:59:54
38:81:x7:3D:xx:xx Yes Yes -70dBm n Yes Yes No No 1 40M 150M 6M 13:00:17


------------------------------------------------------------------------------------------------------------------------------------
Should note that between the first log and the next we had a three hour power failure. My UPS on the router was not going to make an extended outage so I shut the router down after an hour.

Next 160 clients connect but RADAR detected:

SSID: "xxxxxx"
noise: -88 dBm Channel: 36/80
BSSID: 3C:7C:3F:E1:EB:54 Capability: ESS RRM
Supported Rates: [ 6(b) 9 12 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 42 80MHz (0xe02a)
Primary channel: 36
Interference Level: Acceptable
Mode : AP Only
DFS status: state IDLE time elapsed 150ms radar channel cleared by DFS channel 36/160 (0xE832)
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
4C:03:4F:9B:xx:xx Yes Yes -58dBm ac No Yes Yes Yes 2 80M 866.7M 866.7M 00:04:23
94:EA:32:53:xx:xx Yes Yes -65dBm ax Yes Yes No No 2 80M 1201.0M 24M 00:27:18
4C:82:CF:x9:xx:xx Yes Yes -67dBm n No Yes No No 2 40M 270M 300M 00:35:28
EC:CE:x7:35:xx:xx Yes Yes -62dBm ac Yes Yes No No 1 80M 390M 24M 00:43:27
44:61:32:E9:xx:xx Yes Yes -57dBm ac No Yes Yes Yes 1 80M 390M 6M 01:00:36
18:4E:CB:C4:xx:xx Yes Yes -71dBm ac Yes Yes Yes Yes 1 80M 390M 6M 01:01:19
F0:B5:x1:A1:xx:xx Yes Yes -54dBm n Yes Yes No No 1 40M 135M 6M 01:01:26
08:AA:55:08:xx:xx Yes Yes -69dBm ac Yes Yes Yes Yes 1 80M 433.3M 6M 01:02:27
2C:1F:23:E3:xx:xx Yes Yes -54dBm n Yes Yes No No 1 40M 135M 24M 01:02:43
B8:27:EB:62:xx:xx Yes Yes -47dBm ac No Yes No No 1 80M 390M 390M 01:03:13
38:81:x7:3D:xx:xx Yes Yes -69dBm n Yes Yes No No 1 40M 135M 6M 01:03:43

------------------------------------------------------------------------------------------------------------------------------------
Now clients connected at 160 MHz:
SSID: "xxxxxx"
noise: -87 dBm Channel: 36/160
BSSID: 3C:7C:3F:E1:EB:54 Capability: ESS RRM
Supported Rates: [ 6(b) 9 12 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 50 160MHz (0xe832)
Primary channel: 36
Interference Level: Acceptable
Mode : AP Only
DFS status: state In-Service Monitoring(ISM) time elapsed 36450ms radar channel cleared by DFS channel 36/160 (0xE832)
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
B4:0E:xE:6D:xx:xx Yes Yes -38dBm ax No Yes Yes Yes 2 160M 2268.5M 490M 00:00:03
4C:03:4F:9B:xx:xx Yes Yes -63dBm ac No Yes Yes Yes 2 160M 1560M 1300M 00:00:33
94:EA:32:53:xx:xx Yes Yes -66dBm ax Yes Yes No No 2 80M 1134.2M 24M 01:16:14
4C:82:CF:x9:xx:xx Yes Yes -70dBm n No Yes No No 2 40M 270M 300M 01:24:24
EC:CE:x7:35:xx:xx Yes Yes -64dBm ac Yes Yes No No 1 80M 390M 24M 01:32:23
44:61:32:E9:xx:xx Yes Yes -60dBm ac No Yes Yes Yes 1 80M 390M 433.3M 01:49:32
18:4E:CB:C4:xx:xx Yes Yes -72dBm ac Yes Yes Yes Yes 1 80M 390M 6M 01:50:15
F0:B5:x1:A1:xx:xx Yes Yes -59dBm n Yes Yes No No 1 40M 135M 6M 01:50:22
08:AA:55:08:xx:xx Yes Yes -71dBm ac Yes Yes Yes Yes 1 80M 390M 6M 01:51:23
2C:1F:23:E3:xx:xx Yes Yes -56dBm n Yes Yes No No 1 40M 135M 24M 01:51:39
B8:27:EB:62:xx:xx Yes Yes -46dBm ac No Yes No No 1 80M 390M 390M 01:52:09
38:81:x7:3D:xx:xx Yes Yes -71dBm n Yes Yes No No 1 40M 135M 6M 01:52:39

My AX86U has been working like this since the 386 code and into the 388 beta and the two releases. We still feel problems others are having are a result of changing the default WIFI settings or your environment. Maybe you have too many IoT devices with crappy firmware?
 
No WIFI bugs here. Working as it should work! A few minor GUI bugs. SpeedTest error turned out to be a fault on my ISP end. Speedtest to other sites works as it should.

My test:
First WIFI log early morning before 160 MHz clients connect:
SSID: "xxxxxx"
noise: -87 dBm Channel: 44/80
BSSID: 3C:7C:3F:E1:EB:54 Capability: ESS RRM
Supported Rates: [ 6(b) 9 12 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 42 80MHz (0xe22a)
Primary channel: 44
Interference Level: Acceptable
Mode : AP Only
DFS status: state IDLE time elapsed 0ms radar channel cleared by DFS channel 44/160 (0xEA32)
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
4C:82:CF:x9:xx:xx Yes Yes -61dBm n No Yes No No 2 40M 270M 300M 06:29:48
18:4E:CB:C4:xx:xx Yes Yes -76dBm ac Yes Yes Yes Yes 1 80M 390M 6M 10:13:19
08:AA:55:08:xx:xx Yes Yes -59dBm ac Yes Yes Yes Yes 1 80M 390M 6M 12:26:26
EC:CE:x7:35:xx:xx Yes Yes -61dBm ac No Yes No No 1 80M 433.3M 433.3M 12:31:42
F0:B5:x1:A1:xx:xx Yes Yes -52dBm n Yes Yes No No 1 40M 135M 6M 12:58:33
B8:27:EB:62:xx:xx Yes Yes -47dBm ac No Yes No No 1 80M 433.3M 24M 12:59:54
38:81:x7:3D:xx:xx Yes Yes -70dBm n Yes Yes No No 1 40M 150M 6M 13:00:17


------------------------------------------------------------------------------------------------------------------------------------
Should note that between the first log and the next we had a three hour power failure. My UPS on the router was not going to make an extended outage so I shut the router down after an hour.

Next 160 clients connect but RADAR detected:

SSID: "xxxxxx"
noise: -88 dBm Channel: 36/80
BSSID: 3C:7C:3F:E1:EB:54 Capability: ESS RRM
Supported Rates: [ 6(b) 9 12 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 42 80MHz (0xe02a)
Primary channel: 36
Interference Level: Acceptable
Mode : AP Only
DFS status: state IDLE time elapsed 150ms radar channel cleared by DFS channel 36/160 (0xE832)
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
4C:03:4F:9B:xx:xx Yes Yes -58dBm ac No Yes Yes Yes 2 80M 866.7M 866.7M 00:04:23
94:EA:32:53:xx:xx Yes Yes -65dBm ax Yes Yes No No 2 80M 1201.0M 24M 00:27:18
4C:82:CF:x9:xx:xx Yes Yes -67dBm n No Yes No No 2 40M 270M 300M 00:35:28
EC:CE:x7:35:xx:xx Yes Yes -62dBm ac Yes Yes No No 1 80M 390M 24M 00:43:27
44:61:32:E9:xx:xx Yes Yes -57dBm ac No Yes Yes Yes 1 80M 390M 6M 01:00:36
18:4E:CB:C4:xx:xx Yes Yes -71dBm ac Yes Yes Yes Yes 1 80M 390M 6M 01:01:19
F0:B5:x1:A1:xx:xx Yes Yes -54dBm n Yes Yes No No 1 40M 135M 6M 01:01:26
08:AA:55:08:xx:xx Yes Yes -69dBm ac Yes Yes Yes Yes 1 80M 433.3M 6M 01:02:27
2C:1F:23:E3:xx:xx Yes Yes -54dBm n Yes Yes No No 1 40M 135M 24M 01:02:43
B8:27:EB:62:xx:xx Yes Yes -47dBm ac No Yes No No 1 80M 390M 390M 01:03:13
38:81:x7:3D:xx:xx Yes Yes -69dBm n Yes Yes No No 1 40M 135M 6M 01:03:43

------------------------------------------------------------------------------------------------------------------------------------
Now clients connected at 160 MHz:
SSID: "xxxxxx"
noise: -87 dBm Channel: 36/160
BSSID: 3C:7C:3F:E1:EB:54 Capability: ESS RRM
Supported Rates: [ 6(b) 9 12 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 50 160MHz (0xe832)
Primary channel: 36
Interference Level: Acceptable
Mode : AP Only
DFS status: state In-Service Monitoring(ISM) time elapsed 36450ms radar channel cleared by DFS channel 36/160 (0xE832)
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
B4:0E:xE:6D:xx:xx Yes Yes -38dBm ax No Yes Yes Yes 2 160M 2268.5M 490M 00:00:03
4C:03:4F:9B:xx:xx Yes Yes -63dBm ac No Yes Yes Yes 2 160M 1560M 1300M 00:00:33
94:EA:32:53:xx:xx Yes Yes -66dBm ax Yes Yes No No 2 80M 1134.2M 24M 01:16:14
4C:82:CF:x9:xx:xx Yes Yes -70dBm n No Yes No No 2 40M 270M 300M 01:24:24
EC:CE:x7:35:xx:xx Yes Yes -64dBm ac Yes Yes No No 1 80M 390M 24M 01:32:23
44:61:32:E9:xx:xx Yes Yes -60dBm ac No Yes Yes Yes 1 80M 390M 433.3M 01:49:32
18:4E:CB:C4:xx:xx Yes Yes -72dBm ac Yes Yes Yes Yes 1 80M 390M 6M 01:50:15
F0:B5:x1:A1:xx:xx Yes Yes -59dBm n Yes Yes No No 1 40M 135M 6M 01:50:22
08:AA:55:08:xx:xx Yes Yes -71dBm ac Yes Yes Yes Yes 1 80M 390M 6M 01:51:23
2C:1F:23:E3:xx:xx Yes Yes -56dBm n Yes Yes No No 1 40M 135M 24M 01:51:39
B8:27:EB:62:xx:xx Yes Yes -46dBm ac No Yes No No 1 80M 390M 390M 01:52:09
38:81:x7:3D:xx:xx Yes Yes -71dBm n Yes Yes No No 1 40M 135M 6M 01:52:39

My AX86U has been working like this since the 386 code and into the 388 beta and the two releases. We still feel problems others are having are a result of changing the default WIFI settings or your environment. Maybe you have too many IoT devices with crappy firmware?
My findings regarding 5G160Mhz.
I have two Ax86U one as mesh node connected with2.5G cable.

On the Main router 160Mhz works fine switching from 80 up to 160 if an AX or 160 AC WiFi capable client connects. This always works fine!
However on the mesh node in basement (were my Ax200 computer is located) it doesn't ever switch up to 160 automatically! I tried with several 160mHz clients.
It stays on 80 Mhz until a 160mhz cable client connect to the main router. Then I get 160 (2400mbs on my computer) on 160Mhz clients on the Mesh router as well.
If all other 160Mhz clients are off and I turn off the mesh node my computer can connect to main router and get 160mhz 300-400mbs. So my computer can make main router switch up to 160Mhz.
I thought this was a bug in latest Asuswrt and 388.1 Merlin but believe I just now saw same behavior with Merlin 386.7_2 on main router (but I had latest Asuswrt on mesh node..). I down graded mesh node to Merlin 386.7_2 now will test if same behavior when possible.
Not sure if this has been a bug for long time since not often no 160Mhz client isn't connected to main router...
 
My findings regarding 5G160Mhz.
I have two Ax86U one as mesh node connected with2.5G cable.

On the Main router 160Mhz works fine switching from 80 up to 160 if an AX or 160 AC WiFi capable client connects. This always works fine!
However on the mesh node in basement (were my Ax200 computer is located) it doesn't ever switch up to 160 automatically! I tried with several 160mHz clients.
It stays on 80 Mhz until a 160mhz cable client connect to the main router. Then I get 160 (2400mbs on my computer) on 160Mhz clients on the Mesh router as well.
If all other 160Mhz clients are off and I turn off the mesh node my computer can connect to main router and get 160mhz 300-400mbs. So my computer can make main router switch up to 160Mhz.
I thought this was a bug in latest Asuswrt and 388.1 Merlin but believe I just now saw same behavior with Merlin 386.7_2 on main router (but I had latest Asuswrt on mesh node..). I down graded mesh node to Merlin 386.7_2 now will test if same behavior when possible.
Not sure if this has been a bug for long time since not often no 160Mhz client isn't connected to main router...
I also have a pair of AX86u's connected via 2.5G port.
I don't have 2 x 160Mhz devices to verify exactly, but having moved my laptop from main router @ 160Mhz to my basement node it does seem to have connected at 160Mhz - the TX/RX speed shows 1733Mbps in the client list.
 
I also have a pair of AX86u's connected via 2.5G port.
I don't have 2 x 160Mhz devices to verify exactly, but having moved my laptop from main router @ 160Mhz to my basement node it does seem to have connected at 160Mhz - the TX/RX speed shows 1733Mbps in the client list.
That's interesting.
And you are running latest Asuswrt on both router and node?
And you are sure you get 1733mbs on your computer?
Check on the router wireless log if it still say ch#/160.
I usually check in win10 "network & internet settings" WiFi properties to see actual connected speed since seems not possible to se true connection speed of clients on the mesh node (at least not in Merlin). Or is it, were?

I have tried two latest Merlin and Asuswrt and get same result on mesh node. Always stay at 80Mhz if only have 160 Mhz capable client on mesh node. And always go to 160Mhz if 160 Mhz node connects to router.

And I also found that 5G does not work at all on mesh node if ch 100-128 160Mhz used!
36-64 160Mhz works fine.
No 5G client (older 80Mhz or newer 160Mhz clients) can connect to mesh node if router use these channels at 160Mhz.
Edit: ch 100-128 160Mhz works fine on main router...

Ch 100-128 manually set @80Mhz works fine.
 
Last edited:
That's interesting.
And you are running latest Asuswrt on both router and node?
And you are sure you get 1733mbs on your computer?
Check on the router wireless log if it still say ch#/160.
I usually check in win10 "network & internet settings" WiFi properties to see actual connected speed since seems not possible to se true connection speed of clients on the mesh node (at least not in Merlin). Or is it, were?

I have tried two latest Merlin and Asuswrt and get same result on mesh node. Always stay at 80Mhz if only have 160 Mhz capable client on mesh node. And always go to 160Mhz if 160 Mhz node connects to router.

And I also found that 5G does not work at all on mesh node if ch 100-128 160Mhz used!
36-64 160Mhz works fine.
No 5G client (older 80Mhz or newer 160Mhz clients) can connect to mesh node if router use these channels at 160Mhz.
Edit: ch 100-128 160Mhz works fine on main router...

Ch 100-128 manually set @80Mhz works fine.
388.1 on both router and node.
Only my laptop supports 160Mhz, so all the clients connected to 5G on the node are operating at 80Mhz.
I just looked at Network Map > View List and check the TX / RX rate columns - my Apple devices @ 80Mhz top out at 1200Mbps but the laptop shows 1733Mbps and when connected to router I see the 160Mhz in wireless log info so assume same must be true on node. And aggregate link speed in Win 11 network properties also shows 1733Mbps.
You can SSH into the node explicitly and run some commands - which I just did.
Get list of mac addresses of connected clients (wl1.1 interface is my 5ghz radio): wl -i wl1.1 assoclist
Gives you a load of info about the connection of the specific device with that particular mac address: wl -i wl1.1 sta_info aa:bb:cc:dd:ee:ff
Such as:

admin@AX86U-OFFICE:/jffs/scripts# wl -i wl1.1 sta_info aa:bb:cc:dd:ee:ff
[VER 8] STA aa:bb:cc:dd:ee:ff:
chanspec 36/160 (0xe832)
....
tx nrate
vht mcs 9 Nss 2 Tx Exp 2 bw160 ldpc sgi auto
rx nrate
vht mcs 9 Nss 2 Tx Exp 0 bw160 ldpc sgi auto
wnm
0x101: BSS-Transition Notification
link bandwidth = 160 MHZ
 
And more - OpenVPN configuration file:

View attachment 45734

The router knows my DDNS settings. Why the internal WAN IP?? This ovpn file has to be modified manually to work...
I know this was a while back.

When ddns detects internal ip on wan a new setting shows up for internal or external ip detection.

Internal just uses the ip on the wan interface.
External I assume uses stun to a Google server or something.

Setting external detection should get the actual public ip instead of internal.
Which should also fix certificates using internal ip issues.
 
I think this update "bricked" my router. I had a ac86u before.
Now the AX86U came, after a quick setup i was first enjoying the performances.
Then i wanted to change some settings and i noticed that the gui was somehow broken, i could browse the menus (in the web gui) but no matter what i clicked it didnt no anything.
I rememberd while doing the initial setup he did a firmware update. So i've tought: ok lets go to the restore page do a factory reset and start again.
After reset, the setup page appears, with the two buttons "create new network/advanced" but i can't do anything.
I did firmware restore (same version) and nothing changes. reset etc.. nothing changed. I tried cabled, wifi, other broswser, clean cache. nothing.
It's brand new, built 2022 in china. I have the option to ship it back and get a new one... im thinking about it...
 
Hey!
I just got the file to flash, but... there's something that I feel isn't right...

Look at the file name of the upload file it grabs from Asus server/s.

What is this?! Look at the whole file name, after ...21709.

Thanks for all advises!
Best Regards,
Mikael
The -GXXXXXXX value is the Github version number, and can be ignored by the end user.
For software support, it identifies exactly which internal version is deployed.
 
Call me crazy, but I wish ASUS had kept the firmware release date as well as the version number.
OK, your crazy.
Now, why is the date important. It is just a number like the version number. And we should be aware that the highest version is the one to use. Those who do not upgrade put their network, family, Co workers and us at risk. And I do not want to hear about minor graphical issues or poor performance. Just get over it and run the current firmware!
 
OK, your crazy.
Now, why is the date important. It is just a number like the version number. And we should be aware that the highest version is the one to use. Those who do not upgrade put their network, family, Co workers and us at risk. And I do not want to hear about minor graphical issues or poor performance. Just get over it and run the current firmware!

?? I'm not that annoyed about the date on the site..but.. having the firmware dated gives a person some idea of the age of the firmware... use case..one is having an issue and wants to see if an older release solves something..going to site they pick some version and it works but it's from 2018 and has an ssl bug.. ..cant tell if the old firmware is from 2015 or last week..
 
Now, why is the date important.

Because looking at release dates you could tell what support history the model has. Now you don't know if the firmware was released yesterday or it's 2 years old already and this router has no support anymore. Not very successful models like AX92U are still offered in stores and the latest firmware is from the beginning of 2022, but potential customers have no good way to know. Sounds like marketing reasons to me.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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