u/littlebighuman

TL;DR: I upgraded a 5-year-stable ASUS WiFi 6 AiMesh to WiFi 7 (RT-BE92U + RT-BE58U). Both units are unstable in the same way: clients stay "connected" but lose internet for 1-2 minutes at a time, and the main unit randomly crash-reboots. I logged the errors for weeks. The data points squarely at the ASUS/Broadcom WiFi 7 driver, not my configuration. ASUS support acknowledged a Broadcom-chip conflict in writing but offered only a firmware downgrade with no fix timeline, and no replacement. I'm going back to WiFi 6. If you're about to buy ASUS WiFi 7, read this first.

Background

I've run ASUS routers for over 15 years and an AiMesh for 5+, all on wired Ethernet backhaul. The old setup (RT-AX86U as the main node plus older nodes) was boringly reliable.

Worth being clear about why I upgraded: it was not for WiFi 7 wireless. I'd moved my switches to 2.5 GbE and my internet to 2 Gbit, and I wanted the AiMesh wired backbone and uplinks to actually use that multi-gig capacity. The newer units have 2.5 GbE ports, so the draw was the wired side. WiFi 7 / 6 GHz came along for the ride and I made the classic mistake of "newer tech, probably better" assumption.

In April 2026 I upgraded the main node to an RT-BE92U (tri-band WiFi 7, has 6 GHz) and added an RT-BE58U (dual-band WiFi 7, no 6 GHz). I kept the WiFi 6 RT-AX86U in the mesh as a node. All three on the latest official firmware (3.0.0.6.102). The irony is that the feature I didn't actually need (WiFi 7) is the one that broke the network.

Symptoms

• User-facing: wireless clients periodically lose internet for 1-2 minutes while still showing "connected" to the SSID. Wired clients are always fine.
• Quickly switching Wifi off/on would usually fix it. For instance when watching a youtube video that frooze.
• On the AP itself: the RT-BE92U crash-rebooted on its own three times in eight days, each time with a kernel stall and the clock resetting to the year 1918.

The data

Because the stalls were intermittent, I forwarded syslog from all three nodes to a Synology and aggregated the error counts daily. Then I ran a controlled 24-hour comparison: all three APs, same single SSID, same clients, same wired backhaul, same house. Only the hardware differs.

AP	Class	MLO ERROR / 24h	SCB deauth -30 / 24h
RT-BE92U (CAP)	Broadcom WiFi 7, tri-band incl. 6 GHz	156	378
RT-BE58U (node)	Broadcom WiFi 7, dual-band, no 6 GHz	0	307
RT-AX86U (node)	Broadcom WiFi 6, dual-band	0	0

What this shows:

1. The SCB deauthorize -30 errors are not specific to one model. Both WiFi 7 units throw hundreds per day. The only difference between the clean RT-AX86U and the broken RT-BE58U is the Wi-Fi generation. That puts the bug in the WiFi 7 driver branch shared across ASUS's WiFi 7 lineup, not in any one product's firmware tuning.
2. The MLO errors track the 6 GHz radio. The dual-band BE58U (no 6 GHz) logs zero MLO errors; the tri-band BE92U logs plenty.
3. The WiFi 6 unit on the identical network is completely silent. That rules out my environment, my clients, and my configuration.

The log signatures, for anyone searching later:

wlceventd: ... wlX: SCB deauthorize 30 ...
wlX-vifY: MLO ERROR [wlc_ap_process_assocreq] ... status 30

My clients (because someone will comment "it's your devices")

It's a busy, heavily-Apple household. The regulars: around 7 MacBooks (Air/Pro), 5 iPhones (16 and 16 Pro), 5 Apple Watches, a couple of Windows laptops, three Apple TV's plus the usual pile of 2.4 GHz smart-home / IoT (Netatmo, HomeWizard energy monitor, LG sensors, an Espressif board, assorted plugs and sensors), different version of Raspberry Pi's. I have more stuff, but that is connected via ethernet.

This is relevant, not just background. The iPhone 16 / 16 Pro and the recent MacBooks are Wi-Fi 6E/7 clients, so they're the ones that actually use 6 GHz and attempt MLO association. In other words, my client fleet is exactly the kind that exercises the WiFi 7 code path, and the MLO ERROR status 30 events line up with those devices.

Now, the obvious reply to an Apple-heavy home is "it's Apple's aggressive Wi-Fi power-save, known issue." Two things kill that:

1. Same devices, only WiFi 7 fails. These exact iPhones and MacBooks roam across all three APs on one SSID. The WiFi 6 RT-AX86U serves every one of them with zero errors; the two WiFi 7 units throw hundreds per day. If the Apple devices were the cause, the WiFi 6 AP carrying the identical devices would show it too. It doesn't. The clients are the constant; the Wi-Fi generation is the only variable.
2. I tested the power-save theory directly. Disabled WMM APSD on all bands (the usual "fix" for Apple power-save churn). No improvement, slightly worse if anything. So "it's your iPhones" doesn't survive contact with the data.

What I tried (none of it fixed the errors)

• Latest official firmware on both units.
• Full factory reset on both, reconfigured from scratch. The numbers above are post-reset. This rules out leftover config / nvram state.
• Disabled Roaming Assistant (helped node churn, did nothing for SCB-30/MLO).
• Disabled MLO via the app toggle (no effect on MLO error counts).
• Disabled WMM APSD on all bands (community-suggested fix; no help, slightly worse).
• Fixed non-DFS channels, fixed channel width, forced wired backhaul, single SSID.

Config levers are exhausted. A full factory reset not changing anything, while a WiFi 6 unit on the same network stays silent, is about as clear as it gets: this is a driver/firmware defect.

How ASUS support responded

To their credit, the technician was honest. He confirmed in writing that my logs show a conflict with the Broadcom chips. But the only remedies offered were:

1. Submit the bug to R&D in Taiwan myself via the router's feedback tab, and
2. Downgrade the firmware and wait for an eventual fix, with no timeline.

No RMA, no replacement, no committed fix date. The downgrade is a non-starter for me because the earlier firmware had the same errors. So the official position is effectively "roll back and wait indefinitely."

What I'm doing

I'm switching back to WiFi 6 (ordered two RT-AX88U Pros) and keeping AiMesh. It's the one ASUS driver generation my own logs prove is clean. Crucially, the AX88U Pro has dual 2.5 GbE ports, so I keep the multi-gig wired backbone that was the actual reason I upgraded, and I only drop the 6 GHz / MLO radio layer that was broken. I lose nothing I wanted.

One bright spot: even though I was past the standard return window, Amazon agreed to take the WiFi 7 unit back for a full refund, treating it as defective. Manufacturer-acknowledged defect plus hard data apparently carries weight. So if you're stuck with an unstable RT-BE unit and ASUS only offers you a downgrade, it's worth pushing your retailer on a defect return rather than waiting on ASUS. Caveat, this is amazon.nl in Europe.

Why this is bigger than two models: it's the chipset, not the SKU

This is the part I most want people to understand before buying. Almost the entire ASUS WiFi 7 range is built on the same Broadcom WiFi 7 chipset family (BCM6766/6726-class) running the same ASUSWRT 3.0.0.6 firmware branch. The marketing splits them into "mainline," "ZenWiFi mesh," and "ROG gaming" tiers at wildly different prices, but the radio silicon and the driver code underneath are shared. The bug lives in that shared layer, which is exactly why my BE92U (tri-band flagship) and my BE58U (cheap dual-band node) fail in the same way.

My logs only personally confirm the two units I own. But because they share the platform, every model below is built on the same Broadcom WiFi 7 stack and I'd treat them all as suspect until someone posts clean data:

Mainline (RT-BE): RT-BE96U, RT-BE92U*, RT-BE88U, RT-BE86U, RT-BE58U* ZenWiFi mesh: ZenWiFi BT12, BT10, BT8, BT6 ROG / gaming: ROG Rapture GT-BE98, GT-BE98 Pro, GT-BE96, GT-BE19000, ROG Strix GS-BE18000

(* = the two I personally confirmed with logs.)

That's a flagship quad-band router, a budget node, and an 18000-class gaming unit all sharing the same defect surface. The price tag doesn't change the driver.

The one exception: ASUS's ZenWiFi BD4 / BD5 use a MediaTek Filogic chipset instead of Broadcom, so they're on a completely different driver lineage and likely not affected. Community data on them is sparse.

Takeaways

• If your ASUS WiFi 7 router randomly drops clients or reboots itself, it's probably not your config. Pull the syslog and grep for SCB deauthorize 30 and MLO ERROR.
• It's a chipset/driver-level problem, so jumping to a different ASUS WiFi 7 model (even a pricier ROG one) likely gets you the same bug. The fix is either a Broadcom driver patch or stepping back to WiFi 6 / 6E.
• WiFi 6 / 6E ASUS gear (RT-AX, RT-AXE, ZenWiFi XT/XD/ET, ROG AX/AXE) is on a different, mature driver branch and has been rock solid for me.
• If you don't specifically need WiFi 7, I'd wait until ASUS/Broadcom actually ship a driver fix before buying into the RT-BE line.

Not trying to brand-bash. I want to keep using ASUS. But people deserve to know this before spending several hundred euro on a flagship that ASUS itself can only tell you to downgrade.

Happy to share more detail or a redacted log sample if it helps anyone debugging the same thing.

I have had Asus router for 10+ years and am using a six node aimesh network for 6+ years and I'm (was) very happy, not too many issues. Fyi, I use my "routers" in AP mode, I have an Opnsense firewall with dual-WAN that does the routing/internet.

About 2 months ago, I decided I wanted to upgrade my main router/AP RT-AX86U to a newer model, I ended up buying the RT-BE92U, mostly for the 10 en 2.5 GBit interfaces, as I have upgraded my wired network to 2.5 gbit with 10 gbit trunks. I don't really need Wifi 7. Fyi, I also bought a RT-BE58U to use as an additional aimesh node, I have no problems with this one, that one is running perfectly.

I only managed to install it about a month ago as the main router in my aimesh network and I have nothing but problems. I have a bunch of Apple computers, iPhones, Apple watches etc at my home, some iOT, but nothing than minutes of broken internet connections. Lots of MLO errors, SCB deauthorize events. To be clear, only when connected to the  RT-BE92U's wifi. All the other AP's are fine, wired is fine.

I upgraded to the latest firmware. Some googling indicated there are bugs in the drivers for the Broadcom chipset used. I tried Claude to try to troubleshoot the errors for a week, but getting nowhere.

I need to have stable internet, because me and my oldest daughter work 100% from home. So I decided to get another router/AP. Does anyone have tips for a good stable Asus aimesh compatible router, with 2.5 Gbit interfaces?

Hi all,

I have my middle mouse button assigned to Mission Control. I don’t want to change this, as it’s a big part of how I work with multiple Spaces across multiple screens.

However, in Autodesk Fusion this causes some issues, since the middle mouse button is needed for navigation. I tried setting up BetterTouchTool for Fusion only, but nothing I’ve tried seems to work. I can’t find a way to “pass through” Mouse Button 3 to Fusion just for this purpose.

Is this even possible? I guess the complication is that I need to be able to click and drag with it, as well as use Shift + middle-click and drag.

Maybe I could create a shortcut that temporarily disables the Mission Control mouse button assignment?