ASUS RT-AC68U Firmware version 3.0.0.4.384_81039

[Stephen Harrington]

Looks like Asus update servers are back up and 81039 has been pulled ... my RT-AC68U is no longer offered it now when I hit the "Check Update" button.

 

[asmopul]

Available by firmware update check.

Not posted to the website yet.

It's in the german site:
https://www.asus.com/de/Networking/RTAC68U/HelpDesk_Download/

 

[organshifter]

Stephen,
Thanks ... I actually have updated FW 81039 for AiMesh "nodes" last week both RT-AC68U and RT-AC86U and it appear to be running without issue so far.

Same here. FW 81039 has been rock solid on my RT-AC86U as an AiMesh node. Thankfully.

 

[wouterv]

Looks like Asus update servers are back up and 81039 has been pulled ... my RT-AC68U is no longer offered it now when I hit the "Check Update" button.

I can confirm the same:
The router Check Update reports the router current firmware (45717) is the latest version, some days ago it still found 81039.
And the website no longer shows it (not at BIOS & FIRMWARE and not under DRIVER & TOOLS / Windows 10 64-bit) while it did until yesterday.

 

[OzarkEdge]

I can confirm the same:
The router Check Update reports the router current firmware (45717) is the latest version, some days ago it still found 81039.
And the website no longer shows it (not at BIOS & FIRMWARE and not under DRIVER & TOOLS / Windows 10 64-bit) while it did until yesterday.

Great, ASUS router firmware development is moving forward again!

OE

 

[dosborne]

It's in the german site:
https://www.asus.com/de/Networking/RTAC68U/HelpDesk_Download/

Seems to have been pulled from there as well now. (or at least I am unable to display it).
The english site is (currently) showing it in the list [https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/], but results in a 404 error. [https://dlcdnets.asus.com/pub/ASUS/...16.102617708.1566926467-1914965561.1566669266]

 

[Brad Affleck]

Having similar issues here with my three mesh system (RT-AC68U)...

 

[netmann]

This firmware pull out most likely lasts one week before repost similar to the last time....

 

[ForkWNY]

I've been working with ASUS support regarding the problems with the 81039 firmware update since the night it was released on 8/22. Even on a blank-slate, the CPU usage is all over the place and the GUI is slow. Adding AiMesh nodes would cause the UI to crash. The UI would also crash at random when viewing connected clients. This was on a RT-AC86U. I have 3 RT-AC68U's running as AiMesh nodes on my network, all 3 have the latest 81039 firmware and run fine, but then again I don't have to access the web UI on any of them since everything is managed from the 86U. The Web UI is where all the problems lie.

As RMerlin noted, connecting via SSH and running TOP would not show any rogue processes eating up CPU. However, if you open up a HTTPS web UI session into the router, then start clicking on client lists, AiMesh nodes, etc., you SHOULD see the CPU spikes within TOP via SSH as you do within the Web UI status area. The UI itself seems to be the source of the problems...from a network standpoint everything seemed fine. The minute you'd go into the web UI, all bets on stability were off the table.

ASUS had me try the following (obviously no one else has to try this - the 81039 firmware is a dud, so it's not something on your end causing the problems) - (1) update firmware, hard reset router, import CFG file from backup, observe behavior. (2) They also had me do a complete wipe and restore of the newest firmware by placing the 86U into recovery mode, then re-configure the router manually from scratch, resetting every AiMesh node and re-adding them (re-adding Aimesh nodes would cause the UI to crash!). I hate losing all the traffic data but can live without it. Same results each time I followed a different step, an unstable web UI.

ASUS pulled the update from the firmware update check at some point Tuesday then pulled the file off their website at some point Wednesday into Thursday. I provided them with countless logs as well as my RT-AC86U router configuration. Just yesterday I received a call-back from a support engineer that they were aware of some software issues and would be getting back to me with a version to test out that they think might fix these issues. The 81039 update appears to have been pulled across the board for all routers. This was the buggiest firmware release I've seen from ASUS in quite awhile.

 

[netmann]

I've been working with ASUS support regarding the problems with the 81039 firmware update since the night it was released on 8/22. Even on a blank-slate, the CPU usage is all over the place and the GUI is slow. Adding AiMesh nodes would cause the UI to crash. The UI would also crash at random when viewing connected clients. This was on a RT-AC86U. I have 3 RT-AC68U's running as AiMesh nodes on my network, all 3 have the latest 81039 firmware and run fine, but then again I don't have to access the web UI on any of them since everything is managed from the 86U. The Web UI is where all the problems lie.

As RMerlin noted, connecting via SSH and running TOP would not show any rogue processes eating up CPU. However, if you open up a HTTPS web UI session into the router, then start clicking on client lists, AiMesh nodes, etc., you SHOULD see the CPU spikes within TOP via SSH as you do within the Web UI status area. The UI itself seems to be the source of the problems...from a network standpoint everything seemed fine. The minute you'd go into the web UI, all bets on stability were off the table.

ASUS pulled the update from the firmware update check at some point Tuesday then pulled the file off their website at some point Wednesday into Thursday. I provided them with countless logs as well as my RT-AC86U router configuration. Just yesterday I received a call-back from a support engineer that they were aware of some software issues and would be getting back to me with a version to test out that they think might fix these issues. The 81039 update appears to have been pulled across the board for all routers. This was the buggiest firmware release I've seen from ASUS in quite awhile.

Good news and nice job to collaborate with Asus to speed up the recovery of this firmware ForkWNY!

 

[128bit]

I've been working with ASUS support regarding the problems with the 81039 firmware update since the night it was released on 8/22. Even on a blank-slate, the CPU usage is all over the place and the GUI is slow. Adding AiMesh nodes would cause the UI to crash. The UI would also crash at random when viewing connected clients. This was on a RT-AC86U. I have 3 RT-AC68U's running as AiMesh nodes on my network, all 3 have the latest 81039 firmware and run fine, but then again I don't have to access the web UI on any of them since everything is managed from the 86U. The Web UI is where all the problems lie.

As RMerlin noted, connecting via SSH and running TOP would not show any rogue processes eating up CPU. However, if you open up a HTTPS web UI session into the router, then start clicking on client lists, AiMesh nodes, etc., you SHOULD see the CPU spikes within TOP via SSH as you do within the Web UI status area. The UI itself seems to be the source of the problems...from a network standpoint everything seemed fine. The minute you'd go into the web UI, all bets on stability were off the table.

ASUS had me try the following (obviously no one else has to try this - the 81039 firmware is a dud, so it's not something on your end causing the problems) - (1) update firmware, hard reset router, import CFG file from backup, observe behavior. (2) They also had me do a complete wipe and restore of the newest firmware by placing the 86U into recovery mode, then re-configure the router manually from scratch, resetting every AiMesh node and re-adding them (re-adding Aimesh nodes would cause the UI to crash!). I hate losing all the traffic data but can live without it. Same results each time I followed a different step, an unstable web UI.

ASUS pulled the update from the firmware update check at some point Tuesday then pulled the file off their website at some point Wednesday into Thursday. I provided them with countless logs as well as my RT-AC86U router configuration. Just yesterday I received a call-back from a support engineer that they were aware of some software issues and would be getting back to me with a version to test out that they think might fix these issues. The 81039 update appears to have been pulled across the board for all routers. This was the buggiest firmware release I've seen from ASUS in quite awhile.

weird that my 86u gui works fine with no apparent spikes, per se. i hope that i won't have to go through a complete factory reset when the next "fix" comes in, tedious. i've had this pup at home for a few years now and have never performed any reset post upgrade. all's been well if not exceptional. perhaps my box is an anomaly re 81039. software's weird.

 

[wouterv]

weird that my 86u gui works fine with no apparent spikes, per se. i hope that i won't have to go through a complete factory reset when the next "fix" comes in, tedious. i've had this pup at home for a few years now and have never performed any reset post upgrade. all's been well if not exceptional. perhaps my box is an anomaly re 81039. software's weird.

Make it good practice to write down all the changes you made from the defaults in a text file.
This helps to avoid the need to pull your hair out when you have to rebuild your router setup.

Mine is like this:

RT-AC68U

2.4 GHz Network Name: xxx
Network Key: yyyy
5 GHz Network Name: xxx
Network Key: yyyy

Advanced Settings - Wireless - General - 2.4 GHz
Channel bandwidth: 20 MHz
Control Channel: 1

Advanced Settings - Wireless - WPS
Enable WPS: OFF

Advanced Settings - LAN - LAN IP
IP Address: 192.168.1.1

Advanced Settings - LAN - DHCP Server
IP Pool Starting Address: 192.168.1.3
IP Pool Ending Address: 192.168.1.254

Advanced Settings - WAN - Internet Connection
Enable UPnP: No

Advanced Settings - Administration - System
USB Mode: USB 2.0
Time Zone: (GMT+1:00) Amsterdam, Berlin, Bern
DST time zone changes starts: weekday = 5th
DST time zone changes ends: month =10, weekday = 5th, 3 hours

Guest Network
2.4GHz
zzzz
xxxxxx
5GHz
zzzz
xxxxxx

USB application - Servers Center - Media Server
Enable UPnP Media Server: OFF

USB application - Servers Center - Network Place
Device Name: rrrrr
Work Group: ggggg

NB: 192.168.1.2 is the fixed address of my RT-N66U Media Bridge.

 

[ForkWNY]

Make it good practice to write down all the changes you made from the defaults in a text file.
This helps to avoid the need to pull your hair out when you have to rebuild your router setup.

Mine is like this:

RT-AC68U

2.4 GHz Network Name: xxx
Network Key: yyyy
5 GHz Network Name: xxx
Network Key: yyyy

Advanced Settings - Wireless - General - 2.4 GHz
Channel bandwidth: 20 MHz
Control Channel: 1

Advanced Settings - Wireless - WPS
Enable WPS: OFF

Advanced Settings - LAN - LAN IP
IP Address: 192.168.1.1

**Advanced Settings - LAN - DHCP Server
IP Pool Starting Address: 192.168.1.3
IP Pool Ending Address: 192.168.1.254

Advanced Settings - WAN - Internet Connection
Enable UPnP: No

Advanced Settings - Administration - System
USB Mode: USB 2.0
Time Zone: (GMT+1:00) Amsterdam, Berlin, Bern
DST time zone changes starts: weekday = 5th
DST time zone changes ends: month =10, weekday = 5th, 3 hours

Guest Network
2.4GHz
zzzz
xxxxxx
5GHz
zzzz
xxxxxx

USB application - Servers Center - Media Server
Enable UPnP Media Server: OFF

USB application - Servers Center - Network Place
Device Name: rrrrr
Work Group: ggggg

NB: 192.168.1.2 is the fixed address of my RT-N66U Media Bridge.

I usually just screenshot everything and save the jpg files just in case.

As for those having problems and others not having them, probably depends on configuration and other factors. I'd be surprised though if there weren't at least some issues encountered even on a primarily default config. Could also be the case that some hardware revisions are affected while others are not. I also can't speak for 68U users as I only use 68U's as aimesh nodes and an 86U as the parent router.

 

[128bit]

thanks guys and fwiw, i do a ctrl-p and save those gui settings as pdf's.
very similar to a screenshot but much more user friendly cause they're searchable!! in my case, i have 24 ac86u pages of interest and if i don't recall a specific page for a setting, acrobat reader "find" or "advanced search" are my friends. mind u not every object on each page is searchable - i know button labels are not; i can live with that.
u can also have a timestamp on the header of each page should u choose as not all pages need archiving with every update.

 

[OzarkEdge]

thanks guys and fwiw, i do a ctrl-p and save those gui settings as pdf's.
very similar to a screenshot but much more user friendly cause they're searchable!! in my case, i have 24 ac86u pages of interest and if i don't recall a specific page for a setting, acrobat reader "find" or "advanced search" are my friends. mind u not every object on each page is searchable - i know button labels are not; i can live with that.
u can also have a timestamp on the header of each page should u choose as not all pages need archiving with every update.
View attachment 19190

Thanks for the tip... I had not discovered this yet!

OE

 

[128bit]

the party's over! my 86u now shows the same reported behavior with high core usage and very slow page loads on the gui. i had a feeling the good times were limited. not sure if i should wait for the next fix or attempt to reinstall the previous release as both bands seem to still be working.

never had to do this before but i suspect to backlevel the device, i'll need to go into rescue/recovery even though it's using stock code. oh well, time to read up.

 

[OzarkEdge]

the party's over! my 86u now shows the same reported behavior with high core usage and very slow page loads on the gui. i had a feeling the good times were limited. not sure if i should wait for the next fix or attempt to reinstall the previous release as both bands seem to still be working.

never had to do this before but i suspect to backlevel the device, i'll need to go into rescue/recovery even though it's using stock code. oh well, time to read up.

To revert from 81039, I simply uploaded 45717 from the webUI and then performed a webUI Restore w/Initialize to reset to 45717 defaults and to clear logged data.

OE

 

[Smokindog]

My two AC68's that I updated are used as wired backhaul APs and "fringe" to my core use. Most taxing thing I can think of is serving the ROKU Stick+ in the master (MPEG2 streaming for live TV). It also serves the Stick+ in the master bath and both have been in use at the same time/same purpose.

I haven't done any explicit tests but I don't notice any performance issues as it relates to the "primary function" of delivering bits. Yes, GUI is slow and yes I see the CPU spikes but as noted, but there seems to be little impact if you're not actively "using the GUI via web services".

I plan to just let it stand until an update is released. Don't know that the effort to reset, reload, and reconfigure two routers is worth it based on what I'm seeing.

Free internet advice worth what you paid

 

[128bit]

To revert from 81039, I simply uploaded 45717 from the webUI and then performed a webUI Restore w/Initialize to reset to 45717 defaults and to clear logged data.

OE

yep. done. now doing the manual input. yuck!
thanks

 

[128bit]

My two AC68's that I updated are used as wired backhaul APs and "fringe" to my core use. Most taxing thing I can think of is serving the ROKU Stick+ in the master (MPEG2 streaming for live TV). It also serves the Stick+ in the master bath and both have been in use at the same time/same purpose.

I haven't done any explicit tests but I don't notice any performance issues as it relates to the "primary function" of delivering bits. Yes, GUI is slow and yes I see the CPU spikes but as noted, but there seems to be little impact if you're not actively "using the GUI via web services".

I plan to just let it stand until an update is released. Don't know that the effort to reset, reload, and reconfigure two routers based on what I'm seeing.

Free internet advice worth what you piad

my situation was similar to yours and then poof! couldn't even get to the main sign-on page without a reboot. all my devices worked but i had read where some people reported band loss. so, while watching us open tennis, i decided to revert back to 45717. fairly simple:

1. manually download the fw zip from the asus page and unzip it.
2. on the firmware upgrade page, perform a "manual update" and upload that *.w file

i'm sure you're familiar. being extra cautious, i did do a factory default/restore/initialize then manually re-input all my settings instead of using the old config file. it forced me to revisit some settings that were questionable. tedious? yes, but it's done now.