Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

hagicgn
Beiträge: 67
Registriert: 21 Jun 2019, 12:26

Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von hagicgn »

Hallo zusammen,

ich habe einen LN-1700 und einen LX-6400 AP im Betrieb.
Auf dem LN-1700 läuft 10.72.0055 (beta), auf dem LX 6.10.0011RC1.

Die Authentifizierung läuft über den Radius-Server im 1781VA, die entsprechende SSID ist auf beiden APs mit WPA3 only, Standard & Fast-Roaming konfiguriert. Pre-Auth. und OKC sind auf beiden APs deaktiviert.
Ich nutze die dynamische VLAN-Vergabe über den Radius-Server.
Die Clients sind ein aktuelles Ipad Pro und ein Iphone 12, IOS 16.2 (beide Wifi-6).

Der jeweils empfangene Hash "Domain-ID" in Status/WLAN/IAPP-Table ist für die SSID auf beiden APs identisch.
Das Roaming vom LX-6400 -> LN 1700 klappt, im Log des 1700er steht "Fast transition for WLAN station <MAC> succeeded".
Anderesherum vom LN 1700 -> LX 6400 wird der Client nach einer kurzen Verbindung deauthentifiziert und weigert sich dann einige Minuten bevor er sich tatsächlich verbindet. Das Log im LX-6400 gibt leider keinen Aufschluss.

Mit der aktuellen FW LX 5.38.0084Rel klappt das Roaming in beide Richtungen.

Generell ist die Verbindung der Clients unter der 5.38er FW nicht sehr stabil, beim Messenger dreht sich öfter der Wartekreisel und gelegentlich hakeln Webseiten. Ein kurzes Deaktivieren des WLANs auf dem Client korrigiert den Fehler wieder für eine zeitlang.
Dieses Verhalten zeigen die Clients nur, wenn sie auf dem LX-6400 eingebucht sind, auf dem LN-1700 läuft es tadellos.

Das als Feedback zum aktuellen Release-Candidate (bevor er zum Release wird :wink: )

VG
Dirk
hagicgn
Beiträge: 67
Registriert: 21 Jun 2019, 12:26

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von hagicgn »

Hallo zusammen,

die Schwierigkeiten mit der 5.38 Fw scheinen an der Konvertierung von Multicast -> Unicast zu liegen.
Das Snooping-Modul hatte ich aktiviert und dachte auch bisher, den IGMP Querier korrekt konfuguriert zu haben. Jedenfalls klappte mit dem alten Lancom L-1302 AP an gleicher Stelle alles korrekt.
Die Tabelle im Status/Multicast-Snooping des LX 6400 ist immer leer.
Zudem tauchen auch im Dashboard einige Clients mit IP 0.0.0.0 und Modus unknown auf. Der Spuk endet, sobald ich die Konverteirung auf Unicast abschalte.

Hat einer von euch dazu eine Idee?

Danke + VG
Dirk
Drakoo
Beiträge: 2
Registriert: 13 Jan 2023, 10:21

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von Drakoo »

hagicgn hat geschrieben: 30 Dez 2022, 20:33 Hallo zusammen,

ich habe einen LN-1700 und einen LX-6400 AP im Betrieb.
Auf dem LN-1700 läuft 10.72.0055 (beta), auf dem LX 6.10.0011RC1.

Die Authentifizierung läuft über den Radius-Server im 1781VA, die entsprechende SSID ist auf beiden APs mit WPA3 only, Standard & Fast-Roaming konfiguriert. Pre-Auth. und OKC sind auf beiden APs deaktiviert.
Ich nutze die dynamische VLAN-Vergabe über den Radius-Server.
Die Clients sind ein aktuelles Ipad Pro und ein Iphone 12, IOS 16.2 (beide Wifi-6).

Der jeweils empfangene Hash "Domain-ID" in Status/WLAN/IAPP-Table ist für die SSID auf beiden APs identisch.
Das Roaming vom LX-6400 -> LN 1700 klappt, im Log des 1700er steht "Fast transition for WLAN station <MAC> succeeded".
Anderesherum vom LN 1700 -> LX 6400 wird der Client nach einer kurzen Verbindung deauthentifiziert und weigert sich dann einige Minuten bevor er sich tatsächlich verbindet. Das Log im LX-6400 gibt leider keinen Aufschluss.

Mit der aktuellen FW LX 5.38.0084Rel klappt das Roaming in beide Richtungen.

Generell ist die Verbindung der Clients unter der 5.38er FW nicht sehr stabil, beim Messenger dreht sich öfter der Wartekreisel und gelegentlich hakeln Webseiten. Ein kurzes Deaktivieren des WLANs auf dem Client korrigiert den Fehler wieder für eine zeitlang.
Dieses Verhalten zeigen die Clients nur, wenn sie auf dem LX-6400 eingebucht sind, auf dem LN-1700 läuft es tadellos.

Das als Feedback zum aktuellen Release-Candidate (bevor er zum Release wird :wink: )

VG
Dirk
Hallo Dirk,

vielen Dank für das Feedback, wir konnten Problem feststellen und es wurde für die REL Version gefixt.

Viele Grüße
Jörg
tstimper
Beiträge: 975
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von tstimper »

Drakoo hat geschrieben: 09 Feb 2023, 10:26
Hallo Dirk,

vielen Dank für das Feedback, wir konnten Problem feststellen und es wurde für die REL Version gefixt.

Viele Grüße
Jörg
Hallo Jörg,

baut Ihr OpenSSL 1.1.1t gleich mit ein?

Ich habe hier 160 * LX-6400, die warten drauf, gepatcht zu werden :D

Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
hagicgn
Beiträge: 67
Registriert: 21 Jun 2019, 12:26

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von hagicgn »

hagicgn hat geschrieben: 13 Jan 2023, 01:26 Hallo zusammen,

die Schwierigkeiten mit der 5.38 Fw scheinen an der Konvertierung von Multicast -> Unicast zu liegen.
Das Snooping-Modul hatte ich aktiviert und dachte auch bisher, den IGMP Querier korrekt konfuguriert zu haben. Jedenfalls klappte mit dem alten Lancom L-1302 AP an gleicher Stelle alles korrekt.
Die Tabelle im Status/Multicast-Snooping des LX 6400 ist immer leer.
Zudem tauchen auch im Dashboard einige Clients mit IP 0.0.0.0 und Modus unknown auf. Der Spuk endet, sobald ich die Konverteirung auf Unicast abschalte.

Hat einer von euch dazu eine Idee?

Danke + VG
Dirk
Ich hatte zwischenzeitlich etwas experimentiert. Der LX-6400 verhält sich hier anders, als die LCOS-Geräte.
Ich habe zu Hause Yamaha Musiccast-Lautsprecher, die nicht richtig funktionieren, wenn sie am Lx-6400 eingebucht sind (V 5.38 Rel)
Auch Apples Airplay findet die Lautsprecher dann nicht.
Die Lautsprecher sind zwar in einer anderen SSID eingebucht (WPA2-personal, Auth über Radius mit Leps-Mac),
aber im gleichen Subnetz wie z.B. das Ipad.
Sind die Lautsprecher am LN 1700 eingebucht, funktioniert alles, auch wenn das iPad am LX-6400 eingebucht ist.
Mit dem früheren L-1302 lief die gleiche Konfig problemlos.
hagicgn
Beiträge: 67
Registriert: 21 Jun 2019, 12:26

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.12rel

Beitrag von hagicgn »

Hallo zusammen,

ich krame den Thread nochmal hervor.
Den alten 1302er habe ich aussortiert und durch einen LN-1702B ersetzt.
Konfig ist noch WPA3 mit 802.1x über den Radiusserver im 1781VA.

Das Fast-Roaming zwischen einem LN-1700 und dem LN-1702B klappt tadellos. Beide 10.72.0291RU4.
Versuche ich das Fast-Roaming mit dem LX-6400 (6.12.0024Rel) und dem o.g. LN-1700, meldet der LN-1700 invalid MDIE.
Andersherum (LN1700->LX-6400) verbindet sich der Client erst nach einem Trennen erneut wieder.

Die Hashes in der IAPP-Table sind für die jeweilige SSID auf beiden APs identisch. Beide APs "sehen" sich entsprechend.
Für mein Verständnis sollte die Konfig der SSIDs dann nahezu idetisch sein, oder? Pre-Auth ist auf beiden APs eingeschaltet. Muss ich in der Network-Konfig beim LX-6400 noch etwas unter mobility Domain eintragen?

Ein WLC ist nicht im Netz.
Hat noch jemand eine Idee? :-)
Zuletzt geändert von hagicgn am 20 Aug 2023, 21:06, insgesamt 1-mal geändert.
jfuchs
Beiträge: 66
Registriert: 19 Feb 2023, 00:20
Wohnort: Plauen i.V.

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von jfuchs »

hagicgn hat geschrieben: 27 Jul 2023, 23:17 Versuche ich das Fast-Roaming mit dem LX-6400 (6.12.0024Rel) und dem o.g. LN-1700, meldet der LN-1700 invalid MDIE.
Andersherum (LN1700->LX-6400) verbindet sich der Client erst nach einem Trennen erneut wieder.
Das klingt so als ob es in beide Richtungen gar nicht funktioniert, ja. Wenn es erst nach dem Trennen funktioniert vollführt er danach eine vollständige 802.1X Authentifizierung die du ja dank Fast-Roaming umgehen/beschleunigen möchtest.

Bist du technisch in der Lage ein Packet Capture (Wireshark, oder per Onboard-Tools bspw. im Webinterface in LX -> Diagnose -> Packet-Capturing und LCOS) anzufertigen von diesem Verhalten? Mir würde das Association Request + Response (wo die Ablehnung mit "Invalid MDIE" drin steht) sowie einem Beacon von dem AP reichen. Am besten von beiden APs. Dann kann man das Mobility Domain Information Element (MDIE) miteinander vergleichen und schauen was voneinander abweicht.
hagicgn hat geschrieben: 27 Jul 2023, 23:17 Die Hashes in der IAPP-Table sind für die jeweilige SSID auf beiden APs identisch. Beide APs "sehen" sich entsprechend.
Für mein Verständnis sollte die Konfig der SSIDs dann nahezu idetisch sein, oder? Pre-Auth ist auf beiden APs eingeschaltet.
Die Konfiguration beider SSIDs muss identisch sein. Ich hab vergessen wie die Mobility Domain ID bei LANCOM berechnet wurde - aber ich erinnere mich düster, dass das auf Basis des Netzwerk-Namens war (der identisch sein muss!). Ich weiß aber noch, dass das damals bei mir auf jedenfall zwischen LCOS <-> LCOS-LX tadellos funktioniert hat (auch mit 802.1X).
hagicgn hat geschrieben: 27 Jul 2023, 23:17 Muss ich in der Network-Konfig beim LX-6400 noch etwas unter mobility Domain eintragen?
Ich wüsste gerade nicht wo du da was eintragen willst. Kannst du vielleicht mal genauer zeigen (Screenshot oder so) was du meinst? :D Gern auch weitere Konfigurations-Einstellungen.
ua
Beiträge: 707
Registriert: 29 Apr 2005, 12:29

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von ua »

Hi,

Bislang gab es m.W. Probleme mit Fastroaming.
Gibt aber eine neue Version:
https://my.lancom-systems.de/download/d ... Rel_DE.pdf

VG
... das Netz ist der Computer ...
n* LC und vieles mehr...
jfuchs
Beiträge: 66
Registriert: 19 Feb 2023, 00:20
Wohnort: Plauen i.V.

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von jfuchs »

ua hat geschrieben: 28 Jul 2023, 16:27 Bislang gab es m.W. Probleme mit Fastroaming.
Gibt aber eine neue Version:
https://my.lancom-systems.de/download/d ... Rel_DE.pdf
Er hat bereits geschrieben gehabt, dass er diese genau Version (6.12REL) nutzt. Soweit mir bekannt ging es dabei auch um den Austausch der PMKs via IAPP. Da würde ich dann einen anderen Fehler als"Invalid MDIE" erwarten (bspw. PMK mismatch oder sowas ähnliches).
hagicgn hat geschrieben: 27 Jul 2023, 23:17 Versuche ich das Fast-Roaming mit dem LX-6400 (6.12.0024Rel) [..]
ua
Beiträge: 707
Registriert: 29 Apr 2005, 12:29

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von ua »

sorry, hatte ich überlesen.
Hat tatsächlich nichts mit einander zu tuen 😳
Am besten bei Lancom ein Ticket erstellen.
... das Netz ist der Computer ...
n* LC und vieles mehr...
hagicgn
Beiträge: 67
Registriert: 21 Jun 2019, 12:26

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.12rel

Beitrag von hagicgn »

Hallo zusammen,

es ist etwas mühsam, da zumindest das Fast-Roaming mit einer früheren Version des LX schon funktioniert hat.
hagicgn hat geschrieben: 30 Dez 2022, 20:33 Mit der aktuellen FW LX 5.38.0084Rel klappt das Roaming in beide Richtungen.
Man fängt leider immer wieder von vorne an. Ich habe heute weiter experimentiert, und die Pre-Auth auf beiden APs deaktiviert.
Das bringt auch nichts.

Mit Pre-Auth sieht es so aus:

Workflow:
1) Iphone Wlan-Verbindung aus
2) Iphone in die Nähe des LX-6400 bringen
3) Iphone Wlan einschalten -> Iphone bucht sich am LX-6400 ein
3a) Ich sehe, dass bei dieser Erstanmeldung am LX-6400 das PMK in der Tabelle des LN-1700 (Status/Wlan/PMK-Caching) gespiegelt wird, Quelle IAPP,
es sind zwei Einträge (für die beiden Radios 2,4 und 5 GHz), Mobility Domain 56005 (0xDAC5)
4) Mit dem Iphone in den Bereich des LN-1700 laufen.
4a) Beim Roamingversuch scheitert es dann wie erwähnt am der falschen MDIE (Logeintrag am LN-1700).
5) die vollständige 802.1.x-Anmeldung läuft durch.

Kann ich die errechnete Mobility Domain irgendwo beim LX-6400 einsehen? Dann wäre das Debuggen einfacher. Ich habe bisher nichts gefunden.

Folgend der Trace auf dem LN-1700 beim Roamingversuch:
(Die MACs habe ich mit xx:xx:xx versehen).

Code: Alles auswählen

[WLAN-DATA] 2023/07/29 19:33:51,055  Devicetime: 2023/07/29 19:33:49,223
Received frame from address 98:60:ca:xx:xx:xx (Apple xx:xx:xx) on WLAN-2:
-->Orig Length:    205 bytes
-->Rate:           6M
-->Signal:         -52 dBm
-->Chain Signals:  1/14/-64/-44 dBm
-->Noise:          -105 dBm
-->Chain Noises:   -105/-105/-105/-105 dBm
-->IEEE 802.11 Header
Protocol Version    : 0
Flags               :
Type                : Mgmt
Subtype             : Authenticate
Duration            : 003c
Address1 [DA ]      : 00:a0:57:xx:xx:xx (LANCOM xx:xx:xx)
Address2 [SA ]      : 98:60:ca:xx:xx:xx(Apple xx:xx:xx)
Address3 [BSS]      : 00:a0:57:xx:xx:xx(LANCOM xx:xx:xx)
Sequence Number     : 346
Fragment Number     : 0
-->802.11 Management Frame:
Algorithm           : Fast Transition
Trans. SeqNum       : 1
Status Code         : Successful
RSN Cipher Info     : Version 1
                      Group Cipher TGI-CSE-CCMP128
                      Pairwise Ciphers TGI-CSE-CCMP128
                      Authentication Selectors TGI-AUTHSE-8021X-FT
                      Capabilities: Mgmt-Frame-Prot-Req Mgmt-Frame-Prot-Supp 16 PTKSA replay counters 1 GTKSA replay counters
                      PMK IDs 0ed50c14cabfb2a2a5b37a6a9a8c5b6f
Mobility Domain     : ID 0xdac5
Fast BSS Transition :
 Flags              :
 MIC Count          : 0
 MIC                : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
 ANonce             : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
 SNonce             : f8 58 c0 2b d2 11 b8 16 .X.+....
                      3d 9f 3e 35 3a ef f0 d7 =.>5:...
                      19 39 57 59 6f 64 64 48 .9WYoddH
                      ef a4 31 85 c0 6f d9 ba ..1..o..
 R0KH-ID            : fake R0KH
Ext. Capabilities   : BSS-Transition Operating-Mode-Notification
Vendor Specific     : 00:17:f2 (Apple) Type 10
<trailer>           : 00 01 04 00 00 00 00    .......
Vendor Specific     : 00:10:18 (Broadcom) Type 2
<trailer>           : 01 00 10 00 00 02       ......

[WLAN-FT] 2023/07/29 19:33:51,066  Devicetime: 2023/07/29 19:33:49,224
Handle FT auth request from 98:60:ca:xx:xx:xx (Apple xx:xx:xx):
-> MDE mismatch, rejecting request

[WLAN-DATA] 2023/07/29 19:33:51,066  Devicetime: 2023/07/29 19:33:49,224
Send frame to address 98:60:ca:xx:xx:xx (Apple xx:xx:xx) on WLAN-2:
-->Orig Length:    30 bytes
-->IEEE 802.11 Header
Protocol Version    : 0
Flags               :
Type                : Mgmt
Subtype             : Authenticate
Duration            : 0000
Address1 [DA ]      : 98:60:ca:xx:xx:xx (Apple xx:xx:xx)
Address2 [SA ]      : 00:a0:57:xx:xx:xx (LANCOM xx:xx:xx)
Address3 [BSS]      : 00:a0:57:xx:xx:xx (LANCOM xx:xx:xx)
Sequence Number     : 0
Fragment Number     : 0
-->802.11 Management Frame:
Algorithm           : Fast Transition
Trans. SeqNum       : 2
Status Code         : Invalid MDIE
IAPP-Passphrase usw. sind selbstverständlich identisch. Wie gesagt, zumindest das FR hatte schon mal funktioniert. Dafür gingen andere Dinge nicht, so dass der LX-6400 erstmal in den Schrank gewandert ist.
Ich habe auf dem LX-6400 ein Capture der entsprechenden SSID laufen lassen und mit Wireshark angesehen. Wonach muss ich da suchen? Ich habe erstmal nichts über einen Anmeldeversuch gefunden. Auf der Konsole hatte ich vorher den Trace für WLAN und IAPP eingeschaltet.

Da ich die Geräte als Privatperson gekauft habe, bin ich beim Lancom-Support am Anfang der Nahrungskette. Vermutlich wird eher ein AP mit WIFI-7 released, als dass mein Ticket bearbeitet wird. :? (Sorry, der Kommentar ist nicht hilfreich, aber meine letzte Kontaktaufnahme ist dort im Sande verlaufen).

Hier gibt es das Feld für die Mobility Domain. Ich vermute mal, die wird in HEX erwartet, da das Feld keine 5-Ziffern akzeptiert.
Bringt aber auch nichts, außer das Lanconfig (10.80.0010 RC2) dann beim Senden der Konfig crasht.
MDomain.png
VG
Dirk
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von hagicgn am 20 Aug 2023, 14:06, insgesamt 1-mal geändert.
jfuchs
Beiträge: 66
Registriert: 19 Feb 2023, 00:20
Wohnort: Plauen i.V.

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von jfuchs »

hagicgn hat geschrieben: 29 Jul 2023, 20:20 3a) Ich sehe, dass bei dieser Erstanmeldung am LX-6400 das PMK in der Tabelle des LN-1700 (Status/Wlan/PMK-Caching) gespiegelt wird, Quelle IAPP,
es sind zwei Einträge (für die beiden Radios 2,4 und 5 GHz), Mobility Domain 56005 (0xDAC5)
Das hast du soweit schon mal korrekt ermittelt: die Mobility Domain ist 0xdac5, wie auch aus deinem Trace vom LN-1700 hervorgeht.
hagicgn hat geschrieben: 29 Jul 2023, 20:20 Kann ich die errechnete Mobility Domain irgendwo beim LX-6400 einsehen? Dann wäre das Debuggen einfacher. Ich habe bisher nichts gefunden.
Über den Umweg auf dem LN-1700 unter "ls /Status/WLAN/IAPP-Table/" müsste in der Spalte "Domain-ID" diese für den LX-6400 stehen. Ebenso vice versa auf dem LX-6400 die vom LN-1700.
hagicgn hat geschrieben: 29 Jul 2023, 20:20 Ich habe auf dem LX-6400 ein Capture der entsprechenden SSID laufen lassen und mit Wireshark angesehen. Wonach muss ich da suchen? Ich habe erstmal nichts über einen Anmeldeversuch gefunden. Auf der Konsole hatte ich vorher den Trace für WLAN und IAPP eingeschaltet.
Wenn du als Capture-Mode "Rawmodus" auswählst muss das Authenticate und das (Re-) Association Request vom Apple (Client) zu sehen sein (Wireshark-Filter für das Apple-Gerät: "((wlan.fc.type_subtype == 0x000b) || (wlan.fc.type_subtype == 0x0000)) && wlan.addr[0:3] == 98:60:ca"). Im "normalen" Capture-Modus ist dies nicht der Fall - dieser enthält größtenteils nur Datenframes.
hagicgn hat geschrieben: 29 Jul 2023, 20:20 Hier gibt es das Feld für die Mobility Domain. Ich vermute mal, die wird in HEX erwartet, da das Feld keine 5-Ziffern akzeptiert.
Bringt aber auch nichts, außer das Lanconfig (10.80.0010 RC2) dann beim Senden der Konfig crasht.
Ja die MDIE ist in Hex anzugeben afaik. Probiere es alternativ bitte nicht über LANconfig sondern per SSH/CLI. Das LANconfig crasht klingt nach einem Bug für mich.

Nachtrag:
hagicgn hat geschrieben: 29 Jul 2023, 20:20 Da ich die Geräte als Privatperson gekauft habe, bin ich beim Lancom-Support am Anfang der Nahrungskette.
Ich glaube das du hier an der besseren Adresse bist (besonders falls alf29 noch mitliest). Ohne mich jetzt selber in den Vordergrund zu drängen: ich hab damals eine recht flexible Test-Automatisierung in meiner Zeit als Angesteller bei LANCOM geschrieben die genau das was du machst in wenigen Sekunden konfiguriert und auf Funktionaltität prüft. Leider habe ich nun kein 802.1X Setup mit FT mehr um das konkret nachzustellen. Alles was ich bräuchte lieferst du mir zum Teil schon, am Besten wären Wireshark Captures von den Beacons beider APs und auch Authenticates/Association Requests & Responses. Dann könnte ich die RSN Information Elemente etc. vergleichen und dir sagen, ob etwas (unbewusst) unterschiedlich konfiguriert ist oder ob hier ein Fehler im LCOS/LX vorliegt. Deine Anonymisierung bzw. das du die Captures mit den MAC-Adressen nicht öffentlich posten möchtest ist zu respektieren und auch richtig. Ich kann dir nur anbieten das du mir die privat noch senden könntest.
hagicgn
Beiträge: 67
Registriert: 21 Jun 2019, 12:26

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.12rel

Beitrag von hagicgn »

Ich danke euch für eure Hilfe, bis zum Wochenende bin ich im Urlaub. Nächste Woche baue ich das Testszenario nochmal auf.
Zuletzt geändert von hagicgn am 20 Aug 2023, 14:06, insgesamt 1-mal geändert.
hagicgn
Beiträge: 67
Registriert: 21 Jun 2019, 12:26

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von hagicgn »

So, da bin ich wieder, sorry, es hat etwas länger gedauert.

Ich habe den Paket-Capture auf der 5GHz Schnittstelle im RAW Modus laufen lassen und deinen Filterausdruck in Wireshark eingegeben.
Vorweg: Ich hatte zwischen durch auch das Fast-Roaming over DS im LCOS-AP deaktiviert, das änderte auch nichts.

Filter:
((wlan.fc.type_subtype == 0x000b) || (wlan.fc.type_subtype == 0x0000)) && wlan.addr[0:3] == 98:60:ca

Code: Alles auswählen

Frame 7683: 253 bytes on wire (2024 bits), 253 bytes captured (2024 bits)
    Encapsulation type: IEEE 802.11 plus radiotap radio header (23)
    Arrival Time: Aug 17, 2023 18:26:45.835104000 Mitteleuropäische Sommerzeit
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1692289605.835104000 seconds
    [Time delta from previous captured frame: 0.030139000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 73.225693000 seconds]
    Frame Number: 7683
    Frame Length: 253 bytes (2024 bits)
    Capture Length: 253 bytes (2024 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: radiotap:wlan_radio:wlan]
Radiotap Header v0, Length 48
    Header revision: 0
    Header pad: 0
    Header length: 48
    Present flags
        Present flags word: 0x4000086f
            .... .... .... .... .... .... .... ...1 = TSFT: Present
            .... .... .... .... .... .... .... ..1. = Flags: Present
            .... .... .... .... .... .... .... .1.. = Rate: Present
            .... .... .... .... .... .... .... 1... = Channel: Present
            .... .... .... .... .... .... ...0 .... = FHSS: Absent
            .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: Present
            .... .... .... .... .... .... .1.. .... = dBm Antenna Noise: Present
            .... .... .... .... .... .... 0... .... = Lock Quality: Absent
            .... .... .... .... .... ...0 .... .... = TX Attenuation: Absent
            .... .... .... .... .... ..0. .... .... = dB TX Attenuation: Absent
            .... .... .... .... .... .0.. .... .... = dBm TX Power: Absent
            .... .... .... .... .... 1... .... .... = Antenna: Present
            .... .... .... .... ...0 .... .... .... = dB Antenna Signal: Absent
            .... .... .... .... ..0. .... .... .... = dB Antenna Noise: Absent
            .... .... .... .... .0.. .... .... .... = RX flags: Absent
            .... .... .... .... 0... .... .... .... = TX flags: Absent
            .... .... .... ..0. .... .... .... .... = data retries: Absent
            .... .... .... .0.. .... .... .... .... = Channel+: Absent
            .... .... .... 0... .... .... .... .... = MCS information: Absent
            .... .... ...0 .... .... .... .... .... = A-MPDU Status: Absent
            .... .... ..0. .... .... .... .... .... = VHT information: Absent
            .... .... .0.. .... .... .... .... .... = frame timestamp: Absent
            .... .... 0... .... .... .... .... .... = HE information: Absent
            .... ...0 .... .... .... .... .... .... = HE-MU information: Absent
            .... .0.. .... .... .... .... .... .... = 0 Length PSDU: Absent
            .... 0... .... .... .... .... .... .... = L-SIG: Absent
            ...0 .... .... .... .... .... .... .... = TLVs: Absent
            ..0. .... .... .... .... .... .... .... = Radiotap NS next: False
            .1.. .... .... .... .... .... .... .... = Vendor NS next: True
            0... .... .... .... .... .... .... .... = Ext: Absent
    MAC timestamp: 579600250
    Flags: 0x00
        .... ...0 = CFP: False
        .... ..0. = Preamble: Long
        .... .0.. = WEP: False
        .... 0... = Fragmentation: False
        ...0 .... = FCS at end: False
        ..0. .... = Data Pad: False
        .0.. .... = Bad FCS: False
        0... .... = Short GI: False
    Data Rate: 6,0 Mb/s
    Channel frequency: 5320 [A 64]
    Channel flags: 0x0140, Orthogonal Frequency-Division Multiplexing (OFDM), 5 GHz spectrum
        .... .... .... ...0 = 700 MHz spectrum: False
        .... .... .... ..0. = 800 MHz spectrum: False
        .... .... .... .0.. = 900 MHz spectrum: False
        .... .... ...0 .... = Turbo: False
        .... .... ..0. .... = Complementary Code Keying (CCK): False
        .... .... .1.. .... = Orthogonal Frequency-Division Multiplexing (OFDM): True
        .... .... 0... .... = 2 GHz spectrum: False
        .... ...1 .... .... = 5 GHz spectrum: True
        .... ..0. .... .... = Passive: False
        .... .0.. .... .... = Dynamic CCK-OFDM: False
        .... 0... .... .... = Gaussian Frequency Shift Keying (GFSK): False
        ...0 .... .... .... = GSM (900MHz): False
        ..0. .... .... .... = Static Turbo: False
        .0.. .... .... .... = Half Rate Channel (10MHz Channel Width): False
        0... .... .... .... = Quarter Rate Channel (5MHz Channel Width): False
    Antenna signal: -59 dBm
    Antenna noise: -107 dBm
    Antenna: 0
    Vendor namespace: AtherosC-0
        Vendor OUI: 00:03:7f (Atheros Communication
        Vendor sub namespace: 0
        Vendor data length: 16
        Vendor data
802.11 radio information
    PHY type: 802.11a (OFDM) (5)
    Turbo type: Non-turbo (0)
    Data rate: 6,0 Mb/s
    Channel: 64
    Frequency: 5320MHz
    Signal strength (dBm): -59 dBm
    Noise level (dBm): -107 dBm
    Signal/noise ratio (dB): 48 dB
    TSF timestamp: 579600250
    [Duration: 300µs]
        [Preamble: 20µs]
        [IFS: 29016µs]
        [Start: 579599950µs]
        [End: 579600250µs]
IEEE 802.11 Authentication, Flags: ........
    Type/Subtype: Authentication (0x000b)
    Frame Control Field: 0xb000
        .... ..00 = Version: 0
        .... 00.. = Type: Management frame (0)
        1011 .... = Subtype: 11
        Flags: 0x00
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x0)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = +HTC/Order flag: Not strictly ordered
    .000 0000 0011 1100 = Duration: 60 microseconds
    Receiver address: 06:a0:57:73:YY:YY (06:a0:57:73:YY:YY)
    Destination address: 06:a0:57:73:YY:YY (06:a0:57:73:YY:YY)
    Transmitter address: Apple_26:XX:XX (98:60:ca:26:XX:XX)
    Source address: Apple_26:XX:XX (98:60:ca:26:XX:XX)
    BSS Id: 06:a0:57:73:YY:YY (06:a0:57:73:YY:YY)
    .... .... .... 0000 = Fragment number: 0
    1011 1111 0011 .... = Sequence number: 3059
IEEE 802.11 Wireless Management
    Fixed parameters (6 bytes)
        Authentication Algorithm: Fast BSS Transition (2)
        Authentication SEQ: 0x0001
        Status code: Successful (0x0000)
    Tagged parameters (175 bytes)
        Tag: RSN Information
            Tag Number: RSN Information (48)
            Tag length: 38
            RSN Version: 1
            Group Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
                Group Cipher Suite OUI: 00:0f:ac (Ieee 802.11)
                Group Cipher Suite type: AES (CCM) (4)
            Pairwise Cipher Suite Count: 1
            Pairwise Cipher Suite List 00:0f:ac (Ieee 802.11) AES (CCM)
                Pairwise Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
                    Pairwise Cipher Suite OUI: 00:0f:ac (Ieee 802.11)
                    Pairwise Cipher Suite type: AES (CCM) (4)
            Auth Key Management (AKM) Suite Count: 1
            Auth Key Management (AKM) List 00:0f:ac (Ieee 802.11) FT over IEEE 802.1X
                Auth Key Management (AKM) Suite: 00:0f:ac (Ieee 802.11) FT over IEEE 802.1X
                    Auth Key Management (AKM) OUI: 00:0f:ac (Ieee 802.11)
                    Auth Key Management (AKM) type: FT over IEEE 802.1X (3)
            RSN Capabilities: 0x00cc
                .... .... .... ...0 = RSN Pre-Auth capabilities: Transmitter does not support pre-authentication
                .... .... .... ..0. = RSN No Pairwise capabilities: Transmitter can support WEP default key 0 simultaneously with Pairwise key
                .... .... .... 11.. = RSN PTKSA Replay Counter capabilities: 16 replay counters per PTKSA/GTKSA/STAKeySA (0x3)
                .... .... ..00 .... = RSN GTKSA Replay Counter capabilities: 1 replay counter per PTKSA/GTKSA/STAKeySA (0x0)
                .... .... .1.. .... = Management Frame Protection Required: True
                .... .... 1... .... = Management Frame Protection Capable: True
                .... ...0 .... .... = Joint Multi-band RSNA: False
                .... ..0. .... .... = PeerKey Enabled: False
                ..0. .... .... .... = Extended Key ID for Individually Addressed Frames: Not supported
            PMKID Count: 1
            PMKID List
                PMKID: ac1a3262b6b9a030b5454bdf82bf7c5f
        Tag: Mobility Domain
            Tag Number: Mobility Domain (54)
            Tag length: 3
            Mobility Domain Identifier: 0xdac5
            FT Capability and Policy: 0x01
                .... ...1 = Fast BSS Transition over DS: 0x1
                .... ..0. = Resource Request Protocol Capability: 0x0
                0000 00.. = Reserved: 0x00
        Tag: Fast BSS Transition
            Tag Number: Fast BSS Transition (55)
            Tag length: 93
            MIC Control: 0x0000
                .... .... 0000 0000 = Reserved: 0x00
                0000 0000 .... .... = Element Count: 0
            MIC: 00000000000000000000000000000000
            ANonce: 0000000000000000000000000000000000000000000000000000000000000000
            SNonce: 94388b45ac4df7681d205dd3617eb7d6054743ff083cfaad160ebf3b81c0a34f
            Subelement: PMK-R0 key holder identifier (R0KH-ID)
                Subelement ID: PMK-R0 key holder identifier (R0KH-ID) (3)
                Length: 9
                PMK-R0 key holder identifier (R0KH-ID): 66616b652052304b48
        Tag: Extended Capabilities (8 octets)
            Tag Number: Extended Capabilities (127)
            Tag length: 8
            Extended Capabilities: 0x00 (octet 1)
                .... ...0 = 20/40 BSS Coexistence Management Support: Not supported
                .... ..0. = Reserved (was On-demand beacon): 0x0
                .... .0.. = Extended Channel Switching: Not supported
                .... 0... = Reserved (was WAVE indication): 0x0
                ...0 .... = PSMP Capability: Not supported
                ..0. .... = Reserved: 0x0
                .0.. .... = S-PSMP Support: Not supported
                0... .... = Event: Not supported
            Extended Capabilities: 0x00 (octet 2)
                .... ...0 = Diagnostics: Not supported
                .... ..0. = Multicast Diagnostics: Not supported
                .... .0.. = Location Tracking: Not supported
                .... 0... = FMS: Not supported
                ...0 .... = Proxy ARP Service: Not supported
                ..0. .... = Collocated Interference Reporting: Not supported
                .0.. .... = Civic Location: Not supported
                0... .... = Geospatial Location: Not supported
            Extended Capabilities: 0x08 (octet 3)
                .... ...0 = TFS: Not supported
                .... ..0. = WNM Sleep Mode: Not supported
                .... .0.. = TIM Broadcast: Not supported
                .... 1... = BSS Transition: Supported
                ...0 .... = QoS Traffic Capability: Not supported
                ..0. .... = AC Station Count: Not supported
                .0.. .... = Multiple BSSID: Not supported
                0... .... = Timing Measurement: Not supported
            Extended Capabilities: 0x00 (octet 4)
                .... ...0 = Channel Usage: Not supported
                .... ..0. = SSID List: Not supported
                .... .0.. = DMS: Not supported
                .... 0... = UTC TSF Offset: Not supported
                ...0 .... = TPU Buffer STA Support: Not supported
                ..0. .... = TDLS Peer PSM Support: Not supported
                .0.. .... = TDLS channel switching: Not supported
                0... .... = Interworking: Not supported
            Extended Capabilities: 0x00 (octet 5)
                .... ...0 = QoS Map: Not supported
                .... ..0. = EBR: Not supported
                .... .0.. = SSPN Interface: Not supported
                .... 0... = Reserved: 0x0
                ...0 .... = MSGCF Capability: Not supported
                ..0. .... = TDLS Support: Not supported
                .0.. .... = TDLS Prohibited: Not supported
                0... .... = TDLS Channel Switching Prohibited: Not supported
            Extended Capabilities: 0x00 (octet 6)
                .... ...0 = Reject Unadmitted Frame: Not supported
                .... 000. = Service Interval Granularity: 5 ms (0)
                ...0 .... = Identifier Location: Not supported
                ..0. .... = U-APSD Coexistence: Not supported
                .0.. .... = WNM Notification: Not supported
                0... .... = QAB Capability: 0x0
            Extended Capabilities: 0x00 (octet 7)
                .... ...0 = UTF-8 SSID: Not supported
                .... ..0. = QMF Activated: False
                .... .0.. = QMF Reconfiguration Activated: False
                .... 0... = Robust AV Streaming: False
                ...0 .... = Advanced GCR: False
                ..0. .... = Mesh GCR: False
                .0.. .... = SCS: False
                0... .... = QLoad Report: False
            Extended Capabilities: 0x40 (octet 8)
                .... ...0 = Alternate EDCA: False
                .... ..0. = Unprotected TXOP Negotiation: False
                .... .0.. = Protected TXOP Negotiation: False
                .... 0... = Reserved: 0x0
                ...0 .... = Protected QLoad Report: False
                ..0. .... = TDLS Wider Bandwidth: Not supported
                .1.. .... = Operating Mode Notification: Supported
                0... .... = Max Number Of MSDUs In A-MSDU: 0
        Tag: Vendor Specific: Apple, Inc.
            Tag Number: Vendor Specific (221)
            Tag length: 11
            OUI: 00:17:f2 (Apple, Inc.)
            Vendor Specific OUI Type: 10
            Vendor Specific Data: 0a00010400000000
        Tag: Vendor Specific: Broadcom
            Tag Number: Vendor Specific (221)
            Tag length: 10
            OUI: 00:10:18 (Broadcom)
            Vendor Specific OUI Type: 2
            Vendor Specific Data: 02010010000002
jfuchs
Beiträge: 66
Registriert: 19 Feb 2023, 00:20
Wohnort: Plauen i.V.

Re: Fast-Roaming LCOS/LX via IAPP, LX 6.10RC1

Beitrag von jfuchs »

Leider hast du jetzt nicht ganz alle Sachen geliefert (Beacons von beiden, und Authentication/Assoc vom LCOS-AP) wodurch das Ganze ziemlich müssig bleibt, jedoch immerhin das Authentication (Request) vom Apple Client zum LX-AP. Die vermerkte MDIE ID mit "0xdac5" in der Afrage vom iPhone sollte ja aber für den LN-1700 passen, wobei ich immernoch nicht weiß, welche der LCOS-LX AP propagiert. Darüber hinaus wird ersichtlich, dass du PMF Mandatory (Management Frame Protection Required: True) konfiguriert hast. Eigentlich ist dies laut WFA (FT over WPA3 (== WPA2 + 802.1X + PMF)) auch vorgesehen und in [0] auf Seite 11 ("4.1.2 Enterprise modes") aufgelistet. Hier muss ich wohl eine vorherige Aussage von mir revidieren: eine Kombination mit WPA3 & Suite-B (192bit) als Interoperabilitätstest zwischen LCOS & LCOS-LX habe ich glaube damals nicht als Testcase vorgesehen gehabt - wieso weiß ich gerade nicht mehr. Lediglich WPA2-Enterprise + FT wurde zwischen LX-6402 und einem LN-862 getestet.

Könntest du testweise auf beiden APs PMF ausschalten - also lediglich WPA2 fahren?

Auf was hast du das "WPA-802.1X-Security-Level" (LCOS: /Setup/Interfaces/WLAN/Encryption/WLAN-X/WPA-802.1X-Security-Level) konfiguriert? Auf was beim LCOS-LX AP "/Setup/WLAN/Encryption/<Profile>/Method" sowie "WPA-Version"? Einfacher wäre es noch, wenn du vom LCOS AP die Setup/Interfaces/WLAN-X/Encryption Tabelle, sowie vom LX-AP /Setup/WLAN/Encryption/Profile reinkopieren könntest.

[0]: https://www.wi-fi.org/wi-fi-download/35332
Antworten