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!