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

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

Hostseitige Linux-mac80211-Treibererweiterung und Bugfix-Patchset für den Mainline-rtw89-WLAN-Treiber (Realtek RTL8852AE PCIe [10ec:8852], mit architektonischer Kompatibilität für RTL8852BE und RTL8852CE).

Ermöglicht vollständige IEEE-802.11-NL80211_IFTYPE_MONITOR-Radiotap-Paketerfassung für Wireshark / tcpdump, vollständige airmon-ng / airodump-ng-Kompatibilität sowie standardskonforme Raw-Frame-Übertragung / Packet Injection (IEEE80211_TX_CTL_INJECTED / aireplay-ng).

Funktioniert zu 100 % auf der Host-Kernel-Treiberseite unter Verwendung unveränderter, kryptografisch signierter rtw89-Firmware-Images aus dem offiziellen linux-firmware-Distributionspaket. Kein Reverse-Patching oder Binärmodifikation der Firmware erforderlich.

---

Praxisnaher Proof of Concept (Kali-Linux-Verifikation)

[!TIP] Zu 100 % funktionsfähig unter Kali Linux: Die folgenden Screenshots zeigen die tatsächliche Ausführung auf einem Live-System mit Kali Linux (Kernel 7.1.5+kali-amd64) und einem Realtek RTL8852AE PCIe Wireless Adapter ([10ec:8852]).

1. IEEE-802.11-Radiotap-Erfassung in Wireshark

Live-802.11-Paketerfassung mit vollständigem Promiscuous-Empfang von Management- (Beacons, Probe Requests/Responses), Control- (ACK, Block Ack, RTS, CTS) und Data-Frames über verschiedene BSSIDs hinweg, mit vollständigen RSSI-Metadaten pro Antenne (-18 dBm, -24 dBm) und Kanal frequenz (2462 MHz / CH 11):

2. Hochleistungs-Benchmark für Packet Injection (aireplay-ng -9)

Erfolgreicher IEEE-802.11-Diagnose-Packet-Injection-Test mit 100 % Frame-Zustellung (30/30 Probe Requests mit Ping-Zeiten unter 2 ms bestätigt) gegenüber aktiven APs, verifiziert durch verify_monitor_diag.py und aireplay-ng:

---

Warum RTL8852AE Monitor-Modus & Injection Upstream scheiterte

Tausende Linux- und Kali-Linux-Nutzer berichten, dass moderne Wi-Fi-6-Laptops mit Realtek-RTL8852AE-Adaptern beim Ausführen von airmon-ng oder beim Versuch der Packet Injection fehlschlagen. Häufige Upstream-Probleme in lwfinger/rtw89 und Mainline-Linux-Kerneln:

• „Unterstützt RTL8852AE den Monitor-Modus oder Packet Injection?"
• „Firmware blockiert TX auf Monitor-vif"
• „airodump-ng sieht keine Beacons oder Control-Frames"
• „Kernel-Crash oder NULL-Pointer-Dereferenzierung beim Injizieren von 802.11-Frames"

Durch detailliertes Reverse Engineering der Hardware-Register und Analyse des rtw89-RISC-V-Firmware-Kommunikationsprotokolls löst dieses Projekt die vier Grundursachen vollständig im Host-Kernel-Treiber:

1. Hardware-MAC-RX-Subtyp- & Adress-CAM-Filterung (reg.h / mac.c)
   • Problem: Band-0-MAC-Register verwerfen 802.11-Control-Frames (ACK, RTS, CTS, BlockAck) und Cross-BSS-Unicast-Data-Frames, die nicht mit dem Hardware-ADDR_CAM übereinstimmen. Hardware-Scan-Offload kann zudem den Band-0-RX-Paketfilter pausiert lassen (R_AX_PKT_CTRL_B0_PAUSE).
   • Fix: rtw89_mon_program_mac_rx_tx_regs() konfiguriert R_AX_RX_FLTR_OPT (0xCE20), R_AX_CTRL_FLTR (0xCE24), R_AX_MGNT_FLTR (0xCE28) und R_AX_DATA_FLTR (0xCE2C) mit der Promiscuous-Maske 0x55555555 neu, berücksichtigt FIF_FCSFAIL und stellt den Filterzustand bei Kanalwechseln (rtw89_set_channel()) automatisch wieder her.
2. Kernel-Panic bei NULL-vif beim Monitor-TX (mac80211.c & core.c)
   • Problem: In rtw89_ops_tx() und rtw89_core_tx_write() wurde das Makro vif_to_rtwvif(vif) in lokalen Variablendeklarationen bedingungslos ausgewertet, bevor geprüft wurde, ob info->control.vif NULL ist (was dem Standardverhalten für mac80211-Radiotap-Injection entspricht).
   • Fix: rtw89_mon_resolve_tx_vif() löst das aktive Monitor-VIF vor der Dereferenzierung auf und verhindert so Kernel-Abstürze.
3. Ungültiger Rate-Index & fehlendes TXWD_INFO in rtw89_core_tx_update_injection() (core.c)
   • Problem: Wenn Radiotap-Header keine explizite Bitrate angeben, übergibt mac80211 das vorzeichenbehaftete s8 rates[0].idx = -1. Upstream castete dies zu u8 (255), wodurch ein ungültiger Hardware-Rate-Index geschrieben wurde, und ließ desc_info->en_wd_info bei Nicht-Management-Frames aus.
   • Fix: rtw89_mon_fixup_tx_desc() wählt eine gültige Hardware-Rate (standardmäßig RTW89_HW_RATE_OFDM6 / 6,0 Mbps), setzt en_wd_info / use_rate / dis_data_fb und begrenzt Hardware-Retries (tx_cnt_lmt = 1), wenn IEEE80211_TX_CTL_NO_ACK gesetzt ist.
4. Nicht initialisierter Monitor-mac_id-Scheduler-Kontext & Sleep-Lock (fw.h)
   • Problem: Eigenständige Monitor-Interfaces (IEEE80211_HW_WANT_MONITOR_VIF) weisen eine mac_id und einen Hardware-Port zu, konfigurieren jedoch niemals die CMAC/DMAC-Tabellen oder registrieren den Link beim Firmware-Scheduler. Die Firmware hält die TX-Queue pausiert.
   • Fix: rtw89_mon_add_vif_post() programmiert h2c_default_cmac_tbl / h2c_default_dmac_tbl, registriert die Rolle über rtw89_fw_h2c_join_info() mit RTW89_SELF_ROLE_AP und RTW89_NET_TYPE_NO_LINK (umgeht die Beacon-Timeout-Prüfungen der Client-Rolle, während Beacon-TX deaktiviert bleibt), hebt die Pausierung der MACID über rtw89_fw_h2c_macid_pause() auf und löscht R_AX_MACID_SLEEP_0 (0xC2C0).

---

Kernel- & Distributionskompatibilität

Der AST-/Klammer-bewusste Patcher (scripts/patch_rtw89.py) inspiziert core.h und mac80211.c zur Build-Zeit und passt sich automatisch an beide Upstream-Treibergenerationen an:

Treibergeneration	Kernel-Versionen	Locking- & VIF-Architektur	Distributionsbeispiele
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-Struktur