wifi: rtw89: 8852AE: zero SMA in addr CAM for virtual monitor vif, and ~200 ms delay before first TX attempt of injected unicast

wifi: rtw89: 8852AE: zero SMA in addr CAM for virtual monitor vif, and ~200 ms delay before first TX attempt of injected unicast

[Adilson]

Hi Ping-Ke,

I am working on Linux interoperability with Apple's AirDrop, using a
userspace AWDL implementation (OWL, from TU Darmstadt's SEEMOO Lab) on
top of a monitor interface with radiotap injection. While testing on an
RTL8852AE I found two issues in the monitor/injection path. The first
has a cause and an experimental fix; the second is a question about
firmware behavior.

With the fix for (1) and a workaround for (2), a complete transfer of a
small test file from a current macOS to this card now succeeds
(discovery, request and upload, with the received file identical to
the original). So the fix seems useful in practice, and the remaining
delay is the main obstacle to a clean implementation.

Setup:
- RTL8852AE, PCIe 10ec:8852, firmware 0.13.36.2 (52acc807)
- kernel 7.2.8; the rtw89 directory is identical to upstream v7.2.8
- passive monitor interface (rtw89 does not support active monitor),
  injected data frames at a fixed rate of 12 Mb/s via radiotap
- peer: a MacBook, on channel 149

I checked rtw-next and wireless-next as of October 1, 2026 and found no
changes touching these paths.

1) The virtual monitor vif gets SMA 00:00:00:00:00:00 in the addr CAM

I understand that a passive monitor interface is not expected to ACK.
The problem is that, when injecting, the peer then retransmits every
frame it sends back to us: in a 40-packet ping test, the peer sent 15
original frames and 89 retries. The concrete cause seems to be the
address of the virtual monitor vif.

rtw89 sets WANT_MONITOR_VIF. Without active monitor, mac80211 does not
pass the monitor netdev to the driver and creates the virtual monitor
vif in ieee80211_add_virtual_monitor(). That vif is allocated zeroed and
reaches the driver without an address. rtw89 copies it into
rtwvif->mac_addr and rtwvif_link->mac_addr, and rtw89_mac_add_vif()
then programs the addr CAM (rtw89_mac_vif_init() -> rtw89_fw_h2c_cam()
-> rtw89_cam_fill_addr_cam_info()) with SMA = 00:00:00:00:00:00, and
TMA = the zero BSSID. A debugfs dump of the addr CAM (mac_mem_dump)
confirms it: entry 0 is valid, with both SMA and TMA zero.

For context, mac80211 marks passive monitor interfaces with
vif->addr_valid = false, not with a zero address; the zero address comes
only from the internal virtual monitor vif, which is what rtw89 receives
with WANT_MONITOR_VIF. So the question is rather what rtw89 should
program into the addr CAM for that vif when frames are injected through
it.

Experimental fix: when the vif is a monitor vif and its address is all
zeros, use the permanent address of the device before the CAM is
programmed (behind a module parameter, default off, in my test build).
With it, the addr CAM entry carries the real address, and in the same
40-ping test the peer's retries dropped from 89 to 1, with no
duplicates in the ping. So in this mode the hardware does ACK unicast
frames addressed to it once the SMA is set. Managed mode is unaffected:
the change only acts on a monitor vif with a zero address, and since
ieee80211_open() rejects any netdev without a valid address, only the
virtual monitor vif (which has no netdev) can reach the driver that
way.

Would a patch along these lines be acceptable upstream? And would it
be enough for, or a step towards, advertising ACTIVE_MONITOR on these
chips? The fix could also key on addr_valid instead of testing for a
zero address, if you prefer.

2) Injected unicast waits ~200 ms before the first TX attempt

Injected unicast data frames reach the peer much later than injected
multicast. Your series from November 2025 (rate/bw/GI for injected
packets) is included in this kernel; it does not seem to touch this
wait. What I measured:

- mac80211 to driver: 5 to 19 us (bpftrace on the TX path).
- With the default retry settings, the peer's ACK (seen in an
  over-the-air capture) arrives 150 to 469 ms after the driver hands the
  frame to the hardware.
- TX status: every unicast frame without a peer ACK fails with status
  1 (retry limit exceeded); none with status 2 or 3.
- With a per-frame retry limit in the TX descriptor
  (DATA_TXCNT_LMT_SEL, the same field the driver already uses for USB,
  set here by a second experimental change, since on PCIe the driver
  does not write it), the limit is honored. Answered pings out of 40,
  before the fix in (1): limit 1: 0, limit 2: 3, limit 4: 4,
  default: 15. With a limit of 1, the failure status arrives 148 ms or
  more after the handoff; subtracting the ~8.5 ms status latency, the
  single attempt happens 140 to 445 ms after the handoff (32 of 40
  frames between 160 and 220 ms). So the wait happens before the first
  attempt, not between retries.
- Injected multicast frames usually get their TX status within 2.7 to
  9.6 ms; a few outliers took up to ~200 ms.
- The wait does not line up with a 102.4 ms beacon grid, and behaves
  like a delay counted from the handoff. (Our userspace stack always
  hands frames off at the same phase of its own slot schedule, so I
  cannot fully separate the two.)
- MACID_SLEEP_0 and SS_MACID_PAUSE_0 read zero in 10,466 samples each,
  taken every ~6 ms during traffic with the stock driver, so macid 0
  does not seem to be sleeping or paused.
- Power save cannot be turned off on the monitor interface: "iw dev
  wlan0 set power_save off" returns -EOPNOTSUPP (-95), so I could not
  rule it out from userspace.
- Setting SPE_RPT on these frames did not produce any C2H TX RPT on
  PCIe: with RTW89_DBG_TXRX enabled, the debug message in
  rtw89_mac_c2h_tx_rpt(), which is printed before the skb lookup, never
  appeared.
- The fix in (1) does not change the wait.

Workaround: since the wait behaves like a delay from the handoff, our
userspace stack now hands unicast frames to the driver earlier than the
peer's availability window, with a descriptor retry limit of 4 (set by
the same experimental driver change). Calibrating the lead time, with
the fix for (1) in place: 140 ms gave 33/40 answered pings, 180 ms gave
28/40 and 220 ms gave 13/40, against 3/40 with the same settings and no
early handoff. So the wait is stable enough to be compensated. With 140
ms, the transfer above completed. It works, but it is tuned to this
card and firmware.

My guesses, untested: injected unicast goes out through macid 0, with no
station context. The driver already sets a fixed rate for these frames
(use_rate and dis_data_fb in rtw89_core_tx_update_injection()) and does
not request aggregation (no IEEE80211_TX_CTL_AMPDU), so does the
firmware hold or aggregate unicast on its own when the macid has no
station entry? Other possibilities: a slow path for unicast to an
address with no addr CAM or station entry, or the "no link" role of the
monitor port making it defer unicast.

What is the firmware waiting for in this case? Is there a descriptor
field, an H2C command, or a CAM or station setup that makes injected
unicast go out immediately, as multicast does?
Would the diag_mac or diag_bb debugfs entries from your series help to
see what the firmware is waiting for?

Disclosure: I did this investigation with the help of an AI assistant
(Claude, by Anthropic), which I used to read the driver code, write the
measurement scripts and the experimental patches, and draft this
message. All measurements were run by me on my own hardware, and I
have reviewed every claim above and can answer questions about it.

I can share the measurement scripts, captures (with personal data
removed) and the experimental patches.

Thanks,
Adilson

RE: wifi: rtw89: 8852AE: zero SMA in addr CAM for virtual monitor vif, and ~200 ms delay before first TX attempt of injected unicast

[Ping-Ke Shih]

Adilson <aoleandro@proton.me> wrote:
> Would a patch along these lines be acceptable upstream? And would it
> be enough for, or a step towards, advertising ACTIVE_MONITOR on these
> chips? The fix could also key on addr_valid instead of testing for a
> zero address, if you prefer.

I think advertising NL80211_FEATURE_ACTIVE_MONITOR to support active
monitor is better way.

> 
> 2) Injected unicast waits ~200 ms before the first TX attempt
> 
> Injected unicast data frames reach the peer much later than injected
> multicast. Your series from November 2025 (rate/bw/GI for injected
> packets) is included in this kernel; it does not seem to touch this
> wait.

The main differences from unicast and multicast frames are:
1. hw queue 
2. with different queue. It relies on EDCA parameter.
3. rate

You can adjust unicast frame to TX with the same desc_info attributes
as multicast frame to see if anything improved. 

> Disclosure: I did this investigation with the help of an AI assistant
> (Claude, by Anthropic), which I used to read the driver code, write the
> measurement scripts and the experimental patches, and draft this
> message. All measurements were run by me on my own hardware, and I
> have reviewed every claim above and can answer questions about it.

Understood. Currently I assume long long article is generated by LLM.
I knew that becomes common, but it is actual heavy load to me to
read a lot. But still noted your disclosure.