Quantcast
Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Hilfe Verbindungsprobleme mit dyndns

m2k

Newbie
Registriert
12. Februar 2008
Beiträge
20
Reaktionspunkte
16
Punkte
23
Moin

Folgendes
Ich habe meine Gigblue 800se mal wieder angeschmissen
Jetzt habe ich folgendes Problem .

Wenn ich auf meinen Server connecte über die Server Ip ist alles in Ordnung und funktioniert,möchte ich aber jetzt über eine dyndns connecten ,schreibt er mir Usr/Pw falsch
Das gleiche auch wenn ich über die Ip vom Anbieter ,in meinem Fall Vodafon draufmöchte

Ich habe 2 dyndns ausprobiert beide gleich ,sobald ich wieder die Home Ip angebe connectet er sofort.
Das komische ist ,das andere von ausen auf den Server kommen .
Ich habe Username und pw mal geändert ,das gleiche . Hat hier irgendeiner eine Idee?

Auf dem Server ist die Version

  • OSCam: 1.20_svn Build: r11517 Compiler: i686-linux-gnu

Auf dem Client ist die Version
  • OSCam: 1.20_svn_cw_64_hardcoded Build: r11518 Compiler: mipsel-dreambox_fpu-linux-gnu-ssl-libusb
Nachtrag

Es liegt nicht an der Box ,auf meiner anderen Box ,ist das gleiche Problem ...
 
Zuletzt bearbeitet:
Nun, das ist eines der unzähligen Probleme von IPv4:
Du kriegst von Deinem Anbieter für ein ganzes Netzwerk mit zig Geräten (PC, Smartphones, Receiver, ....) nur eine einzige IPv4-Adresse, obwohl eigentlich jedes Gerät eine eigene IP-Adresse braucht.

Dieses Problem umgeht man durch die Krücke "NAT" (Network Address Translation):
Alle Geräte im Heimnetz erhalten IPv4-Adressen aus einem relativ kleinen Adressbereich, der auch von der ganzen restlichen Welt für diesen Zweck benutzt wird, sogenannte "private IP-Adressen".
"Privat", weil sie nicht durch das Internet geroutet werden können, denn von 10 Nachbarn haben 8 genau denselben Adressbereich in Gebrauch, die anderen 2 einen ähnlichen, je nachdem wie viel Mühe sich jemand beim Einrichten seines Heimnetzes gibt.

Sobald Pakete das Heimnetz verlassen, werden sie auf die eine einzige "richtige" IPv4 umgemappt die Du hast und reingehende Pakete werden an derselben Stelle auf Deine privaten IP-Adressen umgemappt, je nachdem, welches Gerät das Paket angefordert hat (Wenn es ein Antwort-Paket ist) oder welches Gerät es verarbeiten soll (Wenn es ein Zugriff von außen auf einen Server in Deinem Netzwerk ist).

Genau das erledigt Dein Router:
Über Portweiterleitungen hast Du ihm z.B. gesagt "Wenn auf Deiner WAN-Seite (Internet) ein Paket mit Zielport 12000 aufschlägt, dann leite es LAN-seitig an die private IPv4 192.168.0.25 Port 12000 weiter."
Schickt 192.168.0.25 nun ein Paket in die Welt (WAN) hinaus, dann merkt sich der Router das und wenn die Antwort an seiner WAN-Seite wieder ankommt, adressiert er sie wiederum an 192.168.0.25 um.

Geräte innerhalb des Heimnetzes kommunizieren aber eigentlich gar nicht über den Router und auch nicht über Deine öffentliche IPv4-Adresse miteinander, sondern vielmehr direkt (über einen Switch und wenn es nur die Switch-Komponente im Router ist).

Wenn Du nun innerhalb des Heimnetzes als Server-Adresse nicht die private IPv4 aus Deinem Heimnetz verwendest, sondern Deine eine öffentliche (denn die ist es, die hinter dem DynDNS steckt), dann zwingst Du das Paket durch den Router, obwohl es nur geswitched werden müßte.

Für den Router bedeutet das:
Der Router muß erkennen, daß an seiner LAN-Seite ein Paket mit einer Zieladresse des anderen Netzes (WAN/Internet) angekommen ist und diese Ziel-Adresse eigentlich seine eigene in diesem anderen Netzwerk ist. Dann kann er es seinen Portweiterleitungsregeln unterwerfen und statt ins WAN (Wohin es adressiert war) doch wieder - umadressiert - ins LAN zurückschicken.

Prinzipiell ist das wenig clever, weil es nur unnötige Zusatzarbeit für den Router ist. Aus diesem Grunde können viele Router dieses sogenannte "Reverse-NAT" erst gar nicht.
 
poste mal die Configs vom Server und einem Client Reci,
verwendest du Hostname etc vielleicht?
bevor man anfängt rumzuraten, zeig mal alles bitte
 
SERVER:
Oscam.conf
  • clienttimeout = 6000
    fallbacktimeout = 2000
    bindwait = 10
    nice = -1
    maxlogsize = 48
    dropdups = 1
    block_same_ip = 0
    block_same_name = 0
    lb_mode = 1
    disablecrccws_only_for = 098C:000000;09C4:000000
    [cccam]
    port = 34002
    nodeid = 1D30036810FC13F8
    version = 2.3.2
    reshare = 1
    reshare_mode = 1
    ignorereshare = 1
    stealth = 1

Oscam User
[account]
user = Markus-********
pwd = ***********
keepalive = 1
betatunnel = 1833.FFFF:1702
group = 10
cccreshare = 1
CLIENT
Oscam Config
[dvbapi]
enabled = 1
au = 1
pmt_mode = 0
user = dvbapiau
read_sdt = 2
write_sdt_prov = 1
boxtype = dreambox

[webif]
httpport = 8082
httpuser = BluePeer
httppwd = ***********
httpcss = /usr/local/etc/carbon.v3.css
httptpl = usr/local/etc/picons2
httppiconpath = usr/local/etc/picons
httphelplang = de
http_prepend_embedded_css = 1
httprefresh = 10
httpshowpicons = 1
httppiconsize = 50
httpshowuserinfo = 1
httpallowed = 0.0.0.0-192.192.254.254
httpdyndns =*******.hopto.org
hideclient_to = 15
httposcamlabel = HomeCS

[cccam]
port = 34005
nodeid = 1D30036810FC13F8
version = 2.3.0
reshare = 1
reshare_mode = 1
ignorereshare = 1
stealth = 1

Oscam Server
[reader]
label = home
description = home
protocol = cccam
device = 192.168.2.229,34002
user = *********
password = *********
inactivitytimeout = 30
group = 21
emmcache = 1,1,2,0
cccversion = 2.3.2
ccckeepalive = 1
cccreshare = 1
audisabled = 1

Log
(ecm) dvbapiau (09C4@000000/01A8/0197/A7:2C09FB4922E752C7FCF1646EEE162A5F): found (637 ms) by home - Sky Cinema Family

Oscam Server
[reader]
label = home
description = home
protocol = cccam
device = ********hopto.org,34002
user = *********
password = *********
inactivitytimeout = 30
group = 21
emmcache = 1,1,2,0
cccversion = 2.3.2
ccckeepalive = 1
cccreshare = 1
audisabled = 1

Log
  • 2019/12/14 19:07:17 3FEE1969 p (reader) home [cccam] connecting to ********.hopto.org:34002
  • 2019/12/14 19:07:17 3FEE1969 p (cccam) cccam(r) home: login failed, usr/pwd invalid
 
Zuletzt bearbeitet:
du hast doch am server in der oscam.conf Port 34002 für cccam eingestellt, dann muss im client in der oscam.server auch dieser Port rein (= 34002) und nicht 34005.
Du willst dein client wohl nicht mit sich selbst verbinden.

Port ist von außen erreichbar?
 
Sorry hab es geändert
War schon der port 34002 hab mich verklickt ;)

Aber es geht ja mit der Home IP wie man ja in der Log sieht
Eigentlich müsste ich nur wissen , ob es von außen geht,weil der Receiver zum Bekannten kommt und er weiter weg wohnt ,bin mir unsicher.
Von aussen ist der port erreichbar ,sind ja auch andere connectet :)
 
lösche doch mal beim Client den CCcam Abschnitt und starte mal neu....
 
Aber es geht ja mit der Home IP wie man ja in der Log sieht
Eigentlich müsste ich nur wissen , ob es von außen geht,weil der Receiver zum Bekannten kommt und er weiter weg wohnt ,bin mir unsicher.
Von aussen ist der port erreichbar ,sind ja auch andere connectet :smile:

Wenn
- andere User - denen Du denselben DynDNS eingetragen hast - per IPv4 verbunden sind
und
- es bei lokalen Tests mit der privaten IPv4 funktioniert
und
- Du rechtzeitig vor der Weitergabe des guten Stücks die private IPv4 durch den den im ersten Punkt genannten DynDNS ersetzt,
dann kann er sich auch verbinden.

Soviel Vertrauen muß man einfach haben.

Wie gesagt, Deinen eigenen DynDNS kannst Du aus dem eigenen Netzwerk genauso wenig testen wie ein VPN aus dem eigenen Netzwerk zum eigenen Netzwerk:
Selbst wenn Dein Router Reverse-NAT beherrschen würde, durchliefen die Pakete den Router immer noch anders, als wenn die Pakete wirklich aus dem WAN kämen.
 
lösche doch mal beim Client den CCcam Abschnitt und starte mal neu....
Geht auch nicht ;)

@
Schimmelreiter

Danke fuer deine ausführliche Beschreibung :)

Also wenn es ja von außen geht,soll es mir ja Recht sein , jetzt bleibt noch die Frage ,warum connectet er ,und sagt dann User/ PW falsch :=)

Naja wenn es ja halt nicht geht so ,dann ist das so :=)

Vielen Dank an euch da oben
 
Wie gesagt, Deinen eigenen DynDNS kannst Du aus dem eigenen Netzwerk genauso wenig testen
ein nslookup sollte schon möglich sein und die aktuelle öffentliche IP bringen (und es gibt auch Router die die eigene Dyndns unterstützen - geht hier Problemlos :smirk: )
wenn dem nicht so ist, dann sollte kein connect stehen und wo nichts ist kann auch kein User/Passwort falsch sein
 
Zuletzt bearbeitet:
Das komische ist ,das andere von ausen auf den Server kommen .

Konfiguriere den GigaBlue 800 SE wie alle anderen Receiver und gut ist es. Wo ist das Problem? Wenn es nicht funktioniert, liegt es am Internet-Anschluss und der Konfiguration vom Router beim „Bekannten“, wo der GigaBlue benutzt werden soll.
 
(und es gibt auch Router die die eigene Dyndns unterstützen - geht hier Problemlos :smirk: )
Ja, gibt es.
Trotzdem durchlaufen diese Pakete den Router dann immer noch anders (LAN->LAN), als wenn sie wie später wirklich von außen kommen (WAN->LAN).

Das extremste Beispiel für "lokaler Test funktioniert und extern geht gar nichts" wäre CGN (Carrier-Grade-NAT):
Die Fratz!Büchsen haben oder hatten zumindest kein Problem damit, DynDNS-Hosts mit IPv4-Adressen aus dem CGN-Bereich 100.64.0.0/10 (Wie man ihn z.B. bei Glasfaser Deutschland hat) zu aktualisieren.
Diese Situation kann einen als Anfänger schon richtig verwirren:
Mit einem Router, der Reverse-NAT kann, funktioniert der Test dann aus dem Heimnetz problemlos, auch von Anschlüssen bei Bekannten, Freunden und Familie geht es wunderbar, wenn diese auch bei Glasfaser Deutschland sind, aber von außerhalb (Anderer Anbieter) geht es nicht.

wenn dem nicht so ist, dann sollte kein connect stehen und wo nichts ist kann auch kein User/Passwort falsch sein
Wer weiß, wo der Router diese Anfragen hin leitet.
Hinter der Vodafone-Station steckt meines Wissens auch wieder ein TechniColor-Gerät und diese Geräte sind eigentlich bekannt dafür, sehr wenig von dem zu können, was "wir" von einer Fratz!Büchse gewohnt sind.
Bei den bisherigen Geräten war ja selbst ein DNS-Proxy und lokale Namensauflösung schon Utopie.
 
Zurück
Oben