P2P Link Abbruch mit 4.02 und 4.12

[thomasgiger]

Ich habe zwar noch nicht die Daten von der während eines Verbindungsabbruchs für mich nicht mehr erreichbaren P2P Slave-Seite, aber mir sind bei einem Abbruch heute um 5 Uhr morgens zwei Dinge aufgefallen:

1) TKIP/AES oder doch nur AES?

Die P2P-Links, die den Abbruch zeigen, haben bei einen "WPA Session Key Type" = TKIP/AES, wie's ja auch im Handbuch steht. Wenn man dann im Experten-Modus die Schlüssel abfragt, findet man zum einen wie erwartet

Schluessel-Liste
Index Quelle Schluesseltyp Schluesselwert TSC RSC
1 dynamisch AES-CCM 2fe6c82dc7d372e9491dd8bfdfaab236 00000032944a 00000048db37

jedoch

Gruppen-Schluessel
Index Quelle Schluesseltyp Schluesselwert TSC RSC
WLAN-1-G dynamisch TKIP *0ba9ecbafd263bc9ae1014f132028172a669d638a0ed80bcc143a90505dcd9a4 00000000001b 000000000000

Das "TKIP" ist hier etwas seltsam. Habe deshalb eine andere P2P-Verbindung mit "WPA Session Key Type" = AES eingerichtet, und siehe da:

Gruppen-Schluessel
Index Quelle Schluesseltyp Schluesselwert TSC RSC
WLAN-1-G dynamisch AES-CCM *3c15b92be2b23a1502cc410210bebb55 00000000011e 000000000000

Hat das was zu bedeuten?

2) Stack-Fehler

Während des Verbindungsabbruchs fand ich auf der Master-Seite des P2P-Links:

Fehler-Statistik
Ifc Rx-Fehler Tx-Fehler Stack-Fehler NIC-Fehler Queue-Fehler Tx-Verworfen Wiederholungen Mehrfach-Wiederholungen Dupes-Verworfen Unentschluesselbar Undekomprimierbar Veraltet Michael-Fehler IV-Sequenzfehler
WLAN-1 14601 0 1 0 0 57015 74898 8443 1 14449 0 0 0 0

und auf der Slave-Seite

Fehler-Statistik
Ifc Rx-Fehler Tx-Fehler Stack-Fehler NIC-Fehler Queue-Fehler Tx-Verworfen Wiederholungen Mehrfach-Wiederholungen Dupes-Verworfen Unentschluesselbar Undekomprimierbar Veraltet Michael-Fehler IV-Sequenzfehler
WLAN-1 25861 38 5 0 0 788075 471575 45309 11 25455 0 0 0 13955

Dazu muss man sagen, dass ich das P2P-Link durch Kaltstart auf der Master-Seite in Gang setze. Die Slave-Seite wird nicht resettet. Der Stack-Fehler Stand von "5" am Slave entspricht ganz gut der Anzahl der Abbrüche, die ich durch Reset auf der Master-Seite behoben habe.

Hat das was zu bedeuten?

[thomasgiger]

So, jetzt habe ich das Script am Laufen, das von beiden Seiten des PTP Links per SNMP alle OIDs im LANCOM Zweig ausliest. Ich warte nur noch auf den nächsten Hänger. Werden diese Daten ausreichend sein?

[alf29]

Moin,

Das mit dem TKIP und AES ist korrekt so. Der Gruppenschlüssel ist der Schlüssel,
mit dem Broadcasts an eingebuchte Clients verschlüsselt werden - dies ist
notwendigerweise immer das 'schlechteste' Verfahren. Für den gerichteten
Datentransfer handeln beide Seiten immer den bestmöglichen Schlüssel aus,
zwei LANCOMs also untereinander AES (es sei denn man verbietet es ihnen
ausdrücklich...). Aus WLAN-Sicht sind P2P-Frames immer gerichtete Pakete,
von daher wird der Gruppenschlüssel auf P2P-Verbindungen für nichts benutzt.

Gruß Alfred

[thomasgiger]

Ja, das hatte ich dann auch gemerkt: Habe AES statt AES/TKIP eingestellt und dann war auch AES bei den Gruppenschlüsseln zu sehen ... es hat aber nichts gebracht .

Wie gesagt, irgendwann in den nächsten Tagen wissen wir mehr ...

[alf29]

Moin,

'Stack'-Fehler heißt, daß ein Paket die internen Protokollstacks des
LANCOM heraufgelaufen ist, mit dem aber niemand im LANCOM etwas
anfangen konnte. Typischerweise sind das Broadcasts oder Multicasts
für etwas 'ausgefallenere' Protokolle (Bridge-PDUs, IPX, Appletalk). Stört
aber nicht weiter, das Paket wird eben ignoriert.

Ich hätte noch die Tabelle 'Status/WLAN/Interpoint/Accesspoint' gebaucht, da
stünde genau drin, wer (noch) welchen Schlüssel hat. So wie's für mich aussieht,
hat der Master aber die Beacons vom Slave nicht mehr gesehen und den Schlüssel
verworfen. Alle Firmwaren bis einschließlich 5.00 haben noch den Fehler, daß ein
P2P-Partner ohne ausgehandelte Schlüssel weiter an den Partner Daten senden
(ist ein Job für Montag ) und dabei dann den Gruppenschlüssel nutzen. Das
versteht die Gegenseite dann natürlich nicht mehr und es hagelt die 'undecryptables'.

Hat es auf den Geräten vor den Verbindungsverlust evtl. vorher mal thermische
Rekalibrierungen gegeben (stehen im WLAN-Log)?

Gruß Alfred

[thomasgiger]

Ich hätte noch die Tabelle 'Status/WLAN/Interpoint/Accesspoint' gebraucht, da
stünde genau drin, wer (noch) welchen Schlüssel hat.

Ziemlich am Anfang dieses nun recht langen Threads hatte ich die gepostet - oder meinen Sie was anderes?

Hat es auf den Geräten vor den Verbindungsverlust evtl. vorher mal thermische Rekalibrierungen gegeben (stehen im WLAN-Log)?

Jein. Es gab "cool-down" Events, die auch immer von einer neuen Schlüsselverhandlung gefolgt werden. Das passiert z.B. regelmäßig nach einem Boot oder Warmstart innerhalb der ersten 1-3 Minuten oder sonst wenn's eben kälter wird, führt aber nie zum Hänger. Habe aber noch nie einen "warm-up" Event gesehen und auch nie ein Schlüsselverhandlung, die alleine aufgetaucht wäre (wir haben genug RSSI).

Wenn der Hänger passiert, sieht man am Master absolut nichts im WLAN-Log, das zeitlich passend wäre - nur die Einträge vom letzten Warmstart. Der Slave schreibt auch nichts ins WLAN-Log, das kann ich allerdings erst nach dem Master-Warmstart sehen. Erst durch den Warmstart werden wieder Schlüssel ausgetauscht und die stehen natürlich auch im Log.

PS: Mein (alter) Verdacht: Die warm-up Events werden nicht registriert und ergo nicht von einem Schlüsselaustausch begleitet.

[alf29]

Ziemlich am Anfang dieses nun recht langen Threads hatte ich die gepostet - oder meinen Sie was anderes?

Die meinte ich schon - aber der Auszug vom Anfang des Threads war ja zu einem
Zeitpunkt, wo die Verbindung lief - wenn sie gerade nicht läuft, müßte dort ein 'idle'
als Keying-State stehen.

PS: Mein (alter) Verdacht: Die warm-up Events werden nicht registriert und ergo nicht von einem Schlüsselaustausch begleitet.

Da das absolut der gleiche Programmzweig ist, würde mich das sehr wundern...

Gruß Alfred

[thomasgiger]

... aber der Auszug vom Anfang des Threads war ja zu einem Zeitpunkt, wo die Verbindung lief - wenn sie gerade nicht läuft, müßte dort ein 'idle' als Keying-State stehen.

Doch, dieser Auszug war VOR dem rettenden Warmstart gemacht worden (steht auch im Text). Der Keying state ist während des Hängers nicht "idle". Zumindest nicht am Master, an den ich rankomme. Was der Slave am Remote Ende macht, weiss ich erst, wenn jetzt endlich mal ein Hänger kommt - ich warte ja geradezu darauf