Release Asuswrt-Merlin 386.12 is now available for AC models

[Howard_inGA]

So, put in the 2nd update with TrendMicro off. Clean logs and smooth ops.

I've just turned on the TM engine and am waiting to see...
After 15 minutes, here are the only new log entries:

Nov 8 12:57:55 kernel: *** ERROR: [tdts_shell_ioctl_sig_op_load:95] tdts_core_rule_parsing_trf_load() fail!
Nov 8 12:57:55 kernel: SHN Release Version: 2.0.2 3a73e78
Nov 8 12:57:55 kernel: UDB Core Version: 0.2.20
Nov 8 12:57:55 kernel: sizeof forward pkt param = 192

Hope this continues, cause it is working for now!!

 

[langesgnu]

so I have the firmware now running for ~22h, but did reboot 6 hours ago. after installation I started QoS and ~1 hour later asd crashed. after the reboot, I used the router for some time and got upset with the low speed of my 2.4 Ghz connection and/or internet connection and did withdraw from the TM agreement, immediately the performance of my 2.4 Ghz clients is up as expected. then I tried to test it once more and started QoS again, but saw the same behavior as before (asd crash after 1 hour and low performance of wirless clients).

if the TM features are doing what they should is not clear for me either, but I do not see anything strange here. in any case, as long as enabling TM leads to unusable wireless networks, I have to turn it off to get proper internet speeds.

 

[Howard_inGA]

So, put in the 2nd update with TrendMicro off. Clean logs and smooth ops.

I've just turned on the TM engine and am waiting to see...
After 15 minutes, here are the only new log entries:

Nov 8 12:57:55 kernel: *** ERROR: [tdts_shell_ioctl_sig_op_load:95] tdts_core_rule_parsing_trf_load() fail!
Nov 8 12:57:55 kernel: SHN Release Version: 2.0.2 3a73e78
Nov 8 12:57:55 kernel: UDB Core Version: 0.2.20
Nov 8 12:57:55 kernel: sizeof forward pkt param = 192

Hope this continues, cause it is working for now!!

Well, wifi got weird, deleted EULA (Admin, Privacy) and the alpha is smooth as silk again, with no additional log packing...

 

[RMerlin]

and ~1 hour later asd crashed.

asd is unrelated to Trend Micro. It's the security daemon from Asus.

 

[Woody]

Asus are going to try a different approach at working around the issue. I'll try to get at least an RT-AC68U test build ready before heading to bed, and will compile the other ones tomorrow. For now I'll remove the current test builds to avoid any confusion.

@Woody The improvements you are seeing with the latest 386.12_1 alpha are probably due to one of these updates/fixes from https://github.com/RMerl/asuswrt-merlin.ng/blob/386.12_x/Changelog-386.txt

I am confused (situation normal for me..)

Changelog https://github.com/RMerl/asuswrt-merlin.ng/blob/386.12_x/Changelog-386.txt is for 386.12_2 - and doesn't mention anything specifically about the AC86U - although it mentions the crashing across all models.

This alpha that I am now running (released last night) is RT-AC86U_386.12_1 - so are you saying that the _2 release notes are for this _1 build as well?

Apologies if I am being particularly dense.

 

[RMerlin]

Changelog https://github.com/RMerl/asuswrt-merlin.ng/blob/386.12_x/Changelog-386.txt is for 386.12_2

Odd minor revisions = test builds, even minor revisions = final release.

 

[Calkulin]

asd is unrelated to Trend Micro. It's the security daemon from Asus.

Maybe unrelated but the crashing of ASD is new to this latest test build, so something is causing it to crash as all 6 of my routers on the latest test build have ASD crashing a little over an hour following a reboot. And it happens after every reboot only once

 

[maxbraketorque]

Maybe unrelated but the crashing of ASD is new to this latest test build, so something is causing it to crash as all 6 of my routers on the latest test build have ASD crashing a little over an hour following a reboot. And it happens after every reboot only once

Ever since installing 386.12 (the release version) on one of my AC86Us several months ago, asd has been routinely crashing (every hour or less). So I wouldn't say the asd crash is new. Rather, for some reason, its becoming more widespread.

 

[KrypteX]

Can we rule out that the asd crash has absolutely nothing to do with the dcd issue?

 

[Icemanz]

FWIW on my RT-AC68U the 386.12 release caused the DCD crashing due to my use of the traffic analyzer (none of the other features) 386.12_1-g0251ee445a has apparently stopped that crashing.

 

[AMP]

I suspect that TP-Link ran into a similar issue with their Broadcom-based AC routers with the HomeCare feature. HomeCare is their Trend Micro system that’s equivalent to AI Protection (not to be confused with HomeShield which is on some of their other models and is Avira-based).

In September and October, TP-Link released firmware updates for most of the HomeCare models. For many routers, this was the first update they’ve seen in three or four YEARS! TP-Link isn’t as forthcoming as ASUS with changelogs, but “enhanced HomeCare stability” and “renewal certificate” are mentioned.

This doesn’t help with the ASUS DCD issue, but I thought it was interesting.

 

[RMerlin]

Nov 12th:: 386.12_2 is now available. This resolves the constant dcd crashes.

386.12_2 (12-Nov-2023)
  - UPDATED: openssl to 1.1.1w.
  - UPDATED: curl to 8.4.0.
  - UPDATED: openvpn to 2.6.7.
  - FIXED: WPS not working on SDK6/SDK7 devices (affecting
           RT-AC68U and RT-AC88U/3100/5300)
  - FIXED: dcd constantly crashing (updated Trend Micro
           components)

 

[Viktor Jaep]

Nov 12th:: 386.12_2 is now available. This resolves the constant dcd crashes.

386.12_2 (12-Nov-2023)
  - UPDATED: openssl to 1.1.1w.
  - UPDATED: curl to 8.4.0.
  - UPDATED: openvpn to 2.6.7.
  - FIXED: WPS not working on SDK6/SDK7 devices (affecting
           RT-AC68U and RT-AC88U/3100/5300)
  - FIXED: dcd constantly crashing (updated Trend Micro
           components)

Thanks @RMerlin! Quick question... what's the best way to grab the current firmware/build version from nvram? What's the best way to get to that minor version (12_2) officially?

nvram get firmver
3.0.0.4
nvram get buildno
386.12

nvram show | grep "12_2"
webs_state_info=3004_386_12_2
webs_state_info_am=386_12_2

 

[Gnome10]

As a software engineer, I have a ton of respect for what you do, and your contribution to the networking community. Just wanted to say that.

This bug, in the Asus stock firmware, has been constantly causing a pain in my ***.

Is there any way to download the factory fix for it? For the stock firmware?

 

[visortgw]

Nov 12th:: 386.12_2 is now available. This resolves the constant dcd crashes.

386.12_2 (12-Nov-2023)
  - UPDATED: openssl to 1.1.1w.
  - UPDATED: curl to 8.4.0.
  - UPDATED: openvpn to 2.6.7.
  - FIXED: WPS not working on SDK6/SDK7 devices (affecting
           RT-AC68U and RT-AC88U/3100/5300)
  - FIXED: dcd constantly crashing (updated Trend Micro
           components)

@RMerlin It doesn't appear that 386.12_2 builds have been uploaded to OneDrive.

 

[RMerlin]

What's the best way to get to that minor version (12_2) officially?

The variable containing it is extendno .

Is there any way to download the factory fix for it? For the stock firmware?

Stock firmware with this fix are currently still undergoing QA. Look for the following releases once they are finalized:

@RMerlin It doesn't appear that 386.12_2 builds have been uploaded to OneDrive.

I'll check later, my NAS's Onedrive sync service is probably stopped/disconnected, so the folder didn't get synced upstream.

 

[RMerlin]

Looking at that list, that reminds me that I forgot to update the RT-AC68U_V4 components... I'll need to generate them, and re-issue the RT-AC68U image for those with that (fairly uncommon) model.

 

[Martinski]

Ever since installing 386.12 (the release version) on one of my AC86Us several months ago, asd has been routinely crashing (every hour or less). So I wouldn't say the asd crash is new. Rather, for some reason, its becoming more widespread.

Yeah, I've noticed that as well. As a temporary workaround, I've resorted to stopping the ASD process execution with the following code (running every 2 hours via a cron job):

#!/bin/sh
######################################################################
# STOP_ASD.sh
# Temporary workaround for 386.12 version until a fix is provided.
#--------------------------------------------------------------------#
LOG_TAG="${0##*/}"
if [ -z "$(pidof asd)" ]
then
    logger -t "${LOG_TAG}_[$$]" "ASD process not found." ; exit 0
fi
if [ "$(ps | grep "asd" | grep -v "grep" | awk -F ' ' '{print $4}')" != "T" ]
then
    kill -STOP $(pidof asd)
    logger -t "${LOG_TAG}_[$$]" "Stopping ASD [$(pidof asd)]..."
else
    logger -t "${LOG_TAG}_[$$]" "ASD [$(pidof asd)] is stopped."
fi
exit 0
#EOF#

So far no issues.

Just FYI.

 

[heysoundude]

Nov 12th:: 386.12_2 is now available. This resolves the constant dcd crashes.

386.12_2 (12-Nov-2023)
  - UPDATED: openssl to 1.1.1w.
  - UPDATED: curl to 8.4.0.
  - UPDATED: openvpn to 2.6.7.
  - FIXED: WPS not working on SDK6/SDK7 devices (affecting
           RT-AC68U and RT-AC88U/3100/5300)
  - FIXED: dcd constantly crashing (updated Trend Micro
           components)

lol so much for going to bed early...
updated AC86, and rebooted - significantly faster than before.
Not certain it was the update or other network changes I've made today, but the reboot was bazinga! speed

 

[maxbraketorque]

Yeah, I've noticed that as well. As a temporary workaround, I've resorted to stopping the ASD process execution with the following code (running every 2 hours via a cron job):

#!/bin/sh
######################################################################
# STOP_ASD.sh
# Temporary workaround for 386.12 version until a fix is provided.
#--------------------------------------------------------------------#
LOG_TAG="${0##*/}"
if [ -z "$(pidof asd)" ]
then
    logger -t "${LOG_TAG}_[$$]" "ASD process not found." ; exit 0
fi
if [ "$(ps | grep "asd" | grep -v "grep" | awk -F ' ' '{print $4}')" != "T" ]
then
    kill -STOP $(pidof asd)
    logger -t "${LOG_TAG}_[$$]" "Stopping ASD [$(pidof asd)]..."
else
    logger -t "${LOG_TAG}_[$$]" "ASD [$(pidof asd)] is stopped."
fi
exit 0
#EOF#

So far no issues.

Just FYI.

Thanks. Should be better than letting asd crash. If I'm still seeing asd crashes after upgrading to 12_2, I'll implement this.