Correction des problèmes de domaine réglementaire Wi‑Fi 7 sous Linux avec Qualcomm WCN785x (ath12k)

TL;DR : Sous Linux, avec les cartes Wi‑Fi 7 Qualcomm WCN785x (FastConnect 7800, ath12k) ou similaires, la définition du domaine réglementaire (iw reg set, wireless-regdb, etc.) ne fonctionne pas.

Correctif : Le firmware impose des domaines auto‑gérés pour la conformité légale, donc les indications de l’OS sont ignorées. La solution consiste à déclencher un scan passif lors de la connexion, puis à réappliquer iw reg set CA.

Mise à jour (2025-12-31) : Le problème est réapparu plusieurs mois plus tard. Les mises à jour du firmware ont amélioré le comportement, mais ont confirmé que la cause racine est liée au firmware et à l’environnement.

Le Wi‑Fi 7 est enfin arrivé, promettant des débits multi‑gigabits, des canaux de 320 MHz plus larges, et une meilleure efficacité dans les environnements denses. Mais sous Linux, profiter de ces fonctionnalités n’est pas toujours simple, surtout en ce qui concerne les domaines réglementaires.

Sur le papier, définir le code pays de votre carte Wi‑Fi devrait être simple : dire à Linux que vous êtes au Canada (CA), et le pilote déverrouille les fréquences et puissances d’émission autorisées pour cette région. En pratique, après avoir installé une carte Qualcomm WCN785x (FastConnect 7800) sur CachyOS (Linux 6.17, pilote ath12k), aucun des trucs habituels n’a fonctionné. Le système restait obstinément dans le domaine “00 – world” par défaut, bloquant totalement le 6 GHz et sabotant le 5 GHz.

Cet article est une analyse détaillée de ce processus de débogage. J’aborderai :

• Pourquoi les méthodes Linux standard (iw reg set, wireless-regdb, options du noyau, wpa_supplicant, etc.) échouent toutes avec ath12k.
• Ce que j’ai découvert sur la façon dont le firmware impose les paramètres réglementaires à la place du pilote.
• L’indice étrange que j’ai trouvé dans les balises des points d’accès (Environment: bogus).
• Et enfin, le contournement étonnamment simple qui rend le Wi‑Fi 7 utilisable sous Linux avec ce chipset.

Si vous rencontrez le même problème avec un Wi‑Fi 7 Qualcomm, une carte similaire, ou que vous voulez simplement comprendre comment l’application du domaine réglementaire fonctionne en interne, lisez la suite.

Avant de trouver la vraie solution, j’ai passé en revue toutes les méthodes classiques pour imposer le domaine réglementaire à CA, sans succès durable. Voici le décryptage technique, étape par étape.

Contexte : domaine réglementaire et DFS

Avant d’entrer dans le débogage, il est important de comprendre deux concepts clés : le domaine réglementaire (regdom) et le DFS (Dynamic Frequency Selection).

Qu’est‑ce que le domaine réglementaire ?

Chaque pays définit ses propres règles pour l’utilisation du Wi‑Fi :

• Quelles bandes de fréquences peuvent être utilisées (2,4 GHz, 5 GHz, 6 GHz).
• Quels canaux sont disponibles.
• Quelle puissance d’émission est autorisée.
• Si certaines fonctionnalités (comme l’usage extérieur du 5 GHz) sont légales.

Sous Linux, ces règles sont représentées dans la base de données réglementaire sans fil (wireless-regdb), et des outils comme iw, wpa_supplicant et NetworkManager les appliquent généralement. Traditionnellement, vous pouviez définir vous‑même le domaine réglementaire avec des commandes comme iw reg set CA.

Mais les régulateurs, en particulier la FCC aux États‑Unis et des agences similaires dans le monde, en ont eu assez que les utilisateurs contournent ces limites pour augmenter la puissance du signal ou débloquer des canaux interdits. En conséquence, les chipsets Wi‑Fi modernes ne se fient plus uniquement à l’OS. Ils appliquent le domaine réglementaire au niveau du firmware et verrouillent souvent la base de données (regdb.bin) cryptographiquement pour empêcher toute manipulation. C’est pourquoi des commandes qui fonctionnaient sur d’anciennes cartes ne sont plus forcément prises en compte.

Qu’est‑ce que le DFS ?

DFS signifie Dynamic Frequency Selection. Il s’applique principalement à la bande 5 GHz, où certains canaux se chevauchent avec des systèmes radar et météo. Un dispositif Wi‑Fi compatible DFS doit :

1. Écouter les signaux radar avant de transmettre.
2. Libérer immédiatement le canal si un radar est détecté.

À cause de cela, de nombreux canaux DFS sont restreints ou désactivés, sauf si l’appareil est sûr de son domaine réglementaire. Des appareils mal configurés pourraient interférer avec le contrôle du trafic aérien ou des radars militaires, c’est pourquoi les firmwares et points d’accès appliquent une prudence supplémentaire ici.

Comment la carte détermine‑t‑elle le pays ?

Normalement, les points d’accès Wi‑Fi diffusent le code pays dans leurs trames de balise (beacons). Les clients peuvent alors décider s’ils lui font confiance :

• Si le code est valide, le firmware applique le domaine réglementaire correspondant.
• S’il est absent ou bogus, la carte revient généralement aux valeurs sûres par défaut (00), qui restreignent fortement les fréquences disponibles.

Par exemple, lors du scan des AP, vous pouvez voir leurs annonces de pays avec iw dev wlan0 scan dump | grep -e ^BSS -e SSID -e Country

Si un AP est mal configuré, il peut annoncer le mauvais pays ou afficher Environment: bogus. Dans ce cas, des clients comme le firmware du Qualcomm WCN785x n’ouvriront pas tout le spectre, et l’OS ne pourra pas faire grand‑chose pour le contourner.

Pourquoi est‑ce important pour le Wi‑Fi 7 ?

En 2,4 GHz, les erreurs sont moins critiques car l’interférence est déjà omniprésente (fours à micro‑ondes, téléphones sans fil, etc.). Mais en 5 GHz et 6 GHz, une mauvaise configuration pourrait signifier brouiller des systèmes radar. C’est pourquoi des appareils Wi‑Fi 7 comme le Qualcomm WCN785x adoptent une position très conservatrice. Tant qu’ils ne voient pas une annonce de pays valide (ou du trafic prouvant l’environnement), ils se verrouillent.

Domaine mondial vs domaine réglementaire du Canada

La différence entre le domaine mondial (00) et un domaine spécifique à un pays (CA pour le Canada) est spectaculaire. En mode mondial, les fonctionnalités Wi‑Fi 7 comme le 6 GHz et les canaux larges sont désactivées.
Une fois le bon domaine appliqué, tout le spectre et les limites de puissance deviennent disponibles.

Problème : bloqué en domaine mondial (00), Wi‑Fi 7 désactivé

Après l’installation de ma nouvelle carte Qualcomm WCN785x (FastConnect 7800) sous Linux et son association avec un point d’accès UniFi U7 Pro, j’ai remarqué que les fonctionnalités Wi‑Fi 7 étaient absentes. Le système refusait d’activer les canaux larges en 5 GHz, et la bande 6 GHz entière était indisponible.

La vérification du domaine réglementaire a confirmé le problème. Au lieu de respecter CA (Canada), la carte utilisait le code pays 00 (world) par défaut :

sudo iw reg get

• Global regdom : affiche correctement CA avec les règles spécifiques au Canada.
• phy#0 (le périphérique) : reste sur 00 – DFS-UNSET, ce qui handicape la carte.

global
country CA: DFS-FCC
  (2402 - 2472 @ 40), (N/A, 30), (N/A)
  (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
  (5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
  (5470 - 5600 @ 80), (N/A, 24), (0 ms), DFS
  (5650 - 5730 @ 80), (N/A, 24), (0 ms), DFS
  (5735 - 5835 @ 80), (N/A, 30), (N/A)
  (5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR

phy#0 (self-managed)
country 00: DFS-UNSET
  (2402 - 2472 @ 40), (N/A, 20), (N/A), NO-80MHZ, NO-160MHZ, NO-320MHZ
  (2457 - 2482 @ 20), (N/A, 20), (N/A), NO-80MHZ, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
  (5170 - 5330 @ 160), (N/A, 20), (N/A), AUTO-BW, NO-320MHZ, PASSIVE-SCAN
  (5490 - 5730 @ 160), (N/A, 20), (N/A), AUTO-BW, NO-320MHZ, PASSIVE-SCAN
  (5735 - 5895 @ 160), (N/A, 20), (N/A), AUTO-BW, NO-320MHZ, PASSIVE-SCAN

Avec 00, les canaux 5 GHz sont restreints (scan passif uniquement, aucun canal large), et le 6 GHz est complètement désactivé.

Comme vous pouvez le voir ci‑dessous, avec le pays courant 00 (world), les fréquences 5 GHz sont limitées et les fréquences 6 GHz sont complètement désactivées.

iw list | grep -A10 "Frequencies:"

(sortie : 2,4 GHz OK, 5 GHz limité/no IR, 6 GHz désactivé)

  Frequencies: 
    * 2412.0 MHz [1] (20.0 dBm) 
    * 2417.0 MHz [2] (20.0 dBm) 
    * 2422.0 MHz [3] (20.0 dBm) 
    * 2427.0 MHz [4] (20.0 dBm) 
    * 2432.0 MHz [5] (20.0 dBm) 
    * 2437.0 MHz [6] (20.0 dBm) 
    * 2442.0 MHz [7] (20.0 dBm) 
    * 2447.0 MHz [8] (20.0 dBm) 
    * 2452.0 MHz [9] (20.0 dBm) 
    * 2457.0 MHz [10] (20.0 dBm)
--
  Frequencies: 
    * 5180.0 MHz [36] (20.0 dBm) (no IR) 
    * 5200.0 MHz [40] (20.0 dBm) (no IR) 
    * 5220.0 MHz [44] (20.0 dBm) (no IR) 
    * 5240.0 MHz [48] (20.0 dBm) (no IR) 
    * 5260.0 MHz [52] (20.0 dBm) (no IR) 
    * 5280.0 MHz [56] (20.0 dBm) (no IR) 
    * 5300.0 MHz [60] (20.0 dBm) (no IR) 
    * 5320.0 MHz [64] (20.0 dBm) (no IR) 
    * 5500.0 MHz [100] (20.0 dBm) (no IR) 
    * 5520.0 MHz [104] (20.0 dBm) (no IR)
--
  Frequencies: 
    * 5935.0 MHz [2] (disabled) 
    * 5955.0 MHz [1] (disabled) 
    * 5975.0 MHz [5] (disabled) 
    * 5995.0 MHz [9] (disabled) 
    * 6015.0 MHz [13] (disabled) 
    * 6035.0 MHz [17] (disabled) 
    * 6055.0 MHz [21] (disabled) 
    * 6075.0 MHz [25] (disabled) 
    * 6095.0 MHz [29] (disabled) 
    * 6115.0 MHz [33] (disabled)

Résultat : même avec du matériel moderne et des pilotes à jour, la carte refuse d’utiliser les capacités Wi‑Fi 7 sous Linux.

Comportement attendu vs réel

Tentatives pour forcer le domaine réglementaire sous Linux (et pourquoi elles ont échoué)

J’ai essayé toutes les méthodes standard (noyau et espace utilisateur) sur lesquelles les utilisateurs Linux comptent habituellement pour imposer le domaine réglementaire. Aucune n’a fonctionné de manière fiable avec le chipset WCN785x / ath12k.

Tentative 1. iw reg set : changements globaux ignorés par le firmware ath12k

Objectif : Régler le périphérique sur le Canada (CA) afin de déverrouiller les canaux larges 5 GHz et l’ensemble de la bande 6 GHz.

# Définir le domaine réglementaire global
sudo iw reg set CA

# Vérifier ce que pensent le système et le périphérique
sudo iw reg get

# Inspecter ce que le périphérique active réellement
iw list | grep -iE "Frequencies| MHz ["

# Surveiller les réactions du noyau/pilote en temps réel
sudo dmesg -w | grep -iE 'ath12k|cfg80211|regdom|regulator|regulatory'

Attendu :

• iw reg get montre global et phy#0 comme pays CA: DFS-FCC
• iw list expose le 6 GHz + les canaux larges.

Réel :

• global passe à CA, mais phy#0 reste à 00: DFS-UNSET.
• iw list ne montre aucun 6 GHz et aucun 80/160/320 MHz en 5 GHz.
• Les journaux du noyau contiennent des timeouts/erreurs similaires à :

ath12k_pci ... Failed to set the requested Country regulatory setting
ath12k_pci ... Timeout while waiting for regulatory update

Voici ce que signifie réellement la sortie, si vous lancez :

sudo iw reg get

Vous verrez généralement deux sections :

• global : point de vue au niveau de l’OS (ce que cfg80211/wireless-regdb veut).
• phy#0 (self-managed) : point de vue au niveau du périphérique (ce que décide le firmware de la carte).

Si vous voyez (self-managed) à côté de phy#0, le périphérique (ath12k) dit à Linux :

« Je choisirai moi‑même mon domaine réglementaire. »

Dans ce mode, le firmware peut ignorer les requêtes de l’OS comme iw reg set, les paramètres de boot du noyau ou les options de modprobe.

Pourquoi cela échoue sur ath12k

• ath12k (Qualcomm WCN785x / FastConnect 7800) annonce un comportement de réglementation auto‑gérée (self-managed).
• Pour les périphériques auto‑gérés, le firmware applique le pays en se basant sur des preuves “over‑the‑air” (Country IE dans les beacons, résultats de scans, et/ou autre logique interne).
• iw reg set CA met toujours à jour le regdom global, mais n’oblige pas le périphérique à basculer si le firmware ne lui fait pas encore confiance.
• C’est pourquoi vous voyez global = CA alors que phy#0 = 00.

Tentative 2 : wireless-regdb mis à jour, le périphérique l’ignore toujours

Objectif : Appliquer le domaine réglementaire canadien à l’échelle du système via la base de données réglementaire Linux.

Installer wireless-regdb :

pacman -S wireless-regdb

Ou vérifier s’il est déjà installé :

pacman -Qi wireless-regdb

Installed From  : core
Name            : wireless-regdb
Version         : 2025.07.10-1
Description     : Central Regulatory Domain Database
Architecture    : any
URL             : https://wireless.wiki.kernel.org/en/developers/regulatory/wireless-regdb
Licenses        : LicenseRef-custom
Groups          : None
Provides        : crda
Depends On      : bash  iw
Optional Deps   : None
Required By     : None
Optional For    : linux-cachyos  linux-cachyos-lts
Conflicts With  : crda
Replaces        : crda
Installed Size  : 21.21 KiB
Packager        : Tobias Powalowski <tpowa@archlinux.org>
Build Date      : Thu 10 Jul 2025 03:53:56 PM
Install Date    : Thu 25 Sep 2025 01:13:12 AM
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Décommentez la configuration WIRELESS_REGDOM appropriée dans /etc/conf.d/wireless-regdom, ce qui serait WIRELESS_REGDOM="CA" dans mon cas.

cat /etc/conf.d/wireless-regdom | grep -i CA

WIRELESS_REGDOM="CA"

Redémarrez puis vérifiez le domaine réglementaire :

iw reg get

wireless-regdb met à jour la base de données réglementaire du système et fonctionne bien avec la plupart des pilotes.

Mais sur ath12k, le périphérique s’annonce comme self-managed : c’est le firmware qui décide du domaine réglementaire, pas l’OS. Cela signifie que le réglage système est simplement ignoré.

Tentative 3 : options modprobe & paramètres noyau, acceptés mais sans effet

Objectif : Forcer le domaine réglementaire au chargement du module en passant des paramètres au pilote.

J’ai tenté d’ajouter ce qui suit dans /etc/modprobe.d/ath12k.conf :

options cfg80211 ieee80211_regdom=CA

J’ai aussi essayé de définir le même paramètre dans la ligne de commande du noyau (cfg80211.ieee80211_regdom=CA).

Le module se charge sans erreur dans dmesg.

Après redémarrage, j’ai vérifié :

sudo iw reg get

Résultat : comme avant : global = CA et phy#0 = 00 (DFS-UNSET). Aucun changement dans les fréquences ou largeurs de canal disponibles.

Sur les périphériques auto‑gérés, les overrides de regdom au niveau du pilote/module sont contournés : le firmware applique ses propres règles, indépendamment de ce que demande l’OS. cfg80211 accepte le paramètre, mais le firmware ath12k l’ignore.

Tentative 4 : wpa_supplicant : le code pays est interprété, mais pas appliqué

Objectif : Laisser wpa_supplicant appliquer le domaine réglementaire lors de la gestion des connexions Wi‑Fi.

Modification de /etc/wpa_supplicant/wpa_supplicant.conf :

country=CA
ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel
update_config=1

Redémarrage du service :

sudo systemctl restart wpa_supplicant

Vérification du regdom :

sudo iw reg get

Résultat :

• La configuration est correctement interprétée par wpa_supplicant.
• Aucun effet sur le périphérique, phy#0 reste à 00 (DFS-UNSET).
• Les fréquences restent limitées (pas de 6 GHz, 5 GHz étroit).

Sur d’anciens chipsets, wpa_supplicant pouvait appliquer des indications de regdom lors de l’association. Sur les périphériques ath12k auto‑gérés, le firmware ignore ce réglage et se base plutôt sur les beacons de l’AP ou sa propre détection.

Tentative 5 : forcer le backend de NetworkManager n’aide pas pour le regdom

Objectif : Forcer NetworkManager à s’appuyer sur wpa_supplicant pour la gestion Wi‑Fi, en espérant qu’il applique le country=CA lors de l’association.

Modification de /etc/NetworkManager/NetworkManager.conf :

[device]
wifi.backend=wpa_supplicant

Redémarrage de NetworkManager :

sudo systemctl restart NetworkManager

Vérification du regdom après reconnexion

iw reg get

• NetworkManager passe bien à wpa_supplicant comme backend.
• La carte reste en 00 (DFS-UNSET).
• Aucun changement dans les canaux ou bandes disponibles.

NetworkManager n’est qu’une surcouche autour de wpa_supplicant (ou iwd). Le forcer à l’utiliser n’aide pas. Le firmware ignore l’indication et reste sur sa propre logique réglementaire auto‑gérée.

Tentative 6 : automatisation via règles udev échoue à appliquer le regdom

Objectif : Automatiser un contournement en basculant le Wi‑Fi à l’ajout du périphérique, puis en réappliquant le domaine réglementaire avec iw reg set.

Création d’une règle personnalisée dans /etc/udev/rules.d/80-wifi-regdom.rules :

ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*", 
  RUN+="/usr/bin/nmcli radio wifi off; /usr/bin/iw reg set CA; /usr/bin/nmcli radio wifi on"

Rechargement et déclenchement des règles :

sudo udevadm control --reload-rules
sudo udevadm trigger

Vérification :

sudo iw reg get

• La règle s’exécute (les logs confirment que nmcli a tourné).
• Mais le périphérique arrive toujours en 00 (DFS-UNSET).
• Les fréquences et canaux restent restreints.

Désactiver/réactiver le Wi‑Fi ne déclenche pas l’adoption du regdom de l’OS par le firmware. Même lorsque iw reg set CA est exécuté lors de l’ajout du périphérique, le firmware auto‑géré de la carte l’ignore. L’approche semblait “bricolée” et n’apportait aucun avantage par rapport à l’exécution manuelle de iw reg set.

Vérifications de cohérence : noyau, firmware et configs

Objectif : Écarter les erreurs simples ou logiciels obsolètes comme causes de l’échec du regdom.

• Documentation respectée : relecture de l’Arch Wiki et de la doc Linux Wireless pour confirmer que chaque méthode a été appliquée correctement.

• Vérification que le noyau est à jour

  uname -a
  
  Linux cachy 6.16.8-2-cachyos #1 SMP PREEMPT_DYNAMIC Fri, 19 Sep 2025 x86_64 GNU/Linux

• Vérification des paquets et du firmware :

  pacman -Qi iw wireless-regdb linux-firmware | egrep 'Name|Version|Build Date'
  
  Name            : wireless-regdb
  Version         : 2025.07.10-1
  Name            : linux-firmware
  Version         : 1:20250917-1

• Revue des logs du pilote :

  dmesg | grep -i ath12k
  ath12k_pci ... Failed to set the requested Country regulatory setting

Tout était à jour et correctement configuré. Malgré cela, le périphérique refusait toujours de passer à CA. Cela a confirmé que le problème ne venait pas :

• D’un noyau ou d’outils sans fil obsolètes.
• D’une mauvaise configuration.
• D’un firmware non mis à jour.

Le problème était clairement lié au comportement du firmware ath12k, et non à une erreur utilisateur ou un logiciel périmé.

Découverte : le firmware attend un scan d’AP pour définir le regdom

À ce stade, toutes les méthodes Linux standard avaient échoué. Les logs étaient clairs :

ath12k_pci ... Failed to set the requested Country regulatory setting

J’ai donc changé d’angle. Si l’OS n’était pas aux commandes, peut‑être que le firmware attendait un signal de l’environnement.

Vérification du point d’accès (AP)

J’ai scanné mon UniFi U7 Pro et les réseaux à proximité :

sudo iw dev wlan0 scan | grep -A3 "SSID:" | grep Country

Country: CA	Environment: bogus
Country: CA	Environment: Indoor/Outdoor
Country: CA	Environment: Indoor/Outdoor
Country: CA	Environment: Indoor/Outdoor
Country: CA	Environment: Indoor/Outdoor
Country: CA	Environment: bogus
Country: CA	Environment: bogus
Country: CA	Environment: bogus

Parfois l’AP annonçait correctement CA, mais d’autres fois il étiquetait l’environnement comme bogus. Cela correspondait à ce que je voyais : occasionnellement la carte acceptait CA, mais la plupart du temps elle revenait à 00.

L’indice : le scan déclenche le regdom

Après davantage de tests, j’ai remarqué un schéma :

• Au démarrage, la carte commence toujours en 00.
• Si je lance un scan manuellement (iw dev wlan0 scan passive), le périphérique adopte soudainement CA.
• À partir de là, les fréquences se déverrouillent correctement, jusqu’au prochain redémarrage.

Cela expliquait le comportement “aléatoire” que j’avais observé. Il n’était pas aléatoire du tout : le firmware attendait un scan passif pour confirmer l’environnement avant de changer de domaine réglementaire.

Solution : déclencher un scan passif et réappliquer automatiquement le regdom

Une fois que j’ai compris que le firmware avait besoin d’un déclencheur de scan avant d’accepter le domaine réglementaire, la solution de contournement est devenue évidente :

lancer automatiquement un scan passif à chaque fois que l’interface Wi-Fi se lève, puis réappliquer iw reg set CA.

Script de dispatcher NetworkManager

J’ai créé un script dans /etc/NetworkManager/dispatcher.d/20-regdom.sh :

#!/bin/sh
if [ "$2" = "up" ] && [ "$1" = "wlan0" ]; then
    logger "[dispatcher] triggering passive scan for regdom"
    /usr/bin/iw dev wlan0 scan passive >/dev/null 2>&1

    logger "[dispatcher] re-applying regdom CA after connect"
    /usr/bin/iw reg set CA
fi

Je l’ai rendu exécutable :

sudo chmod +x /etc/NetworkManager/dispatcher.d/20-regdom.sh

• Après redémarrage, la connexion au Wi-Fi déclenche maintenant le script du dispatcher.
• La carte lance un scan passif, le firmware met à jour le regdom vers CA.
• iw list confirme que le 6 GHz est activé et que les canaux larges sont disponibles.
• Plus de comportement aléatoire, les fonctionnalités Wi-Fi 7 sont utilisables de manière cohérente.

sudo iw reg get

global
country CA: DFS-FCC
	(2402 - 2472 @ 40), (N/A, 30), (N/A)
	(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
	(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
	(5470 - 5600 @ 80), (N/A, 24), (0 ms), DFS
	(5650 - 5730 @ 80), (N/A, 24), (0 ms), DFS
	(5735 - 5835 @ 80), (N/A, 30), (N/A)
	(5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR

phy#0 (self-managed)
country CA: DFS-FCC
	(2402 - 2472 @ 40), (6, 30), (N/A), NO-80MHZ, NO-160MHZ, NO-320MHZ
	(5170 - 5250 @ 80), (6, 24), (N/A), NO-OUTDOOR, AUTO-BW, NO-320MHZ
	(5250 - 5330 @ 80), (6, 24), (0 ms), DFS, AUTO-BW, NO-320MHZ
	(5490 - 5590 @ 80), (6, 24), (0 ms), DFS, AUTO-BW, NO-320MHZ
	(5650 - 5730 @ 80), (6, 24), (0 ms), DFS, AUTO-BW, NO-320MHZ
	(5735 - 5835 @ 80), (6, 30), (N/A), AUTO-BW, NO-320MHZ
	(5925 - 7125 @ 320), (N/A, 24), (N/A), NO-OUTDOOR, AUTO-BW

• Bande 5 GHz avec canaux 80/160 MHz déverrouillés.
• Bande 6 GHz disponible, jusqu’à 320 MHz de largeur.
• Puissance d’émission jusqu’à 30 dBm selon le canal.

iw list | grep -E "Frequencies| MHz ["

Frequencies:
    * 2412.0 MHz [1] (30.0 dBm)
    * 2417.0 MHz [2] (30.0 dBm)
    * 2422.0 MHz [3] (30.0 dBm)
    * 2427.0 MHz [4] (30.0 dBm)
    * 2432.0 MHz [5] (30.0 dBm)
    * 2437.0 MHz [6] (30.0 dBm)
    * 2442.0 MHz [7] (30.0 dBm)
    * 2447.0 MHz [8] (30.0 dBm)
    * 2452.0 MHz [9] (30.0 dBm)
    * 2457.0 MHz [10] (30.0 dBm)
    * 2462.0 MHz [11] (30.0 dBm)
    * 2467.0 MHz [12] (disabled)
    * 2472.0 MHz [13] (disabled)
    * 2484.0 MHz [14] (disabled)
Frequencies:
    * 5180.0 MHz [36] (24.0 dBm)
    * 5200.0 MHz [40] (24.0 dBm)
    * 5220.0 MHz [44] (24.0 dBm)
    * 5240.0 MHz [48] (24.0 dBm)
    * 5260.0 MHz [52] (24.0 dBm) (radar detection)
    * 5280.0 MHz [56] (24.0 dBm) (radar detection)
    * 5300.0 MHz [60] (24.0 dBm) (radar detection)
    * 5320.0 MHz [64] (24.0 dBm) (radar detection)
    * 5500.0 MHz [100] (24.0 dBm) (radar detection)
    * 5520.0 MHz [104] (24.0 dBm) (radar detection)
    * 5540.0 MHz [108] (24.0 dBm) (radar detection)
    * 5560.0 MHz [112] (24.0 dBm) (radar detection)
    * 5580.0 MHz [116] (24.0 dBm) (radar detection)
    * 5600.0 MHz [120] (disabled)
    * 5620.0 MHz [124] (disabled)
    * 5640.0 MHz [128] (disabled)
    * 5660.0 MHz [132] (24.0 dBm) (radar detection)
    * 5680.0 MHz [136] (24.0 dBm) (radar detection)
    * 5700.0 MHz [140] (24.0 dBm) (radar detection)
    * 5720.0 MHz [144] (24.0 dBm) (radar detection)
    * 5745.0 MHz [149] (30.0 dBm)
    * 5765.0 MHz [153] (30.0 dBm)
    * 5785.0 MHz [157] (30.0 dBm)
    * 5805.0 MHz [161] (30.0 dBm)
    * 5825.0 MHz [165] (30.0 dBm)
    * 5845.0 MHz [169] (disabled)
    * 5865.0 MHz [173] (disabled)
Frequencies:
    * 5935.0 MHz [2] (24.0 dBm)
    * 5955.0 MHz [1] (24.0 dBm)
    * 5975.0 MHz [5] (24.0 dBm)
    * 5995.0 MHz [9] (24.0 dBm)
    * 6015.0 MHz [13] (24.0 dBm)
    * 6035.0 MHz [17] (24.0 dBm)
    * 6055.0 MHz [21] (24.0 dBm)
    * 6075.0 MHz [25] (24.0 dBm)
    * 6095.0 MHz [29] (24.0 dBm)
    * 6115.0 MHz [33] (24.0 dBm)
    * 6135.0 MHz [37] (24.0 dBm)
    * 6155.0 MHz [41] (24.0 dBm)
    * 6175.0 MHz [45] (24.0 dBm)
    * 6195.0 MHz [49] (24.0 dBm)
    * 6215.0 MHz [53] (24.0 dBm)
    * 6235.0 MHz [57] (24.0 dBm)
    * 6255.0 MHz [61] (24.0 dBm)
    * 6275.0 MHz [65] (24.0 dBm)
    * 6295.0 MHz [69] (24.0 dBm)
    * 6315.0 MHz [73] (24.0 dBm)
    * 6335.0 MHz [77] (24.0 dBm)
    * 6355.0 MHz [81] (24.0 dBm)
    * 6375.0 MHz [85] (24.0 dBm)
    * 6395.0 MHz [89] (24.0 dBm)
    * 6415.0 MHz [93] (24.0 dBm)
    * 6435.0 MHz [97] (24.0 dBm)
    * 6455.0 MHz [101] (24.0 dBm)
    * 6475.0 MHz [105] (24.0 dBm)
    * 6495.0 MHz [109] (24.0 dBm)
    * 6515.0 MHz [113] (24.0 dBm)
    * 6535.0 MHz [117] (24.0 dBm)
    * 6555.0 MHz [121] (24.0 dBm)
    * 6575.0 MHz [125] (24.0 dBm)
    * 6595.0 MHz [129] (24.0 dBm)
    * 6615.0 MHz [133] (24.0 dBm)
    * 6635.0 MHz [137] (24.0 dBm)
    * 6655.0 MHz [141] (24.0 dBm)
    * 6675.0 MHz [145] (24.0 dBm)
    * 6695.0 MHz [149] (24.0 dBm)
    * 6715.0 MHz [153] (24.0 dBm)
    * 6735.0 MHz [157] (24.0 dBm)
    * 6755.0 MHz [161] (24.0 dBm)
    * 6775.0 MHz [165] (24.0 dBm)
    * 6795.0 MHz [169] (24.0 dBm)
    * 6815.0 MHz [173] (24.0 dBm)
    * 6835.0 MHz [177] (24.0 dBm)
    * 6855.0 MHz [181] (24.0 dBm)
    * 6875.0 MHz [185] (24.0 dBm)
    * 6895.0 MHz [189] (24.0 dBm)
    * 6915.0 MHz [193] (24.0 dBm)
    * 6935.0 MHz [197] (24.0 dBm)
    * 6955.0 MHz [201] (24.0 dBm)
    * 6975.0 MHz [205] (24.0 dBm)
    * 6995.0 MHz [209] (24.0 dBm)
    * 7015.0 MHz [213] (24.0 dBm)
    * 7035.0 MHz [217] (24.0 dBm)
    * 7055.0 MHz [221] (24.0 dBm)
    * 7075.0 MHz [225] (24.0 dBm)
    * 7095.0 MHz [229] (24.0 dBm)
    * 7115.0 MHz [233] (24.0 dBm)

Conclusion : pourquoi le regdom Wi-Fi 7 sous Linux est contrôlé par le firmware

Le parcours avec le Qualcomm WCN785x (FastConnect 7800, ath12k) sous Linux a rendu une chose claire :

c’est le firmware, pas l’OS, qui contrôle le domaine réglementaire.

Toutes les méthodes classiques Linux, iw reg set, wireless-regdb, options modprobe, kernel cmdline, wpa_supplicant, NetworkManager, et même les règles udev, n’avaient aucun effet parce que la carte se déclare comme self-managed. Cela signifie que le firmware décide quand basculer du world domain (00) vers un code pays spécifique.

Pour ce chipset, le déclencheur était simple mais non évident :

• Pas de scan = bloqué à 00
• Lancer un scan = le firmware met à jour le regdom

En automatisant un scan passif à la connexion et en réappliquant iw reg set CA, j’ai pu déverrouiller le support complet du Wi-Fi 7 sous Linux, incluant 6 GHz, canaux 320 MHz, et une puissance d’émission correcte.

Points clés à retenir pour les utilisateurs Wi-Fi 7 sous Linux

• Si votre carte affiche phy#0 (self-managed), les outils user-space peuvent être ignorés.
• Les chipsets modernes appliquent le regdom au niveau firmware en raison de la pression réglementaire (FCC, ISED, ETSI, etc.).
• Cherchez des indices dans les beacons des AP (iw dev wlan0 scan dump | grep Country) des valeurs bogus ou missing peuvent vous laisser bloqué à 00.
• Les contournements impliquent souvent de déclencher des comportements du firmware (comme des scans), pas de bidouiller les paramètres du noyau.
• À long terme, seules des mises à jour de firmware ou de pilote peuvent réellement corriger ces bizarreries.

Références & ressources supplémentaires sur le regdom et le Wi-Fi Linux

• Arch Wiki : Wireless configuration
• Arch Wiki : wpa_supplicant
• Source kernel : wireless_regdb
• Linux Wireless : Regulatory domain documentation
• Unix StackExchange : Wi-Fi problem with regulatory domain settings
• Discussion Reddit : Mini-review of Qualcomm QCNFA765 ath11k WiFi card in Linux WAP usage

Mise à jour : le problème est revenu… rafraîchissement du firmware et facteurs environnementaux

Plusieurs semaines après une période apparemment stable, j’ai rencontré exactement le même problème de domaine réglementaire à nouveau.

Rien n’avait changé dans ma configuration :

• Même noyau
• Même configuration NetworkManager / dispatcher
• Même point d’accès

Pourtant, phy#0 est de nouveau revenu en self-managed / 00 (DFS-UNSET), avec une disponibilité 6 GHz incohérente et des canaux larges fortement restreints.

Cela excluait une mauvaise configuration côté user‑space et pointait, une fois de plus, vers le comportement du firmware ath12k.

Rafraîchissement du firmware : mise à jour manuelle du fichier board ath12k

La seule action ayant amélioré la situation a été de rafraîchir le fichier board du firmware pour le Qualcomm WCN7850 :

cd /lib/firmware/ath12k/WCN7850/hw2.0
sudo wget -O board-2.bin https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/ath12k/WCN7850/hw2.0/board-2.bin
sudo chmod 644 board-2.bin

Après un redémarrage :

• phy#0 indiquait toujours self-managed
• Le code pays ne basculait pas de manière fiable vers CA
• Cependant, le fonctionnement Wi‑Fi 6 / 6E s’est immédiatement stabilisé
• Le 6 GHz est redevenu utilisable même en restant bloqué sur 00: DFS-UNSET

C’est une nuance importante : la mise à jour du firmware n’a pas corrigé la logique du domaine réglementaire, mais elle a assoupli les limitations fonctionnelles imposées en mode monde.

Interprétation : tolérance du firmware améliorée, logique inchangée

Le firmware plus récent semble être moins conservateur lorsqu’il fonctionne sous 00 :

• Disponibilité de canaux plus large
• Moins de restrictions artificielles
• Stabilité améliorée

Cela suggère fortement que les versions précédentes du firmware étaient excessivement restrictives, voire boguées, lorsqu’elles combinaient DFS‑UNSET avec une utilisation moderne du 6 GHz.

Hypothèse d’interférence environnementale

À ce stade, l’incohérence restante s’explique mieux par l’influence de l’environnement RF, et non par la configuration logicielle.

D’après des scans répétés et les schémas de comportement observés :

• Au moins un point d’accès voisin semble annoncer un Country IE invalide ou incohérent
• Certains beacons indiquent Environment: bogus
• Le firmware ath12k semble recouper les annonces des AP environnants avant de valider un code pays

Si des informations réglementaires contradictoires sont détectées, le firmware préfère rester en mode monde sécurisé (00) plutôt que de risquer une violation DFS ou régionale.

Cela explique pourquoi :

• Les scans passifs corrigent parfois le problème… et parfois non
• Le comportement peut varier selon les redémarrages ou l’heure de la journée
• Les mises à jour du firmware améliorent la tolérance mais pas le déterminisme

Un seul point d’accès voisin mal configuré peut suffire à polluer l’environnement réglementaire pour tous les clients à proximité.

Conclusion pratique

• Si votre périphérique ath12k revient à phy#0 (self-managed) country 00, partez du principe qu’il s’agit d’un état du firmware, pas d’une mauvaise configuration
• Maintenez linux-firmware et les fichiers board ath12k à jour
• Attendez-vous à une application réglementaire sensible à l’environnement, et non strictement déterministe

Sur le matériel Qualcomm Wi‑Fi 6E / Wi‑Fi 7 moderne, le domaine réglementaire n’est plus un paramètre que vous contrôlez : c’est une décision prise par le firmware, influencée par l’environnement RF.