Laberthread zu Anleitung IPv6 und Cardsharing

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

OK, ich verstehe...
Diese ganze Tunnelei brauche ich nicht wirklich. Habe ja IPv4 Adressen. Das ganze ist eher Spielerei als Notwendigkeit.

Bei mir ja auch ...

So lange macht's ja eben auch Spaß zu wissen, daß es geht und wie. Wenn's nicht klappt, läßt man's sein und versucht es ein anderes Mal weiter.
Hat man sich vorher nie um IPv6 gekümmert und muß dann plötzlich umstellen, nachdem man festgestellt hat, daß es beim neuen Provider nur noch DS-lite gibt, dann kann's schon frustrierend werden, wenn's nicht auf Anhieb klappt.

Vielen Dank aber für deine ausführliche Erklärung.

Bitteschön.

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)

Mir ist keine Cam bekannt, die überhaupt noch weiterentwickelt wird, außer oscam (und das davon abgeleitete, blöd benannte, doscam).
MGCam und scam kriegen ja schon Probleme, wenn Du auf dem System z.B. die OpenSSL-Bibliothek auf den aktuellen Stand bringst ...
... es gibt ja auch keinen cccam für sh4-Boxen, für die Fritz!Box 7390 oder 7490, ...
Aus diesem Grund habe ich mich auch komplett von cccam, mgcam & Co. getrennt, denn oscam ist das einzige CAM, das ich einheitlich einsetzen kann.

Ja, oscams können sich untereinander direkt per IPv6 verbinden, sofern der IPv6-Support beim Bauen ausgewählt wurde.

Aktuell kann das auch lediglich oscam aus eigener Kraft, bei allen anderen Cams müßte man tatsächlich über solche Port-Proxies tricksen.
Das funktioniert übrigens auch umgekehrt, man kann also auch einen reinen CCCam-Server (Der ja für sich betrachtet IPv4-only ist) per IPv6 erreichbar machen:

6tunnel -4 -6 12200 127.0.0.1 12100

läßt den lokalen Rechner per IPv6 auf Port 12200 lauschen und verbindet dann weiter zu Port 12100 auf 127.0.0.1 also localhost.

Statt localhost bzw. 127.0.0.1 sollte man aber besser die tatsächliche lokale IPv4 des Rechners verwenden, da bei Verwendung von localhost / 127.0.0.1 je nach Server die Autorisierung übersprungen wird (Aus Sicht des Servers wird ja "lokal" zugegriffen).
Ist der Rechner/die Box auf der CCCam als Server läuft z.B. lokal die 192.168.178.10, dann lautet der Aufruf besser

6tunnel -4 -6 12200 192.168.178.10 12100

Richtig geschlußfolgert hat übrigens der, der jetzt denkt "Hm, dann kann ich ja sogar zwei CCcams, einen Server und einen Client, über eine IPv6-Internetverbindung koppeln, obwohl beide CCcams nur IPv4 können".
Dazu nutzt man einfach beide Tips, den 6tunnel wie im Posting weiter oben auf dem Client und den 6tunnel wie eben beschrieben auf dem Server ...

Hinweis: Der CCcam-Server oder auch jeder andere IPv4-only-Server darf dabei aber keine Überprüfung der IP-Adresse des Clients vornehmen. Für den Server kommen alle diese getunnelten Zugriffe von der eigenen Adresse ...

 

[habnefrage]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Ich baue mir gerade mal ein OSCAM für die ET9200 mit IPv6.
Mal gucken obs dann geht.

 

[habnefrage]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Hi,
ich habe das CrossCompiling nun hinbekommen und einen Oscam mit IPv6 auf meinem ET9200 laufen.
Im Oscam-Server auf dem PI ist der Benutzer eingeloggt und unter IP steht jetzt ne hübsche v6. Ich freu mich. :dfingers:

 

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

ich habe das CrossCompiling nun hinbekommen und einen Oscam mit IPv6 auf meinem ET9200 laufen.

Prima! :good:

Im Oscam-Server auf dem PI ist der Benutzer eingeloggt und unter IP steht jetzt ne hübsche v6. Ich freu mich. :dfingers:

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:

Wäre schön, wenn das mehr Leute tun würden, dann müßte man zu diesem Thema nicht mehr so viel Stuß lesen ... :JC_hmmm:

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

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.

Kannst du das nochmal erklären. Ich verwende acamd und hab einen portproxy hinzugefügt:

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.

Server ist auch ein raspberry pi mit ipv6 und dual stack (ipv4 und ipv6)
Client ist mit ipv4 und 6in4 tunnel (tunnelbroker).

Woan liegts?

 

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Nur leider seh ich im Webinterface von Oscam, dass sich der client weiterhin per ipv4 verbindet.

Du mußt noch im acamd die Server-Adresse ändern ...

In der smartcard.conf dürfte ja bisher so etwas wie

cccamn:meinserver.dyndns.org:12345:1/0000/0000:Benutzer:Kennwort:1:5

stehen, also wird auch das als Server genutzt.

Um durch den Port-Proxy zu gehen, muß daraus nun

cccamn:127.0.0.1:12345:1/0000/0000:Benutzer:Kennwort:1:5

werden.

Auf 127.0.0.1 12345 lauscht ja Dein Port-Proxy aus dem Aufruf von
netsh interface portproxy add v4tov6 listenport=12345 connectaddress=meinserver.dyndns.org connectport=12345
und die eigentliche Server-Adresse steht auch schon drin ...

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Okay, hab ich so gemacht, nur meldet dann acamd folgende Fehlermeldung und kann sich nicht mehr verbinden:

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)

usw.

Kannst du mal testen, ob dieser portproxy bei dir auch mit acamd funktioniert? Du hast ja glaube ich hadu verwendet. Aber das sollte ja eigentlich keinen Unterschied machen.

 

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Ist der Dyn-Hostname "meinserver.dyndns.org " denn wirklich auf eine IPv6 auflösbar?

Wenn Du auf der Kommandozeile

nslookup meinserver.dyndns.org

eingibst, muß auch eine IPv6 zu sehen sein (Sonst kann der Portproxy ja nicht verbinden).

Ach ja:
Die Portproxies gehen bei einem Neustart verloren.
Ich habe den Aufruf

In eine .cmd gepackt, die bei jedem Systemstart aufgerufen wird:

@echo off
netsh interface portproxy reset
netsh interface portproxy add v4tov6 listenport=10005 himbeere.fritz.box 10005

Der Aufruf von "netsh interface portproxy reset" zu Beginn erfolgt, damit man das Script auch später noch benutzen kann. Es werden also erst alle Port-Proxies gelöscht und dann de bzw. die neue (wieder) angelegt.

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

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?

 

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

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?

Wenn es für einen Hostname sowohl eine IPv6- als auch eine IPv4-Adresse gibt, wird IPv6 bevorzugt (Natürlich nur von Clients, die das auch können).

Trotzdem würde ich immer drei Hostnames (= 4 Records) anlegen:
blablabla.mooo.com (Mit A und AAAA Record)
ipv4.blablabla.mooo.com (Nur A Record)
ipv6.blablabla.mooo.com (Nur AAAA Record)


oscam z.B. hat nämlich keinen Rückfall auf IPv4 eingebaut. Wenn oscam auf einem IPv6-fähigen System läuft und eine IPv6-Anbindung erkennt, dann wird er IPv6 nutzen ... selbst wenn diese IPv6-Anbindung nur scheinbar besteht und nicht funktioniert.

Und diese Fehlkonfiguration liegt standardmäßig bei jedem Router mit OpenWrt ab mindestens Barrier Breaker vor:
Es ist standardmäßig ein ULA-Präfix eingetragen, welches im Heimnetz verteilt wird, selbst wenn keine IPv6-WAN-Anbindung konfiguriert wird. Dieses ULA-Präfix genügt oscam, um IPv6 zu benutzen, was aber dann mangels Außenanbindung schiefgeht.

Die richtige Lösung wäre dann natürlich, auch wirklich für die IPv6-Anbindung zu sorgen (z.B. über einen Hurricane Electric Tunnel, wenn es vom Provider kein natives IPv6 gibt) oder zumindest das ULA-Präfix aus der Konfiguration zu löschen um sauberen IPv4-only-Betrieb zu gewährleisten.
Von einer solchen sauberen Konfiguration kannst Du aber bei externen Clients nicht immer ausgehen.
Solchen Clients kann man dann den Hostname mit "ipv4." am Anfang geben, um eine IPv4-Verbindung zu erzwingen.

Umgekehrt kann man so über "ipv6." am Anfang eine IPv6-Verbindung erzwingen.
Das kann z.B. bei Clients Sinn machen die Tunnel für IPv6 benutzen, denn der Tunnel ist bei einem Verbindungsaufbau immer erst kurz nach der IPv4-Anbindung wieder oben, da er ja erst noch über diese aufgebaut werden muß.

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Danke, hat alles sehr weiter geholfen!

Mal eine andere Frage @Schimmelreiter, wie sind bei dir bei dieser ipv4/ipv6 portproxy-Geschichte die ECM-Zeiten? Im Vgl. zu nur ipv4?

 

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

wie sind bei dir bei dieser ipv4/ipv6 portproxy-Geschichte die ECM-Zeiten? Im Vgl. zu nur ipv4?

Die eigentlichen ECM-Zeiten ändern sich ja nicht.

Es kommt nur ggf. etwas Latenz auf dem Übertragungsweg hinzu, wenn der Traffic erst durch einen Port-Proxy im Netz muß.

Bei (D)einem lokalen Port-Proxy kommt da genau gar nix hinzu, denn 127.0.0.1 ist ja der eigene Rechner:

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]

Benutzen bei der Verbindung eine oder beide Seiten einen IPv6-Tunnel oder kommt ein Port-Proxy im Netz (feste-ip.net z.B.) ins Spiel, dann erhöht sich die Latenz geringfügig, weil der Traffic durch ein weiteres System im Internet geschleust werden muß. In der Praxis liegt diese Verzögerung aber << 15ms.

Bei einer nativen IPv6-Anbindung auf beiden Seiten wäre die IPv6-Verbindung sogar marginal schneller, da der Router sich nicht mehr mit dem NAT befassen muß, sondern einfach nur durchroutet.

Und wenn ein Server IPv4-only hat und dann für die IPv6-Anbindung einen Tunnel nutzt dann ist es durchaus wahrscheinlich, daß für einen DS-lite-Client die Latenz über IPv6 deutlich besser/geringer ausfällt, weil der Traffic nun zwar durch die IPv6-Tunnelanbindung zum Server muß, dafür aber der DS-lite-Tunnel samt mindestens doppeltem NAT auf Client-Seite entfällt.

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Wie ist das eigentlich, nehmen wir mal an ich habe einen nicht IPv6-fähigen Clienten (z.B. Diablo CAM Wifi oder so) im LAN und einen oscam-server (z.B. raspberry pi) im LAN, welcher eine IPv6-Adresse hat und oscam ist auch IPv6 fähig.

Ich kann ja nun nicht direkt auf Clientseite einen portproxy einrichten (oder doch, wenn ja wie?), der das auf IPv6 umwandelt. Kann ich jedoch einen portproxy auf dem raspberry einstellen (d.h. serverseitig), der mir dann die Anfragen für den Client auf IPv6 umwandelt? Oder wie funktioniert das?

 

[Osprey]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Dein Raspberry oder was auch immer Server ist im LAN, hat zusätzlich zur ipv6 auch eine private ipv4 Adresse.
Bei mir Zuhause verbinde ich mich auf meinem Pogoplug mit dem optimuss OS Receiver per oscam mit ipv6 und im Schlafzimmer mit der Dbox2 per ipv4.
Wenn oscam mit ipv6 Support auf dem Server läuft, bedeutet es nicht das nur noch ipv6 Verbindungen gehen, sondern es ist Mischbetrieb möglich.
Ein reiner ipv4 Client kann auch auf einen ipv6 Proxy Reader zugreifen und umgekehrt auch. Genial oder!?

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Ich weiß, aber ich will mich im LAN explizit über IPv6 verbinden, darum ging's mir.