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!

 

[Kendo]

A question regarding the Asus GT-BE98 PRO and NON PRO version:
Is the Merlin firmware the same for both? Can be used with the non pro as well?
We only have the "simple" GT-BE98 in Europe.
Thank you in advance.

 

[jksmurf]

A question regarding the Asus GT-BE98 PRO and NON PRO version:
Is the Merlin firmware the same for both? Can be used with the non pro as well?
We only have the "simple" GT-BE98 in Europe.
Thank you in advance.

AsusWRT-Merlin FW is only available for the Pro Version.

Home | Asuswrt-Merlin

www.asuswrt-merlin.net

However, you are in luck that the Gnuton fork is available for the non-pro version. It is not updated quite as often.

GitHub - gnuton/asuswrt-merlin.ng: Extends the support of Merlin firmware to more ASUS routers

Extends the support of Merlin firmware to more ASUS routers - gnuton/asuswrt-merlin.ng

github.com

 

[bennor]

A question regarding the Asus GT-BE98 PRO and NON PRO version:
Is the Merlin firmware the same for both? Can be used with the non pro as well?

No. In addition to what @jksmurf indicated, the router GUI will typically perform a check to ensure the firmware one attempts to load/flash is correct for the router model it is being flashed to. It will typically reject the firmware if it doesn't match the specific router model.

 

[Kendo]

Thank you both for the answers.
Never tried gnuton, would that be recommended over the stock asus firmware? Thanks in advance.

 

[jksmurf]

Thank you both for the answers.
Never tried gnuton, would that be recommended over the stock asus firmware? Thanks in advance.

Gnuton is a fork of AsusWRT-Merlin; what that means is that it shares a significant proportion of Merlin’s functions and capabilities. Someone who has used both might be better to advise the exact differences.

As Gnuton notes “My builds are intended to support all features present in the original Merlin firmware. Occasionally, I also incorporate additional features for specific models.”

So with that as the background, I would recommend you don’t focus on Merlin vs Gnuton, but rather on “what do I NEED from Merlin or its variant that stock does not have”. Read what the features and advantages of Merlin are, what addons you may need, then decide.

You may decide that stock does everything you want; and that’s just fine. There are no prizes for running Merlin.

 

[random9]

Nothing was changed with regards to the WAN handling between 102.6 and 102.7.

merlin@ubuntu-dev:~/dev/amng$ git log --oneline 3006.102.6..3006.102.7
21d30a367f (tag: 3006.102.7) Bumped revision to 3006.102.7 final
7b6810ec20 Updated documentation
2bc9ee0923 rc: refresh wireguard BLOG bypass when refreshing VPN routing on BCM4916 platform
b4182dd67a webui: update routing rules when toggling a client from the VPNDirector page
4904a33e94 webui: styling fixes to the Firmware Upgrade page for non-AiMesh models.
0099cd1cb9 Bumped revision to beta 2
96e757e5f9 Updated documentation
3f2c98fe2f rom: fix missing signature updater for models with TrendMicro HNS engine
ec8eeec434 (tag: 3006.102.7-beta1) Bumped revision to beta 1
f17e8fd1b0 dnsmasq: Fix PXE boot server (PXEBS) responses broken in 2.92
1cb558f26e VSCode: filter out parsing of the multiple kernels + SDKs
371168d9f7 openvpn: default server keysize to 2048 bit
c8043ed06b Updated documentation
78f6248cdf tor: updated to 0.4.8.22
38c5c23e79 openvpn: updated to 2.6.19
d852901046 Updated documentation
11a4dfd13f webui: display ntpd options in WISP mode
cda1c30121 Bumped revision to alpha 2
ee6ec0e3c8 webui: stop polling online copy of DNS DB on WAN page
a855f2bb40 webui: disable obsolete DNS DB pulling on WAN page
64f6a2a0ee Updated documentation
0fe770bb67 rc: Add new 2024 IANA Root trust anchor
ddfdb4e847 webui: fix Connections table layout (wrong class)
fcc481062c webui: remove duplicate code on WAN page
5eb90360bb webui: add missing UPnP settings to multiservice version of WAN page
d744657e68 openssl: Ported 7 OpenSSL-1.1.1w CVE Fixes from Ubuntu ESM Repository. (#884)
e0071bcad0 dnsmasq: updated to 2.93-test2
5b063cb580 Updated documentation
77204f70e6 Updated documentation
56a7cf7003 dnsmasq: updated to 2.92
c30f5681c8 Updated documentation
091ab74b7a dropbear: update to 2025.89
92bcc4a553 nettle: updated to 3.10.2
e9933de16e openvpn: update to 2.6.17
944609be6d aicloud: disabled AiCloud
47316c04f3 Bumped revision to 3006.102.7 alpha 1
4090acdc79 rc: fix missing DNS Director DoT IPv6 rules (#883)

Yeah. Nothing obvious. Did some digging (upgrade/downgrade...) and found something that could be random luck as it relates to the media (WiFi) bridges... It seems that .6 and .7 both had auto-selected for the control channel. I found that .6 was picking a control channel on 5ghz that was compatible with the older hardware, like an AC68U media bridge or the Netgear WAX202, but .7 was picking control channel 100, which did not work with that hardware (neither provides a means to enable DFS...at least in bridge mode). Manually selecting 149 fixed it with .7 / .7_2

I'm still not sure why the wan seems to behave differently, given nothing has changed. Under .6, I can reboot the router, and it successfully dhcps from the modem. With .7/.7_2, if I reboot the router, then the modem either needs to be rebooted or I can manually unplug the WAN ethernet cable and plug it back in to get an IP. I'm now running .7_2, so I'll give it a few days and see if something is getting cached - perhaps it will resolve itself with time (or rather some type of cache timeout).

 

[isr25]

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

During a firmware update, the router would restart automatically. The manually restart router message normally comes if you do the update via 5 GHz WiFi, and less common if you connect to the router on Ethernet or 2.4 GHz WiFi. This is due to the 5 GHz WiFi takes time to be available because it needs to scan the available channels, including DFS. Just refresh the router page when your WiFi is connected and should be good to go, even without manually restarting the router again.