RTL8821AU: trace-derived register-init parity (partial — does not fix RX asymmetry)#37
Merged
Merged
Conversation
Brings devourer's CHIP_8821 init register-write set into parity with aircrack-ng/88XXau's post-fwdl monitor-mode bring-up, based on a usbmon-trace diff of both drivers running on the same T2U Plus (2357:0120). Adds 13 missing post-fwdl writes, 17 BB/AGC value overrides, MAC-address programming, and corrects the earlier REG_USB_HRPWM=0x84 to 0x00 (the LPS-leave wake was a wrong guess — kernel writes 0x00 here during init). WHAT THIS DOES NOT FIX ====================== The 8812-peer-asymmetry symptom reported in #30 / surfaced in #34's full matrix (devourer-RX 8821 catches kernel-TX 8814 at ~200 hits/cell but gets 0 hits from kernel-TX 8812 — verified asymmetric across single-pair retests, same chip, same channel) is **NOT fixed** by this PR. The "what's different at the register level" patches don't cross the threshold. Most likely reason: aircrack-ng's runtime phydm continually adjusts AGC / RX-gain based on observed signal quality. This PR snapshots kernel's post-init register values — but the chip needs the ACTIVE feedback loop to maintain them during RX. Without phydm, the chip drifts back toward defaults that work for higher-SNR peers (8814) but not lower-SNR ones (8812). So this PR is partial. The follow-up paths are: 1. Port phydm runtime — substantial code import from aircrack-ng/hal/phydm/rtl8821a/. Days of work. Cleanest fix. 2. Loop-replay — capture kernel's full register sequence over a 5-second RX window (not just init) and replay periodically. Hacky but cheap. 3. Accept devourer-RX 8821 as "works for some peers, not others" until phydm is in. Document in adapter matrix. WHAT THIS DOES ============== Even though it doesn't fix the RX gap, this PR is worth landing because it brings the chip's *baseline* register state into kernel parity. That: - Removes 1 register's worth of wrong guesses (REG_USB_HRPWM) - Adds programmed MAC address (kernel always does this; some chip RX-path logic gates on MACID being non-zero even in monitor mode) - Adds REG_AUTO_LLT / REG_TX_PTCL_CTRL / NAV-related / BB-high-addr writes the kernel does — these are not optional from the chip's point of view, just under-tested in devourer until now - Forces 17 BB/AGC values to kernel's observed runtime state, which may help future phydm-runtime work start from a sane baseline - Folds in `--rate` arg for tests/inject_beacon.py (added during rate-decode hypothesis testing — useful diagnostic knob to keep) USBMON METHODOLOGY (for future trace-diff work) ================================================ Capture kernel side (in VM with aircrack-ng/88XXau): # On VM: sudo modprobe usbmon sudo bash -c "cat /sys/kernel/debug/usb/usbmon/0u > /tmp/trace_kernel.txt &" # Then attach DUT via virsh, bring up monitor mode, stop usbmon Capture devourer side (on host): sudo bash -c "timeout 20 cat /sys/kernel/debug/usb/usbmon/Nu > /tmp/trace_dvr.txt" & sudo ./build/WiFiDriverDemo ... Filter Realtek control writes: grep -E "S Co:.* 40 05 " trace.txt | awk '{print $8, $13}' Important encoding gotcha: usbmon shows wire bytes in transmission order (= LE u32's byte sequence). To write the same value via rtw_write32 on a LE host, the u32 value is read-as-LE — so the trace text "82824001" represents u32 0x01408282 (NOT 0x82824001). This bit me — the first attempt at the post-fwdl writes used wrong-endian values and naturally had no effect. VALIDATION ========== Single-pair test on trainer-arch + VM, channel 100: kernel-TX 8812 → kernel-RX 8821 (baseline) 283 hits ✓ devourer-TX 8821 → kernel-RX 8814 4663 hits ✓ (8821 TX path solid) kernel-TX 8812 → devourer-RX 8821 0 hits ✗ (the asymmetry — unresolved) devourer-TX 8821 → devourer-RX 8812 0 hits ✗ (same — TX 8821 doesn't reach 8812 RX in either driver combo) Other chips (8812, 8814) untouched by this PR — only CHIP_8821 dispatch paths modified. Refs #30 (initial 8821 port), #34 (full matrix that surfaced the asymmetry). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Status: partial — register-state parity with kernel, but doesn't fix #30's 8812-peer asymmetry
Brings devourer's
CHIP_8821init register-write set into parity withaircrack-ng/88XXau's post-fwdl monitor-mode bring-up, based on a usbmon-trace diff. Adds 13 missing post-fwdl writes, 17 BB/AGC value overrides, MAC-address programming, and corrects an earlier wrong guess at REG_USB_HRPWM.This does NOT fix the asymmetry (
devourer-RX 8821catches kernel-TX 8814 frames but drops kernel-TX 8812 frames at 0/280) that #34 surfaced. The cheap "what's different at the register level" patches don't cross the threshold. Filing anyway because it's honest progress + brings the chip's baseline state into kernel parity, which the next fix attempt can build on.What this changes
HalModule.cpp::rtl8812au_hal_initHalModule.cpp::rtl8812au_hal_initHalModule.cpp::rtl8812au_hal_initHalModule.cpp::rtl8812au_hal_inittests/inject_beacon.py--rateCLI arg (added during rate-decode hypothesis testing; useful diagnostic knob)8812AU + 8814AU paths untouched.
Why the RX gap probably remains
Aircrack-ng runs phydm — a runtime feedback loop that continually adjusts AGC / RX-gain based on observed signal quality. This PR sets the chip's static values to match kernel's post-init snapshot, but the chip needs the active loop to maintain them during RX. Without phydm running, the chip drifts back toward defaults that work for higher-SNR peers (8814) but not for 8812.
Three follow-up paths to actually fix the asymmetry:
aircrack-ng/hal/phydm/rtl8821a/). Days of work, cleanest fix.usbmon methodology (for future trace-diff work)
Capture kernel side (in VM with
aircrack-ng/88XXau):Capture devourer side (on host):
Filter Realtek control writes:
Important encoding gotcha: usbmon shows wire bytes in transmission order (= LE u32's byte sequence). To write the same value via
rtw_write32on a LE host, the u32 value is read-as-LE — so the trace text82824001represents u320x01408282(NOT0x82824001). The first attempt at the post-fwdl writes in this PR used wrong-endian values and naturally had no effect; the fix was to byte-pair-reverse them.Validation
Single-pair test on the trainer rig (Arch host, Ubuntu 22.04 VM with aircrack-ng/88XXau, channel 100, 10s):
Other chips untouched.
Test plan
Refs #30 (initial 8821 port), #34 (full matrix that surfaced the asymmetry).
🤖 Generated with Claude Code