Wlan Abbrüche dokumentieren

[MSfree]

Die FB loggt nicht den genauen Zeitpunkt des Abbruchs der WLAN-Verbindung.

Das meinte ich damit, als ich weiter oben schrub:

Abbrüche lassen sich in der Regel gar nicht erkennen. Das, was man erkennen kann, ist, wenn das System die Verbindung (erneut) aufbaut.

Auch die Fritzbox kann nur annehmen, daß, nach Ablauf eines Zeitintervalls, die Verbindung als nicht mehr existent zu werten ist.

[mat6937]

Die FB loggt nicht den genauen Zeitpunkt des Abbruchs der WLAN-Verbindung.

Das meinte ich damit, als ich weiter ober schrub:

Abbrüche lassen sich in der Regel gar nicht erkennen. Das, was man erkennen kann, ist, wenn das System die Verbindung (erneut) aufbaut.

Naja, mit dem wpa_cli und den events "CONNECTED" und "DISCONNECTED" kann man schon den Abbruch genau erkennen. Z. B.:

Code: Alles auswählen

wpa_supplicant: connection lost, Thu 1 Dec 00:04:37 CET 2016
wpa_supplicant: connection established, Thu 1 Dec 00:06:39 CET 2016

[MSfree]

Naja, mit dem wpa_cli und den events "CONNECTED" und "DISCONNECTED" kann man schon den Abbruch genau erkennen. Z. B.:

Code: Alles auswählen

wpa_supplicant: connection lost, Thu 1 Dec 00:04:37 CET 2016
wpa_supplicant: connection established, Thu 1 Dec 00:06:39 CET 2016

Auch die Uhrzeit, die bei "connection lost" steht, ist nicht der exakte Moment, als die Verbindung abgebrochen ist sondern meist der Moment, nachdem ein Timeout abgelaufen ist, wonach die Verbindung als abgebrochen betrachtet wird.

[DeletedUserReAsG]

Das ist bei jeder Verbindung so. Wie sonst würde man „Abbruch“ definieren, als durch „Gegenstation hat bis zum Ablauf des Timers nicht reagiert“? Ich meine, „Gegenstation hat uns gesendet, dass die Verbindung abgebrochen ist“ wäre irgendwie ’n dämliches Kriterium …

[mat6937]

Auch die Uhrzeit, die bei "connection lost" steht, ist nicht der exakte Moment, als die Verbindung abgebrochen ist sondern meist der Moment, nachdem ein Timeout abgelaufen ist, wonach die Verbindung als abgebrochen betrachtet wird.

Woher hast Du diese Information?

Die Zeiten die der wpa_cli (mit dem event "DISCONNECTED") anzeigt, entsprechen genau den Zeiten die auch im kernel ring buffer (für "connection lost") angezeigt werden.

[mat6937]

Das ist bei jeder Verbindung so. Wie sonst würde man „Abbruch“ definieren, als durch „Gegenstation hat bis zum Ablauf des Timers nicht reagiert“?…

Nein, den der Kernel bzw. wpa_cli/wpa_supplicant braucht keine Gegenstation um festzustellen, dass er selber im einem "verbindungslosen Zustand" ist. Hier muss keine Gegenstation das feststellen/anzeigen bzw. darauf reagieren.

[DeletedUserReAsG]

Eine Verbindung sehe zumindest ich dann als abgebrochen, wenn die Gegenstation nicht reagiert. Um das festzustellen, muss man aber einen Timer setzen, weil ohne sowas bei jeder Verzögerung die Verbindung als abgebrochen gelten würde (also bei jedem einzelnen Paket, weil es immer eine Latenz gibt).

Wenn nun, wie du sagst, die Erreichbarkeit/Reaktion der Gegenstation ohne Belang sein sollte – wie genau wird dann die Verbindung definiert? Angenommen, meine Verbindung bricht ab, weil die Gegenstelle gestorben ist – anhand welchen Kriteriums registriert der wpa_supplicant das, wenn die ausbleibende Reaktion der Gegenstelle innerhalb einer bestimmten Zeit nicht der Indikator ist?

[mat6937]

Wenn nun, wie du sagst, die Erreichbarkeit/Reaktion der Gegenstation ohne Belang sein sollte – wie genau wird dann die Verbindung definiert?

Naja, praktisch ist das zumindest so, dass der wpa_supplicant sich in einem Zustand befinden muss, in dem er (im Zuge des rekeying) das eapol-request der Gegenstelle/AP erkennen kann und auch (sofort) mit einem eapol-reply darauf antwortet/reagiert.
Oder der wpa_supplicant sollte in der Lage sein, entsprechend seiner Konfiguration, periodische scans der Gegenstelle/AP durchzuführen. Wenn er das nicht ist, und das kann ja "intern" (d. h. ohne eine Reaktion der Gegenstelle/AP) erkannt werden, dann ist der wpa_supplicant im verbindungslosen Zustand.

Angenommen, meine Verbindung bricht ab, weil die Gegenstelle gestorben ist – anhand welchen Kriteriums registriert der wpa_supplicant das, wenn die ausbleibende Reaktion der Gegenstelle innerhalb einer bestimmten Zeit nicht der Indikator ist?

Das ist dann der andere/gegenteilige Fall (d. h. der AP ist nicht mehr vorhanden, evtl. temporär wegen reboot, etc.). Natürlich kann auch die ausbleibende Reaktion der Gegenstelle (AP) dazu führen, dass die Verbindung abgebrochen wird. Der wpa_supplicant kann auch so konfiguriert sein, dass er periodische scans an den AP macht oder, dass er selber auch rekeying (wpa_ptk_rekey) macht. Wenn darauf die Gegenstelle nicht entsprechend reagiert/antwortet, wird der verbindungslose Zustand des wpa_supplicant eintreten bzw. vorhanden sein, der dann mit Hilfe der event-Variable "DISCONNECTED" angezeigt/ermittelt werden kann bzw. darauf auch reagiert werden kann.

Wenn man genau wissen will wie das ím source code (der ja zugänglich ist) des wpa_supplicant/wpa_cli umgesetzt/programmiert ist, kann man ja dort nachschauen.

[DeletedUserReAsG]

… mit anderen Worten: die ausbleibende Reaktion der Gegenstelle innerhalb eines definierten Zeitfensters ist also doch das Kriterium.

[mat6937]

… mit anderen Worten: die ausbleibende Reaktion der Gegenstelle innerhalb eines definierten Zeitfensters ist also doch das Kriterium.

Kann ein Kriterium sein, ist aber nicht das einzige Kriterium. Es bedarf auch nicht einer ausbleibenden Reaktion innerhalb eines bestimmten Zeitfensters. Je nach Art und Weise, wie der wpa_supplicant gerade bzw. weshalb (d. h. nur rekeying oder sofortige Nutzdatenübertragung oder ...?) mit der Gegenstelle kommunizieren will/muss, kann der verbindungslose Zustand auch "sofort"/zeitnah eintreten, festgestellt und angezeigt werden.

Wenn die Gegenstelle/AP mal richtig konfiguriert ist, ist das ausbleiben einer Reaktion durch die Gegenstelle/AP, ganz selten durch die Gegenstelle/AP selber verursacht. Meistens liegt das Problem beim WLAN-Client oder es sind Störungen von extern auf das WLAN.

[DeletedUserReAsG]

Kann ein Kriterium sein, ist aber nicht das einzige Kriterium.

Das war ja meine Frage: welches Kriterium kann herangezogen werden, bei dem das Ausbleiben von Reaktionen der Gegenstelle nicht involviert ist? Ich als Laie kann mir da nämlich keines vorstellen – schließlich definiert sich für mich eine Verbindung aus zwei Punkten, die miteinander kommunizieren. Du sagst die ganze Zeit, das geht – und ich frage immer noch: wie? Wenn Nutzdaten gesendet werden sollen und es gibt keine Antwort, oder wenn Rekeying ansteht und es gibt keine Antwort usw. – alles Sachen, bei denen letztlich das Ausbleiben einer Reaktion der Gegenstelle nach einer gewissen Zeit (denn Latenzen gibt’s nunmal immer, deswegen muss es eine gewisse Wartezeit geben) zur lokalen Erkenntnis führt, dass die Verbindung wohl weg sein muss.

Ich kann mir nix vorstellen, bei dem der lokale wpa_supplicant unabhängig von der Gegenstelle sagt „Verbindung ist weg“. Das Einzige wären Probleme mit dem eigenen Interface, aber das taucht im Log auf.

OT: du solltest meinen Text nicht rot anmalen. Einerseits wirkt das ziemlich agressiv, und andererseits ist’s per Konvention den Mods vorbehalten (die nunmal ziemlich agressiv sind – scnr).

[mat6937]

... – schließlich definiert sich für mich eine Verbindung aus zwei Punkten, die miteinander kommunizieren.

Ja, und wenn einer dieser beiden Punkte aufhört zu kommunizieren (... aus einem Grund der ihm bekannt ist und auch nur an ihm liegt), dann kann dieser Punkt sich doch als "verbindungslos" erklären.

Ich kann mir nix vorstellen, bei dem der lokale wpa_supplicant unabhängig von der Gegenstelle sagt „Verbindung ist weg“.

Es ist aber so. Wenn Du es genau wissen willst, kannst ja mal bei den Entwickler vom wpa_supplicant bzw. wpa_cli anfragen: http://w1.fi/wpa_supplicant/

[DeletedUserReAsG]

Mit deinem dir selbst Widersprechen verwirrst du mich. Deine Beispiele involvieren alle, dass die Gegenstation nicht mehr erreichbar ist/nicht mehr reagiert, gleichzeitig betonst du, dass der Status der Gegenstelle dabei nicht von Bedeutung ist. Was denn nun?

[mat6937]

Mit deinem dir selbst Widersprechen ...

Ich kann keinen Widerspruch erkennen, in dem was ich geschrieben habe.

Deine Beispiele involvieren alle, dass die Gegenstation nicht mehr erreichbar ist/nicht mehr reagiert, gleichzeitig betonst du, dass der Status der Gegenstelle dabei nicht von Bedeutung ist. Was denn nun?

So ist es, die Gegenstelle ist nicht mehr erreichbar, wenn die Verbindung abgebrochen ist (egal wer das verursacht hat).

Und das betone ich erneut, ja der "Status der Gegenstelle ist nicht von Bedeutung", denn der wpa_supplicant/wpa-cli kann (auch ohne den Status der Gegenstelle) selber erkennen (... den Zeitpunkt betreffend, mal genau bzw. mal weniger genau) wann bzw. ob die Verbindung unterbrochen worden ist. D. h., man ist auf den Status der Gegenstelle nicht angewiesen.

[DeletedUserReAsG]

Ach, ich geb’s auf. Für’s Topic: die Ausgabe von wpa_supplicant ist geeignet, tatsächliche Abbrüche zu dokumentieren. Allerdings ist’s gerade bei gestörtem WLAN auch gerne mal so, dass einige Sekunden lang gar nichts durchkommt und dann die gesammelten Pakete in einem Rutsch durchgehen – für den Fall ist die Auswertung der Ausgaben von wpa_supplicant oder der Logs nicht zielführend, weil es technisch kein Verbindungsabbruch ist.

OT: Wie der Abbruch einer Verbindung festgestellt werden soll, wenn die Nichterreichbarkeit der Gegenstelle dafür nicht maßgeblich ist, fragt am besten den mat6937 – mit Philosophie hab’ ich es nicht so; in meiner Welt ist die Erreichbarkeit der Gegenstelle der Maßstab, ob die Verbindung steht oder nicht, und wenn wpa_supplicant nicht mit Quantenmagie arbeitet, kann’s da auch nicht anders sein.

[mat6937]

Allerdings ist’s gerade bei gestörtem WLAN auch gerne mal so, dass einige Sekunden lang gar nichts durchkommt und dann die gesammelten Pakete in einem Rutsch durchgehen – für den Fall ist die Auswertung der Ausgaben von wpa_supplicant oder der Logs nicht zielführend, weil es technisch kein Verbindungsabbruch ist.

Das hat jetzt aber nichts mit dem Titel dieses Threads zu tun, denn der heißt "Wlan Abbrüche erkennen". Du willst jetzt ein "gestörtes Wlan" daraus machen. OK, aber das ist dann was ganz anderes. Was Du jetzt beschrieben hast, ist auch kein Wlan-Abbruch und wird deshalb auch nicht mit Hilfe des DISCONNECTED-events erkannt werden können, geschweige denn, in irgend welchen Logs/buffers (Client/gegenstelle) eingetragen sein. Wir sprechen hier von Unterbrechungen/Abbrüchen.

[DeletedUserReAsG]

Das hat jetzt aber nichts mit dem Titel dieses Threads zu tun, […]

Nein, aber ich habe den Thread und die weiteren Posts des Threadstarters gelesen. Du nicht?

Ich verbitte mir das rote Anmalen meines Textes. Ich glaube, ich hatte schon einmal höflich drauf hingewiesen, dass sowas hier allgemein, und von mir im Speziellen, nicht erwünscht ist. Danke.

[mat6937]

Nein, ...

Ok, das habe ich dann nicht richtig verstanden. Das hat dann mit meinen Beiträgen, nichts zu tun gehabt.

[Emess]

Hallo!
Ich hab den thread gestartet und weiss immer noch nicht was ich eingeben muss und wo das log rauskommt.
Ja. Ich hab keine Ahnung von scripts und was weiss immer.
Wenn mir also jemand genau sagen könnte wie das geht ( also was ich da reintippen muss ), wäre ich entzückt.
Dann würde ich euch auch gerne an all meinen Lebensweisheiten teilhaben lassen, die ich mir erarbeitet oder an gelesen habe.
Also ich steh nach wie vor auf dem Schlauch.
Ich will doch nur wissen ob meine Box Scheiße ist oder der Amazon Stream einen zu kleinen Puffer benutzt.
Wahrscheinlich ist beides der Fall!
Die Wahrheit muss doch irgend wo da draußen sein?

Die Verwirrung wird größer und größer

[BenutzerGa4gooPh]

Code: Alles auswählen

su
ping -i 5 google.de | xargs -L 1 -I '{}' date '+%Y-%m-%d %H:%M:%S: {}' | tee test.txt

Die Datet test.txt findest du im home-Verzeichnis.
Wenn du anstelle von google.de 8.8.8.8 eingibst, "umgehst" du Namensauflösung.
Wenn du anstelle von google.de deinen Default-Gateway eingibst, testest du nur dein internes Netz (einschl. deines WLANs und ohne DNS).
Wenn du die Zahl hinter -i änderst, wird die Wartezeit zwischen 2 Pings anders. Derzeit 5 sec. Siehe

Code: Alles auswählen

man ping

Alles schon in meiner ersten AW verlinkt.

Deinen Default-Gateway (Router) findest du mit

Code: Alles auswählen

su
ip route

Logischer Testablauf: Befehle mal kurz ausprobieren. Dann Test Default-GW. Dann Test 8.8.8.8. Dann Test google.de. So kann man schon etwas den Fehler eingrenzen. Wenn du umgekehrt beginnst, kann es an allem liegen. Wenn Fehler bis zum Default-GW vorliegen, teste mit Netzwerkkabel zwischen PC und Router. Damit weißt du, ob es an deinem WLAN liegt.

Außerdem würde ich mal die Logs des Routers auf Fehler durchsehen! Geht am schnellsten und sagt vlt. schon was. Auch schon geschrieben.

[mat6937]

Die Wahrheit muss doch irgend wo ...

Poste mal die Ausgaben von:

Code: Alles auswählen

lsmod | grep -i cfg
dmesg -T | grep -iE 'cfg|auth'
ps aux | grep -i [w]pa

Evtl. sofort nach dem Start deines Gerätes und nach dem Du den Eindruck hattest, dass die WLAN-Verbindung unterbrochen worden ist.

[Emess]

Code: Alles auswählen

su
ping -i 5 google.de | xargs -L 1 -I '{}' date '+%Y-%m-%d %H:%M:%S: {}' | tee test.txt

Die Datet test.txt findest du im home-Verzeichnis.
Wenn du anstelle von google.de 8.8.8.8 eingibst, "umgehst" du Namensauflösung.
Wenn du anstelle von google.de deinen Default-Gateway eingibst, testest du nur dein internes Netz (einschl. deines WLANs und ohne DNS).
Wenn du die Zahl hinter -i änderst, wird die Wartezeit zwischen 2 Pings anders. Derzeit 5 sec. Siehe

Code: Alles auswählen

man ping

Alles schon in meiner ersten AW verlinkt.

Deinen Default-Gateway (Router) findest du mit

Code: Alles auswählen

su
ip route

Logischer Testablauf: Befehle mal kurz ausprobieren. Dann Test Default-GW. Dann Test 8.8.8.8. Dann Test google.de. So kann man schon etwas den Fehler eingrenzen. Wenn du umgekehrt beginnst, kann es an allem liegen. Wenn Fehler bis zum Default-GW vorliegen, teste mit Netzwerkkabel zwischen PC und Router. Damit weißt du, ob es an deinem WLAN liegt.

Außerdem würde ich mal die Logs des Routers auf Fehler durchsehen! Geht am schnellsten und sagt vlt. schon was. Auch schon geschrieben.

Vielen Dank!
Das konnte ich reproduzieren. Damit ist das Problem mit eurer Hilfe gelöst.

letzte Frage: Ist das instabil

Code: Alles auswählen

2016-12-02 11:14:22: 64 bytes from 192.168.178.1: icmp_seq=27 ttl=64 time=3.35 ms
2016-12-02 11:14:27: 64 bytes from 192.168.178.1: icmp_seq=28 ttl=64 time=2.52 ms
2016-12-02 11:14:32: 64 bytes from 192.168.178.1: icmp_seq=29 ttl=64 time=211 ms

2016-12-02 11:28:33: 64 bytes from 192.168.178.1: icmp_seq=197 ttl=64 time=2.23 ms
2016-12-02 11:28:38: 64 bytes from 192.168.178.1: icmp_seq=198 ttl=64 time=1.94 ms
2016-12-02 11:28:43: 64 bytes from 192.168.178.1: icmp_seq=199 ttl=64 time=46.7 ms

2016-12-02 11:30:33: 64 bytes from 192.168.178.1: icmp_seq=221 ttl=64 time=1.52 ms
2016-12-02 11:30:38: 64 bytes from 192.168.178.1: icmp_seq=222 ttl=64 time=1.56 ms
2016-12-02 11:30:43: 64 bytes from 192.168.178.1: icmp_seq=223 ttl=64 time=77.6 ms

[BenutzerGa4gooPh]

2016-12-02 11:14:32: 64 bytes from 192.168.178.1: icmp_seq=29 ttl=64 time=211 ms

Sieht nicht gut aus. Poste das, was mat6937 schrieb. Kurz nach dem Abbruch, dazu "Dauerping" in Konsole auf Gateway laufen lassen.

Zusätzlich als root (während Verbindung):

Code: Alles auswählen

iw list
iw phy
iwconfig
iw dev wlan0 scan

Und nimm das "gelöst" im Titel wieder weg.

[DeletedUserReAsG]

Mehr Sorgen würden mir die ~95% Paketverlust machen (wenn das Gepostete die direkte Ausgabe von ping sein sollte, und nicht manuell was rausgeschnitten wurde).

[BenutzerGa4gooPh]

Nach den Timestamps zu urteilen, denke ich Ausschnitt. Emess weiss mehr.