RE: [PATCH RFC net-next 0/2] wifi: rtw89: fix monitor mode RX filtering and enable raw packet injection

[Ping-Ke Shih <pkshih@realtek.com>]

ph4ntom-rev <owner@ph4ntom-rev.uz> wrote:
> Hi Ping-Ke, Kalle, and linux-wireless maintainers,
> 
> This RFC patchset addresses long-standing limitations in rtw89 regarding
> IEEE 802.11 monitor interfaces (NL80211_IFTYPE_MONITOR) and raw frame
> transmission / diagnostic injection (IEEE80211_TX_CTL_INJECTED) on Realtek
> 802.11ax PCIe hardware (specifically verified on RTL8852AE [10ec:8852]).

I can only see this cover letter. Did I miss something?

https://lore.kernel.org/linux-wireless/1a196d6dfbc.35537d221913104450.3720060455831933789@zoho.com/

> 
> While rtw89 includes scaffolding for monitor mode (pure_monitor_mode_vif
> and rtw89_core_tx_update_injection), standalone monitor operation hits
> four distinct host-driver obstacles rather than a firmware limitation:
> 
> 1. MAC Promiscuous RX Drops:
>    Band 0 MAC registers (R_AX_RX_FLTR_OPT 0xCE20, R_AX_CTRL_FLTR 0xCE24,
>    and R_AX_DATA_FLTR 0xCE2C) default to filtering out Control frames (ACK,
>    RTS, CTS, BlockAck) and non-matching BSSID Data before reaching host
>    DMA rings. Setting promiscuous mask 0x55555555 and syncing CRC32 drops
>    with FIF_FCSFAIL unlocks all 16 IEEE 802.11 Control and Management
>    subtypes across channel switches.

The commit a371139d8be9 ("wifi: rtw89: SNIFFER_MODE bit along IEEE80211_CONF_MONITOR")
added a missing bit B_AX_SNIFFER_MODE, which I suppose it can capture
packets promiscuously. Can you try it?

> 
> 2. NULL vif Dereference on Monitor TX:
>    In rtw89_ops_tx() and rtw89_core_tx_write(), vif_to_rtwvif(vif) is
>    evaluated unconditionally in local declarations before checking whether
>    info->control.vif is NULL. Injected Radiotap frames from mac80211 pass
>    a NULL control.vif, triggering an immediate kernel oops.

Please add a guard. But I have never encountered the oops. Could you
share the steps?

> 
> 3. Injection Descriptor Rate Handling:
>    When Radiotap headers omit an explicit bitrate, mac80211 sets
>    rates[0].idx = -1. In rtw89_core_tx_update_injection(), casting this to
>    u8 yields an invalid rate index 255 and leaves desc_info->en_wd_info
>    unset for non-management frames. We map negative indices to a valid
>    OFDM 6.0 Mbps fallback (RTW89_HW_RATE_OFDM6), enable hardware rate
>    override (use_rate, dis_data_fb), and bound retries (tx_cnt_lmt = 1)
>    when IEEE80211_TX_CTL_NO_ACK is set.

OK.

> 
> 4. Firmware Scheduler MACID Stalling:
>    When mac80211 allocates a standalone monitor VIF, a mac_id is assigned,
>    but default CMAC/DMAC tables are never populated and no H2C join is
>    issued, leaving the MACID context paused in the firmware scheduler.
>    Attempting to join as RTW89_SELF_ROLE_CLIENT triggers firmware 5-second
>    beacon-loss timeouts. However, registering a non-associated AP context
>    (RTW89_SELF_ROLE_AP with RTW89_NET_TYPE_NO_LINK) initializes the MACID
>    queues without generating AP beacons or tracking client beacons. Clearing
>    R_AX_MACID_SLEEP_0 (0xC2C0) and sending rtw89_fw_h2c_macid_pause(..., false)
>    cleanly unpauses hardware transmit queues.

I'd check this in detail with RFC patch.