You are not logged in.
I recently upgraded my computer and it has a Qualcomm FastConnect 7800 WiFi 7 card. I'm having a strange issue. I am able to connect to my router through 2.4ghz (b/g) and 5ghz (a/ac.) But it will not connect to my 6E SSID, If the passkey is wrong, it will complain about that as if it knows how to negotiate with the router. But if it is correct, it either says there is no internet, or (more recently) it gives up after a while and falls back to the 5ghz connection.
I'm on the 6.11.7-arch1-1 kernel, with Gnome and NetworkManager. Looks like it's the ath12k module. Has anyone experienced a similar issue or have any ideas as to what this could be? Thanks for your help!
Offline
My first guess would be regulatory domain
https://wiki.archlinux.org/title/Networ … ory_domain
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
I set it to US; issue persists. Tail end of dmesg looking for ath12k:
[244967.695449] ath12k_warn: 38 callbacks suppressed
[244967.695451] ath12k_pci 0000:06:00.0: failed to enqueue rx buf: -28
[245018.740568] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 11 (-105)
[245018.740574] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 11 (-105)
[245018.740575] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE cmd, tid 11 (-105)
[245018.740578] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 12 (-105)
[245018.740579] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 12 (-105)
[245018.740580] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 12 (-105)
[245018.740581] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 12 (-105)
[245018.740583] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 13 (-105)
[245018.740584] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE cmd, tid 13 (-105)
[245018.740585] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 14 (-105)
[245018.740587] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 14 (-105)
[245018.740587] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE, tid 14 (-105)
[245018.740589] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE cmd, tid 14 (-105)
[245018.740591] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE cmd, tid 15 (-105)
[245018.740592] ath12k_pci 0000:06:00.0: failed to send HAL_REO_CMD_FLUSH_CACHE cmd, tid 16 (-105)
[245024.988253] ath12k_warn: 14 callbacks suppressed
[245024.988256] ath12k_pci 0000:06:00.0: failed to enqueue rx buf: -28Offline
If you search your error message, you will see users from all sorts of distros affected with 6.11.
Wifi 7 is still wip for ath12k. If you can wait, I'd do that until linux 6.12 at least.
If that still does not work, you need to check the IDs of the card you have exactly, because there are bugs and some of the patches are applied only to specific cards for which they are reported, e.g. https://bugzilla.kernel.org/show_bug.cgi?id=218467
If you see one with your error message but for a different ath12k card, it should not hurt to add the info.
Offline
Hi there,
I confirm that it is neither a hardware identifier problem, nor a regulatory domain problem.
On Linux 6.12, ath12k works very well with your card. However, there is indeed a problem with iwd.
I identified this problem back in March 2024.
https://lists.infradead.org/pipermail/a … 02005.html
https://lists.infradead.org/pipermail/a … 04696.html
https://bugzilla.kernel.org/show_bug.cgi?id=218733
This issue is now considered an P1 priority.
while i'm sure the team behind ath12k is doing their best to fix this problem. in the meantime this is the workaround:
put this in /etc/iwd/main.conf
[General]
ControlPortOverNL80211=false
Last edited by GreyXor (2024-12-12 11:08:42)
Offline
If you search your error message, you will see users from all sorts of distros affected with 6.11.
Wifi 7 is still wip for ath12k. If you can wait, I'd do that until linux 6.12 at least.
If that still does not work, you need to check the IDs of the card you have exactly, because there are bugs and some of the patches are applied only to specific cards for which they are reported, e.g. https://bugzilla.kernel.org/show_bug.cgi?id=218467
If you see one with your error message but for a different ath12k card, it should not hurt to add the info.
Posting so folks know.
The Qualcomm FastConnect 7800 WiFi 7 card doesn't work with 6.12.4 either. At least not for Bluetooth, it sort of works like the OP said ... with Wifi.
It's not reliable though.
Offline
So I am on Tuxedo OS and was having a similar issue. I am no network expert or anything, but I have Claude code (verify by Codex and Google Gemini online). It MAY have found the issue:
Root cause found: iwd doesn't recognize Wi-Fi 7 oper class 137 (6 GHz 320 MHz)
I hit the same issue — Qualcomm WCN7850 (FastConnect 7800), ath12k, iwd 3.11, connected to a TP-Link Deco BE63 (Wi-Fi 7 mesh). Card would connect to 5 GHz but never select 6 GHz, with constant roam-scan →
client-initiated deauth loops.
The root cause is in iwd's src/band.c. The oper_class_to_band_global table maps oper classes 131–136 to BAND_FREQ_6_GHZ, but oper class 137 (6 GHz, 320 MHz — the Wi-Fi 7 channel width) is missing. When a Wi-Fi 7
AP advertises its 6 GHz BSS as oper class 137 in neighbor reports, iwd can't resolve the band and silently discards it (station.c:2103–2107). This starves the roam scanner of 6 GHz candidates entirely.
The "Failed to find band with country string 'US 4' and oper class 137, trying fallback" warning in the journal is the smoking gun — it fires on every connect but was previously dismissed as cosmetic.
Fix (one-line patch in src/band.c:1481):
// Before:
[131 ... 136] = BAND_FREQ_6_GHZ,
// After:
[131 ... 137] = BAND_FREQ_6_GHZ,
You'll also need to add an entry to the e4_operating_classes table for class 137 (320 MHz, starting freq 5955). Then rebuild and reboot (don't systemctl restart iwd — it can crash with malloc corruption on some
setups).
Still untested as of this writing — will update after applying the patch. This affects iwd 3.11 and 3.12 (latest release, band.c unchanged).
Credit: found with help from Claude (Anthropic) during a homelab debugging session.
Last edited by mrseanpaul81 (2026-03-19 22:56:04)
Offline