What's new

ASUS RT-AC68U firmware release 3.0.0.4.385_10000-gd8ccd3c

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

LimJK

Very Senior Member
I got this from GUI update ... cannot see from Asus Support Website yet

Screenshot 2019-11-26 at 6.07.15 PM.png
 
nice....
 
that was fast, almost as fast as going from the 81039 FW to 81049. was there something as bad as the gui bug in 81039 or is it a security update related to some recent ddos attacks ?
 
I wasn't expecting a 385 track.
I was expecting directly a 386. At least the rumors were pointing to a soon-to-be-released 386.
 
Retrieved the changelog from their update server:

Code:
Firmware version 3.0.0.4.385_10000
- Release Note - 

1. Fixed firmware update issues.

That's, uh... interesting.
 
Firmware update issues? That's a bit cryptic....what issues? Reminds me of the Arlo (security camera system) firmware update notes that always say "Bug fixes", as if that was helpful.
 
- Fixed one thing
- Broke three others
;)
do you mean this? :p:p:p

upload_2019-11-26_19-37-31.png



NB: Very confused they left their regular way to makes steps by 2, so there should be 386 as we already saw some beta firmwares beginning with 386.
 
Last edited:
This is just my personal theory, but the RT-AC68U firmware update code has extra validation in place due to the numerous SKUs that share the same firmware model (for instance, that code will ensure that you will not try to flash an older RT-AC68U firmware which would not work on the newer revisions with a BCM4709C0 CPU). Could be that in preparation for the 386 release, they needed to push an update that adjusted that update code so future 386 releases can be applied.

Again, that is just a personal theory.
 
This is just my personal theory, but the RT-AC68U firmware update code has extra validation in place due to the numerous SKUs that share the same firmware model (for instance, that code will ensure that you will not try to flash an older RT-AC68U firmware which would not work on the newer revisions with a BCM4709C0 CPU). Could be that in preparation for the 386 release, they needed to push an update that adjusted that update code so future 386 releases can be applied.

Again, that is just a personal theory.

Hmmmm - "extra validation" makes me worry for something that rhymes with me-toe-bill.
 
Hmmmm - "extra validation" makes me worry for something that rhymes with me-toe-bill.

As I said, nothing nefarious there, it's essentially to prevent people from bricking their router by flashing an older firmware not supported by their hardware revision. The current version cutoff is at around 382_2000 if I recall (I forgot the exact revision). That's why it only applies to the RT-AC68U series specifically (older firmware is not compatible with the CPU used in newer revisions).
 
Okay, I got the same result (as below) when I installed 10000 on my main (68R) and AiMesh node (68U) routers, as I've had on all the firmware updates since 45717

=======
Installed 10000 over 45717... on both my main 68R snd AiMesh node 68U

My hardwired 68U node dropped it's wireless and hard wired connections, except the one to the main router.

Getting WLCEVENTD wlceventd_proc_event(420) & (449) entries on the wireless devices near the node in the system log. The 68U node's hardwired device is not on the device list in the Network Map.

Reinstalled 45717 on the node... My node's hardwired device came back on the Map.
Rebooted both routers.. Everything is connected again and no more WLCEVENTD messages...
=======

==> is this a "known" bug for the AiMesh node router?
==> Do I need to do something additional on the node to "fix it" post update?

Thanks!
>> Tom
 
Last edited:
I reviewed the visible (non-binary) changes in this release, it's essentially tied to libusb (which might impact plugged USB printers or modems), firmware upgrade process, and one change related to DFS channel and bridge mode.
 
Okay, I got the same result (as below) when I installed 10000 on my main (66R) and AiMesh node (66U) routers, as I've had on all the firmware updates since 45717
There is no 385.10000 or Aimesh for RT-AC66U or RT-AC66R, last one is: Version 3.0.0.4.382.51641
 
There is no 385.10000 or Aimesh for RT-AC66U or RT-AC66R, last one is: Version 3.0.0.4.382.51641
most likely talking about the 66U_B1 version
more reason that asus need to clean up their terrible naming scheme o_O
 
Okay, I got the same result (as below) when I installed 10000 on my main (66R) and AiMesh node (66U) routers, as I've had on all the firmware updates since 45717

=======
Installed 10000 over 45717... on both my main 66R snd AiMesh node 66U

My hardwired 66U node dropped it's wireless and hard wired connections, except the one to the main router.

Getting WLCEVENTD wlceventd_proc_event(420) & (449) entries on the wireless devices near the node in the system log. The 66U node's hardwired device is not on the device list in the Network Map.

Reinstalled 45717 on the node... My node's hardwired device came back on the Map.
Rebooted both routers.. Everything is connected again and no more WLCEVENTD messages...
=======

==> is this a "known" bug for the AiMesh node router?
==> Do I need to do something additional on the node to "fix it" post update?

Thanks!
>> Tom

I get the exact same issues with my setup that uses the RT-AC86U as my main router and the RT-AC68U as a wireless repeater. My hope is that ASUS makes a change that inadvertently fixes these issues, but so far the only solid firmware for me is 45717.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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