Lancom L54-ag verliert Verbindung

[Guenter]

Wir haben hier 2 Lancom L-54ag die über jeweils eine Externe Antenne (von Wimo 18660.54) eine etwa 2km Stecke überbrücken.

Die Stecke lief, seit wir auf die Firmware Version 4.x umgestiegen sind (vor etwa 3 Monaten), fehlerfrei und ohne Ausfälle.

Seit etwa 2 Wochen ist die Verbindung nach etwa 24 Stunden plötzlich weg und kommt auch nicht wieder bis ich die L54ag neu starte. Direkt nach dem Neustart steht die Verbindung wieder 1a und läuft die oben erwähnten ~24 Stunden ohne Probleme durch.

Da sich Lancom seit etwa einer Woche weigert unsere Anrufe entgegenzunehmen bzw. auf unsere Supportanfragen zu antworten, wäre es vielleicht möglich das hier jemand weiß woran dieses Problem liegen kann und wie wir es schnellst möglich beheben können.

P.S. wir haben inzwischen auch mal die neue Firmware aufgespielt, das Ergebniss bleibt allerdings das gleiche. Wir haben einen der L54ag duch einen neuen ersetzt, hat allerdings nicht gebracht (ich will nicht nochmal 300,- für ein Gerät ausgeben wenn ich nicht weiß das es was bringt)

[hebraun]

Hallo,

mit der gleichen Problematik kämpfe ich mit einem L-54g seit 3 Monaten.
Bei der Verschlüsselungsart WEP tritt das Problem nicht auf, lediglich AES/TKIP bringt mich zum verzweifeln.

Sämtliche Konfigurationsänderungen oder Firmwarewechsel brachten keinen Erfolg.

Mir hat LANCOM angeboten die beiden Geräte überprüfen zulassen.

Shiehe:
http://www.lancom-forum.de/topic,736,-V ... gsart.html

Gruss
Herbert Braun

[thomasgiger]

Es gibt hier einen Thread "P2P Abbruch mit 4.02 und 4.12", in dem ich dieses Problem mit Herrn Arnold diskutiert habe. Richtig scheint zu sein, dass dieses Phänomen nur mit AES auftritt. Wenn es sich um DASSELBE Problem handelt, müsste ein Warmstart (im Expertenmenü zu finden) auf nur einer Seite des Links genügen, den Hänger zu beseitigen.

Ich habe außerdem den Verdacht, dass die Hänger durch einen Temperaturanstieg ausgelöst werden. Ich hatte diese Vermutung schon anfangs geäußert und so rein empirisch erhärtet sich der Verdacht. Bei Ihnen ist das durchaus ähnlich: Jetzt ist es warm, davor war es kühler - im Einzelfall wird es aber je nach Standort und baulichen Faktoren Unterschiede geben.

Wie auch immer: Herr Arnold braucht die Daten von BEIDEN Seiten, um die Ursache eingrenzen zu können. Problem dabei ist, dass es einfach zu lange dauert, die SLAVE Seite aufzusuchen - während des Hängers komme ich ja nicht dran und eine Anfahrt dauer den Kunden zu lang. Ich habe nun ein Script auf den Routern auf beiden Seiten laufen, das per SNMP den Zustand des jeweiligen L54ag ausliest und mir zumailt, nachdem es den Reset gemacht hat. Nun warte ich nur noch auf den nächsten Hänger, der bei uns nicht so oft auftritt wie anderswo.

PS: Wenn ich hier so im Forum lese, kommt ein Upgrade auf 5.0 nicht in Frage, zumal das Problem nur *zufällig* behoben sein könnte, da es anscheinend bei LANCOM nicht bekannt ist. Ein Austausch der Geräte ist sinnlos. Wir haben zwei Links, die das Problem zeigen.

[Guenter]

Richtig scheint zu sein, dass dieses Phänomen nur mit AES auftritt.
Wenn es sich um DASSELBE Problem handelt, müsste ein Warmstart (im
Expertenmenü zu finden) auf nur einer Seite des Links genügen, den
Hänger zu beseitigen.

hmm, ob wir AES benutzen weiß ich jetzt garnicht, muss ich morgen mal nachsehen. Allerdings ist es mit dem Reset auf egal welcher Seite nicht immer getan, manchmal funktioniert es, meist komme ich aber nicht drumrum zum anderen zu fahren und den neu zu starten. Das könnte evtl auch daran liegen das bei uns die entfernte Gegenstelle der Master ist und ein Reset desselben das Problem behebt (Ich werde den Master mal zu uns legen um festzustellen obs hilft).

Ich habe außerdem den Verdacht, dass die Hänger durch einen
Temperaturanstieg ausgelöst werden. Ich hatte diese Vermutung schon
anfangs geäußert und so rein empirisch erhärtet sich der Verdacht. Bei
Ihnen ist das durchaus ähnlich: Jetzt ist es warm, davor war es kühler - im
Einzelfall wird es aber je nach Standort und baulichen Faktoren
Unterschiede geben.

Das war auch unserer erster Gedanke da das Gerät ja nichtmal nen passiven Kühlkörper auf dem Prozessor hat, allerdings müsste das Gerät dann abstürzen wenn zu warm wird und nicht nach 24 Stunden (die zZ so gelegt sind das es früh zwischen 8 und 9 Uhr passiert) und ein Neustart dürfte die 24-Stunden First nicht wieder neu starten (Der Prozessor wird dadurch ja nicht wirklich kühler) was er aber tut.

Wie auch immer: Herr Arnold braucht die Daten von BEIDEN Seiten, um die
Ursache eingrenzen zu können. Problem dabei ist, dass es einfach zu
lange dauert, die SLAVE Seite aufzusuchen - während des Hängers komme
ich ja nicht dran und eine Anfahrt dauer den Kunden zu lang. Ich habe nun
ein Script auf den Routern auf beiden Seiten laufen, das per SNMP den
Zustand des jeweiligen L54ag ausliest und mir zumailt, nachdem es den
Reset gemacht hat. Nun warte ich nur noch auf den nächsten Hänger, der
bei uns nicht so oft auftritt wie anderswo.

Die Daten von beiden Seiten zu bekommen wäre bei uns hier nicht das Problem, ich muss nur mit nem Laptop rüber um den entfernten L54 auszulesen. Andererseits, wäre es möglich das du mir das skript mal schickst ? Dann könnte ich mir den Status auch zuschicken lassen.

[thomasgiger]

Allerdings ist es mit dem Reset auf egal welcher Seite nicht immer getan, manchmal funktioniert es, meist komme ich aber nicht drumrum zum anderen zu fahren und den neu zu starten.

Dann ist es doch nicht DASSELBE Problem. Bei uns kann auf jeder Seite neu gestartet werden. Es geht nur darum, einen AES Schlüsselaustausch zu triggern.

..., allerdings müsste das Gerät dann abstürzen wenn zu warm wird und nicht nach 24 Stunden

Ich meinte nicht eine thermischen Instabilität, sondern einen "warm-up" Event des Atheros-Chips, der unerkannt bleibt und daher auch nicht von einem Schlüsselaustausch gefolgt wird.

Andererseits, wäre es möglich das du mir das skript mal schickst ? Dann könnte ich mir den Status auch zuschicken lassen.

Leider nein. Das ist zwar ein Linux Shell Script und insofern portabel; es nutzt aber so viele Bibliotheksfunktionen unserer Router Firmware, dass es ohne diesen Kontext wesentlich erweitert werden müsste.

[Guenter]

Also der Fehler liegt bei uns definitiv nur am Master. sobald die Verbindung weg ist und neu gestartet werden muss, muss ich nur den Master neu starten und es funktioniert wieder.

[ristokom]

Hallo,

habe ähnliches Problem zwischen einem L-54ag und einem 1811, P2P Verbindung, exclusiv, AES Verschlüsselt, Kompression an.
Tritt aber nur sporadisch und nicht im 24h Rythmus auf. Reset auf Slave bringt nichts, es muss der Master in dem Fall der 1811 resetet werden. Mach ich über telnet : /other / cold-boot.
Danach ist wieder ruhe und alles läuft normal Link 24-36 Mbit.
Werde testen ob Kompression abschalten was bringt.

[ristokom]

Habe jetzt die Kopression abgeschaltet. Keine Änderung der Situation. Immer noch sporadische Abbrüche, meistens spät Abends oder Nachts. Hab seit zwei Tagen dir 5.02 drauf. Aber trotzdem keine Änderung.

[thomasgiger]

Der quasi-Zusammenhang mit der Uhrzeit könnte aus einem Zusammenhang mit der Betriebstemperatur resultieren (mein Verdacht seit längerer Zeit), die wiederum zu einem "thermal recalibration" Event führt, der aber nicht von einer Schlüsselaushandlung gefolgt wird.

In der 5.02 gibt es nun einen Parameter Experten-Konfiguration / Setup / WLAN / Therm.-Rekal.-Messzyklus, mit dem es möglich sein soll, dieses Feature ganz abzuschalten. Ich vermute aber nur, dass dies der Wert "0" sein könnte. Genaueres muesste uns Herr Arnold sagen.

[alf29]

Moin,

korrekt, ein Null schaltet das ab - wobei aber noch keiner weiß, was
das jetzt wieder für Nebenwirkungen haben wird...

Gruß Alfred

[mm_erde2000]

http://www.wlan-skynet.de/docs/rechtlic ... _893.shtml

Soviel zum Thema WLAN in 5.470 bis 5.725 GHz - Alle 24 Stunden eine Minute Zwangspause und 24 STUNDEN den Kanal in Ruhe lassen, wenn ein Radarsignal festgestellt wurde.

[alf29]

Moin,

Das mit der 24-Stunden-Sperre nach einer Radarerkennung stimmt nicht. Die
'Sperrzeit' beträgt lediglich 30 Minuten. Wenn der Kanal nach Ablauf dieser
Zeit (im Rahmen eines Channel Availibility Check) wieder als radar-frei erkannt
wird, darf er auch wieder benutzt werden.

Des weiteren wird während des Availibility Check das ganze Band überprüft, d.h.
es ist erlaubt, bei einer Radarerkennung ohne erneute Warteminute auf einen
anderen Kanal zu wechseln. Da die 'Gut-Erkennung' aber womöglich schon länger
zurückliegt, kann die Nutzungsdauer dieses neuen Kanals deutlich kürzer
als 24 Stunden sein, bis die Warteminute ansteht...

Diese Dinge sind seit LCOS 5.0x so implementiert und auch vorher mit der RegTP
so abgeklärt worden.

Gruß Alfred

[mm_erde2000]

Hallo Alfred,

danke für die Info. Wenn das langfristig so beibehalten werden darf, kann man damit ja leben.

Stimmt es den, das die EIRP fest auf 27dBm eingestellt werden darf?

Gruß, Michael

[alf29]

Stimmt es den, das die EIRP fest auf 27dBm eingestellt werden darf?

Im oberen Band sind bis zu 30 dBm EIRP erlaubt, allerdings muß die TPC
beachtet werden. Das heißt, Dein Aufbau muß die Möglichkeit bieten,
die Sendeleistung um bis zu 6 dB herunterregeln zu können. Da dies
üblicherweise durch Reduktion der Sendeleistung erfolgt und in den LANCOMs
die Sendeleistung nicht unter 0 dBm gestellt werden kann, begrenzt dies
den Gewinn, den eine Antenne abzüglich Kabelverlusten haben kann, auf
24 dBi.

Gruß Alfred

[thomasgiger]

Hmm. Aber ist es nicht so, dass TPC nur dann um 6dB herunterregeln muss, wenn ein Mehr an Sendeleistung nicht erforderlich ist?

Oder anders gesagt: Wenn ich für eine Verbindung über 6km eben nun mal volle 30 dBm EIRP brauche und ein Herunterregeln um 6dB zu einem ungenügend Zustand (Wechsel auf schlechtere Modulation) führen würde, dann müsste TPC auch nicht runterregeln.

Oder nochmal anders gefragt: Unter welchen anderen Umständen soll denn TPC herabregeln?