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