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!
IAP-822 / Client trennt sich, bitte um Hilfe bei Log-Auswertung
Moderator: Lancom-Systems Moderatoren
Re: IAP-822 / Client trennt sich, bitte um Hilfe bei Log-Auswertung
Moin,
Viele Grüße
Alfred
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.Allerdings verstehe ich den Anmeldeprozess nicht. Wieso wird die Authentication zwei mal durchgeführt?
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.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?
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.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?
Wie davor schon explizit steht: "...due to station request". Der Client hat von sich aus beschlossen, sich abzumelden.Vor allem stört mich die Meldung: Disassociated because sending station is leaving (has left) BSS
Viele Grüße
Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Re: IAP-822 / Client trennt sich, bitte um Hilfe bei Log-Auswertung
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.
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.
Re: IAP-822 / Client trennt sich, bitte um Hilfe bei Log-Auswertung
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.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?
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.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.
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.Zwischen Meldung 66 und 606 bestand ja scheinbar eine Verbindung, von der wir aber nicht wissen wie lang sie bestand, oder?
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.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 kann durchaus passieren.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 der Client meint die Verbindung verloren zu haben und sich wieder neu anmeldet, dann wird das vom LANCOM genauso wie jede andere Anmeldung geloggt.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?
Du hast halt nur die Logs vom AP, und keine vom Client, wie der die Sache sieht.Irgendwie ist es nicht ganz so einfach anhand der Logs tatsächlich einen Verbindungsabbruch zu ernennen.
Viele Grüße
Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Re: IAP-822 / Client trennt sich, bitte um Hilfe bei Log-Auswertung
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!
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!
Re: IAP-822 / Client trennt sich, bitte um Hilfe bei Log-Auswertung
Moin,
Viele Grüße
Alfred
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 versteckenDer 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...
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...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.
Viele Grüße
Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015