ASUS RT-AC68U firmware release 3.0.0.4.385_10000-gd8ccd3c

[DANIEL BYRNS]

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.

Same here as a previous post everything past 717 I lose my movie server on the router due to the smba upgrade they do

 

[tom.moughan]

Greetings!

SUCCESS! I've updated both of my routers to the 3.0.0.4.385_10000 firmware and my AiMesh node now stays connected to all its devices.

Guess I missed the step where one needs to factory reset the router after a firmware update. I factory reset the RT-AC68U node, then my main RT-AC68R, ran through setup, and everything has stayed connected at the node.

>> Tom

Still getting tons of WLCEVENTD messages but no disconnects

 

[Ronald Schwerer]

Still getting tons of WLCEVENTD messages but no disconnects

Try setting log_level to 5. I haven't seen a single WLCEVENTD message with that log_level.

nvram set log_level=5;nvram commit;reboot

I first installed 385.10000 on my 68U repeater and got lots of WLCEVENTD messages (every time a client connected or disconnected). When I installed 385.10000 on my 68U main router, I didn't see any of those messages. When I checked for differences in log_level, I saw that I had (long ago) set the main router's log_level to 5. So I set it to 5 in the repeater and rebooted. No more WLCEVENTD!

I still get the normal (routine) logging such as service restarts, log-in attempts, etc.

 

[tom.moughan]

Thanks, Ronald!

(Now I have to figure out how to do THAT! Reading up on SSH now...)

 

[VANT]

this build work ok with my 68u (node). No 2.4GHz disconections for now.

 

[wouterv]

Try setting log_level to 5. I haven't seen a single WLCEVENTD message with that log_level.

nvram set log_level=6;nvram commit;reboot

I first installed 385.10000 on my 68U repeater and got lots of WLCEVENTD messages (every time a client connected or disconnected). When I installed 385.10000 on my 68U main router, I didn't see any of those messages. When I checked for differences in log_level, I saw that I had (long ago) set the main router's log_level to 6. So I set it to 6 in the repeater and rebooted. No more WLCEVENTD!

I still get the normal (routine) logging such as service restarts, log-in attempts, etc.

The default log_level is 6, the higher the number, the more is shown in the log.
5 = more silent
6 = default, showing WLCEVENTD events
7 = adding dnsmasq-dhcp events
Maybe RMerlin can tell more about the specifics of the different log_levels.

 

[Ronald Schwerer]

The default log_level is 6, the higher the number, the more is shown in the log.
5 = more silent
6 = default, showing WLCEVENTD events
7 = adding dnsmasq-dhcp events
Maybe RMerlin can tell more about the specifics of the different log_levels.

Ooops! I mis-typed. Yes I meant to say, set it to 5. I fixed my post. Thanks.

 

[tom.moughan]

Ooops! I mis-typed. Yes I meant to say, set it to 5. I fixed my post. Thanks.

Used Ubuntu (for Windows 10) to reset the log_level to 5, and the WLCEVENTD messages mostly disappeared. I found the SSH how to details on one of Merlin's Wiki pages. Easy! Thanks again!

 

[wouterv]

System Log severity levels are explained here:
https://en.wikipedia.org/wiki/Syslog#Severity_level

 

[Ronald Schwerer]

System Log severity levels are explained here:
https://en.wikipedia.org/wiki/Syslog#Severity_level

Thanks. So I presume setting log_level=5 will show message severity 0 (Emergency) through 5 (Notice), ignoring messages which are just Informational or Debug. As a former coder, I realize that the severity level is just whatever the developer feels at the moment - not necessarily what a user would expect.

 

[wouterv]

Thanks. So I presume setting log_level=5 will show message severity 0 (Emergency) through 5 (Notice), ignoring messages which are just Informational or Debug. As a former coder, I realize that the severity level is just whatever the developer feels at the moment - not necessarily what a user would expect.

Yes right, with every higher number more message types are added to the log.
I believe RMerlin said somewhere that Asus does not strictly follow RFC 5424 for the severity levels, it is a programmers decision to assign messages to a level.

 

[Elrendhel]

I've read thru this thread a couple of times and I'm still very confused. The OP says he sees the upgrade available from the GUI but not from the support site, and I'm seeing the same thing. When I go to the Merlin site, it still shows the 384.14 as the most recent version for RT-AC68U Routers,

I bought my AC68U via Craigslist and the previous owner had already updated the firmware to 385_10000, so I left it alone. But now I see that it doesn't really exist, at least in terms of what Merlin is documenting.

Can someone clarify if this is legit? Should I downgrade from 385_10000 to 384.14?

 

[dave14305]

I've read thru this thread a couple of times and I'm still very confused. The OP says he sees the upgrade available from the GUI but not from the support site, and I'm seeing the same thing. When I go to the Merlin site, it still shows the 384.14 as the most recent version for RT-AC68U Routers,

I bought my AC68U via Craigslist and the previous owner had already updated the firmware to 385_10000, so I left it alone. But now I see that it doesn't really exist, at least in terms of what Merlin is documenting.

Can someone clarify if this is legit? Should I downgrade from 385_10000 to 384.14?

You're mixing Merlin versions with Asus stock versions. Merlin's 384.14 is equivalent to Asus 384_81351.

 

[Elrendhel]

You're mixing Merlin versions with Asus stock versions. Merlin's 384.14 is equivalent to Asus 384_81351.

I can totally accept that, but where does 385_10000 come from?

 

[dave14305]

I can totally accept that, but where does 385_10000 come from?

It’s ASUS’ latest release, but too late for inclusion in 384.14.

 

[dosborne]

where does 385_10000 come from?

You should see it in this Asus link:
https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/

Version 3.0.0.4.385.10000 2019/11/26 40.19 MBytes

(Keeping in mind that, as already mentioned, this is Asus FW, not Merlin FW)

 

[sidewinder]

recently started using aimesh on 2 x rt-ac68u and started getting bunch of wlceventd disassociations hourly from multiple devices. was running latest merlin 384.14 on both router/node and changed both to this official firmware but was still getting same drops. so as some mentioned, downgraded to 3.0.0.4.384_45717 first on the node but still getting drops. then downgraded the router to same version and now not a peep. it appears the later versions are buggy with aimesh at least for the 68U.

EDIT: looks like 45717 its not logging any of the disassociation events by default which explains why the log is clean. later versions seems to log wlceventd by default which is why it shows up in the logs.

 

[wouterv]

Why does the router now indicate there are 2 clients connecting through the iPhone while the thing is all at its own?
The iPhone hotspot function is really OFF, I even tried to toggle it ON and OFF, with no difference.
Toggling the iPhone WiFi OFF make it disappear totally from the Client list, and togging ON again make it connect as below.
There is one entry for this iPhone in the Wireless Log (one IP address).
Other iPhones on the router do show as single device.

[EDIT]
No matter I "forget" the network on the phone and swap between 2.4 and 5 GHz or connect to a guest network of the router.

[EDIT2]
Factory defults and manual configure the router again cleared the "2".

 

[lucluke]

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

Ran into the same thing, my ac68u hardwired node would disconnect all wireless clients after a while (less than a day) until node restart, disabling universal beamforming and airtime fairness didn’t help.
Trying downgrading the ac68u hardwired node to 45717, thanks!

 

[tom.moughan]

Ran into the same thing, my ac68u hardwired node would disconnect all wireless clients after a while (less than a day) until node restart, disabling universal beamforming and airtime fairness didn’t help.
Trying downgrading the ac68u hardwired node to 45717, thanks!

View attachment 20429

Hey lucluke

My "obvious" solution was, after the upgrade to 10000, to do a factory reset (duh) on the node router first, then the main router, and no more disconnects!! ( see a later post from me.).

Also check previous posts on how to set a log_level parm to eliminate informational disconnect messages.

Tom