Bei mir ja auch ...OK, ich verstehe...
Diese ganze Tunnelei brauche ich nicht wirklich. Habe ja IPv4 Adressen. Das ganze ist eher Spielerei als Notwendigkeit.
Bitteschön.Vielen Dank aber für deine ausführliche Erklärung.
Mir ist keine Cam bekannt, die überhaupt noch weiterentwickelt wird, außer oscam (und das davon abgeleitete, blöd benannte, doscam).Gibt es evtl. CCCam-Alternativen die das können? MGCam, Scam und wie die alle heißen...
Oscam zu oscam funktioniert wenn ich dich richtig verstanden habe, gelle? (Wenn IPv6 einkompiliert)
6tunnel -4 -6 12200 127.0.0.1 12100
6tunnel -4 -6 12200 192.168.178.10 12100
Prima! :good:ich habe das CrossCompiling nun hinbekommen und einen Oscam mit IPv6 auf meinem ET9200 laufen.
Und ich freue mich, daß sich auch mal jemand damit beschäftigt hat, der es gar nicht muß, sondern wie ich einfach neugierig ist :good:Im Oscam-Server auf dem PI ist der Benutzer eingeloggt und unter IP steht jetzt ne hübsche v6. Ich freu mich. :dfingers:
cccam kann kein IPv6, wie auch vieles andere nicht.
Auf direktem Weg nutzt Dir das CS über IPv6 nur zwischen oscams etwas, die können - wenn mit IPv6-Support gebaut - IPv6.
Um andere Clients als oscam per IPv6 zu einem oscam-Server verbinden zu lassen kann man nur mit 6tunnel, haproxy etc. tricksen.
Zur Show nutze ich z.B. auch das DVBViewer-Plugin "Hadu" über IPv6 ...
Auf meiner Fritz!Box läuft oscam mit IPv6-Support, aber Hadu kann selber kein IPv6, also lasse ich beim Systemstart von Windows folgenden Befehl ausführen:
Diese Zeile weist Windows' eingebauten Portproxy an, alle per IPv4 auf Port 12010 eingehenden Anfragen per IPv6 an den host "fritz.box", dort auf Port 12005, weiterzuleiten.
Der entsprechende Abschnitt der Hadu.ini lautet nun dementsprechend nicht mehr
sondern
Unter Linux kann man das selbe mit 6tunnel erreichen:
Sobald man
6tunnel 12200 ipv6-server.dyn.ip 12100
ausgeführt hat, kann man in CCcam.cfg den entsprechenden, wegen IPv6 nicht funktionierenden Server-Eintrag
durch diesen ersetzen
Der CCCam-Client kriegt somit einen IPv4-Server auf localhost/127.0.0.1 Port 12200 vorgegaukelt, wobei es sich eben nur um unseren IPv4-zu-IPv6-Portproxy handelt, der die IPv6-Kommunikation mit dem eigentlichen Server (Also oscam) auf ipv6-server.dyn.ip Port 12100 übernimmt.
Hinweis:
Die Ports müssen sich nicht unterscheiden, ich habe das nur gemacht, damit man besser sieht, welcher wofür ist bzw. wo landet. Wichtig ist nur, daß auf dem lokalen Port für den Portproxy (Dem jeweils zuerst angegebenen) noch nichts lauscht.
netsh interface portproxy add v4tov6 listenport=12345 connectaddress=meinserver.dyndns.org connectport=12345
Nur leider seh ich im Webinterface von Oscam, dass sich der client weiterhin per ipv4 verbindet.
cccamn:meinserver.dyndns.org:12345:1/0000/0000:Benutzer:Kennwort:1:5
cccamn:127.0.0.1:12345:1/0000/0000:Benutzer:Kennwort:1:5
19:28:48.865: cCardClientCCcamN::Login19:28:48.866: connecting to 127.0.0.1:12345/tcp (127.0.0.1)
19:28:58.866: get no welcome request
19:28:58.866: cCardClientCCcamN::Login
19:28:58.867: connecting to 127.0.0.1:12345/tcp (127.0.0.1)
19:29:08.867: get no welcome request
19:29:08.867: cCardClientCCcamN::Login
19:29:08.868: connecting to 127.0.0.1:12345/tcp (127.0.0.1)
nslookup meinserver.dyndns.org
@echo off
netsh interface portproxy reset
netsh interface portproxy add v4tov6 listenport=10005 himbeere.fritz.box 10005
Funktioniert jetzt. Irgendwie hab ich das problem, dass der dns immer falsch auflöst und die ipv6-adresse des routers anstatt des oscam-servers nimmt. ist es empfehlenswert, für ipv4 und ipv6 den gleichen dns-namen zu verwenden, wird dann ipv6 bevorzugt?
Die eigentlichen ECM-Zeiten ändern sich ja nicht.wie sind bei dir bei dieser ipv4/ipv6 portproxy-Geschichte die ECM-Zeiten? Im Vgl. zu nur ipv4?
Ping wird ausgeführt für 127.0.0.1 mit 32 Bytes Daten:
Antwort von 127.0.0.1: Bytes=32 [B]Zeit<1ms[/B] TTL=128
Antwort von 127.0.0.1: Bytes=32 [B]Zeit<1ms[/B] TTL=128
Antwort von 127.0.0.1: Bytes=32 [B]Zeit<1ms[/B] TTL=128
Antwort von 127.0.0.1: Bytes=32 [B]Zeit<1ms[/B] TTL=128
Ping-Statistik für 127.0.0.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = [B]0ms[/B], Maximum = [B]0ms[/B], Mittelwert = [B]0ms[/B]
Wir verwenden Cookies und ähnliche Technologien für folgende Zwecke:
Akzeptieren Sie Cookies und diese Technologien?
Wir verwenden Cookies und ähnliche Technologien für folgende Zwecke:
Akzeptieren Sie Cookies und diese Technologien?