WiFi/Wave2 – „SA Query timeout“

Wer bei Mikrotik das neue „WiFi“-Paket (ROS >= v7.13 (oder das Wave2-Paket, ROS <v7.13)) nutzt und dabei immer wieder Abbrüche bei manchen Geräten im WLAN erlebt, ist hier richtig.

Im Log werden dabei Meldungen wie z. B. „00:11:22:33:44:55@WLAN.NETZ.TLD3 disconnected, SA Query timeout, signal strength -34“ geloggt.

Bei mir tritt das Phänomen meistens (aber nicht nur) mit einem Lenovo-Laptop mit Realtek 8821CE-WLAN-Adapter auf.

Vermutlich tritt das Ganze auf, wenn das Endgerät von 2,4 nach 5 GHz oder umgekehrt wechselt. Dabei erfolgt der Wechsel nicht sofort, sondern erst nach einer kleinen Wartezeit. Beim neuen WiFi (oder Wave2) Paket gibt es die Sicherheitsoption „connect-priority“:

 

connect-priority (accept-priority/hold-priority (integers))

Theese parameters determine, how a connection is handled if the MAC address of the client device is the same as that of another active connection to another AP.
If (accept-priority of AP2) < (hold-priority of AP1), a connection to AP2 wil cause the client to be dropped from AP1.
If (accept-priority of AP2) = (hold-priority of AP1), a connection to AP2 will be allowed only if the MAC address can no longer be reached via AP1.
If (accept-priority of AP2) > (hold-priority of AP1), a connection to AP2 will not be accepted.

If omitted, hold-priority is the same as accept-priority.
By default, APs, which perform user authentication, have higher priority (lower integer value), than open APs.

Quelle

Standardmäßig ist hold-priority = accept-priority.
Mit AP1 ist z. B. das 2,4 GHz und mit AP2 das 5 GHz Interface gemeint.

 

Meine Vermutung ist, dass, wenn das Endgerät z. B. von 5 GHz nach 2,4 GHz wechselt, der Access Point dies erst zulässt, wenn er über sein 2,4 GHz Interface das Endgerät (MAC-Adresse) nicht mehr erreicht (a connection to AP2 will be allowed only if the MAC address can no longer be reached via AP1). Dieses Prozedere dauert scheinbar einige Sekunden, in der das Endgerät keine Verbindung herstellen darf.

Ändert man die Einstellung:

security.connect-priority=0/1

 

Trat bei mir das Phänomen nicht mehr auf.

 

WICHITG: Wenn man die Einstellung entsprechend tätigt, ist das Netz für die sogenannte „MacStealer“-Attacke verwundbar, die sich aber – meines Wissens – nur auf WLAN-Netzwekre mit Client-Isolation bezieht. Hier muss man abwägen, ob man für bestimmte Hochsicherheitsnetze (mit aktiver Client-Isolation) die Option wieder deaktiviert und dafür die Abbrüche in Kauf nimmt.

Unfortunately support confirmed that it would make the clients vulnerable to the macstealer attack. Quelle

 

Der Hersteller Sonicwall hat das Problem etwas genauer untersucht und sagt dazu:

SonicWall PSIRT believes that this vulnerability has a minimal effect on data confidentiality and considers this vulnerability a low risk vulnerability.
SonicWall is not aware of any malicious use of this vulnerability.
Quelle

 

Referenzen:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert