A ¥112 Qualcomm QCNCM865 Running Wi-Fi 7 at 1.7 Gbps on Debian 13

From missing firmware and regulatory-domain problems to a fully operational 6 GHz / 160 MHz 802.11be access point

Hardware installation and performance report — October 9, 2026

1. Introduction

I recently replaced the original Realtek RTL8852BE Wi-Fi 6 adapter in my ASUS TUF A15 laptop with a Qualcomm QCNCM865 Wi-Fi 7 card.

The price? 112 Chinese yuan (CNY).

The seller explicitly described the product as:

拆机单卡（非测试版卡）

In English: a pulled card sold individually, rather than a test-version card.

In other words, this was not a new retail-packaged Wi-Fi adapter. It was a second-hand OEM module, supposedly removed from another machine.

For 112 yuan, I considered it worth experimenting with.

The result was better than expected. After resolving several Linux driver and firmware issues, the card successfully operated as a Wi-Fi 7 access point on Debian 13, establishing a 6 GHz, 160 MHz, 802.11be connection with an iPhone 16 Pro.

Final iperf3 results: approximately 1,600 Mbps average TCP throughput, with observed peaks of 1,700 Mbps.

This report documents the physical hardware, operating environment, initial problems, software upgrades, configuration, and performance measurements.

It is intended as a reproducible compatibility record rather than a formal laboratory benchmark.

2. Physical Hardware Identification

The card was sold under the model name Qualcomm QCNCM865, based on the WCN7850 / FastConnect 7800 family.

Since OEM cards can have different labels, revisions, and subsystem identifiers, I recorded the physical markings before installation.

2.1 Front-side label

The following is my original transcription:

Model: QCNCM865 WF MAC BT MAC S/N: KF54L006I5 NCM865 T99H432.03 2189081320-08L4 Made in China 

There was also a separate PCB marking near the edge connector:

V015 T99H432.03 GP/HF 

The repeated T99H432.03 identifier is particularly useful when comparing cards from different suppliers.

The exact interpretation of every production and PCB marking has not been independently verified.

2.2 Reverse-side markings

The reverse-side label was transcribed as follows:

Model Name : QCNCM865 Manufacturer: Qualcomm Technologies lnc. FCC ID:... ANATEL:... R-C-QTI-Q... IC:2723A-QCNCM865 CCAI23Y10030T2 R:C-29215 

A regulatory notice was also printed on the card. The readable portion included:

5GHz band(W52, W53) and 6GH... band (LPI): Indoor use only (except communicate to high power radio) 

Transcription note: Some regulatory identifiers were obscured by a seller's warranty/return sticker. The ellipses indicate information that was not visible in the original inspection. The regulatory notice is likewise incomplete and should not be treated as an authoritative full transcription.

The original MAC addresses were not transcribed as text.

2.3 Identification reported by Linux

Once installed, lspci identified the device as:

04:00.0 Network controller [0280]: Qualcomm Technologies, Inc WCN785x Wi-Fi 7(802.11be) 320MHz 2x2 [FastConnect 7800] [17cb:1107] (rev 01) Subsystem: Foxconn International, Inc. High Band Simultaneous Wireless Network Adapter [105b:e0f7] 

The kernel additionally reported:

Hardware name: wcn7850 hw2.0 

These identifiers should make it easier for other Linux users to determine whether their QCNCM865 is the same variant.

3. Test System

All tests were performed on the following machine.

3.1 Hardware

3.2 Software environment

The system remained on Debian GNU/Linux 13.7 (Trixie) throughout the experiment.

The NVIDIA driver was installed from NVIDIA's official Debian 13 repository, with version 595 pinned through its APT driver-pinning package.

The Debian kernel and wireless firmware upgrades were supplied by the official trixie-backports repository.

No distribution change or custom kernel compilation was necessary.

4. Initial Installation: Recognized Immediately, but Unusable

The physical installation was straightforward.

On the first boot, Linux successfully enumerated the new PCIe device. The card appeared in lspci without requiring BIOS modifications or unusual boot parameters.

However, no wireless network interface was available.

The first useful diagnostic commands were:

lspci -nnk | grep -A 6 -Ei 'network|wireless|qualcomm' nmcli device status sudo journalctl -k -b --no-pager | grep -Ei 'ath12k|wcn7850|firmware|qmi|mhi' 

The kernel log showed:

ath12k_pci 0000:04:00.0: Hardware name: wcn7850 hw2.0 ath12k_pci 0000:04:00.0: firmware: failed to load ath12k/WCN7850/hw2.0/firmware-2.bin (-2) mhi mhi0: firmware: failed to load ath12k/WCN7850/hw2.0/amss.bin (-2) mhi mhi0: Error loading firmware: -2 ath12k_pci 0000:04:00.0: failed to start mhi: -110 ath12k_pci 0000:04:00.0: probe with driver ath12k_pci failed with error -110 

The important distinction is that PCIe detection and driver initialization are separate operations.

The kernel could identify the WCN7850 and attempt to initialize it, but the required firmware was missing.

-2 corresponds to ENOENT, indicating that a requested file could not be found. The subsequent -110 is a timeout during initialization.

The Bluetooth side also reported a missing Qualcomm firmware file:

qca/rampatch_usb_00190200.bin 

4.1 Installing firmware

The initial solution was simply to install Debian's official firmware package:

sudo apt update sudo apt install firmware-atheros 

After installing the firmware and rebooting, the card became available in NetworkManager.

The wireless interface was:

wlp4s0 

The initial driver was:

ath12k_pci 

Wi-Fi client functionality worked, and the laptop could connect to my existing Wi-Fi 6 router.

No third-party kernel module or proprietary driver installer was needed.

One small detail: the kernel could still report that firmware-2.bin was unavailable while successfully loading firmware through another supported path. That message alone was therefore not evidence of a continuing failure.

4.2 The original firmware

Once the card initialized, the kernel reported:

fw_version 0x100301e1 fw_build_timestamp 2023-12-06 04:05 

The full firmware build identifier was:

WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 

Thus, although the installed Debian package was dated 2025, the particular WCN7850 firmware image was built in December 2023.

This distinction later became important.

5. The Regulatory-Domain Problem

After obtaining a working Wi-Fi connection, I attempted to use the card as a wireless access point.

The initial 5 GHz hotspot command was:

sudo nmcli device wifi hotspot \ ifname wlp4s0 \ con-name QCNCM865-Test \ ssid QCNCM865-Test \ band a \ channel 36 \ password 'Wifi7Test2026' 

NetworkManager failed to activate it.

The error was:

Connection activation failed: 802.1X supplicant took too long to authenticate 

Repeated attempts did not solve the problem.

5.1 Investigating the regulatory domain

The crucial information came from:

sudo iw reg get 

The output contained two independent regulatory-domain sections:

global country 00: DFS-UNSET 

And:

phy#0 (self-managed) country na: DFS-UNSET 

The wireless card's 5 GHz and 6 GHz bands were marked with PASSIVE-SCAN.

For example:

(5170 - 5330 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN 

This was important because operating as a wireless client and operating as an AP do not have identical regulatory requirements.

A client can often connect to an existing access point on a channel where it is not permitted to initiate transmissions independently.

An AP must initiate transmissions such as beacon frames.

Consequently, the card could connect to my Wi-Fi 6 router while failing to start a 5 GHz hotspot.

5.2 Manually setting Germany did not solve it

I tried:

sudo iw reg set DE sudo iw reg get 

The Linux global regulatory domain changed:

global country DE: DFS-ETSI 

But the wireless device remained:

phy#0 (self-managed) country na: DFS-UNSET 

In other words, the Qualcomm firmware was managing its own regulatory domain, and setting the global domain did not resolve the device-level restrictions.

Similar country na behavior and incorrect wireless statistics had already been reported by other WCN7850 users on the Linux ath12k mailing list in 2024.

5.3 A control experiment: 2.4 GHz AP

To distinguish a general AP driver failure from a regulatory restriction, I tried a 2.4 GHz hotspot on channel 6.

It worked.

The configuration reported:

type AP channel 6 (2437 MHz) width: 20 MHz 

Using an iPhone 16 Pro as the client, iperf3 produced approximately:

80 Mbps TCP throughput.

This confirmed that the card could function as an AP under at least some conditions.

The remaining 5 GHz problem was therefore consistent with the observed regulatory restrictions, although the exact cause had not yet been isolated.

6. Upgrading the Kernel and Firmware

At this point, I decided against continuing to troubleshoot an older wireless-driver implementation.

Debian 13 Stable was retained, but newer kernel and firmware packages were installed through Debian Backports.

The APT source was:

Types: deb URIs: https://deb.debian.org/debian Suites: trixie-backports Components: main contrib non-free non-free-firmware Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg 

After updating the APT package lists, the relevant upgrade command was:

sudo apt install \ linux-image-amd64/trixie-backports \ linux-headers-amd64/trixie-backports \ firmware-atheros/trixie-backports 

For another machine, reviewing the result of apt -s install before performing the upgrade would be advisable.

6.1 The NVIDIA surprise

There was one additional concern.

The laptop uses an NVIDIA RTX 4060 with the 595.91.07 Open Kernel Modules, managed by DKMS.

A major kernel upgrade can sometimes break out-of-tree GPU modules.

Here, however, the entire NVIDIA build completed successfully:

Autoinstall of module nvidia/595.91.07 for kernel 7.2.6+deb13-amd64 (x86_64) Building module(s)................... done. 

The installer built and installed:

nvidia.ko nvidia-modeset.ko nvidia-drm.ko nvidia-peermem.ko nvidia-uvm.ko 

The final DKMS status was:

nvidia/595.91.07, 6.12.107+deb13-amd64: installed nvidia/595.91.07, 6.12.111+deb13-amd64: installed nvidia/595.91.07, 7.2.6+deb13-amd64: installed 

After rebooting, nvidia-smi worked normally. GNOME Shell, Xwayland, and Firefox were also running with NVIDIA acceleration.

Against the usual expectations of NVIDIA-related Linux adventures, absolutely nothing broke.

The existing 6.12 kernels were retained as fallback boot options.

6.2 The new Qualcomm driver and firmware

The upgraded environment reported:

Linux kernel: 7.2.6+deb13-amd64 Driver: ath12k_wifi7_pci firmware-atheros: 20260810-1~bpo13+1 

The new WCN7850 firmware reported:

fw_version 0x1103006c fw_build_timestamp 2026-03-06 09:10 

With build identifier:

WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 

The firmware had advanced from a December 2023 build to a March 2026 build.

6.3 The regulatory domain finally worked

After rebooting, I checked:

sudo iw reg get 

This time the result was:

global country 00: DFS-UNSET phy#0 (self-managed) country DE: DFS-ETSI 

The wireless device itself now recognized Germany.

The 5 GHz channel range used for the original hotspot was no longer restricted to passive operation.

The 6 GHz band also exposed the appropriate German regulatory limits:

(5945 - 6425 @ 320), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW 

Importantly, this describes the permitted frequency range and operating constraints, not a guarantee that every 320 MHz AP configuration will work.

The upgrade had changed both the kernel driver and firmware simultaneously, so this experiment cannot identify which individual change fixed the regulatory issue.

What can be established is that the new kernel/firmware combination resolved the previous 5 GHz AP failure.

7. PCIe: Does the M.2 Slot Limit Performance?

While investigating the hardware, I noticed an interesting result in lspci -vv.

The card reported:

LnkCap: Speed 8GT/s, Width x2 LnkSta: Speed 8GT/s, Width x1 (downgraded) 

Initially, this looked like an unexpected reduction in PCIe width.

However, the upstream AMD Phoenix Root Port revealed the explanation:

00:02.2 AMD Phoenix Root Port LnkCap: Speed 16GT/s, Width x1 LnkSta: Speed 8GT/s, Width x1 

The host port supports PCIe Gen4 ×1, while the Wi-Fi card supports PCIe Gen3 ×2.

Their negotiated connection is therefore:

PCIe Gen3 ×1.

PCIe Gen3 ×1 provides approximately 7.88 Gbit/s of theoretical data capacity per direction after line encoding, before higher-level PCIe transaction overhead.

That is already greater than the approximately 5.8 Gbit/s advertised maximum wireless PHY rate of the FastConnect 7800.

Consequently, there is no compelling bandwidth-related reason to move this Wi-Fi card to an SSD M.2 slot using an adapter.

Such a modification would also complicate the Bluetooth USB connection and antenna arrangement.

The original laptop Wi-Fi slot is the sensible choice.

8. Performance Testing with iPhone 16 Pro and iperf3

All recorded throughput measurements were performed locally, using:

• Access point: ASUS TUF A15 with Qualcomm QCNCM865.
• Client: Apple iPhone 16 Pro.
• Benchmark: iperf3 over TCP.
• Network: Direct Wi-Fi connection between laptop AP and iPhone.
• Internet connection: Not part of the measured data path.

This configuration eliminates an external wireless router as a forwarding bottleneck.

The Debian laptop ran an iperf3 server:

iperf3 -s 

For the manually configured hostapd tests, the laptop used:

192.168.77.1/24 

The iPhone connected to that address using an iperf3-compatible iOS client.

These figures are the approximate average throughput values recorded during the experiments. They are not statistically derived confidence intervals from repeated benchmark batches.

8.1 Results

The highest observed throughput during the final Wi-Fi 7 test was approximately:

1,700 Mbps (1.7 Gbit/s).

8.2 NetworkManager: 20 MHz to 80 MHz

The first successful 5 GHz hotspot used NetworkManager.

By default, it selected:

channel 36 (5180 MHz) width: 20 MHz 

Throughput was approximately 130 Mbps.

Changing the channel-width setting:

sudo nmcli connection modify QCNCM865-5G \ 802-11-wireless.channel-width 80mhz 

Then restarting the connection:

sudo nmcli connection down QCNCM865-5G sudo nmcli connection up QCNCM865-5G 

Produced:

channel 36 (5180 MHz) width: 80 MHz center1: 5210 MHz 

Throughput increased immediately to approximately 635 Mbps.

This demonstrated that the original hotspot's narrow channel width, rather than the PCIe interface, was the primary bottleneck.

8.3 Wi-Fi 6: 80 MHz and 160 MHz

For greater control over wireless operation, I switched from NetworkManager's hotspot function to hostapd.

The 5 GHz AP was configured with 802.11ax enabled.

At 80 MHz, the iPhone negotiated:

tx bitrate: 1200.9 MBit/s 80MHz HE-MCS 11 HE-NSS 2 HE-GI 0 rx bitrate: 1200.9 MBit/s 80MHz HE-MCS 11 HE-NSS 2 HE-GI 0 

The resulting TCP throughput was approximately:

820 Mbps.

This is a substantial improvement over the previous 635 Mbps Wi-Fi 5 test at the same channel width, although the two configurations were not controlled laboratory comparisons.

Moving to 160 MHz

The 5 GHz hostapd configuration used channel 36 and a 160 MHz operating width, with center channel 50.

The relevant parameters included:

hw_mode=a channel=36 ieee80211n=1 ht_capab=[HT40+] ieee80211ac=1 vht_oper_chwidth=2 vht_oper_centr_freq_seg0_idx=50 ieee80211ax=1 he_oper_chwidth=2 he_oper_centr_freq_seg0_idx=50 

The resulting channel required DFS radar detection.

The hostapd log reported:

DFS-CAC-START freq=5180 chan=36 width=2 seg0=50 cac_time=60s DFS-CAC-COMPLETED success=1 AP-ENABLED 

The system then reported:

channel 36 (5180 MHz) width: 160 MHz center1: 5250 MHz 

The iPhone connected successfully.

The average measured throughput reached:

1,500 Mbps.

This was the first result above 1 Gbit/s.

The complete 160 MHz configuration spans channels subject to German DFS rules. The one-minute channel availability check was therefore expected. It should not be disabled or bypassed.

9. Wi-Fi 7: 6 GHz, 160 MHz, and EHT

The final step was to test actual 802.11be operation.

The iPhone 16 Pro supports Wi-Fi 7, including operation in the 6 GHz band.

However, Apple's published specifications limit its single-band channel width to 160 MHz, with two spatial streams and a maximum EHT MCS index of 11.

Therefore, the iPhone cannot test the QCNCM865's full advertised 320 MHz capability.

It can nevertheless verify a real Wi-Fi 7 link.

9.1 Building hostapd 2.12

I used upstream hostapd 2.12 for the Wi-Fi 7 experiment.

This version was officially released in August 2026 and includes additional EHT / IEEE 802.11be improvements.

The required build dependencies can be installed with:

sudo apt install \ build-essential \ pkg-config \ libssl-dev \ libnl-3-dev \ libnl-genl-3-dev 

Then:

mkdir -p ~/src cd ~/src wget https://w1.fi/releases/hostapd-2.12.tar.gz tar xf hostapd-2.12.tar.gz cd hostapd-2.12/hostapd cp defconfig .config 

The following capabilities were explicitly enabled:

CONFIG_DRIVER_NL80211=y CONFIG_LIBNL32=y CONFIG_IEEE80211N=y CONFIG_IEEE80211AC=y CONFIG_IEEE80211AX=y CONFIG_IEEE80211BE=y CONFIG_SAE=y 

The program was then compiled using:

make -j"$(nproc)" 

It was run directly from the build directory, without replacing Debian's packaged hostapd binary.

9.2 Preparing the wireless interface

Before starting standalone hostapd, NetworkManager relinquished control of the Wi-Fi interface:

sudo nmcli device disconnect wlp4s0 sudo nmcli device set wlp4s0 managed no 

The interface was configured for local testing:

sudo ip addr flush dev wlp4s0 sudo ip addr add 192.168.77.1/24 dev wlp4s0 sudo ip link set wlp4s0 up 

The iPhone used a manually configured address in the same subnet.

No DHCP server or Internet connection-sharing service was necessary for iperf3.

9.3 The Wi-Fi 7 hostapd configuration

The following configuration corresponds to the successful 6 GHz / 160 MHz test, with the test password replaced by a reusable example:

interface=wlp4s0 driver=nl80211 ssid=QCNCM865-WiFi7 country_code=DE country3=0x49 ieee80211d=1 hw_mode=a channel=5 op_class=134 wmm_enabled=1 ieee80211ax=1 he_oper_centr_freq_seg0_idx=15 he_6ghz_reg_pwr_type=0 ieee80211be=1 eht_oper_chwidth=2 eht_oper_centr_freq_seg0_idx=15 wpa=2 wpa_key_mgmt=SAE rsn_pairwise=CCMP ieee80211w=2 sae_pwe=2 wpa_passphrase=change-this-test-password unsol_bcast_probe_resp_interval=20 

Several parameters are important:

• channel=5: 6 GHz primary channel at 5975 MHz.
• op_class=134: 6 GHz, 160 MHz operation.
• ieee80211be=1: Enables EHT / Wi-Fi 7.
• he_6ghz_reg_pwr_type=0: Low Power Indoor AP mode.
• wpa_key_mgmt=SAE: WPA3-Personal authentication.
• ieee80211w=2: Required protected management frames.
• sae_pwe=2: Supports SAE Hash-to-Element authentication.

This configuration is intended for indoor use in Germany, consistent with the reported regulatory-domain restrictions.

The AP was started with:

sudo ~/src/hostapd-2.12/hostapd/hostapd \ /tmp/qcncm865-be.conf 

The exact configuration path must match the file created on the local machine.

9.4 Successful Wi-Fi 7 association

The iPhone 16 Pro connected immediately and identified the network as Wi-Fi 7 in iOS settings.

Linux independently confirmed the operating channel:

Interface wlp4s0 type AP channel 5 (5975 MHz) width: 160 MHz center1: 6025 MHz txpower 14.00 dBm 

The station information was even more conclusive:

rx bitrate: 2268.5 MBit/s 160MHz EHT-MCS 11 EHT-NSS 2 EHT-GI 1 last ack signal: -46 dBm avg ack signal: -51 dBm authorized: yes authenticated: yes associated: yes MFP: yes 

This is the decisive evidence that the connection was operating in 802.11be mode.

EHT-MCS 11 and EHT-NSS 2 show the actual Wi-Fi 7 modulation/coding and spatial-stream information reported by the driver.

The 2268.5 Mbit/s value is a PHY-rate observation, not an application-level throughput measurement.

The separate iperf3 benchmark produced:

• Average TCP throughput: approximately 1,600 Mbps
• Highest observed throughput: approximately 1,700 Mbps

The final AP configuration, iPhone settings, and Linux station statistics were mutually consistent with a successful Wi-Fi 7 connection.

10. Interpreting the Results

Several conclusions follow from these experiments.

10.1 Wi-Fi 7 does not automatically double throughput

At 160 MHz, the Wi-Fi 6 experiment already delivered approximately 1,500 Mbps.

Switching to 6 GHz Wi-Fi 7 increased the measured average to approximately 1,600 Mbps.

That is roughly a 6.7% improvement.

However, this should not be interpreted as a controlled measurement of the efficiency advantage of 802.11be over 802.11ax.

The experiments also changed frequency bands, AP software/configuration, and operating conditions.

More importantly, the iPhone 16 Pro is limited to 160 MHz and EHT MCS 11. It cannot use the QCNCM865's advertised 320 MHz channel width or EHT MCS 12–13 in this test.

The achievement is therefore successful 802.11be operation, not proof of the absolute maximum performance of the Qualcomm chipset.

10.2 The old driver reported suspicious statistics

Under Linux 6.12, the WCN7850 occasionally reported:

signal: 0 dBm 

And even:

HE-NSS 3 

The latter would imply three spatial streams, despite the QCNCM865 being a 2×2 device.

The older firmware also produced implausible 802.11n rate reports.

Similar problems were described on the upstream ath12k mailing list.

With the newer kernel, the reported number of HE/EHT spatial streams was consistent with the hardware.

However, the signal: 0 dBm field was still observed under the new driver.

The ACK signal statistics, such as -46 dBm, were more plausible.

Therefore, the upgraded software improved the reported wireless information but did not eliminate every apparent statistics issue.

10.3 PCIe Gen3 ×1 is sufficient

The Wi-Fi card was operating through a PCIe Gen3 ×1 link throughout the tests.

Nevertheless, it achieved 1.6 Gbit/s average TCP throughput and an observed peak of 1.7 Gbit/s.

This strongly supports the conclusion that the existing PCIe connection is not limiting performance in the tested configurations.

There is no reason to sacrifice an SSD slot merely to obtain an additional PCIe lane.

10.4 A new kernel made a substantial difference

On Debian 13 with Linux 6.12, the card could function as a Wi-Fi client after installing firmware, but its 5 GHz AP operation was blocked by unresolved regulatory/initialization behavior.

After upgrading to Linux 7.2.6 and newer firmware:

• The new ath12k_wifi7_pci driver initialized successfully.
• The card reported DE: DFS-ETSI.
• 5 GHz AP mode operated correctly.
• 160 MHz Wi-Fi 6 AP mode worked with DFS.
• 6 GHz Wi-Fi 7 AP mode worked with WPA3-SAE.
• iperf3 reached 1.6 Gbit/s average throughput.

For users experiencing similar problems, checking the kernel and firmware versions should be a priority before attempting complicated manual driver modifications.

11. What Was Not Tested

To avoid overstating the findings, several features remain unverified.

320 MHz channels: The Qualcomm card advertises support, and Linux exposes relevant EHT capabilities. However, the iPhone 16 Pro supports only 160 MHz per band. No 320 MHz client test was conducted.

Multi-Link Operation (MLO): The successful 6 GHz EHT association does not establish that multi-link operation works. No multi-link association or aggregate multi-band throughput test was performed.

Bluetooth: The initial boot reported missing Qualcomm Bluetooth firmware. Bluetooth behavior after upgrading was not separately benchmarked or systematically verified.

Suspend/resume stability: The regulatory domain and AP behavior were tested after a clean reboot. Repeated suspend/resume and long-term stability testing were not performed.

Power consumption: No controlled measurements were made comparing QCNCM865 and the original RTL8852BE.

Long-term AP reliability: Successful short iperf3 sessions do not prove uninterrupted operation over days or weeks.

Benchmark repeatability: The reported speeds are observational results from an exploratory series, not averages over a large number of standardized trials. Different TCP directions, stream counts, environmental conditions, and client configurations may produce different results.

These limitations do not undermine the basic compatibility result: the hardware successfully operated as a Wi-Fi 7 AP under Linux.

12. Conclusion

The Qualcomm QCNCM865 turned out to be a remarkably interesting upgrade.

For 112 CNY, I obtained a second-hand OEM Wi-Fi 7 module that Linux immediately recognized at the PCIe level.

The initial experience was not entirely painless:

1. Missing firmware prevented driver initialization.
2. Installing Debian's firmware-atheros enabled Wi-Fi client operation.
3. The original kernel/firmware combination left the card in an unresolved self-managed regulatory domain, preventing 5 GHz AP activation.
4. Upgrading to Linux 7.2.6 and newer Qualcomm firmware corrected the observed regulatory behavior.
5. NetworkManager successfully provided basic hotspot functionality.
6. hostapd enabled 160 MHz Wi-Fi 6 and ultimately 6 GHz Wi-Fi 7 operation.

And, unexpectedly, the NVIDIA 595 driver survived the kernel upgrade without requiring any intervention.

The final configuration achieved:

Qualcomm QCNCM865 + Debian 13 + Linux 7.2.6 + hostapd 2.12 + iPhone 16 Pro

With:

6 GHz / 160 MHz / 802.11be / 2×2 MIMO / WPA3-SAE

And:

1.6 Gbit/s average TCP throughput, 1.7 Gbit/s observed peak.

The result does not establish the absolute maximum throughput of the hardware, nor does it verify MLO or 320 MHz operation.

But it demonstrates that, with sufficiently recent kernel and firmware support, a very inexpensive pulled QCNCM865 can deliver fully functional, high-throughput Wi-Fi 7 on Debian 13.

For me, that is a successful hardware upgrade—and a good reminder that compatibility often depends as much on the software stack as on the physical device.

References and Further Reading

1. Debian Trixie Backports — Linux kernel packages
2. Debian Trixie Backports — firmware-atheros
3. hostapd official releases
4. hostapd / wpa_supplicant 2.12 release announcement, August 2026
5. Apple — Wi-Fi and Ethernet specifications for Apple devices
6. Linux ath12k mailing list — WCN7850 issues, August 2024

All hardware identifiers, system logs, configuration outcomes, and benchmark results described in this report were taken from the actual installation and testing session, conducted on October 9, 2026.

Summarized by ChatGPT. Reviewed by the author.