Lösung: Unable to resolve hostname

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo dreamshader,

    war dumm von mir, hätte mich vorab schlau machen sollen, wie -spoiler- oder -code- dafür zu nutzen ist. Wollte, nachdem Andreas die Antwort gesichtet hat, diesen Teil wieder löschen/entfernen. ich hoffe, daß das möglich ist.

    Hallo rpi444,

    vielen Dank, habe das Paket installiert.
    Nach der Eingabe: sudo tcpdump -vvveni ppp0 und aktiver VPN-Verbindung kommt das hier(nur ein kurzer Ausdruck dargestellt):

    pi@raspberrypi ~ $ sudo tcpdump -vvveni ppp0
    tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    14:00:37.917274 Out ethertype IPv4 (0x0800), length 272: (tos 0x0, ttl 64, id 15339, offset 0, flags [DF], proto UDP (17), length 256)
    10.206.219.37.55286 > 217.50.126.128.4500: [udp sum ok] UDP-encap: ESP(spi=0x9bc07828,seq=0xb03), length 228
    14:00:37.917685 Out ethertype IPv4 (0x0800), length 192: (tos 0x0, ttl 64, id 15340, offset 0, flags [DF], proto UDP (17), length 176)

    Die Auflistung setzt sich unendlich fort, habe mit Strg + C abgebrochen.

    Leider verstehe ich dessen Bedeutung nicht ansatzweise.

    Gruß Meisengeier


  • Nach der Eingabe: sudo tcpdump -vvveni ppp0 und aktiver VPN-Verbindung kommt das hier(nur ein kurzer Ausdruck dargestellt):

    Code
    pi@raspberrypi ~ $ sudo tcpdump -vvveni ppp0
    tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    14:00:37.917274 Out ethertype IPv4 (0x0800), length 272: (tos 0x0, ttl 64, id 15339, offset 0, flags [DF], proto UDP (17), length 256)
        10.206.219.37.55286 > 217.50.126.128.4500: [udp sum ok] UDP-encap: ESP(spi=0x9bc07828,seq=0xb03), length 228
    14:00:37.917685 Out ethertype IPv4 (0x0800), length 192: (tos 0x0, ttl 64, id 15340, offset 0, flags [DF], proto UDP (17), length 176)


    Die Auflistung setzt sich unendlich fort, ...

    OK, aber bei aktiver (d. h. funktionierender) VPN-Verbindung werden doch nicht nur (Out-)Verbindungen von "10.206.219.37.55286 > 217.50.126.128.4500" sondern auch von "217.50.126.128 zu 10.206.219.37" angezeigt, oder?

    D. h. ein evtl. sinnvoller Filter wäre der udp-Port 4500.

    Versuch mal mit:

    Code
    sudo tcpdump -c 100 -vvveni ppp0 udp port 4500


    wenn die VPN-Verbindung nicht funktioniert.

    In der FritzBox.conf wirst Du ja nicht die IP-Adresse 217.50.126.128 eingetragen haben. Evtl. auch die Namensauflösung (mit nslookup oder, dig) , bei nicht funktionierender VPN-Verbindung, testen.

    EDIT:

    Wenn dir die externe IPv4-Adresse deiner FritzBox, bei nicht funktionierender VPN-Verbindung (vom PI zur FB) bekannt ist, dann versuch mal auf deinem PI, auch:

    Code
    nc -zv <externe-IPv4-Adresse-FritzBox> 8089

    Z. B. jetzt sieht das so aus:

    Code
    :~ $ nc -zv 217.50.126.128 8089
    Connection to 217.50.126.128 8089 port [tcp/*] succeeded!


    Ist zwar tcp und nicht udp, aber egal denn es kann ein Hinweis sein, ob die Verbindung vom PI zur FB über das Internet, möglich 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 (11. September 2016 um 14:43)

  • Hallo rpi444,

    bei der Eingabe (VPN aktiv) von "sudo tcpdump -c 100 -vvveni ppp0 udp port 4500" kommt:

    pi@raspberrypi ~ $ sudo tcpdump -c 100 -vvveni ppp0 udp port 4500
    tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    17:56:03.712201 Out ethertype IPv4 (0x0800), length 49: (tos 0x0, ttl 64, id 47308, offset 0, flags [DF], proto UDP (17), length 33)
    10.120.30.167.43389 > 217.50.126.128.4500: [udp sum ok] NONESP-encap: [|isakmp]
    17:56:13.215608 Out ethertype IPv4 (0x0800), length 49: (tos 0x0, ttl 64, id 47424, offset 0, flags [DF], proto UDP (17), length 33)
    10.120.30.167.43389 > 217.50.126.128.4500: [udp sum ok] NONESP-encap: [|isakmp]
    17:56:19.544825 In ethertype IPv4 (0x0800), length 45: (tos 0x0, ttl 51, id 5354, offset 0, flags [none], proto UDP (17), length 29)
    217.50.126.128.4500 > 10.120.30.167.43389: [no cksum] isakmp-nat-keep-alive
    17:56:22.719141.....usw.
    ^C
    7 packets captured
    7 packets received by filter
    0 packets dropped by kernel
    pi@raspberrypi ~ $


    Bei Eingabe von: nc -zv 217.50.126.128 8089 kommt:

    Connection to 217.50.126.128 8089 port [tcp/*] succeeded! (genau wie von dir geschrieben)

    "Ist zwar tcp und nicht udp, aber egal denn es kann ein Hinweis sein, ob die Verbindung vom PI zur FB über das Internet, möglich ist."

    Ich weiß nicht, ob ich dich vielleicht auch nicht verstehe, aber in meiner Anfrage an Andreas geht es nicht darum, ob eine VPN-Verbindung hergestellt werden kann, denn das "läuft" soweit alles zu meiner Zufriedenheit, sondern darum, dass sich die VPN-Verbindung nicht immer zuverlässig per (meinem) Startscript (mittels "sudo pon" und "sudo vpn fritzbox.conf") herstellen läßt. Ich wollte das nur noch einmal erwähnt haben.

    Gruß Meisengeier

  • Hallo Andreas,

    ich habe nochmal einige "Versuche" mit dmesg gemacht, anbei die Anzeigen:

    dmesg | grep ppp0 (Aufruf mit direkter Kabelverbindung von PC zum Raspi)

    pi@raspberrypi ~ $ dmesg | grep ppp0

    [ 3780.645326] device ppp0 entered promiscuous mode


    [ 3781.050439] device ppp0 left promiscuous mode


    dmesg | grep ppp0 (Aufruf bei aktiver VPN-Verbindung, ohne Kabelverbindung)

    kein Ergebnis

    dmesg | grep eth0 (Aufruf mit direkter Kabelverbindung von PC zum Raspi)

    pi@raspberrypi ~ $ dmesg | grep eth0

    [ 2.859315] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:63:aa:72

    [ 14.577227] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup

    [ 16.125979] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1


    [ 18.797155] smsc95xx 1-1.1:1.0 eth0: link down

    dmesg | grep eth0 (Aufruf bei aktiver VPN-Verbindung, ohne Kabelverbindung)

    pi@raspberrypi ~ $ dmesg | grep eth0

    [ 2.859281] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:63:aa:72

    [ 13.518297] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup


    pi@raspberrypi ~ $


    Vielleicht sagt dir das was.

    Gruß Meisengeier


  • ..., , sondern darum, dass sich die VPN-Verbindung nicht immer zuverlässig per (meinem) Startscript (mittels "sudo pon" und "sudo vpn fritzbox.conf") herstellen läßt.

    Genau so habe ich das bzw. dich, auch aus deinem 1. Beitrag in diesem Thread, verstanden.

    Dass Du meine Vorschläge (noch) nicht verstehst, ist an den Ausgaben von tcpdump bzw. nc, die Du nur mit aktivem VPN zeigst, m. E. ersichtlich. Interessant ist der Vergleich der Ausgaben, mit und ohne funktionierender VPN-Verbindung. Oder wie willst Du die Ursache, warum es nicht immer zuverlässig mit deinem Startscript funktioniert, finden?

    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 zusammen,

    Genau so habe ich das bzw. dich, auch aus deinem 1. Beitrag in diesem Thread, verstanden.

    Dass Du meine Vorschläge (noch) nicht verstehst, ist an den Ausgaben von tcpdump bzw. nc, die Du nur mit aktivem VPN zeigst, m. E. ersichtlich. Interessant ist der Vergleich der Ausgaben, mit und ohne funktionierender VPN-Verbindung. Oder wie willst Du die Ursache, warum es nicht immer zuverlässig mit deinem Startscript funktioniert, finden?

    Meisengeier:
    Wir brauchen die Systemmeldungen, wenn die Verbindung zusammengebrochen ist - zu einem Zeitpunkt, an dem die Verbindung eigentlich stehen sollte.

    Wie die ganzen Systemmeldungen bei funktionierender Verbindung aussehen, das wissen wir.

    Erst aus dem abweichenden Systemverhalten können wir Ursachen erkennen und zuielführende Maßnahmen ableiten.

    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 Andreas,

    Zu deinem Zitat "Wir brauchen die Systemmeldungen, wenn die Verbindung zusammengebrochen ist - zu einem Zeitpunkt, an dem die Verbindung eigentlich stehen sollte" zeigt mir eigentlich nur, dass ich meine Eingangsanfrage wohl falsch formuliert habe. Zum besseren Verständnis, womit ich mich eigentlich beschäftige, möchte ich auf einen der beiden Beiträge hier aus dem Forum hinweisen:

    mephisti
    17. Juli 2014 um 20:44

    Ich nutze den Beitrag wegen dem "wvdial" zwar nicht 1:1, aber das Prinzip ist gleich.

    Ich wüßte daher absolut nicht, wie man eine Systemmeldung erhalten will, wenn die VPN-Verbindung deaktiviert ist? Bestenfalls kann man nach einem erneuten Verbindungsaufbau die LOG-Dateien betrachten, welche ja auch reichlich vorhanden sind. Leider habe ich hierfür ebenfalls nicht die Kenntnisse, diese auszuwerten.

    Gruß Meisengeier

  • Hallo Meisengeier,

    ich versuche, es nochmal zu erklären...

    Ein Computer nutzt ein Betriebssystem, um über mehrere Ebenen abgesetzt letztlich Anwendungsprogramme laufen zu lassen. Auf irgendeiner Ebene wird dann auch mal ein Dienst genutzt, der eine Verbindung zu / über eine/r Schnittstelle nutzt.

    Immer, wenn irgendein Dienst irgendwas macht, dann wird diese Aktion in eine Log-Datei geschrieben. Dies gilt insbesondere für Aktivieren, Deaktivieren und Reaktivieren.
    Somit kannst Du diese drei Aktionen sauber in den Log-Dateien verfolgen. Dies funktioniert sowohl beim beabsichtigten Aktivieren, Deaktivieren und Reaktivieren, damit Du erkennen kannst, was beispielsweise bei einem entsprechenden [font="Courier New"]ifup[/font] oder [font="Courier New"]ifdown[/font] passiert.
    Diese drei Aktionen werden aber auch vom Betriebssystem oder eines auf irgendeiner Ebene laufenden Dienstes durchgeführt. Wenn beispielsweise der Stromverbrauch so groß wird, dass einzelne Schnittstellen, Hardware, Verbindungen, Dienste nicht mehr versorgt werden können, dann schaltet der Raspberry Pi ausgewählte Dienste einfach mal so ab, damit der Rest umso stabiler laufen kann. Unter dem Stichwort Mysterium haben sich hier ganz viele Threads aufgetan, die dieses Phänomen von allen denkbaren Richtungen beleuchten. Wenn dann irgendwann wieder der deaktivierte Dienst versorgt werden könnte, dann wird er wieder reaktiviert.
    Auch diese Vorgänge werden sauber in einer der vielen Dateien in [font="Courier New"]/var/log[/font] gespeichert und auch archiviert.

    Die wichtigsten dieser Log-Einträge kannst Du über das Linux-Kommando

    Code
    dmesg


    erreichen.

    Solange Du aber keinen Unterschied benennen kannst, an dem man GUT von SCHLECHT unterscheiden kann, kann Dir hier auch niemand eine Lösung präsentieren.

    Verbindung steht
    LOG-Datei enthält einen Hinweis
    ...
    Verbindung bricht zusammen
    LOG-Datei enthält einen Hinweis
    ...
    Verbindung wird wieder hergestellt
    LOG-Datei enthält einen Hinweis
    ...
    Verbindung bricht zusammen
    LOG-Datei enthält einen Hinweis

    Auf diesem Prinzip setzt mein [font="Courier New"]HostRepair[/font] auf. Eine bestehende Verbindung ist an bestimmten Inhalten von Dateien im Linux-Dateisystem erkennbar. Fehlen diese Inhalte, gibt es die Verbindung nicht (mehr). Versucht eine Anwendung, diese Verbindung zu nutzen, wenn sie gerade mal nicht mehr existiert, dann produziert diese Anwendung eine unschöne Fehlermeldung.

    Läuft [font="Courier New"]HostRepair[/font] mit minimalen Ressourcen im Hintergrund, dann werden diese ausgewählten Linux-Dateien untersucht und im Fehlerfall wieder hergestellt. Dies führt dazu, dass die Verbindung wieder steht - bevor eine andere Anwendung einen Verbindungsverlust feststellen konnte.

    Also nochmals die Fragen:
    Was steht in den logs, was liefert [font="Courier New"]dmesg[/font] bei einer gewollt aktiven Verbindung und bei einer unbeabsichtigt verlorenen Verbindung?

    Erst dann ist es eine Kleinigkeit, dies in eine Software zu stecken und Dein beschriebenes Problem zu lösen.


    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 (16. Oktober 2017 um 00:07)

  • Hallo Andreas,

    vielen Dank für deine Hinweise, habe diese befolgt und in den letzten Tagen (bis eben) ALLE Log-Dateien akribisch durchforstet. Aber leider konnte ich hierin keine Hinweise / Veränderungen finden, welche irgendwie zur weiteren Auswertung herangezogen werden könnten. So speichert bei mir z.B. die "dmesg" Datei nur Einträge, wenn der Raspi neu gestartet wird. Ich habe das daran gesehen, weil ich einen Verbindungsabbruch hatte, habe den Zeitpunkt aufgeschrieben und eine Kabelverbindung hergestellt; der Raspi war nicht abgestürzt, aber in keiner Log-Datei war ein Eintrag zu dieser Zeit passend vorhanden. Weiterhin habe ich noch mit der Datei /etc/ppp/peers/umts "herumexperimentiert". Hier habe ich den einen oder anderen Befehl auskommentiert, mit dem Ergebnis, dass die VPN-Verbindung dennoch aufgebaut wurde. Sieht so aus, als wäre diese Datei schon nicht richtig konfiguriert. Kurzum, ich weiß einfach nicht, was ich noch machen könnte, wo noch suchen.
    Würde es daher vielleicht doch Sinn machen, dein Programm trotzdem mal zu installieren, gerade weil kein Fehler zu finden ist? Falls ja, würdest du mir bitte mitteilen, wie es für meinen Zweck anzupassen wäre?

    Gruß Meisengeier

  • Hallo Meisengeier,



    vielen Dank für deine Hinweise, habe diese befolgt und in den letzten Tagen (bis eben) ALLE Log-Dateien akribisch durchforstet. Aber leider konnte ich hierin keine Hinweise / Veränderungen finden, welche irgendwie zur weiteren Auswertung herangezogen werden könnten.


    Das glaube ich nicht. Alles, was irgendein Programm oder Dienst umschaltet, wird in LOG-Dateien gespeichert. Es wäre für eine Fehlersuche extrem unangenehm, wenn das nicht so wäre.


    [font="Courier New"]dmesg[/font] gibt nur Meldungen seit dem letzten Booten aus. Wenn es zu Fehlern kommt, kannst Du diese mit [font="Courier New"]dmesg[/font] nach einem Reboot nicht mehr finden. Dies ist aber mit den Log-Dateien möglich.

    Du kannst mein Programm [font="Courier New"]HostRepair[/font] gern für Deine Bedürfnisse anpassen. Du müsstest lediglich die IP-Adressen anpassen, die in dem Programm verwendet werden. Und die Programmiersprache Icon installieren... wie das geht steht im Icon Tutorial Teil 1.. Allerdings wird es schwierig werden, dem Programm beizubringen, woran es einen ungewollten Verbindungsabbruch erkennen kann - solange es Dir nicht gelingt, diese Frage zu beantworten. Erst, wenn man weiß, was auf Deinem System passiert, kann man dann auch sinnvolle Gegenmaßnahmen anleiern und im Programm codieren.

    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 (16. Oktober 2017 um 11:41)

  • Hallo Andreas,

    nachdem ich nun wieder einige Tage intensiv auf Einträge in den Logdateien, insbesondere bei einem Absturz der VPN-Verbindung, geachtet habe, ist das Ergebis immer noch gleich: Es wird in keiner bzw. für mich sichtbare Logdatei irgendwas dazu erfasst! Auch nach einem Neustart des Raspi ist kein Eintrag zu finden! Wenn gemäß deiner Aussage das eher untypisch ist, beschleicht mich mehr und mehr der Gedanke, ob es nicht vielleicht doch ein Netzteilproblem ist oder zumindest daran beteiligt sein kann? Das würde zumindest erklären, warum eben nichts "festgehalten" wird. Wie ich schrieb, versorge ich den UMTS-Stick schon mit einem Aktivhub von D-Link. Aber möglicherweise ist er ungeeignet, das falsche Modell? Zumindest bleibt der Stick an (in Betrieb), wenn ich den Raspi herunterfahre. Meine Frage wäre und wenn du so freundllich wärst: Kannst du mir einen brauchbaren Aktivhub nennen?

    Gruß Meisengeier

  • Hallo Meisengeier,


    Frage wäre und wenn du so freundllich wärst: Kannst du mir einen brauchbaren Aktivhub nennen?


    den hier beispielsweise. Den habe ich seit über zwei Jahren vollkommen problemlos an allen RPi-Modellen (die ich habe) eingesetzt.

    Der Klassiker ist der D-Link Dub H7. Den habe ich in meinem ersten Industrie-Projekt 2013 verbaut. Der ist sehr robust. Und das war das Stichwort des damaligen Projekts, nachdem mehrere HiTech-Produkte auf dem damaligen Markt bei harmlosen Tests versagten.

    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 (16. Oktober 2017 um 00:40)

  • Hallo Andreas,

    den DLink USB-Hub habe ich inzwischen erhalten und auch ausprobiert. Neben einigen Scriptänderungen sieht es nun so aus, als hätte das was gebracht: Dieser "doppelte" Aufruf hat sich jedenfalls in "Luft" aufgelöst. Vielen Dank nochmal für den Tip zum Aktivhub.

    Geblieben sind leider die gelegentlichen Abstürze der VPN-Verbindung, welche sich, obwohl der Raspi dann noch per Kabel erreichbar ist und reagiert, nach wie vor nur durch den "Netzstecker ziehen" beseitigen lassen. Mache ich das nicht und sende z.B. per SMS ein "shutdown" reagiert der Raspi zwar darauf (und manchmal auch nicht), aber nach einem Neustart funktioniert der Programmablauf nicht mehr ordnungsgemäß. Es scheint, als wäre etwas "hängen" geblieben, als würde sich der Raspi oder der UMTS-Stick die nicht ordnungsgemäß abgearbeiteten Kommandos "merken"? Falls dem so ist, gibt es eine Möglichkeit das "Gedächtnis" vor oder beim Neustart zu löschen?

    Weiterhin habe ich in den letzen Tagen immer wieder verschiedene Abfragen bei aktiver VPN-Verbindung und nach dem Absturz miteinander verglichen und als einziger Unterschied ist mir nun endlich das aufgefallen:

    pi@raspberrypi ~ $ nslookup fernschalten.ddns.net

    Ausgabe, VPN aktiv:

    Server: 192.168.178.1 (ist meine Fritzbox)
    Address: 192.168.178.1#53 (diese IP kenne ich nicht, meine lautet: .....178.201, vergeben von meiner Fritzbox)
    Non-authoritative answer:
    Name: fernschalten.ddns.net (ist meine Dyn DNS)
    Address: 77.7.0.22

    Abfrage nach Absturz der VPN-Verbindung, Kabel angeschlossen:

    ;; connection timed out; no servers could be reached
    Zeitüberschreitung der Verbindung; keine Server erreicht werden konnte

    Diese Abfrage ist genau die, welche du gleich zu Beginn meiner Anfrage erwähnt hast (dein Gespühr war also genau richtig) und wofür ich nach den Tips von rpi444 und dreamshader bereits am 11.09.16 das Paket "dnsutils" installiert und eine Abfrage bei AKTIVER VPN-Verbindung gemacht habe. Nur leider habe ich zu dem Zeitpunkt durch meine viele Probiererei (u.a. mit den Logdateien) vergessen, diese bei inaktiver Verbindung zu wiederholen.
    Was solls, besser spät als nie.

    Jetzt wäre ich dir natürlich dankbar, wenn du mir mitteilen würdest, ob sich dieser Unterschied nun überhaupt in irgendeiner Form verwenden ließe und falls ja, wie? Soweit ich gesehen habe, stürzt der ppp-deamon ab, lässt sich durch sudo poff -a, sudo pon nicht mehr "restarten".
    Schlussendlich würde ich damit auch einfach nur einen "shutdown" auslösen.

    Gruß Meisengeier

  • Hallo Meisengeier,

    jetzt hat man in der Tat etwas, worauf man eine Abfrage in der Software stützen kann. Ich poste irgendwann im Laufe des Abends eine Lösung. Kann auch sein, dass es etwas umfangeicher wird. Mir schwebt eine Konfiguration vor, die der Anwender leicht nach seinen Vorstellungen anpassen kann - während die Software nur die Einstellungen nutzt und die dort definierten Verbindungen prüft und ggf. wieder herstellt.

    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 (29. Juli 2017 um 15:17)


  • Address: 192.168.178.1#53 (diese IP kenne ich nicht, meine lautet: .....178.201, vergeben von meiner Fritzbox)

    Diese IP kennst Du schon. Das ist die interne IP-Adresse der FritzBox. "#53" steht für den Port 53 (DNS).
    D. h., dein PI will erstmal für die Namensauflösung (DNS) nur die VPN-Verbindung zur FritzBox nutzen, was bei nicht aktiver VPN-Verbindung ja nicht möglich ist.

    Konfiguriere die Namensauflösung deines PIs so, dass dieser zusätzlich "sofort" (... d. h. ohne reboot und/oder gleichwertig) auch die UMTS-Verbindung (ins Internet) für die Namensauflösung (DNS) nutzt (und nicht nur die FritzBox/VPN).

    EDIT:

    Poste von deinem PI, die Ausgaben von:

    Code
    cat /etc/resolv.conf
    cat /etc/resolvconf.conf

    EDIT 2:

    Mit z. B. einer iptables-Regel, kannst Du deinen PI auch so "konfigurieren", dass die Namensauflösung (DNS) für fernschalten.ddns.net, nie von der FritzBox (192.168.178.1) gemacht wird:

    Code
    sudo iptables -I OUTPUT 1 -p udp -d 192.168.178.1 --dport 53 -m string --algo kmp --string fernschalten -j REJECT


    , sondern von den anderen (externen) DNS-Server (z. B. 8.8.8.8 oder gleichwertig), die in der /etc/resolv.conf-Datei deines PIs eingetragen sind und über die UMTS-Verbindung sicher und immer erreicht werden können.

    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 (4. Oktober 2016 um 13:35)


  • Hm, wie @dreamshader@ schon schrieb: Symtombehandlung.
    Ist wie: "Schütt mal ab und zu 'n Eimer Wasser auf die glühenden Bremsen, damit die nicht verbrennen" (an die angezogene Handbremse denkt keiner) :lol:

    Ok, also mal Butter bei die Fische, wie man so sagt:
    Was steht denn so in den Log-Files? Also dmsg, messages usw...
    Der Verbindungsabbruch (um einen solchen handelt es sich ja offensichtlich) muss ja eine Ursache haben:

    und was soll ein User machen? den PI nachentwickeln mache ich ja schon, bessere größere Stützkondensatoren verlöten, aber jedes verkaufte Teil nachentwickeln?

    Ich kann Andreas verstehen, ich hatte mal ein NAS
    RaidSonic IB-NAS2001-B Icy Box NAS-System

    das hat immer den Webserver verloren, die LOGs liefen über! also per SW ein cut der LOGs eingeführt mit tail die letzten 100 Meldungen das die Log Datei nicht die Platte sprengt!

    Ursache war Absturz des Webservers, warum wieso, bin ich als User der Ursachenforscher? das ist nun wirklich nicht die Aufgabe des Users!

    Das Problem betraf alle RaisSonic Nutzer der 4220 & 2001b also wurde als würgaround eingeführt, Dienst vorhanden prüfen wenn nicht Prozess kill und Prozess Neustart!

    http://forum.nas-forum.org/index.php?page…light=#post1648

    Ich weiss ist Krampf aber die schnellste Lösung!

    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)

    Einmal editiert, zuletzt von jar (4. Oktober 2016 um 15:04)

  • Hallo Andreas,

    vorab vielen Dank für deine Bemühungen.
    Vielleicht ist es ja unwichtig?, aber ich möchte nur noch mal kurz erwähnen, dass die VPN-Verbindung nicht ständig aktiv ist, sondern daß ich diese (weil die Fritzbox eine ständige Verbindung ohnehin nach 1 Stunde automatisch beendet) per SMS für jeweils 30 Minuten aufrufe.

    Hallo rpi444,

    habe wieder vielen Dank.
    Das "#53" die DNS-Portnummer der Fritzbox ist, wußte ich nicht.

    Könntest du mir bitte kurz mitteilen, wo ich Hinweise zur Anwendung der Funktion "code" oder "spoiler" finde, damit die "resolv"-Dateien "verkleinern" kann? (dreamshader hatte mich zu recht ermahnt, das zukünftig zu verwenden)

    Verstehe ich das "Konfiguriere die Namensauflösung deines Pis so........" dahingehend richtig, dass ich deinen Vorschlag gemäß EDIT 2 ausführen soll? falls ja, was passiert dann? Ändern sich dadurch die Einträge in der "resolv.conf"? Läßt sich die Eingabe gegegebenfalls rückgängig machen oder sollte ich vorher ein Backup machen? Dazu solltest du wissen, dass für mich die ganzen Abläufe und Zusammenhänge absolutes Neuland sind und ich daher sicher sehr begriffsstutzig wirken muss. Aber ich bin sehr interessiert, das besser zu verstehen.

    Hall jar,

    ebenfalls erst einmal danke für deinen Hinweis.


    Gruß Meisengeier


  • Könntest du mir bitte kurz mitteilen, wo ich Hinweise zur Anwendung der Funktion "code" oder "spoiler" finde, damit die "resolv"-Dateien "verkleinern" kann? (dreamshader hatte mich zu recht ermahnt, das zukünftig zu verwenden)

    Das geht im Text (Beitrag) mit z. B.:
    '\[code'\]

    '\[/code'\]
    und
    '\[spoiler'\]

    '\[/spoiler'\]
    ohne die Maskierung.


    Verstehe ich das "Konfiguriere die Namensauflösung deines Pis so........" dahingehend richtig, dass ich deinen Vorschlag gemäß EDIT 2 ausführen soll?

    Nein, noch nicht. Poste zu erst, die Ausgaben aus dem 1. EDIT:

    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 (4. Oktober 2016 um 15:16)

  • Hallo rpi444,

    danke, hier die Inhalte bei aktiver VPN-Verbindung.

    '\[/spoiler'\]
    pi@raspberrypi ~ $ cat /etc/resolv.conf
    # Generated by resolvconf
    nameserver 192.168.178.1
    nameserver 212.23.103.8
    nameserver 212.23.103.9


    pi@raspberrypi ~ $ cat /etc/resolvconf.conf
    # Configuration for resolvconf(8)
    # See resolvconf.conf(5) for details


    resolv_conf=/etc/resolv.conf
    # If you run a local name server, you should uncomment the below line and
    # configure your subscribers configuration files below.
    #name_servers=127.0.0.1


    # Mirror the Debian package defaults for the below resolvers
    # so that resolvconf integrates seemlessly.
    dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
    pdnsd_conf=/etc/pdnsd.conf
    unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf

    Hoffe, dass es mit "spoiler" funktioniert.

    Gruß Meisengeier


  • Hoffe, dass es mit "spoiler" funktioniert.

    so leider nicht, aber du darfst deine Beiträge editieren

    deinen Wunsch code spoiler einfach in [ ] setzen ohne "

    wie bei quote

    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)

Jetzt mitmachen!

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