What's new

Release Asuswrt-Merlin 3006.102.6 is now available

RT-BE88U. After updating, I did a full reset, but for a long time I couldn’t connect to the drive via Samba. Through trial and error, I discovered the issue was the password—everything worked fine without it. I changed both the logins and the password in the system, and it turned out to be related to password length. With a 12-character password, everything works. I searched for information on password length limits but couldn’t find anything on Asus.com or in the forum. Can anyone help?
 
I searched for information on password length limits but couldn’t find anything on Asus.com or in the forum. Can anyone help?
Asus implemented a change in router passwords with their firmware. For example with the RT-BE88U they implemented that change with 3.0.0.6.102_38186 (2025/08/08):
- Password Policy Upgrade – Minimum 10 characters with at least 1 letter, 1 digit and 1 special symbol, and no consecutive identical characters; hardens defence against brute-force attacks.
However per the Asus-Merlin 3006.102.6 change log (and first post of this 3006.102.6 discussion):
3006.102.6 (25-Nov-2025)
- NOTE: Asus has made some security related changes. Password
requirements are stricter, and UPNP is no longer
enabled by default. New password rules were
slightly loosened for Asuswrt-Merlin, repeating
characters are still allowed.
 
Asus implemented a change in router passwords with their firmware. For example with the RT-BE88U they implemented that change with 3.0.0.6.102_38186 (2025/08/08):

However per the Asus-Merlin 3006.102.6 change log (and first post of this 3006.102.6 discussion):
That's the catch. It says it must be at least 10 characters long, but there's no mention of a character limit—yet there is one, like in Samba. Unfortunately, I only discovered this after completely reconfiguring the router while trying to fix the Samba issue.
 
That's the catch. It says it must be at least 10 characters long, but there's no mention of a character limit—yet there is one, like in Samba. Unfortunately, I only discovered this after completely reconfiguring the router while trying to fix the Samba issue.
Samba (CIFS/SMB protocol) password length may be limited to 16 characters for legacy reasons. Some very old posts on it:

Using AI may generate possible ways to have longer passwords but unknown if such methods work on the Samba(SMB/CIF) mount that the Asus router firmware uses.
 
The new Traffic Analyzer UI is awesome.

Feature request: The graphs is labeled in bits per second (Kbps/Mbps). It would be nice if the settings included a way to show it in kb/mb / sec. (if i remember correctly the old ui had this setting)
 
I've had these repeating log entries - Every 10-90 minutes. I don't recall this in the 388 code branch, and I don't think it was in 3006.102.5 either,

I use scribe and have some very personalized rules to keep the noise in the system log down, these are quite annoying.

Jan 7 01:12:46 RT-BE86U kernel: SUSPREQ 0 SUSPREQ1 0 SUSPREQ2 0
Jan 7 01:12:46 RT-BE86U kernel: CHNSUSP_STATUS 0 CHNSUSP_STATUS1 0 CHNSUSP_STATUS2 0
Jan 7 01:12:46 RT-BE86U kernel: FLUSHREQ 0 FLUSHREQ1 0 FLUSHREQ2 0
Jan 7 01:12:46 RT-BE86U kernel: CHNFLUSH_STATUS 0 CHNFLUSH_STATUS1 0 CHNFLUSH_STATUS2 0
Jan 7 01:12:46 RT-BE86U kernel: intstatus 0x0 intmask 0x10000 aqm_intstatus 0x0 aqm_intmask 0xfebfff7f
Jan 7 01:12:46 RT-BE86U kernel: puq_idx active lmidx tid txmode 0 0x 3f 7 16384 1 raw data 0xb83f
Jan 7 01:12:46 RT-BE86U kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0xfdffe7f7
Jan 7 01:12:46 RT-BE86U kernel: puq_idx active lmidx tid txmode 1 0x 0 0 0 0 raw data 0x0
Jan 7 01:12:46 RT-BE86U kernel: intstatus 0x0 intmask 0x10000 aqm_intstatus 0x0 aqm_intmask 0xeffdbedb
Jan 7 01:12:46 RT-BE86U kernel: puq_idx active lmidx tid txmode 2 0x 0 0 0 0 raw data 0x0
Jan 7 01:12:46 RT-BE86U kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0xfff7fb3f
Jan 7 01:12:46 RT-BE86U kernel: puq_idx active lmidx tid txmode 3 0x 3f 0 16384 1 raw data 0x803f
Jan 7 01:12:46 RT-BE86U kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0xebfffef7
Jan 7 01:12:46 RT-BE86U kernel: puq_idx active lmidx tid txmode 4 0x 0 0 0 0 raw data 0x0
Jan 7 01:12:46 RT-BE86U kernel: wl0: wlc_ftm_hal_csi_buf_get:1760: hal 00000000e372d8bf
Jan 7 01:12:46 RT-BE86U kernel: CSIMON: CSIMON[1.1.1] Initialization
Jan 7 01:12:46 RT-BE86U kernel: CSIMON: M2M usr already registered ...

The system seems stable, wifi clients stay connected, Mesh and SC working as they should... but it would be nice to know what's causing it. Then I can try send it to my noise.log file.
 
@RMerlin

I just wanted to report an issue I discovered while testing things on the latest firmware.
The issue is L2/ARP failure to wired clients between LAN Port 4 and LAN Port 2 of my GT-BE98 Pro. If I move Hue Bridge I am trying to ping to LAN port 5 (1Gb) things instantly work again.

I realize this is likely out of your scope; but maybe you could escalate the message up the chain when you have a free cycle?
I know this also impacted @Viktor Jaep as he mentioned similar behavior in DMs to me previously, and I do see similar threads on the issue here: https://www.snbforums.com/threads/be-98-pro-3006-102-5-upgrade-lan-port-issue.95528/
This seems to indicate the issue has existed since firmware 102.5...

Here are some detailed screenshots and the behavior I've noticed.
When the Hue Bridge is connected to LAN port 4, my desktop cannot reach it even though both devices are on the same subnet.
The failure is clearly Layer-2 / ARP: Windows cannot resolve a MAC for 192.168.50.189 and returns “Destination host unreachable” immediately.

1767908428316.png


If I add a host route (/32) to force traffic via the router, it works (suggesting the router is effectively relaying it at L3 / proxying).
However, the real “smoking gun” is that moving the Hue Bridge from LAN4 to LAN5 (the 1Gb port) instantly resolves the issue with no workaround needed. That points to a LAN4 bridging/switching issue...

1767907406862.png


The expected behavior would be on a flat /24, the Desktop PC should ARP for 192.168.50.189 and then ping it directly (on-link).
No static routes should be required. But the actual behavior can be seen below (only when Hue Bridge is on LAN Port 4)

From my desktop on LAN port 2:
Ping fails immediately:
Code:
ping 192.168.50.189
Reply from 192.168.50.163: Destination host unreachable.

Traceroute fails immediately at hop 1 (local host unreachable):
Code:
tracert 192.168.50.189
1  192.168.50.163 reports: Destination host unreachable.

No ARP entry for the Hue Bridge:
Code:
arp -a | findstr 192.168.50.189
<no output>

1767907840351.png


Windows neighbor table explicitly shows it as unreachable:
Code:
netsh interface ipv4 show neighbors | findstr 192.168.50.189
192.168.50.189  Unreachable  Unreachable

Routing table is correct (on-link /24 route exists):
Code:
route print -4 | findstr 192.168.50.
192.168.50.0  255.255.255.0  On-link  192.168.50.163

1767907887886.png


So the PC is doing the right thing (treating it as on-link), but ARP resolution is failing.
Things I’ve already verified (to rule out config / isolation)

- The Hue Bridge is NOT on a Guest/IoT SSID with LAN blocked.
- There is no AP/client isolation enabled on the primary network/VLAN
- I’ve ensured everything is on the same bridge/VLAN
- The router correctly sees the Hue Bridge online at 192.168.50.189.
1767908005972.png


The 2 current workarounds I've found (while keeping isolation enabled on the Guest VLANs) are:
1. Moving my Hue Bridge from LAN Port 4 to LAN port 5 (1Gb Port) things will instantly work again, even without the below route.
2. Or add a /32 host route so Windows sends it to the gateway instead of ARPing for the Hue Bridge directly, the desktop can ping it:
Code:
route add 192.168.50.189 mask 255.255.255.255 192.168.50.1 metric 1
This allows things to continue to work on LAN Port 4 and LAN Port 2.

After that, ping works.
This is not a “real fix” for a same-subnet host. it’s just a workaround that avoids direct ARP to 192.168.50.189.
 
Last edited:
I realize this is likely out of your scope; but maybe you could escalate the message up the chain when you have a free cycle?
What fantastic troubleshooting! I guess there’s no way you could try to raise the issue with Asus (just for laughs) as you’re using Merlin to run all the checks ?
 
What fantastic troubleshooting! I guess there’s no way you could try to raise the issue with Asus (just for laughs) as you’re using Merlin to run all the checks ?

I absolutely will send them a message shortly, but I was giving RMerlin first dibs 😉
Because yes I run Merlin firmware, and I'm not 100% positive this is something out of scope for him. Even if it is, he has more weight and contacts than I do in reporting things.

Just unfortunately when I escalate to Asus I often get some level 1 tech that wants me to factory reset and play with settings unnecessarily.
(No harsh feelings ASUS, love your products, but your support can be a bit lacking)

Anyways, just putting the report here first to see if anything sticks, and help others if they have the issue, otherwise I'll for sure find the ASUS contact info again.
 
Last edited:
@RMerlin

Thanks for our detailed behind-the-scenes discussions troubleshooting this weird issue, and for kicking this off, @ExtremeFiretop ... Wanted to confirm that I had very similar issues, recently moving a working static route from my original GT-AX6000 to the GT-BE98Pro.

In my case, I had an RT-AX88U's WAN port plugged into the LAN 2 port on the BE98. This route statement (below) provided a path for the 88U to my other network (LAN 4) using the BE98's LAN IP in order to push BACKUPMON backups to it, and it failed in being able to establish a route to it. But as soon as I moved the cable from LAN 2 to LAN 5, everything worked fine.

RT-AX88U route using BE98 as gateway
1767955492794.png


GT-BE98Pro (192.168.50.1) route to backup server on 86.x network
1767956109254.png


@ExtremeFiretop dug up a post stating that if you had enabled AP isolation on one of your Wi-Fi networks, that for some reason the LAN ports might be joining in on isolating themselves, and that an apparent fix is turning off AP isolation, which makes the LAN ports function as normal. This seemed to affect RT-BE92U's and the BE98Pro's according to the post... but haven't confirmed this behavior myself. However I just noticed above that @ExtremeFiretop was experiencing this issue even with AP isolation turned off. So this may be a non-issue. So this looks like this may be the issue afterall (after reading @ExtremeFiretop's latest post below).


I'm guessing this is probably something low-level enough that Asus probably needs to pursue on their end, but just wanted to get this in front of you.
 
Last edited:
- There is no AP/client isolation enabled.
However I just noticed above that @ExtremeFiretop was experiencing this issue even with AP isolation turned off. So this may be a non-issue.

Just to be 120% clear, I had no AP/client isolation enabled for my "primary" network/VLAN.
Sorry for the potential confusion, I've now edited my post to make that more clear.

The primary network / VLAN is where I validated; as that is what the LAN ports are using. (They fall within the primary VLAN, same as my desktop)
The goal of stating no isolation was enabled was to indicate that the configuration didn't call for isolation of those LAN ports.

However I do have isolation enabled for 2 of my Guest Networks.
I did turn it off on both Guest Networks temporarily, and the results are the same as that thread, which is why I linked to it.

It confirms the issue is related that the thread I linked, if my Guest Networks have isolation disabled, everything begins working as expected.

1767981738515.png


Even though my Guest networks are on their own VLAN separate from the primary network and the LAN ports are not configured to use that VLAN.

1767981859920.png
 
First, THANX for the update!
Dirty update from 102.4 to 102.6, GT-AX16000.
Everything seems to be working fine, except I have a possible annoying UI bug.
Seems that on Network Map page, as well as the Smart Connect Rule page (may affect others with the same "List" option/code), when clicking/viweing:
View List
Client List
by All and Network

Using either All *or* Network choice, the popup window keeps resetting/scrolling to top, every refresh, doesnt give time to even read/see full list.
ie if the lists are longer than the view size, and you have to scroll down to see out-of-view items, every 3 seconds, during the refresh, the view pops back to the top of the view/list.
Quite annoying when there is a long list to view.

Now, no idea if it could be on my end, I am using LibreWolf (Firefox fork) for browser, and I am on a 1600x900 laptop. I also have Windows10 UI set to 125% default, as my eyesight is bad.
Using the *browser* quick zoom setting, I'm usually at 100%, but I have to go to 50%, to make the popup view non-scrollable, so the full list is viewable at all atimes (ie, thru all the 3 sec. refreshes). But, obv. 50% is extremely tiny to read.

LMK if more info needed.
Thanx!
 
First, THANX for the update!
Dirty update from 102.4 to 102.6, GT-AX16000.
Everything seems to be working fine, except I have a possible annoying UI bug.
Seems that on Network Map page, as well as the Smart Connect Rule page (may affect others with the same "List" option/code), when clicking/viweing:
View List
Client List
by All and Network

Using either All *or* Network choice, the popup window keeps resetting/scrolling to top, every refresh, doesnt give time to even read/see full list.
ie if the lists are longer than the view size, and you have to scroll down to see out-of-view items, every 3 seconds, during the refresh, the view pops back to the top of the view/list.
Quite annoying when there is a long list to view.

Now, no idea if it could be on my end, I am using LibreWolf (Firefox fork) for browser, and I am on a 1600x900 laptop. I also have Windows10 UI set to 125% default, as my eyesight is bad.
Using the *browser* quick zoom setting, I'm usually at 100%, but I have to go to 50%, to make the popup view non-scrollable, so the full list is viewable at all atimes (ie, thru all the 3 sec. refreshes). But, obv. 50% is extremely tiny to read.

LMK if more info needed.
Thanx!
Apparently an issue with Firefox -- it works as expected with Chrome.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top