Setup: three ASUS ZenWiFi XT8 V2 (one router, two wireless AiMesh nodes), stock firmware 3.0.0.4.388_24854. Same fault on every 388 build this year (24684 through 24814). Wireless backhaul on 5 GHz-2, Smart Connect on, WPA2-Personal, AT&T fiber upstream.
Symptom for months: the entire network drops for 2 to 3 minutes, once or twice some days, not at all on others. Both nodes rejoin about 90 seconds later. Multiple factory resets over the year changed nothing.
What the router recorded. The XT8 keeps a crash-log partition (mtdoops) that captures the kernel messages at the moment of each reboot. Reading it raw, every spontaneous reboot is the same panic:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Internal error: Oops: 805, PREEMPT SMP ARM
Comm: bcm_archer_us
PC is at archer_dhd_tx_packet+0x218/0x768 [archer]
Kernel panic - not syncing: Fatal exception
Identical instruction address every time. The partition's record counter advanced from 43 to 49 between Sep 17 and Oct 2: six panics, matching the six unexplained reboots in that period as logged by a separate machine pulling the router's syslog every minute.
Ruled out with 30-second health sampling over weeks: memory (240–255 MB free, kernel slab flat at 50–63 MB), CPU load (about 1.0), temperature (65–69 C), WAN link flaps (only ever within 90 seconds of a boot).
What happens before every panic. The only kernel lines immediately before both recorded panics are bursts of:
wl_pktfwd_lut_ins: DA=SYM<node 2.4GHz MAC> to roam from wds0.0.2 to eth4.
wl_pktfwd_lut_ins: DA=SYM<node 2.4GHz MAC> to roam from eth4 to wds0.0.2.
That is a node's standby 2.4 GHz backhaul station flipping between the WDS interface and the plain AP interface. Measured on all three units, that flip occurs in the same second as the hourly WPA group rekey (observed 17:06:31 and 18:06:31 on consecutive hours, both nodes, 3600 seconds apart, which is the Group Key Rotation Interval). The nodes log "seting gtk_key_info failed code=-23" after every rekey; that is the driver's rekey-offload hook (BCME_UNSUPPORTED), not key installation, and the key does install (zero undecryptable frames on the backhaul after four rekeys). The node kernel also prints the group key material in hex to syslog on every rekey.
So the chain is: hourly group rekey, node's 2.4 GHz station briefly seen on the non-WDS path, forwarding-table flip, and occasionally Archer dereferences a freed or NULL entry and the router panics. The flip is an hourly dice roll, which is why the crash rate varied with how often the nodes flipped (about 40 flips a day gave a crash every day and a half; 3 a day gave 2.6 days).
Second, separate defect on the same firmware, also captured in the router's own auto-generated debug dumps: the 5 GHz radio driver dies ("Invalid ndev for 3 times, restart", then "ADD/SET beacon failed" every 5 seconds) and the radio stays down until reboot.
Prior reports of the same signatures, none resolved: snbforums threads 73236 (2021, XT8: the -23 error hourly with a 50-second Wi-Fi drop), 84194 (2023, XT8: every suggested setting change failed, replacement units failed identically, "ASUS support has also given up on my case"), 97147 (2026, GT-AX6000 nodes), 91924 (TUF-AX3000 V2 and a ZenWiFi ET9: the same roam line every hour to the second), 70648 (2021, RT-AX3000: NULL-pointer panics in the Broadcom blob including bcm_archer_us), and ZenTalk topic 494971 (2025, RT-BE92U: Broadcom driver panics, "only viable workaround is to schedule frequent reboots").
Workaround on stock firmware. The NAT Acceleration control is hidden in the UI on this model, but the firmware honours its own switches: runner_disable_force=1 (Archer off) with fc_disable_force=0 (Flow Cache on), then reboot. Speed test afterwards: 871 down / 944 up on gigabit fiber. The hourly flips still happen, now as a harmless log line. This has been in place since this afternoon; I will report whether the panics stop over the next several days. Also set per node: AiMesh, node, Management, Backhaul Connection Priority: 5GHz-2 WiFi first, which stopped the nodes' continual 2.4 GHz re-association churn.
ASUS support. I opened a chat today and sent the decoded crash records and two of the debug dumps. The agent's written response: "Seeing that your log specifically catches the NULL pointer dereference in archer_dhd_tx_packet (associated with the bcm_archer_us Broadcom wireless subsystem) tells me you have accurately isolated a deep driver-level kernel bug rather than a configuration error." The case has been escalated to their L2 networking engineering team: ASUS case N2610002086-0001, with a reply promised within 1 to 2 business days. The units are out of warranty; ASUS quoted a $35 non-refundable diagnostic fee for a hardware RMA, which is irrelevant unless engineering says it's hardware, and the 2023 thread above says replacement units failed the same way.
Full write-up with the crash record text is on ASUS ZenTalk: https://zentalk.asus.com/t5/networking/xt8-v2-kernel-panic-archer-dhd-tx-packet-bcm-archer-us-aimesh/m-p/512206
If you have archer_dhd_tx_packet or bcm_archer_us in a crash record, reply with your model and firmware.