Discover composite Wi-Fi interfaces and standardize RX FCS

[RomanLut]

RTL8822BU support and standardize RX FCS

• discover the Wi-Fi bulk interface/endpoints on composite BT/Wi-Fi adapters
• retain the trailing FCS in Packet::Data across Realtek RX paths
• enable APPFCS for Jaguar2 monitor reception

Tested in PixelPilot and hx-esp32-cam android gs.

[josephnef]

Thanks — the direction is right on both halves, and the core FCS change verifies on-air: A/B on an Archer T3U (RTL8812BU), same ambient beacon populations decode at 282/352 B on master vs 286/356 B on this branch — exactly the +4 appended FCS. The parity claim also checks out at the register level (Jaguar1 sets RCR_APPFCS in HalModule.cpp / RadioManagementModule.cpp; Jaguar3's RCR 0xF410400F already has bit31 — Jaguar2 was the outlier). Downstream is mechanically clean: frame_len passes through untouched, C2H reports carry no FCS, the aggregation walk uses next_offset. All 20 ctest selftests pass, and the rewrite incidentally fixes a config-descriptor leak on the old bNumInterfaces==0 path. Nice.

Requesting changes for one functional gap: the discovered Wi-Fi interface number is only logged, never claimed — on a true composite adapter the in-repo demos claim interface 0 (Bluetooth) and bulk I/O on the Wi-Fi interface fails. Details inline. Two smaller items also inline (stale RCR bit-list comment, last-match altsetting selection).

One more thing to note in the PR description: enable_rx() is shared with the RTL8821CE vfio-pci transport, so PCIe RX frames also grow by 4 — tests/pcie_rx_smoke.py should get a re-run before merge. And consider retitling (the 8822BU is already supported; the real content is composite-interface discovery + FCS standardization, which is a deliberate +4 B breaking change for existing Jaguar2 consumers).

[josephnef]

Force-push 5a3c753d addresses all three findings — thanks for the quick turnaround.

Main fix (interface claim): the new find_wifi_interface(handle) helper in UsbOpen is exactly the right shape — it runs the vendor-spec + bulk-IN/OUT scan on the raw handle before the claim, returns bInterfaceNumber (correct for both libusb_claim_interface and the discover_endpoints match), and all 11 demos + the tests now pass its result instead of the literal 0. Falls back to 0 for single-interface parts (8812AU/8814AU), so no regression there. discover_endpoints reuses the helper and now matches altsetting 0 only — which also resolves the last-match altsetting nit.

Comments: both the RCR bit-list (now ... = 0x7000002F + APP_FCS (BIT31) = 0xF000002F with the J1/J3 parity rationale) and the Packet::Data contract are updated and accurate.

Re-verified on hardware (RTL8812BU / Archer T3U): builds clean, all 20 ctest selftests pass, and rxdemo brings up green through the new path — selected USB interface 0 / bulk IN endpoint: 0x84, RX loop entered, ambient beacon decoded at len=285 (body + 4-byte FCS). The RCR constant is byte-identical to the first commit, so the earlier A/B (+4 B, 282/352 → 286/356) still stands.

Two non-blocking follow-ups for whenever convenient: (1) the two commits share the title added rtl8822bu support — a squash-merge with a title reflecting the real content (composite-interface discovery + Jaguar2 RX-FCS standardization, a deliberate +4 B change for existing consumers) would read better in history; (2) enable_rx() is shared with the 8821CE vfio-pci transport, so a tests/pcie_rx_smoke.py pass on that rig before/after merge is still worth doing. LGTM.

[josephnef]

Closed out my open follow-up — ran tests/pcie_rx_smoke.py on the RTL8821CE (PCIe). Since enable_rx() is shared between the USB and vfio-pci transports and the 8821C has finicky phy-status/drvinfo alignment, I did an A/B of just the RCR line on the vfio-bound 8821CE (radxa-x4, 0000:01:00.0):

RCR	ch6	ch36
baseline 0x7000002F	frames=1087 beacons=845 crc_fail=0 PASS	frames=6460 beacons=1160 crc_fail=0 PASS
PR 0xF000002F	frames=1051 beacons=792 crc_fail=0 PASS	frames=9898 beacons=1276 crc_fail=0 PASS

beacon_crc_fail=0 on both bands in both configs → the APP_FCS (BIT31) bit doesn't disturb 8821C PCIe RX. No regression. (The smoke test keys on CRC cleanliness rather than frame length, but the +4 B FCS itself is already confirmed on USB Jaguar2 and the RCR write is transport-agnostic.) NIC restored to rtw_8821ce afterward. That was the last item on my list — no action needed from you.