Release Asuswrt-Merlin 3006.102.7 is now available

[Saulus]

Hi RMerlin and everyone!

I’ve just updated my RT-AX86U Pro to the new 3006.102.7_2 version. In the previous release (.7), I had a lot of trouble setting up Dual WAN (Load Balance).

Before I try to configure everything again, I want to ask:

Does the Load Balance mode work now without dropping the connection?

Is it still mandatory to fill in the 'Destination IP' field in Routing Rules, or can it be left empty now?

Do I still need to reboot the router every time I change the Primary WAN provider?

I am not an advanced user and I don't use SSH, so I just want to know if the Web Interface and the switching logic are working correctly now. I don't want to mess up my settings if these issues are still present.

Thanks for any info!

 

[Zirescu]

My BE92U keeps crashing (5th so far) with the 102.7_2 and only change beside the firmware updates is I've onlined an 8th IOT device to the 2.4GHz network. Conincidentally, I had a previous 8th device on the network but disconnected it over the winter. I don't know for sure if this is causing the CPU stalls as I did have some stability for a period of time. Will take the newest addition off the network to see if that resolves it.

Mar 25 10:18:20 asusroot: Clock check: Current year is 2026, Router uptime:  10:18:20 up  2:01,  load average: 0.18, 0.21, 0.24
Mar 25 10:23:20 asusroot: Clock check: Current year is 2026, Router uptime:  10:23:20 up  2:06,  load average: 0.19, 0.25, 0.25
Sep  2 22:45:00 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Sep  2 22:45:00 kernel: rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
Sep  2 22:45:00 kernel: rcu:     (detected by 1, t=900704567728 jiffies, g=1565161, q=82497)
Sep  2 22:45:00 kernel: rcu:     (detected by 0, t=900704567728 jiffies, g=238861, q=87)
Sep  2 22:45:00 kernel: rcu: INFO: Stall ended before state dump start
Sep  2 22:45:00 kernel: rcu: All QSes seen, last rcu_sched kthread activity 900704567728 (905007233726-4302665998), jiffies_till_next_fqs=3, root ->qsmask 0x0
Sep  2 22:45:00 kernel: tdts_core_ioctl_udb_op_prog_ctrl() fail!
Sep  2 22:45:00 kernel: amas_portstatus R  running task        0  4230   4202 0x00400000
Sep  2 22:45:00 kernel: Call trace:
Sep  2 22:45:00 kernel:  dump_backtrace+0x0/0x150
Sep  2 22:45:00 kernel:  show_stack+0x14/0x20
Sep  2 22:45:00 kernel:  sched_show_task+0x100/0x120
Sep  2 22:45:00 kernel:  rcu_check_callbacks+0x798/0x810
Sep  2 22:45:00 kernel:  update_process_times+0x2c/0x70
Sep  2 22:45:00 kernel:  tick_sched_timer+0x54/0xd0
Sep  2 22:45:00 kernel:  __hrtimer_run_queues+0x13c/0x1d0
Sep  2 22:45:00 kernel:  hrtimer_interrupt+0xe4/0x2b0
Sep  2 22:45:00 kernel:  arch_timer_handler_phys+0x30/0x40
Sep  2 22:45:00 kernel:  handle_percpu_devid_irq+0x80/0x140
Sep  2 22:45:00 kernel:  __handle_domain_irq+0x70/0xd0
Sep  2 22:45:00 kernel:  gic_handle_irq+0x5c/0xc0
Sep  2 22:45:00 kernel:  el1_irq+0xe8/0x190
Sep  2 22:45:00 asusroot: Clock check: Current year is 1918, Router uptime:  22:45:00 up 10424 days, 21:56,  load average: 1.84, 0.38, 0.12
Sep  2 22:45:00 crond[4137]: time disparity of 15011749 minutes detected
Sep  2 22:45:00 kernel:  __memset+0x170/0x188
Sep  2 22:45:00 kernel:  kernfs_seq_show+0x28/0x30
Sep  2 22:45:00 kernel:  seq_read+0x150/0x4e0
Sep  2 22:45:00 kernel:  kernfs_fop_read+0x24/0x1e0
Sep  2 22:45:00 kernel:  __vfs_read+0x2c/0x150
Sep  2 22:45:00 kernel:  vfs_read+0xa8/0x130
Sep  2 22:45:00 kernel:  ksys_read+0x60/0xe0
Sep  2 22:45:00 kernel:  __arm64_sys_read+0x18/0x20
Sep  2 22:45:00 kernel:  el0_svc_common+0x70/0x170
Sep  2 22:45:00 kernel:  el0_svc_compat_handler+0x1c/0x30
Sep  2 22:45:00 kernel:  el0_svc_compat+0x8/0x34
Sep  2 22:45:00 kernel: rcu: rcu_sched kthread starved for 900704567830 jiffies! g238861 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
Sep  2 22:45:00 kernel: rcu: RCU grace-period kthread stack dump:
Sep  2 22:45:00 kernel: rcu_sched       R    0    11      2 0x00000008
Sep  2 22:45:00 kernel: Call trace:
Sep  2 22:45:00 kernel:  __switch_to+0xe8/0x170
Sep  2 22:45:00 kernel:  __schedule+0x214/0x5a0
Sep  2 22:45:00 kernel:  schedule+0x38/0xa0
Sep  2 22:45:00 kernel:  schedule_timeout+0x15c/0x2a0
Sep  2 22:45:00 kernel:  rcu_gp_kthread+0x488/0x900
Sep  2 22:45:00 kernel:  kthread+0x118/0x150
Sep  2 22:45:00 kernel:  ret_from_fork+0x10/0x24
Sep  2 22:45:00 hostapd: wl1.1: STA 84:0f:4c:48:51:c4 IEEE 802.11: associated (aid 7)
Sep  2 22:45:00 hostapd: wl1.1: STA 84:0f:4c:48:51:c4 IEEE 802.11: Could not add STA to kernel driver
Sep  2 22:45:00 hostapd: wl2.1: STA 14:35:b7:33:33:5c WPA: group key handshake completed (RSN)
Sep  2 22:45:00 hostapd: wl1.1: STA 84:0f:4c:48:51:c4 IEEE 802.11: disassociated
Sep  2 22:45:00 asusroot: Year is 1918 (less than 1969) – restarting router
Sep  2 22:45:00 hostapd: wl1.1: STA ec:a9:07:2b:6e:1e WPA: group key handshake completed (RSN)
Sep  2 22:45:00 hostapd: wl1.1: STA 04:99:b9:61:a2:38 WPA: group key handshake completed (RSN)
Sep  2 22:45:00 hostapd: wl1.1: STA e0:2b:96:b5:3f:8f WPA: group key handshake completed (RSN)
Sep  2 22:45:00 hostapd: wl1.1: STA 3c:e9:f7:48:1d:ef WPA: group key handshake completed (RSN)
Sep  2 22:45:00 rc_service: Rebooting...
Sep  2 22:45:00 hostapd: wl1.1: STA 84:0f:4c:48:51:c4 IEEE 802.11: associated (aid 7)
Sep  2 22:45:00 kernel: sysrq: SysRq: intr handled on CPU 3
Sep  2 22:45:00 kernel: sysrq: Emergency Sync
Sep  2 22:45:00 kernel: Emergency Sync complete

 

[CJ-V300]

I've successfully updated my RT-BE92U (running as an AiMesh AP node) to the final 3006.102.7.2 release. Everything is incredibly stable, but I caught a very curious behavior in the logs regarding MLO that I wanted to share, just in case it is a known Asus GPL quirk.

I have MLO completely disabled in the GUI. I keep it off intentionally because it causes streaming issues with heavy 60GB MKV files on my Sony TV. However, my OnePlus 15 (a Wi-Fi 7 client) had a brief moment of connection instability today.

When I checked the log, I saw the phone apparently trying to force an MLO association anyway. The router correctly rejected it, but it threw a loop of "status 30" MLO errors, deauthenticating the phone several times in a row before finally letting it connect normally a few seconds later.

Interestingly, I never detected this specific issue with the previous Beta 2 or the test builds you shared over the past few days. I have only had this final firmware installed for about 10 hours, so it could be a completely isolated event or just my phone being stubborn and not respecting the disabled MLO flag, but I wanted to report it anyway.

Here is the sanitized log showing the struggle:

Mar 25 19:28:30 hostapd: wl1.1: STA XX:XX:XX:XX:XX:XX IEEE 802.11: associated (aid 5)Mar 25 19:28:31 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:32 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:32 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:32 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:32 hostapd: wl1.1: STA XX:XX:XX:XX:XX:XX IEEE 802.11: disassociatedMar 25 19:28:32 kernel: CFG80211-ERROR) wl_cfg80211_change_station :Mar 25 19:28:32 kernel: WLC_SCB_DEAUTHORIZE error (-30)Mar 25 19:28:32 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:34 hostapd: wl1.1: STA XX:XX:XX:XX:XX:XX IEEE 802.11: associated (aid 5)

Has anyone else noticed these "status 30" errors with Wi-Fi 7 clients when MLO is disabled? Thanks again for the release!

 

[Mutzli]

Seeing all the reports of issues with the RT‑BE92U lately makes me wonder if there are some bad units floating around. My own BE92U has been rock‑solid on the latest Merlin build, so it doesn’t seem universal.

 

[heysoundude]

Oh my…
I hadn’t thought it possible, but I’ve just completed my first update wirelessly from my iPad. Just now.
Gobsmacked.

 

[jksmurf]

Oh my…
I hadn’t thought it possible, but I’ve just completed my first update wirelessly from my iPad. Just now.
Gobsmacked.

You know that’s you done right, you’re now officially an absolute geek…
.

 

[heysoundude]

You know that’s you done right, you’re now officially an absolute geek…
.

You’ll hook me up with the secret handshake and my personal decoder ring, right?

 

[Poul Bak]

The ipv6 GUI bug of RT-BE92U has been fixed!

This evening I upgraded my router to 3006.102.7_2.
Previously when you connected to the GUI using the host name (like: 'https://router.home') you would actually connect using ipv6 - because it would resolve to both ipv4 and ipv6 and the browser would use ipv6) and while you could connect, it gave you a lot of problems, like throwing you to the front page and even logging you off etc. ((the workaround was to always use ipv4).

However, although I thought I wouldn't live long enough to see that fixed, that seems to have happened now. I can connect using ipv6 without problems - it even displays the ipv6 addresses correct in 'Security update notification':

Wed Mar 25 22:33:23 2026  [info] [LOGIN][https][Web] successful (2a00:....................:ceac)

Also note that it now says 'successful ' instead of 'successed'.
And all the weird behaviour is gone.
Nice to see that Asus apparently reads these forums

 

[GWTechTalk]

I've successfully updated my RT-BE92U (running as an AiMesh AP node) to the final 3006.102.7.2 release. Everything is incredibly stable, but I caught a very curious behavior in the logs regarding MLO that I wanted to share, just in case it is a known Asus GPL quirk.

I have MLO completely disabled in the GUI. I keep it off intentionally because it causes streaming issues with heavy 60GB MKV files on my Sony TV. However, my OnePlus 15 (a Wi-Fi 7 client) had a brief moment of connection instability today.

When I checked the log, I saw the phone apparently trying to force an MLO association anyway. The router correctly rejected it, but it threw a loop of "status 30" MLO errors, deauthenticating the phone several times in a row before finally letting it connect normally a few seconds later.

Interestingly, I never detected this specific issue with the previous Beta 2 or the test builds you shared over the past few days. I have only had this final firmware installed for about 10 hours, so it could be a completely isolated event or just my phone being stubborn and not respecting the disabled MLO flag, but I wanted to report it anyway.

Here is the sanitized log showing the struggle:

Mar 25 19:28:30 hostapd: wl1.1: STA XX:XX:XX:XX:XX:XX IEEE 802.11: associated (aid 5)Mar 25 19:28:31 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:32 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:32 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:32 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:32 hostapd: wl1.1: STA XX:XX:XX:XX:XX:XX IEEE 802.11: disassociatedMar 25 19:28:32 kernel: CFG80211-ERROR) wl_cfg80211_change_station :Mar 25 19:28:32 kernel: WLC_SCB_DEAUTHORIZE error (-30)Mar 25 19:28:32 kernel: === MLO ERROR [wlc_ap_process_assocreq] Assoc processingfailure for XX:XX:XX:XX:XX:XX on wl1 status 30 ===Mar 25 19:28:34 hostapd: wl1.1: STA XX:XX:XX:XX:XX:XX IEEE 802.11: associated (aid 5)

Has anyone else noticed these "status 30" errors with Wi-Fi 7 clients when MLO is disabled? Thanks again for the release!

Someone correctly told me once that even if you are not using MLO you should have it toggled on in the MLO menu. Just having that on does not allow or advertise MLO capability. It's primarily used for backhauling only in a mesh system. In order for front end clients to use it you must turn on that feature in the network settings of the router. "Enable Fronthaul". I had all kinds of weird issues when I had the MLO toggle off but now with it on I'm still not using MLO because it doesn't really do what it was advertised to do and I get create connection just using the 320Mhz band.

MLO Menu = MLO Enabled
Network Menu = "Enable Fronthaul", unchecked.
I don't use the mesh network feature so it's no big deal for me.

Food for thought.

 

[anotherengineer]

Could be a browser issue (i.e. it's using DoH). Try another browser and/or PC.

Or for some reason the browser isn't honouring the router's DoH setting. Try changing "Prevent client auto DoH" to Yes.

how about this default firefox setting??

 

[anotherengineer]

Have you flushed the resolver cache? ipconfig /flushdns from a command prompt in Windows



Also, what DNS does this say you're using dnscheck.tools

did that, corrected FF and LAN on router and got this...........doesn't look like open dns family