RTL8821AU: revisit 'RX silent' conclusion from PR #30 (new evidence: works)

[josephnef]

What changed

The full-matrix regression rig (#34) showed evidence that the RTL8821AU TX and RX paths brought up in #30 — both flagged as gaps when that PR merged — are actually functional under at least some conditions.

Cell	Result
devourer-TX 8821 → kernel-RX 8814	4341 hits / 4500 TX (~96% delivery)
kernel-TX 8814 → devourer-RX 8821	200 hits / 281 TX (~71% delivery)

The original PR #30 concluded RX was silent based on a single test session against an actively-associated 5GHz AP. The regression rig instead injects a known-SA beacon from a peer adapter and clearly sees devourer's 8821 RX moving frames. Comment with details: #30 (comment)

Specific things to pin down

1. Reproduce the original "silent" condition. PR RTL8821AU: partial bring-up — chip init OK, RX silent — WIP #30's test environment was: macOS host, T2U Plus on a USB hub, channel 100 with the host Mac actively associated to KArt2/WPA3-AX. The rig run that contradicted this was: Linux + libvirt VM with aircrack-ng/88XXau as peer, channel 100, no live AP traffic on the channel. Two things differ: the OS (macOS vs Linux) and the traffic profile (live AP vs injected beacon). One or both might be the actual gating factor. Worth a focused retest on macOS with a peer injecting the canonical SA.

2. The 8821→8812 asymmetry. In the full matrix, devourer-TX 8821 → kernel-RX 8814 hit cleanly (4341 hits) but the same TX → kernel-RX 8812 in the same session showed 0 hits. Possibly chip-state degradation from passthrough cycles by that cell, possibly 8812 kernel-RX in VM was stale, possibly something 8821-specific in the TX-to-8812-RX direction. Single-pair --tx-pid 0x0120 --rx-pid 0x8812 retest would isolate.

3. Channel coverage. The matrix run was only on channel 100. Worth running across 2.4G (channel 6) and other 5G channels (36, 149) to see if any channel shows the original "silent" behaviour.

4. EFUSE / RFE-type variance. The T2U Plus on this rig reads rfe_type=0 from EFUSE — same as RTL8821AU: partial bring-up — chip init OK, RX silent — WIP #30 observed. So that's not the differentiator. But other 8821AU SKUs (0bda:0820/0821/0823, Edimax 7392:a811, etc.) may have different EFUSE settings that affect RX.

What's not claimed

• 8821AU bring-up is not complete — the matrix only confirmed end-to-end on two specific cells. Need broader validation before claiming production-ready.
• The 200/281 hit rate on RX is decent but not as clean as the kernel-only baseline cells (88-271 hits). May indicate marginal RX or just session variance.

Suggested next steps

• Retest the original PR RTL8821AU: partial bring-up — chip init OK, RX silent — WIP #30 scenario (macOS + peer-injected canonical SA) to isolate macOS-vs-Linux or the live-AP traffic factor
• Run tests/regress.py --full-matrix on a different rig with different ambient RF to check for reproducibility
• If the 8821 RX path proves solid across conditions, update README's adapter support matrix to add RTL8821AU as a working chipset

cc @RomanLut whose #22 supplied the HAL data that ended up working.