WiFi 6E unter Ubuntu 24.04
23.08.26 (Allgemein)
wenn das 6-GHz-Band unsichtbar bleibt
Der Laptop hing hartnäckig auf 2,4 GHz oder 5 GHz. Pixel 9 und Windows installation verbanden sich am selben UniFi U7 Pro problemlos mit über 1 Gbit/s auf 6 GHz.
Doch mein Ubuntu zeigte das Netz nicht einmal in der Liste an. Das Problem begleitet mich seit 22.04, über mehrere Releases hinweg, und ist auch in 24.04 nicht behoben. Klasische Suche nach leidgenossen und problemlösungen brachten mich erfolglos zu redit aber ließen mich mit Wlan drossel zurück.
Vorweg, damit niemand falsche Erwartungen hat: Ich kann zeigen, dass Hardware, Treiber, Profil und Access Point alle korrekt konfiguriert sind, und einen Workaround liefern, der zuverlässig funktioniert. Was ich nicht liefern kann, ist die endgültige Antwort, warum Ubuntu sich hier anders verhält als Windows, Android und offenbar andere Distributionen. Es sieht nach einem Bug aus — oder zumindest nach einer sehr konservativen Voreinstellung. Wo ich spekuliere, schreibe ich es dazu.
Vorweg, damit niemand falsche Erwartungen hat: Ich kann zeigen, dass Hardware, Treiber, Profil und Was hier sicher ist — und was nicht
Belegt
- Der Access Point sendet 6 GHz, korrekt konfiguriert, mit WPA3-SAE und MFP.
- Der AP kündigt sein 6-GHz-Radio ordnungsgemäß per RNR an.
- Die Karte kann 6 GHz, der Treiber gibt das Band frei, das NM-Profil ist korrekt.
- Ein normaler Scan findet das Netz trotzdem nicht — ein Scan mit Co-Location-Flag sofort.
Offen
- Warum der reguläre Scan-Zyklus von NetworkManager bzw. wpa_supplicant dieses Flag offenbar nicht setzt.
- Was genau Ubuntu anders macht als Fedora oder Mint.
- Ob es dafür einen offiziellen Bug-Report gibt — ich habe keinen gefunden.
Der Workaround weiter unten funktioniert unabhängig davon, woran es am Ende liegt.
Warum das nach einem Ubuntu-Problem aussieht
Ich bin mit dem Symptom nicht allein. Im Ubuntu Community Hub beschreibt jemand exakt dieselbe Situation mit einer AX210 unter 24.04.2 LTS: Das aggregierte SSID wird erkannt, die Verbindung landet aber immer auf 5 GHz — und ein reines 6-GHz-SSID taucht überhaupt nicht auf. Der Autor ist am Ende zu Fedora 42 und Linux Mint 22.1 gewechselt, wo 6 GHz auf derselben Hardware fehlerfrei lief.
Auch an anderer Stelle heißt es sinngemäß, die AX210 könne 6 GHz unter etlichen Distributionen problemlos — unter Ubuntu 24.04 und 25.04 aber offenbar nicht. Einen offiziellen Bug-Report dazu habe ich nicht gefunden. Das Problem scheint bekannt, aber nirgends sauber dokumentiert zu sein. Zugegeben eine arbeit die ich mir auch noch nicht gemacht habe.
Ein Verdächtiger — und warum er nicht recht passt
Der naheliegendste Kandidat ist die wpa_supplicant-Version:
dpkg -l wpasupplicant | tail -1 # ii wpasupplicant 2:2.10-21ubuntu0.4
2.10 ist das Upstream-Release vom Januar 2022. Ubuntu liefert es seit 22.04 durchgehend aus, auch noch in 24.04, während upstream längst 2.11 steht (Juli 2024), das Fedora ausliefert. In den 2.1x-Versionen gab es Arbeit am 6-GHz-Scanning. Das Timing würde zu meinem „seit 22.04″ passen.
Der Haken an der Hypothese
Linux Mint 22.1 sitzt auf derselben Ubuntu-24.04-Basis und müsste damit dieselbe wpa_supplicant-Version mitbringen und dort funktioniert es laut den Berichten. Damit fällt die Versions-Erklärung als alleinige Ursache aus. Ich kann diesen Widerspruch nicht auflösen. Falls jemand den entscheidenden Unterschied kennt: her damit.
Was sich immerhin ausschließen ließ: Die Ubuntu-Datei default-wifi-powersave-on.conf setzt trotz ihres Namens wifi.powersave = 2, und der Wert 2 bedeutet in NetworkManager disable. Powersave ist also ohnehin aus und scheidet als Erklärung aus.
Der Hintergrund: no IR und RNR
Zwei Mechanismen muss man kennen, um die Diagnose zu verstehen.
Erstens: Im 6-GHz-Band markiert die Regulierung alle Kanäle als no IR — no Initiate Radiation. Ein Client darf dort nicht von sich aus senden, also auch keine Probe Requests, mit denen ein gewöhnlicher WLAN-Scan arbeitet. Er darf ausschließlich passiv lauschen.
Zweitens: Damit Clients nicht das ganze Band blind abhören müssen, sieht der Standard den RNR vor — den Reduced Neighbor Report, Information Element 201. Der AP kündigt darin in seinen 2,4- und 5-GHz-Beacons an: „ich habe auch ein 6-GHz-Radio, und zwar auf Kanal X, mit dieser BSSID.“
Ein Client, der das RNR auswertet, weiß danach genau, wo er passiv hinhören muss. Genau das passiert unter Ubuntu offenbar nicht automatisch — obwohl alle Zutaten vorhanden sind und der Kernel es könnte.
01
Prüfen, ob die Hardware überhaupt kann
lspci -nnk | grep -iA3 network
Network controller: Intel Corporation Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2
Kernel driver in use: iwlwifi
Entscheidend ist das 6E im Namen. Eine AX200 kann kein 6 GHz, eine AX210 / AX211 / BE200 schon. Dann prüfen, ob der Treiber das Band freigibt:
iw phy | grep -A3 "Band 4:" iw reg get
phy#0 (self-managed)
country DE: DFS-UNSET
(5945 - 6425 @ 160), (6, 22), (N/A), NO-OUTDOOR, ... PASSIVE-SCAN
5945 – 6425 ist der in der EU freigegebene Bereich (Kanäle 1–93). Fehlt die Zeile, ist 6 GHz auf Treiber- oder Firmware-Ebene gesperrt, und alles Weitere hilft nicht.
Kein Fehler
Das (no IR) an den einzelnen Kanälen muss nicht behoben werden. Es ist genau die oben beschriebene Vorschrift und im Client-Betrieb völlig normal. Es gibt im Netz viele Anleitungen, die daran herumdoktern — das führt in die Irre.
02
Das NetworkManager-Profil prüfen
Naheliegender Verdacht, in meinem Fall aber unschuldig:
nmcli -f 802-11-wireless,802-11-wireless-security connection show "MeineSSID"
Diese vier Werte müssen stimmen, sonst ist 6 GHz von vornherein ausgeschlossen:
| Einstellung | Sollwert | Warum |
|---|---|---|
…security.key-mgmt | sae | 6 GHz erlaubt ausschließlich WPA3-SAE — kein WPA2 |
…security.pmf | 3 (required) | Protected Management Frames sind Pflicht |
…wireless.band | -- | Ein Band-Lock auf a oder bg schließt 6 GHz aus |
…wireless.channel | 0 | Kein Kanal-Lock |
Warnung
Wer gegen das Kleben auf 2,4 GHz 802-11-wireless.band a setzt, sperrt sich damit unter Umständen 6 GHz aus — der Wert meint 5 GHz. Finger weg von dieser vermeintlichen Abkürzung.
03
Nachweisen, dass der AP überhaupt sendet
Ein normaler Scan findet auf 6 GHz nichts:
sudo iw dev wlp88s0 scan | grep -E "^BSS|freq:|SSID:"
Ein passiver Scan über alle EU-6-GHz-Kanäle findet den AP sofort:
sudo iw dev wlp88s0 scan freq \ 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 \ 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415 \ passive | grep -E "^BSS|freq:|SSID:|signal:"
Syntax-Falle
Das Schlüsselwort passive muss hinter die Frequenzliste. Steht es davor, wirft iw nur die Usage-Hilfe aus.
BSS 9c:05:d6:62:e3:b8(on wlp88s0)
freq: 6135.0
signal: -55.00 dBm
SSID: Heginet-Fast
Damit ist die Karte entlastet: Sie kann das Netz empfangen. Sie sucht im Normalbetrieb nur nicht danach. BSSID und Frequenz notieren.
Kommt hier gar nichts, sendet der AP wirklich kein 6 GHz — dann liegt es am Access Point. U6-Pro, U6-LR und U6-Lite haben trotz „WiFi 6″ kein 6 GHz.
04
Nachweisen, dass RNR vorhanden ist
Hier wurde es interessant — und hier bin ich zuerst selbst auf die Nase gefallen.
Der naheliegende Test läuft ins Leere:
sudo iw dev wlp88s0 scan | grep -i "Reduced Neighbor" # (keine Ausgabe)
Falsches Negativ
iw (bei mir 6.7) dekodiert Element 201 gar nicht. Es taucht nur als unbekanntes IE auf — und dafür braucht es das Flag -u. Wer ohne -u greppt, hält den AP fälschlich für schuldig.
sudo iw dev wlp88s0 scan -u | grep -E "Unknown IE \(201\)"
Plötzlich war es da, in jedem 2,4- und 5-GHz-Beacon des APs:
Unknown IE (201): 00 10 86 25 ff 9c 05 d6 62 e3 b8 a2 59 df be 4a 14 ...
Von Hand dekodiert
00 10TBTT Info Header — 1 Eintrag, 16 Byte lang
86Operating Class 134 → 6 GHz, 160 MHz
25Kanal 37
9c 05 d6 62 e3 b8BSSID des 6-GHz-Radios
4aBSS-Parameter — u. a. Same SSID und Co-Located AP gesetzt
Der AP macht also alles richtig. Er kündigt sein 6-GHz-Radio mit korrekter Operating Class, Kanal und BSSID an. Es gibt in UniFi auch keinen RNR-Schalter, den man vergessen haben könnte — das läuft automatisch, sobald dieselbe SSID auf 6 GHz und darunter aktiv ist.
Der Gegentest, der den Bug einkreist
iw kann einen Scan mit gesetztem Co-Location-Flag anfordern (NL80211_SCAN_FLAG_COLOCATED_6GHZ). Dabei wertet der Kernel das RNR aus und hört auf dem angekündigten Kanal passiv mit:
sudo iw dev wlp88s0 scan # → kein 6-GHz-BSS sudo iw dev wlp88s0 scan coloc # → 9c:05:d6:62:e3:b8, 6135 MHz ✓
Derselbe Rechner, derselbe Moment, derselbe AP — nur ein gesetztes Flag Unterschied.
Ab hier Spekulation
Meine Vermutung: Der reguläre Scan-Zyklus setzt dieses Flag nicht, weshalb das vorhandene RNR nie ausgewertet wird. Ob das an NetworkManager liegt, an wpa_supplicant 2.10, an der Kombination beider oder an einem Ubuntu-spezifischen Paketierungsdetail, kann ich nicht sagen. Der Kernel jedenfalls beherrscht den Co-Location-Scan — er wird im Normalbetrieb nur nicht angefordert.
Praktisch ist es zum Glück egal — der Workaround greift so oder so.
05
Der Workaround: BSSID pinnen
Wenn der Client das 6-GHz-BSS nicht von selbst findet, sagen wir ihm direkt, wohin er soll.
5.1 — Bestehendes Profil klonen
Der Klon übernimmt das WLAN-Passwort automatisch. Man muss es nirgends im Klartext eingeben oder auslesen:
nmcli connection clone "Heginet-Fast" "Heginet-Fast-6G"
5.2 — BSSID des 6-GHz-Radios festnageln
nmcli connection modify "Heginet-Fast-6G" \ 802-11-wireless.bssid 9C:05:D6:62:E3:B8
5.3 — Prioritäten setzen
Das 6-GHz-Profil bekommt Vorrang, das alte bleibt als Rückfallebene:
nmcli connection modify "Heginet-Fast-6G" \ connection.autoconnect yes \ connection.autoconnect-priority 10 nmcli connection modify "Heginet-Fast" \ connection.autoconnect-priority 0
Ist das 6-GHz-BSS außer Reichweite, greift automatisch wieder das normale Profil. Man sperrt sich also nicht aus.
5.4 — Verbinden
nmcli connection up "Heginet-Fast-6G"
06
Verifizieren
iw dev wlp88s0 link
Connected to 9c:05:d6:62:e3:b8 (on wlp88s0)
SSID: Heginet-Fast
freq: 6135.0
signal: -52 dBm
rx bitrate: 1441.3 MBit/s 160MHz HE-MCS 7 HE-NSS 2
tx bitrate: 2401.9 MBit/s 160MHz HE-MCS 11 HE-NSS 2
Entscheidend sind freq ≥ 5955 MHz und 160MHz als Kanalbreite. Vorher: 2462 MHz und 172 Mbit/s — grob Faktor 8.
Test, ob es auch nach einem Neustart des Funkmoduls automatisch greift:
nmcli radio wifi off && sleep 8 && nmcli radio wifi on sleep 20 && iw dev wlp88s0 link | grep freq
07
Aufräumen: veraltete Treiber-Optionen
Viele ältere Forenanleitungen empfehlen lar_disable=1, um die Location Aware Regulatory abzuschalten. Diesen Parameter gibt es in aktuellen Kerneln nicht mehr. Bei mir lag noch so eine Altlast herum:
cat /etc/modprobe.d/iwlwifi.conf # options iwlwifi lar_disable=1 sudo dmesg | grep iwlwifi | grep -i "unknown parameter" # iwlwifi: unknown parameter 'lar_disable' ignored
Die Datei kann weg — ein Backup schadet nicht:
sudo mv /etc/modprobe.d/iwlwifi.conf /etc/modprobe.d/iwlwifi.conf.bak
Ebenfalls wirkungslos und reine Kosmetik: iw reg set DE. Die AX210 meldet ihre Regulierungsdomäne self-managed direkt aus der Firmware — der globale Wert wird für diese Karte ohnehin ignoriert.
Was sich gegenüber dem Original ändert
| Änderung | Zweck | Pflicht |
|---|---|---|
| Neues NM-Profil als Klon | Übernimmt das PSK, ohne das Passwort anzufassen | ja |
802-11-wireless.bssid auf die 6-GHz-BSSID | Der eigentliche Workaround | ja |
autoconnect-priority 10 / 0 | 6 GHz bevorzugt, alter Pfad als Fallback | ja |
key-mgmt=sae + pmf=required | Voraussetzung für 6 GHz — meist schon gesetzt | ja |
/etc/modprobe.d/iwlwifi.conf entfernen | Wirkungslose Altlast | optional |
Nicht angefasst werden: Kernel-Parameter, Treiber-Optionen, Regulierungsdomäne, Firmware, AP-Konfiguration. Es ist reine NetworkManager-Konfiguration.
Häufige Rückfragen
Brauche ich das zweite Profil wirklich, oder kann ich das Original ändern?
Technisch geht beides — die BSSID lässt sich genauso gut direkt im Originalprofil setzen. Der Klon existiert allein wegen der Rückfallebene: Ein BSSID-Pin bindet dich an genau dieses eine AP-Radio.
Wer nur einen AP hat, kann das Original bedenkenlos ändern. Wer mehrere APs betreibt und nur einer davon 6 GHz kann, verliert ohne Fallback in allen anderen Räumen das WLAN auf dieser SSID.
Gilt der Workaround ab jetzt automatisch für andere 6-GHz-Netze?
Nein. Der Pin hängt an genau diesem Profil und dieser BSSID. In einem neuen 6-GHz-Netz steht dasselbe Spiel wieder an: passiv scannen, BSSID notieren, pinnen.
Reicht nicht ein regelmäßiger passiver Scan per Cronjob?
Naheliegend, aber getestet und verworfen. Ein passiver Scan legt das BSS tatsächlich in den Cache, nmcli device wifi list zeigt es danach an — aber NetworkManager wechselt nicht von selbst dorthin. Roaming findet nur bei schlechtem Signal statt, und die bestehende 5-GHz-Verbindung ist ja gut.
Man bräuchte zusätzlich einen erzwungenen Reconnect nach jedem Scan. Der Pin ist einfacher und zuverlässiger.
Muss ich am Access Point etwas umstellen?
Nach allem, was ich messen konnte: nein. Der AP sendet RNR korrekt, die SSID ist auf allen Bändern richtig konfiguriert, einen RNR-Schalter gibt es in UniFi ohnehin nicht. Ein Firmware-Update kann trotzdem nie schaden — falls sich das Verhalten damit ändert, würde mich das Ergebnis interessieren.
Ist das jetzt ein Ubuntu-Bug?
Es sieht stark danach aus, aber ich würde es nicht als gesichert verkaufen. Alle Voraussetzungen sind erfüllt, der Kernel kann den Co-Location-Scan, Windows und Android nutzen ihn, und nach übereinstimmenden Berichten tun es Fedora und Mint auf derselben Hardware auch.
Was Ubuntu davon abhält, weiß ich nicht — und einen Bug-Report, der das sauber festhält, habe ich nicht gefunden.
Lohnt sich ein Distributionswechsel?
Wenn 6 GHz der einzige Grund wäre: eher nicht. Der Workaround kostet drei nmcli-Befehle und hält. Wer ohnehin mit dem Gedanken spielt, findet in den verlinkten Threads allerdings Leute, die genau deswegen gewechselt sind und danach Ruhe hatten.
Kurzreferenz
# Kann die Karte 6 GHz? iw phy | grep -A3 "Band 4:" # Sendet der AP 6 GHz? (passiv scannen!) sudo iw dev wlp88s0 scan freq 5955 5975 5995 6015 6035 6055 6075 6095 \ 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 \ 6375 6395 6415 passive | grep -E "^BSS|freq:|SSID:" # Kündigt der AP es per RNR an? (-u ist nötig!) sudo iw dev wlp88s0 scan -u | grep -E "Unknown IE \(201\)" # Gegentest: findet ein Co-Location-Scan es? sudo iw dev wlp88s0 scan coloc | grep -E "^BSS|freq:" # Workaround nmcli connection clone "SSID" "SSID-6G" nmcli connection modify "SSID-6G" 802-11-wireless.bssid <6GHZ-BSSID> \ connection.autoconnect yes connection.autoconnect-priority 10 nmcli connection modify "SSID" connection.autoconnect-priority 0 nmcli connection up "SSID-6G" # Kontrolle iw dev wlp88s0 link
Getestet auf Ubuntu 24.04.4 LTS (Noble) · Intel AX210 · Kernel 7.0 · NetworkManager 1.46 · wpa_supplicant 2:2.10-21ubuntu0.4 · iw 6.7 — Access Point: UniFi U7 Pro.
Der Gerätename wlp88s0 ist überall an das eigene Interface anzupassen, ip link zeigt es.
Quellen: Ubuntu Community Hub — Intel AX210 6 GHz support w/Ubuntu 24.04.2 LTS and later · Intel Community — 6 GHz Wifi with AX210 and Ubuntu
