Release Asuswrt-Merlin 3006.102.7 is now available

[Elmer]

AXE-16000. Have reverted back to 3006.102.6. Losing devices, both wired and wireless. Reboot brings them back and then they disappear around two hours later. Might have something to do with IPV6. Don't see anything in the logs that pops out at me.

 

[huubhuub]

7 days and counting with 3006.102.7 on my BE88U with stock AImesh nodes.... thanks again @RMerlin.

 

[Ripshod]

7 days and counting with 3006.102.7 on my BE88U with stock AImesh nodes.... thanks again @RMerlin.

Same here, but no nodes

 

[jksmurf]

Same here, but no nodes

You don't know what you're missing.. so much fun...

 

[Clark Griswald]

You don't know what you're missing.. so much fun...

Nodes are not always "fun", and sometimes they are scary.
Casa Griswald only uses a Main and an AP. No network issues with latest RMerlin FW.

 

[128bit]

Thank you as always!
If anyone installs this on their (ROG) GT-AX11000 Pro, would appreciate andy follow ups/comments. Both the August and November releases displayed quirks, was awating this to see how it goes. Good weekend to all, S.

the only weird behavior i've noticed since my 102.7 update was with the usb 3.0 health scanner panel. when doing a rescan of my nas attached usb.30 ssd, at ~50% i get logged out! after logging back in, the scan shows completion. this behavior is new with 102.7 as that 860 evo ssd has been solid on several asus devices over the years.

 

[RMerlin]

the only weird behavior i've noticed since my 102.7 update was with the usb 3.0 health scanner panel. when doing a rescan of my nas attached usb.30 ssd, at ~50% i get logged out! after logging back in, the scan shows completion. this behavior is new with 102.7 as that 860 evo ssd has been solid on several asus devices over the years.

Check the system log. The most likely reason I can think of would be your router runs out of memory while doing the scan, causing service crashes. In the past running a fs check on a large disk has always been a problem due to the amount of RAM required for it.

 

[128bit]

Check the system log. The most likely reason I can think of would be your router runs out of memory while doing the scan, causing service crashes. In the past running a fs check on a large disk has always been a problem due to the amount of RAM required for it.

not seeing anything specific re ram/memory in the syslog.
>>> >> >
Mar 2 11:14:39 disk_monitor: re-mount partition
Mar 2 11:14:39 kernel: tntfs info (device sda1, pid 18165): ntfs_fill_super(): fail_safe is enabled.
Mar 2 11:14:39 kernel: tntfs info (device sda1, pid 18165): load_system_files(): NTFS volume name 'gpdNAS-1t', version 3.1 (cluster_size 4096, PAGE_SIZE 4096).
Mar 2 11:14:39 disk_monitor: USB ntfs fs at /dev/sda1 mounted on /tmp/mnt/ssdNAS-1t
Mar 2 11:14:39 usb: USB ntfs fs at /dev/sda1 mounted on /tmp/mnt/gpdNAS-1t.
Mar 2 11:14:39 rc_service: disk_monitor 4555:notify_rc stop_httpd
Mar 2 11:14:39 rc_service: disk_monitor 4555:notify_rc start_httpd
Mar 2 11:14:39 rc_service: waitting "stop_httpd"(last_rc:stop_httpd) via disk_monitor ...
Mar 2 11:14:40 rc_service: disk_monitor 4555:notify_rc start_samba
Mar 2 11:14:40 rc_service: waitting "start_httpd"(last_rc:start_httpd) via disk_monitor ...
< << <<<
on the system status panel, ram typically shows ~47% but i'm not sure how that may change during the scan. shortly after the remount msg is when i get logged out. this is just a snippet but no other messages re ram/memory show on a fresh log.

 

[dave14305]

Mar 2 11:14:39 rc_service: disk_monitor 4555:notify_rc stop_httpd
Mar 2 11:14:39 rc_service: disk_monitor 4555:notify_rc start_httpd
Mar 2 11:14:39 rc_service: waitting "stop_httpd"(last_rc:stop_httpd) via disk_monitor ...
Mar 2 11:14:40 rc_service: disk_monitor 4555:notify_rc start_samba
Mar 2 11:14:40 rc_service: waitting "start_httpd"(last_rc:start_httpd) via disk_monitor ...

I suppose it’s this part of disk_monitor that stops the httpd daemon. Perhaps this isn’t meant to be there:

asuswrt-merlin.ng/release/src/router/rc/usb.c at 58b0b7acd100117014970d01741952939cd79ad8 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[RMerlin]

I suppose it’s this part of disk_monitor that stops the httpd daemon. Perhaps this isn’t meant to be there:

asuswrt-merlin.ng/release/src/router/rc/usb.c at 58b0b7acd100117014970d01741952939cd79ad8 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

The real question is why Asus is setting DEBUG_RCTEST in the Makefile, which I would expect should only be enabled for test purposes. I just checked the GPL code itself and it's there.

I also see this (unrelated) typo next to a DEBUG_RCTEST section I just reviewed:

#ifdef HND_ROTUER

Well...

 

[RMerlin]

That DEBUG_RCTEST constant has been present since at least 2017 according to git blame (the initial GPL merge when the repo was started), so at this point I'd rather not touch it. This enables the "rc" applet, which may potentially be used by other components of the firmware.

That code block in usb.c is also present in the GPL, so it's not a merge issue on my part.

 

[dave14305]

I also see this (unrelated) typo next to a DEBUG_RCTEST section I just reviewed:

I think it’s French.

 

[128bit]

The real question is why Asus is setting DEBUG_RCTEST in the Makefile, which I would expect should only be enabled for test purposes. I just checked the GPL code itself and it's there.

I also see this (unrelated) typo next to a DEBUG_RCTEST section I just reviewed:

#ifdef HND_ROTUER

Well...

hey guys, been working this and another connect problem but fwiw, "claude" called out the same possibility with ram as u did but after seeing the log, though it may be a bug. i realize "ai" can be sensitive on this board but i assure you, i'm just trying to learn - below the text from a claude session. the log it had may have been larger.
>>>
This log tells a very clear story. Let me walk through it precisely.


What actually happened:


At 11:14:29, the disk rescan triggered and immediately began tearing down services — Samba, FTP, avahi, wsdd2, iTunes daemon. At 11:14:39, after remounting the NTFS partition, disk_monitor called stop_httpd then start_httpd, which restarted dnsmasq entirely — both instances (PID 4456 and 4451 get SIGTERM at 11:14:41, replaced by 18237 and 18242).

That dnsmasq restart is your problem. The ESP's DHCP negotiation was in progress during the 11:14:28–11:14:41 window. The old dnsmasq was killed mid-transaction. The new dnsmasq came up, saw the Discovers, sent Offers — but the ESP was in a confused state from the previous incomplete exchange and the timing kept missing. It didn't complete a Request/Ack until well after the dust settled.

This is also your UI logout. httpd was stopped and restarted as part of the same chain reaction. That's not a memory issue — that's disk_monitor explicitly calling stop_httpd/start_httpd as part of its rescan sequence. Merlin's suspicion about memory may be a red herring; the logout is by design (poorly), not by crash.

The core issue: ASUS's disk_monitor rescan sequence is unnecessarily nuclear — it tears down and restarts httpd and dnsmasq for what should be a filesystem-level operation. That's a Merlin/ASUS bug worth filing properly on SNBForums with this exact log.

What Copilot likely missed: it probably focused on the dnsmasq restart in isolation without connecting it back to disk_monitor being the trigger, and without recognizing that the httpd restart and the DHCP failure are both children of the same parent event — not two separate problems.

<<< << <
that was claude's 2 cents. so don't kill the messenger. the reference to copilot comes from a similar session with that ai. copilot and gemini are typically 10-20% accurate but i often start there.

 

[dave14305]

hey guys, been working this and another connect problem but fwiw, "claude" called out the same possibility with ram as u did but after seeing the log, though it may be a bug. i realize "ai" can be sensitive on this board but i assure you, i'm just trying to learn - below the text from a claude session. the log it had may have been larger.

I would try to recreate this problem on 102.6. Since this code has been there a while, maybe somehow the disabling of AiCloud and other USB adjacent features causes something not to happen. It’s only a wild guess, but Claude tends to agree with me.

 

[RMerlin]

If Asus decided to put an httpd restart there it might be for a reason, so I'm not really keen on changing that behaviour.

Nothing in that log even mentions dnsmasq, only httpd gets restarted.

 

[dave14305]

If Asus decided to put an httpd restart there it might be for a reason, so I'm not really keen on changing that behaviour.

I think it’s suspicious that this DEBUG_RCTEST in usb.c immediately follows a RTCONFIG_CLOUDSYNC section. I wonder if it’s meant to be within it.

 

[RMerlin]

I think it’s suspicious that this DEBUG_RCTEST in usb.c immediately follows a RTCONFIG_CLOUDSYNC section. I wonder if it’s meant to be within it.

The whole function will mount a partition, so I can see restarting httpd after mounting the volume to ensure that httpd is aware of the system level change.

That code was added in GPL 3006_102_34369.

Without knowing the intention behind it it's hard to tell if it's legitimate or not. The fact that it lies within a debug-related define that has been permanently set for many years makes it even murkier. I would probably have to ask them to know for sure, assuming anyone currently on the team would remember why it's there.

 

[junior120872]

AXE-16000. Have reverted back to 3006.102.6. Losing devices, both wired and wireless. Reboot brings them back and then they disappear around two hours later. Might have something to do with IPV6. Don't see anything in the logs that pops out at me.

I've always noticed funny things with networkmap losing it's brains a little bit. I usually have around 124 devices connected to my mesh on average. In the evenings it's more in the mornings it's less. If I notice any discrepancies in those numbers I'll just run a 'killall -HUP networkmap' and it fixes it. I'm not running ipv6 though. I saw some fixed issues around ipv6 earlier in the thread with restarting some services via cron. You may want to look at those.

 

[128bit]

I would try to recreate this problem on 102.6. Since this code has been there a while, maybe somehow the disabling of AiCloud and other USB adjacent features causes something not to happen. It’s only a wild guess, but Claude tends to agree with me.

i can assure you that with every new release, i dismount then physically remove the usb 3 ssd. once the new fw is loaded and the mesh node operational, that process is reversed. been doin that for years and never experienced this behavior. going back to 102.6 would be painful as it never failed on that fw.

 

[CaptnDanLKW]

I've always noticed funny things with networkmap losing it's brains a little bit. I usually have around 124 devices connected to my mesh on average. In the evenings it's more in the mornings it's less. If I notice any discrepancies in those numbers I'll just run a 'killall -HUP networkmap' and it fixes it. I'm not running ipv6 though. I saw some fixed issues around ipv6 earlier in the thread with restarting some services via cron. You may want to look at those.

Same here. When things start to look odd, I also notice the device counts on the AI Mesh page do not add up to the number on the main page. Also the AI Mesh counts seem to be frozen, and the station binding/unbinding doesn't work. (or it does but the AI Mesh interface doesn't reflect it).