Attempting to track Down a Persistent Broadcom Kernel Instability on Asus RT-BE92U in an AiMesh Setup

[Nihilist71]

Sharing My Deep-Dive: Attempting to track Down a Persistent Broadcom Kernel Instability on Asus RT-BE92U (Merlin) in an AiMesh Setup​

Hi everyone,

I wanted to share a detailed log analysis and troubleshooting process for a frustrating stability issue I've been experiencing on my network. This problem appears to be rooted in a deep, recurring bug within the proprietary Broadcom Wi-Fi kernel drivers used by ASUS. I've already posted about this issue on the official ASUS Zentalk forum but am now sharing my findings here to engage with the technical community.

My network setup is:

• Hardware: Two ASUS RT-BE92U routers (Main + Node)
• Mesh: AiMesh setup utilizing Ethernet Backhaul.
• Firmware: AsusWRT-Merlin 3006.102.5
• SSIDs: The network is segmented into three SSIDs: MAIN_WIFI, LEGACY_IoT, and Guest_Wifi.

The core symptom is a gradual, but inevitable, network degradation leading to high latency and sluggish Wi-Fi for all clients, typically manifesting 12–24 hours after a reboot.

1. Identifying the Core Error​

The problem consistently traces back to one specific, recurring kernel error, which is overwhelmingly triggered after a client decides to disconnect or goes into deep sleep due to inactivity:

[ROUTER_IP] wlX.X: Deauth_ind [CLIENT_MAC_A], reason: Disassociated due to inactivity (4)kernel: WLC_SCB_DEAUTHORIZE error (-30)

Interpretation: The router's kernel is failing to correctly de-allocate the memory block (SCB - Station Control Block) associated with the disconnecting client. This indicates a memory management failure deep within the proprietary Broadcom kernel code.

2. Initial Suspects & Tests​

The bug is most frequently triggered by modern devices using aggressive power-save modes, particularly Apple devices.

• Test 1: Apple Client Configurations (MAC Randomization): We disabled the "Private Wi-Fi Address" feature on all Apple client devices and eliminated a noisy Apple Watch (MAC ending in 48:49) from the network.
  
  • Result: Did not solve the -30 kernel bug. The issue is deeper than client settings.
• Test 2: Disabling Wi-Fi 7 Mode (MLO)
  
  • Hypothesis: The error was linked to the complex Multi-Link Operation (MLO) logic.
  • Action Taken: Disabled Wi-Fi 7 (802.11be) mode on our main network today (Nov 10th @ 9:45 AM CET).
  • Result: Failed. The stability improved for a few hours (no errors logged for ~3 hours), but the error returned at 12:32:37 today, shortly before the router required a manual reboot. This proves the kernel bug persists even in non-MLO modes.

3. The Current Focus: WMM Automatic Power Save Delivery (APSD)​

Since the error is directly linked to client inactivity, the last remaining configurable suspect is the power management protocol that negotiates the client's sleep cycles.

• Hypothesis: The proprietary Broadcom driver struggles to correctly execute the WMM Automatic Power Save Delivery (APSD) protocol, causing the SCB memory failure.
• Action Taken (Current Status): As of today (Nov 10th @ 12:48 PM CET), I have disabled WMM APSD on all radio bands (5 GHz and 6 GHz, 2.4 GHz was already off).
• Status: The router is now operating with both Wi-Fi 7 (MLO) and WMM APSD disabled. This configuration simplifies the power management logic to the bare minimum.

I'm currently observing the system to see if this change finally eliminates the error, though my expectations are low as this appears to be a core driver bug.

Has anyone else on an ASUS/Broadcom Wi-Fi 7 platform seen similar kernel errors (WLC_SCB_DEAUTHORIZE error (-30))?
Any shared experiences or solutions would be greatly appreciated as I continue to observe the logs!

Thanks for reading, and I'll keep the thread updated with the results of the APSD test!

 

[Nihilist71]

UPDATE (Nov 11): Stability Issues Continue on RT-BE92U – APSD Disabled​

Hi everyone,

I'm providing an update on the ongoing deep-dive into the kernel stability issue (WLC_SCB_DEAUTHORIZE error (-30)) on my RT-BE92U AiMesh (Ethernet Backhaul) running AsusWRT-Merlin.

Recap: The core problem is a memory failure in the proprietary Broadcom Wi-Fi kernel drivers triggered by power-saving clients entering deep sleep (reason: Disassociated due to inactivity (4)).

---

Test 1: Disabling Wi-Fi 7 Mode (MLO)​

• Result: Reduced frequency of the error, but the bug persisted.

Test 2: Disabling WMM Automatic Power Save Delivery (APSD)​

• Action Taken: WMM APSD was disabled on all bands (2.4, 5, and 6 GHz)
• Result: Failed Overnight. The network ran stable for nearly 12 hours, which is a significant improvement over previous tests. However, the critical error finally recurred just after midnight:
  • Nov 11 00:30:33 on the AiMesh Node
  • The trigger was a de-authentication from an Apple TV 4K.

Conclusion: Disabling APSD extended stability but did not eliminate the core memory/SCB bug. This strongly suggests the issue is a fundamental flaw in the Broadcom kernel code itself, likely relating to the 6 GHz band's interaction with the AiMesh architecture and/or power management.

 

[jzchen]

Did you also post on ZenTalk? I @ a moderator there so hopefully techs can take a look....

 

[Nihilist71]

Did you also post on ZenTalk? I @ a moderator there so hopefully techs can take a look....

Yes I did, I saw someone tagging a moderator. Although I've seen reports about Broadcom driver issues like these for almost a year so I'm not holding my breath.

 

[GJJ]

Possibly related....

Like many, I was having trouble with my 2.4GHz radio dropping after 1h or so, after upgrading to the most recent fw (Oct 31 2025).

With some help from Spartan, I managed to track it down to some "smart" bulbs installed in one of our rooms. We're only using them as dumb bulbs and are switching them off at the light switch, rather than messing around with an app. There are 3 bulbs, so when we flick the switch on, all 3 turn on together and when we flick it off, all 3 power off together. It turned out that most of the time, after switching them off, the router's 2.4GHz radio would crash. It didn't matter if the bulbs were on the main wifi network or were on an IOT network, switching them off would crash the whole radio.

As part of my fault finding, I set up an IOT network and had to move the bulbs over. During the setup process for each bulb, the 2.4GHz would crash as they left the main network and before joining the IOT network. That was annoying and repetitive.

I have now excluded their MACs from any network on the 2.4GHz and it has been stable for the past 24h now. Ok, not very long and the expectation is for an almost infinite up time, but hey, 24h is better than 1h or less.

I don't have the experience or knowledge to prove it, but I think it supports your disassociation theory above.

Sorry, I didn't keep any log files of when this was happening. I do get the disassociation errors that you are seeing, when other wireless devices on my network wake up and go to sleep and come and go.

Hope this helps.
GJ

 

[DrVoidberg]

Heyo,
I decided to abandon ASUS, but thought I'd drop my gathered info in case it can help you or somebody else along.

The background
I've accumulated a mishmash of TP-Link hardware of all sorts and ages over the years. Routers, switches, routers as access points and switches, access points, repeaters. It's an old-ish (and very long) house, so cable routing is a bit complicated and far from ideal. And after falling down the smart home rabbit hole while chasing an abnormally high power consumption, the WiFi was getting a bit unreliable with all the new IoT devices. Two additional WiFis in the viscinity but outside my reach didn't particularly help either.
So I decided to finally upgrade to some modern equipment and after a bit of looking around, the RT-BE92U looked like a solid, albeit not cheap option. I got three of them to replace the main router and have two more as access points to cover the complete house. One TP-Link access point (TL-WA850RE) in the basement and a TP-Link repeater (RE550) in the garage remained. (Funny side note: The access point in the basement was used only as repeater previously as it would immediately crash the entire network when connected via ethernet cable to the old TP-Link router)

The setup
All three units are running the latest original firmware. The two Asus APs are connected via ethernet to a managed TP-Link switch (due to said complicated cable routing) which is connected to the main router. The TP-Link AP is connected directly to the main router. I'm running a 2.4/5 GHz main WiFi and a 2.4 GHz only IoT WiFi. No VLANs or other shenanigans. The TP-Link devices only transmit the IoT network.
Initially I had AiMesh set up with ethernet backhaul, but it was absolutely horrible. Devices would keep dropping out and not returning (and especially the ACs are a pain to get back in) and my phone often simply refused to connect. So I changed to Router/AP setup, which works a lot better.

The situation
The network itself is stable, but I keep having the main router crash randomly several times a day, which is super annoying as it takes quite a long time to boot back up.

The analysis
Packet tracking with Wireshark did not show anything out of the ordinary, but I noticed quite a few of the DEAUTH messages in the router log right before the crash would occur. After closer expection of the MAC addresses, it turned out that all deauths yesterday came from 14 devices. 11 were Shelly power meters/relays, one self-made ESP device, the WiFi repeater in the garage (!) and a MAC that did not appear in any of my lists (which should not be possible) but could also come from the repeater. Many of these are usually connecting to the remaining TP-Link devices.
Interesting side finding: The TP-Link repeater in the garage reports its MAC as F0:09:0D:E1:60C and F0:09:0D:E1:60D for 2.4 and 5 GHz respectively. The router's logs (and the sticker on the device IIRC) say it's F6:09:0D:E1:60C. The unidentified one is F6:99:04:80:0F:E7.
The measures
I've tried basically everything I could find here and elsewhere. Everything done to all Asus devices respectively. Turn off the 6 GHz band, deactivate 160 MHz bandwidth, turn off roaming assist and WMM APSD on all remaining bands.
Yet the issue persists.
After turning off roaming assist and WMM APSD, the router started massively spamming kernel: CSIMON: M2M usr already registered ... messages and some other stuff which I haven't noticed before.

The bottomline
The bottomline is: F*** this s***. When I spend north of 170€ per pop on WiFi equipment, I expect it to bloody work flawlessly.
Since none of the measures seem to be promising, I'm returning the Asus devices while I still can. I really don't want to relive the good old dial-up days. Especially not at that price point.
I have ordered a Ubiquiti setup that should accomplish the same coverage for pretty much the same price point. I think it's safe to assume they know their stuff a lot better than Asus does.

Hope that somehow maybe helps. If you wish any more details on any of the things, please feel free to ask.

 

[Tech9]

The bottom line is: F*** this s***.

You're not the first one returning RT-BE92U and replacing it with something else. Long model specific thread here with shared user experience similar to yours:

ASUS RT-BE92U

New ASUS RT-BE92U. https://dongknows.com/asus-wi-fi-7-hardware-expanded-significantly/ This is a BE9700 router, somewhat of a replacement for the RT-AX92U, though it shares the same design as the RT-AX86U. Cost: $329...

www.snbforums.com

 

[DrVoidberg]

You're not the first one returning RT-BE92U and replacing it with something else. Long model specific thread here with shared user experience similar to yours:

ASUS RT-BE92U

New ASUS RT-BE92U. https://dongknows.com/asus-wi-fi-7-hardware-expanded-significantly/ This is a BE9700 router, somewhat of a replacement for the RT-AX92U, though it shares the same design as the RT-AX86U. Cost: $329...

www.snbforums.com

Oof, seems like they should maybe just quietly stop selling it and never talk about it again. Unfortunately one usually finds these informations only after the fact.
I'm just glad I can still get my money back. Only a few wasted hours, but wiser in the end.

 

[Tech9]

There is a lot of false advertising on the consumer market. First, latest, greatest, best, seamless, amazing... disposable products. If you have wired infrastructure, good budget and enough knowledge - go SMB.

 

[DrVoidberg]

There is a lot of false advertising on the consumer market. First, latest, greatest, best, seamless, amazing... disposable products. If you have wired infrastructure, good budget and enough knowledge - go SMB.

I can second that. I'm honestly surprised I even got that far with that random assortment of hardware and 75-ish clients.
The first time I was thinking that I maybe need professional networking equipment was when the TP-Link router told me that I can't assign more than 32 static IPs. I thought it must be joking... I still cannot imagine a logical reason for that limit. (But I don't know very much about networks either)
I specifically bought a 50 cm long drill bit to realize wired infrastructure but it's still pretty hacked together. If/when we tear down any walls for renovation I'll make sure to run plenty of ethernet cables. As of now even having enough power outlets is a challenge. The previous owners didn't believe in electricity or something, idk. But in any case it's challenging after the fact because half of the house is solid wall and the other half is solid wall clad with drywall. No idea how that's called in english.
Budget is fortunately not an issue and the knowledge will come as needed. But from what I've seen it will be a walk in the park compared to getting home assistant OS to run in a VM on a raspberry pi that's also hosting the weather station and a DIY NAS in RAID - without any prior Linux experience. Sounds like I'm a glutton for punishment.

 

[aaronwt]

Sharing My Deep-Dive: Attempting to track Down a Persistent Broadcom Kernel Instability on Asus RT-BE92U (Merlin) in an AiMesh Setup​

Hi everyone,

I wanted to share a detailed log analysis and troubleshooting process for a frustrating stability issue I've been experiencing on my network. This problem appears to be rooted in a deep, recurring bug within the proprietary Broadcom Wi-Fi kernel drivers used by ASUS. I've already posted about this issue on the official ASUS Zentalk forum but am now sharing my findings here to engage with the technical community.

My network setup is:

• Hardware: Two ASUS RT-BE92U routers (Main + Node)
• Mesh: AiMesh setup utilizing Ethernet Backhaul.
• Firmware: AsusWRT-Merlin 3006.102.5
• SSIDs: The network is segmented into three SSIDs: MAIN_WIFI, LEGACY_IoT, and Guest_Wifi.

The core symptom is a gradual, but inevitable, network degradation leading to high latency and sluggish Wi-Fi for all clients, typically manifesting 12–24 hours after a reboot.

1. Identifying the Core Error​

The problem consistently traces back to one specific, recurring kernel error, which is overwhelmingly triggered after a client decides to disconnect or goes into deep sleep due to inactivity:

[ROUTER_IP] wlX.X: Deauth_ind [CLIENT_MAC_A], reason: Disassociated due to inactivity (4)kernel: WLC_SCB_DEAUTHORIZE error (-30)

Interpretation: The router's kernel is failing to correctly de-allocate the memory block (SCB - Station Control Block) associated with the disconnecting client. This indicates a memory management failure deep within the proprietary Broadcom kernel code.

2. Initial Suspects & Tests​

The bug is most frequently triggered by modern devices using aggressive power-save modes, particularly Apple devices.

• Test 1: Apple Client Configurations (MAC Randomization): We disabled the "Private Wi-Fi Address" feature on all Apple client devices and eliminated a noisy Apple Watch (MAC ending in 48:49)from the network.
  • Result: Did not solve the -30 kernel bug. The issue is deeper than client settings.
• Test 2: Disabling Wi-Fi 7 Mode (MLO)
  • Hypothesis: The error was linked to the complex Multi-Link Operation (MLO) logic.
  • Action Taken: Disabled Wi-Fi 7 (802.11be) mode on our main network today (Nov 10th @ 9:45 AM CET).
  • Result: Failed. The stability improved for a few hours (no errors logged for ~3 hours), but the error returned at 12:32:37 today, shortly before the router required a manual reboot. This proves the kernel bug persists even in non-MLO modes.

3. The Current Focus: WMM Automatic Power Save Delivery (APSD)​

Since the error is directly linked to client inactivity, the last remaining configurable suspect is the power management protocol that negotiates the client's sleep cycles.

• Hypothesis: The proprietary Broadcom driver struggles to correctly execute the WMM Automatic Power Save Delivery (APSD) protocol, causing the SCB memory failure.
• Action Taken (Current Status): As of today (Nov 10th @ 12:48 PM CET), I have disabled WMM APSD on all radio bands (5 GHz and 6 GHz, 2.4 GHz was already off).
• Status: The router is now operating with both Wi-Fi 7 (MLO) and WMM APSD disabled. This configuration simplifies the power management logic to the bare minimum.

I'm currently observing the system to see if this change finally eliminates the error, though my expectations are low as this appears to be a core driver bug.

Has anyone else on an ASUS/Broadcom Wi-Fi 7 platform seen similar kernel errors (WLC_SCB_DEAUTHORIZE error (-30))?
Any shared experiences or solutions would be greatly appreciated as I continue to observe the logs!

Thanks for reading, and I'll keep the thread updated with the results of the APSD test!

I am seeing the same error in my BE96U logs. It is in the log many, many times.
But, it has not caused any issues. My setup was rock solid for weeks. With two BE96U UNITS. One as a router and one as a node. Previously, I was using BE92U units, which made everything unstable. After I transferred my BE92U settings file to the BE96U, everything was instantly rock solid. And even after several weeks, I was still able to get 1.5Gbs+ speeds over MLO WiFi7.

Although, around 12 or 13 days ago I reset the router and input everything from scratch. Since it was showing a missing BE92U node that did not exist any more. Even though I had deleted the BE92U node before saving the settings. But, it has been as solid and as fast as before.