\n\n

CCcam-Server unter Linux: Vollständige Einrichtung& Konfigurationsanleitung

\n\n

Die Einrichtung eines CCcam-Servers auf einer Linux-Box von Grund auf ist eine dieser Aufgaben, die einfach aussieht, bis Sie um 23 Uhr auf den ersten binären Kompatibilitätsfehler stoßen. Diese Anleitung behandelt den gesamten Weg: Architekturentscheidungen, binäre Installation, Syntax der Konfigurationsdatei, Firewall-Regeln und was zu tun ist, wenn etwas schiefgeht. Wenn Sie eine Smartcard in der Hand und eine Linux-Maschine bereit haben, hier ist genau das, was Sie wissen müssen.

\n\n

Was CCcam tatsächlich unter Linux tut (und wann Sie einen Server benötigen)

\n\n

CCcam ist ein Karten-Sharing-Daemon. Eine Maschine führt es mit einem angeschlossenen physischen Smartcard-Reader aus — das ist der Server. Andere Geräte in Ihrem Netzwerk (oder über das Internet) verbinden sich damit und fordern die ECM-Entschlüsselung für die Kanäle an, die sie sehen möchten. Der Server entschlüsselt mit der physischen Karte und sendet das Control Word zurück an den Client. All dies geschieht über TCP, Standardport 12000.

\n\n

Die Architektur ist wichtig, da sie Ihre Konfiguration bestimmt. Ein Server hat eine Karte lokal angeschlossen und stellt F-Linien für eingehende Clients zur Verfügung. Ein Client verbindet sich outbound mit C-Linien. Die meisten Menschen sind verwirrt, weil CCcam an beiden Enden läuft — es ist die gleiche Binärdatei, nur unterschiedlich konfiguriert.

\n\n

Client- vs. Server-Modus: Was sich in der Konfiguration ändert

\n\n

Es gibt kein separates "Server-Modus"-Flag. Die Unterscheidung liegt ganz darin, welche Zeilen inCCcam.cfg erscheinen. Wenn Sie F-Linien (die Benutzer definieren, die sich mit Ihnen verbinden) und eine DEVICE-Zeile haben, die auf einen lokalen Reader zeigt, sind Sie ein Server. Wenn Sie nur C-Linien haben (die nach außen zu einem anderen Host zeigen), sind Sie ein Client. Sie können auch beides gleichzeitig sein — upstream verbinden, während Sie downstream Clients bedienen — so funktionieren Kaskaden.

\n\n

Warum Linux das bevorzugte Host-Betriebssystem für CCcam ist

\n\n

Zuverlässigkeit ist der Hauptgrund. Eine Linux-Maschine, die CCcam als systemd-Dienst ausführt, wird nach einem Absturz automatisch neu gestartet und übersteht Neustarts ohne Eingreifen. Windows hat keine entsprechende Daemon-Infrastruktur dafür. Außerdem laufen die meisten ARM-basierten Satellitenreceiver, die die Leute tatsächlich verwenden — Dreambox, VU+, Zgemma — mit Enigma2, das Linux ist. Daher sind die Binärdatei, Init-Skripte und Konfigurationspfade plattformübergreifend gleich.

\n\n

Hardware-Anforderungen: CPU, RAM und Unterstützung für physische Smartcard-Reader

\n\n

CCcam ist nicht ressourcenhungrig. Ein 500-MHz-Prozessor und 64 MB RAM sind wirklich genug für eine Handvoll Clients. Jede moderne Linux-Box ist massiv überqualifiziert. Die echte Einschränkung ist der Smartcard-Reader: Sie benötigen entweder einen internen Reader (häufig bei Dreambox-Hardware) oder einen externen USB-Reader, der vom Kernel erkannt wird. Häufige Optionen sind sc8in1, phoenixrc-ähnliche Reader und standardmäßige CCID-konforme USB-Reader. Führen Siedmesg | grep tty nach dem Anschließen zur Bestätigung, dass es angezeigt wird — es wird erscheinen als/dev/ttyUSB0,/dev/ttyACM0 oder ähnlich, abhängig vom Chipsatz.

\n\n

CCcam auf Linux installieren: Binärdatei, Abhängigkeiten und erster Start

\n\n

CCcam 2.3.0 ist die letzte Version, die jemals weit verbreitet war. Es ist Closed-Source, wurde nie aktualisiert, und die ursprünglichen Entwickler sind längst verschwunden. Was Sie haben, ist eine statische oder semi-statische Binärdatei — und auf einem modernen 64-Bit Debian oder Ubuntu Server verursacht das sofort Probleme, da es sich um eine 32-Bit ELF-Binärdatei handelt.

\n\n

Die richtige CCcam-Binärdatei für Ihre Architektur auswählen

\n\n

Führen Siefile CCcam auf welcher Binärdatei auch immer Sie haben, aus. Sie werden etwas sehen wieELF 32-bit LSB ausführbar, ARM, EABI5 oderELF 32-bit LSB ausführbar, Intel 80386. Passen Sie die Binärdatei an Ihre Hardware an. ARM-Binärdateien für ARM-Empfänger. x86 32-Bit-Binärdateien für generische PC-Server. Wenn Sie auf einer 64-Bit x86-Maschine sind, benötigen Sie die x86 32-Bit-Binärdatei plus die Kompatibilitätsschicht — nicht den ARM-Bau, selbst wenn ARM irgendwie verfügbar ist.

\n\n

32-Bit-Bibliotheksabhängigkeiten auf Debian/Ubuntu installieren

\n\n

Auf einem frischen 64-Bit Debian 11/12 oder Ubuntu 22.04 System ist die 32-Bit-Laufzeit standardmäßig nicht installiert. Beheben Sie das zuerst:

\n\n

dpkg --add-architecture i386\napt-get update\napt-get install libc6-i386 lib32gcc-s1

\n\n

In älteren Ubuntu-Versionen (vor 20.04) könnten Sieia32-libs in alten Anleitungen erwähnt sehen — dieses Paket gibt es nicht mehr. Verwenden Sielibc6-i386 stattdessen. Nach der Installation überprüfen Sie mitldd CCcam ob alle Shared Libraries aufgelöst werden. Wenn Sie einen Docker-Container ausführen, der nur 64-Bit unterstützt und keine Multiarch-Unterstützung hat, überspringen Sie CCcam vollständig und gehen Sie direkt zu OScam (in Abschnitt 6 behandelt).

\n\n

Das Binärprogramm platzieren und ausführbare Berechtigungen setzen

\n\n

cp CCcam /usr/local/bin/CCcam\nchmod +x /usr/local/bin/CCcam\nchown root:root /usr/local/bin/CCcam

\n\n

Auf Enigma2-Receiver-Images befindet sich das Binärprogramm normalerweise in/usr/bin/CCcam und wird von einem init.d-Skript gestartet. Verschieben Sie es auf diesen Systemen nicht — deren Init-Skripte erwarten es an diesem Pfad.

\n\n

CCcam als systemd-Dienst für automatischen Neustart ausführen

\n\n

Erstellen Sie/etc/systemd/system/cccam.service mit folgendem Inhalt:

\n\n

[Unit]\nBeschreibung=CCcam Kartenserver\nNach=network.target\n\n[Dienst]\nExecStartPre=/bin/sleep 10\nExecStart=/usr/local/bin/CCcam\nRestart=on-failure\nRestartSec=5\nStandardOutput=journal\nStandardError=journal\n\n[Install]\nWantedBy=multi-user.target

\n\n

DasExecStartPre=/bin/sleep 10 ist nicht optional, wenn Ihr Smartcard-Leser einen Moment benötigt, um nach dem Booten zu initialisieren. Ohne es startet CCcam, bevor der Kernel den USB-Leser überhaupt eingerichtet hat, und protokolliert "keine Karte gefunden" — und versucht dann nie richtig erneut.

\n\n

systemctl daemon-reload\nsystemctl enable cccam\nsystemctl start cccam

\n\n

Überprüfen, ob der Prozess auf Port 12000 lauscht

\n\n

ss -tlnp | grep 12000\n# oder\nnetstat -tlnp | grep CCcam

\n\n

Sie sollten sehen, dass CCcam gebunden ist an0.0.0.0:12000 oder eine spezifische Schnittstellen-IP. Wenn nichts angezeigt wird, überprüfen Siejournalctl -u cccam -n 50 auf Startfehler.

\n\n

CCcam.cfg Tiefenblick: Jede Direktive, die Sie wissen müssen

\n\n

Die Konfigurationsdatei befindet sich standardmäßig unter/etc/CCcam.cfg . CCcam schaut dort zuerst. Einige Startskripte übergeben den Pfad als Argument – überprüfen Sie Ihres, wenn Änderungen nicht übernommen werden. Eine Sache, die die Leute ständig beißt: Windows-Zeilenenden (CRLF) in der Konfigurationsdatei verursachen stille Parsing-Fehler unter Linux. Wenn Sie diese Datei unter Windows bearbeitet und übertragen haben, führen Siedos2unix /etc/CCcam.cfg aus, bevor Sie etwas anderes debuggen.

\n\n

Kommentare verwenden# oder// – beides funktioniert. Direktiven sind nicht groß-/kleinschreibungsempfindlich für das Schlüsselwort selbst, aber die Werte (Benutzernamen, Passwörter, Hostnamen) sind groß-/kleinschreibungsempfindlich.

\n\n

Serverport und Listenadresse: SERVERPORT und BIND-Direktiven

\n\n

# Hören Sie auf eingehende CCcam-Clientverbindungen\nSERVERPORT: 12000\n\n# Binden Sie an eine spezifische Schnittstelle (empfohlen)\n# BIND: 10.8.0.1

\n\n

Wenn Sie mehrere Netzwerkschnittstellen haben – sagen wir, eine WAN-Schnittstelle und eine VPN-Schnittstelle – wird CCcam standardmäßig an alle gebunden (0.0.0.0). Das ist ein Sicherheitsproblem. Verwenden Sie die BIND-Direktive, um es nur an die IP der VPN-Schnittstelle zu binden. Mehr dazu im Abschnitt zur Firewall.

\n\n

Lokale Kartenleser definieren: DEVICE, CARDTYPE und BOXKEY-Zeilen

\n\n

# Definieren Sie den physischen Smartcard-Leser\nDEVICE: /dev/ttyUSB0 SR\nCARDTYPE: 0\nBOXKEY: 00 00 00 00 00 00 00 00

\n\n

Der DEVICE-Pfad muss mit dem übereinstimmen, wasdmesgzeigt. Wenn Ihr Leser als/dev/ttyACM0statt als/dev/ttyUSB0erscheint, muss die Konfiguration/dev/ttyACM0sagen. Dies falsch zu machen, ist einer der häufigsten Gründe für "keine Karte gefunden"-Fehler. CARDTYPE 0 bedeutet automatische Erkennung, was für die meisten Karten funktioniert. BOXKEY ist relevant für Nagravision-Karten, die einen Boxkey verwenden — lassen Sie ihn auf null, wenn Ihre keinen hat.

\n\n

Hinzufügen von C-Line-Clients: C: Syntax-Zerlegung

\n\n

Eine C-Line sagt diesem Server, dass er sich nach außen mit einem anderen CCcam-Server verbinden soll:

\n\n

C: remote.host.example 12000 meinbenutzername meinpasswort {0:0:1} 01

\n\n

Das aufgeschlüsselt:remote.host.example ist der Hostname oder die IP des upstream Servers.12000 ist der Port.meinbenutzername undmeinpasswort sind Ihre Anmeldedaten auf diesem Server.{0:0:1} ist ein optionaler CAID-Filter im Format{CAID:ProviderID:1} — ein Wert von0:0:1 bedeutet, alle CAIDs zu akzeptieren. Die nachfolgende01 ist die Hop-Anzahl für das Resharing von Karten, die von dieser Zeile empfangen wurden.

\n\n

Hinzufügen von F-Zeilen-Benutzern (Eingehende Verbindungen): F: Syntax und Hop-Limits

\n\n

F-Zeilen definieren, wer sich mit Ihrem Server verbinden darf:

\n\n

F: client1 starkespasswort 1 0 0 0 { 1830:000000:1 }\nF: client2 anderespass 1 0 0 0 { 0:0:1 }

\n\n

Die Felder nach dem Passwort sind: Reshare-Level (1 = kann einen Hop resharen), minimale Karten-Hop (0 = lokale Karten), CAID-Gruppe, Ident-Gruppe und ein optionaler CAID-Filterblock. Der Filter{ 1830:000000:1 } beschränkt diesen Benutzer nur auf CAID 0x1830. Verwenden Sie starke, einzigartige Passwörter für jede F-Zeile — dies sind die Anmeldeinformationen, die Ihre Clients in ihre C-Zeilen eingeben.

\n\n

B-Zeile zum Blockieren spezifischer Anbieter-IDs

\n\n

B: 1234 000000

\n\n

B-Zeilen blockieren eine spezifische CAID/Anbieter-Kombination vom Teilen. Wenn Sie eine Karte mit mehreren Anbietern haben und einen zurückhalten möchten, so geht das. Das Format istB: CAID AnbieterID.

\n\n

TEILENLIMIT und HOP-ANZAHL: Steuerung der Reshare-Tiefe

\n\n

HOP-ANZAHL steuert, wie oft eine Karte reshared werden kann, bevor CCcam aufhört, sie weiterzugeben. Stellen Sie es in F-Zeilen (pro Benutzer) oder global ein:

\n\n

TEILENLIMIT: 3

\n\n

Eine HOP-ANZAHL von 0 bedeutet, dass die Karte lokal ist und überhaupt nicht reshared wird. Ein Wert von 1 bedeutet, dass sie einen Hop zu Clients gehen kann, aber diese Clients können sie nicht resharen. Halten Sie dies so niedrig wie praktisch nötig — tiefe Reshare-Ketten verlangsamen die ECM-Antwortzeiten und schaffen Verantwortungsprobleme.

\n\n

LOG- und DEBUG-Direktiven zur Fehlersuche

\n\n

LOGFILE: /var/log/cccam.log\nLOGLEVEL: 1\nDEBUG: 0

\n\n

LOGLEVEL 1 gibt Ihnen Verbindungsereignisse und ECM-Aktivitäten, ohne die Festplatte zu überfluten. Setzen Sie DEBUG vorübergehend auf 1, wenn Sie ein spezifisches Problem verfolgen — es ist ausführlich und Sie werden es wieder ausschalten wollen. Die Weboberfläche auf Port 16001 (Standardanmeldedaten: admin/admin — ändern Sie diese sofort) zeigt den aktuellen Kartenstatus, verbundene Clients und ECM-Zeitmessung an, was während der Diagnose viel einfacher zu lesen ist als rohe Protokolle.

\n\n

Firewall, Netzwerk und Portweiterleitung für CCcam

\n\n

Hier bleibt eine CCcam-Server-Linux-Installation am häufigsten stecken. Der Dienst läuft, die Konfiguration sieht richtig aus, aber Clients können sich nicht verbinden. Neun von zehn Mal liegt es an einer Firewall-Regel oder einem NAT-Problem.

\n\n

Öffnen des TCP-Ports 12000 mit iptables und ufw

\n\n

Direkte Verwendung von iptables:

\n\n

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT\n# Regeln speichern, damit sie beim Neustart überleben:\niptables-save > /etc/iptables/rules.v4

\n\n

Oder wenn Sie ufw verwenden:

\n\n

ufw allow 12000/tcp\nufw reload

\n\n

Wenn Sie nur bekannte Client-IP-Adressen zulassen möchten (viel bessere Praxis):

\n\n

iptables -A INPUT -p tcp --dport 12000 -s 203.0.113.45 -j ACCEPT\niptables -A INPUT -p tcp --dport 12000 -j DROP

\n\n

CCcam an eine bestimmte Schnittstelle binden, um Exposition zu vermeiden

\n\n

Wenn Ihr Server eine öffentliche Schnittstelle (eth0) und eine VPN-Schnittstelle (wg0 oder tun0) hat, lassen Sie CCcam nicht auf beiden lauschen. Fügen Sie die BIND-Direktive in CCcam.cfg mit der IP der privaten/VPN-Schnittstelle hinzu. Clients verbinden sich über das VPN, und Port 12000 wird niemals öffentlich im Internet exponiert. Das ist der richtige Weg, es zu tun.

\n\n

Verwendung eines VPN-Tunnels (WireGuard/OpenVPN), anstatt Port 12000 öffentlich zu exponieren

\n\n

WireGuard ist heutzutage die bessere Wahl — weniger Overhead als OpenVPN, einfachere Konfiguration, und das Kernel-Modul ist seit Linux 5.6 im Hauptzweig. Richten Sie einen WireGuard-Peer zwischen Ihrem Server und jedem Client ein, weisen Sie ihnen Adressen in einem privaten Subnetz zu (z.B. 10.8.0.0/24), binden Sie CCcam an 10.8.0.1 und geben Sie diese Adresse in den C-Zeilen auf der Client-Seite an. Niemand, der das Internet scannt, wird jemals Port 12000 sehen.

\n\n

NAT und Portweiterleitung, wenn der Server hinter einem Heimrouter steht

\n\n

Wenn Ihre Linux-Box in einem Heimnetzwerk ist, müssen Sie den TCP-Port 12000 auf Ihrem Router an die lokale IP des Servers weiterleiten. Die meisten Router nennen dies "Portweiterleitung" oder "virtueller Server." Setzen Sie den externen Port auf 12000, Protokoll TCP, interne IP auf die LAN-Adresse Ihres Servers (machen Sie sie statisch, entweder über DHCP-Reservierung oder manuelle Konfiguration), interner Port 12000. Dann verwenden die Clients Ihre öffentliche IP in ihren C-Zeilen.

\n\n

Ein großes Problem: Wenn Ihr ISP CGNAT (Carrier-Grade NAT) verwendet, haben Sie tatsächlich keine öffentliche IP — Sie teilen sich eine mit Dutzenden von anderen Kunden und es gibt keine Möglichkeit, eingehende Verbindungen weiterzuleiten. Die Lösung ist, einen günstigen VPS zu mieten, WireGuard darauf auszuführen und den CCcam-Verkehr darüber zu tunneln. Der VPS wird zum öffentlichen Endpunkt; Ihr Heimserver kommuniziert über den Tunnel zurück.

\n\n

Dynamisches DNS für Server ohne statische IP

\n\n

Wenn sich Ihre öffentliche IP ändert, können Clients mit Ihrer alten IP in ihren C-Zeilen keine Verbindung herstellen. Verwenden Sie einen dynamischen DNS-Dienst und geben Sie den Hostnamen (z.B.myserver.ddns.net) in den C-Zeilen anstelle einer reinen IP an. Führen Sie einen DDNS-Update-Client wieddclientauf Ihrem Linux-Server aus, um den Eintrag aktuell zu halten. Die meisten Heimrouter haben dies ebenfalls integriert.

\n\n

Außerdem: Wenn Ihr ISP eingehendes TCP auf Port 12000 speziell blockiert (einige tun dies), ändern Sie SERVERPORT in etwas weniger Auffälliges wie 15000 oder 8080, aktualisieren Sie die Portweiterleitungsregel Ihres Routers und aktualisieren Sie jede C-Zeile des Clients entsprechend.

\n\n

Fehlerbehebung bei häufigen CCcam-Serverproblemen unter Linux

\n\n

Das Debuggen einer CCcam-Server-Linux-Konfiguration folgt einem ziemlich konsistenten Muster: Schichten nacheinander eliminieren, beginnend von unten (läuft der Prozess überhaupt?) über Netzwerk, dann Konfiguration, dann Kartenerkennung.

\n\n

CCcam startet, aber Clients können nicht verbinden: Checkliste

\n\n

\n
• Bestätigen Sie, dass der Prozess tatsächlich läuft:systemctl status cccam
\n
• Bestätigen Sie, dass er lauscht:ss -tlnp | grep 12000
\n
• Zuerst lokal testen:telnet 127.0.0.1 12000 — wenn dies fehlschlägt, liegt das Problem beim Dienst, nicht beim Netzwerk
\n
• Firewall überprüfen:iptables -L -n | grep 12000
\n
• Überprüfen Sie die F-Zeile: Benutzername und Passwort müssen genau mit dem übereinstimmen, was der Client in seiner C-Zeile verwendet
\n
• Bestätigen Sie, dass die IP/Hostname der C-Zeile des Clients korrekt von der Client-Maschine aufgelöst wird
\n

\n\n

'Keine Karte gefunden' oder Karte nach der Leserdefinition nicht erkannt

\n\n

Beginnen Sie mitdmesg | tail -30 direkt nach dem Anschließen des Lesers. Sie sollten eine Zeile über ein neues USB-Gerät und den zugewiesenen Gerätenamen sehen. Wenn Sie es nicht sehen, wird der Leser auf Kernel-Ebene nicht erkannt — könnte ein Treiberproblem oder ein Hardwarefehler sein.

\n\n

Wenn der Leser angezeigt wird, aber die Karte nicht erkannt wird, überprüfen Sie, ob die DEVICE-Zeile in CCcam.cfg auf den genauen Pfad zeigt, der in dmesg angezeigt wird. Denken Sie daran:/dev/ttyACM0 und/dev/ttyUSB0 sind unterschiedliche Geräte und das falsche wird stillschweigend fehlschlagen. Überprüfen Sie auch, ob der CCcam-Prozessbenutzer Lese-/Schreibberechtigungen für das Gerät hat:ls -l /dev/ttyUSB0 und fügen Sie den CCcam-Benutzer bei Bedarf zurdialout Gruppe hinzu.

\n\n

Falsche ECM-Antworten und Dekodierungsfehler (CAID-Mismatch)

\n\n

Der Client verbindet sich, das sehen Sie in der CCcam-Weboberfläche auf Port 16001, aber der Kanal wird nicht entschlüsselt. Fast immer ein CAID-Mismatch. Öffnen Sie die Weboberfläche, schauen Sie sich an, welche CAIDs der Server tatsächlich bewirbt. Überprüfen Sie dann, welchen CAID der Kanal verwendet — der Kanalinfo-Bildschirm Ihres STB oder ein CAM-Menü zeigt dies an. Wenn sie nicht übereinstimmen, kann der Server diesem Client unabhängig vom Verbindungsstatus nicht helfen.

\n\n

Überprüfen Sie auch die HOP COUNT. Wenn die F-Zeile für diesen Client einen Reshare-Wert von 0 hat und die Karte von einer upstream C-Zeile (nicht lokal) empfangen wurde, erhält der Client nichts. HOP COUNT 0 blockiert das Resharing von nicht-lokalen Karten.

\n\n

Hohe Last / Langsame ECM-Antwortzeiten

\n\n

Eine einzelne physische Karte kann immer nur ein ECM gleichzeitig verarbeiten. Wenn Sie 10 Clients haben, die gleichzeitig eine Entschlüsselung anfordern, warten sie in der Warteschlange und die Antwortzeiten steigen. Der Kanal kann stottern oder vorübergehend schwarz werden. Die Lösung besteht darin, entweder weniger Clients, zusätzliche physische Karten oder zusätzliche upstream C-Zeilen mit unterschiedlichen Karten zu verwenden. Es gibt keinen Software-Workaround dafür — es ist eine Hardware-Beschränkung.

\n\n

Protokolldatei-Standort und wie man CCcam-Debug-Ausgaben liest

\n\n

Wenn LOGFILE in CCcam.cfg definiert ist, gehen die Protokolle dorthin. Andernfalls, wenn Sie unter systemd laufen, verwenden Siejournalctl -u cccam -f für einen Live-Tail. Suchen Sie nach Zeilen, die "connected", "ECM", "card" und Fehlercodes enthalten. Eine ECM-Antwort von "0x00" bedeutet normalerweise, dass die Karte korrekt geantwortet hat. Fehler wie "N/A" oder Timeout-Nachrichten deuten auf Kartenprobleme hin.

\n\n

CCcam stürzt beim Start ab: Fehlerbehebung bei binärer Inkompatibilität

\n\n

Führen Sie zuerstfile CCcam aus. Führen Sie dannldd CCcam aus. Wenn Sie "not a dynamic executable" sehen, ist die Binärdatei statisch verlinkt und sollte einfach laufen. Wenn Sie ungelöste Bibliotheken ("not found") sehen, installieren Sie die fehlenden 32-Bit-Pakete. Wenn CCcam sofort mit "Exec format error" beendet wird, haben Sie eine vollständige Architekturinkompatibilität — beispielsweise eine ARM-Binärdatei auf x86. Besorgen Sie sich die richtige Binärdatei für Ihre Plattform.

\n\n

CCcam vs OScam als Linux-Server: Wann wechseln

\n\n

Wenn Sie heute neu anfangen, ziehen Sie ernsthaft OScam in Betracht. CCcam 2.3.0 ist Abandonware — keine Patches, keine Updates, kein Quellcode zur Überprüfung. OScam wird aktiv gewartet, ist Open Source (GPL) und unterstützt eine Obermenge dessen, was CCcam tut. Der einzige Grund, bei CCcam zu bleiben, ist, wenn Sie speziell CCcam-Client-Kompatibilität mit älteren Geräten benötigen, die das native Protokoll von OScam nicht unterstützen — und selbst dann kann OScam das handhaben.

\n\n

Wesentliche Unterschiede in der Architektur

\n\n

CCcam ist eine Black Box. Sie nehmen die Binärdatei, konfigurieren sie und hoffen, dass sie funktioniert — es gibt keine Möglichkeit, die internen Abläufe zu inspizieren oder zu ändern. OScam ist vollständig Open Source, wird aktiv für neue Kartentypen und Sicherheitsprobleme gepatcht und hat ein viel reichhaltigeres Konfigurationsmodell mit Filterung pro Leser und pro Benutzer auf einer Granularität, die CCcam nicht erreichen kann. Die Weboberfläche in OScam ist auch erheblich besser als die grundlegende Seite von CCcam auf Port 16001.

\n\n

OScam's überlegene CAID- und Provider-ID-Filterung

\n\n

In OScam können Sie nach CAID, Provider-ID, Service-ID und sogar spezifischen ECM-PIDs filtern — alles unabhängig pro Leser, pro Benutzer und pro Profil. Im Vergleich dazu ist die Filterung von CCcam grob. Wenn Sie eine Karte mit mehreren Provider-Paketen betreiben und eine präzise Kontrolle darüber benötigen, auf was jeder Client zugreifen kann, ist OScam das richtige Werkzeug für den Job.

\n\n

OScam als CCcam-Protokollserver (cs378x / cs357x-Listener) betreiben

\n\n

OScam kann das CCcam-Protokoll nativ sprechen. Das bedeutet, dass Ihre bestehenden CCcam-Clients ihre C-Linien überhaupt nicht ändern müssen — OScam antwortet auf Port 12000 und sie merken den Unterschied nie.

\n\n

In/etc/oscam/oscam.conf fügen Sie einen Listener-Block hinzu:

\n\n

[cs378x]\nport = 12000\nkey = 0102030405060708091011121314151617181920

\n\n

Das cs378x-Modul verarbeitet CCcam-Protokollversion 2.x-Verbindungen. Verwenden Sie cs357x für ältere CCcam-Protokollvarianten. Benutzer werden dann in/etc/oscam/oscam.user mitprotocol = cccam definiert.

\n\n

Migrationspfad: Konvertierung von CCcam.cfg in OScam-Konfigurationsdateien

\n\n

CCcam C-Linien werden zu Leser-Einträgen in/etc/oscam/oscam.server:

\n\n

[reader]\nlabel = upstream1\nprotocol = cccam\ndevice = remote.host.example,12000\nuser = myusername\npassword = mypassword\ncaid = 1830\nident = 1830:000000

\n\n

CCcam F-Linien werden zu Benutzereinträgen in/etc/oscam/oscam.user:

\n\n

[account]\nuser = client1\npwd = starkespasswort\nprotocol = cccam\ngroup = 1\ncaid = 1830

\n\n

Die Umwandlung ist mechanisch, erfordert jedoch, dass man Zeile für Zeile vorgeht. Es gibt kein automatisches Tool, das jeden Sonderfall zuverlässig behandelt. Nimm dir eine Stunde Zeit und mache es manuell — es lohnt sich für die langfristige Wartbarkeit einer ordentlichen OScam-Konfiguration im Vergleich zu einer veralteten cccam-Server-Linux-Installation.

\n\n