Release Asuswrt-Merlin 386.12 is now available for AC models

[heywire]

I asked for more details:

Kernel Panic and System Crash: The logs contain entries that are indicative of a kernel panic, specifically the lines mentioning "CPU: 1 PID: 27293 Comm: dcd Tainted: P O 4.1.27 #2" and following lines that detail the CPU register states at the time of the crash. A kernel panic is a safety measure taken by an operating system's kernel upon detecting an internal fatal error from which it cannot safely recover. The "Tainted: P O" message suggests that proprietary modules were loaded, and the crash might relate to these or other kernel-level issues. The specific cause of the kernel panic, however, isn't clear from the logs and would require further investigation, potentially with additional debugging tools or deeper system logs.

Not very specific, in other words. But neither were the logs. No indication of what could have caused the crash to occur.

I would have reset the router itself, but then I'd come up against MAJOR problems with pairing the AC66_B1, which for some reason absolutely refuses to be paired in Aimesh, even if AC68 works.

 

[heywire]

Anything in here that stands out?

For example:
Dec 11 22:52:48 rc_service: service 8794:notify_rc restart_firewall
?

Dec 11 22:52:48 kernel: pgd = ffffffc007623000
Dec 11 22:52:48 kernel: [00000168] *pgd=0000000011b9a003, *pud=0000000011b9a003, *pmd=00000000109cb003, *pte=0000000000000000
Dec 11 22:52:48 kernel: CPU: 1 PID: 8169 Comm: asd Tainted: P O 4.1.27 #2
Dec 11 22:52:48 kernel: Hardware name: Broadcom-v8A (DT)
Dec 11 22:52:48 kernel: task: ffffffc01e0840c0 ti: ffffffc016cd4000 task.ti: ffffffc016cd4000
Dec 11 22:52:48 kernel: PC is at 0xf70b516e
Dec 11 22:52:48 kernel: LR is at 0xf70807fc
Dec 11 22:52:48 kernel: pc : [<00000000f70b516e>] lr : [<00000000f70807fc>] pstate: 200f0030
Dec 11 22:52:48 kernel: sp : 00000000fff37818
Dec 11 22:52:48 kernel: x12: 00000000ffffffff
Dec 11 22:52:48 kernel: x11: 00000000fff37d14 x10: 000000000000001c
Dec 11 22:52:48 kernel: x9 : 00000000ffffffff x8 : 000000000000016d
Dec 11 22:52:48 kernel: x7 : 0000000000000000 x6 : 00000000fff37d20
Dec 11 22:52:48 kernel: x5 : 0000000000000073 x4 : 0000000000000005
Dec 11 22:52:48 kernel: x3 : 0000000000000000 x2 : 0000000000000001
Dec 11 22:52:48 kernel: x1 : 0000000000000168 x0 : 000000000000016d
Dec 11 22:52:48 kernel: CPU: 1 PID: 8169 Comm: asd Tainted: P O 4.1.27 #2
Dec 11 22:52:48 kernel: Hardware name: Broadcom-v8A (DT)
Dec 11 22:52:48 kernel: task: ffffffc01e0840c0 ti: ffffffc016cd4000 task.ti: ffffffc016cd4000
Dec 11 22:52:48 kernel: PC is at 0xf70b516e
Dec 11 22:52:48 kernel: LR is at 0xf70807fc
Dec 11 22:52:48 kernel: pc : [<00000000f70b516e>] lr : [<00000000f70807fc>] pstate: 200f0030
Dec 11 22:52:48 kernel: sp : 00000000fff37818
Dec 11 22:52:48 kernel: x12: 00000000ffffffff
Dec 11 22:52:48 kernel: x11: 00000000fff37d14 x10: 000000000000001c
Dec 11 22:52:48 kernel: x9 : 00000000ffffffff x8 : 000000000000016d
Dec 11 22:52:48 kernel: x7 : 0000000000000000 x6 : 00000000fff37d20
Dec 11 22:52:48 kernel: x5 : 0000000000000073 x4 : 0000000000000005
Dec 11 22:52:48 kernel: x3 : 0000000000000000 x2 : 0000000000000001
Dec 11 22:52:48 kernel: x1 : 0000000000000168 x0 : 000000000000016d
Dec 11 22:52:48 rc_service: service 8794:notify_rc restart_firewall
Dec 11 22:54:21 kernel: pgd = ffffffc011549000
Dec 11 22:54:21 kernel: [00000000] *pgd=00000000115f9003, *pud=00000000115f9003, *pmd=0000000012da9003, *pte=0000000000000000
Dec 11 22:54:21 kernel: CPU: 1 PID: 8538 Comm: dcd Tainted: P O 4.1.27 #2
Dec 11 22:54:21 kernel: Hardware name: Broadcom-v8A (DT)
Dec 11 22:54:21 kernel: task: ffffffc01e052a80 ti: ffffffc0164d0000 task.ti: ffffffc0164d0000
Dec 11 22:54:21 kernel: PC is at 0xf72fdf44
Dec 11 22:54:21 kernel: LR is at 0x1dce0
Dec 11 22:54:21 kernel: pc : [<00000000f72fdf44>] lr : [<000000000001dce0>] pstate: 600b0010
Dec 11 22:54:21 kernel: sp : 00000000ff8ee878
Dec 11 22:54:21 kernel: x12: 00000000000a2050
Dec 11 22:54:21 kernel: x11: 00000000f65ff024 x10: 00000000000a23c4
Dec 11 22:54:21 kernel: x9 : 00000000f65ffcd8 x8 : 00000000000a287c
Dec 11 22:54:21 kernel: x7 : 00000000f65ffd0c x6 : 00000000000a2876
Dec 11 22:54:21 kernel: x5 : 0000000000000000 x4 : 00000000f65ffcbc
Dec 11 22:54:21 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Dec 11 22:54:21 kernel: x1 : 000000000007d72e x0 : 0000000000000000
Dec 11 22:54:21 kernel: CPU: 1 PID: 8538 Comm: dcd Tainted: P O 4.1.27 #2
Dec 11 22:54:21 kernel: Hardware name: Broadcom-v8A (DT)
Dec 11 22:54:21 kernel: task: ffffffc01e052a80 ti: ffffffc0164d0000 task.ti: ffffffc0164d0000
Dec 11 22:54:21 kernel: PC is at 0xf72fdf44
Dec 11 22:54:21 kernel: LR is at 0x1dce0
Dec 11 22:54:21 kernel: pc : [<00000000f72fdf44>] lr : [<000000000001dce0>] pstate: 600b0010
Dec 11 22:54:21 kernel: sp : 00000000ff8ee878
Dec 11 22:54:21 kernel: x12: 00000000000a2050
Dec 11 22:54:21 kernel: x11: 00000000f65ff024 x10: 00000000000a23c4
Dec 11 22:54:21 kernel: x9 : 00000000f65ffcd8 x8 : 00000000000a287c
Dec 11 22:54:21 kernel: x7 : 00000000f65ffd0c x6 : 00000000000a2876
Dec 11 22:54:21 kernel: x5 : 0000000000000000 x4 : 00000000f65ffcbc
Dec 11 22:54:21 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Dec 11 22:54:21 kernel: x1 : 000000000007d72e x0 : 0000000000000000

ChatGPT's opinion, for what it's worth:

The log entries you provided indicate additional instances of kernel panic. Let's break them down for clarity:

1. Repeated Kernel Panic Indications: Both sets of logs start with "pgd = ..." followed by a series of memory addresses and CPU register states. This is typically seen in kernel panic situations, where the kernel outputs its state at the time of a critical failure.
2. Tainted Kernel: The "Tainted: P O" message repeats in these logs as well, indicating that proprietary or out-of-tree modules are loaded into the kernel. These modules can sometimes be sources of instability, especially if they are not perfectly compatible with the kernel version or have bugs.
3. Process Information and Crash Location: The logs mention a process "asd" and "dcd" with different PID (Process ID) numbers. This suggests that the kernel panic is occurring in the context of these processes. The "PC is at" and "LR is at" lines indicate the Program Counter and Link Register at the time of the crash, pointing to the specific code address where the failure occurred.
4. Hardware Information: The mention of "Hardware name: Broadcom-v8A (DT)" provides a clue about the platform and hardware architecture. This might be relevant if the panic is related to hardware-specific drivers or operations.
5. No Direct Cause Visible: Despite these detailed logs, the direct cause of the kernel panic is not immediately evident. Understanding the specific trigger often requires cross-referencing the memory addresses with system symbols or analyzing the system with debugging tools.
6. Potential Actions: Given the repeated nature of these panics and their association with specific processes, it might be worth investigating these processes further. If they are part of third-party software or drivers, updating or reconfiguring them could be a solution. In some cases, consulting with the hardware or software vendor is necessary to resolve such deep-seated issues.
7. System Stability Concerns: Repeated kernel panics are a serious concern for system stability and should be addressed promptly. They can lead to system crashes, data loss, and reduced reliability.

In summary, these logs indicate a recurring kernel panic issue in your system, possibly linked to specific processes or drivers. Addressing this will likely require a combination of software updates, configuration changes, and possibly vendor support.

 

[Tech9]

With every firmware update you wait for some Asus fix and ignore my advice. Now your routers are perhaps on last firmware updates available before EoL and even more broken. A network with multiple apartments sharing one connection needs something better than a bunch of old home routers. RT-AC86U is the most unreliable Asus router released in recent years and RT-AC68U was kept alive for so long for AiMesh marketing purposes. Unfortunately, RT-AC68U and variants are statistically the most problematic devices in AiMesh. I hope ChatGPT will give you an advice to upgrade your equipment at some point. I'm not sure if it will be smart enough to suggest VLAN network segmentation per group of users on this multi-user shared network.

What you see above crashing is Asus' Security Daemon and TrendMicro's Data Collection Daemon. The firewall restarted due to ASD crash. Asus attempted to fix it with RT-AC68U firmware update. RMerlin ported the fixes to Asuswrt-Merlin. Why is your RT-AC86U crashing - ask ChatGPT. I don't know.

 

[heywire]

Are there any alternatives to Traffic Monitor which doesn't require the Trend Micro bs? I mainly want to retain the ability to see the amount of network traffic during the day.

Traffic Monitor seems like the only thing left that is using TM, as I use CakeQOS and have Aiprotection disabled (maybe that was the new default in the new 386.12_4 firmware meant to deal with that?).

 

[Tech9]

Traffic Monitor doesn't use TrendMicro engine. Traffic Analyzer does.

Traffic Monitor:

Traffic Analyzer:

 

[heywire]

Traffic Monitor doesn't use TrendMicro engine. Traffic Analyzer does.

Yes, I misspoke. Traffic Analyser - can I get said statistics-log functionality on how much data has been transferred by clients with any add-ons instead?

 

[Tech9]

I don't know any custom scripts doing per IP/MAC monitoring. This will require CPU traffic processing and will be NAT acceleration incompatible. Asuswrt-Merlin has it on your RT-AC68U hardware, but if you make one your main router the WAN-LAN throughput will be limited to about 200Mbps.

Asuswrt-Merlin Addon Software Catalog

Asus-Merlin Addon Software Catalog This sticky post functions as a software catalog (with links to threads, scripts, and author names), grouped by functionality, to make it easier for Asus-Merlin users to find and install addons for their Asus routers without having to search through massive...

www.snbforums.com

 

[heywire]

Just wish there was an option to use the built in Traffic Analyser without the Trend Micro sh:t, which then also presumably would be HW-acceleration compatible.

As far as I can tell, all it provides is the statistics over sites visited, which is an unwanted feature for privacy purposes anyways for me. But I haven't found a way to disable it without also loosing the ability to simply monitor the data transfer statistics in the network.

Don't know if there is a way to scalpel this out, but if you're listening, @RMerlin , I doubt I'm the only one wanting it, especially now with this other TM bugfest of late.

 

[heywire]

64 instances of this for the last 16 hours

rc_service: service 8194:notify_rc restart_firewall

The service # changes between instances.

Here is the log between one of the restart.commands.
(mac addresses has been anonymized, but the anonymized addresses are consistent):

Dec 12 14:16:46 rc_service: service 2073:notify_rc restart_firewall
Dec 12 14:16:48 wlceventd: wlceventd_proc_event(530): eth6: Auth 00:11:22:33:44:55, status: Successful (0), rssi:0
Dec 12 14:16:48 wlceventd: wlceventd_proc_event(540): eth6: ReAssoc 00:11:22:33:44:55, status: Successful (0), rssi:0
Dec 12 14:16:49 roamast: [EXAP]Deauth old sta in 1 0: 66:77:88:99:AA:BB
Dec 12 14:16:49 roamast: eth6: disconnect weak signal strength station [66:77:88:99:AA:BB]
Dec 12 14:16:49 roamast: eth6: remove client [66:77:88:99:AA:BB] from monitor list
Dec 12 14:16:49 wlceventd: wlceventd_proc_event(494): eth6: Deauth_ind 66:77:88:99:AA:BB, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-79
Dec 12 14:17:00 wlceventd: wlceventd_proc_event(530): eth6: Auth 66:77:88:99:AA:BB, status: Successful (0), rssi:0
Dec 12 14:17:00 wlceventd: wlceventd_proc_event(540): eth6: ReAssoc 66:77:88:99:AA:BB, status: Successful (0), rssi:0
Dec 12 14:17:06 bsd: bsd: Sending act Frame to 00:11:22:33:44:55 with transition target eth5 ssid 24:4b:fe:60:52:68
Dec 12 14:17:07 bsd: bsd: BSS Transit Response: ifname=eth6, event=156, token=e, status=6, mac=34:10:24:4b:fe:60
Dec 12 14:17:07 bsd: bsd: BSS Transit Response: STA reject
Dec 12 14:17:07 bsd: bsd: Skip STA:00:11:22:33:44:55 reject BSSID
Dec 12 14:17:07 kernel: pgd = ffffffc010a63000
... [remaining unchanged kernel log lines] ...
Dec 12 14:18:48 wlceventd: wlceventd_proc_event(494): eth6: Deauth_ind 00:11:22:33:44:55, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Dec 12 14:18:48 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 00:11:22:33:44:55, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
... [remaining unchanged kernel log lines] ...
Dec 12 14:20:43 kernel: pgd = ffffffc016678000
... [remaining unchanged kernel log lines] ...
Dec 12 14:20:44 rc_service: service 2680:notify_rc restart_firewall

 

[JTnola]

This is slightly different than what was implied in your previous post. You said the Apple TV was getting a "random IP address" which we assumed was in your LAN's 192.168.x.y range. However 169.254.x.y is not a random address. It is a self assigned address that the device gives to itself when it cannot get a reply from a DHCP server. This usually means that the device has no connection to the network (e.g. a cable fault) or the DHCP server is offline.

Ok. Thank you.

And you don’t think that there’s any change between 386.12 & 386.12_4 that could inadvertently be causing the Apple TV to sometimes fail to get a reply from the DHCP server? Some LAN setting?

 

[bennor]

And you don’t think that there’s any change between 386.12 & 386.12_4 that could inadvertently be causing the Apple TV to sometimes fail to get a reply from the DHCP server? Some LAN setting?

You may want to, if you haven't done so already, check any Apple TV updates that happened recently to see if it's something on the Apple TV's side that is causing the issue.

 

[ColinTaylor]

And you don’t think that there’s any change between 386.12 & 386.12_4 that could inadvertently be causing the Apple TV to sometimes fail to get a reply from the DHCP server? Some LAN setting?

I can't think of anything that would cause such behaviour for an ethernet connected device. Have you tried plugging the Apple TV into a different LAN port on the router?

 

[JTnola]

I can't think of anything that would cause such behaviour for an ethernet connected device. Have you tried plugging the Apple TV into a different LAN port on the router?

Yup.

You may want to, if you haven't done so already, check any Apple TV updates that happened recently to see if it's something on the Apple TV's side that is causing the issue.

There hasn’t been. (There was one earlier this wk, but the issue predates that. Plus i only installed it yesterday.)

——————


The weirdest part for me is that it’s only rectified by rebooting the router—not by rebooting the appleTV. Simply using scMerlin to restart the DHCP/DNS server (or any/all other services) alone is not sufficient to right the problem. Nor is setting the IP address manually on the AppleTV. Only rebooting the router gets the job done.

Also , I can’t discern why it happens sometimes and not others. Sometimes the Apple TV will be in standby all night and it has no problem. other times it’s down for a much shorter period, but when I go to use it, it’s not connected.

And none of this had happened prior to 386.12_4 …… (though of course that could be a coincidence. I don’t know that the issue started immediately after the update since I’m not watching tv every day & since the problem does *not* manifest every single time I go to use the Apple tv. . All I know is that when it first began, it was within a day or two of my having updated.)

Thank you all for trying to think this through with me.

 

[banger]

Log gone all quiet on 12_4 apart from a smart bulb which disconnects every 15 mins after a firmware update.

 

[banger]

After 27 days on 12_4 at precisely 3pm 23/12/23 all my clients and nodes disappeared from the master. A reboot saw all clients reconnect and nodes.

 

[bibikalka]

After 27 days on 12_4 at precisely 3pm 23/12/23 all my clients and nodes disappeared from the master. A reboot saw all clients reconnect and nodes.

Probably a good opportunity to upgrade to 12_6

 

[L&LD]

12_6?

 

[banger]

Well reboot scheduler works. Might have to use after testing for another 27 days.

 

[banger]

Wifi Scheduler works I wonder if this is a solution to the disappearing wifi problem I have experienced and noted earlier in this thread.

 

[rn170uk]

RT-AC86U. 386.12_4. 5Ghz WiFi is intermittently dropping out. Should I back out back to 12 (_0) or is there another fix. Didn't read all the pages, but I see others reporting WiFi stability issues. (it died again trying to post this)