P2P Link Abbruch mit 4.02 und 4.12

[thomasgiger]

Es gibt einen früheren Beitrag, der sehr ähnlich klingt, sich allerdings auf 2.4 GHz bezieht; deshalb beschreibe ich das Problem hier nochmal:

Wir haben zwei L54ag P2P Links über 6 km aufgebaut und dabei erstmals LCOS 4.02 und 4.12 eingesetzt, mit WPA2-PSK/AES Verschlüsselung.

Beide Strecken liefen 1-2 Wochen ohne jedes Problem. Dann fing das erste der beiden P2P Links mit einem spontanen Verbindungsabbruch an. Das hat sich alle paar Tage (meist in der Nacht um 4 Uhr) wiederholt, anfangs mit LCOS 4.02 aber auch mit 4.12. Seit etwa einer Woche jedoch gab es am ersten Link keine Verbindungsabbrüche mehr.

Statt dessen hat nun das zweite P2P Link mit diesem Phänomen angefangen nachdem es bisher 4 Wochen stabil lief, 2x im Abstand von erstmals nur 2 Tagen.

Zu den Details:

Beide Links haben gute Signalwerte (-62dBm) und geringes Rauschen (-100dBm), sodass sich auch ein sehr gutes SNR von 36-39 dB einstellt. Das L54ag wählt freiwillig eine 54M Modulation. Alles bestens also und die Performance ist ja auch über Tage und Wochen OK.

Wenn das Link dann abbricht, sieht man im WLAN-Link-Test immer noch den Eintrag der Gegenseite, allerdings nur die Zeile "wie von AP gesehen" und nur den SNR von eben 36 bis 39 dB. Ich weiss nicht, ob das so eine Art "letzte Erinnerung" ist oder ein aktueller Wert.

Das Link erwacht nicht wieder zum Leben sondern bleibt, wenn man nichts unternimmt, auf ewig weg. Eine Radar(fehl)erkennung schließe ich aus, auch wegen Egalistan. Wiederbelebung ist durch Strom-Reset möglich, oder indem man in Experten-Konfiguration / Sonstiges einen Kalt- oder Warmstart macht. Welche Seite man dafür wählt ist egal; ein "Reset" auf einer Seite genügt.

Bei nächster Gelegenheit in der Nacht (wenn etwas Zeit bleibt, bevor unsere Kunden zu quietschen anfangen) werde ich mal sehen, ob irgendeine sonstige Änderung der Konfiguration, die eine Neuaushandlung bewirken könnte, ebenso die Verbindung wieder herstellt.

Nach dem Warm- oder Kaltstart ist die Log-Tabelle natürlich leer. Wenn man zuvor hineinsieht, ist aber kein Eintrag zu finden, der sich auf den Abbruch bezieht. Der letzte Eintrag gilt vielmehr dem ein paar Tage zurückliegenden Neustart, und das gilt auch für die andere Seite des P2P Links. Nach dem Neustart findet man die üblichen Einträge zum Start des BSS ID und des Key Exchange; letzteren auch auf der Seite, die nicht neu gestartet wurde.

Auch mit der "thermal recalibration" scheint die Sache nicht unmittelbar zu tun zu haben, denn die tritt wohl manchmal auf, unmittelbar gefolgt von einem Key Exchange. Ich konnte bisher aber nur "cool down" Events ausmachen (z.B. etwa 11 Minuten nach dem Kalt/Warmstart) aber noch keine "warm up" Events.

Wir haben ein weiteres P2P Link mit LCOS 4.12, jedoch WEP Schlüsseln. Dieses Link hat sich in einem Beobachtungszeitraum von ebenfalls etwa 4 Wochen noch nie verklemmt.

Bei allen drei LCOS 4.12 Links ist Hardware-Kompression aktiv. Auch wenn die Kompression im Verdacht steht, die Radarfehlerkennung zu verstärken, meine ich gefühlsmässig, dass wir hier eher ein Problem mit WPA2/AES auf P2P Links seit LCOS 4.02 haben.

Was sollen wir testen? Ein Downgrade auf unter 4.02 wird nichts bringen, denke ich - da haben wir viele ewig stabile P2P-Links. Ich könnte nur mal auf AES verzichten und zu WEP zurück gehen ...

PS: Weil in einem Forum naturgemäß immer nur die Problemfälle hochkommen, möchte ich betonen, dass die geschilderte Situation Einzelfälle von nun etwa 40 LANCOM L54ag PTP Links sind, die alle wunderbar funktionieren -- über Distanzen bis 18 km und immer mit dem Durchsatz, den man aufgrund der Distanz und der maximalen Sendeleistung erwarten darf.

[alf29]

Moin,

In den Interpoint-Statistiken gibt es einen Zustand 'Keying-State'. Wie steht
der im Fall einer solchen Verklemmung auf beiden Geräten?

Gruß Alfred

[thomasgiger]

OK, Gute Frage! Ich werde das beim nächsten Abbruch nachsehen -- kann ja ein paar Tage dauern.

[hebraun]

hallo,

dein beschriebenes problem klingt ähnlich dem meinem.

ich bin mittlerweile am verzweifeln -((((

Lese mal nach:
[url]http://www.lancom-forum.de/topic,736,-V ... gsart.html[/url]

es grüsst
herbert[/url]

[thomasgiger]

Hallo Herr Arnold,

So häufig wie bei meinem Vorredner tritt das Problem (glücklicherweise/leider) nicht auf. Jetzt gab es aber wieder diesen oben beschriebenen Abbruch der Verbindung - auf logischer Ebene würde ich sagen, denn die Verbindung scheint noch zu bestehen. Ich konnte die gewünschten Daten ermitteln, bevor ich den System-Boot gemacht habe, um die Verbindung wieder aufzubauen.

Zunächst das WLAN-Log:

Index Zeit Interface Ereignis Adresse Grund
6 29.5.2005 4:44:49 WLAN-1 Key exchange with peer 00:0b:6b:34:7e:c3 successfully 000b6b347ec3
5 29.5.2005 4:44:49 WLAN-1 Performing thermal recalibration (cool-down) 000000000000
4 27.5.2005 19:21:27 WLAN-1 Key exchange with peer 00:0b:6b:34:7e:c3 successfully 000b6b347ec3
3 27.5.2005 19:21:23 WLAN-1 Performing thermal recalibration (cool-down) 000000000000
2 27.5.2005 19:10:44 WLAN-1 Key exchange with peer 00:0b:6b:34:7e:c3 successfully 000b6b347ec3
1 27.5.2005 19:10:41 WLAN-1 Started WLAN BSS ID 00:0b:6b:32:58:89 000b6b325889

Ich sehe zwar bei jedem "cool-down" einen Key Exchange, habe aber noch kein "warm-up" gesehen. Das Ding kann ja nicht nur immer kälter werden ...

Und nun der Rest:

Accesspoint-Liste
Index Node-ID Rx-Phy-Signal Rx-Rate Link-Signal Antenne Kompression Schluessel-Status LAN-Tx-Bytes LAN-Rx-Bytes Durchsatz
1 000b6b347ec3 56 54M 57 1 Aktiv fertig 4168252342 292688065 359 B


Index Quelle Schluesseltyp Schluesselwert TSC RSC
1 dynamisch AES-CCM 9416xxxxxxxxxxxxx044e9 000000fa6d7e 000000c1060b

WLAN Link Test

Station Adresse Signalpegel Rauschpegel SNR Datenrate
00-0b-6b-34-7e-c3
(Wistron 34:7e:c3) (keine Antwort)
wie vom AP gesehen: 36dB 54M
--------------------------------------------------------------------------------
10.6.2005 13:06

[alf29]

Hi,

Ich sehe zwar bei jedem "cool-down" einen Key Exchange, habe aber noch kein "warm-up" gesehen. Das Ding kann ja nicht nur immer kälter werden ...

Durch die Art und Weise, wie die Kalibrierung des Atheros-Radio-Teils arbeitet,
muß bei jeder thermischen Rekalibrierung der komplette Chip neu initialisiert werden.
Dadurch gehen auch die Schlüssel flöten...

Accesspoint-Liste
Index Node-ID Rx-Phy-Signal Rx-Rate Link-Signal Antenne Kompression Schluessel-Status LAN-Tx-Bytes LAN-Rx-Bytes Durchsatz
1 000b6b347ec3 56 54M 57 1 Aktiv fertig 4168252342 292688065 359 B

Das sieht so weit schlüsselmäßig alles gut aus - die Frage ist nur, wie's zu diesem
Zeitpunkt auf der anderen Seite aussah..,ich würd's mal ohne Kompression
probieren, das brignt nach allgemeiner Erfahrung ohnehin nicht viel und erhöht
das Risiko von Radar-Fehlerkennungen (ich weiß aber noch nicht warum).
Außerdem ist es bei Atheros eine etwas 'haarige' Sache, wann genau während
des Schlüsselaustauschs die Kompression angeschaltet wird. Eventuell haben
wir da noch ein Problem.

Gruß Alfred

[thomasgiger]

Diese Verbindung führt zu einer TGNET/wireless Basisstation, die aber leider noch nicht in einem Ring ist. Zum Zeitpunkt der Störung kann ich also leider nicht auf die andere Seite gucken (ohne unsere Netzteilnehmer eine Stunde oder länger versauern zu lassen).

Ich weiss bloss, dass die Störung auch von der anderen Seite behoben werden kann - die Leute vor Ort können allerdings nur einen Strom-Reset machen und nicht auf das L54ag gucken.

Wenn der Warmstart dagegen von der Upstream-Seite gemacht wird, findet sich im jenseitigen WLAN-Log überhaupt nichts - außer natürlich der erneute Key Exchange, den ich durch den diesseitigen Warmstart triggere.

Übrigens: mit dem Hinweis auf "warm up" habe ich nicht kritisiert, dass ein Key Exchange notwendig ist. Es ist vielmehr seltsam, dass ich in den Logs immer nur "cool down" sehe ... ich gehe davon aus, dass es ja auch mal wieder wärmer werden muss und dann sollte wohl ein "warm up" mit Key Exchange kommen. Ich finde die aber in den Logs nicht und da dachte ich mir, vielleicht werden die "warm up" Events ignoriert und genau das erzeugt dann das Problem?

Ich werde die Kompression abschalten (aber mit Radar hat das nichts zu tun, denn eine Fehlerkennung haben wir sicher nicht .

PS: Dass die Kompression die Radarerfehlerkennung erhöht, kann ich mir ganz gut vorstellen. Komprimierte Daten müssen wohl ein Maximum 01 und 10-Flanken haben, also irgendwie "energiereicher" sein, als "normale" Daten und daher das Gegenüber mehr stören. Schließlich hängt die Radarfehlerkennungsrate ja auch ganz stark von der Datenrate selbst ab ...

[alf29]

Moin,

Übrigens: mit dem Hinweis auf "warm up" habe ich nicht kritisiert, dass ein Key Exchange notwendig ist. Es ist vielmehr seltsam, dass ich in den Logs immer nur "cool down" sehe ... ich gehe davon aus, dass es ja auch mal wieder wärmer werden muss und dann sollte wohl ein "warm up" mit Key Exchange kommen. Ich finde die aber in den Logs nicht und da dachte ich mir, vielleicht werden die "warm up" Events ignoriert und genau das erzeugt dann das Problem?

Es kann sein, daß da im WLAN-Log noch Ereignisse fehlen, die einen kompletten
Reset der WLAN-Hardware bedingen (da gibt's bei Atheros so ein paar Ereignisse,
z.B. ein Überlauf des Rx-FIFOs...). Dann läuft die Kalibrierung erstmal wieder bei
den Startwerten los. Erwärmungen habe ich durchaus schon mal gesehen, aber
nur auf dem Labortisch bei künsticher Aufheizung. Das ganze System hat wohl
auch eine Hysterese. Bei den 2-Chip-Modulen scheint der Arbeitsbereich deutlich
größer zu sein, bis eine solche Rekalibrierung erforderlich ist, dort sehe ich diese
Events kaum noch.

PS: Dass die Kompression die Radarerfehlerkennung erhöht, kann ich mir ganz gut vorstellen. Komprimierte Daten müssen wohl ein Maximum 01 und 10-Flanken haben, also irgendwie "energiereicher" sein, als "normale" Daten und daher das Gegenüber mehr stören. Schließlich hängt die Radarfehlerkennungsrate ja auch ganz stark von der Datenrate selbst ab ...

Hm, also die Kompression läuft (sinnvollerweise) noch vor der Verschlüsselung, und was
aus einer Verschlüsselung herauskommt, sollte ja nach Möglichkeit digitales Rauschen sein...
und um das, was danach noch nicht gleich verteilt ist, kümmert sich der Scrambler im
Modulator...

Gruß Alfred

[thomasgiger]

Hallo Herr Arnold,

es tut mir ja leid, denn ein Workaround durch Abschalten der Hardware-Kompression wäre mir auch lieb gewesen, aber eben hat eines der beiden 4.02/4.12 PTP Links wieder gehangen (es war das mit der 4.02 Firmware), obwohl die Hardware-Kompression abgeschaltet war. Das ist es also nicht.

Was nun? TX-Burst abschalten? AES durch WEP ersetzen?

Ich glaube, letzteres würde sicher helfen, denn ein weiteres PTP Link mit 4.12 Firmware und WEP hat noch nie gehangen. Andererseits machen 4.12 L54ag's mit AES und madwifi/wpa_supplicant Clients bisher glücklicherweise noch keine Probleme. Es hat also etwas mit WDS/PTP und AES zu tun.

Hmm, da fällt mir eine Zusatzfrage ein: Kann es Sinn machen, den WPA-Sitzungsschlüssel auf AES (statt TKIP/AES) zu setzen? Die Einstellung AES haben wir nämlich bei den L54ag/madwifi Verbindungen gemacht, TKIP/AES dagegen bei den L54ag-L54ag WDS Links ...

[Jirka]

Hallo Thomas,

> Was nun? TX-Burst abschalten?

Das wird nichts bringen. Das funktioniert sehr gut.

> AES durch WEP ersetzen?

Wäre sicher für Testzwecke mal in Erwägung zu ziehen.

> Kann es Sinn machen, den WPA-Sitzungsschlüssel auf AES (statt TKIP/AES) zu setzen?

Eigentlich nicht, denn wenn bei einer P2P-Strecke zwischen zwei L-54 "TKIP/AES" ausgewählt ist, einigen sich die Geräte automatisch auf "AES". Somit macht das keinen Sinn. Du kannst es aber trotzdem fest auf AES setzen.

Viele Grüße,
Jirka

[alf29]

Moin,

eine Firmware 4.02 auf einer P2P-Strecke würde ich erstmal durch eine
4.12 ersetzen. Im DFS hat es einpaar Probleme mit Race-Conditions
gegeben, die u.a. dazu führen konnten, daß die beiden Seiten sich
nach einem Kanalwechsel nicht mehr auf dem gleichen Kanal wiederfanden -
und das unabhängig von WPA oder WEP.

Gruß Alfred

[thomasgiger]

Hmm. Sollte ich vielleicht machen, obwohl es in unserem Fall DFS wohl egal ist ... außerdem hat die andere P2P Strecke Firmware 4.12. Ich warte dort noch auf ein Aufhängen nach Abschaltung der Kompression. Letztens kam der nächste Hänger nach 4 Minuten, und dann dauert es wieder Wochen.

[thomasgiger]

Nun, solange mussten wir nicht warten. Das PTP Link mit 4.12 Firmware hatte vorgestern den Hänger - danach hatte ich die Kompression ausgeschaltet - und eben jetzt wieder.

Die Kompression ist es also nicht. Der nächste logische Schritt für mich wäre, AES bei WDS-Links für instabil zu erklären und ein Downgrade auf WEP zu machen.

Herr Arnold, gibt es davor noch etwas, was ich für Sie in der aktuellen Konfiguration herausfinden kann?

[alf29]

Die Kompression ist es also nicht. Der nächste logische Schritt für mich wäre, AES bei WDS-Links für instabil zu erklären und ein Downgrade auf WEP zu machen.

Herr Arnold, gibt es davor noch etwas, was ich für Sie in der aktuellen Konfiguration herausfinden kann?

In dem Fall eines Hängers brauche ich einen Auszug
der oben genannten Statustabellen - für *beide Seiten*

Gruß Alfred

[thomasgiger]

OK, ich werde ein Script schreiben, das auf der Remote Seite läuft und die fraglichen Tabellen per SNMP aus dem L54ag ausliest -- sonst ist dort nämlich keiner, der das für mich tun könnte. Melde mich dann wieder.