Repository navigation
Intel 8265 (8086:24fd): working both ways with two quirks #116
Description
Setup
- ASUS X580VD, Intel Dual Band Wireless-AC 8265
8086:24fd, firmware8265-36(36.c8e8e144.0) - Ubuntu 26.04.1, kernel 7.0.0-42-generic (7.0.14)
- Owly built from source at 6f2e8ea, exclusive mode on channel 6, iPhone a metre away
Result
With the two quirks below, in one 5-minute session: four photos from the iPhone (10.3 MB, each on the first try) and one to it (1.1 MB in 12 s), one receiver entry on the phone throughout, no stuck queues.
Two firmware bugs behind "resets about 10 s after the ad-hoc cell starts"
1. The firmware never sends from the cell's group queue. Owly's broadcast action frames and multicast data are bufferable group frames, so iwlmvm puts them on the cell's cab_queue (IWL_MVM_DQA_GCAST_QUEUE, 3), on the BE FIFO since upstream 192a7e1f/3ff4740d "IBSS: use BE FIFO for multicast". Its read pointer never moves:
iwlwifi 0000:03:00.0: Queue 3 is active on fifo 1 and stuck for 10000 ms. SW [0, 253] HW [0, 253] FH TRB=0x080103070
iwlwifi 0000:03:00.0: Microcode SW error detected. Restarting 0x2000000.
The beacon interval makes no difference (tried 1000, 8000 and 10000 TU). The same log shows up on an 8265 in plain IBSS on Intel's forum in 2020 (firmware 22, kernel 5.6), with no fix: https://community.intel.com/t5/Intel-NUCs/Wireless-8265-IBSS-mode-iwlwifi-failure/m-p/1196385
2. From the cell's first beacon on, the firmware stops sending to its stations. With group frames out of the way, the phone's own queues stall instead (mgmt queue 5, data queue 10/11), always at the first TBTT: about 10.5 s after the cell starts with 10000 TU beacons, about 8.4 s with 8000 TU. A trace of the TX responses (trace-cmd -e iwlwifi:iwlwifi_dev_rx) shows ~1,000 frames to the phone completing with SUCCESS, then no more completions at all, with no notification from the firmware and nothing unusual from the phone (no PM bit). A transfer that ends before the first beacon succeeds; the next one doesn't. Firmware 8265-34 behaves the same, or worse.
Quirks
unicast_groups: owly-awdl sends each broadcast or multicast frame as one unicast copy per peer, so the group queue stays empty.ibss_rejoin_secs = 9: the supervisor leaves and rejoins the cell every 9 s, so its first beacon never comes. On this firmware leaving the cell asserts (ADVANCED_SYSASSERT 0x3437) and the firmware restarts in about 1 s; the monitor interface, awdl0 and the receiver survive it, and transfers carry on through it.
Both are set only under [devices."8086:24fd"]. The change is about 70 lines plus a test, over owly-awdl (driver.rs, node.rs) and owly-radio (quirks.rs, injection/setup.rs, injection/mod.rs, drivers.toml). cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings, cargo xtask hardware --check and cargo xtask coverage pass. So do the workspace tests, apart from the ones that need unprivileged user namespaces, which Ubuntu 26.04 blocks by default (kernel.apparmor_restrict_unprivileged_userns = 1); they fail here without the patch too.
Limits
- A 1 s gap every 10 s: one large file failed once and went through on the retry.
- Tested on one card and one phone. The 8260 (
8086:24f3) runs very similar firmware and may want the same quirks.
The quirks are in the PR that links here.
Activity