AC86U dcd tainted on Merlin 384.8_2

[LiFePO4]

I have been resisting the update to 384.9 due to the dcd crash being seen in it on the AC86U. But I just started seeing these crashes in my system log and I am on 384.8_2. So, are we really sure this is a new error in Asus'/Trend Micro code or is it something else external?

 

[Butterfly Bones]

Known issue:
https://www.snbforums.com/threads/release-asuswrt-merlin-384-9-is-now-available.54843/

Asuswrt-Merlin 384.9 is now available for all supported models. The focus of this release was merging newer GPLs, and implementing the new connection tracking report.

There is a number of known issues in this release that cannot be fixed at this time:

• dcd process crashing on RT-AC86U (bug in Trend Micro's code, outside of my control).
• Changelog is here.

Workaround:
https://www.snbforums.com/threads/script-to-remove-dcd-crashes-from-system-log.54734/#post-464413

 

[LiFePO4]

Known issue:
https://www.snbforums.com/threads/release-asuswrt-merlin-384-9-is-now-available.54843/

Workaround:
https://www.snbforums.com/threads/script-to-remove-dcd-crashes-from-system-log.54734/#post-464413

I know it is an issue on 384.9, thanks. I read the change log. I am saying it is happening on the previous version now as well. This was the reason I did NOT upgrade to 384.9...

 

[RMerlin]

Double check the log entry. It was probably the httpd process crashing in your case, not dcd. Different issue, which was resolved in 384.9.

Sent from my P027 using Tapatalk

 

[Butterfly Bones]

Double check the log entry. It was probably the httpd process crashing in your case, not dcd. Different issue, which was resolved in 384.9.

Sent from my P027 using Tapatalk

Not sure who you were replying to, sure looks like AC86U syslog states dcd crash to me:

Feb 11 07:20:46 kernel: dcd[29416]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Feb 11 07:20:46 kernel: pgd = ffffffc01140a000
Feb 11 07:20:46 kernel: [00000000] *pgd=0000000002155003, *pud=0000000002155003, *pmd=0000000002ce1003, *pte=0000000000000000
Feb 11 07:20:46 kernel: CPU: 1 PID: 29416 Comm: dcd Tainted: P           O    4.1.27 #2
Feb 11 07:20:46 kernel: Hardware name: Broadcom-v8A (DT)
Feb 11 07:20:46 kernel: task: ffffffc017067440 ti: ffffffc002a9c000 task.ti: ffffffc002a9c000
Feb 11 07:20:46 kernel: PC is at 0xf73c4f44
Feb 11 07:20:46 kernel: LR is at 0x1dc74
Feb 11 07:20:46 kernel: pc : [<00000000f73c4f44>] lr : [<000000000001dc74>] pstate: 600e0010
Feb 11 07:20:46 kernel: sp : 00000000ffa19078
Feb 11 07:20:47 kernel: x12: 000000000009ff10 
Feb 11 07:20:47 kernel: x11: 00000000f66ff024 x10: 00000000000a02b4 
Feb 11 07:20:47 kernel: x9 : 00000000f66ff670 x8 : 00000000000a076c 
Feb 11 07:20:47 kernel: x7 : 00000000f66ff6a8 x6 : 00000000000a0766 
Feb 11 07:20:47 kernel: x5 : 0000000000000000 x4 : 00000000f66ff654 
Feb 11 07:20:47 kernel: x3 : 0000000000000000 x2 : 00000000ffa19054 
Feb 11 07:20:47 kernel: x1 : 000000000007c674 x0 : 0000000000000000

 

[LiFePO4]

Double check the log entry. It was probably the httpd process crashing in your case, not dcd. Different issue, which was resolved in 384.9.

Sent from my P027 using Tapatalk

Here is the crash log and I am on 384.8_2.

Feb  9 21:34:49 kernel: pgd = ffffffc007bca000
Feb  9 21:34:49 kernel: [00000000] *pgd=000000000746a003, *pud=000000000746a003, *pmd=000000000896f003, *pte=0000000000000000
Feb  9 21:34:49 kernel: CPU: 1 PID: 8782 Comm: dcd Tainted: P           O    4.1.27 #2
Feb  9 21:34:49 kernel: Hardware name: Broadcom-v8A (DT)
Feb  9 21:34:49 kernel: task: ffffffc0170fea80 ti: ffffffc007a98000 task.ti: ffffffc007a98000
Feb  9 21:34:49 kernel: PC is at 0x29b7c
Feb  9 21:34:49 kernel: LR is at 0x29dfc
Feb  9 21:34:49 kernel: pc : [<0000000000029b7c>] lr : [<0000000000029dfc>] pstate: 20070010
Feb  9 21:34:49 kernel: sp : 00000000ffc902b0
Feb  9 21:34:49 kernel: x12: 00000000000a004c
Feb  9 21:34:49 kernel: x11: 0000000000080c34 x10: 000000000000002b
Feb  9 21:34:49 kernel: x9 : 0000000000000003 x8 : 000000000000002b
Feb  9 21:34:49 kernel: x7 : 00000000f5e0048c x6 : 0000000000000036
Feb  9 21:34:49 kernel: x5 : 0000000000000293 x4 : 00000000f5e004ec
Feb  9 21:34:49 kernel: x3 : 0000000000000000 x2 : 000000000000002a
Feb  9 21:34:49 kernel: x1 : 000000000000000a x0 : 0000000000000000

 

[FLA_NL]

I wonder if it has something to do with the signature update, if this is now also occuring on 384.8_2.

 

[RMerlin]

Here is the crash log and I am on 384.8_2.

This is indeed dcd. Then it's possible that for some users the version used in 384.8 was also unstable.

 

[FLA_NL]

If I look at my logs for 384.9, the crashes did stop at 03:49 CET. Before that they where occuring regularly.

Edit:
Had no errors for quite some time, after I had to reboot the router they where back again...

 

[Bong!]

Not everyone is an Asus specialist...."dcd" application, "dcd" application...: what is "dcd" application, what is it used for?

 

[Butterfly Bones]

Not everyone is an Asus specialist...."dcd" application, "dcd" application...: what is "dcd" application, what is it used for?

TrendMicro CLOSED source as RMerlin already states, so you need to ask TrendMicro.

https://www.snbforums.com/threads/release-asuswrt-merlin-384-9-is-now-available.54843/

"There is a number of known issues in this release that cannot be fixed at this time:"

• dcd process crashing on RT-AC86U (bug in Trend Micro's code, outside of my control).
• IPv6s on Tracked Connections have their last two bytes set to 00 (bug in Trend Micro's code truncating the last two bytes).
• No IPS events logged (bug in Asus's code, IPS should work, just fails to log hits)
• Networkmap listing may be unreliable. (Bug in Asus's code)
• Users failing to read changelogs will probably complain about the above issues. (Outside of my control).
  

 

[Bong!]

I read the Merlin's text, but...what is "dcd" application, what is it used for?

 

[AndreiV]

I read the Merlin's text, but...what is "dcd" application, what is it used for?

• dcd process crashing on RT-AC86U (bug in Trend Micro's code, outside of my control)..........
  
  AiProtection/QOS/Traffic Analysis.
  
  

 

[Bong!]

Thanks!
And also Download Master? All Trend Micro's application?
I would have expected more seriousness from ASUS, a subcontractor problem should not become a customer problem!

 

[blue166]

What version of Asus Firmware introduced this issue in the first place?

 

[GxlactusDa]

What version of Asus Firmware introduced this issue in the first place?

Bro I’m getting the same stupid issue on 384.6, stock firmware 21140 like what is the issue. Wtf is causing this problem. Apparently the issue was only present on 384,9 but isnt it’s like a virus.

 

[Ronald Schwerer]

"IT'S BAACK!!!". I just installed 384.19 on an RT-AX3000 and today I noticed the logs caused by dcd crashing. BTW, the script mentioned in the other thread as a "workaround" isn't working for me. I suspect the message format is slightly different.
I've got a simpler one-step work-around. Step 1: don;t look in the System Log!
It's just as effective.

Or - turn-off AiProtection. Just tried that 30 minutes ago and no more crashes.

 

[cooloutac]

just got this too. ac86u with 384.19. already had qos and ai protection turned off. but i had traffic analyzer statistics on. so turned that off hope it fixes it. exactly when this happened, my desktop pc on ethernet hard reset. wow.

are you guys using vpn on some devices too? wonder if its related, big brother? lmao...

 

[Butterfly Bones]

are you guys using vpn on some devices too? wonder if its related, big brother? lmao...

I run a full time VPN on my router for all devices except a smart TV, and have no dcd crashes after turning off AI Protection.

 

[cooloutac]

I run a full time VPN on my router for all devices except a smart TV, and have no dcd crashes after turning off AI Protection.

turning off my ai protection and qos fixd my original post of the more serious crash and router rebooting. https://www.snbforums.com/posts/626386/ never noticed a dcd crash until now but i probably just missed it among the noise. which i've cut down on. i'm assuming you do not have traffic analyzer statistics turned on. at least i hope thats what its related to and i will be keeping an eye out.

i would criticize asus for all these features ,which are main selling points of the router, for not being functional if i wasn't using a 3rd party firmware with almost all my devices on vpn. lol which kind of makes them all pointless anyways. But i didnt' get crashes using stock and i don't believe i was running vpn on it very long cause no policy rules. i would test that further but i bought this router to use with merlins vpn policy rules to put some devices to wan which i mostly use the vpn vendor's apps on. I think its all suspcious but i wear a tinfoil hat. I use to live lke a monk but realize life is too short and i missed out on nice things. But i still can't turn off my consciousness.