IAP-822 / Client trennt sich, bitte um Hilfe bei Log-Auswertung

[Scallywag]

Hallo,

dies ist mein erster Post, da ich mich für mein Problem soeben hier angemeldet habe.

Da ich aber in Zukunft eine Menge Lancom APs überwachen muss, werde ich sicher öfters mal vorbei schauen.

Ich hoffe ihr könnt mir helfen.

Ein Client, der stationär betrieben wird trennt in unregelmäßigen Abständen die Verbindung zum AP.
Aus dem Log konnte ich fogendes entnehmen:

55 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Determined IPv6 address for station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): fe80::8c8ec642:f48e
56 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Determined IPv4 address for station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): 192.168.58.41
57 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Connected WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
58 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Key handshake with peer 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) successfully completed
59 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Associated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
60 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Authenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): algorithm is open-system
61 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Deauthenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): Disassociated because sending station is leaving (has left) BSS
62 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Disassociated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) due to station request: Disassociated because sending station is leav
63 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Connected WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
64 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Key handshake with peer 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) successfully completed
65 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Associated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
66 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Authenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): algorithm is open-system

606 2020-06-08 07:06:07 AUTH Hinweis [WLAN-1] Determined IPv6 address for station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): fe80::8c8ec642:f48e
607 2020-06-08 07:06:07 AUTH Hinweis [WLAN-1] Determined IPv4 address for station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): 192.168.58.41
608 2020-06-08 07:06:07 AUTH Hinweis [WLAN-1] Connected WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
609 2020-06-08 07:06:07 AUTH Hinweis [WLAN-1] Key handshake with peer 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) successfully completed
610 2020-06-08 07:06:07 AUTH Hinweis [WLAN-1] Associated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
611 2020-06-08 07:06:07 AUTH Hinweis [WLAN-1] Authenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): algorithm is open-system
612 2020-06-08 07:06:06 AUTH Hinweis [WLAN-1] Deauthenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): Disassociated because sending station is leaving (has left) BSS
613 2020-06-08 07:06:06 AUTH Hinweis [WLAN-1] Disassociated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) due to station request: Disassociated because sending station is leav
614 2020-06-08 07:06:06 AUTH Hinweis [WLAN-1] Connected WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
615 2020-06-08 07:06:06 AUTH Hinweis [WLAN-1] Key handshake with peer 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) successfully completed
616 2020-06-08 07:06:06 AUTH Hinweis [WLAN-1] Associated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
617 2020-06-08 07:06:06 AUTH Hinweis [WLAN-1] Authenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): algorithm is open-system
2294 2020-06-05 17:55:37 AUTH Hinweis [WLAN-1] Disassociated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) due to idle timeout


Ich interpretiere das jetzt mal so:

am 2020-06-05 um 17:55 wurde die Verbindung zur Station vom AP getrennt, da dieser seit 1 Stunde nicht mehr gesehen wurde. Das passt, da der Timeout auf 3600 steht. Am Wochenende wurde keine Verbindung hergestellt und heute früh um 07:06:06 wurde die Station wieder eingeschaltet. Das passt auch.

Allerdings verstehe ich den Anmeldeprozess nicht. Wieso wird die Authentication zwei mal durchgeführt? For allem Meldung 612 und 613 sind komisch.
Was passiert da? Ich entnehme dem, dass die Station dem AP selber mitteilt, dass es die Verbindung trennt, aber dann sofort wieder aufbaut? Kann das sein?

In den Meldungen 606 und 607 steht die Verbindung dann dauerhaft, da dort IP Adressen bestimmt werden konnten.
Dann wird mit Meldung 66 der Authentifizierungsprozess neu gestartet und es passiert exakt das selbe.

Sieht das LOG so korrekt aus?

Tatsächlich kommt es öfter in diesem Momenten zu kurzen Verbindungsabbrüchen und die Clientsoftware trennt die Verbindung zum Server.

Vor allem stört mich die Meldung: Disassociated because sending station is leaving (has left) BSS

Hat jemand eine Idee?



Danke!

[alf29]

Moin,

Allerdings verstehe ich den Anmeldeprozess nicht. Wieso wird die Authentication zwei mal durchgeführt?

Bin mir nicht sicher, auf welche Stelle im Log Du Dich da jetzt beziehst. Generell ist es bei 802.11 aber so, daß es eine "Legacy-Authentisierung" aus Zeiten der nicht mehr verwendeten WEP-Verschlüsselung gibt, die eigentlich gar keine ist (was der Name "open system" ausdrücken will), und eine "richtige", z.B. per 802.1X, die mit WPA eingeführt wurde und *nach* der Assoziierung abläuft. Das führt manchmal zu Verwirrung.

For allem Meldung 612 und 613 sind komisch.
Was passiert da? Ich entnehme dem, dass die Station dem AP selber mitteilt, dass es die Verbindung trennt, aber dann sofort wieder aufbaut? Kann das sein?

Ja, das heißt es, der Client hat sich abgemeldet und meldet sich gleich wieder an. Warum, das kann der AP nicht feststellen. Gängig ist z.B., daß ein Client auf einen anderen AP wegroamen will.

In den Meldungen 606 und 607 steht die Verbindung dann dauerhaft, da dort IP Adressen bestimmt werden konnten.
Dann wird mit Meldung 66 der Authentifizierungsprozess neu gestartet und es passiert exakt das selbe.

Sieht das LOG so korrekt aus?

Kann durchaus sein, auch wenn in den anderthalb Stunden nichts anderes bezüglich dieses Clients geloggt wurde, dann kann es einfach sein, daß der Client meint, die Verbindung verloren zu haben (d.h. er hat die Beacons vom AP nicht mehr gesehen). In so einem Fall meldet ein Client sich dann auch nicht mehr ab, denn der AP ist nach seiner Meinung ja nicht mehr erreichbar.

Vor allem stört mich die Meldung: Disassociated because sending station is leaving (has left) BSS

Wie davor schon explizit steht: "...due to station request". Der Client hat von sich aus beschlossen, sich abzumelden.

Viele Grüße

Alfred

[Scallywag]

Hallo Alfred,

danke für deine Antwort.

Nochmal kurz was zum Log:

55 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Determined IPv6 address for station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): fe80::8c8ec642:f48e
56 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Determined IPv4 address for station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): 192.168.58.41
57 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Connected WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
58 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Key handshake with peer 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) successfully completed
59 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Associated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
60 2020-06-08 08:34:50 AUTH Hinweis [WLAN-1] Authenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): algorithm is open-system
61 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Deauthenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): Disassociated because sending station is leaving (has left) BSS
62 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Disassociated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) due to station request: Disassociated because sending station is leav
63 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Connected WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
64 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Key handshake with peer 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31) successfully completed
65 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Associated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31)
66 2020-06-08 08:34:49 AUTH Hinweis [WLAN-1] Authenticated WLAN station 00:0e:8e:56:eb:31 (SparkLAN 56:eb:31): algorithm is open-system

Vielleicht vesrtehe ich es auch noch nicht, aber bei 66-63 wird eine Verbindung zum AP aufgebaut die in 62-61 wieder vom Vlient beendet wird, nur um sie dann in 60-57 wieder aufzbauen. Das alles passiert in weniger als 2 Sekunden. Ist das so korrekt?

Die Station wird stationär betrieben. Es sind zwar andere APs in der Nähe, aber eigentlich roamed der Client nicht weg. Das würde ja dann auch klar im Log drinstehen.

Zwischen Meldung 66 und 606 bestand ja scheinbar eine Verbindung, von der wir aber nicht wissen wie lang sie bestand, oder?
Der idle Timeout steht auf 1 Stunde. Das bedeutet, dass der Client auch längere Zeit schon keine Pakete mehr gesendet haben könnt und der AP
nicht wusste ob er überhaupt noch eingschaltet ist. Erst bei 1 Std. Inaktivität würde der AP dann die Verbindung trennen, richtig?

Das würde bedeutet, falls der Client Probleme hat und die Verbindung verliert, könnte es sein, dass der AP das gar nicht mitbekommt?
Wenn zu diesem Zeitpunkt eine Datenübertragung stattfinden muss würde meine Anwendung eine Fehlermeldung ausgeben.
Wenn dann auf einmal der Client wieder eine Verbindung zum AP hat, wird dass nicht wieder geloggt oder kommt es dann zu einer neuen Authentifizierung?

Irgendwie ist es nicht ganz so einfach anhand der Logs tatsächlich einen Verbindungsabbruch zu ernennen.

[alf29]

Vielleicht vesrtehe ich es auch noch nicht, aber bei 66-63 wird eine Verbindung zum AP aufgebaut die in 62-61 wieder vom Vlient beendet wird, nur um sie dann in 60-57 wieder aufzbauen. Das alles passiert in weniger als 2 Sekunden. Ist das so korrekt?

Nicht unbedingt sinnvoll, aber nicht unmöglich. Wie Clients "ticken" und warum sie dieses oder jenes machen, dazu müßte man in die Clients reinschauen, und das geht üblicherweise nicht, weil sie keine solchen ausführlichen Logs wie ein LANCOM bieten.

Die Station wird stationär betrieben. Es sind zwar andere APs in der Nähe, aber eigentlich roamed der Client nicht weg. Das würde ja dann auch klar im Log drinstehen.

In welchem Log? Ein Client muß sich nicht bewegen, um auf die Idee zu kommen, daß da noch ein anderer AP ist, den er "besser" findet. Und ich habe Roaming ja auch nur als einen möglichen Grund genannt, warum Clients sich abmelden.

Zwischen Meldung 66 und 606 bestand ja scheinbar eine Verbindung, von der wir aber nicht wissen wie lang sie bestand, oder?

Dazwischen fehlen Dir Log-Einträge? Dann weiß man es nicht, wie lange die Verbindung bestand, weder aus Sicht des AP, noch aus Sicht des Clients.

Der idle Timeout steht auf 1 Stunde. Das bedeutet, dass der Client auch längere Zeit schon keine Pakete mehr gesendet haben könnt und der AP
nicht wusste ob er überhaupt noch eingschaltet ist. Erst bei 1 Std. Inaktivität würde der AP dann die Verbindung trennen, richtig?

Clients müssen sich halt nicht regelmäßig beim AP 'melden'. Ein Client kann theoretisch tagelang 'still' sein und gar nichts senden. Kommt bei "normalen" Clients halt nicht vor und deshalb gibt es so etwas wie Idle-Timeouts, über die ein Client herausfliegt, dem z.B. der Saft ausgegangen ist und der sich gar nicht mehr abmelden konnte. Auf neueren LCOS-Versionen ist der Default für den Idle-Timeout noch deutlich niedriger.

Das würde bedeutet, falls der Client Probleme hat und die Verbindung verliert, könnte es sein, dass der AP das gar nicht mitbekommt?

Das kann durchaus passieren.

Wenn dann auf einmal der Client wieder eine Verbindung zum AP hat, wird dass nicht wieder geloggt oder kommt es dann zu einer neuen Authentifizierung?

Wenn der Client meint die Verbindung verloren zu haben und sich wieder neu anmeldet, dann wird das vom LANCOM genauso wie jede andere Anmeldung geloggt.

Irgendwie ist es nicht ganz so einfach anhand der Logs tatsächlich einen Verbindungsabbruch zu ernennen.

Du hast halt nur die Logs vom AP, und keine vom Client, wie der die Sache sieht.

Viele Grüße

Alfred

[Scallywag]

Der Client ist ein Windows PC mit Windows 10 2016 IOT ich fürchte da ist nichts zu loggen.
Wäre es Linux ginge sicher mehr...

Log-Einträge fehlen mir nicht. Ich habe dazwischen nur alle rausgelöscht da diese nur andere Clients betrafen.

Ich denke es liegt am Client, da die zahlreichen APs sonst einwandfrei arbeiten.
Vielleicht tauschen wir mal das WLAN Modul aus. Anonsten wird es schwierig.

Danke schon mal für deine Hilfe!

[alf29]

Moin,

Der Client ist ein Windows PC mit Windows 10 2016 IOT ich fürchte da ist nichts zu loggen.
Wäre es Linux ginge sicher mehr...

Ja, ein WPA-Supplicant ist da wesentlich gesprächiger. Wobei sich moderne Linux-Distributionen auch nach Kräften bemühen, so etwas vor dem "dummen Anwender" zu verstecken

Ich denke es liegt am Client, da die zahlreichen APs sonst einwandfrei arbeiten.
Vielleicht tauschen wir mal das WLAN Modul aus. Anonsten wird es schwierig.

Das wird es so oder so, wenn man den Anspruch erhebt, daß die Verbindung einfach immer zu stehen hat. Ich kenne das aus ein paar Industrie-Projekten, wo solche Forderungen nach "Null Paketverlust" und "Null Handover-Zeit" kamen. Da kann man Wochen über Wochen in die Suche nach Unterbrechungen versenken, die nur sporadisch auftreten. Dann hat man vielleicht einen Grund gefunden, die Unterbrechungen treten nur noch ein Mal in der Woche auf statt einmal am Tag und der Kunde ist immer noch nicht zufrieden...

Viele Grüße

Alfred