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!