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

 

[ColinTaylor]

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

Yep, they're OpenDNS (aka Cisco) addresses.

 

[anotherengineer]

Yep, they're OpenDNS addresses.

This is what I have router WAN set to

Setup Guide | OpenDNS

Thanks for choosing OpenDNS! To get started, you’ll need to set up one or more of your devices to use OpenDNS’s DNS nameservers. For instructions on how to do this, choose your device type from one of the categories below.

www.opendns.com

Our FamilyShield nameservers are:
- 208.67.222.123
- 208.67.220.123
Before if you tried to access adult or other content the cisco/open dns screen would pop up on browser but now it doesn't do that. Looks like it's the browser itself blocking it or it doesn't get blocked?? Weird............something not jiving

 

[RMerlin]

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.

Reproduce the issue with the stock firmware, then contact Asus. I have done all that I could, and since mine no longer crashed after that GPL update, there`s notthing more that I can do.

Nice to see that Asus apparently reads these forums

They fixed it because I reported it to them a few weeks ago. I couldn`t integrate the fix myself because it involves changes in closed source componentts, but that fix is part of the new GPL that the RT-BE92U uses.

 

[Tech9]

Our FamilyShield nameservers are:
- 208.67.222.123
- 208.67.220.123

They have multiple servers. I was using OpenDNS for a long time and Toronto servers are 30+ addresses.

 

[JohnSmith]

Purchased an ASUS RT-BE58 Go for vacations/backup and decided to upgrade its original firmware to Merlin V3006_102.7_2 FW.

After setting it up in basic Wireless Router mode, and being able to login to to the GUI, I went to Advanced Settings | Administration | Firmware Upgrade | AiMesh router and chose "Upload" for the file "RT-BE58_GO_3006_102.7_2_nand_squashfs.pkgtb" from the unzipped file.

It started to "Applying Settings" and then kicked me back to the Main Login page.

After reading the readme.txt file, it said to run the command "nvram set DOWNGRADE_CHECK_PASS=1" via SSH for the first time upgrading to Merlin FW, and I did that, and then reran the upload, same thing happened.

I have restarted and rebooted the router, unplugged and plugged the router back in, even used a different browser (Chrome & Firefox), and the same issue each time. Even tried the old firmware file "RT-BE58_GO_3006_102.6_0_nand_squashfs.pkgtb", still no go.

Anybody else have this issue with the RT-BE58 Go?

 

[NeverRight]

Hmmm, similar issue with AT&T BGW320-500 and three different brand routers now. Finally figured out that the routers were provided IP Passthrough address correctly, BUT no Internet service, (red WAN LED on all three), until I used the Broadband Restart option on the BGW GUI. Yes the date was December 2023 but I think around the 15th.

It took me the whole weekend to finally reach that solution....

Do you still have this issue? Any long term fixes or workarounds you are aware of?
I am worried about being away and the whole network going down because the light flickered for two seconds.

 

[RDaneel]

So, I installed 3006.102.7_2 on my RTBE-88U, and then did a full power off shutdown of both my router and my Windows 11 PC (the modem had been power cycled earlier).

I now see a weird graphic on the main Merlin interface page - the WiFi strength "pie wedge" only has half of the pie slice showing, which probably goes along with there being NO 2.4 GHz network running and only a tiny piece of 5 GHz (it only shows 149/151 and 0 for 5 GHz channels)?

To be completely transparent, I am not sure if this started before or after the upgrade, and I can move this to a different thread if it is considered unlikely that it has anything to do with the new firmware...

In the meantime, is it likely that my BE-88U is dead, or at least the WiFi part? Note that the wired networks are happy. This is just over a year old, and my AX-88U ran for a good number of years.

Perhaps there is some interesting "WiFi H/W reset" that doesn't happen in a mere power cycling?

Thanks, and like I said, if I need to be in a different thread, please LMK.

EDIT1: BTW, my Wireless page, General tab, has NOTHING on it besides the "Enable Smart Connect" sliding switch - which doesn't actually seem to do anything if I try to turn it off - this isn't Good Thing(tm), is it?

EDIT2: if I do a full factory reset, I will lose all settings, and I will also lose my Merlin firmware, right? OTOH, if I end up having to pursue a warranty claim, I will likely have to do the H/W reset anyway?

EDIT3: I assume someone here has experience with the ASUS warranty process - does it go smoothly? IF I have to go this way, am I likely to have a good experience? Like with a new BE88U within a week or less?