L-54ag <-> L-54ag Verbindungsabbruch ohne Absturz

[alf29]

Moin,

Soll das bedeuten, das geplant ist den Kanalwechsel ohne Unterbrechung zu realisieren? So wie die Geräte von Radionet das schon tun?
Ich würde mich mächtig freuen wenn das dann ginge.

Nein, das hat damit etwas zu tun, daß der AP im Normalbetrieb auch mal auf den
anderen Kanälen sich umschaut - eben um in größeren Installationen Rogue APs
zu finden.

Gruß Alfred

[Nils]

Moin,
mittlerweile habe ich das Problem noch weiter untersucht, dazu habe mit einem ping Gegenstelle -s 10000 eine konstante Last auf die Richtfunkstrecke gegeben.

Es ergibt sich bei dieser Strecke folgendes:
- Das Problem steht in keinem Zusammenhang mit Radarstörungen!
- Es gibt auch keinen Channelwechsel !
- Es gibt einfach keinen einzigen Logeintrag!

d.h. bei gleichbleibenden Channel und ohne Radarmeldungen bricht die Funkstrecke igendwann zusammen!

Der einzige Logeintrag der erscheint NACHDEM eins der beiden Geräte "warm" gestartet wurde, ist der:
Key handshake
und das wars!

Ich tippe schon fast auf ein Verschlüsselungsproblem (WPA2 / AES), gibt es da Vorgaben, ab welchem Volumen ein neuer Key getauscht wird, bzw. kann das schiefgehen ?

Leider kann ich meine Strecke nun wirklich nicht ohne Verschlüsselung laufen lassen.
Bin dankbar für jeden Hinweis!!!

Gruß,
Nils

[Nils]

Moin,
gibt es einen Befehl mit dem man den key handshake manuell erzwingen kann ? (z.B. per ssh)
[oder für disconnecten und wieder connecten ?]
Gruß,
Nils

[alf29]

Moin,

Du könntest das WLAN kurz aus- und wieder einschalten.


Gruß Alfred

[Nils]

Moin,
danke für den Tip. Per Weboberfläche habe ich dies auch schon hinbekommen, aber wie geht das bei ssh ?
[login]
cd /Setup/Interfaces/WLAN/Operational
set operating yes (oder) set operating 0
liefert immer 'operating': Table is full

Gruß,
Nils

[Nils]

Moin,
okay. Ich war nur zu blöd ..
So geht's natürlich:
set wlan-1 no
set wlan-1 yes
Gruß,
Nils

[reichi]

Hallo,

Ich bin Projektleiter eines FH-Projektes das u.A. die Anbindung eines Wohnheimes realisiert.

Seit kurzem setzen auch wir eine Lancom Wireless-Bridge als Ablöse für unsere alte 11 MBit HD-Anbindung ein. (2x L54ag +2x AirLancer Extender O-18a).

In Sachen Durchsatz kann ich wie meine Vorredner nicht meckern aber wir haben ebenfalls mit diesen merkwürdigen Ausfällen zu kämpfen.
Der AP ist über LAN pronblemlos erreichbar aber (wie ohnehin bereits geschildert) es geht kein traffic mehr "durch" den AP.

Beim Linktest zeigt zumindest eine Seite nach wie vor einen Korrekten WLAN-Link an.

Ich hoffe man kann für dieses Problem baldmöglichst eine Lösung finden, da dieser Zustand auf dauer für uns nicht akzeptabel ist (jede woche 2-3x einen AP neustarten kann einfach keine Lösung sein).

[alf29]

Ich hoffe man kann für dieses Problem baldmöglichst eine Lösung finden, da dieser Zustand auf dauer für uns nicht akzeptabel ist (jede woche 2-3x einen AP neustarten kann einfach keine Lösung sein).

Solange ich das Problem hier nicht nachstellen kann und
auch keinen Zugang zu einer Strecke bekomme, die
in diesem Zustand ist, kann ich da leider nicht helfen...

Gruß Alfred

[Nils]

Hallo,

seit heute 12:20 Uhr habe ich auf einem unserer Router eine perl+bash skript Kombi laufen, die einen Fehler erkennen kann und nur durch an+abschalten des WLAN-Moduls (geht sehr schnell) den Link wiederherstellen soll.

Ob das klappt, weiß ich nicht, wenn es klappt, poste ich die Skripte hier.

Auch dies wäre keine zufriedenstellende Lösung, aber man kann mit der bisherigen Anlage gut weiterarbeiten. Ich hoffe ebenfalls das Lancom das Problem mit Hilfe eines Firmware-Updates in den Griff bekommt. Ich vermute das sich die Schwierigkeiten ab der 5.0er eingeschlichen haben.

Ich freue mich zumindest, dass ich nicht der einzige bin, der diese Problem hat. Der P2P Basis <-> Basis weist übrigens das gleiche Problem wie P2P Basis <-> Client (im Client-Bridge-Mode) auf.

Gruß,
Nils

P.S. Schau dir mal
/Setup/TCP-IP/Alive-Test
an. Wenn du wirklich das gleiche Problem hast, bekommst du mit einem Warmstart auf einer der beiden Seiten den Link wiederhergestellt. Unser Gerät rebootet etwa 3 mal Tag. Ich hab' die Werte 10 1 1 15 genommen, damit man mitbekommt, dass es nicht vernünftig läuft. Aber das manuelle Rebooten treibt die Leute einfach in den Wahnsinn

[Nils]

Hi Alf,

ich könnte dir unsere Strecke mal zur Verfügung stellen. Was benötigst du denn genau? Brauchst du physischen Zugang zu den Geräten (Strecke steht in Aachen) oder reicht ein ssh-Zugang ?

Gruß,
Nils

[reichi]

same here, Zugang zur Strecke liese sich "notfalls2 schon $irgendwie einrichten.

[reichi]

Hallo nochmal,

Jetzt muss ich mich direkt nochmal melden.

Nach etwas überlegung ergibt sich eine ganz bestimmte Auffälligkeit:

Wir haben derzeit wieder Probleme mit Viren (erst seit kurzem).
Konkret gibt es Rechner die ENORM viele ARP-Requests versursachen.
Enorm viel bedeutet, dass ein einziger Client ca. 24 KB/sec ARP-Requests durchs LAN schickt (die gehen natürlich allesamt auch über die bridge).

In der Zeit in der wir keine solche "ARP-Schleudern" hatten gab es die Probleme auch nicht mehr, erst seit letzter Woche tritt das wieder auf, eigtl. hatte ich die Dose des Users disabled, hab aber jetzt erfahren, dass dieser seinen Rechner einfach im Gemeinschaftsraum angeschlossen hat in dieser Zeit....

Jetzt meine MÖGLICHE Folgerung:

Läuft da evtl. irgendein Cache/Buffer voll???

Ich mein 24 KB/sec ARP sind selbst im größten Netzwerk eigtl so gut wie nicht real...

@Nils: könntest du mit Ethereal mal nachsehen ob das auch in deinem Netzwerk so auftritt?

Wie gesagt: "Nur so eine Idee" bzw eine Beobachtung.
Ich denke dieses Szenario liese sich aus Seitens Lancom relativ einfach nachbilden (ARP-Requests erzeugen sollte ja für Programmierer kein Stress sein )

[Nils]

Hallo,
wäre natürlich schön, wenn man das so einfach in Griff kriegen würde. Interessanterweise hatte ich den letzten Ausfall heute Morgen. Im Schnitt tritt dies alle 8h auf. (Auf jeden Fall sind weniger Personen online)
Bei mir sieht das folgendermaßen aus:
Internet <-> Router <-> L-54ag <-> L-54ag <-> Router <-> Subnetz (mit 128 IPs)
Das Netz zwischen dem Router inkl. deren Interfaces befinden sich in einem Transportnetz mit 8 IPs, d.h. nur arp Pakete, welche von den Routern bzw. der APs generiert wurden, werden zwischen denen übertragen. Zur Sicherheit überprüfe ich dies gerade noch mit ethereal, aber der arp-Traffic scheint ziemlich gering zu sein. (Ein paar Pakete pro Minute)
Ich könnte natürlich auch mal Testen, was passiert, wenn ich mein eigenes Netz mit arp floode.
Ich hatte auch schon Anzahl offener Verbindungen oder ähnliches vermutet, aber für eine Bridge sollte das eigentlich alles keine Rolle spielen.

Gruß,
Nils

P.S. Mich würde mal interessieren, ob sich dein Problem wieder löst, wenn du diesen einen Rechner vom Netz nimmst. Wenn ja, wäre es interessant, was dieser Rechner genau macht.

[reichi]

Spontan würde ich sagen nein, das Problem löst sich nicht wenn der Rechner vom Netz genommen wird, da ich nicht davon ausgehe, dass infizierte Clients 24/7 laufen (wir haben ca. 200 Clients im Netzwerk) müsste der AP sich ja irgendwann mal selbstständig regenerieren und genau das ist bisher nie passiert.

Wie gesagt, die bisherige Beobachtung ist: es hilft nur ein Warmstart des APs.

[Nils]

Hallo Ihr,

@reichi: Ob die Clients 24/7 laufen oder nicht, spielt keine Rolle, denn wenn die Strecke erstmal verreckt ist, bleibt sie das auch. Es hilft ein Warm- oder Kalt-Start, aber auch das an und abschalten des Wlan-Moduls.

@all: In der Datei findet ihr meine Lösung für das Problem. Bis Lancom nachbessert kann man damit zumindest arbeiten. Die Idee ist die Gegenstelle regelmäßig zu pingen, sollte es fehlschlagen, wird es noch zwei Mal überprüft, ob die Gegenstelle vorhanden ist. Sollte dies nicht der Fall sein, loggt sich das perl-skript auf den kabelgebundenen AP (also nicht die Gegenstelle!) per telnet ein. Ich habe telnet genommen, weil es am einfachsten war und das Passwort könnte man auch nur sniffen, wenn man Zugang zum Kabel hat...
Der Vorteil gegenüber Kalt- und Warmstarts ist der, dass z.B. keine Logs verloren gehen.

Das eigentliche Problem kann ich leider nicht lösen, da ich keinen Zugang zum LCOS-Code habe. Eine weitere Vermutung von mir wäre, das irgendwo Störsignale mit hohen Peaks auftreten, die eventuell die Sende-Empfangseinheit zum Absturz bringen ?!?

Gruß,
Nils