RPi 3 WLAN schläft ein

  • Hallo allerseits,

    ich haben einen RPi 3, der als Server für einen einfachen Dienst per WLAN erreichbar sein soll und entsprechend eine fixe IP bekommen hat. Das hat anfangs auch alles funktioniert, vor ein paar Wochen hat er allerdings angefangen, Probleme zu machen:
    Manchmal (eher öfter) ist der RPi nicht erreichbar. Das hat nichts mit meinem Server-Programm zu tun; er ist auch per Ping nicht erreichbar. Oder besser: er muß erst aufgeweckt werden: wenn man das Programm ein paar mal anspricht oder so zwischen 5 und 30 mal anpingt, scheint er aufzuwachen und ist dann wieder normal ansprechbar.

    Es scheint also so, als ob das WLAN zwischendrin einschläft. Das scheint auch ein gängiges Problem zu sein, zu dem ich einige Postings im Netz gefunden habe.

    Was ich nicht geschafft habe, ist, das Problem definitiv abzustellen. Es ist erschreckend schwierig, auch nur herauszufinden, auf welche Art und Weise die WLAN-Konfiguration funktioniert. /etc/network/interfaces scheint ja total veraltet zu sein; das geht ja alles inzwischen über dhcpcd, oder eigentlich ja inzwischen über systemd-networkd... Für erstere Variante gibt es die Eintragung wireless-power off, die auch drinsteht (s.u.). Aber ich habe nicht einmal herausgefunden, wer jetzt wirklich mein WLAN konfiguriert, geschweige denn, dass ich Dokumentation gefunden hätte, wie das geht...

    Vielen Dank schon mal für Eure Hilfe. Ich habe ein paar Infos beigefügt; wenn Ihr noch mehr braucht, sagt Bescheid.

    Code
    pi@toshio:~ $ cat /etc/*release
    PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
    NAME="Raspbian GNU/Linux"
    VERSION_ID="8"
    VERSION="8 (jessie)"
    ID=raspbian
    ID_LIKE=debian
    HOME_URL="http://www.raspbian.org/"
    SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
    BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
    Code
    pi@toshio:/etc/systemd/network $ service networking status
    ● networking.service - LSB: Raise network interfaces.
       Loaded: loaded (/etc/init.d/networking)
      Drop-In: /run/systemd/generator/networking.service.d
               └─50-insserv.conf-$network.conf
            /lib/systemd/system/networking.service.d
               └─network-pre.conf
       Active: active (exited) since Mo 2017-02-20 15:56:57 CET; 4 days ago

    Noch nebenbei: Ich habe versucht, mit einem ping -i 60 toshio von einem anderen Rechner die Schnittstelle wach zu halten... funktioniert aber auch nicht. Wieso?


  • ... wenn man das Programm ein paar mal anspricht ...

    Was genau meinst Du mit "wenn man das Programm ein paar mal anspricht"?


    ..., auch nur herauszufinden, auf welche Art und Weise die WLAN-Konfiguration funktioniert. ...

    Nein, es ist nicht schwierig. Poste mal die Ausgaben von:

    Code
    ps aux | grep -i [d]hc
    ip a
    ip r
    iwconfig

    Hast Du systemd-networkd aktiviert (enabled)? Hast Du eine *.network-Datei für das wlan-Interface erstellt?



    Noch nebenbei: Ich habe versucht, mit einem ping -i 60 toshio von einem anderen Rechner die Schnittstelle wach zu halten... funktioniert aber auch nicht. Wieso?

    Wenn, dann vom PI aus, aber mit dem arp-Protokoll. Evtl. nicht angeforderte arp-replys.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (25. Februar 2017 um 20:48)


  • Was genau meinst Du mit "wenn man das Programm ein paar mal anspricht"?


    ...versucht, den Port zu öffnen.

    Zitat

    Nein, es ist nicht schwierig. Poste mal die Ausgaben von:

    Code
    ps aux | grep -i [d]hc
    ip a
    ip r
    iwconfig

    Nochmal wegen "Programm ansprechen" - der Versuch, mich einzuloggen (die Versuche wurden direkt hintereinander ausgeführt):

    Code
    pi@toshio:~ $ ps aux | grep -i [d]hc
    root       693  0.0  0.1   2564  1724 ?        Ss   Feb20   0:02 /sbin/dhcpcd -q -w
    ntp        746  0.0  0.3   5776  3680 ?        Ss   Feb20   0:27 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 106:111
    Zitat


    Hast Du systemd-networkd aktiviert (enabled)? Hast Du eine *.network-Datei für das wlan-Interface erstellt?


    Ich habe da nichts bewußt aktiviert.

    Zitat

    Wenn, dann vom PI aus, aber mit dem arp-Protokoll. Evtl. nicht angeforderte arp-replys.

    Wie mache ich einen arp-ping?

  • Code
    pi@toshio:~ $ ip a
    3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
        link/ether b8:27:eb:7e:69:3b brd ff:ff:ff:ff:ff:ff
        inet 192.168.200.11/24 brd 192.168.200.255 scope global wlan0
           valid_lft forever preferred_lft forever
        inet6 fe80::a2cc:d02b:b914:5290/64 scope link 
           valid_lft forever preferred_lft forever


    Wie mache ich einen arp-ping?

    Installiere:

    Code
    sudo apt-get install iputils-arping tcpdump


    ... konfiguriere den dhcpcd oder deinen Router so, dass das wlan0-Interface immer die feste IP-Adresse 192.168.200.11 bekommt und mach in die systemweite crontab mit:

    Code
    sudo nano /etc/crontab


    folgenden Eintrag, dort als letzte Zeilen:

    Code
    */3 * * * * root /usr/bin/arping -q -c 2 -A -I wlan0 -s 192.168.200.11 255.255.255.255 > /dev/null 2>&1
    */2 *    * * * root /usr/bin/arping -q -c 3 -w 10 -b -f -I wlan0 -s 192.168.200.11 192.168.200.1 > /dev/null 2>&1
    # - - - - - -


    und in die /etc/rc.local-Datei (vor exit 0) folgenden Eintrag:

    Code
    /usr/sbin/arp -i wlan0 -d 192.168.200.1
    /usr/sbin/arp -i wlan0 -s 192.168.200.1 <richtige-MAC-Adresse-Router>


    Für die richtige MAC-Adresse deines WLAN-Routers (ohne die spitzen Klammern) siehe jetzt auf deinem PI, die Ausgaben von:

    Code
    arp -av


    ... nach diesen Änderungen, deinen PI rebooten und beobachten.

    EDIT:

    Poste danach von deinem PI, über einen Zeitraum von ca. 5 Minuten, die Ausgabe von:

    Code
    sudo tcpdump -c 40 -vvveni wlan0 arp


    und sofort nach dem rebooten, die Ausgabe von:

    Code
    ip n s

    EDIT 2:

    Poste mal von deinem PI, auch die richtig anonymisierte Ausgabe von:

    Code
    sudo cat /etc/wpa_supplicant/wpa_supplicant.conf


    und die Ausgaben von:

    Code
    wpa_supplicant -v
    strings $(which wpa_supplicant) | grep -i autoscan

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (26. Februar 2017 um 11:59)


  • EDIT 2:

    Poste mal von deinem PI, auch die richtig anonymisierte Ausgabe von:

    Code
    sudo cat /etc/wpa_supplicant/wpa_supplicant.conf


    und die Ausgaben von:

    Code
    wpa_supplicant -v
    strings $(which wpa_supplicant) | grep -i autoscan

    Das ziehe ich mal vor:

    Code
    country=DE
    ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
    update_config=1
    
    
    network={
            ssid="blabla"
            id_str="home"
            psk="blibli"
    }

    Rest kommt gleich.
    Automatisch zusammengefügt:


    ... nach diesen Änderungen, deinen PI rebooten und beobachten.

    arpings eingebaut. Beobachte. ;)


    EDIT:

    Poste danach von deinem PI, über einen Zeitraum von ca. 5 Minuten, die Ausgabe von:

    Code
    sudo tcpdump -c 40 -vvveni wlan0 arp


    und sofort nach dem rebooten, die Ausgabe von:

    Code
    ip n s
    Code
    pi@toshio:~ $ ip n s
    192.168.200.1 dev wlan0 lladdr 24:65:11:f2:c7:62 REACHABLE
    192.168.200.2 dev wlan0 lladdr 40:61:86:85:6e:3b REACHABLE

    Damit behebe ich aber nicht das Problem, sondern umgehe es nur, indem ich das WLAN wach halte, richtig?
    Der erste arping scheint quasi einfach zwei leere Arp-Antworten in die Landschaft zu pusten.
    Der zweite pingt gezielt den Router an.
    Warum diese beiden?

    Einmal editiert, zuletzt von Toshio (26. Februar 2017 um 12:23)


  • Das ziehe ich mal vor:

    Code
    country=DE
    ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
    update_config=1
    
    
    network={
            ssid="blabla"
            id_str="home"
            psk="blibli"
    }

    OK, dann ergänze die wpa_supplicant.conf, nach der Zeile "update_config=1" (d. h. außerhalb des nerwork-blockes) mit der Zeile:

    Code
    autoscan=periodic:120

    Reboote deinen PI und poste nach dem Reboot, die Ausgabe von:

    Code
    ip n s


    und über einen Zeitraum von ca. 12 Minuten, von deinem PI, die Ausgaben von:

    Code
    iwevent


    Evtl. musst Du vorher noch "wireless-tools" und "net-tools" installieren. Siehe dazu die Ausgabe von:

    Code
    apt-cache policy wireless-tools net-tools


    Damit behebe ich aber nicht das Problem, sondern umgehe es nur, indem ich das WLAN wach halte, richtig?

    Wir wissen ja nicht ob das WLAN dein Problem ist, oder ob die anderen Clients in deinem (W)LAN, den PI evtl. nicht (mehr) in ihrem arp-cache eingetragen haben.

    Für Erkenntnisse über die WLAN-Verbindung deins PIs, müsste man evtl. mit wpa_cli und einem action-file, die event-Variablen "CONNECTED" or "DISCONNECTED" beobachten bzw. auswerten.


    Der erste arping scheint quasi einfach zwei leere Arp-Antworten in die Landschaft zu pusten.
    Der zweite pingt gezielt den Router an.
    Warum diese beiden?


    Der erste arping geht an Alle (... als "gratuitous ARP reply"), ins (W)LAN.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (26. Februar 2017 um 13:05)

  • Bisher keine Besserung.
    Im Gegenteil, jetzt startet mein Server nicht mehr automatisch... er wird eigentlich auch im rc.local als letztes gestartet, also nach den beiden arp-Aufrufen.


    OK, dann ergänze die wpa_supplicant.conf, nach der Zeile "update_config=1" (d. h. außerhalb des nerwork-blockes) mit der Zeile:

    Code
    autoscan=periodic:120

    Reboote deinen PI und poste nach dem Reboot, die Ausgabe von:

    Code
    ip n s

    Erledigt.

    Code
    pi@toshio:~ $ ip n s
    192.168.200.1 dev wlan0 lladdr 24:65:11:f2:c7:62 REACHABLE
    192.168.200.2 dev wlan0 lladdr 40:61:86:85:6e:3b REACHABLE

    und über einen Zeitraum von ca. 12 Minuten, von deinem PI, die Ausgaben von:

    Code
    iwevent


    Evtl. musst Du vorher noch "wireless-tools" und "net-tools" installieren. Siehe dazu die Ausgabe von:

    Code
    apt-cache policy wireless-tools net-tools


    War schon drin.

    iwevent gibt keine Ereignisse aus.

    Jetzt hab ich aber das Problem, dass ich ja über ssh zugreife (von dem Rechner mit .2). Solange ich da eingeloggt bin, ist es ja sehr unwahrscheinlich, dass das Phänomen auftritt, oder?


    Wir wissen ja nicht ob das WLAN dein Problem ist, oder ob die anderen Clients in deinem (W)LAN, den PI evtl. nicht (mehr) in ihrem arp-cache eingetragen haben.


    Hm. Halte ich aber für eher unwahrscheinlich... zum einen sind es verschiedene Rechner, die Zugriffsprobleme haben (mehrere Android, mehrere Linux, Windows), zum anderen habe ich die Probleme mit anderen PasPis nicht. Die zugegebenermaßen aber auch andere Aufgaben haben.


    Für Erkenntnisse über die WLAN-Verbindung deins PIs, müsste man evtl. mit wpa_cli und einem action-file, die event-Variablen "CONNECTED" or "DISCONNECTED" beobachten bzw. auswerten.


    Muß ich mir mal ansehen, wie das geht... das wäre dann praktisch die Langzeit-Version von iwevents, oder? Ich schreibe ein Logfile, in dem die Ereignisse aufgezeichnet werden, und schau mir dann an was passiert?

    Einmal editiert, zuletzt von Toshio (27. Februar 2017 um 17:02)


  • ..., jetzt startet mein Server nicht mehr automatisch... er wird eigentlich auch im rc.local als letztes gestartet, also nach den beiden arp-Aufrufen.

    Code
    pi@toshio:~ $ ip n s
    192.168.200.1 dev wlan0 lladdr 24:65:11:f2:c7:62 REACHABLE
    192.168.200.2 dev wlan0 lladdr 40:61:86:85:6e:3b REACHABLE


    Dann kannst die Zeilen mit arp in der rc.local wieder löschen, denn diese haben nicht bewirkt, dass der PI einen statischen arp-cache-Eintrag für den Router, bekommt. Evtl. mit einer timer-unit (systemd) versuchen.


    iwevent gibt keine Ereignisse aus.

    OK, dann liegt es evtl. an der wpa_supplicant-Version, denn mit 2.6 auf meinem PI3. bekomme ich folgende Ausgaben:

    Code
    pi@raspberrypi:~ $ iwevent
    Waiting for Wireless Events from interfaces...
    18:03:56.647595   wlan0    Scan request completed
    18:05:56.696505   wlan0    Scan request completed
    ...


    ... das wäre dann praktisch die Langzeit-Version von iwevents, oder?

    Nein, denn iwevent soll nur scans anzeigen und keine Unterbrechungen in der WLAN-Verbindung zwischen deinem PI3 und deinem Router.


    Ich schreibe ein Logfile, in dem die Ereignisse aufgezeichnet werden, und schau mir dann an was passiert?

    Wenn keine Unterbrechungen statt finden, dann wird es auch keine Unterbrechungen geben.

    Eine andere Möglichkeit evtl. Unterbrechungen in der WLAN-Verbindung festzustellen, ist z. B. mit Hilfe des eapol-Protokolls (rekeying und/oder 4-way-handshake zwischen deinem PI und dem WLAN-Router):

    Code
    sudo tcpdump -vvveni wlan0 ether proto 0x888e


    auf deinem PI3 über einen längeren Zeitraum (ca. 1,5 Std), da wir den rekeying-Intervall deines WLAN-Routers nicht kennen (btw. der ist bei der FB 10 Minuten).

    EDIT:

    Ohne SSH-Verbindung zu deinem PI, kannst Du auf einem Rechner in deinem WLAN, die arp-requests bzw. arp-replys von deinem PI3 anzeigen lassen:

    Code
    sudo tcpdump -vvveni <Interface> src host 192.168.200.11 and arp


    oder mit wireshark, falls es ein WIN-Rechner ist.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (27. Februar 2017 um 19:45)


  • Ohne SSH-Verbindung zu deinem PI, kannst Du auf einem Rechner in deinem WLAN, die arp-requests bzw. arp-replys von deinem PI3 anzeigen lassen:

    Code
    sudo tcpdump -vvveni <Interface> src host 192.168.200.11 and arp


    oder mit wireshark, falls es ein WIN-Rechner ist.

    Die arpings scheinen also durchzugehen. Trotzdem hat der Ping wieder erst nach ein paar Anläufen funktioniert.

    Was auch noch interessant ist:

    Code
    pi@toshio:~ $ ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    +tor.epow0.org   85.214.240.100   3 u  232 1024  167   25.198    0.618   4.752
    +96-7.cpe.smnt.p 91.211.101.141   3 u  62m 1024  170   58.500    2.901 187.079
    -ntp2.ig-haase.d 131.188.3.222    2 u  376 1024  351   47.517    9.861  16.539
    *infra.ig42.org  131.188.3.221    2 u   54 1024  373   25.729   -0.270   3.482


    Wichtig ist die Spalte reach: offensichtlich gehen auch ntp eine Menge Antworten verloren.

    Wenn also die arpings durchkommen, schläft das WLAN offensichtlich nicht ein. Also warum erreichen dann die Pakete den Raspi nicht?? :s


  • Wenn also die arpings durchkommen, schläft das WLAN offensichtlich nicht ein.

    Genau so ist es.


    Also warum erreichen dann die Pakete den Raspi nicht?? :s

    Wenn Du in deinem (W)LAN ein 2. Linux-Gerät hast, dann konfiguriere mal _manuell_ auf deinem PI einen statischen arp-cache-Eintrag für dieses Linux-Gerät bzw. für den Router und auf dem Linux-Gerät auch _manuel_ einen statischen arp-cache-Eintrag für deinen PI bzw. für den Router. (Siehe die Ausgaben von "ip n s").

    Teste danach in einem dafür geeigneten Zeitraum, ob die Pakete (vom Linux-Gerät) den Raspi erreichen oder nicht erreichen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Wenn Du in deinem (W)LAN ein 2. Linux-Gerät hast, dann konfiguriere mal _manuell_ auf deinem PI einen statischen arp-cache-Eintrag für dieses Linux-Gerät bzw. für den Router und auf dem Linux-Gerät auch _manuel_ einen statischen arp-cache-Eintrag für deinen PI bzw. für den Router. (Siehe die Ausgaben von "ip n s").

    Teste danach in einem dafür geeigneten Zeitraum, ob die Pakete (vom Linux-Gerät) den Raspi erreichen oder nicht erreichen.

    Die statischen arp-Einträge habe ich zugegebenermaßen noch nicht gemacht, aber ich bin trotzdem noch ein Stückchen weiter:
    toshio (WLAN): Der RasPi, um den es geht
    Rechner A (mein Hauptrechner, Linux, Kabel): Auf dem läuft der tcpdump, der keinerlei Ausfällt dokumentiert. Außerdem pinge ich alle paar Stunden den toshio an und kommen problemlos durch.
    Rechner B (RasPi, Kabel): Auf dem läuft FHEM mit einem Presence-Test per Ping auf den toshio, für den ich jetzt auch ein Logfile erzeugen lasse: er ist immer verfügbar.
    Rechner C (Handy, Android, WLAN): Direkt nach dem Ping von Rechner A ist von hier aus toshio nicht erreichbar. Nach ca. 10 Pings von diesem Handy aus antwortet toshio wieder.

    Also: Aus irgendeinem Grund gibt es Rechner, die erst mal nicht wissen, wo sie den RasPi finden.
    Nehmen wir mal an, dass das ein arp-Problem ist. Dann geht doch da irgendetwas gewaltig schief; schließlich sind die Protokolle ja genau darauf ausgelegt, einen Rechner transparent zu finden, selbst wenn er gerade nicht im arp-cache ist, oder??


  • Rechner C (Handy, Android, WLAN): Direkt nach dem Ping von Rechner A ist von hier aus toshio nicht erreichbar. Nach ca. 10 Pings von diesem Handy aus antwortet toshio wieder.

    Verstehe ich das richtig, ... hast Du diese Probleme, nur mit Android?



    ...; schließlich sind die Protokolle ja genau darauf ausgelegt, einen Rechner transparent zu finden, selbst wenn er gerade nicht im arp-cache ist, oder??

    Naja, der Rechner wird ja auch gefunden, aber nicht sofort. D. h., es muss erstmal gepingt oder was Gleichwertiges gemacht werden. Das ist nicht schön, aber es ist nun mal so.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample


  • Verstehe ich das richtig, ... hast Du diese Probleme, nur mit Android?


    Nicht ganz - auch mit Rechner A hatte ich das schon, dass ping oder ssh nicht auf Anhieb durchkamen (s. weiter oben).


    Naja, der Rechner wird ja auch gefunden, aber nicht sofort. D. h., es muss erstmal gepingt oder was Gleichwertiges gemacht werden. Das ist nicht schön, aber es ist nun mal so.

    Na ja - das ist nicht das erwartete Verhalten und es hat auch schon funktioniert. Irgendetwas ist da also jetzt "kaputt", was eigentlich funktionieren sollte.
    Ich könnte einen Workaround bauen, ja... aber eigentlich würde ich lieber die Ursache finden und beheben, als an den Symptomen rumzudoktern.


  • Na ja - das ist nicht das erwartete Verhalten und es hat auch schon funktioniert. Irgendetwas ist da also jetzt "kaputt", was eigentlich funktionieren sollte.

    Ja, das kann ich von meinen PIs auch so bestätigen.


    Ich könnte einen Workaround bauen, ja...

    Ohne einen workaround, sind meine PIs auch nicht immer und zuverlässig, erreichbar.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ohne einen workaround, sind meine PIs auch nicht immer und zuverlässig, erreichbar.

    Echt jetzt? Dann ist bei jessie aber was kaputt.

    Die Sache mit dem arp scheint sich übrigens zu bestätigen:


    toshio ist nicht im arp-cache und reagiert erst beim siebten Ping. Also würe ich vermuten, dass da was mit der arp-Kommunikation gestört ist. Da werde ich mal weiter graben.
    Was mich allerdings wundert: Eigentlich schreit doch toshio dauernd seine arp-Daten in die Landschaft... scheint aber nichts zu nutzen...

    Außerdem muß ich hier mal :danke_ATDE: sagen. Du hast mich schon wesentlich weiter gebracht und ich hab auch wieder jede Menge über allerlei Netzwerktools gelernt. :thumbs1:


  • Eigentlich schreit doch toshio dauernd seine arp-Daten in die Landschaft... scheint aber nichts zu nutzen...

    Ja, weil die/das andere(n) Gerät(e) diese arp-requests/-replys von toshio einfach ignorieren. Deshalb ist es m. E. wichtig, dass die Geräte die untereinander immer und _schnell_ kommunizieren müssen, einen statischen arp-cache-Eintrag von dem anderen Gerät, haben sollen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ja, weil die/das andere(n) Gerät(e) diese arp-requests/-replys von toshio einfach ignorieren. Deshalb ist es m. E. wichtig, dass die Geräte die untereinander immer und _schnell_ kommunizieren müssen, einen statischen arp-cache-Eintrag von dem anderen Gerät, haben sollen.

    Ich stimme zu, dass das ein Workaround wäre. Aber einerseits halte ich das für einen Implementierungsfheler irgendwo, wenn das nötig ist, und andererseits habe ich da ein Problem, das bei einem nicht gerooteden Android einzubauen...
    Da muß ich noch weiter forschen.


  • Da muß ich noch weiter forschen.

    Ja, evtl. in die Richtung "arp cache + timeout". Siehe auch: http://www.networkers-online.com/blog/2009/02/a…ng-and-timeout/

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Reaktion auf 5 pings vom Handy:

    Also braucht der RasPi tatsächlich 10 sec für die Antwort. Das erklärt manches.

    [Nur zur weiteren Dokumentation]

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!