CMR 2040 und No IP

Guten Mrogen I1I2I3,

das wichtigste hast du leider nicht hochgeladen. Den Diagnosepuffer.

Da drin steht entweder, ob das DynDNS Update erfolgreich war oder nicht.

Wenn ja - was für einen Provider nutzt du? Den APN internet.wind kenne ich überhaupt nicht. Erhälst du dort sicher eine öffentliche IP Adresse? Das ist Pflichtvorraussetzung beim OpenVPN Zugriff auf das CMR

Gruß

Mit Update meinte ich den Mechanismus, den das CMR bei aktivierter DynDNS Option hat.

Das CMR meldet dann die aktuelle IP Adresse der Mobilfunkverbindung an den DynDNS Dienst. Im Diagnosepuffer wird dann der Eintrag erzeugt: Update of IP x.x.x.x succesfull oder failed, falls es nicht klappt.

Die OpenVPN Einstellungen sind korrekt von dir.

Diese Infos stehen im

Diagnosepuffer:

ERROR   DynDNS-Update fehlgeschlagen, Interne Rückantwort Fehlerkennung: 3

INFO   OpenVPN: VPN konfiguriert, es wird auf Partner gewartet

INFO  Mobieler Dienst bereit

Scurity- Übersicht- Open VPN Verbindung:

Verbindung zu OpenVPN-Partner besteht (nein)

IP-Adresse des OpenVPN Peer (0.0.0.0)

Lokaler Endpunkt (10.8.0.2)

Ferner Endpunkt (10.8.0.1)

WAN- Übersicht:

...

...

IP-Adresse (10.64.152.xxx)

DNS-Server (151.5.xxx.xx)

Hey,habe gerade mal mit einem CMR mit V2.1.7 bei mir rumgespielt

Wie du siehst, funktioniert dein DynDNS Update nicht --> Die IP Adresse ist nicht beim Namen deines VPN Servers hinterlegt.Die DynDNS Fehlermeldung mit Reason 3 bekomme ich, wenn entweder mein Passwort oder der Benutzername in der DynDNS Konfiguration des CMR fehlerhaft ist. Ist alles korrekt, funktioniert es. Benutzt du das Passwort oder den Update Key deines DynDNS accounts? Würde es nochmal eintragen und/oder, falls noch nicht geschehen, mal auf die V2.1.7 updaten

Du kannst testweise, um zu schauen ob es prinzipiell funktioniert die OpenVPN Konfiguration, welche du hernutergeladen hast so anpassen, dass du die IP Adresse direkt angibst.Also statt "remote deindyndnsname 1190" --> "remote 10.xxx.xxx.xxx 1190". Sollte die Verbindung dann nicht funktionieren, vermute ich, dass du keine öffentliche IP erhälst über deinen Provider. IP Adressen aus dem Netz 10.xxx.xxx.xxx sind eig. nie öffentlich.

Bei der Telekom, welche ich immer benutze, zum Beispiel:

APN: internet.telekom.de --> IP Adressse 10.xxx.xxx.xxx --> nicht öffentlich --> Kann nicht als OVPN Server verwendet werden

APN: internet.t-d1.de --> IP Adressse 37.80.xxx.xxx --> öffentlich --> Kann als OVPN Server verwendet werden

Du kannst das auch prüfen, indem du unter Security --> HTTPS die Option "HTTPS auch auf der Mobilfunk-Schnittstelle aktivieren" aktivierst und deine Mobilfunkadresse in Firefox (wichtig, kein anderer Browser!) als https://10.xxx.xxx.xxx eingibst. Ist sie öffentlich, wird sich das WBM laden, wenn nicht dann nicht (das funktioniert ohne Firewall probleme, welche beim OVPN auch noch dazu kommen können)

Gruß

Vielen Dank für deine professionelle Hilfe. Ich werde das testen und hier dann die Ergebnisse berichten. 

Grüße 

jetzt bekomme ich

ERROR DynDNS-Update fehlgeschlagen. Interne Fehlerkennung: 6

Ich benutze das Passwort meines DynDNS accounts und habe das Passwort vom DynDNS neu eingegeben.

Ich habe im Handbuch nirgends eine Liste mit den Fehlerkennungen gefunden.

Guten Morgen,

immerhin eine Veränderung...

Es handelt sich bei dieser Nummer um die Fehlernummer der Open Source Komponente "libcurl"

Aktuelles Handbuch, Seite 146, Kapitel 6.3 Fehlerkennungen zu E-Mails

"Der Diagnosepuffereintrag kann folgende Angaben enthalten:
● Interne Fehlerkennung; die entsprechenden Fehlercodes werden auf der folgenden Seite erklärt: Link: (https://curl.haxx.se/libcurl/c/libcurl-errors.html)"

Da ist die Überschrift im Handbuch falsch, müsste E-Mail und DynDNS sein...tztz

Fehlercode 6 kann ich mir aktuell leider nicht erklären bzw in meinem CMR reproduzieren. Mit falschem Anbieter/Host/Benutzer/Passwort bekomme ich nur 3, 5 oder 15.

CURLE_COULDNT_RESOLVE_HOST (6) deutet für mich eher auf eine Störung der Datenverbindung bzw ein falscher DynDNS-Link innerhalb des CMRs. Du benutzt die aktuelle V2.1.7?

Läuft über die Datenverbindung deines CMR noch irgendetwas - NTP oder EMail - was funktioniert, um das auszuschließen? Wenn nicht einfach mal NTP Zeitsync bei System-->Systemzeit aktivieren (NTP Server zb 0.pool.ntp.org) Wenn es klappt wird in dem Feld "Letzte Uhrzeitsynchronisation vor (dd:hh:mm:ss)" ein Timer loslaufen. Dann wissen wir, dass die Datenverbindungskommunikation korrekt funktioniert und die Baugruppe dann eine korrekte Uhrzeit hat (kann bei so etwas hinderlich sein, falls es bisher nicht so war).

Zur Not kannst/solltest du dich an den Support wenden, im Online Support bei Instandhaltung gibt es einen mechanismus um dem Support Baugruppeninformationen zur Verfügung zu stellen. Die kannst du aktivieren, bisschen testen, neustarten und dann schicken. Vielleicht finden die dann den konkreten Grund direkt.

Handbuch Kapitel 5.9.4 Online Support

Grüße