Lösung: Unable to resolve hostname

L I V E Stammtisch ab 20:30 Uhr im Chat

  • deren Ursache auch zu erforschen ist.

    Ja, klar.



    Bei den zahlreichen Berichten mit diversesten Fehlerbildern konnte überwiegend eine unzureichende Spannungsversorgung identifiziert werden - bzw. bei Bereitstelluing einer nachweislich unzureichenden Spannungsquelle konnten die gleichen Fehlerbilder erhalten werden. Somit kann man hier nicht ausschließen, dass auch hier ein schwaches Netzteil die eigentliche Ursache darstellt.

    Ja, ... dazu hat Meisengeier im Beitrag #69 geschrieben:

    Zitat


    Hallo Andreas,

    nochmal zum Netzteil:
    Den Raspi speist ein Original Raspi 3 Netzteil, 5,1 Volt; 2,5 A. Am Raspi hängt nur ein Temperatursensor, mehr nicht. Der UMTS-Stick wird nun von einem DLink DUB H7 Aktivhub (dein Vorschlag) versorgt. Weiter ist dort nichts angeschlossen!

    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

  • Hallo Rpi444,


    Ja, ... dazu hat Meisengeier im Beitrag #69 geschrieben:

    Das habe ich noch im Gedächnis. Nur ob bei dieser Massenware die Qualität stimmt? Was drauf steht, ist das Eine - was rauskommt, das Andere. Hier bleibt letztlich auch der Nachweis schuldig, dass da bei 5.1 V wirklich mehr als 1000 mA fließen können. Bzw. ob da keine Rückspeisung erfolgt wie bei den früheren RPi - und vielleicht doch der aktive USB-Hub die eigentliche Spannungsversorgung darstellt?

    Eine sichere Auskunft, wieviel Strom beispielsweise der RPi zieht, wenn der aktive USB-Hub angeschlossen ist. Kommt hier nämlich 0 heraus, dann ist da die Ursache gefunden.

    Meisengeier: Na, wie schaut's aus?


    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.

  • Hallo Leute,

    ich denke, ich habe mein "Problem" inzwischen mehr als ausgiebig dargelegt. Da kann es eigentlich nicht mehr sein, dass ich immer wieder das gleiche erklären soll, z.B. ob nun die Internetverbindung oder der VPN-Tunnel zuerst "weg" ist. Das kann ich nicht sagen, denn das eine funktioniert nunmal ohne das andere nicht! Und da ich die Ursache bisher nicht finden konnte und ihr auch nicht, wäre ich schon zufrieden gewesen, wenn Dank des Scrpites von Andreas der Raspi bei einem Verbindungsabbruch automatisch heruntergefahren und neu gestartet worden wäre. Dafür sollte ich vorab einen Unterschied zwischen aktiver VPN-Verbindung und nach einem Absturz "liefern". Den habe ich ja nun gefunden und mitgeteilt. Eigentlich wolltest du, Andreas, mir jetzt ein Script zusenden. Bekomme ich das noch?


    Zitat von jar: " ich bekomme die Kriese, soll ich dich als hoffnungslosen Fall auf Ignore setzen?"

    Ja bitte. Hauptsache, du fühlst dich dann besser.

    Ich wünsche euch eine gute Nacht.
    Ich gehe jedenfalls jetzt schlafen.

    Gruß Meisengeier

  • ich weiss keinen Grund warum du deinen Fehler in #59 nicht korrigieren willst, aber so ignorant auf Hilfe hoffen ist DEIN Ding und führt sicher weiter zum Erfolg!

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)


  • ..., denn das eine funktioniert nunmal ohne das andere nicht! ...

    Das ist so nicht richtig, denn die Internetverbindung sollte/muss auch ohne VPN-Verbindung funktionieren, aber die VPN-Verbindung ist (hier, in deinem Fall) ohne Internetverbindung nicht möglich.

    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

  • Hallo rpi444,

    "Das ist so nicht richtig, denn die Internetverbindung sollte/muss auch ohne VPN-Verbindung funktionieren, aber die VPN-Verbindung ist (hier, in deinem Fall) ohne Internetverbindung nicht möglich."

    Das weiß ich. Gemeint war, dass der Raspi ja an einem Ort (Gartenlaube) ohne Internetanschluss stehen soll, und da braucht man eben beides. Weil der Raspi z.B. ohne Internet keine Zeitbasis hat, baut dieser beim Neustart für ca 1 Minute (sodo pon) auch nur die Internetverbindung auf und wieder ab. Wenn die VPN-Verbindung gestartet werden soll, wird erst die Internetverbindung gestartet, dann geprüft (ping Internet) ob sie OK ist, wenn ja, wird die VPN-Verbindung (sudo vpnc fritzbox.conf) gestartet und ebenfall überprüft (ping Fritzbox). Der Verbindungsabbau geschieht per Script dann nach 30 Minuten andersherum.

    Hallo Andreas,

    Um die Spannung am Netzteil zu messen und weil ich leider keinen Micro-USB Adapter besitze, habe ich kurzerhand die Zuleitung "misshandeln" müssen. Zum Ergebnis: Das Netzteil liefert eine konstante Spannung von 5,19 Volt (direkt am Kabel) und liegt auch an den USB-Anschlüssen an. Hierfür habe ich solch ein China-Spannungs-Strommesser angesteckt. Weil mein Meßgerät im Strommessbereich leider gleich 0,4 Volt "schluckt" und damit die Strommessung zu ungenau wäre, habe ich hilfsweise zwecks Strombelastung den UMTS-Stick zusätzlich an den Pi gesteckt, den Aktivhub weggelassen. Im Ergebnis ließ sich die VPN-Verbindung dennoch öffnen, aber kurz danach war Schluss; hat der Pi die USB-Anschlüsse abgeschaltet, also 0 Volt. Dabei ist die Spannung des Netzteils völlig stabil geblieben, hat überhaupt nicht "gezuckt"! Dabei möchte ich noch erwähnen, dass ich die Stromentnahme der USB-Anschlüsse auf "MAX" eingestellt habe, ich glaube 1200 mA sind dann möglich? Zusammengefaßt sehe ich keinen Fehler des Netzteiles (das wäre ja auch wirklich ein Witz, wenn ein von Raspberry freigegebenes Netzteil nicht funktionieren würde) sondern allenfalls im Raspberry und dessen interne Steuerung selbst. Z.B. habe ich versuchsweise mal meinen Vorgänger Aktivhub (welcher ja auch funktioniert hatte) angeschlossen und festgestellt, dass der UMTS-Stick gar nicht mehr "startet". Danach wieder der neue dran: alles ok. Wie ist das zu erklären? Weißt du das? Desweiteren "spinnt" seit der heutigen Rumprobiererei mein "Startskript". Mittels "sleep" habe ich eine verzögerung von 120 Sekunden eingetragen, funktioniert normalerweise auch. Jetzt startet das Script schon nach ca. 30 Sekunden! Änderungen habe ich aber nicht vorgenommen. Was könnte das für Ursachen haben? Hat sich hier selbst etwas "verstellt"? Bei über 80000 Dateien vielleicht kein Wunder. Das sind jedenfalls momentan meine Mysterien.

    Gruß Meisengeier


  • Wenn die VPN-Verbindung gestartet werden soll, wird erst die Internetverbindung gestartet, dann geprüft (ping Internet) ob sie OK ist, wenn ja, wird die VPN-Verbindung (sudo vpnc fritzbox.conf) gestartet und ebenfall überprüft (ping Fritzbox). Der Verbindungsabbau geschieht per Script dann nach 30 Minuten andersherum.

    Was wird durch den richtigen/gewollten Start der VPN-Verbindung, am Internetzugang verändert/ergänzt? Wenn etwas verändert wird, wird das dann nach dem nicht gewollten Abbruch der Internet- (und VPN-)Verbindung auch wieder bzw. sofort rückgängig gemacht? ... so dass eine neue Internetverbindung, ohne Probleme aufgebaut werden kann?

    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

  • Hallo rpi444,

    hast du dir meinen Hinweis auf den Beitrag: "RPi mit UMTS Stick, VPN zu FritzBox" angesehen?
    Das sollte deine Fragen eigentlich beantwortet haben.
    Danach dürfte klar sein, das man bei einem Verbindungsabruch ja nur noch den Stecker ziehen kann oder das es, wenn man nicht vor Ort ist, und das ist ja der Sinn, nämlich eine Fernüberwachung, von einem Script bemerkt wirkt, was dann den Raspi, auf welche Art auch immer, wieder "startklar" machen müßte. Darum dreht sich ja meine Anfrage überhaupt. Da die absturzursache nicht bekannt ist, wollte ich gern das Script von Andreas nehmen. Als Grundlage wollte er einen Unterschied zwischen aktiver und deaktivierter VPN-Verbindung. Den habe ich "geliefert", wollte mir schon vor Tagen sein angepasstes Script zusenden. Hat er aber nicht, stattdessen geht es jetzt erst mal um das Netzeil, wie du weißt.

    Gruß Meisengeier


  • Das sollte deine Fragen eigentlich beantwortet haben.
    Danach dürfte klar sein, das man bei einem Verbindungsabruch ja nur noch den Stecker ziehen kann oder das es, wenn man nicht vor Ort ist, und das ist ja der Sinn, nämlich eine Fernüberwachung, von einem Script bemerkt wirkt, was dann den Raspi, auf welche Art auch immer, wieder "startklar" machen müßte.


    Nein, klar ist das nicht. Warum bist Du so sicher, dass nur noch "Stecker ziehen" helfen kann oder ein "Holzhammer-Methode"-Script? Klar, wenn Du aus welchen Gründen auch immer nicht in der Lage bist, die Ursache für die Internet-/VPN-Abbrüche zu suchen bzw. zu finden, dann wirst Du so ein Script haben wollen bzw. brauchen.

    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

  • Hallo Meisengeier,


    Um die Spannung am Netzteil zu messen und weil ich leider keinen Micro-USB Adapter besitze, habe ich kurzerhand die Zuleitung "misshandeln" müssen. Zum Ergebnis: Das Netzteil liefert eine konstante Spannung von 5,19 Volt (direkt am Kabel) und liegt auch an den USB-Anschlüssen an.


    Wann tut sie das? Ist der Raspberry Pi dann eingeschaltet oder misst Du die 5,19 V im unbelasteten Zustand?


    Hierfür habe ich solch ein China-Spannungs-Strommesser angesteckt. Weil mein Meßgerät im Strommessbereich leider gleich 0,4 Volt "schluckt" und damit die Strommessung zu ungenau wäre, habe ich hilfsweise zwecks Strombelastung den UMTS-Stick zusätzlich an den Pi gesteckt, den Aktivhub weggelassen. Im Ergebnis ließ sich die VPN-Verbindung dennoch öffnen, aber kurz danach war Schluss; hat der Pi die USB-Anschlüsse abgeschaltet, also 0 Volt.


    Zu klären ist, warum das passiert. Denn normal ist das nicht - und ist wohl ungewollt, oder?
    Hast Du dies über [font="Courier New"]dmesg[/font] odr Log-Dateien verfolgen können?


    Dabei ist die Spannung des Netzteils völlig stabil geblieben, hat überhaupt nicht "gezuckt"! Dabei möchte ich noch erwähnen, dass ich die Stromentnahme der USB-Anschlüsse auf "MAX" eingestellt habe, ich glaube 1200 mA sind dann möglich?


    Ja, 1200 mA über die 4 Ports sind dann möglich.


    Zusammengefaßt sehe ich keinen Fehler des Netzteiles (das wäre ja auch wirklich ein Witz, wenn ein von Raspberry freigegebenes Netzteil nicht funktionieren würde) sondern allenfalls im Raspberry und dessen interne Steuerung selbst. Z.B. habe ich versuchsweise mal meinen Vorgänger Aktivhub (welcher ja auch funktioniert hatte) angeschlossen und festgestellt, dass der UMTS-Stick gar nicht mehr "startet". Danach wieder der neue dran: alles ok. Wie ist das zu erklären? Weißt du das?


    Der neue was? Redest Du vom UMTS-Stick oder vom Aktiv-USB-Hub? Was ist mit dessen Netzteil? Wo war der UMTS-Stick? Befand er sich in einem (welchem) der beiden Aktiv-USB-Hubs oder in einem USB-Port des RPi?

    Und Dir ist schon klar, das eine Rückspeisung der Spannungsversorgung erfolgt bzw. erfolgen kann? Üblicherweise wird der RPi nicht mehr durch sein Netzteil versorgt sondern ausschließlich über die Spannung des Aktiv-USB-Hubs, die an dessen USB-Port anliegt. Und die dürften - sofern der Norm folgend - bei nicht viel mehr als 500 mA anzusiedeln sein. Und dies reicht ganz sicher nicht, um den RPi mitsamt weiterer Peripherie an dessen USB-Ports zu betreiben. Die Sachen werden dann einfach abgeschaltet. Das ist das, was wir hier unter Mysterium verstehen. All dies kann über [font="Courier New"]dmesg[/font] (und Log-Einträgen) verfolgt werden.

    Ein UMTS-Stick funktioniert nur, wenn
    a) die Spannungsversorgung passt
    b) die passende Software den UMTS-Stick unterstützt
    Wenn ersteres nicht gegeben ist (0 V am USB-Port) dann erklärt dies so ziemlich alles.


    Desweiteren "spinnt" seit der heutigen Rumprobiererei mein "Startskript". Mittels "sleep" habe ich eine verzögerung von 120 Sekunden eingetragen, funktioniert normalerweise auch. Jetzt startet das Script schon nach ca. 30 Sekunden! Änderungen habe ich aber nicht vorgenommen. Was könnte das für Ursachen haben? Hat sich hier selbst etwas "verstellt"? Bei über 80000 Dateien vielleicht kein Wunder. Das sind jedenfalls momentan meine Mysterien.


    Und Du bist sicher, dass "Dein" Startskript ausgeführt wurde? Und nicht ein Standard-Skript? Oder hast Du irgendwas an Deinem Start-Skript geändert? Oder sind Abfragen drin, die mal diese Verzögerung verwenden - und bei Vorliegen / Fehlen irgendwelcher Fakten nicht verwenden?


    Ich finde das alles sehr intransparent, was jegliche zielorientierte Unterstützung erschwert.

    Beste Grüße

    Andreas
    Automatisch zusammengefügt:
    Hallo Meisengeier,


    Nein, klar ist das nicht. Warum bist Du so sicher, dass nur noch "Stecker ziehen" helfen kann oder ein "Holzhammer-Methode"-Script? Klar, wenn Du aus welchen Gründen auch immer nicht in der Lage bist, die Ursache für die Internet-/VPN-Abbrüche zu suchen bzw. zu finden, dann wirst Du so ein Script haben wollen bzw. brauchen.

    Das mag in der Windows-Welt vielleicht so sein, bei irgendwelchen Problemchen, Neustart und alles wird wieder gut.

    Bei Linux gibt es für jede vermeintliche Störung eine Ursache, die in der Regel mit Bordmitteln des Betriebssystems erkannt werden kann und auch behoben werden kann. In Linux ist alles dateibasiert. Stellt ein Dienst seine Arbeit ein, dann fehlt einer anderen Datei ein Eintrag, weshalb etwas anderes (Internet, VPN, ...) nicht mehr funktioniert. Hier ist es lediglich erforderlich, genau dies zu erkennen und die Dienste entweder mit dem richtigen Futter neu zu starten - oder die fehlenden Einträge in den Dateien automatisch vornehmen zu lassen.
    Es bedarf keines Neustarts, Reboots, Steckerziehen... außer man weiß es nicht besser. Und da sind wir ja dran... sind da aber auf Deine Mithilfe angewiesen, dass Du die Fragen, die wir haben, aussagekräftig und zweifelsfrei beantwortest.

    All das macht aber nur Sinn, wenn die Spannungsversorgung passt. Und in diesem Punkt ist mir weiterhin Entscheidendes unklar.


    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.

    Einmal editiert, zuletzt von Andreas (6. Oktober 2016 um 22:26)

  • Hallo zusammen,

    hier die neuste Version von HostRepair.

    Neuerungen:

    • Ein paar ressourcenschonende Algorithmen haben Einzug gehalten
    • Einlesen einer Konfigurationsdatei zur Festlegung der zu prüfenden Netzwerkverbindung
    • Ein exponentieller Schieberegler (zur Basis 1.1)
    • Eine Ausgabe der Verzögerungszeit wird mit dem Schieberegler mitgezogen
    • Wenn eine Verbindung prinzipiell nicht existiert (z.B. kein LAN-Kabel eingesteckt, dann erkennt das Programm dies und deaktiviert die Option LAN - beim nächsten Durchlauf wird hier nichts mehr geprüft. Der Anwender müsste ein LAN-Kabel einstecken und die Option aktivieren. Dies beschleunigt die Arbeit dieser Anwendung erheblich, da nicht mehr auf etwas gepingt werden muss, was nicht da ist.
    • Ausgabe der aktuellen CPU-Auslastung

    host-repair.icn:

    Zwei Bilder veranschaulichen den Zusammenhang von Verzögerung und CPU-Auslastung. Selbst bei fehlender Verzögerung innerhalb der Ereignisbehandlung liegt die CPU-Auslastung bei wenig über 3%.


    Beste Grüße

    Andreas

Jetzt mitmachen!

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