[Gelöst] WPA Group key handshake Intervall

[obelix76]

ich bekomme von meiner gefreetzten Box dieses group key handshake

2014-09-30 21:10:35	Daemon.Info	192.168.x.x	Sep 30 21:10:34 hostapd: ath0: STA xx:xx:xx:44:9b:81 WPA: group key handshake completed (WPA)
2014-09-30 21:10:35	Daemon.Info	192.168.x.x	Sep 30 21:10:34 hostapd: ath0: STA xx:xx:xx:69:f7:cb WPA: group key handshake completed (WPA)
2014-09-30 21:10:35	Daemon.Info	192.168.x.x	Sep 30 21:10:34 hostapd: ath0: STA xx:xx:xx:43:d2:62 WPA: group key handshake completed (WPA)
2014-09-30 21:10:35	Daemon.Info	192.168.x.x	Sep 30 21:10:34 hostapd: ath0: STA xx:xx:xx:b9:6f:b1 WPA: group key handshake completed (WPA)
2014-09-30 21:10:35	Daemon.Info	192.168.x.x	Sep 30 21:10:34 hostapd: ath0: STA xx:xx:xx:99:63:51 WPA: group key handshake completed (WPA)
2014-09-30 21:10:35	Daemon.Info	192.168.x.x	Sep 30 21:10:34 hostapd: ath0: STA xx:xx:xx:bd:83:2b WPA: group key handshake completed (WPA)

2014-09-30 21:20:35	Daemon.Info	192.168.x.x	Sep 30 21:20:34 hostapd: ath0: STA xx:xx:xx:b9:6f:b1 WPA: group key handshake completed (WPA)
2014-09-30 21:20:35	Daemon.Info	192.168.x.x	Sep 30 21:20:34 hostapd: ath0: STA xx:xx:xx:44:9b:81 WPA: group key handshake completed (WPA)
2014-09-30 21:20:35	Daemon.Info	192.168.x.x	Sep 30 21:20:34 hostapd: ath0: STA xx:xx:xx:69:f7:cb WPA: group key handshake completed (WPA)
2014-09-30 21:20:35	Daemon.Info	192.168.x.x	Sep 30 21:20:34 hostapd: ath0: STA xx:xx:xx:43:d2:62 WPA: group key handshake completed (WPA)
2014-09-30 21:20:35	Daemon.Info	192.168.x.x	Sep 30 21:20:34 hostapd: ath0: STA xx:xx:xx:99:63:51 WPA: group key handshake completed (WPA)
2014-09-30 21:20:35	Daemon.Info	192.168.x.x	Sep 30 21:20:35 hostapd: ath0: STA xx:xx:xx:bd:83:2b WPA: group key handshake completed (WPA)

für alle verbundenen WLAN Geräte alle 10 Minuten in meinem Syslog (zum Posting hier hab ich die IP der Fritzbox "ausge-x't", ebenso die ersten drei Stellen der MAC-Adressen).

Ich habe jetzt festgestellt, daß einige Geräte bei diesem handshake mitunter einen "Schluckauf" bekommen, und erst nach einiger Zeit (~2s) ihren Dienst wieder korrekt aufnehmen. Grad beim Streaming (ich hab da so einen China WLAN zu HDMI Dongle) ist das etwas ...lästig.

Für das handshake scheint der hostapd zuständig zu zeichnen - gibt es eine Möglichkeit, dieses in längeren Zeitspannen als 10 Minuten ablaufen zu lassen? (ok - falsche Frage... Ich sollte fragen: Wie erreiche ich es mit Freetz, diese Aktion in längeren Zeitspannen ablaufen zu lassen? )

Wenn ich das richtig verstehe, wird bei diesem key handshake in Abhängigkeit vom PSK der Verschlüsselungskey des WLANs neu ausgehandelt, oder? Gut - schneller Schlüsselwechsel ist ein Sicherheitsaspekt. Da bei mir aber die Nachbarn so weit weg sind, ebenso die umzäunte Grundstücksgrenze, daß da "normal" keiner auch nur auf "Hörweite" an das WLAN rankommt, sollte es doch kein Problem darstellen, die Zeitspanne auf sagen wir mal 3 Stunden oder so hochzusetzen? Oder mach ich hier einen fatalen Denkfehler?


Edit:
Ich hab mich weiter durch Dateien gegraben...
in /etc/ath/PSK.ap_bss gibt es eine Zeile

wpa_group_rekey=~!AP_WPA_GROUP_REKEY#~

Durch gurgeln im Netz hab ich rausgefunden/vermute ich, daß diese Zeile irgendwie im Zusammenhang mit meinem Problem stehen könnte...
Da ich jetzt aber (noch nicht) so der Linux-Spezi bin... der Teilstring nach dem "=" sieht irgendwie nach einer Variable aus. Daher meine Frage jetzt: Wo wird der Inhalt dafür definiert, wie änder ich den?

Würde es etwas bringen (Firmware-Umflashereien kann ich erst wieder im späten Abend machen, da ich sonst hier wegen "kaputtem Internet" gegrillt werde ), wenn ich in der Freetz-Buildumgebung die Datei händisch editiere auf - sagen wir - einen festen Wert von 3600 (und damit die Variable in der Zeile überschreibe), die Firmware neu compiliere und flashe? (noch ein edit nachgeschoben: So einfach wie ich mir das dachte, geht es natürlich nicht - wenn ich die Datei von hand ändere und ein make der Firmware anschubse, wird die Datei wieder überschrieben. Wo liegt da mein Denkfehler?)

 

[RalfFriedl]

Passiert das auch mit der AVM Firmware oder nicht?

 

[obelix76]

Da ich in der Originalfirmware keinen Syslog habe, kann ich jetzt "auf die Schnelle" nicht testen, ob da das gleiche passiert. Ich kann im Tagesbetrieb hier die Fritzbox aus im Eingangspost genannten Gründen auch nicht "mal eben" umflashen. Ich werde das im Abend testen müssen.

Wenn ich mir die Syslogs aber so ansehe, ist das schon sehr, sehr lange so, daß da im 10 Minuten-Takt dieser Handshake läuft (ich meine, das geht bis auf meine 7170 vor ...etlichen Jahren zurück).

 

[PeterPawn]

daß da im 10 Minuten-Takt dieser Handshake läuft

Dieser "Group Key" wird bei WPA (das Umschalten auf "reines WPA2" sollte also auch helfen, da läuft der GTK(Groupwise Transient Key)-Austausch etwas anders ab) neben dem gerätespezifischen Session-Key, mit dem die Kommunikation zwischen AP und dem Client individuell verschlüsselt wird, so daß auch kein anderer "mithören" kann (das ist dann ein "Pairwise Transient Key" - PTK), zur Verschlüsselung von Broadcasts und Multicasts verwendet, wenn der AP nicht nur einen einzelnen Client erreichen will.

Die Alternative, jedes potentielle BC- oder MC-Paket als Unicast an jeden Client individuell zu schicken, bräuchte eben wesentlich mehr "Bandbreite" im Funkverkehr. Der Umstieg auf WPA2 unterdrückt aber auch nur die Nachrichten (die Dich ja wohl weniger stören als die Pausen), auch bei WPA2 werden GroupKeys benötigt (aus dem genannten Grund des "sparsamen Umgangs" mit der Bandbreite). Normalerweise wird auch nach jeder Anmeldung eines neuen Clients oder bei der Abmeldung eines alten ein neuer GTK in der "Zelle" des AP verwendet.

Der Anstoß (und die Konfiguration) des Rekeyings und die Verwaltung der GroupKeys sollte im "wpa_supplicant" erfolgen, der ist OSS (gehört zum hostapd) und die Konfigurationsmöglichkeiten für ihn kann man im Internet nachlesen.

Das ist aber in meinen Augen auch nur die halbe Lösung ...
Eine "Denkpause" ist eigentlich untypisch und deutet meiner Meinung nach eher darauf hin, daß da eine Seite "nicht hinterher kommt" mit dem Wechsel des Keys (und dann z.B. im Falle des China-Geräts die MCs schlicht nicht mehr versteht, wenn das Streamen da per MC laufen sollte) oder auch die (Funk-)Pakete dafür nicht "empfängt" oder sie falsch versteht (das wäre dann ein Problem des Clients).

Der AP kann ja erst dann den neuen GroupKey verwenden, wenn alle benachrichtigten Clients die Änderung auch bestätigt haben, sonst versteht ihn die Hälfte der Clients am Ende nicht.

Wenn jetzt irgendein Client (der z.B. einfach "ohne Abmeldung" schlafen geht) nicht - sofort - auf die Message zum GTK-Wechsel reagiert, braucht der AP einen Moment für Wiederholungen oder um den aus der Liste zu werfen, einen neuen GroupKey an die Clients zu verteilen und dann wieder "an alle" zu senden. Da würde die Verzögerung dann wiederum beim AP auftreten und alle Clients zu diesem Zeitpunkt betreffen.

Wenn Du schreibst, das betrifft nur "einige Geräte", könnte das aber u.U. trotzdem ein AP-Problem sein. Wenn der von sich aus Unsinn sendet (also falsche Pakete und damit falsche Schlüssel verteilt), kommt bei den Clients (immer vorausgesetzt, es sind wirklich mehrere) natürlich auch Unsinn an und die verstehen dann die folgenden BC-/MC-Pakete nicht, weil diese aus ihrer Sicht falsch verschlüsselt sind.

Die logische Folge wäre dann aber ein kompletter Neuaufbau der Client-WLAN-Verbindung, gibt es denn bei den "Pausen" noch weitere Meldungen im Syslog bzw. auch im AVM-Eventlog ?

Der Austausch des GroupKeys erfolgt - nur der Vollständigkeit halber angemerkt - nicht als Broadcast, das ist schon für jeden angemeldeten Client dann eine individuelle "Ansage" des AP (mit dem PTK des Client). Insofern wäre das wieder - wenn mehrere (aber nicht alle) Clients parallel den "Schluckauf" bekommen - eher ein Zeichen für ein Problem im AP-Code für das Rekeying.

Normalerweise kann man in so einem Falle dann ein ausführlicheres Logging im hostapd/wpa_supplicant einschalten (um dabei z.B. zu sehen, ob ein Client vielleicht nicht antwortet oder ob da dann bei dem "stockenden" Client eine komplette Anmeldung abläuft); ob und wie das bei der FB7490 auch geht, mußte ich noch nie selbst erkunden und kann Dir deshalb an dieser Stelle auch nicht weiterhelfen. Nur der eher allgemeine Tipp zum (kabelgestützten) Paketmitschnitt des AP-Verkehrs bleibt am Ende noch über, da könnte man dann die Kommunikation zumindest anhand der ausgetauschten Pakete verfolgen und so eventuelle "Timeout-Sünder" aufspüren.

 

[obelix76]

danke erstmal für die super ausführliche Antwort - da prasselte erstmal viel geballtes Wissen auf mich ein

Was den Umstieg auf reines WPA2 angeht - ja, ich muß noch mal schauen ob in meinem Sammelsurium von WLAN-geräten alle damit auskommen. Wenn da weniger geschlüsselt wird, hilft das vielleicht auch weiter. Die Geräte mit Schluckauf (jedenfalls solch einer, der mir eben dank der Konrad Zuse - Gedenkminute auffällt) sind zwei WLAN->HDMI Sticks unterschiedlicher Bauart aus China.

Die Probleme / Streamabrisse treten blöderweise nicht bei jedem Rekeying auf (und wenn man drauf wartet, natürlich schon mal gar nicht... Murphy läßt grüßen ), sondern nur sporadisch und schwer reproduzierbar. Deswegen nerven sie noch mehr. Ein kompletter WLAN-Verbindungsabriß scheint dabei jedoch nicht aufzutreten. Um den Zeitpunkt des Rekeyings herum (und bei eingetretenem Abriß am Stick) zeigen die Logs keine Auffälligkeiten.

Ich werde mal weiter suchen, was man vielleicht in Richtung des hostapd noch tun kann um das Intervall höherzuschrauben. Falls da noch jemand sachdienliche Hinweise hat - ich bin für alles offen...

 

[obelix76]

so... ich habe jetzt wohl eine (quick & dirty) Lösung... vielleicht kann mir ja jemand mit mehr Kenntnis von Freetz noch sagen, wie das ganze vielleicht eleganter zu lösen ist.

also - offensichtlich wird die Datei

/etc/ath/PSK.ap_bss

zum Konfigurieren des hostapd herangezogen. Folglich habe ich in dieser "herumgepfuscht".
Wie ich ja schon schrieb, ist ein einfaches Editieren in der Build-Umgebung fehlgeschlagen, da die Datei vor dem Packen des Freetz-Images wieder mit dem "Original" überschrieben wurde und meine Änderungen damit futsch waren.

Ich bin also Umwege gelaufen:

• Schritt 1: Freetz Image ganz normal bauen
• Schritt 2: gebautes Freetz Image wieder in ein eigenes Verzeichnis entpacken (nach Anleitung von hier: http://freetz.org/wiki/help/howtos/development/repack_fw )
• Schritt 3: o.g. Datei editieren (ich hab die Zeilen wpa_group_rekey und wpa_gmk_rekey ihrer Variable beraubt und dort fest 3600 eingetragen, die Originalzeilen hab ich erstmal nur auskommentiert. Sieht dann so aus:
  

  #wpa_group_rekey=~!AP_WPA_GROUP_REKEY#~
  wpa_group_rekey=3600
  #wpa_gmk_rekey=~!AP_WPA_GMK_REKEY#~
  wpa_gmk_rekey=3600

• Schritt 4: nachbehandeltes Dateisystem wieder zu einem Freetz-Image packen (ebenfalls nach Anleitung aus Schritt 2)
• Schritt 5: Image flashen

Danach passiert das Rekeying nur noch alle 60 Minuten und die Chance, einen "schlechten" Rekey-Vorgang mit meinem Streamclient zu erwischen ist schon mal deutlich geringer. Etwa jeder dritte bis vierte Rekey ging ja irgendwie schlecht ab, mit der Default-Einstellung von AVM / Freetz also nach 30-40 minuten. Jetzt dann rechnerisch nach 3-4 Stunden...


Meine Frage an die etwas Versierteren hier:
Ich gehe mal davon aus, daß meine Abfolge da oben so manchem die Fußnägel aufrollt (für mein Empfinden ist das ne ziemlich krude Hackerei, die ich da verbreche ). Wie kann man das besser lösen?

Ich hab im Freetz Wiki versucht, mich zu belesen, aber so wirklich einen richtigen Hinweis auf meine Problemstellung habe ich nicht ausmachen können. Vor allem wäre es natürlich auch schön, wenn ich diese Änderung lokal in meiner Buildumgebung so einbinden könnte, daß sie bei jedem make automatisch mit durchläuft. Geht das irgendwie?
(noch viel viel besser wäre es, wenn es dafür ne Option im Menuconfig gäbe - aber da verlassen sie mich endgültig )

 

[PeterPawn]

Vor allem wäre es natürlich auch schön, wenn ich diese Änderung lokal in meiner Buildumgebung so einbinden könnte, daß sie bei jedem make automatisch mit durchläuft. Geht das irgendwie?

Genau für solche Problemstellungen gibt es wohl die "fwmod_custom" im Trunk-Verzeichnis.

Wenn man da die all-Funktion duch folgende Zeilen ersetzt:

all() {
    patch -p0 <<-"EOP"
--- filesystem/etc/ath/PSK.ap_bss.org
+++ filesystem/etc/ath/PSK.ap_bss
@@ -35,5 +35,7 @@
 ieee80211w=~!AP_PMF#~

 wpa_pairwise=~~AP_CYPHER#~
-wpa_group_rekey=~!AP_WPA_GROUP_REKEY#~
-wpa_gmk_rekey=~!AP_WPA_GMK_REKEY#~
+#wpa_group_rekey=~!AP_WPA_GROUP_REKEY#~
+wpa_group_rekey=3600
+#wpa_gmk_rekey=~!AP_WPA_GMK_REKEY#~
+wpa_gmk_rekey=3600
EOP
}

... dann werden die Änderungen bei jedem neuen 'make' automatisch mit eingebaut (allerdings sollte man dann die 'fwmod_custom' noch irgendwo beiseite legen, damit man nicht doch versehentlich ein 'svn revert' dafür macht). Der Patch passt für die 7490 mit 06.20 und stellt Deine 3600 Sekunden ein ... bei anderen Rahmenbedingungen mußt Du ihn einfach mit 'diff' korrekt erstellen. Auch wenn das nicht besonders schön aussieht, habe ich das Patch-File absichtlich als "here document" in das Shell-Skript eingefügt, da sich damit Deine notwendigen Änderungen in einer einzigen Datei versammeln.

 

[obelix76]

supi - wieder was gelernt.
ganz großes Danke an dich!!