LEPS sporadisch Assoziierung abgelehnt

Allgemeine Fragen zu Themen die sonst nirgendwo passen

Moderator: Lancom-Systems Moderatoren

crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

LEPS sporadisch Assoziierung abgelehnt

Beitrag von crypticvision »

Hallo, ich habe schon seit längerem bei unterschiedlichsten Geräten die Fehlermeldung, daß die Assoziierung abgelehnt wird. Nach einem Geräteneustart ist alles wieder gut. Das Problem tritt in erster Linie bei meinen OAPs sowie bei derzeit einem L315 vermehrt auf. Ich nutze keine P2P Strecken. Alle Strecken basieren auf der AP/Client Technik. Ich vermute es liegt an LEPS. Ohne LEPS konnte ich dieses Phänomen noch nicht beobachten. Dummerweise kann ich nicht darauf verzichten. Ich habe auch beobachten können, daß das Problem besonders häufig bei viel Datenverkehr auftritt. Es betrifft immer den AP bei welchem sich der Client einbucht. Ich nutze WPA2-AES mit 63 Zeichen langen Passwörtern, welche mittels Passwortgenerator erstellt wurden. Ich habe immer gehofft, daß Problem wäre mit neueren Firmwareupdates behoben, aber langsam sehe ich keine Chance mehr, das überhaupt noch in den Griff zu bekommen. Es ist jedenfalls unschön, wenn einen die Kunden anrufen, weil das Internet nicht mehr geht und ich dann den betreffenden AP mit eben jener Fehlermeldung durchstarten muß. Das zeugt wenig von Professionalität, welche ich eigentlich von Lancom Geräten erwartete. Danke vorab für die Hilfe.
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,

Was genau für eine Meldung bekommst Du den nim
WLAN-Log? Wenn dort wirklich etzwas von abgelehnter
Assoziierung steht, dann hat das erstmal nichts mit LEPS
zu tun, denn das beeinflußt nur die für den WPA-Key-
Handshake verwendete Passphrase, und spielt für
die Assoziierung erstmal keine Rolle. Auf Probleme mit
der Passphrase würde es hindeuten, wenn Du im WLAN-
Log der APs Meldungen wie 'Timeout in Key Handshake'
bekommst.

Sind die MAC-Listen mit den LEPS-Passphrasen lokal
auf den APs gespeichert oder zentral auf einem RADIUS-
Server? Wenn letzteres, dann liegt Dein Problem evtl.
eher an dieser Stelle, d.h. die Prüfung der MAC-Adresse
per RADIUS klappt irgendwie nicht. Die APs cachen
RADIUS-Antworten eine (einstellbare) Zeit, um die Last
auf dem RADIUS-Server zu begrenzen, und nach einer
negativen Antwort lehnen sie für diese Zeit auch ab -
das könnte das beschriebene Phänomen schon eher
erklären.
Es ist jedenfalls unschön, wenn einen die Kunden anrufen, weil das Internet nicht mehr geht und ich dann den betreffenden AP mit eben jener Fehlermeldung durchstarten muß. Das zeugt wenig von Professionalität, welche ich eigentlich von Lancom Geräten erwartete. Danke vorab für die Hilfe.
Bist Du mit Deinem Problem denn in der Vergangenheit
schon einmal an den LANCOM-Support herangetreten?
Wenn nicht, dann kann sich auch keiner um Dein Problem
kümmern...

Gruß Alfred
crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

Beitrag von crypticvision »

Die Meldung erscheint im Lanmonitor mit rotem Ausrufezeichen.
Ich kann im Moment leider nicht sagen, was im WLAN Log gestanden hat, da der Eintrag wahrscheinlich unten raus gerutscht ist. Häufige Einträge sind

Index 200
Zeit 27.10.2009 11:33:06
Interface WLAN-1
Ereignis WLAN card 00:07:d5:01:3b:0a [] hung (), resetting
Adresse 0007d5013b0a
Grund too many radar pulses in short distance (unplausible)

aber da kann man wohl nichts machen. Ich weiß nicht, ob es da einen Zusammenhang gibt. Dasselbe Problem habe ich auch auf dem anderen OAP, der am selben Mast hängt. Trotz dieser Meldungen läuft es aber. Ich habe noch keinen zentralen RADIUS, obwohl das in Zukunft kommen soll. Bisher sind alle Passwörter lokal auf den jeweiligen APs gespeichert.

An den Lancom Support bin ich noch nicht herangetreten. Ich wollte es erstmal hier versuchen. Vielleicht haben ja auch andere das Problem und eine passende Lösung parat. Ich hab mich jetzt beim Partnerprogramm registriert und bekomme dann vielleicht kostengünstigen Support. Die 0900 Hotline ist eher die letzte Wahl.
Benutzeravatar
Jirka
Beiträge: 5288
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Beitrag von Jirka »

Hallo crypticvision,
crypticvision hat geschrieben:aber da kann man wohl nichts machen.
Nö. Man nicht. Aber möglicherweise Andere. Und mit einer entsprechenden Dokumentation des Problems kann man die Anderen über das Problem informieren bzw. Ihnen soviele Infos zukommen lassen, dass sie das Problem nachstellen oder lösen können. *Kopfschüttel*

Kannst Du mir mal bitte sagen, ob Du den (MAC-)Stations-Filter auf der entsprechenden SSID nutzt? (Man kann LEPS auch ohne selbigen nutzen.) Also ob MAC-Filter unter den Logischen WLAN-Einstellungen aktiviert ist. Und falls ja, tritt das Problem auch auf, wenn Du den MAC-Filter deaktivierst? (bei WPA-2 ist ein Deaktivieren des MAC-Filters kein Sicherheitsrisiko).

Vielen Dank und viele Grüße,
Jirka
crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

Beitrag von crypticvision »

Hallo Jirka,

da brauchst Du gar nicht mit dem Kopf zu schütteln. Wenn ich das Problem reproduzieren könnte, hätte ich den Fehler wahrscheinlich schon selbst gefunden. Der MAC Stations Filter war bei beiden APs am Mast aktiviert. Ich habe diesen nun bei beiden deaktiviert. Funktioniert soweit erstmal, nur ob das von Dauer ist, wird sich erst im laufe der Zeit zeigen. Wie gesagt, der Fehler trat sporadisch auf.
Was die Radarpulse angeht, so sehe ich da aber keinen Zusammenhang. Ich vermute, daß sich die APs gegenseitig zumüllen an den zwei OAPs hängt an jedem Main Ausgang eine Sektorantenne über jede die selbe SSID im 5 GHz Unterband 2, also insgesamt 4 Stück. Roaming ist aktiviert und funktioniert soweit auch. Es sind übrigens OAPs der ersten Generation, falls das von Bedeutung ist.
crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

Beitrag von crypticvision »

So, heute ist der Fehler erneut aufgetreten. Der Stationsfilter scheint nicht mittelbar daran beteiligt zu sein. Ich habe testweise TX Burst und Kompression zugeschaltet und da passierte es recht zeitnah. Nach dem Abschalten stabilisierte sich die Sache wieder etwas, aber so richtig läuft es noch nicht. Die Logs der WLAN Module sind da recht unaussagekräftig.

AP1:

Index 69 Zeit 21.10.2009 12:06:01 Interface WLAN-2 Ereignis Rejected Association from WLAN station 00:0b:6b:2a:ff:d0 []: () Adresse 000b6b2affd0 Grund Unspecified Failure

Index 83 Zeit 21.10.2009 12:15:33 Interface WLAN-2 Ereignis Rejected Authentication from WLAN station 00:0b:6b:2a:ff:d0 []: () Adresse 000b6b2affd0 Grund Responding station does not support the specified authentication algorithm

Das Letztere ist natürlich völliger Blödsinn. Freilich unterstützt die Station das, im Normalfall läuft es ja.

AP2:

Index 23 Zeit 30.10.2009 10:36:00 Interface WLAN-1 Ereignis WLAN card 00:07:d5:01:3b:0a [] hung (), resetting Adresse 0007d5013b0a Grund too many radar pulses in short distance (unplausible)

Index 24 Zeit 30.10.2009 10:36:00 Interface WLAN-1 Ereignis Rejected Association from WLAN station 00:0b:6b:2c:c9:dc []: () Adresse 000b6b2cc9dc Grund Unspecified Failure

Es könnte natürlich mit den falschen Radarerkennungen zu tun haben, bloß wie bekomme ich das weg?

Hier nochwas von AP1. Der will mit der Station offensichtlich garnicht mehr:

WLAN protocol error communicating with 00:0b:6b:2a:ff:d0 []

Im Moment wollen mich meine APs ärgern. Ich kann nur noch versuchen eine schwächere Verschlüsselung einzustellen, aber das kann nicht der Sinn der Sache sein. Es wäre sehr hilfreich, wenn mal jemand einen Tip geben könnte. Danke!
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

ndex 69 Zeit 21.10.2009 12:06:01 Interface WLAN-2 Ereignis Rejected Association from WLAN station 00:0b:6b:2a:ff:d0 []: () Adresse 000b6b2affd0 Grund Unspecified Failure

Index 83 Zeit 21.10.2009 12:15:33 Interface WLAN-2 Ereignis Rejected Authentication from WLAN station 00:0b:6b:2a:ff:d0 []: () Adresse 000b6b2affd0 Grund Responding station does not support the specified authentication algorithm

Das Letztere ist natürlich völliger Blödsinn. Freilich unterstützt die Station das, im Normalfall läuft es ja.
Dazu müßte man jetzt den Authentication Request vom Client sehen. Wenn da etwas anderes als Open System
als Algorithmus drinsteht (warum auch immer...), dann
hat der AP schon recht, daß er das ablehnt.

Unspecified Failure kann verschiedene Gründe haben:

- Der Association Request kommt mit einer falschen SSID
- Das WPA-Infoelement im Association Request fehlt oder
ist kaputt.
- Die Stationstabelle im Gerät ist voll (das sähe man im
WLAN-Status recht leicht).

Es könnte natürlich mit den falschen Radarerkennungen zu tun haben, bloß wie bekomme ich das weg?
Nein, das dürfte ein anderes sein. Du kannst natürlich DFS
ausschalten oder an den Radar-Schwellwerten herumdrehen,
legal ist das natürlich nicht. Aber false positives sind leider
ein bekannte Problem, besonders auf Geräten mit
älteren Funkmodulen (vor AR5414)
Hier nochwas von AP1. Der will mit der Station offensichtlich garnicht mehr:

WLAN protocol error communicating with 00:0b:6b:2a:ff:d0 []
Was steht denn überhaupt auf der anderen Seite?

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

Beitrag von crypticvision »

Unspecified Failure kann verschiedene Gründe haben:

- Der Association Request kommt mit einer falschen SSID
- Das WPA-Infoelement im Association Request fehlt oder
ist kaputt.
- Die Stationstabelle im Gerät ist voll (das sähe man im
WLAN-Status recht leicht).
Ersteres ist ausgeschlossen, da sich die SSID ja nicht auf einmal ändert. Das zweite hielte ich für wahrscheinlich, wobei sich hier die Frage stellt, was ich dagegen tun könnte. Das Letzte ist es auch nicht, da aktuell nur 4 Stationen dranhängen. Alle Stationen auf Basis AR5414 (2x OAC-54-1, 1x C-54ag, 1x L54 dual WLAN1), aber nur der L54 dual zickt besonders rum.
Nein, das dürfte ein anderes sein. Du kannst natürlich DFS
ausschalten oder an den Radar-Schwellwerten herumdrehen,
legal ist das natürlich nicht. Aber false positives sind leider
ein bekannte Problem, besonders auf Geräten mit
älteren Funkmodulen (vor AR5414)
Da hilft wohl nur tauschen gegen neue OAPs, aber das ist auch ein finanzielles Problem. Wobei dann falsche Radarerkennung nicht ausgeschlossen ist. Gerade wenn man beide Funkmodule auf der selben Frequenz und im selben Modus mit selber SSID betreibt, ist die Gefahr des sich selbst zumüllens recht hoch. Da gibt es sicher noch einiges an Entwicklungsarbeit zu leisten.
Was steht denn überhaupt auf der anderen Seite?
Da steht dann z.B. sowas:

Index 45
Zeit 30.10.2009 19:56:19
Interface WLAN-2
Ereignis Lost connection to WLAN AP 00:0b:6b:2f:08:1e []:
Adresse 000b6b2f081e
Grund Beacon Timeout


Das schlimme daran ist, daß es eben gerade einen Teil meines Backbones besonders betrifft und nicht einfach nur ein paar kleinere Stationen bei Kunden. Ein weiteres Problem ist die physikalische Lage der OAPs. Zum Austausch muß ich in 80 Meter Höhe an einen Industrieschornstein. Gerade in den kommenden Monaten dürfte das keine Freude bereiten. Ich muß zusehen, daß ich das softwaretechnisch in den Griff bekomme.

Danke soweit erstmal für die Mithilfe!
crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

Beitrag von crypticvision »

Dazu müßte man jetzt den Authentication Request vom Client sehen. Wenn da etwas anderes als Open System
als Algorithmus drinsteht (warum auch immer...), dann
hat der AP schon recht, daß er das ablehnt.
Ich wollte nur noch kurz erwähnen, daß hier natürlich nichts anderes als Open System drin steht, immerhin kann man den Eintrag bei der Auswahl von WPA und AES ja nichtmal ändern, da ausgegraut (zumindest per Lanconfig).

Wie gesagt, das Ganze tritt mitten im Betrieb auf, während des Datentransfers. Auf der WLAN Strecke, über die sich der L54 dual eingängt, habe ich momentan nur den 54 MBit Modus laufen. Alle anderen laufen im Turbomodus. Dies schaffte zumindest kurzfristig Abhilfe, da der AP, welcher sich als Client einbucht, heute alle viertel Stunde die Assoziierung verloren hat. Ich frage mich ehrlichgesagt, ob ich der Einzige bin, der so ein Problem hat? Es betrifft unterschiedlichste Lancom Geräte unterschiedlichster Generation. Da liegt doch irgendwas im Argen!?
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,
Ich wollte nur noch kurz erwähnen, daß hier natürlich nichts anderes als Open System drin steht, immerhin kann man den Eintrag bei der Auswahl von WPA und AES ja nichtmal ändern, da ausgegraut (zumindest per Lanconfig).
Daß Du das nicht konfigurieren kannst, mag schon sein, aber das Log sagt nun einmal, daß
der AP einen Authentication Request von dieser Adresse mit etwas anderem als Open
System bekommen hat. Und MAC-Adressen lassen sich beliebig fälschen. Du hast nicht
zufällig irgendeinen Scherzkeks in der Gegend, der...?
Das Letzte ist es auch nicht, da aktuell nur 4 Stationen dranhängen.
Auch da gibt es Angriffstools, die versuchen, den AP zu fluten. Schau in so einem Fall
doch einfach mal in die Stationstabelle auf dem AP rein - dann wissen wir's...

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

Beitrag von crypticvision »

Das kann ich beides nicht bestätigen. Jetzt, nachdem ich die Strecke zum L54 dual auf den normalen 54 MBit Betrieb ohne allen Schnickschnack umgestellt habe, tritt der Fehler erstmal nicht mehr auf. Der Lancom Support sagte mir, ich solle einen Trace laufen lassen, weiß aber nicht genau, was ich da tracen soll. Vielleicht kannst Du mir mal sagen welche Werte hier aussagekräftig sind. Dann lasse ich den Trace laufen und stell die Strecke wieder auf den Turbomodus um und nehm die Kompression sowie den TX Burst rein. Dann ist es nur noch eine Frage der Zeit, bis es wieder passiert. Kommt dann manchmal in 5-10 Minuten und manchmal brauchts ne Stunde. Aber der Fehler tritt dann mit Sicherheit auf, irgendwann...
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,

laß die Kompression aus, die bringt eh in der Praxis so gut wie nix und spätestens bei 108 MBit
wird die Sache eher langsamer als schneller...

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

Beitrag von crypticvision »

Sag mir doch bitte nochmal, was ich wegen den Traces zu tun habe.
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,

wenn man wirklich die kaputten Pakete sehen will, dann landet man bei einem WLAN-Data-Trace.
Den sollte man allerdings tunlichst erst anmachen, wenn man in dieser Situation ist, und mittels
Setup->WLAN->Trace-MAC die Ausgabe der empfangenen Pakete auf diese Gegenstelle zu
beschränken.

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
crypticvision
Beiträge: 157
Registriert: 22 Mai 2009, 21:58

Beitrag von crypticvision »

Das mit dem Trace hab ich irgendwie nicht raus. Ich brauche wohl mal eine Anleitung, wie ich an die entsprechende Stelle komme. Jedenfalls
Setup->WLAN->Trace-MAC
hab ich nirgends gefunden. Ich gehe im Lanmonitor auf das entsprechende Gerät und im Menü auf Traces... und ab da gibts eine Menge Möglichkeiten, nur nicht die zitierte.

Die Probleme treten leider laufend auf. Ich bin offenbar der Einzige, der Sie hat. Ich denke übrigens gerade darüber nach, Geräte anderer Hersteller einzusetzen, da ich es einfach nicht in den Griff bekomme. Ein Mitbewerber benutzt Geräte von Ubiquiti Networks und scheint damit ganz gut zu fahren. Außerdem sind diese teilweise für ein Zehntel des Preises zu haben.

So long... ein enttäuschter Lancom Nutzer mit ca. 100 Geräten im Bestand.
Antworten