Beta Asuswrt-Merlin 3006.102.6 Beta is now available

[bluepoint]

That's why you noticed nothing, if set to Off in Administration - System like for me, they light up wrongly after reboot.
And the other things I noticed..?

I can confirm LED ligts/RED WAN light were on even if they were off from admin. in GT-AX6000.

 

[NiklasO]

The clients # steadily increasing has been fixed (yay!). I have the same LED-situation. On at reboot (I have it off in gui) with the internet led staying red. Turning on, off, on from GUI and the leds works fine again (red -> white).

 

[MDM]

I hope some other WIFI 6 router non GT-AX6000 user can confirm the issues too (for RMerlin sake)...

And the Multi-User MIMO setting, was it gone before this, someone noticed?

 

[XIII]

Another GT-AX6000 here where the LED lights are on with Beta 1, while they were not with the alpha and previous releases.

 

[RMerlin]

@RMerlin – With the new security update, do we need to perform a factory reset when using your firmware? I noticed ASUS recommends this step for their stock firmware when this was introduced. Just wanted to ensure this is not the case with your firmware. Thanks.

No. Disable UPnP if you want to match the new default behaviour, change your password if you want a stronger password that fits in the new requirements.

 

[RMerlin]

security update notification observation I agree. Also the GAME color change. LAN VLAN changes

All of these changes are on Asus' side, and nothing abnormal there.

 

[RMerlin]

I see the problem with the GT-AX6000 and its leds at boot time. I'm not sure however why only that particular model would be affected.

Can anyone test on other models? Disable the LEDs (on the Administration -> System page, reboot, and see what state LEDs are once rebooted. I need to know if I should apply the fix to all models, or only to the GT-AX6000.

 

[Texasguy]

Rt-be92u here all lights are on and Multi-User MIMO setting shows on all Wi-Fi the only problem my had installing beta one after manually reboot would not connect to Internet showed a weird Mac address and client list with unknown IP after a reboot from the app Internet turned back on other than that everything is good dirty upgrade

 

[BlackIce]

I see the problem with the GT-AX6000 and its leds at boot time. I'm not sure however why only that particular model would be affected.

Can anyone test on other models? Disable the LEDs (on the Administration -> System page, reboot, and see what state LEDs are once rebooted. I need to know if I should apply the fix to all models, or only to the GT-AX6000.

With Beta1 on my RT-AX86u Pro all the lights are off with them disabled in the GUI.

 

[RMerlin]

Smart Power strips + Home Assistant = how I can deal with so many routers, when I need to randomly turn one on to test something on it.

The older models are gathered on shelves in another room, where a bunch of labeled AC adapters are laying on the table close to the power bar, requiring me to manually plug it, plug Ethernet in, then turn it on.

Neighbours must have been scratching their heads ealier this week when I turned all of these on to test flash beta builds. There must have been over 20+ SSIDs all starting with "skyrealm" visible at that time.

 

[RMerlin]

Rt-be92u here all lights are on

Works fine on my RT-BE92U, all LEDs are properly turned off at boot time when disabled.

 

[Wisiwyg]

LEDs function as expected in ON and OFF selections with reboot. BE-96U.
Dirty update over Alpha2.

 

[Poul Bak]

Installed on RT-BE92U, did a factory reset.
It's working fine, but I found what seems to be an embarrassing ASUS display bug:

After I enabled ipv6 (which works fine), I noticed that when I log in to the GUI using ipv6, the new 'Security Update Notification' shows really weird ipv4 addresses:

Wed Nov 12 20:42:25 2025 [info] [LOGIN][https][Web] successed (173.195.129.202)
Wed Nov 12 20:45:56 2025 [info] [LOGIN][https][Web] successed (62.215.139.87)
Wed Nov 12 20:52:01 2025 [info] [LOGIN][https][Web] successed (27.137.36.230)
Wed Nov 12 20:56:25 2025 [info] [LOGIN][https][Web] successed (112.163.86.240)
Wed Nov 12 21:06:35 2025 [info] [LOG]:clear (112.163.86.240)
Wed Nov 12 21:28:09 2025 [info] [LOGIN][https][Web] successed (112.163.86.240)
Wed Nov 12 21:44:33 2025 [info] [LOGIN][https][Web] successed (112.71.240.18)
Wed Nov 12 21:57:58 2025 [info] [LOGIN][https][Web] successed (112.71.240.18)
Wed Nov 12 22:05:43 2025 [info] [LOGIN][https][Web] successed (112.71.240.18)
Wed Nov 12 22:10:41 2025 [info] [LOGIN][https][Web] successed (34.2.54.236)
Wed Nov 12 22:25:03 2025 [info] [LOGIN][https][Web] successed (34.2.54.236)
Wed Nov 12 22:34:13 2025 [info] [LOG]:clear (34.2.54.236)
Wed Nov 12 22:45:05 2025 [info] [LOGIN][https][Web] successed (124.222.56.180)
Wed Nov 12 22:51:58 2025 [info] [LOG]:clear (124.222.56.180)
Wed Nov 12 23:11:38 2025 [info] [LOGIN][https][Web] successed (124.222.56.180)
Wed Nov 12 23:29:10 2025 [info] [LOGIN][https][Web] successed (124.222.56.180)
Wed Nov 12 23:31:18 2025 [info] [LOGIN][https][Web] successed (124.222.56.180)
Wed Nov 12 23:44:51 2025 [info] [LOGIN][https][Web] successed (85.226.61.95)
Thu Nov 13 00:09:29 2025 [info] [LOGIN][https][Web] successed (85.226.61.95)

I don't have access to GUI from internet and the times shown fully match my own log in (I'm nor being hacked!).

It seems to wrongly make the ipv6 address from my PC into a string as an ipv4 address.
Very weird and I call it embarrassing that they didn't test with ipv6.
I don't see this on BT10 because access points don't have ipv6.

 

[Texasguy]

Works fine on my RT-BE92U, all LEDs are properly turned off at boot time when disabled.

OK, I see what you’re saying. I don’t turn mine off. I keep them on the lights, but I did a test and they stated off at reboot.

 

[jerry6]

All working well on my gt1100pro updated from the latest Alpha build
Thanks

 

[Zirescu]

Had the dreaded clock randomly resetting back to 1918 happen again on the RT-BE92U since updating to the beta last evening, a little less than 24 hours ago. The alphas didn't appear to have any issue. I have a script that forces a reboot when it detects the clock year is less than 1969 as the router isn't able to recover otherwise. I updated my script to include the uptime in case it happens again while on beta 1. Not sure if the following is of any help.

Nov 12 17:35:24 asusroot: Clock check: Current year is 2025
Apr 23 12:48:08 crond[4077]: time disparity of 15012101 minutes detected
Apr 23 12:48:08 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Apr 23 12:48:08 kernel: rcu:     3-...!: (0 ticks this GP) idle=022/0/0x1 softirq=13047858/13047858 fqs=0
Apr 23 12:48:08 kernel: rcu:     (detected by 2, t=601290 jiffies, g=14176509, q=1225)
Apr 23 12:48:08 kernel: Task dump for CPU 3:
Apr 23 12:48:08 kernel: swapper/3       R  running task        0     0      1 0x00000008
Apr 23 12:48:08 kernel: Call trace:
Apr 23 12:48:08 kernel:  __switch_to+0xe8/0x170
Apr 23 12:48:08 kernel:  0xffffff80080abef0
Apr 23 12:48:08 kernel: rcu: rcu_preempt kthread starved for 601290 jiffies! g14176509 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=2
Apr 23 12:48:08 kernel: rcu: RCU grace-period kthread stack dump:
Apr 23 12:48:08 kernel: rcu_preempt     I    0    10      2 0x00000008
Apr 23 12:48:08 kernel: Call trace:
Apr 23 12:48:08 kernel:  __switch_to+0xe8/0x170
Apr 23 12:48:08 kernel:  __schedule+0x214/0x5a0
Apr 23 12:48:08 kernel:  schedule+0x38/0xa0
Apr 23 12:48:08 kernel:  schedule_timeout+0x15c/0x2a0
Apr 23 12:48:08 kernel:  rcu_gp_kthread+0x488/0x900
Apr 23 12:48:08 kernel:  kthread+0x118/0x150
Apr 23 12:48:08 hostapd: wl2.1: STA 84:0f:4c:48:51:c4 WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl1.1: STA ec:a9:07:2b:6e:1e WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl1.1: STA 04:99:b9:61:a2:38 WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl1.1: STA e0:2b:96:b5:3f:8f WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl1.1: STA 14:35:b7:33:33:5c WPA: group key handshake completed (RSN)
Apr 23 12:48:08 kernel:  ret_from_fork+0x10/0x24
Apr 23 12:48:08 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Apr 23 12:48:08 kernel: rcu: INFO: rcu_sched self-detected stall on CPU
Apr 23 12:48:08 kernel: rcu:     (detected by 2, t=900726059718 jiffies, g=14176509, q=66869)
Apr 23 12:48:08 kernel: rcu:     0-...!: (10 ticks this GP) idle=c5e/0/0x1 softirq=17546337/17546344 fqs=0
Apr 23 12:48:08 kernel: rcu: All QSes seen, last rcu_preempt kthread activity 900725458428 (905101362806-4375904378), jiffies_till_next_fqs=3, root ->qsmask 0x0
Apr 23 12:48:08 kernel: rcu:      (t=900725458428 jiffies g=2236865 q=16)
Apr 23 12:48:08 kernel: swapper/2       R  running task        0     0      1 0x0000000a
Apr 23 12:48:08 kernel: rcu: rcu_sched kthread starved for 900725458428 jiffies! g2236865 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=2
Apr 23 12:48:08 kernel: Call trace:
Apr 23 12:48:08 kernel:  dump_backtrace+0x0/0x150
Apr 23 12:48:08 kernel: rcu: RCU grace-period kthread stack dump:
Apr 23 12:48:08 kernel:  show_stack+0x14/0x20
Apr 23 12:48:08 kernel: rcu_sched       I    0    11      2 0x00000008
Apr 23 12:48:08 kernel:  sched_show_task+0x100/0x120
Apr 23 12:48:08 kernel: Call trace:
Apr 23 12:48:08 kernel:  rcu_check_callbacks+0x798/0x810
Apr 23 12:48:08 kernel:  __switch_to+0xe8/0x170
Apr 23 12:48:08 kernel:  update_process_times+0x2c/0x70
Apr 23 12:48:08 kernel:  __schedule+0x214/0x5a0
Apr 23 12:48:08 kernel:  tick_sched_timer+0x54/0xd0
Apr 23 12:48:08 kernel:  schedule+0x38/0xa0
Apr 23 12:48:08 kernel:  __hrtimer_run_queues+0x13c/0x1d0
Apr 23 12:48:08 kernel:  schedule_timeout+0x15c/0x2a0
Apr 23 12:48:08 kernel:  hrtimer_interrupt+0xe4/0x2b0
Apr 23 12:48:08 kernel:  rcu_gp_kthread+0x488/0x900
Apr 23 12:48:08 kernel:  arch_timer_handler_phys+0x30/0x40
Apr 23 12:48:08 kernel:  kthread+0x118/0x150
Apr 23 12:48:08 kernel:  handle_percpu_devid_irq+0x80/0x140
Apr 23 12:48:08 kernel:  ret_from_fork+0x10/0x24
Apr 23 12:48:08 kernel:  __handle_domain_irq+0x70/0xd0
Apr 23 12:48:08 kernel: Task dump for CPU 0:
Apr 23 12:48:08 kernel:  gic_handle_irq+0x5c/0xc0
Apr 23 12:48:08 kernel:  el1_irq+0xe8/0x190
Apr 23 12:48:08 kernel: swapper/0       R
Apr 23 12:48:08 kernel:  cpuidle_enter_state+0x80/0x220
Apr 23 12:48:08 kernel:   running task   
Apr 23 12:48:08 kernel:  cpuidle_enter+0x18/0x20
Apr 23 12:48:08 kernel:     0     0      0 0x0000000a
Apr 23 12:48:08 kernel:  do_idle+0x1d8/0x260
Apr 23 12:48:08 kernel:  cpu_startup_entry+0x20/0x40
Apr 23 12:48:08 kernel:  secondary_start_kernel+0x13c/0x170
Apr 23 12:48:08 kernel: rcu: rcu_preempt kthread starved for 900725458428 jiffies! g14176509 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=2
Apr 23 12:48:08 kernel: rcu: RCU grace-period kthread stack dump:
Apr 23 12:48:08 kernel: rcu_preempt     R    0    10      2 0x00000008
Apr 23 12:48:08 kernel: Call trace:
Apr 23 12:48:08 kernel:  __switch_to+0xe8/0x170
Apr 23 12:48:08 kernel:  __schedule+0x214/0x5a0
Apr 23 12:48:08 kernel:  schedule+0x38/0xa0
Apr 23 12:48:08 kernel:  schedule_timeout+0x15c/0x2a0
Apr 23 12:48:08 kernel:  rcu_gp_kthread+0x488/0x900
Apr 23 12:48:08 kernel:  kthread+0x118/0x150
Apr 23 12:48:08 kernel:  ret_from_fork+0x10/0x24
Apr 23 12:48:08 kernel: Call trace:
Apr 23 12:48:08 kernel:  dump_backtrace+0x0/0x150
Apr 23 12:48:08 kernel:  show_stack+0x14/0x20
Apr 23 12:48:08 kernel:  sched_show_task+0x100/0x120
Apr 23 12:48:08 kernel:  dump_cpu_task+0x40/0x4c
Apr 23 12:48:08 kernel:  rcu_dump_cpu_stacks+0x90/0xcc
Apr 23 12:48:08 kernel:  rcu_check_callbacks+0x67c/0x810
Apr 23 12:48:08 kernel:  update_process_times+0x2c/0x70
Apr 23 12:48:08 kernel:  tick_sched_timer+0x54/0xd0
Apr 23 12:48:08 kernel:  __hrtimer_run_queues+0x13c/0x1d0
Apr 23 12:48:08 kernel:  hrtimer_interrupt+0xe4/0x2b0
Apr 23 12:48:08 kernel:  arch_timer_handler_phys+0x30/0x40
Apr 23 12:48:08 kernel:  handle_percpu_devid_irq+0x80/0x140
Apr 23 12:48:08 kernel:  __handle_domain_irq+0x70/0xd0
Apr 23 12:48:08 kernel:  gic_handle_irq+0x5c/0xc0
Apr 23 12:48:08 kernel:  el1_irq+0xe8/0x190
Apr 23 12:48:08 kernel:  cpuidle_enter_state+0x80/0x220
Apr 23 12:48:08 kernel:  cpuidle_enter+0x18/0x20
Apr 23 12:48:08 kernel:  do_idle+0x1d8/0x260
Apr 23 12:48:08 kernel:  cpu_startup_entry+0x24/0x40
Apr 23 12:48:08 kernel:  rest_init+0xcc/0xd8
Apr 23 12:48:08 kernel:  start_kernel+0x494/0x4c8
Apr 23 12:48:08 asusroot: Clock check: Current year is 1918
Apr 23 12:48:08 hostapd: wl0.1: STA 44:cb:8b:79:04:47 WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl0.1: STA 8c:85:80:cc:d6:ff WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl0.1: STA 44:cb:8b:79:01:4c WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl0.1: STA 8c:85:80:47:5c:e7 WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl0.1: STA bc:dd:c2:ee:cc:8a WPA: group key handshake completed (RSN)
Apr 23 12:48:08 hostapd: wl0.1: STA 44:61:32:ee:61:51 WPA: group key handshake completed (RSN)
Apr 23 12:48:08 asusroot: Year is 1918 (less than 1969) – restarting router
Apr 23 12:48:08 rc_service: Rebooting...

 

[RMerlin]

It seems to wrongly make the ipv6 address from my PC into a string as an ipv4 address.
Very weird and I call it embarrassing that they didn't test with ipv6.

I'm not sure if the stock firmware even expects logging to happen over IPv6, as they automatically redirect you to www.asusrouter.com, which probably resolves only as an IPv4. Asuswrt-Merlin does not enforce that redirection, so it might be causing this issue.

That means I will probably have to see if I can fix that myself. At least part of that log code is open source, no idea if enough of it is accessible for me to fix it. I suspect I might be able to fix the syslog portion, but not the Security Log portion.

 

[Howard_inGA]

Dirty upgrade from the 2nd alpha. No hitches, except that the software failed to load first try. The second immediate follow-up upgrade took with no problems...

 

[elorimer]

I noticed that when I log in to the GUI using ipv6, the new 'Security Update Notification' shows really weird ipv4 addresses:

On my AX86-Pro these correctly show logins to the router. Not sure why this would be called "Security Update Notivication" or noted as "successed".

 

[Dedel66]

I see the problem with the GT-AX6000 and its leds at boot time. I'm not sure however why only that particular model would be affected.

Can anyone test on other models? Disable the LEDs (on the Administration -> System page, reboot, and see what state LEDs are once rebooted. I need to know if I should apply the fix to all models, or only to the GT-AX6000.

The LEDs on the ax88u pro main router and the ax88u pro node are off after a reboot. They light up for about 10-20 seconds during the reboot, then go out as expected.