ASUS RT-AC68U Firmware version 3.0.0.4.384_81039

[wshuman3]

Available by firmware update check.

Not posted to the website yet.

 

[VANT]

Security fix

- Fixed a DDoS vulnerability. Thanks for Altin Thartori's contribution.

Bug fix

- Fixed Samba server compatibility issue.
- Fixed OpenVPN related bugs.
- Fixed schedule reboot bugs.
- Improved AiMesh compatibility.
- Improved system stability.

Link:

https://dlcdnets.asus.com/pub/ASUS/wireless/RT-AC68U/FW_RT_AC68U_300438481039.zip

 

[Domdus]

Just updated my two AC68U in AiMesh setup via the ASUS Router App.
All went smooth, no hickups, no bugs yet seen (no failures reported in logs). I did not perform any manual reboot or factory reset, devices just came up again with previous configuration and continued operating normally.

AiMesh router was on 45717, the node on 45713 (for stability).

BR

 

[128bit]

i have the ac86u and like u, i just install via the asus gui and roll. been doing that for years now with 0 issues. perhaps we're lucky but when compared to my previous linksys (marvel) routers, this 86u is a dream. still, i'm just a low-level home user with a ssd nas. my fastest client has 802.11ac and i'm quite ok with concurrent 4k streams. course with spectrum putting out 200 Mbps. . .

 

[wouterv]

It is funny and weird:
The router is still at version 45717.
The system log reports:

Aug 24 10:43:16 WATCHDOG: [FAUPGRADE][auto_firmware_check:(5834)]period_retry = 0
Aug 24 10:43:16 WATCHDOG: [FAUPGRADE][auto_firmware_check:(5840)]periodic_check AM 4:42
Aug 24 10:43:18 WATCHDOG: [FAUPGRADE][auto_firmware_check:(5860)]retrieve firmware information
Aug 24 10:43:18 WATCHDOG: [FAUPGRADE][auto_firmware_check:(5874)]no need to upgrade firmware

A manual update check does find the 81039 update.

 

[wouterv]

I upgraded the router followed by factory defaults and manual configure.
The Deauth / Auth / Assoc messages are back again:

Aug 24 15:33:44 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 68:07:15:11:11:11, status: 0, reason: Unspecified reason (1)
Aug 24 15:33:44 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth 68:07:15:11:11:111, status: 0, reason: d11 RC reserved (0)
Aug 24 15:33:44 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc 68:07:15:11:11:11, status: 0, reason: d11 RC reserved (0)

And the GUI seems a bit slow.

Wondering if there really have been ‭35,322‬ builds between May 13 with build 3.0.0.4.384.45717 and August 23 with build 3.0.0.4.384.81039, that is to close to 600 builds per working day

 

[hancox]

I upgraded the router followed by factory defaults and manual configure.
The Deauth / Auth / Assoc messages are back again:

Aug 24 15:33:44 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 68:07:15:11:11:11, status: 0, reason: Unspecified reason (1)
Aug 24 15:33:44 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth 68:07:15:11:11:111, status: 0, reason: d11 RC reserved (0)
Aug 24 15:33:44 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc 68:07:15:11:11:11, status: 0, reason: d11 RC reserved (0)

And the GUI seems a bit slow.

Concur. Skip this one until the inevitable Asus "oopsie" patch comes out.

 

[Grisu]

Wondering if there really have been ‭35,322‬ builds between May 13 with build 3.0.0.4.384.45717 and August 23 with build 3.0.0.4.384.81039, that is to close to 600 builds per working day

They just need a reason for 386.xxxxx running out with 384.99999 or this are seconds not builds.

 

[VANT]

And the GUI seems a bit slow.

same in 86u, but IMO not bit but very slow.

 

[camedia]

Yes, very slow on some pages.

 

[wouterv]

Defenitely something wrong in this build, here the CPU and RAM figures.
The dump is made without a WAN connection, also with a WAN connection and no active clients the figures are the same.
It shows frequent high CPU loads, mostly Core 2, sometimes also Core 1 without any external action of a client or the Internet:

With other firmware build the CPU load is usually low and only start to increase when there is really action initiated.
The router setup is very basic, no AiProtection active, no AiCloud.

 

[sanke1]

GUI sluggishness was the first thing I noticed. Maybe some form of planned obsolescence and forcing everyone to buy their faster AX based routers.

 

[Ronald Schwerer]

Defenitely something wrong in this build, here the CPU and RAM figures.
The dump is made without a WAN connection, also with a WAN connection and no active clients the figures are the same.
It shows frequent high CPU loads, mostly Core 2, sometimes also Core 1 without any external action of a client or the Internet:

With other firmware build the CPU load is usually low and only start to increase when there is really action initiated.
The router setup is very basic, no AiProtection active, no AiCloud.

Same here. I installed it on a 68U configured as a repeater. Couldn't log-in after installing & power cycle. So I did an NVRAM erase and wirelessly re-configured as a repeater, choosing to get an automatic IP (static in the router as 192.168.1.3). After reboot, still couldn't see it on my LAN, but could sign-in wirelessly in the GUI. I saw it still had an IP of 192.168.1.1, so I manually set it correctly and rebooted. After that, it worked as a repeater fine. Only a few low bandwidth clients connected. But when I logged-in to the GUI I saw core 2 CPU spiked to around 50% every 3 seconds. Due to this I decided not to install elsewhere and rolled the repeater back to 384_45717.

 

[Smokindog]

I've got a couple AC68's as APs that look similar. About every 5 seconds one of the CPUs jumps to 50% or more for about a second and then they return to near idle. Very repetitive pattern and very consistent between the APs.

Defenitely something wrong in this build, here the CPU and RAM figures.
The dump is made without a WAN connection, also with a WAN connection and no active clients the figures are the same.
It shows frequent high CPU loads, mostly Core 2, sometimes also Core 1 without any external action of a client or the Internet:

View attachment 19091
With other firmware build the CPU load is usually low and only start to increase when there is really action initiated.
The router setup is very basic, no AiProtection active, no AiCloud.

 

[wouterv]

And back to 3.0.0.4.384.45717 with exact the same manual configured settings, all quiet again:

RAM from 29% down to 26% for what it is worth.

 

[RMerlin]

Run "top" over SSH, you'll see what's causing the CPU spikes.

EDIT: Tested it here, and I don't get those CPU spikes. My router is 92% idle while on the main page, with 4% of CPU usage caused by httpd updating the system status page. Moving to a different page drops its usage to 1%, leaving the router idling at 97-98%, which is perfectly normal.

You will have to check with "top" to determine what is using your CPU.

 

[OzarkEdge]

Run "top" over SSH, you'll see what's causing the CPU spikes.

EDIT: Tested it here, and I don't get those CPU spikes. My router is 92% idle while on the main page, with 4% of CPU usage caused by httpd updating the system status page. Moving to a different page drops its usage to 1%, leaving the router idling at 97-98%, which is perfectly normal.

You will have to check with "top" to determine what is using your CPU.

Did you have Smart Connect enabled?

OE

 

[RMerlin]

Did you have Smart Connect enabled?

OE

Smart Connect does not exist on the RT-AC68U.

 

[OzarkEdge]

Smart Connect does not exist on the RT-AC68U.

Oops... I know that!

So, the CPU utilization observed on both 68U and 86U 81039 must not be related to Smart Connect (and the excessive channel scanning some are seeing).

OE

 

[wouterv]

Run "top" over SSH, you'll see what's causing the CPU spikes.

EDIT: Tested it here, and I don't get those CPU spikes. My router is 92% idle while on the main page, with 4% of CPU usage caused by httpd updating the system status page. Moving to a different page drops its usage to 1%, leaving the router idling at 97-98%, which is perfectly normal.

You will have to check with "top" to determine what is using your CPU.

Here you go:

81039: clearly httpd, the Apache HTTP server takes most CPU time, also explaining the slugish GUI response.

45717: nt_center is the top, but others are close.