FritzBox Mesh Probleme - gibt es eine bessere Alternative?

[bender_]

Zumindest bei den Wi-Fi 5 Gerätschaften der Telekom ist offenbar auch noch ordentlich Luft nach oben.

Oder beim Surface 3. Sieht nicht danach aus als würde bei dir 802.11r klappen.
Hier der Vergleich:

Quelle: https://blogs.cisco.com/networking/what-is-802-11r-why-is-this-important

 

[7H0M45]

Ich denke, da liegt ein Mißverständnis vor, was Mesh bewirken soll. Im Mesh kannst Du von einer Stelle in Deiner Wohnung - abgedeckt von der 7580 - zu einer anderen Stelle - abgedeckt vom Repeater - gehen, ohne die Parameter für das WLAN (SSID, Passwort) umstellen zu müssen (auch Dein PC muß nicht umgeschaltet werden). Mesh bedeutet nicht, daß Du eine unterbrechungsfreie WLAN-Versorgung hast.

Dann liegt das Missverständnis aber bei AVM vor. Die werben mit:

"Im Gegensatz zu WLAN-Roaming kann die FRITZ!Box ab FRITZ!OS 7.10 aktuelle WLAN-Geräte per WLAN Mesh Steering unterbrechungsfrei in das optimale Funknetz steuern."

https://avm.de/mesh/faqs/welche-fri...Was-ist-WLAN-Roaming-und-wie-funktioniert-es/

 

[redjack1000]

"Im Gegensatz zu WLAN-Roaming kann die FRITZ!Box ab FRITZ!OS 7.10 aktuelle WLAN-Geräte per WLAN Mesh Steering unterbrechungsfrei in das optimale Funknetz steuern."

Nette Werbefloskeln, nicht mehr und nicht weniger. Du must dann mal weiterlesen -> https://avm.de/mesh/faqs/welche-fri...t-WLAN-Mesh-Steering-und-wie-funktioniert-es/

Und dann kommen die Einschränkungen bzw. was erforderlich ist.

Cu
redjack

 

[Engaged]

Oder beim Surface 3. Sieht nicht danach aus als würde bei dir 802.11r klappen.
Hier der Vergleich:
Anhang anzeigen 1230835
Quelle: https://blogs.cisco.com/networking/what-is-802-11r-why-is-this-important

Die schaltszeiten sind ja mal geil, das kann AVM auf keinen Fall(?), und nervt mich jetzt schon wenn ich die Grafik da sehe. 🤣

Dann liegt das Missverständnis aber bei AVM vor. Die werben mit:

"Im Gegensatz zu WLAN-Roaming kann die FRITZ!Box ab FRITZ!OS 7.10 aktuelle WLAN-Geräte per WLAN Mesh Steering unterbrechungsfrei in das optimale Funknetz steuern."

Also so schnell wie oben in der Grafik mit wenigen Millisekunden funktioniert das irgendwie nicht nein. 🤷🏻‍♂️

Ergänzung (22. Juni 2022)

Nette Werbefloskeln, nicht mehr und nicht weniger. Du must dann mal weiterlesen -> https://avm.de/mesh/faqs/welche-fri...t-WLAN-Mesh-Steering-und-wie-funktioniert-es/

Wie es aussieht fehlt AVM das wichtigste für einen schnellen Wechsel das sollte dann 802.11r sein oder was, das ist ja kacke! 😑

 

[0-8-15 User]

Oder beim Surface 3.

Richtig, aber bei der derzeitigen Softwarequalität des Speedport Pro halte ich das für den mit Abstand unwahrscheinlichsten Grund. Die aktuelle Firmware strotzt nur so von Bugs in Sachen WLAN und Mesh.

Sieht nicht danach aus als würde bei dir 802.11r klappen.

Wenn ich folgende Aussage richtig verstehe, dann ist beim Speedport Pro ohne Mesh Essig mit 802.11r:

Laut der der Rückmeldung wird das IEEE 802.11r vom Speedport Pro nur im Zusammenhang des eigenen Mesh-Netzwerkes unterstützt, aber nicht zwischen Speedport Pro und einer Insel-Mesh Lösung im LAN.

 

[ookee]

Wenn ich folgende Aussage richtig verstehe, dann ist beim Speedport Pro ohne Mesh Essig mit 802.11r:

Das ist doch aber zwangsläufig so? Das generelle Prinzip von 802.11r ist ja, dass die APs untereinander Schlüsseldaten austauschen, wofür es unter anderem einen gemeinsamen AES-Schlüssel zur Verschlüsselung der ausgetauschten Pakete braucht. Wobei man zumindest bei bei WPA2-PSK auch darauf verzichten und die nötigen Daten stattdessen lokal berechnen kann. Aber auch dann muss bei allen APs die gleiche Mobility Domain konfiguriert sein (die wird in den Beacons mitgesendet).

 

[0-8-15 User]

In dem oben verlinkten Thread im Telekom hilft Forum, war die Ausgangslage:

Jeder AP macht sein eigenes WLAN auf, allerdings alles mit gleicher SSID usw. Die APs sind über LAN verbunden. Der Speedport Pro macht ebenfalls das gleiche WLAN auf und dient über LAN allen anderen als Gateway.

Bei meinem Test war die Ausgangslage ein als WLAN-Repeater konfigurierter Speed Home WiFi, der direkt mit dem Speedport Pro verbunden war. Eine Konfiguration als Mesh-Repeater ist mit der aktuellen Firmware auch nach mehreren Versuchen nicht möglich und das Fehlerbild riecht schwer nach einem Bug.

Das ist doch aber zwangsläufig so?

Wenn das zwangsläufig so wäre, dann stünde das im Widerspruch zu der hier weitläufig verbreiteten Meinung, dass es bezüglich der reinen Funktionalität keinen Unterschied machen würde, ob Mesh oder nicht Mesh, solange alle beteiligten Geräte die entsprechenden Standards unterstützen.

 

[bender_]

Das ist doch aber zwangsläufig so? Das generelle Prinzip von 802.11r ist ja, dass die APs untereinander Schlüsseldaten austauschen

Teil dieses Prinzips sind 2 Protokolle die diesen Austausch definieren:

Because Fast BSS Transition reestablishes existing parameters, the protocols require that information be exchanged during the initial association (or at a subsequent reassociation) between the mobile device (formally referred to as the FT Originator (FTO)) and an AP. The initial exchange is referred to as the FT initial mobility domain association. Subsequent reassociations to APs within the same mobility domain are expected to utilize the FT protocols.

Two basic FT protocols are described:

1. FT Protocol. This protocol is performed when a mobile devices transitions from one AP to another AP but does not require a resource request prior to its transition. The AP selected by the mobile device for reassociation is referred to as the “target AP”.
2. FT Resource Request Protocol. This protocol is performed when a mobile device requires a resource request prior to its transition.

For a mobile device to transition from the AP it is currently associated with to a target AP, the FT protocol message exchanges are performed using one of two methods:

1. Over-the-Air. The mobile device communicates directly with the target AP using IEEE 802.11 authentication with the FT authentication algorithm.
2. Over-the-DS. The mobile device communicates with the target AP via the current AP. Communications between the mobile device and the target AP are encapsulated within FT Action frames between the mobile device and the current AP. Communications between the current AP and the target AP, occurs via a different encapsulation method. The current AP converts between the two encapsulation methods.

[IMG]https://storage.googleapis.com/blogs-images/ciscoblogs/1/802.11r-image-1-550x276.png[/IMG]

Over the Air message exchange (excerpted from IEEE 802.11-2012)

[IMG]https://storage.googleapis.com/blogs-images/ciscoblogs/1/802.11r-image-2-550x356.png[/IMG]

Wieder aus: https://blogs.cisco.com/networking/what-is-802-11r-why-is-this-important

Wenn APs nach Herstellerangabe diese Protokolle unterstützen, funktioniert das natürlich auch. Das ist ja der Sinn hinter einem Standard. Genau so wie sich WLAN Karten nach 802.11n mit jedem AP der 802.11n unterstützt verbinden können - egal von welchem Hersteller.
Wenn es nicht funktioniert, liegt das zu 90% an fehlerhafter Implementierung einer beteiligten Komponente. Mir wäre jetzt auch keine Einrichtung oder Behörde bekannt, die prüft ob Netzwerkgeräte wirklich 100% den Standards entsprechen, die die Hersteller so auf ihre bunten Datenblätter drucken. Das dürfte alles Selbstauskunft sein und da in der Regel keine Menschenleben dranhängen wird hier bestimmt auch viel getrickst.

 

[0-8-15 User]

Speedport Pro in vier Worten: 'Hardware Hui, Software Pfui'. Mit Mesh ist auch kein Blumentopf zu gewinnen:

 

[ookee]

Teil dieses Prinzips sind 2 Protokolle die diesen Austausch definieren:

Nein, diese Protokolle definieren nur die Kommunikation zwischen Endgerät und APs, und im Fall der Over-the-DS-Variante die Weiterleitung dieser Kommunikation zwischen aktuellem und neuem AP.

Der beschriebene Schlüsselaustausch ist davon unabhängig und tatsächlich sind da sogar nur die Anforderungen spezifiziert, aber keine konkrete Implementierung (direkt aus 802.11-2012):

The R0KH and the R1KH are assumed to have a secure channel between them that can be used to exchange cryptographic keys without exposure to any intermediate parties. The cryptographic strength of the secure channel between the R0KH and R1KH is assumed to be greater than or equal to the cryptographic strength of the channels for which the keys are used. This standard assumes that the key transfer includes the PMK-R1, the PMK-R1 PMKSA, the PMK-R1 context, and the associated key authorizations. The protocol for distribution of keying material from the R0KH to the R1KH is outside the scope of this standard.

Wobei wie gesagt bei FT-PSK nicht zwingend eine Kommunikation für den Schlüsselaustausch nötig ist. Zumindest bei hostapd gibt es eine Option mit der die nötigen Werte auf jedem AP lokal berechnet werden (aber interoperabel mit anderen Implementierungen ist das vermutlich auch nicht).

In einem Mesh-System ist das natürlich alles untereinander kompatibel und wird automatisch passend konfiguriert. Aber dass 802.11r einfach so mit beliebigen APs funktioniert halte ich für äußerst unwahrscheinlich. Und für eine manuelle Konfiguration dürften den üblichen Consumer-Geräten sowieso die entsprechenden Einstellungsmöglichkeiten fehlen.

 

[bender_]

@ookee
Das beschreibt die Problematik des Schlüsselaustauschs in einem 802.1X Netzwerk mit Controller.
Siehe auch:

Quelle: https://mrncciew.com/2014/09/05/cwsp-802-11r-key-hierarchy/

802.11r unterstützt aber explizit auch Roaming von WPA2-PSK ohne EAP da es - vereinfacht dargestellt - den PSK als Authentifizierung nutzt.

Schnelles und sicheres Roaming mit 802.11r​

Die schnelle und sichere Roaming-Technik, die auf der 802.11r-Änderung basiert (offiziell Fast BSS Transition nach dem 802.11-Standard genannt und FT), ist die erste Methode, die offiziell (2008) vom IEEE für den 802.11-Standard als Lösung für schnelle Übergänge zwischen APs ratifiziert wurde. (Basic Service Sets, bzw. BSSs), die die Schlüsselhierarchie eindeutig definiert, die bei der Verarbeitung und Zwischenspeicherung von Schlüsseln in einem WLAN verwendet wird. Die Einführung erfolgte jedoch nur langsam, vor allem aufgrund der anderen Lösungen, die bereits verfügbar waren, als tatsächlich schnelle Übergänge erforderlich waren, z. B. bei VoWLAN-Implementierungen bei Verwendung mit einer der in diesem Dokument beschriebenen Methoden. Es gibt nur wenige Geräte, die derzeit einige der FT-Optionen unterstützen (bis 2013).

Diese Technik ist komplizierter zu erklären als die anderen Methoden, da sie neue Konzepte und mehrere Ebenen von PMKs einführt, die auf verschiedenen Geräten (jedes Gerät mit einer anderen Rolle) zwischengespeichert werden, und noch mehr Optionen für schnelles, sicheres Roaming bietet. Daher wird eine kurze Zusammenfassung dieser Methode und ihrer Implementierung mit jeder verfügbaren Option bereitgestellt.

802.11r unterscheidet sich von SKC und OKC, vor allem aus folgenden Gründen:

• Handshake-Messaging (z. B. PMKID, ANonce und SNonce-Austausch) erfolgt in 802.11-Authentifizierungs-Frames oder in Action-Frames anstelle von Reassemblierungs-Frames. Im Gegensatz zu den PMKID-Caching-Methoden wird die separate 4-Wege-Handshake-Phase, die nach dem (Re-)Zuordnung-Nachrichtenaustausch durchgeführt wird, vermieden. Der Schlüsselhandshake mit dem neuen Access Point beginnt, bevor der Client vollständig mit diesem neuen Access Point wechselt bzw. ihm erneut zugeordnet wird.
• Es bietet zwei Methoden für den Fast-Roaming-Handshake: über die AIR und über das Distribution System (DS).
• 802.11r verfügt über mehr Ebenen der Schlüsselhierarchie.
• Da dieses Protokoll den 4-Wege-Handshake für die Schlüsselverwaltung vermeidet, wenn ein Client roam (generiert neue Verschlüsselungsschlüssel - PTK und GTK - ohne diesen Handshake), kann es auch für WPA2-Konfigurationen mit einem PSK angewendet werden, und nicht nur, wenn 802.1X/EAP für die Authentifizierung verwendet wird. Dies beschleunigt das Roaming für diese Einrichtungen sogar noch mehr, wenn kein EAP- oder 4-Wege-Handshake-Austausch erfolgt.

Bei dieser Methode führt der Wireless-Client nur eine erste Authentifizierung für die WLAN-Infrastruktur durch, wenn eine Verbindung mit dem ersten WAP hergestellt wird. Er führt ein schnelles und sicheres Roaming durch, während die WAPs derselben FT-Mobilitätsdomäne Roaming nutzen.

Dies ist eines der neuen Konzepte, das sich im Wesentlichen auf die APs bezieht, die dieselbe SSID (auch als Extended Service Set oder ESS bezeichnet) verwenden und dieselben FT-Schlüssel verarbeiten. Dies ähnelt den bisher erläuterten anderen Methoden. Die Art und Weise, wie APs die FT-Mobilitätsdomänenschlüssel verarbeiten, basiert in der Regel auf einer zentralisierten Einrichtung, z. B. dem WLC oder den Mobilitätsgruppen. Diese Methode kann jedoch auch in autonomen AP-Umgebungen implementiert werden.

Hier eine Zusammenfassung der Schlüsselhierarchie:

• Auf der Client-Komponente und dem Authentifizierungsserver wird weiterhin ein MSK aus der ersten 802.1X/EAP-Authentifizierungsphase abgeleitet (Übertragung vom Authentifizierungsserver zum Authentifizierer (WLC) nach erfolgreicher Authentifizierung). Wie bei den anderen Methoden wird dieses MSK als Seed für die FT-Schlüsselhierarchie verwendet. Wenn Sie WPA2-PSK anstelle einer EAP-Authentifizierungsmethode verwenden, ist das PSK im Grunde dieses MSK.
• Ein paarweise Master Key R0 (PMK-R0) wird vom MSK abgeleitet, dem ersten Schlüssel der FT-Schlüsselhierarchie. Die Hauptakteure für diesen PMK-R0 sind der WLC und der Client.
• Ein zweiter Schlüssel, der paarweise Master Key R1 (PMK-R1) genannt wird, wird vom PMK-R0 abgeleitet. Die Hauptakteure sind der Client und die vom WLC verwalteten APs, die den PMK-R0 enthalten.
• Der dritte und letzte Schlüssel der FT-Schlüsselhierarchie ist das PTK. Hierbei handelt es sich um den endgültigen Schlüssel zur Verschlüsselung der 802.11-Unicast-Datenframes (ähnlich den anderen Methoden, die WPA/TKIP oder WPA2/AES verwenden). Dieses PTK wird auf FT vom PMK-R1 abgeleitet, und die Hauptakteure sind der Client und die vom WLC verwalteten APs.

Hier der detailierte Raoming Vorgang dazu:

Im Folgenden werden die Erfassung und das Debuggen einer anfänglichen Verknüpfung mit dem WLAN aufgeführt, wenn Sie FT mit WPA2-PSK ausführen (anstelle einer 802.1X/EAP-Methode), wobei der Association Response-Frame aus dem Access Point ausgewählt wird, um das Fast BSS Transition Information Element (hervorgehobenes Element) anzuzeigen. Einige der wichtigsten Informationen, die für die Durchführung des FT 4-Way-Handshakes erforderlich sind, werden ebenfalls angezeigt:

*apfMsConnTask_0: Jun 27 19:29:09.136: ec:85:2f:15:39:32
Association received from mobile on BSSID
84:78:ac:f0:68:d4

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Marking this mobile as TGr capable.

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile
ec:85:2f:15:39:32

*apfMsConnTask_0: Jun 27 19:29:09.137: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:68:d0-00
thread:144be808

*apfMsConnTask_0: Jun 27 19:29:09.137: Adding MDIE,
ID is:0xaaf0

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in Initial
assoc Resp to mobile

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Sending R0KH-ID as:-84.30.6.-3

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Sending R1KH-ID as 3c:ce:73:d8:02:00

*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Including FT IE (length 98) in Initial Assoc Resp to mobile

*apfMsConnTask_0: Jun 27 19:29:09.138: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d4
(status 0) ApVapId 5 Slot 0

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0

*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d4 to PMKID cache at
index 0 for station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: New PMKID: (16)

*dot1xMsgTask: Jun 27 19:29:09.142:
[0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Creating global PMK cache for this TGr client

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKMSK
ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
R0KH-ID:172.30.6.253 R1KH-ID:3c:ce:73:d8:02:00
MSK Len:48 pmkValidTime:1813

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Initiating RSN PSK to mobile ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d4 in
PMKID cache at index 0 of station ec:85:2f:15:39:32

*dot1xMsgTask: Jun 27 19:29:09.142: Including PMKID
in M1 (16)

*dot1xMsgTask: Jun 27 19:29:09.142:
[0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7

*dot1xMsgTask: Jun 27 19:29:09.143: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00

*apfMsConnTask_0: Jun 27 19:29:09.144: ec:85:2f:15:39:32
Got action frame from this client.

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.152: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Calculating PMKR0Name

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: Adding MDIE,
ID is:0xaaf0

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1813

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.154: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32

*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
Bei 802.11r wird die anfängliche Verknüpfung mit dem WLAN als Grundlage für die Ableitung der von dieser Technik verwendeten Basistasten verwendet, wie bei den anderen schnellen und sicheren Roaming-Methoden. Die Hauptunterschiede entstehen, wenn der Client zu roamen beginnt. FT vermeidet nicht nur 802.1X/EAP, wenn es verwendet wird, sondern führt tatsächlich eine effizientere Roaming-Methode durch, die die anfänglichen 802.11-Frames für die offene Systemauthentifizierung und die Neuzuordnung (die immer verwendet werden und beim Roaming zwischen APs erforderlich sind) kombiniert, um FT-Informationen auszutauschen und neue dynamische Verschlüsselungsschlüssel anstelle des 4-Wege-Handshake abzuleiten.

Da es sich auch bei WPA2-PSK um ein standardisiertes Verfahren handelt, funktioniert das alles herstellerübergreifend, wenn keine Fehler oder exotischen Aushandlungen in der Implementierung vorliegen.
Quelle: https://www.cisco.com/c/de_de/suppo...s-lan-wlan/116493-technote-technology-00.html

Und für eine manuelle Konfiguration dürften den üblichen Consumer-Geräten sowieso die entsprechenden Einstellungsmöglichkeiten fehlen.

Welche manuellen Einstellungsmöglichkeiten müssten denn dazu Consumer Geräte haben?
Ich kann dir da nicht ganz folgen, was man dazu einstellen können soll solange man sich außerhalb der 802.1X-EAP Welt befindet?

Zusammengefasst:

Vorteile mit 802.11r​

• Diese Methode ist die erste, die eine Schlüsselhierarchie verwendet, die durch IEEE auf dem 802.11-Standard als Änderung (802.11r) klar definiert ist, sodass die Implementierung dieser FT-Techniken zwischen Anbietern kompatibler ist und keine unterschiedlichen Interpretationen enthält.
• 802.11r unterstützt mehrere hilfreiche Techniken, die von Ihren Anforderungen abhängig sind (Over-the-Air- und Over-the-DS- für 802.1x/EAP-Sicherheit und PSK-Sicherheit).
• Der Wireless-Client führt ein schnelles und sicheres Roaming zu einem neuen WAP im selben WLAN/SSID durch, selbst wenn dieser nie mit diesem WAP verknüpft ist und ohne dass mehrere PMKIDs gespeichert werden müssen.
• Dies ist die erste sichere Methode für schnelles Roaming, die auch bei PSK-Sicherheit ein schnelleres Roaming ermöglicht und den 4-Wege-Handshake vermeidet, der beim Roaming zwischen APs mit WPA/WPA2 PSK erforderlich ist. Der Hauptzweck der schnelle und sichere Roaming-Methoden besteht darin, den 802.1X/EAP-Handshake zu vermeiden, wenn diese Sicherheitsmethode implementiert ist. Für die PSK-Sicherheit wird das Roaming-Ereignis mit 802.11r jedoch noch weiter beschleunigt, indem der 4-Wege-Handshake vermieden wird.

Verbinden mit 802.11r​

• Es gibt einige Wireless-Client-Geräte, die Fast BSS-Übergänge unterstützen, und in den meisten Fällen unterstützen sie nicht alle auf 802.11r verfügbaren Techniken.
• Da diese Implementierungen sehr jung sind, gibt es nicht genügend Testergebnisse aus realen Produktionsumgebungen oder genügend Debugergebnisse, um mögliche Probleme zu beheben, die auftreten könnten.
• Wenn Sie ein WLAN/SSID für die Verwendung einer der FT-Methoden konfigurieren, können nur Wireless-Clients, die 802.11r unterstützen, eine Verbindung zu diesem WLAN/SSID herstellen. Die FT-Einstellungen sind für die Clients nicht optional. Daher müssen die Wireless-Clients, die 802.11r nicht unterstützen, eine Verbindung mit einem separaten WLAN/SSID herstellen, wobei FT überhaupt nicht konfiguriert ist.

Adaptive 802.11r​

• Einige ältere Clients können keine Verbindung zu einem WLAN/SSID herstellen, bei dem 802.11r selbst für den "gemischten Modus" aktiviert ist (was Sie hoffen, auf denselben SSID-Clients verfügbar sein zu können, die 802.11r unterstützen und nicht unterstützen). Dies ist der Fall, wenn der Treiber der Client-Komponente, die für die Analyse des Robust Security Network Information Element (RSN IE) zuständig ist, alt ist und die zusätzlichen AKM-Suites im IE nicht kennt. Aufgrund dieser Einschränkung können Clients keine Zuordnungsanfragen an WLANs senden, die Unterstützung für 802.11r ankündigen. Daher müssen Sie wahrscheinlich ein WLAN/SSID für 802.11r-Clients und ein separates WLAN/SSID für Clients konfigurieren, die 802.11r nicht unterstützen.

Wen es noch interessiert, Ciscos Schlussfolgerungen daraus, denen ich soweit zustimme:

Schlussfolgerungen​

• Beachten Sie, dass der Client immer der Client ist, der sich für das Roaming zu einem bestimmten Access Point entscheidet, und der WLC/AP kann dies nicht für den Client entscheiden. Das Roaming-Ereignis wird vom Wireless-Client initiiert, sobald dieser dies für zweckmäßig hält.
• Der WLC unterstützt eine Kombination der meisten oder aller FSR-Methoden (Fast-Secure Roaming), die zusammen auf demselben WLAN/SSID ausgeführt werden. Beachten Sie jedoch, dass dies in der Regel nicht funktioniert, da es stark vom Client-Verhalten (sehr unterschiedlich über verschiedene Mobilgeräte hinweg) abhängig ist, um zu unterstützen oder sogar zu verstehen, dass der WLC versucht, als unterstützt anzukündigen. Anstatt die Interoperabilität in nur einer SSID zu erreichen, gibt es in der Regel mehr Probleme als die, die voraussichtlich behoben werden. Dies wird daher nicht empfohlen. Wenn dies wirklich erforderlich ist, sollten gründliche Tests mit allen möglichen Clients für dieses WLAN durchgeführt werden.
• Es ist sehr wichtig zu verstehen, dass schnelle und sichere Roaming-Methoden entwickelt werden, um den WLAN-Roaming-Prozess zu beschleunigen, wenn Sie zwischen WAPs wechseln, wenn die WLAN-/SSID-Funktion aktiviert ist. Wenn keine Sicherheit vorhanden ist, kann nichts beschleunigt werden, da der Client-AP einfach die Wireless-Management-Frames austauscht, die beim Roaming zwischen APs immer erforderlich sind, bevor Daten-Frames gesendet werden (offene Systemauthentifizierung vom Client, offene Systemauthentifizierung vom AP, Reassemblierungsanfrage und Reasso-Antwort). Daher kann sich dies nicht schneller bewegen. Wenn Roaming-Probleme ohne Sicherheit auftreten, gibt es keine Schnellroaming-Methoden zur Verbesserung des Roaming, sondern nur Methoden, um zu überprüfen, ob die WLAN/SSID-Einrichtung und das Design für die Wireless-Client-Stationen geeignet sind, dementsprechend zwischen den AP-Abdeckungszellen zu roamen.
• 802.11r/FT wird mit WPA2-PSK implementiert, um Roaming-Ereignisse mit dieser Sicherheit zu beschleunigen, indem der 4-Wege-Handshake vermieden wird, wie im Abschnitt zu 802.11r beschrieben.
• Alle Methoden haben ihre Vor- und Nachteile, aber am Ende müssen Sie immer überprüfen, ob die Wireless-Client-Stationen die spezifische Methode unterstützen, die Sie implementieren möchten, und ob die Cisco WLAN-Infrastruktur alle verfügbaren Methoden unterstützt. Daher müssen Sie die beste Methode auswählen, die tatsächlich von den Wireless-Clients unterstützt wird, die eine Verbindung zum spezifischen WLAN/SSID herstellen. In einigen Bereitstellungen können Sie beispielsweise ein WLAN/SSID mit CCKM für Cisco Wireless IP-Telefone (die WPA2/AES mit CCKM, aber nicht 802.11r unterstützen) und dann ein weiteres WLAN/SSID mit WPA2/AES über 802.11r/FT für Wireless-Clients erstellen, die diese sichere Roaming-Methode unterstützen (oder OKC verwenden) , wenn dies unterstützt wird).
• Wenn die Wireless-Clients keine der verfügbaren, schnell gesicherten Roaming-Methoden unterstützen, müssen Sie möglicherweise akzeptieren, dass diese Clients immer die in diesem Dokument beschriebenen Verzögerungen testen werden, wenn das Roaming zwischen APs auf einem WLAN/SSID mit 802.1X/EAP-Sicherheit erfolgt (dies kann zu Unterbrechungen der Client-Anwendungen/-Services führen).
• Alle Methoden, mit Ausnahme von SKC (WPA2 PMKID Caching), werden für schnelles und sicheres Roaming zwischen APs unterstützt, die von verschiedenen WLCs (Inter-Controller-Roaming) verwaltet werden, solange sie sich in derselben Mobilitätsgruppe befinden.
• CUWN unterstützt bei der Verwendung der 802.1X/EAP-Authentifizierung für WPA/WPA2 alle verschiedenen in diesem Artikel behandelten Fast-Secure Roaming-Methoden. CUWN unterstützt kein Fast-Secure Roaming auf Methoden, die mit WPA2-RSN (CCKM, PMKID Caching/SKC, OKC/PKC) arbeiten, wenn PSK (WPA2-Personal) verwendet wird, bei dem Fast-Roaming-Methoden meist nicht erforderlich sind. CUWN unterstützt jedoch Fast-Secure Roaming bei WPA2-FT (802.11r) mit PSK, wie in diesem Artikel beschrieben.

 

[0-8-15 User]

Cisco schreibt:

Einige ältere Clients können keine Verbindung zu einem WLAN/SSID herstellen

Ubiquiti schreibt:

Another very important fact is 802.11r requires client devices that either support or are aware of it. Older/outdated devices (e.g. barcode scanners, printers) will have issues connecting to a wireless network with this functionality enabled, so it can end-up creating more issues for you.

Wenn ich das lese, würde es mich ehrlich gesagt nicht wundern, wenn es eher die Ausnahme denn die Regel wäre, wenn 802.11r mit (einem Zoo aus) Consumergeräten funktionierte.

Da es sich auch bei WPA2-PSK um ein standardisiertes Verfahren handelt, funktioniert das alles herstellerübergreifend, wenn keine Fehler oder exotischen Aushandlungen in der Implementierung vorliegen.

Dann sollte es ja sehr einfach sein, wenigstens den Nachweis zu erbringen, dass die Verbindung beim Roaming zwischen zwei aktuellen Speed Homes oder zwei aktuellen FRITZ!Repeatern deutlich weniger als 400 ms lang unterbrochen wird.

 

[bender_]

zwei aktuellen FRITZ!Repeatern

Ich kenne kein AVM Produkt, dass offiziell 802.11r unterstützt.
Teste deinen Aufbau doch mal ohne die Fritz Repeater, vielleicht klappts ja dann mit Fast Transition.

 

[Engaged]

Ich kenne kein AVM Produkt, dass offiziell 802.11r unterstützt.
Teste deinen Aufbau doch mal ohne die Fritz Repeater, vielleicht klappts ja dann mit Fast Transition.

Dann wäre das ja die einzige top notch Changelog Meldung von der man aber nichts liest.
Alle wedeln sich ein auf wireguard während das neue qos für eingehenden traffic unbeachtet aber viel sinnvoller ist, und es sind auch jedes Mal Mesh Verbesserung in den changelogs aber oben genannter Standard wäre doch der einzige richtige boost. 🤷🏻‍♂️

Wäre das möglich diesen Standard nachträglich rein zu patchen oder Bedarf es da erst bestimmte Hardware?
Sonst müsste man AVM mal nerven dies umzusetzen!

 

[0-8-15 User]

Ich kenne kein AVM Produkt, dass offiziell 802.11r unterstützt.

Und wo steht, dass die Telekom Dinger 802.11r offiziell unterstützen?

Teste deinen Aufbau doch mal ohne die Fritz Repeater, vielleicht klappts ja dann mit Fast Transition.

Ich hatte noch nie ein Produkt von AVM in der Hand. Wenn bräuchte ich zwei Speed Homes, da es ja wie gesagt zwischen Speedport Pro und Speed Home WiFi ganz offenbar nicht klappt. Aber da ich für die Speed Homes - jenseits von der Befriedigung meines Spieltriebs - absolut keine Verwendung habe, werde ich wohl keinen weiteren anschaffen.

 

[bender_]

Dann wäre das ja die einzige top notch Changelog Meldung von der man aber nichts liest.

Das ist jetzt nicht so dramatisch, wie Du das darstellst. Ist ja nicht unmöglich, dass AVM Teile daraus oder eine proprietäre Methode zur Beschleunigung der Transition in ihrem "Mesh!" verwendet. Vielleicht geht es sogar soweit, dass eine Teilunterstützung davon implementiert ist - es scheint halt nicht komplett umgesetzt, sonst würde man es wohl ausweisen.
Könnte ja ähnlich wie beim CAT-iq Standard sein: https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7490/925_Unterstutzung-von-CAT-iq/

Ergänzung (27. Juni 2022)

Und wo steht, dass die Telekom Dinger 802.11r offiziell unterstützen?

Nirgends. Jedoch gibts ne Aussage einer "Fachabteilung" dass es gehen soll: https://telekomhilft.telekom.de/t5/Telefonie-Internet/Speedport-Pro-Wifi-Fast-Roaming/td-p/4214054#

 

[0-8-15 User]

Tut es ja aber ganz offenbar nicht und bevor jetzt die Aussage "dann probier es doch mit dem Speed Home WLAN" kommt, der war zum Zeitpunkt obiger Aussage der "Fachabteilung" noch nicht auf dem Markt.

 

[bender_]

Tut es ja aber ganz offenbar nicht

Richtig. Bei dir. In Zusammenspiel mit einem Surface 3. Hatten wir ja alles schon. Willst Du wieder von vorne anfangen?
Dann bitte zur Analyse die WireShark Auszüge des Surface 3 zur Transition posten. Welche Einträge relevant sind steht in #51. Da Du sonst hier im Forum der bist, der zu allen möglichen WLAN Themen Datensammlungen präsentiert, dürfte die Analyse an was es tatsächlich scheitert ein Leichtes für Dich sein. Dann hätten wir die Chance Fakten zu schaffen. Ich hab nur einen AP und kann deshalb keine Analyse durchführen. Weder meine Ausstattung noch mein Spieltrieb reicht für solch einen aufwändigen Nachweis aus.

Dass in der Praxis nicht alles so reibungslos läuft wie in der Theorie ist gerade im Kontext 802.11 jetzt keine wirkliche Überraschung. Da du nach eigener Aussage ja schon eine ganze Latte an Bugs im Speedport Pro gefunden hast, kannst Du das Ergebnis dieser Analyse ja noch dazupacken, sollte dabei rauskommen, dass der Speedport oder die APs Blödsinn machen...

 

[0-8-15 User]

dürfte die Analyse an was es tatsächlich scheitert ein Leichtes für Dich sein

In dem Fall schon, weil der Speedport Pro erst gar kein 802.11r anbietet:

 

[bender_]

Also kann ers nicht. Danke! Fakt geschaffen.
Denn das Surface 3 kanns auf jeden Fall: https://docs.microsoft.com/de-de/surface/surface-wireless-connect

Edith:
Hast Du noch nen Speed Home WLAN Zuhause? Wenn ja, könntest Du dort mal die Parameter auslesen. Laut Telekom kann der "Seamless Handover" was eine übliche Bezeichnung für 802.11r sein kann: https://www.telekom.de/hilfe/geraet...und störungsfreien Verbindungsqualität kommen.