Posts by Meisengeier

    Hallo rpi444,


    hast du dir meinen Hinweis auf den Beitrag: "http://www.forum-raspberrypi.de/Thread-tutorial-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

    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

    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

    Hallo jar,


    ich hoffe mal, ich verstehe dich jetzt richtig: Die Spoiler-Funktion in #59 hatte ich natürlich falsch angewendet, ist also missglückt. "dbv" hat mir kurz darauf mitgeteilt, wie es richtig ist und ich denke, ich mache es jetzt korrekt.


    Hallo rpi444,


    nein, sowie die VPN-Verbindung abbricht, ist auch das Internet weg. Das habe ich mittels anschließender Netzwerk-Kabelverbindung vom PC zum Raspi probiert. Wie schon geschrieben, sind dabei scheinbar alle Verbindungen noch "intakt", selbst die Fritzbox zeigt eine aktive VPN-Verbindung (grüner Punkt) an, das ist sie aber nicht! Habe dann nochmal "sudo pon" per putty eingegeben und festgestellt: keine Reaktion. Wie ich auch schon schrieb, verhält sich der Raspi danach sehr "merkwürdig" in der Art, dass ein normaler "shutdown" mit einmaligem Neustart nicht hilft! Ich brauche dann mehrere Versuche (Netzstecker raus und wieder rein) bis der Programmablauf wieder normal läuft. (das schrieb ich in meinen Antworten (Andreas?) aber auch schon).
    Vielleicht sollte man mein Problemen mal ganz anders betrachten? Vielleicht ist das überhaupt kein netzwerkproblem? Andreas redet ja wiederholt von einem Mysterium = Netzteilprobleme. Möglicherweise hat er gar nicht mal so unrecht! Die Stromversorgung selbst möchte ich eigentlich ausklammern, aber kann es sein, dass mein Raspi eine Hardwaremacke hat? Hast du schonmal sowas gehabt? Denn ein ebenfalls unerklärliches Phänomen hat mein Pi. Und zwar schalte ich mit dem Pi gelegentlich versuchsweise Funksteckdosen über den VPN-Tunnel. Diese befinden sich im selben Raum wie der Pi, ca 2 -3 Meter entfernt. Die Antenne habe ich deshalb abgeschraubt. Aber nach einem VPN-Abbruch und in Verbindung mit den eben beschriebenen Neustarts muss ich die Antenne (gelegentlich) anschrauben! Das bedeutet doch, dass sich scheinbar die Sendeleistung verringert haben muss, oder? Da kann doch nur der GPIO ein schwächeres Datensignal liefern. Wenn ja, was hat das für eine Ursache? Läuft der Pi wieder "normal" kann die Antenne nämlich wieder ab.


    Gruß Meisengeier


    Gruß Meisengeier

    Hallo jar,


    "dein falsches Spoilerposting in #59, ich hatte sogar den Link mitgepostet, was ist daran nicht zu verstehen?"


    das habe ich schon verstanden, aber immer noch nicht, was es zu reparieren gäbe?


    Hallo rpi444,


    Tut mir leid, aber ich konnte nicht wissen, dass du meine DNS-Adresse direkt ausprobieren wolltest. Diese habe ich natürlich hier in den Artikeln abgeändert, denn sonst hätte ja JEDER Zugriff darauf. Das möchte ich natürlich nicht.
    Mein Provider ist 1&1, habe dort einen ganz normalen Tarif für Internet und Telefon. Wie schon erwähnt, UMTS mittels Aldi Karte.


    Ich weiß, dass du, wie auch Andreas, mir helfen wollt. Dafür bin ich euch wirklich sehr dankbar, zumal ihr nicht wirklich was davon habt. Aber bitte seit mir nicht böse, wenn ich so langsam denke, das wir so nicht weiterkommen werden und hier nur jemand helfen kann, der sich mit der Materie VPN-Tunnel auskennt, dass schon oft gemacht hat, will sagen: entweder man weiß es oder man weiß es nicht. Ich glaube, anders läßt sich der Fehler nicht finden bzw. beheben. Ein Beispiel: Ich hatte lange zeit Probleme mit dem Versenden einer SMS, wenn die VPN-Verbindung aktiv war. Habe ebenfalls hier im Forum um Hilfe gebeten. Die richtige Antwort blieb leider aus. Dann habe ich durch Zufall die Lösung gefunden: Der kleine Eintrag: smsc = 491770610000 (Eplus / O2 SMS-Zentrale) hat das Problem beseitigt! Das war alles, nur wenn mans nicht weiß....


    Gruß Meisengeier

    Hallo jar,


    deinen Kommentar verstehe ich leider absolut nicht. Was soll ich reparieren?


    Falls du deinen Tip meinst, den habe ich mir angesehen, aber verstehen tue ich hier nur "Bahnhof" Ist einfach so. Außerdem: Eins nach dem anderen. Hatte erstmal damit zu tun, rpi444 Anweisungen zu folgen und "abzuarbeiten".
    Dann hatte ich es schon mehrfach erwähnt: Ich habe bei weitem nicht die Kenntnisse wie Ihr, ziehe ja auch den Hut vor dem, was Ihr so alles wißt.


    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!
    Und auch nochmal: Die Bedingungen sind stets die gleichen. Es ist für mich daher nicht erkennbar, warum die VPN-Verbindung gelegentlich abbricht. Ich könnte mir noch vorstellen, das es an der Signalstärke des Mobilfunknetzes liegen könnte. Sieht aber nicht wirklich danach aus, denn manchmal ist die ok, und die VPN-Verbindung bricht trotzdem ab.


    Hoffe wirklich inständig, dass rpi444 noch die entscheidende Lösung findet oder dein Script, welches du mir zusenden möchtest.


    Zur Jugend gehöre ich mit Sicherheit nicht mehr.


    Gruß Meisengeier

    Hallo rpi444,


    "Wie kommen die DNS-Server 212.23.103.8 und 212.23.103.9 in die resolv.conf-Datei deines PI?"
    Das weiß ich nicht, die Datei war bis auf die 1. Zeile mit #-Taste, LEER, standen, ich glaube, nach meinen "nslookup" Abfragen automatisch drin.


    "Sind das die DNS-Server deines UMTS-Providers "e-plus"?"
    Ich habe meine DNS-Adresse bei No-IP angemeldet und in meiner Fritzbox eingetragen.
    ich habe keinen UMTS-Provider, sondern nur eine ganz einfachen Handy Talk-300-Tarif von Aldi. Meines Wissens nach ist es gar nicht möglich für einen UMTS-Stick eine feste IP zu bekommen. Eine Anfrage bei 1&1 hat mir das jedenfalls so bestätigt.
    Vielleicht hilft das:
    in meiner Fritzbox waren heute bei aktiver VPN-Verbindung folgende Einträge:
    Adresse im Internet: 176.7.54.56 ; Lokale Adresse: 0.0.0.0 ; IP Adesse: 717.186.195.174


    hier die gewünschten Abfragen:


    Da fällt mir übrigens noch was, auch als Hinweis für Andreas, ein:


    Wenn die VPN-Verbindung abbricht, dann "reagiert" auch der ppp-Deamon auf kein Kommando (sudo poff -a) mehr. Wie schon erwähnt, funktioniert dann auch der Raspi erst wieder nach dem Stecker ziehen! Und das muss ich manchmal sogar mehrfach hintereinander machen! warum das so ist, ist mir ebenfalls nicht klar.


    So, für heute ists gut, gehe jetzt schlafen.


    Gruß Meisengeier

    Hallo rpi444,


    habe den Befehl in der rc.local eingetragen, anschließend den Raspi, dann die VPN-Verbindung neu gestartet.
    hier das Ergebnis:


    Wie du siehst, brachten auch die anderen Abfragen kein Ergebnis bzw. eine Rückantwort.
    Habe ich vielleicht etwas falsch gemacht?


    So, mal schauen, ob es diesmal mit der Spoiler-Funktion klappt?


    Gruß Meisengeier

    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

    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

    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 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 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 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:


    http://www.forum-raspberrypi.d…mts-stick-vpn-zu-fritzbox


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

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

    Hallo Andreas,


    die Eingabe "dmesg | grep ppp0" bringt ebenfalls kein Ergebnis.


    Ich habe gemäß den Vorschlägen von "rpi444" und "dreamshader", wofür ich mich hiermit ebenfalls für eure Unterstüzung bedanken möchte, das Paket -dnsutils- installieren können, hier das Ergebnis:


    pi@raspberrypi ~ $ nslookup fernschalten.ddns.net
    Server: 192.168.178.1 (Anmerkung: ist meine Fritzbox)
    Address: 192.168.178.1#53 (Anmerkung: Adresse ist mir nicht bekannt)


    Non-authoritative answer:
    Name: fernschalten.ddns.net
    Address: 217.50.126.128


    pi@raspberrypi ~ $


    hier die dmesg, Stand heute:
    pi@raspberrypi ~ $ dmesg
    [ 0.000000] Booting Linux on physical CPU 0xf00
    [ 0.000000] Initializing cgroup subsys cpuset
    [ 0.000000] Initializing cgroup subsys cpu
    [ 0.000000] Initializing cgroup subsys cpuacct
    [ 0.000000] Linux version 4.1.19-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #858 SMP Tue Mar 15 15:56:00 GMT 2016
    [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
    [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
    [ 0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1
    [ 0.000000] cma: Reserved 8 MiB at 0x3a400000
    [ 0.000000] Memory policy: Data cache writealloc
    [ 0.000000] On node 0 totalpages: 241664
    [ 0.000000] free_area_init_node: node 0, pgdat 80880fc0, node_mem_map b9bb4000
    [ 0.000000] Normal zone: 2124 pages used for memmap
    [ 0.000000] Normal zone: 0 pages reserved
    [ 0.000000] Normal zone: 241664 pages, LIFO batch:31
    [ 0.000000] [bcm2709_smp_init_cpus] enter (9420->f3003010)
    [ 0.000000] [bcm2709_smp_init_cpus] ncores=4
    [ 0.000000] PERCPU: Embedded 12 pages/cpu @bafb1000 s20416 r8192 d20544 u49152
    [ 0.000000] pcpu-alloc: s20416 r8192 d20544 u49152 alloc=12*4096
    [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
    [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 239540
    [ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=592 bcm2708_fb.fbheight=448 bcm2709.boardrev=0xa01041 bcm2709.serial=0x9663aa72 smsc95xx.macaddr=B8:27:EB:63:AA:72 bcm2708_fb.fbswap=1 bcm2709.uart_clock=3000000 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait
    [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
    [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
    [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
    [ 0.000000] Memory: 939380K/966656K available (6064K kernel code, 534K rwdata, 1664K rodata, 444K init, 757K bss, 19084K reserved, 8192K cma-reserved)
    [ 0.000000] Virtual kernel memory layout:
    [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
    [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
    [ 0.000000] vmalloc : 0xbb800000 - 0xff000000 (1080 MB)
    [ 0.000000] lowmem : 0x80000000 - 0xbb000000 ( 944 MB)
    [ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB)
    [ 0.000000] .text : 0x80008000 - 0x807945f0 (7730 kB)
    [ 0.000000] .init : 0x80795000 - 0x80804000 ( 444 kB)
    [ 0.000000] .data : 0x80804000 - 0x80889b10 ( 535 kB)
    [ 0.000000] .bss : 0x8088c000 - 0x809497dc ( 758 kB)
    [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
    [ 0.000000] Hierarchical RCU implementation.
    [ 0.000000] Additional per-CPU info printed with stalls.
    [ 0.000000] NR_IRQS:608
    [ 0.000000] Architected cp15 timer(s) running at 19.20MHz (phys).
    [ 0.000000] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
    [ 0.000011] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
    [ 0.000033] Switching to timer-based delay loop, resolution 52ns
    [ 0.000313] Console: colour dummy device 80x30
    [ 0.001471] console [tty1] enabled
    [ 0.001530] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
    [ 0.001606] pid_max: default: 32768 minimum: 301
    [ 0.001990] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
    [ 0.002044] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
    [ 0.003334] Initializing cgroup subsys blkio
    [ 0.003406] Initializing cgroup subsys memory
    [ 0.003464] Initializing cgroup subsys devices
    [ 0.003517] Initializing cgroup subsys freezer
    [ 0.003581] Initializing cgroup subsys net_cls
    [ 0.003679] CPU: Testing write buffer coherency: ok
    [ 0.003788] ftrace: allocating 20313 entries in 60 pages
    [ 0.052917] CPU0: update cpu_capacity 1024
    [ 0.052992] CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
    [ 0.053033] [bcm2709_smp_prepare_cpus] enter
    [ 0.053188] Setting up static identity map for 0x8240 - 0x8274
    [ 0.055695] [bcm2709_boot_secondary] cpu:1 started (0) 18
    [ 0.056134] [bcm2709_secondary_init] enter cpu:1
    [ 0.056191] CPU1: update cpu_capacity 1024
    [ 0.056200] CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01
    [ 0.056792] [bcm2709_boot_secondary] cpu:2 started (0) 18
    [ 0.057147] [bcm2709_secondary_init] enter cpu:2
    [ 0.057182] CPU2: update cpu_capacity 1024
    [ 0.057190] CPU2: thread -1, cpu 2, socket 15, mpidr 80000f02
    [ 0.057732] [bcm2709_boot_secondary] cpu:3 started (0) 17
    [ 0.057988] [bcm2709_secondary_init] enter cpu:3
    [ 0.058017] CPU3: update cpu_capacity 1024
    [ 0.058025] CPU3: thread -1, cpu 3, socket 15, mpidr 80000f03
    [ 0.058116] Brought up 4 CPUs
    [ 0.058227] SMP: Total of 4 processors activated (153.60 BogoMIPS).
    [ 0.058260] CPU: All CPU(s) started in HYP mode.
    [ 0.058289] CPU: Virtualization extensions available.
    [ 0.059310] devtmpfs: initialized
    [ 0.082954] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
    [ 0.083297] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
    [ 0.084494] pinctrl core: initialized pinctrl subsystem
    [ 0.085308] NET: Registered protocol family 16
    [ 0.090983] DMA: preallocated 4096 KiB pool for atomic coherent allocations
    [ 0.092152] bcm2709.uart_clock = 3000000
    [ 0.097489] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
    [ 0.097551] hw-breakpoint: maximum watchpoint size is 8 bytes.
    [ 0.097775] Serial: AMBA PL011 UART driver
    [ 0.097981] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 83, base_baud = 0) is a PL011 rev2
    [ 0.597383] console [ttyAMA0] enabled
    [ 0.601640] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
    [ 0.678202] bcm2708-dmaengine 3f007000.dma: DMA legacy API manager at f3007000, dmachans=0xf35
    [ 0.686939] bcm2708-dmaengine 3f007000.dma: Initialized 7 DMA channels (+ 1 legacy)
    [ 0.695328] bcm2708-dmaengine 3f007000.dma: Load BCM2835 DMA engine driver
    [ 0.702243] bcm2708-dmaengine 3f007000.dma: dma_debug:0
    [ 0.708202] SCSI subsystem initialized
    [ 0.712214] usbcore: registered new interface driver usbfs
    [ 0.717842] usbcore: registered new interface driver hub
    [ 0.723308] usbcore: registered new device driver usb
    [ 0.729081] raspberrypi-firmware soc:firmware: Attached to firmware from 2016-03-15 14:47
    [ 0.764571] Switched to clocksource arch_sys_counter
    [ 0.818467] FS-Cache: Loaded
    [ 0.821738] CacheFiles: Loaded
    [ 0.836105] NET: Registered protocol family 2
    [ 0.841760] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
    [ 0.848998] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
    [ 0.855665] TCP: Hash tables configured (established 8192 bind 8192)
    [ 0.862169] UDP hash table entries: 512 (order: 2, 16384 bytes)
    [ 0.868189] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
    [ 0.875042] NET: Registered protocol family 1
    [ 0.879834] RPC: Registered named UNIX socket transport module.
    [ 0.885813] RPC: Registered udp transport module.
    [ 0.890533] RPC: Registered tcp transport module.
    [ 0.895269] RPC: Registered tcp NFSv4.1 backchannel transport module.
    [ 0.902917] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
    [ 0.912494] futex hash table entries: 1024 (order: 4, 65536 bytes)
    [ 0.934819] VFS: Disk quotas dquot_6.6.0
    [ 0.939152] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
    [ 0.948661] FS-Cache: Netfs 'nfs' registered for caching
    [ 0.955181] NFS: Registering the id_resolver key type
    [ 0.960308] Key type id_resolver registered
    [ 0.964506] Key type id_legacy registered
    [ 0.971355] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
    [ 0.979021] io scheduler noop registered
    [ 0.982975] io scheduler deadline registered (default)
    [ 0.988498] io scheduler cfq registered
    [ 0.994974] BCM2708FB: allocated DMA memory fa800000
    [ 0.999992] BCM2708FB: allocated DMA channel 0 @ f3007000
    [ 1.010909] Console: switching to colour frame buffer device 74x28
    [ 1.022439] Serial: 8250/16550 driver, 0 ports, IRQ sharing disabled
    [ 1.031796] vc-cma: Videocore CMA driver
    [ 1.037448] vc-cma: vc_cma_base = 0x00000000
    [ 1.043836] vc-cma: vc_cma_size = 0x00000000 (0 MiB)
    [ 1.050958] vc-cma: vc_cma_initial = 0x00000000 (0 MiB)
    [ 1.058278] vc-mem: phys_addr:0x00000000 mem_base=0x3dc00000 mem_size:0x3f000000(1008 MiB)
    [ 1.085631] brd: module loaded
    [ 1.099244] loop: module loaded
    [ 1.105027] vchiq: vchiq_init_state: slot_zero = 0xba880000, is_master = 0
    [ 1.116843] Loading iSCSI transport class v2.0-870.
    [ 1.124289] usbcore: registered new interface driver smsc95xx
    [ 1.131748] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
    [ 1.339541] Core Release: 2.80a
    [ 1.344291] Setting default values for core params
    [ 1.350711] Finished setting default values for core params
    [ 1.558327] Using Buffer DMA mode
    [ 1.563239] Periodic Transfer Interrupt Enhancement - disabled
    [ 1.570745] Multiprocessor Interrupt Enhancement - disabled
    [ 1.578001] OTG VER PARAM: 0, OTG VER FLAG: 0
    [ 1.584040] Dedicated Tx FIFOs mode
    [ 1.589546] WARN::dwc_otg_hcd_init:1047: FIQ DMA bounce buffers: virt = 0xba814000 dma = 0xfa814000 len=9024
    [ 1.602769] FIQ FSM acceleration enabled for :
    [ 1.602769] Non-periodic Split Transactions
    [ 1.602769] Periodic Split Transactions
    [ 1.602769] High-Speed Isochronous Endpoints
    [ 1.626259] dwc_otg: Microframe scheduler enabled
    [ 1.626338] WARN::hcd_init_fiq:412: FIQ on core 1 at 0x80417288
    [ 1.633966] WARN::hcd_init_fiq:413: FIQ ASM at 0x804175f8 length 36
    [ 1.641940] WARN::hcd_init_fiq:438: MPHI regs_base at 0xbb89a000
    [ 1.649696] dwc_otg 3f980000.usb: DWC OTG Controller
    [ 1.656425] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
    [ 1.667084] dwc_otg 3f980000.usb: irq 32, io mem 0x00000000
    [ 1.674400] Init: Port Power? op_state=1
    [ 1.680019] Init: Power Port (0)
    [ 1.685187] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
    [ 1.695341] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
    [ 1.706017] usb usb1: Product: DWC OTG Controller
    [ 1.712470] usb usb1: Manufacturer: Linux 4.1.19-v7+ dwc_otg_hcd
    [ 1.720258] usb usb1: SerialNumber: 3f980000.usb
    [ 1.727569] hub 1-0:1.0: USB hub found
    [ 1.733087] hub 1-0:1.0: 1 port detected
    [ 1.739212] dwc_otg: FIQ enabled
    [ 1.739226] dwc_otg: NAK holdoff enabled
    [ 1.739236] dwc_otg: FIQ split-transaction FSM enabled
    [ 1.739276] Module dwc_common_port init
    [ 1.739663] usbcore: registered new interface driver usb-storage
    [ 1.747668] mousedev: PS/2 mouse device common for all mice
    [ 1.755827] bcm2835-cpufreq: min=600000 max=900000
    [ 1.762681] sdhci: Secure Digital Host Controller Interface driver
    [ 1.770669] sdhci: Copyright(c) Pierre Ossman
    [ 1.777174] sdhost: log_buf @ ba813000 (fa813000)
    [ 1.854617] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
    [ 1.862292] sdhci-pltfm: SDHCI platform and OF driver helper
    [ 1.890559] ledtrig-cpu: registered to indicate activity on CPUs
    [ 1.898706] hidraw: raw HID events driver (C) Jiri Kosina
    [ 1.906212] usbcore: registered new interface driver usbhid
    [ 1.913548] usbhid: USB HID core driver
    [ 1.919678] Initializing XFRM netlink socket
    [ 1.922328] mmc0: host does not support reading read-only switch, assuming write-enable
    [ 1.924358] mmc0: new high speed SDHC card at address 0001
    [ 1.925020] mmcblk0: mmc0:0001 ASTC 7.44 GiB
    [ 1.930238] mmcblk0: p1 p2 < p5 p6 > p3
    [ 1.944737] Indeed it is in host mode hprt0 = 00021501
    [ 1.963089] NET: Registered protocol family 17
    [ 1.969416] Key type dns_resolver registered
    [ 1.975804] Registering SWP/SWPB emulation handler
    [ 1.983264] registered taskstats version 1
    [ 1.989451] vc-sm: Videocore shared memory driver
    [ 1.995917] [vc_sm_connected_init]: start
    [ 2.002288] [vc_sm_connected_init]: end - returning 0
    [ 2.026692] EXT4-fs (mmcblk0p6): mounted filesystem with ordered data mode. Opts: (null)
    [ 2.038233] VFS: Mounted root (ext4 filesystem) readonly on device 179:6.
    [ 2.058164] devtmpfs: mounted
    [ 2.063619] Freeing unused kernel memory: 444K (80795000 - 80804000)
    [ 2.124663] usb 1-1: new high-speed USB device number 2 using dwc_otg
    [ 2.133131] Indeed it is in host mode hprt0 = 00001101
    [ 2.335059] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
    [ 2.345472] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    [ 2.357245] hub 1-1:1.0: USB hub found
    [ 2.362974] hub 1-1:1.0: 5 ports detected
    [ 2.644676] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
    [ 2.765138] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
    [ 2.776290] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    [ 2.791290] smsc95xx v1.0.4
    [ 2.858838] 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
    [ 2.954817] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
    [ 3.076004] usb 1-1.3: New USB device found, idVendor=1908, idProduct=1320
    [ 3.088369] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 3.099923] usb 1-1.3: Product: Mass storage
    [ 3.106739] usb 1-1.3: Manufacturer: Generic
    [ 3.113438] usb 1-1.3: SerialNumber: 1638276825
    [ 3.121407] usb-storage 1-1.3:1.0: USB Mass Storage device detected
    [ 3.130893] scsi host0: usb-storage 1-1.3:1.0
    [ 3.214741] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
    [ 3.327388] udevd[176]: starting version 175
    [ 3.340482] usb 1-1.4: New USB device found, idVendor=2101, idProduct=8500
    [ 3.352046] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    [ 3.364112] usb 1-1.4: Product: USB2.0 Hub
    [ 3.370537] usb 1-1.4: Manufacturer: Action Star
    [ 3.378974] hub 1-1.4:1.0: USB hub found
    [ 3.385668] hub 1-1.4:1.0: 5 ports detected
    [ 3.474678] usb 1-1.5: new high-speed USB device number 6 using dwc_otg
    [ 3.674701] usb 1-1.4.1: new high-speed USB device number 7 using dwc_otg
    [ 3.726296] usb 1-1.5: New USB device found, idVendor=046d, idProduct=08c9
    [ 3.738319] usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=2
    [ 3.749930] usb 1-1.5: SerialNumber: 025077A9
    [ 3.799194] usb 1-1.4.1: New USB device found, idVendor=2101, idProduct=8501
    [ 3.811595] usb 1-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    [ 3.824226] usb 1-1.4.1: Product: USB HID
    [ 3.830992] usb 1-1.4.1: Manufacturer: Action Star
    [ 3.851039] hid-generic 0003:2101:8501.0001: hiddev0,hidraw0: USB HID v1.11 Device [Action Star USB HID] on usb-3f980000.usb-1.4.1/input0
    [ 4.211256] scsi 0:0:0:0: Direct-Access Generic Flash-Disk 1.08 PQ: 0 ANSI: 2
    [ 4.228388] sd 0:0:0:0: [sda] 15669248 512-byte logical blocks: (8.02 GB/7.47 GiB)
    [ 4.247225] sd 0:0:0:0: [sda] Write Protect is off
    [ 4.255239] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
    [ 4.257775] sd 0:0:0:0: [sda] No Caching mode page found
    [ 4.266282] sd 0:0:0:0: [sda] Assuming drive cache: write through
    [ 4.371716] sda: sda1
    [ 4.386768] sd 0:0:0:0: [sda] Attached SCSI removable disk
    [ 4.446754] media: Linux media interface: v0.10
    [ 4.489297] sd 0:0:0:0: Attached scsi generic sg0 type 0
    [ 4.510708] Linux video capture interface: v2.00
    [ 4.607426] uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c9)
    [ 4.686296] input: UVC Camera (046d:08c9) as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/input/input0
    [ 4.714173] usbcore: registered new interface driver uvcvideo
    [ 4.723611] USB Video Class driver (1.1.1)
    [ 4.933709] bcm2835-rng 3f104000.rng: hwrng registered
    [ 4.941834] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
    [ 5.026560] usb 1-1.5: Warning! Unlikely big volume range (=3072), cval->res is probably wrong.
    [ 5.039882] usb 1-1.5: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1
    [ 5.052334] usbcore: registered new interface driver snd-usb-audio
    [ 6.707591] EXT4-fs (mmcblk0p6): re-mounted. Opts: (null)
    [ 6.939976] random: nonblocking pool is initialized
    [ 7.263264] EXT4-fs (mmcblk0p6): re-mounted. Opts: (null)
    [ 10.683911] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
    [ 12.057921] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    [ 13.044752] usb 1-1.4.5: new high-speed USB device number 8 using dwc_otg
    [ 13.147132] usb 1-1.4.5: New USB device found, idVendor=19d2, idProduct=2000
    [ 13.147162] usb 1-1.4.5: New USB device strings: Mfr=3, Product=2, SerialNumber=4
    [ 13.147178] usb 1-1.4.5: Product: ZTE CDMA Technologies MSM
    [ 13.147194] usb 1-1.4.5: Manufacturer: ZTE,Incorporated
    [ 13.147209] usb 1-1.4.5: SerialNumber: 1234567890ABCDEF
    [ 13.150290] usb-storage 1-1.4.5:1.0: USB Mass Storage device detected
    [ 13.151705] scsi host1: usb-storage 1-1.4.5:1.0
    [ 15.115485] usb 1-1.4.5: USB disconnect, device number 8
    [ 16.361278] cfg80211: Calling CRDA to update world regulatory domain
    [ 18.107962] Adding 102396k swap on /var/swap. Priority:-1 extents:1 across:102396k SSFS
    [ 19.514535] cfg80211: Calling CRDA to update world regulatory domain
    [ 19.579070] uart-pl011 3f201000.uart: no DMA platform data
    [ 20.214527] usb 1-1.4.5: new high-speed USB device number 9 using dwc_otg
    [ 20.317121] usb 1-1.4.5: New USB device found, idVendor=19d2, idProduct=0031
    [ 20.317145] usb 1-1.4.5: New USB device strings: Mfr=3, Product=2, SerialNumber=4
    [ 20.317157] usb 1-1.4.5: Product: ZTE CDMA Technologies MSM
    [ 20.317167] usb 1-1.4.5: Manufacturer: ZTE,Incorporated
    [ 20.317177] usb 1-1.4.5: SerialNumber: P671A2WATD010000
    [ 20.320840] usb-storage 1-1.4.5:1.2: USB Mass Storage device detected
    [ 20.321269] scsi host2: usb-storage 1-1.4.5:1.2
    [ 20.353885] usbcore: registered new interface driver usbserial
    [ 20.354003] usbcore: registered new interface driver usbserial_generic
    [ 20.354124] usbserial: USB Serial support registered for generic
    [ 20.372478] usbcore: registered new interface driver option
    [ 20.372633] usbserial: USB Serial support registered for GSM modem (1-port)
    [ 20.373764] option 1-1.4.5:1.0: GSM modem (1-port) converter detected
    [ 20.375250] usb 1-1.4.5: GSM modem (1-port) converter now attached to ttyUSB0
    [ 20.375551] option 1-1.4.5:1.1: GSM modem (1-port) converter detected
    [ 20.377347] usb 1-1.4.5: GSM modem (1-port) converter now attached to ttyUSB1
    [ 20.377795] option 1-1.4.5:1.3: GSM modem (1-port) converter detected
    [ 20.378789] usb 1-1.4.5: GSM modem (1-port) converter now attached to ttyUSB2
    [ 21.316219] scsi 2:0:0:0: Direct-Access ZTE MMC Storage 2.31 PQ: 0 ANSI: 2
    [ 21.317665] sd 2:0:0:0: Attached scsi generic sg1 type 0
    [ 21.325336] sd 2:0:0:0: [sdb] Attached SCSI removable disk
    [ 22.674922] cfg80211: Calling CRDA to update world regulatory domain
    [ 25.833878] cfg80211: Calling CRDA to update world regulatory domain
    [ 28.993457] cfg80211: Calling CRDA to update world regulatory domain
    [ 29.550762] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null)
    [ 32.153050] cfg80211: Calling CRDA to update world regulatory domain
    [ 35.312746] cfg80211: Calling CRDA to update world regulatory domain
    [ 38.472470] cfg80211: Calling CRDA to update world regulatory domain
    [ 41.631942] cfg80211: Calling CRDA to update world regulatory domain
    [ 44.791576] cfg80211: Calling CRDA to update world regulatory domain
    [ 47.951212] cfg80211: Calling CRDA to update world regulatory domain
    [ 51.110827] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
    [ 138.640674] PPP generic driver version 2.4.2
    [ 456.904502] tun: Universal TUN/TAP device driver, 1.6
    [ 456.904525] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
    pi@raspberrypi ~ $


    Ich hoffe, du kannst damit etwas anfangen.


    Heute übrigens wieder das selbe Spiel bzw. Problem: Habe die VPN-Verbindung per SMS meine Datei vpnstart.sh mit Inhalt "sudo pon" und "sudo vpnc fritzbox.conf" gestartet; Resultat die Internetverbindung wird aufgebaut, der VPN-Tunnel nicht. Eine nochmalige SMS mit dem Inhalt: "sudo vpnc fritzbox.conf" hat dann den Tunnel gestartet! Alles funktioniert wieder wie es soll. Wie ich schon schrieb, wird die VPN-Verbindung nach 30 Minuten automatisch (per Script) beendet. Habe danach die VPN-Verbindung erneut gestartet, funktioniert sofort, ohne eine 2. SMS hinterherzuschicken. Soweit ich weiß, gehen ja beim Verbindungsaufbau auch Datenpakete hin und her. Vielleicht wurde die Internetverbindung mittels sudo pon noch nicht vollständig hergestellt und der 2. befehl: sudo vpnc fritzbox kann (noch) nicht ausgeführt werden, was dann zu diesem Effekt führt? Vielleicht müsste man mein Start-Script verbessern?


    Gruß Meisengeier

    Hallo Andreas,


    bei dem Versuch "sudo apt-get install bind-utils" zu laden sagt mir mein Raspi: "E Paket nicht gefunden"
    hostname -I = 10.204.7.102 192.168.178.201 (mein UMTS-Stick Raspi, die 201 hat die Fritzbox vergeben)
    uname -a : Linux raspberrypi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux
    ifconfig (VPN-Tunnel ist momentan aktiv):
    pi@raspberrypi ~ $ ifconfig
    eth0 Link encap:Ethernet Hardware Adresse b8:27:eb:63:aa:72
    UP BROADCAST MULTICAST MTU:1500 Metrik:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)


    lo Link encap:Lokale Schleife
    inet Adresse:127.0.0.1 Maske:255.0.0.0
    UP LOOPBACK RUNNING MTU:65536 Metrik:1
    RX packets:104 errors:0 dropped:0 overruns:0 frame:0
    TX packets:104 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:0
    RX bytes:8880 (8.6 KiB) TX bytes:8880 (8.6 KiB)


    ppp0 Link encap:Punkt-zu-Punkt-Verbindung
    inet Adresse:10.204.7.102 P-z-P:10.64.64.64 Maske:255.255.255.255
    UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metrik:1
    RX packets:230 errors:1 dropped:0 overruns:0 frame:0
    TX packets:308 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:3
    RX bytes:26612 (25.9 KiB) TX bytes:37969 (37.0 KiB)


    tun0 Link encap:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
    inet Adresse:192.168.178.201 P-z-P:192.168.178.201 Maske:255.255.255.255
    UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1412 Metrik:1
    RX packets:124 errors:0 dropped:0 overruns:0 frame:0
    TX packets:182 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:500
    RX bytes:10517 (10.2 KiB) TX bytes:17790 (17.3 KiB)


    dmesg | grep eth1 : kein Ergebnis (sicher weil kein eth1 existiert?) Werde die dmesg datei senden, bitte vorab um Bestätigung.


    Hatte ich vergessen: Ich habe ein echtes Raspi-Netzteil für Raspi 2 (5V, 2A) und Raspi 3 (5,1 Volt, 2,5A), Dlink Aktivhub für UMTS-Stick


    Hallo rpi444,


    vielen Dank für deinen Tip.
    Wenn ich "~ $ apt-cache show dnsutils | tail -n 11" eingebe, kommt auch der Text wie von dir. Leider kann ich nicht wirklich englisch und weiß auch nicht, ob dazu auch erst mal etwas zu installieren ist. Falls ja, so: sudo apt-get install dnsutils ? Und da ich dieses Programm ebenfalls nicht kenne, wäre ich dir für Hinweise zur Anwendung sehr dankbar.


    Gruß Meisengeier