RTL8814AU: devourer-TX produces 0 on-air frames despite 100% URB completion (post-#36)

[josephnef]

Symptom

After PR #49 fixed the bulk-OUT FIFO wedge (#36), devourer-TX on RTL8814AU (0bda:8813) achieves 100% URB submission + completion success at the libusb / kernel level — but produces 0 frames on-air as observed by an AR9271 peer sniffer on the same channel filtering for the canonical SA 57:42:75:05:d6:00.

Concretely on master after PR #49:

# devourer-TX 12s on 8814AU, ch 6
WiFiDriverTxDemo:
  submits: 2203
  complete: 2203   ← chip ACK'd every URB at the USB layer
  fail:     0

# Concurrent AR9271 sniffer:
  canonical-SA frames captured: 0

For RTL8812AU and RTL8821AU under the same harness, on-air capture is ~95% — so this is 8814-specific, not a generic test-rig problem.

Reproduce

# AR9271 (or any chip with vanilla radiotap monitor mode) on the canonical channel
sudo ip link set wlp0s20f0u14 down
sudo iw dev wlp0s20f0u14 set type monitor
sudo ip link set wlp0s20f0u14 up
sudo iw dev wlp0s20f0u14 set channel 6

# Sniffer (background)
sudo tcpdump -i wlp0s20f0u14 -nn -e -s 0 -w /tmp/sniff.pcap \
    'wlan addr2 57:42:75:05:d6:00' &

# devourer-TX on 8814AU
sudo timeout 12 env DEVOURER_PID=0x8813 DEVOURER_CHANNEL=6 \
    ./build/WiFiDriverTxDemo

# Count
sudo tcpdump -nn -r /tmp/sniff.pcap | wc -l   # expect 0

What's known (from 2026-05-26 investigation)

The same chip, when initialized + driven by the in-kernel aircrack-ng/88XXau driver via qemu USB passthrough to devourer-testrig VM and TX'd via tests/inject_beacon.py, produces ~95% on-air capture (e.g. 237/248 frames at −48 dBm). So the chip hardware + RF chain can TX; the gate is in how devourer drives it.

But the gate is not in the libusb-userspace USB driving layer either:

• A direct USBDEVFS_SUBMITURB PoC (no libusb) submitted 500 × 140-byte devourer-format URBs to a chip just initialized by 88XXau in the VM. URBs completed cleanly at the USB layer (500/500 OK, 140 µs mean latency). Sniffer still captured 0 frames on-air.
• A separate sister-project (LKL + libusb HCD + aircrack-ng/88XXau driver verbatim, no devourer code) on the same chip with kernel-driver init also produced 0 on-air despite 2000/2000 USB submits clean.

So the gate is above USB driving and above chip RF init — it's most likely in what's being submitted (TX-descriptor format, rate config, or some chip-state mismatch between kernel-init and devourer-init that affects how the chip interprets bulk-OUT payloads).

Candidate hypotheses to test:

1. TX-descriptor format mismatch. devourer builds a 32-byte TX descriptor wrapping radiotap+frame (src/RtlJaguarDevice.cpp:send_packet). The 8814A's rtl8812a_hal.h macros (SET_TX_DESC_*_8812) are shared with 8812; perhaps 8814 needs a different descriptor variant or different QUEUE_SEL / MACID / RATE_ID bits.
2. Rate / MCS field interpretation. devourer's TX descriptor sets fixed rate:2 (per log); the chip may need a different RATE_ID for 8814 monitor-mode injection.
3. _InitQueueReservedPage_8814AUsb page count + auto-LLT result. Today's bisect noted auto-LLT "completes in 0 polls" (REG_AUTO_LLT_8814A=0x00000010) — could be near-instant kernel-style behavior, or could be the BIT16 trigger never actually setting. Read-back of FIFO page counts after init would confirm.
4. PHY/RF init step missing or out-of-order vs kernel. The kaeru reference RTL8814AU TX gate narrowed to path-A radio table application bisected upstream's 8814au.ko in May 2026 and found phy_RF6052_Config_ParaFile_8814A path-A radio table is essential for on-air TX. devourer ports this table — but the chip-state at table-load time may differ from kernel's.

Acceptance criteria

tests/regress.py --full-matrix --channel 100 --vm-name devourer-testrig --vm-ssh josephnef@... shows ≥ 1 hit in 8814AU devourer-TX cells [2, 4, 6, 8].

Or equivalently: AR9271 sniffer captures ≥ 100 canonical-SA frames during a 12 s WiFiDriverTxDemo run on 8814AU.

Not in scope here

• RTL8814AU: devourer TX degrades to LIBUSB_ERROR_IO after USB passthrough cycles #36 (catastrophic submit-failure mode under USB cycling) — closed by PR RTL8814AU: drop REG_CR=0 post-fwdl write that wedges bulk-OUT #49.
• 8814AU devourer-RX (chip emits frames but devourer doesn't receive them) — separate issue, separate gate, separate ticket.

Diagnostic artifacts from today's session

• tools/usbmon_diff.py — kernel-6.18 text-format usbmon parser + diff. Use to compare libusb-routed vs kernel-routed (via qemu-passthrough) URB streams on the same chip. Useful for any follow-up bisect.
• /tmp/usbdevfs_poc.c — standalone direct-ioctl bulk-OUT PoC. Reusable for "is libusb the bottleneck?" questions.
• The RTL8814AU: devourer TX degrades to LIBUSB_ERROR_IO after USB passthrough cycles #36 amendment comment chain (label correction → libusb refuted → root cause) documents the diagnostic path that landed here.

[josephnef]

Update 2026-05-26 — investigation deepens but root cause still pending

Worked through the four hypothesis paths I'd flagged in the issue body, plus one more. All five tested today, all five negative. But the analysis of the working VM-passthrough capture surfaced a likely direction for next session.

Experiments run today (all → URBs complete cleanly at libusb, but 0 on-air)

#	What was tested	Result
1	TX-descriptor field values: skip OWN/DISQSELSEQ, GID=0x3F, DATA_RETRY_LIMIT=12 (from usbmon byte-diff vs working 88XXau)	2203/2203 URBs OK, 0 on-air
2	Above + HWSEQ_EN=0 (matches aircrack-ng's monitor-injected branch at hal/rtl8814a/usb/rtl8814au_xmit.c:113-116)	861/861 URBs OK, 0 on-air
3	DEVOURER_OOT_REPLAY=1 (replays 4464 kernel boot-time vendor writes)	221/221 URBs OK, 0 on-air
4	DEVOURER_FORCE_TXPWR=1 (forces ~300 per-rate TX-power writes)	3730/3730 URBs OK, 0 on-air
5	Frame body: 45-byte input → 72-byte URB byte-for-byte matching tests/inject_beacon.py's output (PKT_SIZE=32 in descriptor)	856/856 URBs OK, 0 on-air

Devourer's existing post-init chip-state diagnostic surfaces a "ready" chip at every variant — REG_CR=0x06ff (all DMA + MAC enable bits set), TXPAUSE=0, FWHW_TXQ_CTRL has HWSEQ enabled, FIFOPAGE_INFO_1(HPQ)=0x00200020 (32 reserved pages), TXDMA_STATUS=0. Yet bulk-OUT URBs are silently swallowed.

This reconfirms the long-standing finding that the gate is not in: descriptor values, descriptor bytes, post-fwdl vendor-write set, TX-power loop, libusb timing (PR #49 fix landed), or USB layer (USBDEVFS direct-ioctl PoC reproduces the silence).

New context — analysis of working VM-passthrough capture

Working VM-native 88XXau TX session (the one that produced 342 on-air frames from 248 injected) breaks down on the host's bus 4 usbmon as:

706 Bo lines (353 bulk-OUT URBs)
794 Ci lines (397 control-IN reads — chip register polls)
468 Co lines (234 control-OUT writes)
22  Bi lines (11 bulk-IN — RX URBs)

197 of those 234 control-OUT writes happen DURING the TX window (between first and last bulk-OUT timestamps). This is phydm — Realtek's runtime dynamic-mechanism subsystem running RF/BB adjustment loops continuously while TX is active. Pattern observed:

S Co  0x198c = 0x07000000   ← lock the BB-indirect transaction semaphore
S Co  0x08fc = <address>    ← indirect-access port: address
S Co  0x08f8 = <value>      ← indirect-access port: write the value
S Co  0x198c = 0x00000000   ← release the semaphore

Target addresses span all 4 RF paths and the rate-adaptation table:

• BB per-path: 0x0c90/0x0e90/0x1890/0x1a90 (path A/B/C/D), 0x0c1c/0x0e1c/0x181c/0x1a1c
• Rate table: 0x0994/0x0998/0x099c/0x09a0/0x09a4
• Misc: 0x0060 (GPIO_PIN_CTRL_2), 0x08a4, 0x0a2c, 0x0a0a, 0x0b58

Devourer never writes any of these post-init. This is the cleanest "missing-from-devourer" surface that wasn't already in the OOT_REPLAY scope.

Crucial nuance — phydm isn't strictly per-URB

The first 6 bulk-OUT URBs in the working capture (timestamps 2872756065..2872917601, span ~160 ms) flew with zero control writes between them. So the chip emits the first batch of frames without any runtime phydm activity. Phydm kicks in after some idle, likely an AGC retraining timer.

That means a devourer-initialised chip should — in principle — be able to TX without phydm, if its state at "post-init / pre-phydm" matches what 88XXau leaves behind. But it doesn't, even with DEVOURER_OOT_REPLAY=1. So either:

• (a) OOT_REPLAY's vendor-control-only trace misses something the kernel does between fwdl-complete and first-TX. Specifically: writes through the BB-indirect-access port (0x08fc/0x08f8) wouldn't show up as direct-address writes — they'd appear as control-OUT to 0x08f8/0x08fc themselves. The original trace capture window may have missed these.
• (b) The kernel does H2C (Host-to-Chip) mailbox commands at init time via REG_HMETF0 / REG_HMEBOX_E0 (0x1c0 family). H2C is vendor-control-write to a mailbox register, then the chip's firmware reads + processes asynchronously. usbmon shows the mailbox writes but doesn't reveal what the firmware does internally.
• (c) The kernel needs at least one phydm-runtime pass before the chip's first TX produces RF output. The "first 6 URBs without phydm activity" observation might be misleading if 88XXau init had already run phydm once during its 30-second probe and devourer-init does not.

Suspect-address list for next session

Capture devourer's own init usbmon (text format, /sys/kernel/debug/usb/usbmon/4u) and grep for control writes (S Co:4:002:0 s 40 05 <addr>) at the following addresses. Any address in this list that the kernel writes during init/TX but devourer doesn't is a candidate culprit.

0x0060   REG_GPIO_PIN_CTRL_2  (kernel writes 0x00006300 during TX)
0x08a4   BB-related  (12 writes during TX)
0x08f8   BB-indirect-access port: value-write
0x08fc   BB-indirect-access port: address-set
0x0994   Rate-adaptation table  (37 writes — most-touched address)
0x0998   Rate-adaptation table
0x099c   Rate-adaptation table
0x09a0   Rate-adaptation table
0x09a4   Rate-adaptation table  (12 writes)
0x0a0a   ?
0x0a2c   Rate-table indirect access
0x0b58   ?
0x0c1c   BB path A
0x0c50   BB path A
0x0c90   BB path A  (RF-amp related per Realtek conventions)
0x0e1c   BB path B
0x0e50   BB path B
0x0e90   BB path B
0x181c   BB path C
0x1850   BB path C
0x1890   BB path C
0x198c   BB transaction-lock semaphore  (24 writes)
0x1a1c   BB path D
0x1a50   BB path D
0x1a90   BB path D

Particular focus on 0x198c + 0x08fc/0x08f8 triplets in devourer's trace. If devourer issues vendor-control writes to BB registers (e.g. 0x0c90) DIRECTLY (without going through the indirect-access port), but the kernel goes THROUGH the indirect-access port, the chip may treat them differently — the indirect path triggers a BB-RAM update that direct writes don't.

Tooling note

Text-format usbmon (Nu debugfs file on kernel 6.18) truncates URB data to first 32 bytes and strips URB flags. For deeper diffs we'd want binary format (via mon_bin ioctl or wireshark on usbmonN). tools/usbmon_diff.py from earlier today handles text only.

Suggested next-session sequence

1. Capture devourer's full init usbmon during a clean WiFiDriverTxDemo run on 8814AU.
2. Grep for vendor-control writes to each address in the table above.
3. For any address the kernel writes during init that devourer doesn't: port the write into src/HalModule.cpp's 8814 init branch and re-test.
4. If devourer writes the same addresses but different values (likely for some BB regs): match the kernel's values.
5. If all addresses match: investigate the BB-indirect-access port path (0x08fc/0x08f8) for writes devourer makes directly that kernel routes indirectly.
6. If still no on-air: consider H2C mailbox investigation, then phydm runtime port.

Full diagnostic chain recorded as kaeru episodes issue-50-bisect-reconfirms-gate-is-deeper-2026-05-26, issue-50-phydm-runtime-suspect-2026-05-26 (devourer initiative). Working-tree clean; no commits made; experiments fully reverted.

[josephnef]

Update 2026-05-26 (post-hang continuation) — periodic phydm thread also fails

Continued from the previous comment's "next-session suggested sequence". Ran step 3's candidate fix: replay the kernel's pre-first-TX 37-write phydm priming sequence in three insertion-point variants. All three negative.

What was tested

Added HalModule::ApplyPhydmPriming8814a() containing the 37-write sequence captured verbatim from the working VM-passthrough usbmon (timestamps 2870892477–2871770662 — the kernel's writes between fwdl-complete and first bulk-OUT URB). Called it from three different points to rule out "the writes were applied but later overwritten":

Variant	Where it runs	Result
One-shot at end of rtw_hal_init	Before channel-switch + TX-power loop	URBs 1806/1806 OK, 0 on-air
One-shot at end of InitWrite	After channel-switch + TX-power loop	URBs 1803/1803 OK, 0 on-air
Periodic in background thread (every 2 s, matches kernel cadence)	After InitWrite, runs until ~HalModule	URBs 2581/2581 OK, 0 on-air

The periodic variant is the cleanest mimicry of what 88XXau does on VM-passthrough — ~8 cycles of 37 writes interleaved with the bulk-OUT TX URBs over a 16 s window. Chip ACK'd ~296 kernel-style control writes from the background thread without errors. The bulk-OUT path stayed at 100% URB completion. Sniffer (AR9271 monitor ch 6, canonical SA filter) captured 0 frames in every variant.

Implication

Replaying the kernel's runtime register-write pattern — at the same cadence as the working kernel-driver session, with the same byte values, at every plausible insertion point — does not unblock devourer's 8814 on-air TX. The on-air gate is below the vendor-control-write layer that usbmon captures and that we can replay via libusb_control_transfer.

Cumulative negatives across both sessions on this issue (all → 100% URB completion at libusb, 0 on-air):

• TX-descriptor field-value diffs (OWN/DISQSELSEQ, GID, DATA_RETRY_LIMIT)
• TX-descriptor HWSEQ_EN=0 (matches aircrack-ng monitor-injected branch)
• Frame body length / content (45-byte input → 72-byte URB matching inject_beacon.py byte-for-byte)
• DEVOURER_OOT_REPLAY=1 (4464-write kernel post-fwdl replay)
• DEVOURER_FORCE_TXPWR=1 (~300 per-rate TX-power writes)
• 37-write phydm post-init priming, one-shot, both insertion points
• 37-write phydm post-init priming, periodic every 2 s in background thread

That's >= 8 distinct experiments along the register-replay axis. All negative.

Remaining avenues

Per the previous comment's "If still no on-air: consider H2C mailbox investigation, then phydm runtime port" — only the deeper avenues are left:

1. Binary-format usbmon capture. Text-format /sys/kernel/debug/usb/usbmon/Nu strips URB flags (URB_NO_INTERRUPT, URB_BULK_CONTINUATION, URB_ZERO_PACKET, etc.) and truncates data at 32 bytes. qemu's USB host-passthrough on Linux uses libusb under the hood, same as devourer — but qemu may pass URB flags from the VM-side kernel through to the host xhci that libusb's libusb_submit_transfer async path doesn't expose. Wireshark on usbmonN, or a small C tool around MON_IOCX_GETX, would surface URB-flag deltas.
2. H2C (Host-to-Chip) mailbox interface. Kernel writes command data to REG_HMETF0 / REG_HMEBOX_E0 (0x1c0 family). The chip's 8051 firmware reads these mailbox registers and processes the commands asynchronously. usbmon shows the mailbox writes but their effect is firmware-internal — register replay can't reproduce it. Devourer has no H2C interface at all. Implementing it would require reverse-engineering the upstream rtl8814au H2C command formats from hal/rtl8814a/rtl8814a_hal_init.c and the upstream rtl8814a_cmd.c (whichever directory in our vendored aircrack-ng tree).
3. Chip RF state at phy_RFConfig8814A time. Devourer's _radioManagementModule->rtw_hal_set_chnl_bw may be reaching phy_RFConfig8814A from a different chip-state baseline than the kernel does. Same RF-table writes produce different RF outcomes if the chip's BB/AFE state differs at the write. Hard to test cheaply.

Recommend tackling (1) first — binary usbmon is a few-hours job and either rules out URB-flag effects definitively, or points at a specific flag we'd need to set in RtlUsbAdapter::send_packet.

Session artifact state

Branch fix/issue-50-8814-tx-descriptor at origin/master + 0 commits. All experimental code reverted; working tree clean except for tools/usbmon_diff.py (text-format usbmon diff utility, useful for any follow-up).

Kaeru episodes recorded today on this issue: issue-50-bisect-reconfirms-gate-is-deeper-2026-05-26, issue-50-phydm-runtime-suspect-2026-05-26, issue-50-phydm-runtime-thread-also-fails-2026-05-26. The full diagnostic chain is preserved for whoever picks this up next — start from the conclusion ("register-replay exhausted, pivot to binary usbmon or H2C") rather than re-deriving the existing negatives.

[josephnef]

Update 2026-05-26 — band-mismatch hypothesis refuted (channel-hop sweep)

One of the candidate hypotheses I'd flagged was that the chip might be transmitting somewhere — just not on the channel/band we were listening to. Tested directly with a multi-channel hop sweep.

Setup

• devourer-TX running continuously with DEVOURER_CHANNEL=6, DEVOURER_PID=0x8813 against RTL8814AU at sysfs 4-2
• During the run: 27,518 USB submits at the libusb level, 0 fails (confirmed by per-packet log line Packet sent successfully, length: 140,...)
• 2.4 GHz hop: AR9271 (wlp0s20f0u14) in monitor mode, channel set via iw dev ... set channel N between 5 s captures
• 5 GHz hop: RTL8812AU (wlp0s20f0u1) in monitor mode, same procedure
• pcap filter on every capture: wlan addr2 57:42:75:05:d6:00 (canonical txdemo SA, same one that worked at 95 % capture from VM-passthrough 88XXau in the bench-of-record session)

Result

2.4 GHz  ch  1: 0 hits
2.4 GHz  ch  3: 0 hits
2.4 GHz  ch  5: 0 hits
2.4 GHz  ch  6: 0 hits
2.4 GHz  ch  7: 0 hits
2.4 GHz  ch  9: 0 hits
2.4 GHz  ch 11: 0 hits
2.4 GHz  ch 13: 0 hits

5 GHz   ch  36: 0 hits
5 GHz   ch  40: 0 hits
5 GHz   ch  44: 0 hits
5 GHz   ch  48: 0 hits
5 GHz   ch 100: 0 hits
5 GHz   ch 149: 0 hits
5 GHz   ch 161: 0 hits

15 channels covered across both bands, devourer-TX continuously active, zero canonical-SA frames captured anywhere.

Implication

The chip is genuinely silent on all bands when driven by devourer's libusb-userspace path — not hidden on a wrong channel. The on-air gate is real RF-amp-not-emitting (or BB-not-modulating), not a channel/band mis-configuration.

This eliminates one of the hypotheses from the previous comment ("chip RF state at phy_RFConfig8814A time produces a different output channel/band than configured"). The chip isn't on a wrong channel — it's not on any channel.

lkl-wifi-poc cross-check

Also re-ran lkl-wifi-poc 8814AU TX this session: sent=2000 errors=0 at the libusb level, 0 frames on AR9271 ch6. Identical to the bench-of-record run. PR #49 (which fixed devourer's REG_CR=0 wedge) is irrelevant to lkl-wifi-poc — the kernel driver doesn't make that spurious write, so lkl-wifi-poc never had the bulk-OUT wedge issue. Both projects now share the same remaining gate.

Suspect list — narrowed

Of the three remaining hypotheses listed in the previous comment, this experiment reduces them to two:

#	Hypothesis	Status
1	Binary-format usbmon URB-flag diff (qemu's libusb path vs devourer's libusb path)	still open
2	H2C (Host-to-Chip) mailbox commands via REG_HMETF0 / REG_HMEBOX_E0 (0x1c0 family) — opaque-to-usbmon, firmware-internal	still open
3	Chip RF state at phy_RFConfig8814A time produces a different output channel/band	refuted by this hop sweep

Either path forward (1 or 2) is the natural next investigation. (1) is the cheaper of the two — a Wireshark capture on usbmonN for both qemu's passthrough URBs and devourer's URBs would surface URB-flag deltas in a few hours.

[josephnef]

Update 2026-05-26 — H2C mailbox hypothesis refuted

Tested hypothesis (2) from the previous comment. Captured a full-window host-side usbmon (text format) of the working VM-passthrough path covering: virsh attach-device, 88XXau probe + firmware download in VM, iw set monitor + set channel 6, inject_beacon.py 5s burst. ~1 MB capture, 6100 vendor-control-OUT writes total to dev 002.

Filtered for the H2C address range 0x01c0..0x01ff (REG_HMETFR + REG_HMEBOX_0..3 + REG_HMEBOX_EXT_0..3):

$ grep -E '^[0-9a-f]+ [0-9]+ S Co:4:002:0 s 40 05 01[cdef]' /tmp/usbmon_probe.txt
ffff... S Co:4:002:0 s 40 05 01cc 0000 0001 1 = 0f

One H2C-region write across the entire probe + TX session: REG_HMETFR (0x01cc) = 0x0f — and devourer already does that write at src/FirmwareManager.cpp:850:

void FirmwareManager::InitializeFirmwareVars8812() {
  /* Init H2C cmd. */
  _device.rtw_write8(REG_HMETFR, 0x0f);
}

The 942-line hal/rtl8814a/rtl8814a_cmd.c (FillH2CCmd_8814() + friends) in devourer's vendored aircrack-ng tree is for managed-mode features — power-save, BSS-join reports, beacon-early C2H — none of which fire on the monitor-mode injection path. Devourer's existing single H2C-region write is sufficient.

Suspect list — narrowed again

#	Hypothesis	Status
1	Binary usbmon URB-flag diff (URB_NO_INTERRUPT, etc.)	still open — only remaining lead
2	H2C mailbox commands	refuted (this comment)
3	Chip RF state producing wrong channel/band	refuted (previous comment)

The remaining hypothesis is structurally different from everything else tested: it's not about what registers we write, it's about how the URBs are submitted at the usbdevice_fs.h level. libusb-1.0's async API exposes only a subset of the kernel's URB flags. If the 8814's bulk-OUT processor changes behavior based on a flag libusb doesn't set, the gate is invisible to text-format usbmon and won't show up in any register diff.

Next session direction: binary-format usbmon capture (Wireshark on usbmonN, or tshark -i usbmonN -w foo.pcapng) of A=devourer-libusb and B=qemu-passthrough bulk-OUT to EP 0x02; diff xfer_flags byte. If A=0x40 (ZERO_PACKET only) and B includes 0x80 (NO_INTERRUPT), the fix path is to bypass libusb's async submission in src/RtlUsbAdapter::send_packet (Linux only) and call USBDEVFS_SUBMITURB directly with the flag set. PoC exists from earlier today's session (/tmp/usbdevfs_poc.c).

Kaeru episode issue-50-h2c-hypothesis-refuted-2026-05-26 recorded.

[josephnef]

Update 2026-05-26 — binary URB-flag diff refuted; all identified hypotheses exhausted

Tested hypothesis (1) from the previous comment using tshark -i usbmonN -w foo.pcapng to capture binary-format usbmon and usb.copy_of_transfer_flags to inspect URB flags. Captures: A = WiFiDriverTxDemo 12 s on 8814AU (devourer libusb path), B = inject_beacon.py --duration 12 on wlx200db0c7e4b3 while chip is virsh-attached to devourer-testrig (qemu host-passthrough → VM kernel 88XXau → URBs back through libusb on host).

Capture A vs Capture B — full URB-header diff

Field                  A (devourer)      B (qemu kernel)
─────────────────────  ────────────────  ──────────────────
URB type               URB_SUBMIT 'S'    URB_SUBMIT 'S'
URB transfer type      URB_BULK (0x03)   URB_BULK (0x03)
Endpoint               0x02 OUT          0x02 OUT
Device / Bus           4.2.2             4.2.2
URB length             140               72
Data length            140               72
Interval               0                 0
Start frame            0                 0
xfer_flags             0x40 ZERO_PACKET  0x00 (none)
Setup header           unused            unused
Data flag              '\0'              '\0'
URB completion status  0 (success)       0 (success)

The only URB-header-level difference is the URB_ZERO_PACKET flag. Devourer sets it (src/RtlUsbAdapter.cpp:459 → LIBUSB_TRANSFER_ADD_ZERO_PACKET), qemu/kernel doesn't. The flag semantically only fires when transfer length is a non-zero multiple of bulk endpoint MaxPacketSize (1024 for USB-3, 512 for USB-2); 140 and 72 are neither, so the flag is a no-op for both paths.

Removing ZERO_PACKET doesn't help

Gated the flag behind DEVOURER_NO_ZERO_PACKET=1 env var. With the flag suppressed:

submits:  818
complete: 818
fail:     0
on-air:   0

URBs still flow cleanly (the source comment about "chip waits indefinitely for transfer-end signaling and NAKs every URB" was from pre-PR-#49 testing when the bulk-OUT was wedged for a different reason — that condition is gone post-PR-#49, but on-air remains 0).

Submission cadence isn't the gate either

Devourer's default 2 ms inter-submit interval (~500 fps from txdemo/main.cpp:320) vs qemu's 32 ms (~31 fps from inject_beacon.py defaults). Added DEVOURER_TX_INTERVAL_MS=32 env-gate around the sleep, retested:

submits:  46  (matches expected 31 fps × 1.5 s active TX after init)
complete: 46
fail:     0
on-air:   0

Slowing devourer to qemu's cadence doesn't change anything.

Bulk-IN endpoint isn't being used by either path

Both captures: zero bulk-IN URB submissions on dev 002. The earlier concern about "maybe qemu reads bulk-IN to keep TX flowing" is moot.

Full negative ledger from both sessions today on this issue

Hypothesis	Status
TX descriptor field values (3-field skip + HWSEQ_EN flip)	tested — no help
Frame body length/content (byte-for-byte match w/ inject_beacon)	tested — no help
DEVOURER_OOT_REPLAY=1 (4464-write kernel init replay)	tested — no help
DEVOURER_FORCE_TXPWR=1 (~300 per-rate TX-power writes)	tested — no help
37-write phydm post-init priming (3 insertion points + periodic 2 s thread)	tested — no help
Band-mismatch (15 channels across 2.4G + 5G)	refuted
H2C mailbox commands	refuted (kernel uses 1 H2C write devourer already does)
Binary URB-flag diff (only delta was ZERO_PACKET)	refuted (this comment)
Submission cadence (2 ms → 32 ms)	refuted (this comment)

What remains

The on-air gate is genuinely beyond what we can identify from host-side observation. Across every dimension we've tested — descriptor bytes, frame body, register state replay, URB flags, submission rate, channel/band — the chip silently swallows devourer-libusb URBs and emits cleanly for qemu-passthrough kernel-88XXau URBs that are byte-identical at the wire level.

The only operationally distinguishing factor seems to be whether the URBs originated in a kernel usb_submit_urb() (qemu-translated from VM's kernel) vs a libusb libusb_submit_transfer(). That's not a "test cheaply with env var" hypothesis — it's structural. Possible:

1. Host-kernel-side coordination that qemu's USB-host-passthrough sets up (VFIO IOMMU mapping, urb scheduling, completion-handler priority) which libusb userspace can't trigger. Would need kernel-side debugging (ftrace on usb_submit_urb + xhci_handle_event) to confirm/refute.
2. A device-level state-machine quirk where the 8814AU's USB controller distinguishes kernel-submitted from userspace-submitted URBs by some side-channel observation we don't see (urb arrival timing at the µframe level, IOMMU translation latency, etc.). Untestable without specialised hardware (logic analyser on the USB-3 link).
3. The architecture simply doesn't work for this chip. RTL8814AU on devourer's libusb-userspace model may be a hard "no" for TX, just as it's currently a hard "no" for RX (RTL8814AU: devourer-RX captures 0 frames in tests/regress.py full-matrix #51).

Recommendation

Suggest this issue stay open as a known limitation rather than something a code-level fix can close. The diagnostic path is well-documented (5 kaeru episodes in the devourer initiative recording every refutation) so whoever picks it up next won't re-derive what's been ruled out. If RTL8814AU TX support is strategically important, the productive next step is changing the URB submission model (eg. raw USBDEVFS_SUBMITURB with kernel-side instrumentation to compare bulk-OUT URB handling between qemu and direct ioctl) — that's a multi-day investigation beyond a single env-gate experiment.

Artifacts preserved

• /tmp/capA_devourer.pcapng (1.7 MB, binary usbmon) — devourer libusb path
• /tmp/capB_qemu.pcapng (250 KB, binary usbmon) — qemu kernel passthrough path
• /tmp/usbmon_probe.txt (~1 MB, text usbmon) — full kernel probe + TX session
• tools/usbmon_diff.py (text-format parser, ~200 LOC)
• /tmp/usbdevfs_poc.c (raw-ioctl bulk-OUT PoC, ~300 LOC)

Kaeru episodes (full diagnostic detail, devourer initiative):

• issue-50-bisect-reconfirms-gate-is-deeper-2026-05-26
• issue-50-phydm-runtime-suspect-2026-05-26
• issue-50-phydm-runtime-thread-also-fails-2026-05-26
• issue-50-h2c-hypothesis-refuted-2026-05-26
• issue-50-binary-usbmon-zero-packet-flag-not-the-gate-2026-05-26

Working tree clean, no commits on the investigation branch — all experimental code reverted. The fix from PR #49 (bulk-OUT FIFO wedge, REG_CR=0 removal) holds; that's the only landable code change to come out of either session today.