Release Asuswrt-Merlin 386.12 is now available for AC models

[hoot_spoot]

At this point it's just best to upgrade to AX. AC routers are hitting End of Life pretty quickly now and support is ending.

What's an economical AX router?

 

[L&LD]

RT-AX68U for anything less than ~600Mbps is a very good model with RMerlin support.

 

[Tireless Hyena]

Probably because there`s no real reason for anyone to still be on 386.11, so probably a very small installed userbase.

The issue mostly manifest itself by filling up the system log, so most people aren`t even aware of the issue. Asus tested a specific older stock firmware which also had the issue, however neither of us started going further back in time, as we already knew enough - that the issue wasn`t from a regression, and was on Trend Micro`s side.

Hello,
There's me (3 sites 1000 km apart), I like the old versions
The problem exists on my three 386.7_2 AC68Us.
NOT on my two AC386U in 384.19.
Hardware dependency?

 

[rkalinka]

If I am reading this right... it will allow me to re-enable my traffic analyzing and remove the process causing the crashes?

I tried Merlins "tmpdcd" fix - it appears to be working for me. For whatever reason, turning off AiProtect did NOT have any impact. I am not sure what the dcd process actually does (anyone know?), so unclear what the "real" impact is - however putting it to sleep seems to have allowed my syslog to contain usable information rather than being flooded with those dcd errors. If I see things correctly, a simple reboot of the router will undo the change for testing purposes on a later firmware.

Additional note - Opening an Asus service ticket was useless as they told me to hard reset the ENTIRE AiMesh system and MANUALLY re-enter all my configuration information to see if the problem persists - which I cannot really do as this network is being used by multiple people (and I have a lot of configs to put back manually).

At present, I have AiProtect AND Traffic analyser - things seem to be working "fingers crossed".

 

[bennor]

For whatever reason, turning off AiProtect did NOT have any impact.

You may also need to click on the "withdraw" button, if present, under Administration > Privacy to fully withdraw from AiProtection.

 

[L&LD]

And after 'withdrawing', possibly reboot (via the GUI) too.

 

[rkalinka]

You may also need to click on the "withdraw" button, if present, under Administration > Privacy to fully withdraw from AiProtection.

I did that for the AiProtect feature - no change. However, there was another "withdraw" button that had Traffic Analyzer in it - i do use that to monitor stuff on my network - so I left that in place. (To your point, I may have had to withdraw from both). In any case, I just did Merlins "tmpdcd"fix and seem to have the best of both worlds.

 

[fizix610]

After performing the tmpdcd fix, I get thousands of these zombie processes spawning until my router becomes unresponsive:

32654 admin        0 Z    [shn_ctrl]
32661 admin        0 Z    [shn_ctrl]
32663 admin        0 Z    [shn_ctrl]

That process appears to be related to AIProtect in some way.

 

[RocketJSquirrel]

After performing the tmpdcd fix, I get thousands of these zombie processes spawning until my router becomes unresponsive:

32654 admin        0 Z    [shn_ctrl]
32661 admin        0 Z    [shn_ctrl]
32663 admin        0 Z    [shn_ctrl]

That process appears to be related to AIProtect in some way.

You made me look. I have a couple dozen of these also, but not thousands.

On my 68U, they seem to come and go. I can issue ps commands and sometimes all the shn_ctrls have disappeared. Then later, they come back. I wonder what they are.

 

[bscabl]

You made me look. I have a couple dozen of these also, but not thousands.

On my 68U, they seem to come and go. I can issue ps commands and sometimes all the shn_ctrls have disappeared. Then later, they come back. I wonder what they are.

made me look too.. nothing on mine like these.

 

[fizix610]

made me look too.. nothing on mine like these.

Odd. So far, I haven't had the issue since I disabled AIProtect by opting out of the privacy policy.

 

[RMerlin]

Please give these test builds a try: https://www.asuswrt-merlin.net/test-builds/ . They contain an updated TrendMicro engine + certificate which should resolve the constant dcd crashes. Asus and I tested the RT-AC68U over the past few days, and aside from an occasional single crash, dcd is (mostly) stable now.

 

[RocketJSquirrel]

Please give these test builds a try:

Looking good so far. Haven't seen any dcd crashes. ps shows 6 instances of dcd, all saying

3476 S    dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/

Of course, I have no idea what dcd is or what that means.

 

[Howard_inGA]

So, I put the new alpha to work just now. So far, smooth with no crashes and a clean log after the TrendMicro restart...

 

[RocketJSquirrel]

I spoke too soon. The messages are back despite the fact that I continue to have dcd processes apparently running.

Nov 5 11:25:26 kernel: dcd/8254: potentially unexpected fatal signal 6.
Nov 5 11:25:26 kernel: dcd/8247: potentially unexpected fatal signal 6.
Nov 5 11:25:26 kernel: dcd/8246: potentially unexpected fatal signal 6.
Nov 5 11:25:26 kernel: dcd/8243: potentially unexpected fatal signal 6.
Nov 5 11:25:26 kernel: dcd/8245: potentially unexpected fatal signal 6.

 

[RMerlin]

I spoke too soon. The messages are back despite the fact that I continue to have dcd processes apparently running.

Nov 5 11:25:26 kernel: dcd/8254: potentially unexpected fatal signal 6.
Nov 5 11:25:26 kernel: dcd/8247: potentially unexpected fatal signal 6.
Nov 5 11:25:26 kernel: dcd/8246: potentially unexpected fatal signal 6.
Nov 5 11:25:26 kernel: dcd/8243: potentially unexpected fatal signal 6.
Nov 5 11:25:26 kernel: dcd/8245: potentially unexpected fatal signal 6.

That's a single crash (for all of its child threads). It still happens occasionally, but you should see no other crash after that, while before it would immediately crash as it got restarted two minutes later.

 

[Calkulin]

Please give these test builds a try: https://www.asuswrt-merlin.net/test-builds/ . They contain an updated TrendMicro engine + certificate which should resolve the constant dcd crashes. Asus and I tested the RT-AC68U over the past few days, and aside from an occasional single crash, dcd is (mostly) stable now.

I updated all the AC routers, 4x RT-AC68Us and 2x RT-AC88U and they are all still crashing DCD consistently with signature 2.372, so no change with these test builds for me

 

[RMerlin]

they are all still crashing DCD consistently

Define "consistently", Do you mean that it crashes once within the hour, and regularly crashes more times later on, or only during that initial first hour? Because following the change, neither Asus' engineer or myself could get it to crash as regularly as it used to do before the upgrade. My RT-AC66U_B1 just broke 24 hours without any dcd crashes when I turned it off earlier tonight. Before the change, my test router would start crashing within the first hour, and after that it would crash again immediately every two minutes when the watchdog was restarting it.

The signature version has nothing to do with it BTW.

 

[Calkulin]

Define "consistently", Do you mean that it crashes once within the hour, and regularly crashes more times later on, or only during that initial first hour? Because following the change, neither Asus' engineer or myself could get it to crash as regularly as it used to do before the upgrade. My RT-AC66U_B1 just broke 24 hours without any dcd crashes when I turned it off earlier tonight. Before the change, my test router would start crashing within the first hour, and after that it would crash again immediately every two minutes when the watchdog was restarting it.

The signature version has nothing to do with it BTW.

It's still crashing every few mins or so like before the update,

 

[Howard_inGA]

It's still crashing every few mins or so like before the update,

Same for me. I again removed TrendMicro, then rolled back to the stable release...