Realtek RTL8852AE / rtw89 Monitor Mode & Packet Injection (Raw TX) Patch

English | Русская документация | Architecture Reference

Host-side Linux mac80211 driver extension and bugfix patchset for the mainline rtw89 wireless driver (Realtek RTL8852AE PCIe [10ec:8852], with architectural compatibility for RTL8852BE and RTL8852CE).

Enables full IEEE 802.11 NL80211_IFTYPE_MONITOR Radiotap packet capture for Wireshark / tcpdump, full airmon-ng / airodump-ng compatibility, and standards-compliant raw frame transmission / packet injection (IEEE80211_TX_CTL_INJECTED / aireplay-ng).

Works 100% on the host kernel driver side using unmodified, cryptographically signed rtw89 firmware images from the official distribution linux-firmware package. No firmware reverse-patching or binary modification required.

---

Real-World Proof of Concept (Kali Linux Verification)

[!TIP] 100% Functional in Kali Linux: The screenshots below show actual execution on a live system running Kali Linux (Kernel 7.1.5+kali-amd64) with a Realtek RTL8852AE PCIe Wireless Adapter ([10ec:8852]).

1. IEEE 802.11 Radiotap Capture in Wireshark

Live 802.11 packet capture showing full promiscuous reception of Management (Beacons, Probe Requests/Responses), Control (ACK, Block Ack, RTS, CTS), and Data frames across BSSIDs, with complete per-antenna RSSI (-18 dBm, -24 dBm) and channel frequency (2462 MHz / CH 11) metadata:

2. High-Performance Packet Injection Benchmark (aireplay-ng -9)

Successful IEEE 802.11 diagnostic packet injection test showing 100% frame delivery (30/30 probe requests acknowledged with sub-2ms ping times) against active APs, confirmed by verify_monitor_diag.py and aireplay-ng:

---

Why RTL8852AE Failed Monitor Mode & Injection Upstream

Thousands of Linux and Kali Linux users report that modern Wi-Fi 6 laptops with Realtek RTL8852AE adapters fail when running airmon-ng or attempting packet injection. Common upstream issues in lwfinger/rtw89 and mainline Linux kernels:

• "Does RTL8852AE support monitor mode or packet injection?"
• "Firmware blocks TX on monitor vif"
• "airodump-ng sees no beacons or control frames"
• "Kernel crash or NULL pointer dereference when injecting 802.11 frames"

Through detailed hardware register reverse engineering and analysis of the rtw89 RISC-V firmware communication protocol, this project resolves the four root causes entirely in the host kernel driver:

1. Hardware MAC RX Subtype & Address CAM Filtering (reg.h / mac.c)
   • Problem: Band 0 MAC registers drop 802.11 Control frames (ACK, RTS, CTS, BlockAck) and cross-BSS unicast Data frames that do not match the hardware ADDR_CAM. Hardware scan offload can also leave the Band 0 RX packet filter paused (R_AX_PKT_CTRL_B0_PAUSE).
   • Fix: rtw89_mon_program_mac_rx_tx_regs() reconfigures R_AX_RX_FLTR_OPT (0xCE20), R_AX_CTRL_FLTR (0xCE24), R_AX_MGNT_FLTR (0xCE28), and R_AX_DATA_FLTR (0xCE2C) with promiscuous mask 0x55555555, honors FIF_FCSFAIL, and automatically re-asserts filter state across channel switches (rtw89_set_channel()).
2. NULL vif Kernel Panic on Monitor TX (mac80211.c & core.c)
   • Problem: In rtw89_ops_tx() and rtw89_core_tx_write(), the macro vif_to_rtwvif(vif) was evaluated unconditionally in local variable declarations before checking whether info->control.vif is NULL (which is standard behavior for mac80211 Radiotap injection).
   • Fix: rtw89_mon_resolve_tx_vif() resolves the active monitor VIF before dereference, preventing kernel crashes.
3. Invalid Rate Index & Missing TXWD_INFO in rtw89_core_tx_update_injection() (core.c)
   • Problem: When Radiotap headers omit an explicit bitrate, mac80211 passes signed s8 rates[0].idx = -1. Upstream cast this to u8 (255), writing an invalid hardware rate index, and omitted desc_info->en_wd_info on non-management frames.
   • Fix: rtw89_mon_fixup_tx_desc() selects a valid hardware rate (defaulting to RTW89_HW_RATE_OFDM6 / 6.0 Mbps), asserts en_wd_info / use_rate / dis_data_fb, and bounds hardware retries (tx_cnt_lmt = 1) when IEEE80211_TX_CTL_NO_ACK is set.
4. Uninitialized Monitor mac_id Scheduler Context & Sleep Lock (fw.h)
   • Problem: Standalone monitor interfaces (IEEE80211_HW_WANT_MONITOR_VIF) allocate a mac_id and hardware port, but never configure CMAC/DMAC tables or register the link with the firmware scheduler. The firmware keeps the TX queue paused.
   • Fix: rtw89_mon_add_vif_post() programs h2c_default_cmac_tbl / h2c_default_dmac_tbl, registers the role via rtw89_fw_h2c_join_info() using RTW89_SELF_ROLE_AP with RTW89_NET_TYPE_NO_LINK (bypassing client-role beacon timeout checks while leaving beacon TX disabled), unpauses the MACID via rtw89_fw_h2c_macid_pause(), and clears R_AX_MACID_SLEEP_0 (0xC2C0).

---

Kernel & Distro Compatibility

The AST/brace-aware patcher (scripts/patch_rtw89.py) inspects core.h and mac80211.c at build time and automatically adapts to both upstream driver generations:

Driver Generation	Kernel Versions	Locking & VIF Architecture	Distro Examples
API Gen 1	Linux 6.1 – 6.10	struct rtw89_vif, rtwdev->mutex	Debian 12 (Bookworm), Ubuntu 22.04 LTS (HWE)
API Gen 2	Linux 6.11 – 7.x+ & lwfinger/rtw89	MLO struct rtw89_vif_link, pure_monitor_mode_vif, wiphy_lock	Kali Linux 2024+, Ubuntu 24.04+, Arch Linux, Fedora

---

Repository Structure