Pi nicht mehr per Netzwerk erreichbar, aber aktiv


  • Evtl. könntest Du dein Script, zwecks Ursachenforschung, mit "ip neigh show" ergänzen:

    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

  • Kurzer Aufwärmer :lol:

    Ich bin auf einen interessanten (und etwas länglichen) Blog bzgl. Netzteilen und deren Qualität gestossen:

    a-dozen-usb-chargers-in-lab-apple-is

    Besonders interessant: Der Abschnitt bzgl. der Ripple und Noise - Parameter.

    Die Aussagen/Vergleiche/Messungen in diesem Blog unterstreichen eigentlich überdeutlich die (nicht nur meine) Meinung, dass die für den RPi eingesetzten Netzteile sehr oft das eigentliche Hauptproblem bei Instabilitäten usw. sind.

  • Moin,

    ich möchte das Thema noch mal an Tageslicht zerren. Ich weiß nicht, ob es was damit zu tun hat, hoffe aber entweder auf Hilfe oder vielleicht hilft es ja bei der Aufklärung.
    Mein PI ist via WLAN im Netz. Von der Fritzbox ist wird von außen Port 22 weitergeleitet. Damit ist logischerweise mein Pi von außen per SSH erreichbar. Soweit so hübsch.
    Jetzt lässt sich der PI im "Heimnetz" nicht mehr erreichen - Mysterium! Aber ich kann von "außen" über die Portweiterleitung rein (immer,keine Ausnahme). Bin ich drauf heißt es aber noch nicht das der PI Intern wieder erreichbar ist. Keine Chance, es sei denn ich pinge der Router an. Schwubsdiwups alles (Webserver, ssh, ping) ist intern wieder ereichbar.

    Ich sehe die die FB im Arp des pi und umgekehrt.Ich kann den PI von der FB anpingen. Ich komme per ssh von außendrauf. Intern von irgengen einem anderen Rechner keine Chance.
    Ping von dem PI an die FB und alles ist wieder möglich.

    Kann jemand das Verhalten nachvollziehen?
    Was kann ich noch nachsehen/einstellen?

    Gruß Lunepi

    --
    man ist das System-Anzeigeprogramm für die Handbuchseiten von Linux.


  • Ping von dem PI an die FB und alles ist wieder möglich.

    Schau mal ob ein "gratuitous arp" auf dem Pi, die gleiche Wirkung hat:

    Code
    sudo arping -c 3 -A -I <NIC> <interne-IP-Adresse-des-Pi-im-(W)LAN>


    wie der Ping vom Pi an die FB.

    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 (23. August 2014 um 21:23)

  • Bei meinem als NAS/Druck-Server eingerichteten B+ mit nem aktuellen Raspbian habe ich das gleiche Problem. Alles up to date soweit verfügbar.:s

    Netzteil liefert eigentlich 1,5 A, alle USB-Platten hängen an nem aktiven Hub mit genügend Saft, nur der WLAN-Stick hängt direkt dran.

    Leider habe ich mir heute den Pi aus der Ferne "abgeschossen", normalerweise hilft mir nur Stromstecker ziehen, einige Sekunden warten und dann wieder starten lassen.
    Jetzt muss ich auf das Urlaubsende warten.:wallbash:


  • Von der Fritzbox ist wird von außen Port 22 weitergeleitet. Damit ist logischerweise mein Pi von außen per SSH erreichbar. Soweit so hübsch.

    Naja, "hübsch" ist anders...:
    Du solltest einen anderen "Aussen"-Port verwenden und den auf den Port 22 des RPi umleiten, z.B. 10022 ==> 22
    Grund: Üblicherweise scannen die 'bösen' Jungs die Standard-Ports als erstes, dann wird bei einem offenen 22ziger Port natürlich versucht, den anzugreifen... so einfach sollte man es den Jungs nicht machen :D

    Aber der Effekt ist dennoch seltsam.
    Ich verwende einen Buffalo Router und mache etwas ähnliches, geht ohne Probleme..

    Der WebServer (Apache?) könnte wirklich Probleme machen, je nachdem, ob er die Seite lokal oder "remote" ausliefern soll... Domain-Einstellung im Apache spielt da eine Rolle, die Lösung dafür "hab ich gerade nicht auf Tasche" :( , wie das richtig gemacht wird - mal suchen bei Tante G.


  • Du solltest einen anderen "Aussen"-Port verwenden und den auf den Port 22 des RPi umleiten, z.B. 10022 ==> 22
    Grund: Üblicherweise scannen die 'bösen' Jungs die Standard-Ports als erstes, dann wird bei einem offenen 22ziger Port natürlich versucht, den anzugreifen... so einfach sollte man es den Jungs nicht machen :D

    Naja, das hält ja nun wirklich keinen ab und ist auch nur Security by Obscurity ;)

    Zitat


    Aber der Effekt ist dennoch seltsam.
    Ich verwende einen Buffalo Router und mache etwas ähnliches, geht ohne Probleme..

    Der WebServer (Apache?) ....

    Nein nginx, aber an dieser Stelle völlig irrelevant, denn Ping und ssh verhalten sich genauso. Es ist als wenn der PI nicht im Netz wäre, obwohl die FB ihn erkennt und es auch sofort weiter geht sobald ich die anpinge

    Einzig, was ich mir denke ist dass die Portweiterleitung auf FB ein direkte route zum PI herstellt - blöd ausgedrückt aber es ist so obskur das Ganze.

    Arping versuche ich - mompls muss erst installieren und dann vermute ich muss ich erst wieder auf den Effekt warten... Aber der kommt :(

    Na ja was ich sagt, jetzt wo ich vom PI aus zur FB gehe ( in diesem Fall, durch apt-get install arping ) ist alles wieder gut....

    Den arp cache hab ich auch in verdacht, aber weder auf der FB noch auf dem PI deutet auf irgend ein Fehler hin.

    --
    man ist das System-Anzeigeprogramm für die Handbuchseiten von Linux.

    Einmal editiert, zuletzt von Lunepi (23. August 2014 um 23:20)


  • Den arp cache hab ich auch in verdacht, aber weder auf der FB noch auf dem PI deutet auf irgend ein Fehler hin.

    Wie ist auf dem Pi, vor und nach dem Ping zur FB (d. h. wenn es nicht geht und wenn es geht) die Ausgabe von:

    Code
    ip neigh show


    ?

    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


  • Naja, das hält ja nun wirklich keinen ab und ist auch nur Security by Obscurity ;)

    Natürlich bremst das potentielle Angreifer aus: Portscanns sind "teuer" und werden üblicherweise nur bis Ports in die 1024ziger gemacht.
    Wird weltweit gemacht - nur mal so... :)

    Zitat


    Einzig, was ich mir denke ist dass die Portweiterleitung auf FB ein direkte route zum PI herstellt - blöd ausgedrückt aber es ist so obskur das Ganze.

    Selbst wenn das die FB mit einer direkten Route macht (was ich stark bezweifle, Portweiterleitungen sind normalerweise iptables Einträge...) ist der Port 22 im internen LAN immer noch offen... das kann selbst die FB nicht verhindern.

    Welches OS auf dem RPi verwendest du?

    iptraf wäre zum verfolgen des Netzwerktraffics sinnig, tcpdump sollte noch besser sein..

  • Also ermal kurzer Zwischenbericht: Bin gestern beim weeiderholtenmale die Einstellungen der FB durchgehehn auf den Punkt: "DNS Rebind Schutz" gestossen - da ich keine Ahnung hab was das bedeuten soll, Tante Google gefragt. Und siehe da ich stolpere über Threads in denen andere von ähnlichen Problemen berichten. Also gleich mal Firmware update für Fb gezogen - sicher ist sicher. Mal sehen ob es was gebracht hat...
    Sobald das Problem wieder auftritt werde ich die hier genannten Tips und Befehle ausführen und die Ergbnisse hier zu Diskussion stellen. (Kann nicht lange dauern :( )

    --
    man ist das System-Anzeigeprogramm für die Handbuchseiten von Linux.

  • Seit ich meinen Pi als NAS aufgesetzt habe, habe ich auch oft das Problem des Stillstands, wobei bei mir der Pi komplett einfriert.
    Eventuell scheint es am WLAN-Stick bzw. dessen Treiber zu liegen.
    Leider habe ich meinen gestern aus der Ferne abgeschossen und komme erst nächsten Sonntag wieder dran.
    Aber vielleicht könnte ein vergleich der eingesetzten WLAN-Chipsätze helfen?
    Ich versuche mich demnächst mal mit so einem WLAN-Stick wie hier beschrieben:
    https://raspberrypi.stackexchange.com/questions/5364…imax-ew-7711utn

  • aber aktiv ...
    nun ja.

    Da auch ich meine Probleme mit meinem Raspberry habe, melde ich mich hier auch einmal.

    Wenn nun nur die WLAN/LAN-Verbindung weg wäre, der Pi die anderen Aufgaben aber erledigen würde, wäre mein Problem kleiner.
    Aber er protokolliert nicht einmal einfachste Ausgaben in eine Datei (gesteuert vom root via crontab).

    Von daher wird ein periodisches Restarten der Ethernet-Schnittstelle wohl auch keinen Erfolg bringen.
    Also doch der Watchdog mit einem Restart des PI oder Andreas' Icon Programm - na ja, spätestens beim Download der notwendigen Software wird der PI mehrfach die Grätsche machen?

    Was ich grundsätzlich nicht verstehe: da draußen gibt es so viele gemeine Hersteller die uns schrottige Programme liefern, unsere Kohle abkassieren und dafür nur unsere Daten klauen - und auf der anderen Seite das Land wo Milch und Honig fließen, sich alle untereinander helfen und lieb zueinander sind.
    ???
    ist dem so? Nö. Warum wird der Pi ohne Software und ohne Netzteil verkauft?

    Nun, was ich nicht verkaufe, dafür bin ich auch nicht zuständig.

    Tut mir leid, aber das verwendete Kabel ist 'nen halben Zentimeter zu lang.
    'Ne dieses Netzteil tut nur auf Meereshöhe.
    Hatten wir doch geschrieben, daß einfach vergoldete Kontakte beim Micro-USB nicht ausreichen.

    S U P E R :(

    Übrigens: hat Jemand schon mal aktiv den Hersteller dieser Schrottware angeschrieben und um Hilfe gebeten?

    Ach, es gäbe ja einen Workaround: wir lassen unseren PI einfach ohne Netzwerkschnittstelle arbeiten und geben unsere Ergebnisse auf 'nem kleinen Display aus. Das Bild funken wir dann per WebCam weiter.

    Einmal editiert, zuletzt von obod0002 (26. August 2014 um 12:15)


  • Du solltest einen anderen "Aussen"-Port verwenden und den auf den Port 22 des RPi umleiten, z.B. 10022 ==> 22
    Grund: Üblicherweise scannen die 'bösen' Jungs die Standard-Ports als erstes, dann wird bei einem offenen 22ziger Port natürlich versucht, den anzugreifen... so einfach sollte man es den Jungs nicht machen

    Und das wichtigste: einen Zugang per SSH niemals mit Benutzer/Kennwort benutzen, sondern N.U.R. mit PKA!!!

    Warum? Darum! :D

    Im Ernst: Benutzer und Kennwort können ausprobiert werden. Es macht überhaupt keine Mühe, ein Skript zu schreiben, das pro Sekunde mehrere Tausend Kombinationen testet. Einen SSH-Schlüssel zu knacken oder durch Testen herauszubekommen, ist nach heutigem Stand der Technik nicht innerhalb einer Lebensspanne eines normalen Menschen möglich.

    Und wenn Du trotzdem den Zugang per Benutzer und Kennwort betreiben musst, dann tue Dir selber einen Gefallen und schreiben diese Zeilen in die /etc/rc.local:


    Code
    /sbin/iptables -N SSH_LIMIT 
    /sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 11122 -j SSH_LIMIT
    /sbin/iptables -A SSH_LIMIT -m state --state NEW -m limit --limit 3/min --limit-burst 3 -m tcp -p tcp --dport 11122 -j ACCEPT 
    /sbin/iptables -A SSH_LIMIT -m tcp -p tcp --dport 11122 -j DROP


    Wobei Du den Port natürlich an Deinen Server anpassen musst. Diese Zeilen sorgen dafür, daß pro IP nur maximal 3 Anmeldeversuche innerhalb einer Minute akzeptiert werden. Danach wird die IP geblockt. Das bremst Scanner erheblich aus, so daß Dein Rechner dann einfach uninteressant wird.

    Zur Sache mit der Stromversorgung: ich habe jetzt einen aktiven USB-Hub an den Pi geklemmt, der alle angeschlossenen USB-Geräte, auch die Speicher-Zäpfchen, mit Strom versorgt, und aus einem Port auch den Pi selber. Mit anderen Worten: der Eingang des Hub ist an eine USB-Buchse des Pi angeschlossen, und eine der Ausgänge des Hub versorgt des Pi selber mit Strom.

    Und was soll ich sagen? Seit dem läuft der Pi ohne einen einzigen Absturz. :)

    Einmal editiert, zuletzt von PInguin (29. August 2014 um 18:07)

  • Hallo obod0002,


    ...
    Von daher wird ein periodisches Restarten der Ethernet-Schnittstelle wohl auch keinen Erfolg bringen.
    Also doch der Watchdog mit einem Restart des PI oder Andreas' Icon Programm - na ja, spätestens beim Download der notwendigen Software wird der PI mehrfach die Grätsche machen?
    ...

    in den letzten Jahen habe ich auf so manchem Raspberry Pi Icon installiert, dessen Quellcode auf den ARM-Prozessor übertragen und dort compiliert, konfiguriert, eine IDE installiert und konfiguriert.

    Noch nie ist mir dabei ein System abgestürzt oder "hängen geblieben".

    Das Verfahren dazu ist mittlerweile etabliert und auch von anderen erfolgreich umgesetzt worden.

    Und bevor Du das nicht selber probiert hast, weißt Du auch nicht mit Sicherheit, ob es nicht vielleicht doch funktioniert.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Ich möchte nur interessehalber melden, dass ich bei einem meiner PIs im lokalen Netzwerk seit ca. 3 Wochen dasselbe Problem habe. Der PI ist per Wifi angebunden und im Fehlerfall nicht mehr per SSH oder Browser (da läuft eine Webanwendung von mir drauf) zu erreichen.

    Ich bin aber auch der Meinung, dass da was mit dem "Netzwerk" an sich nicht in Ordnung ist. Bei SSH dauert mit das zu lange, aber wenn ich im Browser im Fehlerfall refreshe, kommt der nach x Versuchen plötzlich wieder.

    Raspian

  • Ich kann dazu nur sagen, daß dieses Problem bei mir mit der neuen Stromversorgung der Vergangenheit angehört. Der Pi ist nun mal als "Experimentierkasten" gedacht, und bei den gängigen Experimenten kommen selten mehr als ein USB-Gerät zum Einsatz, und noch seltener welche mit extremen Stromhunger.

    Wenn ich jetzt wetten müsste, würde ich darauf setzen, daß Dein WiFi-Stecker die Stromversorgung des USB-Kontrollers in den Keller zieht. Vielleicht nicht permanent, sondern nur zu Spitzenlasten, aber das reicht, um irgendwo im Speicher Bits kippen zu lassen. Vergiss nicht, daß alle USB-Geräte, auch die Netzwerkschnittstelle, über genau eine(!) USB-Schnittstelle laufen und sich somit genau eine(!) Stromquelle teilen!

    Probiere es einfach aus: stecke alle USB-Geräte vorübergehend an einen externen und aktiven HUB, auch Maus und Tastatur, denn da gibt es auch wahre Stromvernichter. Wenn dann nach mehreren Tagen keine Unterbrechung mehr auftritt, kannst Du davon ausgehen, daß Du die Fehlerquelle gefunden hast.

    Bei mir hat der Zusammenbruch der Versorgungsspannung sogar dazu geführt, daß es im Dateisystem auf der SD-Karte zu nicht behebbaren Fehlern kam, und das bei ext4, was eigentlich sehr robust ist. So waren auf der 4GB-Karte plötzlich Dateien vorhanden, die angeblich mehrere TB groß waren. Gemerkt habe ich das, als die Datensicherung plötzlich elendig lange für einzelne Dateien brauchte.

  • Das würde ich ja alles gelten lassen, wenn nicht genau dieser PI seit über einem Jahr unangetastet an der selben Stelle, an der selben Steckdose, mit demselben Wifi-Stick, etc. stehen würde und bis vor 3 Wochen absolut zuverlässig funktioniert hat... MYSTERIUM :)

  • Es ist nicht ausgeschlossen, daß das verwendete Netzteil gealtert ist. Besonders diese Steckernetzteile, die für wenige Euros zu kriegen sind, verwenden oft minderwertige Elkos, die schon mal gerne hops gehen nach einiger Zeit.

    Prüf einfach mal die Spannung auf dem Pi zwischen TP1 und TP2. Was hast Du zu verlieren?

Jetzt mitmachen!

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