Release Asuswrt-Merlin 3006.102.7 is now available

[Viktor Jaep]

wired of course, why would i use wireless for a WAN speed test? it would introduce unnecessary latency...

Thank goodness. Are you bypassing the router, and plugging this device directly into the WAN cable coming out of your modem?

 

[Blkpanthr]

no, that would defeat the purpose of gaging the router throughput.

I will never use a client connected directly to my gateway, so removing the router from the network chain for testing would be pointless as that's not a viable topology for me.

this is getting severely off topic, lets move on.

 

[H74]

no, that would defeat the purpose of gaging the router throughput.

I will never use a client connected directly to my gateway, so removing the router from the network chain for testing would be pointless as that's not a viable topology for me.

this is getting severely off topic, lets move on.

You are absolutely right that this is off topic, because the results of the speed tests in this case are not fw dependent. It is pointless to analyze how you measure, since you are comparing the results of two different speed tests that you measured in the same way. You did it right. For me, Ookla measures almost similar results, regardless of where I start the measurement (FF/Edge/router/MS store app/WiFi7) ~923-931/305-327 Mbps 2-6 ms latency. Of course, the result also depends on the selected server. In contrast, Cloudflare only 786/283 Mbps 26 ms. The difference is due to the measurement method. Ookla rather shows whether you reach the speed provided by your provider, while Cloudflare simulates real usage through its own network, which you can achieve. It means that Cloudflare’s Speed Test is not trying to show what the maximum speed your connection can reach, but rather what it typically delivers.

 

[Blkpanthr]

That makes sense. thanks.

 

[CJ-V300]

I wanted to share a small finding regarding the final 3006.102.7 release. From a user experience standpoint, my network is running perfectly. I haven't noticed a single drop or performance issue. However, to avoid going crazy reading endless text, I usually feed my weekly router logs to Gemini (the AI) for a quick health check. Well, the AI actually caught a silent bug under the hood that I would have completely missed.

It turns out there are background kernel panics happening on both my main router (BE88U) and my AP node (BE92U). The crashes are related to the asd process (Asus Security Daemon / Trend Micro), throwing "potentially unexpected fatal signal 6" and "signal 11".

The curious part is that I have AiProtection and all Trend Micro features completely disabled on my main BE88U. Furthermore, the BE92U is running purely as an Access Point, where this daemon shouldn't be doing much anyway.

Since the OS just catches the error, dumps the memory, and restarts the process silently in milliseconds, there is absolutely zero impact on my actual network stability. I am just sharing this in case it is an unpolished edge case in the current Asus GPL regarding the Trend Micro engine. Here are the snippets that Gemini extracted from the logs:

Main Router (BE88U):Apr 1 00:32:21 kernel: ===DDD===Apr 1 00:32:21 kernel: 00010000 - 00020000, [asd]Apr 1 00:32:21 kernel: CPU: 2 PID: 3316 Comm: asd Tainted: P O 4.19.294 #1

AP Node (BE92U):Mar 30 18:35:51 kernel: potentially unexpected fatal signal 6.Mar 30 18:35:51 kernel: ===DDD===Mar 30 18:35:51 kernel: 00010000 - 00020000, [asd]Mar 30 18:35:51 kernel: CPU: 1 PID: 5707 Comm: asd Tainted: P O 4.19.294 #1Apr 3 00:49:58 kernel: potentially unexpected fatal signal 11.Apr 3 00:49:58 kernel: ===DDD===Apr 3 00:49:58 kernel: CPU: 3 PID: 22325 Comm: asd Tainted: P O 4.19.294 #1

Has anyone else noticed this background asd crash on their end? Thanks !!

 

[Treadler]

I wanted to share a small finding regarding the final 3006.102.7 release. From a user experience standpoint, my network is running perfectly. I haven't noticed a single drop or performance issue. However, to avoid going crazy reading endless text, I usually feed my weekly router logs to Gemini (the AI) for a quick health check. Well, the AI actually caught a silent bug under the hood that I would have completely missed.

It turns out there are background kernel panics happening on both my main router (BE88U) and my AP node (BE92U). The crashes are related to the asd process (Asus Security Daemon / Trend Micro), throwing "potentially unexpected fatal signal 6" and "signal 11".

The curious part is that I have AiProtection and all Trend Micro features completely disabled on my main BE88U. Furthermore, the BE92U is running purely as an Access Point, where this daemon shouldn't be doing much anyway.

Since the OS just catches the error, dumps the memory, and restarts the process silently in milliseconds, there is absolutely zero impact on my actual network stability. I am just sharing this in case it is an unpolished edge case in the current Asus GPL regarding the Trend Micro engine. Here are the snippets that Gemini extracted from the logs:

Main Router (BE88U):Apr 1 00:32:21 kernel: ===DDD===Apr 1 00:32:21 kernel: 00010000 - 00020000, [asd]Apr 1 00:32:21 kernel: CPU: 2 PID: 3316 Comm: asd Tainted: P O 4.19.294 #1

AP Node (BE92U):Mar 30 18:35:51 kernel: potentially unexpected fatal signal 6.Mar 30 18:35:51 kernel: ===DDD===Mar 30 18:35:51 kernel: 00010000 - 00020000, [asd]Mar 30 18:35:51 kernel: CPU: 1 PID: 5707 Comm: asd Tainted: P O 4.19.294 #1Apr 3 00:49:58 kernel: potentially unexpected fatal signal 11.Apr 3 00:49:58 kernel: ===DDD===Apr 3 00:49:58 kernel: CPU: 3 PID: 22325 Comm: asd Tainted: P O 4.19.294 #1

Has anyone else noticed this background asd crash on their end? Thanks !!

I’ve not noticed this, but haven’t really gone looking either. All ‘appears’ to be working fine.

ASD though is an Asus thing, nothing to do with Trend so far as I know…….

 

[CJ-V300]

I’ve not noticed this, but haven’t really gone looking either. All ‘appears’ to be working fine.

ASD though is an Asus thing, nothing to do with Trend so far as I know…….

Thanks for the clarification! You are totally right, it seems asd (Asus System Daemon) has become more of a catch-all background process for Asus telemetry and internal system checks in these newer 3006 firmwares, rather than being strictly tied to the Trend Micro engine as it used to be.

That actually makes even more sense as to why it's running (and occasionally crashing) even on an AP node with all security features turned off.

Like you said, everything "appears" to be working flawlessly on the surface, which is the most important thing. It's just a completely silent hiccup under the hood that the Linux kernel handles instantly.

 

[CJ-V300]

Just a quick follow-up on the asd kernel crashes I posted about earlier. I was reading through another thread and found that Merlin actually addressed this exact same issue a couple of weeks ago.

He confirmed that this is just a random crash from the ASD security daemon, and it is currently happening across all models. The great news is that we can safely ignore these log entries, as the OS simply catches the error and restarts the daemon automatically without affecting our network traffic or stability at all.

Here is the link to his post in case anyone wants to check it out:

https://www.snbforums.com/threads/l...92u-stability-issues.96798/page-3#post-987509

 

[RMerlin]

It turns out there are background kernel panics happening on both my main router (BE88U) and my AP node (BE92U). The crashes are related to the asd process (Asus Security Daemon / Trend Micro), throwing "potentially unexpected fatal signal 6" and "signal 11".

That`s not a kernel panic, that`s just an application crash. A kernel panic is like a BSOD on Windows - it causes the entire system to crash and require a reboot.

 

[tjones1283]

Is it normal for the firmware upgrade to require the user to manually restart the router? My memory is fuzzy but I thought it was able to auto-restart at one point; perhaps I'm remembering the stock firmware upgrade process (not merlin) or an older ASUS router? This is on the RT-AX86U Pro

 

[visortgw]

Is it normal for the firmware upgrade to require the user to manually restart the router? My memory is fuzzy but I thought it was able to auto-restart at one point; perhaps I'm remembering the stock firmware upgrade process (not merlin) or an older ASUS router? This is on the RT-AX86U Pro

If reboot completion isn't sensed within certain amount of time, user requested to manually reboot (may not be necessary).

 

[NeverRight]

I use UPS (pure sine wave) and DC battery backups. I'm afraid this started when I needed a tech to come out and fix my fiber line connections to the gateway.

Amazon has the DC type for sale if you are looking for them, including hard to find 12V ones.

I wanted to round off this particular topic (and many thanks to jzchen for suggesting the solution). I was using a Cat8 cable and the issue was reproducible with that and jzchen suggested switching to a Cat6 cable.
I ordered a new Cat 6A cable and even with a Hard Reset of the router without resetting the modem, the router was able to acquire the correct time and then connect to the internet.

I have no idea why this worked, just that it did.

 

[CJ-V300]

I wanted to round off this particular topic (and many thanks to jzchen for suggesting the solution). I was using a Cat8 cable and the issue was reproducible with that and jzchen suggested switching to a Cat6 cable.
I ordered a new Cat 6A cable and even with a Hard Reset of the router without resetting the modem, the router was able to acquire the correct time and then connect to the internet.

I have no idea why this worked, just that it did.

That is a very interesting find. It seems that in many home networking scenarios, the higher shielding or strict grounding requirements of Cat 8 can occasionally cause handshake issues with consumer-grade routers, whereas Cat 6/6A is much more "plug-and-play."

In my case, I am currently using Cat 7 and everything is working perfectly. However, my situation was a bit more challenging than yours because my cabling is installed inside the walls. While I have a standard wall socket on one end, the other end goes directly into the communications cabinet where the cable comes out without a dedicated port. Dealing with built-in infrastructure definitely adds a layer of difficulty when you have to troubleshoot or swap things out.

I’m glad the switch to Cat 6A solved it for you. Let’s cross our fingers and hope the connection stays stable from here on out!