Wlan Abbrüche dokumentieren

[BenutzerGa4gooPh]

@MSFree bezüglich FB-Logging: Wenn DHCP-Leases vor der Zeit neu angefordert werden, war es doch ein Abbruch oder? Mal von Bereitschaft oder so abgesehen.
@Emess: Und die FB loggt vlt. auch noch mehr, Errors??? WLAN-Abbrueche aufzeichnen beseitigt diese vmtl. nicht.
Dazu sind im Arch-Wiki-Link meines ersten Beitrages auch Diagnosemöglichkeiten auf Clientseite (dmesg etc.).

[mat6937]

... sichtbar machen kann?

BTW: Wenn es um eine temporäre Überwachung geht, dann könntest Du z. B. auch tcpdump und das eapol-Protokoll 0x888e verwenden. Damit kannst Du durch das Ausbleiben des 10-minütigen rekeying der FritzBox und evtl. erneute/wiederholte 4-way-handshake's, evtl. WLAN-Abbrüche auf deinem Gerät sichtbar machen. Z. B.:

Code: Alles auswählen

tcpdump -vvven ether proto 0x888e

[Emess]

bin jetez gerade rortzbesoffen und scheu mir das fenn morgen an.
cu und gegabt euch allew qwohl.
gurre

[Emess]

Könntest du mir verraten wie man das startet?

Das kannst Du manuell oder per cronjob oder mit einer verzögerten service-unit (timer-unit) starten. Oder mit "ExecStartPost=-/..." in der service-unit des wpa_supplicant (... wenn dieser mit einer service-unit gestartet wird). Wichtig ist, dass der Start, nach dem Start des wpa_supplicant erfolgt. Wenn der wpa_supplicant abstürzt und neu gestartet wird, muss der wpa_cli im daemon modus mit dem action file, evtl. auch erneut gestartet werden.

Als 1. musst Du das action file erstellen. Z. B.:

Code: Alles auswählen

#!/bin/bash -e

case "$2" in
    CONNECTED)
        /bin/echo ""wpa_supplicant: connection established," "`/bin/date`"" >> /home/<user>/connection_state_wpa_supplicant.log;
	/bin/echo $WPA_ID_STR  >> /home/<user>/connection_state_wpa_supplicant.log;
        ;;
    DISCONNECTED)
	/bin/echo ""wpa_supplicant: connection lost," "`/bin/date`"" >> /home/<user>/connection_state_wpa_supplicant.log;
        ;;
esac
#
exit 0

Der Pfad für die log-Datei muss richtig eingetragen werden.

Wie lange man das laufen lässt?

Auf meinem Gerät läuft das ständig/permanent.

Wie man es wieder beendet?

Das ist abhängig von der Art und Weise wie man es gestartet hat. Evtl. auch mit:

Code: Alles auswählen

killall wpa_cli

Wo und wie man die log findet?

Entsprechend dem Pfad im action file.

Ich habe eine Datei wifi.sh mit folgendem Inhalt

Code: Alles auswählen

#!/bin/bash -e

case "$2" in
    CONNECTED)
        /bin/echo ""wpa_supplicant: connection established," "`/bin/date`"" >> /home/michael/connection_state_wpa_supplicant.log;
   /bin/echo $WPA_ID_STR  >> /home/michael/connection_state_wpa_supplicant.log;
        ;;
    DISCONNECTED)
   /bin/echo ""wpa_supplicant: connection lost," "`/bin/date`"" >> /home/michael/connection_state_wpa_supplicant.log;
        ;;
esac
#
exit 0

aber es passiert nichts und eine Log-Datei erhalte ich auch nicht.

Code: Alles auswählen

michael@jessie:~$ ./wifi.sh
michael@jessie:~$ 

[mat6937]

aber es passiert nichts und eine Log-Datei erhalte ich auch nicht.

Code: Alles auswählen

michael@jessie:~$ ./wifi.sh
michael@jessie:~$ 

Warum startest Du das action file so? Aus den Beiträgen ist doch ersichtlich, wie man das mit dem wpa_cli macht:

Code: Alles auswählen

wpa_cli -i wlan0 -B -a /usr/local/bin/wpa_cli_action_script -G 45
ps -fC wpa_cli wpa_supplicant

Eine Log-Datei gibt es nur dann, wenn richtig gestartet und die Ereignisse DISCONNECTED bzw. CONNECTED bezogen auf den aktiven wpa_supplicant, statt finden.

[Emess]

Ich versteh das nicht.
Bin wie gesagt reiner Desktop User und Uralt

[mat6937]

Ich versteh das nicht.

Dann starte:

Code: Alles auswählen

wpa_cli -i wlan0 -B -a /home/michael/wifi.sh -G 45

, wenn "wlan0", das WLAN-Interface ist und poste danach die Ausgaben von:

Code: Alles auswählen

ls -la /home/michael/wifi.sh
ps -fC wpa_cli wpa_supplicant

[scientific]

Die Fritzbox sind solche Abbrüche wohl normal.
http://www.router-forum.de/board-avm-fr ... age-1.html

Für mich hört sich das nach einem Montagsgerät an.

Auch das Smartphone schaltet ständig zwischen Wlan und 3G hin und her!

Was umso mehr für ein defektes Gerät spricht.

Zumindest, solange die Fritte nicht im Keller steht und durch mehrere Stahlbetondecken in den 3. Stock funken muß.

Ich kenns von sich störenden WLAN-Hotspots im selben Frequenzbereich...
Kommt bei hoher Bebyuungsdichte gern msl vor, wenn jeder sein eigenes WLAN hat...
Lg scientific

[Emess]

Ich versteh das nicht.

Dann starte:

Code: Alles auswählen

wpa_cli -i wlan0 -B -a /home/michael/wifi.sh -G 45

, wenn "wlan0", das WLAN-Interface ist und poste danach die Ausgaben von:

Code: Alles auswählen

ls -la /home/michael/wifi.sh
ps -fC wpa_cli wpa_supplicant

Code: Alles auswählen

root@jessie:/home/michael# wpa_cli -i wlan1 -B -a /home/michael/wifi.sh -G 45
root@jessie:/home/michael# ls -la /home/michael/wifi.sh
-rwxrwxr-x 1 michael michael 427 Nov 27 13:13 /home/michael/wifi.sh
root@jessie:/home/michael# ps -fC wpa_cli wpa_supplicant
error: process ID list syntax error

Usage:
 ps [options]

 Try 'ps --help <simple|list|output|threads|misc|all>'
  or 'ps --help <s|l|o|t|m|a>'
 for additional help text.

For more details see ps(1).
root@jessie:

das -fC scheint nicht zu gefallen?

Code: Alles auswählen

root@jessie:/home/michael# ps -e| grep wpa
  598 ?        00:00:00 wpa_supplicant
 2119 ?        00:00:00 wpa_cli
root@jessie:

[mat6937]

Und die FB loggt vlt. auch noch mehr, ...

Ich habe das mit meiner FB getestet. Die FB loggt nicht den genauen Zeitpunkt des Abbruchs der WLAN-Verbindung. D, h., im Log der FB ist der Zeitpunkt der Abmeldung (connection lost) identisch mit dem Zeitpunkt der Anmeldung (connection established), wenn dazwischen (d. h. im Zeitraum zwischen "connection lost" und connection established") kein rekeying durch die FB statt gefunden hat. Wenn dazwischen ein rekeying statt findet, merkt die FB erst dann, lediglich an der ausbleibenden Antwort, dass der wpa_supplicant die Verbindung (aus welchen Gründen auch immer) unterbrochen hat.

[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.