Wenn ich nochmal nerven darf, kannst Du mit lsusb die USB-ID ermitteln?
MfG
Jürgen
Gerne doch!
ID 2109:3431 VIA Labs, Inc. Hub
Posts by Pils
Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
Mach mit und werde Teil unserer Community!
-
-
Den könnte ich wohl mal probieren.
Ich habe den neuen Adapter jetzt seit Ende April im Einsatz und hatte nicht ein einziges Mal dieses Problem mit dem Einfrieren gehabt.
Ich hoffe, das war es jetzt wirklich gewesen. Es hat schwer genervt. Danke an alle, die Hilfe geleistet haben!
Diesen Adapter habe ich gekauft:
https://www.amazon.de/dp/B01K22TZ3I/ref=pe_27091401_487024491_TE_item (Affiliate-Link)
-
Das erreichst Du auch mit einem USB3.0 Hub.
Vielleicht habe ich ja auch ein Montagsmodell des Adapters erwischt. Ich kaufe lieber einen neuen/anderen Adapter und dann gleich einen mit aktiver Versorgung. In der von dir geteilten Liste ist an fünfter Stelle ein Adapter mit Netzteil. CSL 2.5″ SATA to USB 3.0 Adapter*
Den könnte ich wohl mal probieren.
Ich sehe dann meistens das der Swap voll läuft.
Wie hast du diese Kurvenaufzeichnungen erstellt?
-
Hallo Leute,
ich habe einen Adapter mit der ID 174c:55aa (USB3S2SAT3CB von StarTech.com) am laufen. Der soll laut Liste ja ein geeigneter Adapter sein. Kann auch wirklich so sein. Leider bootet mein raspi trotzdem sporadisch neu. nach einigen Tagen kein Zugriff mehr auf den Pi möglich - Raspberry Pi 4 - Deutsches Raspberry Pi Forum (forum-raspberrypi.de)
Auch wenn ich nicht weiß, ob es wirklich am Adapter liegt, würde ich es gern mit einem anderen Modell mit eigenem Netzteil probieren. Ich habe in der Liste keinen mit eigenem Netzteil entdeckt. Gibt es bis jetzt keine bestätigten Modelle?
Vielen Dank!
-
Schalte einmal den VNC Server ab und schau danach in den Logfiles nach, iv der d-Bus error noch vorhanden ist.
Der Server scheint bereits nicht zu laufen. Er wird als inactive (dead) angezeigt.
Was ist bitte ein d-bus error?
-
Ja, tatsächlich. Habe es gerade probiert. Trotzdem habe ich wenig Hoffnung, dass es im Moment des Fehlers funktioniert. Werde es aber dann auch noch mal ausprobieren.
Bernd, hast du eine Idee, warum der raspi die cronjobs nicht mehr ausführt?
-
Der raspi ist nun Mal mein einziges Linux-System. Oder zählt Android?
Edit: Auf Android habe ich schon mehrfach den Termius SSH Client versucht. Wenn der Fehler da ist, kann ich mich mit dem auch nicht verbinden. Sonst natürlich schon.
-
dann ist Verbindung vorhanden und möglich.
Komisch, mit putty kann ich mich jedenfalls nicht verbinden. Alle webserver sind ebenfalls nicht erreichbar.
Was sagst du dazu, dass die cronjobs scheinbar nicht ausgeführt wurden?
Ich werde mir jetzt jedenfalls mal einen neuen USB Adapter kaufen. So geht es nicht weiter.
Versuch einen Ping bzw. arping auf den PI.
Ping funktioniert. Mit Adresse und auch mit hostname.
-
Gestern gegen 14 Uhr ist das Problem wieder aufgetreten.
Als ich abends den nmap Scan gemacht habe, wurden mir alle (relevanten) ports als offen angezeigt, auch port 22 für ssh. Trotzdem war keine Verbindung möglich. Ich kann den log später hier noch anhängen, bin gerade am Handy...
Der cronjob aus Post 34 hat leider nichts bewirkt. Ich habe dieses Mal bewusst nicht den Stecker gezogen. Selbst heute morgen war der raspi nicht wieder erreichbar, obwohl in der Nacht der cronjob den täglichen reboot hätte durchführen müssen, was er normalerweise zuverlässig macht.
Es werden also nicht mal cronjobs durchgeführt. Das Betriebssystem scheint also echt ein massives Problem zu haben in diesem Moment. Erst als ich heute morgen den Stecker gezogen habe, ging alles wieder normal weiter.
-
-
Okay, vielen Dank nochmal. Ich melde mich wieder, falls es erneut auftritt.
-
Danke! Ich habe deinen Vorschlag umgesetzt.
D. h. nach spätestens 15 Minuten machst Du einen TCP-Portscan auf den lauschenden Port des sshd.
Kannst du das bitte etwas genauer erklären. Mehr für "Unerfahrene" - Sorry!
Wenn der Fehler das nächste mal auftritt, reicht es nicht aus, einfach mit putty die SSH Verbindung zu testen?? Ich vermute, du meinst diese nmap Geschichte...?
-
Ooch menno!
Das Thema verfolgt mich leider immernoch. Ich hatte vor längerer Zeit einen täglichen Reboot in der Nacht eingerichtet, um dem sporadischen Neustart mit anschließender nicht-Erreichbarkeit zuvorzukommen. Das ist zwar nicht schön oder gar elegant, da kann ich aber grundsätzlich mit leben. Es hat jetzt auch wirklich lange keine Ausfälle mehr gegeben. Leider hat mich vor ein Paar Tagen trotzdem wieder genau die gleiche Situation ereilt, wie im ersten Post beschrieben. Das ist jetzt wirklich das erste Mal, dass innerhalb von 24h nach einem geordneten Reboot der Fehler auftrat. Vorher hat es immer einige Tage gedauert...
Ich muss weiter Ursachenforschung betreiben. Es ist wichtig für mich, dass der RasPi und seine Anwendungen erreichbar sind bzw. laufen.
Z. B. auf die Erreichbarkeit des gateway (Router) per arping (arp) und den PI auch regelmäßig einen gratuitous arp-reply machen lassen, denn so kannst Du im (W)LAN sehen ob der PI noch aktiv ist (... auch dann wenn er per icmp oder per tcp nicht mehr erreichbar ist).
Im Falle des Fehlers ist der RasPi per Ping erreichbar, das ist ja eine der Merkwürdigkeiten. Würde dein Vorschlag denn überhaupt weiterhelfen?
Ich überlege, ob ich eine andere SSD ausprobieren sollte oder einen anderen USB-Adapter? Es ist wirklich tragisch, dass die logs nichts hergeben. Worauf lässt das schließen? Wieso ist der ungewollte Reboot in der Konsequenz so anders als der bewusst ausgeführte?
-
Bin aus dem Urlaub zurück und es gab im WLAN in der Ferienwohnung keinerlei Probleme, sich mit dem VPN zu verbinden. Auch mit den mobilen Daten (z.B. am Strand) hat es alles gut funktioniert.
Ich werde mal weiter beobachten, in welchen Netzen es Probleme gibt...
-
Kommt die Verbindung jetzt _sofort_ zustande?
Die Verbindung kam in diesem Fall sofort zustande. Das tat sie vorher aber ja auch zum Glück häufig.
Für welches Gerät bzw. für welches OS, blockt Pi-hole die Werbung nicht (mehr)?
Ich hatte an beiden Smartphones testweise die Einstellungen in der Wireguard App geändert. Bei DNS statt der bisherigen IP die 8.8.8.8 eingesetzt. Verbindung hat jeweils funktioniert, Pi-hole hat Werbung jedoch nicht geblockt.
Es kann ja wohl nicht sein, dass die DNS-Server die man _nur_ für den WG-Client (... zur Auflösung des Endpunktes, damit die WG-VPN-Verbindung überhaupt erstmal zustande kommen kann) konfigurieren will/kann, für das "ganze" Gerät (hier das Smartphone) dann wirksam/gültig sind, oder?
Ich habe dieses Verhalten aber eigentlich so erwartet. Es soll ja jeglicher Traffic durch den Tunnel bzw Pi-hole laufen.
Ich kenne diese OSs (Android und iOS) nicht so gut, aber man sollte doch DNS-Server konfigurieren können (... z. B. auch wenn man keinen WG-Client auf so einem Gerät benutzt).
Ja, das geht wohl. Ich habe es gegoogelt. Bei mir sind dahingehend aber die Standardeinstellungen aktiv. Welche DNS dabei verwendet werden, wird einem nicht angezeigt.
BTW: Was genau meinst Du mit "mobile Daten"?
Internet über das Mobilfunknetz. Nicht WLAN.
In welchen Apps hast Du das geändert/eingetragen? Gibt es da mehrere Apps, in denen man die DNS-Server eintragen kann/muss?
Ich rede immer von den Wireguard Apps für Android bzw iOS. An keiner anderen Stelle habe ich bisher Einstellungen geändert. Letztendlich ist es die config der Peers, die man dort ändert. Nur in einem User Interface statt in einem Textfile.
Übrigens gab es heute morgen genau die gleichen Probleme beim Verbinden, auch mit der zusätzlichen 8.8.8.8 als zweiter DNS.
Ob es mit dem Smartphone funktioniert weiß ich nicht, Du kannst es ja testen.
Klingt gut, ich werde es testen.
Wenn sich die IP-Adresse des Endpoints, _während_ der bestehenden WG-VPN-Verbindung ändert, brauchst Du so oder so eine andere Lösung (z. B. was Gleichwertiges zum reresolv-dns.sh-Script).
Das ist schon okay. Einmal am Morgen aus und wieder ein ist kein Problem. Zumal das eh nur eintreten würde, wenn ich mal auswärts schlafe.
-
Ich habe jetzt mal in den Apps bei DNS 10.6.0.1 UND 8.8.8.8 eingetragen. Werde es die Tage beobachten.
Für heute muss ich Schluss machen. Vielen Dank für deine Hilfe!
-
Ich kann in der Wireguard App die mit QR importierten Einstellungen manuell verändern. Da habe ich jetzt die 10.6.0.1 durch 8.8.8.8 ersetzt. Die Verbindung kommt zustande aber Pi-hole blockt keine Werbung.
und nicht den/die DNS-Server für das Smartphone.
Ich glaube nicht, dass ich da etwas verändert habe. Kann man das für mobile Daten überhaupt machen?
-
Gute Frage(n)!
Ich könnte ja mal DNS = 8.8.8.8 in die Configs eintragen. Ich gehe dann aber davon aus, dass pi-Hole nicht mehr wirksam ist.
-
Hast Du beim erstellen der Config mit PiVPN, auch DNS-Server eintragen müssen?
Den DNS-Server legt man wahrscheinlich bei der Ersteinrichtung mit PiVPN fest. Das ist bei mir fast ein Jahr her. Ich weiß es nicht mehr, wie es genau war. Wenn man einen Peer hinzufügt, muss man keinerlei Adressen eingeben. Die vergibt PiVPN eigenständig. Man gibt lediglich einen Namen für den neuen Peer ein und die Configs werden automatisch von PiVPN erstellt. Dann nur noch den QR-Code mit der jeweiligen App scannen und fertig.
Ich kann sehen, dass auf beiden Smartphones die gleiche virtuelle Adresse für den Nameserver eingetragen ist. In meinem Fall ist das 10.6.0.1. Die beiden Clients enden mit 2 bzw. 3.
-
Aber beim WG-Client (Smartphones) hast Du für die Namensauflösung des Endpoints, andere DNS-Server eingetragen/konfiguriert, oder?
Ich habe die Konfiguration auf den Smartphones jeweils mit der QR-Code Scan-Methode eingerichtet / importiert. Die Configs selbst wurden mit PiVPN erstellt. Als Endpunkt steht dort jeweils die richtige dyndns in den Konfigurationen. Wird mir in den Apps auch als Endpunkt angezeigt. Bei der Android App wird dauerhaft die dyndns angezeigt, egal ob Tunnel aktiv oder nicht. In der iPhone App wird die dyndns nur angezeigt, wenn der Tunnel nicht aktiv ist. wenn er aktiv ist, wird dort scheinbar die aufgelöste IP angezeigt. Android und iOS unterscheiden sich hier scheinbar (nicht nur hier).
Wäre es (nur) eine Unterbrechung, würde der WG-Server, WG-Datenpakete an den WG-Client senden (was lt. deiner tcpdump-Ausgabe aber nicht der Fall ist).
Ja, wenn ich einen erfolgreich verbundenen Client trenne, sehe ich vom Server ausgehend noch Traffic im tcpdump. Das ist aber nicht der Fall, wenn ich erstmalig versuche die Verbindung aufzubauen und es nicht funktioniert.
Deine allererste Vermutung scheint richtig zu sein. Ich benötige wohl ein re-resolve für Android bzw. iOS.
