CCcam-Server unter Linux: Vollständige Einrichtungs- und Konfigurationsanleitung

Die Einrichtung eines CCCam-Servers auf einem Linux-System von Grund auf ist eine dieser Aufgaben, die einfach erscheinen, bis man um 23 Uhr auf den ersten Kompatibilitätsfehler stößt. Dieser Leitfaden beschreibt den gesamten Prozess: Architekturentscheidungen, Binärinstallation, Konfigurationsdateisyntax, Firewall-Regeln und was zu tun ist, wenn Probleme auftreten. Wenn Sie eine Smartcard und einen einsatzbereiten Linux-Rechner haben, finden Sie hier alle notwendigen Informationen.

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

CCcam ist ein Karten-Sharing-Daemon. Er läuft auf einem Rechner mit angeschlossenem Smartcard-Lesegerät – das ist der Server. Andere Geräte in Ihrem Netzwerk (oder über das Internet) verbinden sich mit ihm und fordern die ECM-Entschlüsselung der Kanäle an, die sie ansehen möchten. Der Server entschlüsselt die Daten mithilfe der Smartcard und sendet das Kontrollwort an den Client zurück. Die gesamte Kommunikation erfolgt über TCP, Standardport 12000.

Die Architektur ist wichtig, da sie Ihre Konfiguration bestimmt. Ein Server verfügt über eine lokal angeschlossene Karte und stellt F-Leitungen für eingehende Clients bereit. Ein Client verbindet sich ausgehend über C-Leitungen. Die meisten Anwender sind verwirrt, da CCcam auf beiden Seiten läuft – es handelt sich um dieselbe Binärdatei, nur unterschiedlich konfiguriert.

Client- vs. Servermodus: Was ändert sich in der Konfiguration?

Es gibt kein separates „Server-Modus“-Flag. Der Unterschied liegt ausschließlich in den Einträgen der CCcam.cfg . Wenn Sie F-Zeilen (die die Benutzer definieren, die sich mit Ihnen verbinden) und eine DEVICE-Zeile haben, die auf ein lokales Lesegerät verweist, sind Sie ein Server. Wenn Sie nur C-Zeilen haben (die auf einen anderen Host verweisen), sind Sie ein Client. Sie können auch gleichzeitig beides sein – Verbindungen zum Server herstellen und gleichzeitig Clients bedienen –, so funktionieren Kaskadenverbindungen.

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

Zuverlässigkeit ist der Hauptgrund. Ein Linux-Rechner, auf dem CCcam als systemd-Dienst läuft, startet nach einem Absturz automatisch neu und übersteht Neustarts ohne Eingriff. Windows bietet keine vergleichbare Daemon-Infrastruktur. Zudem nutzen die meisten gängigen ARM-basierten Satellitenreceiver – Dreambox, VU+, Zgemma – Enigma2, das auf Linux basiert. Daher sind Binärdateien, Init-Skripte und Konfigurationspfade plattformübergreifend identisch.

Hardwareanforderungen: CPU, RAM und Unterstützung für physische Smartcard-Lesegeräte

CCcam benötigt keine hohen Ressourcen. Ein 500-MHz-Prozessor und 64 MB RAM reichen für einige wenige Clients völlig aus. Jeder moderne Linux-Rechner ist dafür mehr als ausreichend. Die eigentliche Einschränkung ist der Smartcard-Leser: Sie benötigen entweder einen internen Leser (üblicherweise bei Dreambox-Hardware) oder einen externen USB-Leser, der vom Kernel erkannt wird. Gängige Optionen sind sc8in1, Leser im phoenixrc-Stil und standardmäßige CCID-kompatible USB-Leser. Führen Sie nach dem Anschließen den Befehl dmesg | grep tty aus, um zu überprüfen, ob der Leser erkannt wurde – er wird je nach Chipsatz als /dev/ttyUSB0 , /dev/ttyACM0 oder ähnlich angezeigt.

Installation von CCcam unter Linux: Binärdatei, Abhängigkeiten und erster Start

CCcam 2.3.0 ist die letzte Version, die jemals weit verbreitet war. Sie ist proprietär, wurde nie aktualisiert und die ursprünglichen Entwickler sind längst verstorben. Es handelt sich um eine statische oder semistatische Binärdatei – und auf einem modernen 64-Bit-Debian- oder Ubuntu-Server führt dies sofort zu Problemen, da es sich um eine 32-Bit-ELF-Binärdatei handelt.

Auswahl der richtigen CCcam-Binärdatei für Ihre Architektur

Führen Sie file CCcam mit der vorhandenen Binärdatei aus. Sie sehen dann beispielsweise ELF 32-bit LSB executable, ARM, EABI5 oder ELF 32-bit LSB executable, Intel 80386 . Wählen Sie die Binärdatei passend zu Ihrer Hardware aus. ARM-Binärdateien sind für ARM-Empfänger geeignet. x86-32-Bit-Binärdateien sind für Standard-PC-Server gedacht. Wenn Sie ein 64-Bit-x86-System verwenden, benötigen Sie die x86-32-Bit-Binärdatei plus Kompatibilitätsschicht – nicht die ARM-Version, selbst wenn diese verfügbar ist.

Installation von 32-Bit-Bibliotheksabhängigkeiten unter Debian/Ubuntu

Auf einem frisch installierten 64-Bit-System mit Debian 11/12 oder Ubuntu 22.04 ist die 32-Bit-Laufzeitumgebung nicht standardmäßig installiert. Beheben Sie dies zuerst:

 dpkg --add-architecture i386 apt-get update apt-get install libc6-i386 lib32gcc-s1

Bei älteren Ubuntu-Versionen (vor 20.04) wird in alten Anleitungen möglicherweise noch auf ia32-libs verwiesen – dieses Paket ist nicht mehr verfügbar. Verwenden Sie stattdessen libc6-i386 . Überprüfen Sie nach der Installation mit ldd CCcam , ob alle gemeinsam genutzten Bibliotheken aufgelöst werden. Wenn Sie einen Docker-Container verwenden, der ausschließlich 64-Bit unterstützt und keine Multiarch-Architektur bietet, überspringen Sie CCcam und verwenden Sie direkt OScam (siehe Abschnitt 6).

Platzieren der Binärdatei und Festlegen der Ausführungsberechtigungen

 cp CCcam /usr/local/bin/CCcam chmod +x /usr/local/bin/CCcam chown root:root /usr/local/bin/CCcam

Auf Enigma2-Empfänger-Images befindet sich die Binärdatei üblicherweise unter /usr/bin/CCcam und wird von einem init.d-Skript gestartet. Verschieben Sie sie auf diesen Systemen nicht – die init.d-Skripte erwarten sie an diesem Pfad.

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

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

 [Unit] Description=CCcam Card Server After=network.target [Service] ExecStartPre=/bin/sleep 10 ExecStart=/usr/local/bin/CCcam Restart=on-failure RestartSec=5 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

Die ExecStartPre=/bin/sleep 10 ist zwingend erforderlich, wenn Ihr Smartcard-Lesegerät nach dem Systemstart kurz initialisiert werden muss. Ohne diese Zeile startet CCcam, bevor der Kernel die Einrichtung des USB-Lesegeräts abgeschlossen hat, und meldet „Keine Karte gefunden“ – ein erneuter Verbindungsversuch wird anschließend nicht mehr unternommen.

 systemctl daemon-reload systemctl enable cccam systemctl start cccam

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

 ss -tlnp | grep 12000 # or netstat -tlnp | grep CCcam

CCcam sollte an 0.0.0.0:12000 oder eine bestimmte Schnittstellen-IP gebunden sein. Falls nichts angezeigt wird, überprüfen Sie journalctl -u cccam -n 50 auf Startfehler.

CCcam.cfg im Detail: Alle notwendigen Anweisungen

Die Konfigurationsdatei befindet sich standardmäßig unter /etc/CCcam.cfg . CCcam sucht dort zuerst. Einige Startskripte übergeben den Pfad als Argument – überprüfen Sie Ihre Konfiguration, falls Änderungen nicht übernommen werden. Ein häufig auftretendes Problem: Windows-Zeilenumbrüche (CRLF) in der Konfigurationsdatei verursachen unter Linux unbemerkte Analysefehler. Wenn Sie diese Datei unter Windows bearbeitet und übertragen haben, führen Sie dos2unix /etc/CCcam.cfg aus, bevor Sie andere Schritte zur Fehlerbehebung durchführen.

Kommentare verwenden # oder // – beides funktioniert. Direktiven unterscheiden nicht zwischen Groß- und Kleinschreibung beim Schlüsselwort selbst, die Werte (Benutzernamen, Passwörter, Hostnamen) jedoch schon.

Server-Port und Listener-Adresse: SERVERPORT- und BIND-Direktiven

 # Listen for incoming CCcam client connections SERVERPORT: 12000 # Bind to a specific interface (recommended) # BIND: 10.8.0.1

Wenn Sie mehrere Netzwerkschnittstellen haben – beispielsweise eine WAN- und eine VPN-Schnittstelle – bindet CCcam standardmäßig an alle (0.0.0.0). Dies stellt ein Sicherheitsrisiko dar. Verwenden Sie die BIND-Direktive, um die Bindung auf die IP-Adresse der VPN-Schnittstelle zu beschränken. Weitere Informationen dazu finden Sie im Abschnitt zur Firewall.

Lokale Kartenleser definieren: DEVICE-, CARDTYPE- und BOXKEY-Zeilen

 # Define the physical smartcard reader DEVICE: /dev/ttyUSB0 SR CARDTYPE: 0 BOXKEY: 00 00 00 00 00 00 00 00

Der Gerätepfad muss mit dem dmesg angezeigten Pfad übereinstimmen. Wenn Ihr Lesegerät als /dev/ttyACM0 anstatt als /dev/ttyUSB0 angezeigt wird, muss die Konfiguration /dev/ttyACM0 angeben. Ein Fehler in diesem Bereich ist eine der häufigsten Ursachen für die Fehlermeldung „Keine Karte gefunden“. 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 Karte keinen Boxkey verwendet.

Hinzufügen von C-Zeilen-Clients: C: Syntaxaufschlüsselung

Eine C-Leitung weist diesen Server an, eine Verbindung zu einem anderen CCcam-Server herzustellen:

 C: remote.host.example 12000 myusername mypassword {0:0:1} 01

Das bedeutet im Detail: remote.host.example ist der Hostname oder die IP-Adresse des Upstream-Servers. 12000 ist der Port. myusername und mypassword sind Ihre Zugangsdaten für diesen Server. {0:0:1} ist ein optionaler CAID-Filter im Format {CAID:ProviderID:1} – der Wert 0:0:1 bedeutet, dass alle CAIDs akzeptiert werden. Die nachfolgende 01 gibt die Anzahl der Hops für die Weiterleitung von über diese Leitung empfangenen Karten an.

Hinzufügen von F-Leitungsbenutzern (eingehende Verbindungen): F: Syntax und Hop-Limits

F-Linien legen fest, wer sich mit Ihrem Server verbinden darf:

 F: client1 strongpassword 1 0 0 0 { 1830:000000:1 } F: client2 anotherpass 1 0 0 0 { 0:0:1 }

Die Felder nach dem Passwort sind: Reshare-Level (1 = ein Hop Reshare möglich), minimaler Karten-Hop (0 = lokale Karten), CAID-Gruppe, Identifikationsgruppe und ein optionaler CAID-Filterblock. Der Filter { 1830:000000:1 } beschränkt diesen Benutzer auf CAID 0x1830. Verwenden Sie für jede F-Zeile sichere, eindeutige Passwörter – dies sind die Anmeldeinformationen, die Ihre Clients in ihren C-Zeilen hinterlegen.

B-Leitung zum Blockieren bestimmter Anbieter-IDs

 B: 1234 000000

B-Zeilen verhindern die Weitergabe einer bestimmten CAID/Anbieter-Kombination. Wenn Sie eine Karte mit mehreren Anbietern besitzen und einen Anbieter ausschließen möchten, gehen Sie wie folgt vor. Das Format ist B: CAID ProviderID .

Share-Limit und Hop-Anzahl: Kontrolle der Reshare-Tiefe

HOP COUNT steuert, wie oft eine Karte weiterverwendet werden kann, bevor CCcam die Weiterleitung beendet. Die Einstellung kann pro Benutzer in F-Zeilen oder global vorgenommen werden.

 SHARE LIMIT: 3

Ein Wert von 0 für die Anzahl der Hops bedeutet, dass die Karte lokal ist und nicht weiterverbreitet wird. Ein Wert von 1 bedeutet, dass sie an Clients weitergeleitet werden kann, diese Clients sie aber nicht weiterverbreiten können. Halten Sie diesen Wert so niedrig wie unbedingt nötig – lange Weiterleitungsketten verlangsamen die Reaktionszeiten des ECM und führen zu Problemen bei der Nachvollziehbarkeit.

LOG- und DEBUG-Anweisungen zur Fehlerbehebung

 LOGFILE: /var/log/cccam.log LOGLEVEL: 1 DEBUG: 0

LOGLEVEL 1 zeigt Verbindungsereignisse und ECM-Aktivitäten an, ohne die Festplatte zu überlasten. Setzen Sie DEBUG vorübergehend auf 1, wenn Sie ein bestimmtes Problem untersuchen – die Ausgabe ist sehr ausführlich und sollte anschließend wieder deaktiviert werden. Die Weboberfläche unter Port 16001 (Standard-Zugangsdaten: admin/admin – diese sollten Sie umgehend ändern) zeigt den aktuellen Kartenstatus, verbundene Clients und ECM-Zeiten an. Diese Informationen sind während der Diagnose deutlich übersichtlicher als Rohprotokolle.

Firewall, Netzwerk und Portweiterleitung für CCcam

Hier stößt die Installation eines CCCam-Servers unter Linux häufig an ihre Grenzen. Der Dienst läuft, die Konfiguration scheint korrekt zu sein, aber Clients können keine Verbindung herstellen. In neun von zehn Fällen liegt es an einer Firewall-Regel oder einem NAT-Problem.

Öffnen des TCP-Ports 12000 mit iptables und ufw

Direkte Verwendung von iptables:

 iptables -A INPUT -p tcp --dport 12000 -j ACCEPT # Save rules so they survive reboot: iptables-save > /etc/iptables/rules.v4

Oder falls Sie ufw verwenden:

 ufw allow 12000/tcp ufw reload

Wenn Sie den Zugriff auf bekannte Client-IPs beschränken möchten (deutlich bessere Vorgehensweise):

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

CCcam an eine bestimmte Schnittstelle binden, um die Exposition zu vermeiden

Wenn Ihr Server über eine öffentliche Schnittstelle (eth0) und eine VPN-Schnittstelle (wg0 oder tun0) verfügt, lassen Sie CCcam nicht auf beiden Schnittstellen lauschen. Fügen Sie die BIND-Direktive in CCcam.cfg mit der IP-Adresse der privaten/VPN-Schnittstelle hinzu. Clients verbinden sich über das VPN, und Port 12000 ist niemals öffentlich zugänglich. Dies ist die korrekte Vorgehensweise.

Verwendung eines VPN-Tunnels (WireGuard/OpenVPN) anstelle der öffentlichen Freigabe von Port 12000

WireGuard ist heutzutage die bessere Wahl – weniger Overhead als OpenVPN, einfachere Konfiguration und das Kernelmodul ist seit Linux 5.6 im Hauptzweig enthalten. 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 tragen Sie diese Adresse in die C-Zeilen auf Clientseite ein. Niemand, der das Internet scannt, wird jemals Port 12000 sehen.

NAT und Portweiterleitung, wenn sich der Server hinter einem Heimrouter befindet

Befindet sich Ihr Linux-Rechner in einem Heimnetzwerk, müssen Sie den TCP-Port 12000 Ihres Routers an die lokale IP-Adresse des Servers weiterleiten. Die meisten Router bezeichnen dies als „Portweiterleitung“ oder „virtuellen Server“. Stellen Sie den externen Port auf 12000, das Protokoll auf TCP und die interne IP-Adresse auf die LAN-Adresse Ihres Servers ein (statisch, entweder per DHCP-Reservierung oder manueller Konfiguration). Der interne Port ist ebenfalls 12000. Clients verwenden dann Ihre öffentliche IP-Adresse in ihren C-Lines.

Ein großes Problem: Wenn Ihr Internetanbieter CGNAT (Carrier-Grade NAT) verwendet, besitzen Sie keine eigene öffentliche IP-Adresse – Sie teilen sich eine mit Dutzenden anderer Kunden, und eingehende Verbindungen können nicht weitergeleitet werden. Die Lösung: Mieten Sie einen günstigen virtuellen Server (VPS), installieren Sie WireGuard darauf und tunneln Sie den CCcam-Datenverkehr darüber. Der VPS fungiert als öffentlicher Endpunkt; Ihr Heimserver kommuniziert über den Tunnel.

Dynamisches DNS für Server ohne statische IP-Adresse

Wenn sich Ihre öffentliche IP-Adresse ändert, können Clients, die Ihre alte IP-Adresse in ihren C-Zeilen verwenden, keine Verbindung herstellen. Nutzen Sie einen dynamischen DNS-Dienst und tragen Sie den Hostnamen (z. B. myserver.ddns.net ) anstelle der reinen IP-Adresse in die C-Zeilen ein. Führen Sie auf Ihrem Linux-Server einen DDNS-Update-Client wie ddclient aus, um den Eintrag aktuell zu halten. Die meisten Heimrouter verfügen über eine integrierte Funktion.

Außerdem: Wenn Ihr Internetanbieter eingehende TCP-Verbindungen auf Port 12000 blockiert (was bei manchen der Fall ist), ändern Sie SERVERPORT in einen weniger auffälligen Wert wie 15000 oder 8080, aktualisieren Sie die Portweiterleitungsregel Ihres Routers und passen Sie die C-Leitung jedes Clients entsprechend an.

Behebung häufiger CCcam-Serverprobleme unter Linux

Das Debuggen einer CCCam-Server-Linux-Installation folgt einem ziemlich einheitlichen Muster: Man eliminiert die einzelnen Ebenen nacheinander, beginnend mit der untersten (läuft der Prozess überhaupt?), über die Netzwerkfunktionen, dann die Konfiguration und schließlich die Kartenerkennung.

CCcam startet, aber Clients können keine Verbindung herstellen: Checkliste

• Prüfen Sie, ob der Prozess tatsächlich ausgeführt wird: systemctl status cccam
• Überprüfen Sie, ob es zuhört: ss -tlnp | grep 12000
• Testen Sie zunächst lokal: telnet 127.0.0.1 12000 – falls dies fehlschlägt, liegt das Problem beim Dienst und nicht im Netzwerk.
• Firewall prüfen: iptables -L -n | grep 12000
• Überprüfen Sie die F-Zeile: Benutzername und Passwort müssen exakt mit den Angaben übereinstimmen, die der Client in seiner C-Zeile verwendet.
• Prüfen Sie, ob die C-Leitungs-IP-Adresse/der Hostname des Clients vom Clientrechner aus korrekt aufgelöst wird.

„Keine Karte gefunden“ oder Karte nach Leserdefinition nicht erkannt

Führen Sie direkt nach dem Anschließen des Lesegeräts den dmesg | tail -30 aus. Sie sollten eine Zeile über ein neues USB-Gerät und den zugehörigen Geräteknoten sehen. Falls diese Zeile nicht angezeigt wird, wird das Lesegerät auf Kernel-Ebene nicht erkannt – dies könnte an einem Treiberproblem oder einem Hardwaredefekt liegen.

Wird das Lesegerät angezeigt, die Karte aber nicht erkannt, überprüfen Sie, ob die Zeile DEVICE in CCcam.cfg auf den in dmesg angezeigten Pfad verweist. Wichtig: /dev/ttyACM0 und /dev/ttyUSB0 sind unterschiedliche Geräte. Die Verwendung des falschen Geräts führt zu einem Fehler ohne Fehlermeldung. Prüfen Sie außerdem, ob der Benutzer des CCcam-Prozesses Lese- und Schreibrechte für das Gerät besitzt: ls -l /dev/ttyUSB0 Fügen Sie den CCcam-Benutzer gegebenenfalls der Gruppe dialout hinzu.

Falsche ECM-Antworten und Dekodierungsfehler (CAID-Fehlpaarung)

Der Client verbindet sich, er wird in der CCcam-Weboberfläche auf Port 16001 angezeigt, aber der Kanal wird nicht entschlüsselt. Fast immer liegt das an einer CAID-Abweichung. Öffnen Sie die Weboberfläche und prüfen Sie, welche CAIDs der Server tatsächlich angibt. Überprüfen Sie dann, welche CAID der Kanal verwendet – diese wird im Kanalinformationsbildschirm Ihrer Set-Top-Box oder im CAM-Menü angezeigt. Stimmen die CAIDs nicht überein, kann der Server dem Client unabhängig vom Verbindungsstatus nicht helfen.

Prüfen Sie auch HOP COUNT. Wenn die F-Leitung für diesen Client einen Reshare-Wert von 0 aufweist und die Karte von einer vorgelagerten C-Leitung (nicht lokal) empfangen wurde, erhält der Client keine Daten. HOP COUNT 0 verhindert die Weiterverteilung von nicht-lokalen Karten.

Hohe Last / Langsame ECM-Reaktionszeiten

Eine einzelne physische Karte kann jeweils nur eine ECM-Datei verarbeiten. Wenn zehn Clients gleichzeitig eine Entschlüsselung anfordern, kommt es zu einer Warteschlange und die Antwortzeiten verlängern sich. Der Kanal kann kurzzeitig instabil werden oder ausfallen. Abhilfe schaffen weniger Clients, zusätzliche physische Karten oder zusätzliche Upstream-C-Leitungen mit anderen Karten. Eine Softwarelösung gibt es nicht – es handelt sich um eine Hardware-Beschränkung.

Speicherort der Protokolldatei und wie man die CCcam-Debug-Ausgabe liest

Wenn in CCcam.cfg eine LOGFILE definiert ist, werden die Protokolle dort gespeichert. Andernfalls, unter systemd, verwenden Sie journalctl -u cccam -f für eine Live-Protokollierung. Achten Sie auf Zeilen mit den Einträgen „connected“, „ECM“, „card“ und Fehlercodes. Eine ECM-Antwort von „0x00“ bedeutet in der Regel, dass die Karte korrekt reagiert hat. Fehler wie „N/A“ oder Timeout-Meldungen weisen auf Probleme mit der Karte hin.

CCcam stürzt beim Start ab: Behebung eines Problems mit Binärinkompatibilität

Führen Sie zuerst file CCcam aus. Anschließend führen Sie ldd CCcam aus. Erscheint die Meldung „Keine dynamische ausführbare Datei“, ist die Binärdatei statisch gelinkt und sollte sofort lauffähig sein. Werden nicht aufgelöste Bibliotheken („Nicht gefunden“) angezeigt, installieren Sie die fehlenden 32-Bit-Pakete. Beendet CCcam sofort mit der Meldung „Ausführungsformatfehler“, liegt ein Architekturkonflikt vor – beispielsweise eine ARM-Binärdatei auf einem x86-System. Besorgen Sie sich die passende Binärdatei für Ihre Plattform.

CCcam vs. OScam als Linux-Server: Wann wechseln?

Wenn Sie heute neu anfangen, sollten Sie OScam unbedingt in Betracht ziehen. CCcam 2.3.0 ist veraltet – es gibt keine Patches, keine Updates und keinen Quellcode mehr, der überprüft werden könnte. OScam wird aktiv weiterentwickelt, ist Open Source (GPL) und bietet einen größeren Funktionsumfang als CCcam. Der einzige Grund, bei CCcam zu bleiben, besteht darin, dass Sie unbedingt die Kompatibilität des CCcam-Clients mit älteren Geräten benötigen, die das native Protokoll von OScam nicht unterstützen – aber selbst dann bietet OScam eine Lösung.

Wesentliche Unterschiede in der Architektur

CCcam ist eine Blackbox. Man installiert die Binärdatei, konfiguriert sie und hofft, dass sie funktioniert – es gibt keine Möglichkeit, die internen Abläufe einzusehen oder zu verändern. OScam hingegen ist vollständig Open Source, wird aktiv mit Patches für neue Kartentypen und Sicherheitslücken versorgt und bietet ein deutlich umfangreicheres Konfigurationsmodell mit Filterung pro Lesegerät und pro Benutzer in einer Granularität, die CCcam nicht erreicht. Auch die Weboberfläche von OScam ist wesentlich besser als die einfache Seite von CCcam auf Port 16001.

Überlegene CAID- und Provider-ID-Filterung von OScam

Mit OScam können Sie nach CAID, Provider-ID, Service-ID und sogar spezifischen ECM-PIDs filtern – alles unabhängig pro Lesegerät, Benutzer und Profil. Die Filterfunktionen von CCcam sind im Vergleich dazu grob. Wenn Sie eine Karte mit mehreren Provider-Paketen verwenden und genau kontrollieren müssen, worauf jeder Client zugreifen kann, ist OScam das richtige Werkzeug dafür.

OScam als CCcam-Protokollserver ausführen (cs378x / cs357x Listener)

OScam unterstützt das CCcam-Protokoll nativ. Das bedeutet, dass Ihre bestehenden CCcam-Clients ihre C-Leitungen überhaupt nicht ändern müssen – OScam antwortet auf Port 12000, und die Clients merken keinen Unterschied.

Fügen Sie in /etc/oscam/oscam.conf einen Listener-Block hinzu:

 [cs378x] port = 12000 key = 0102030405060708091011121314151617181920

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

Migrationspfad: Konvertierung von CCcam.cfg in OScam-Konfigurationsdateien

CCcam C-Zeilen werden zu Lesereinträgen in /etc/oscam/oscam.server :

 [reader] label = upstream1 protocol = cccam device = remote.host.example,12000 user = myusername password = mypassword caid = 1830 ident = 1830:000000

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

 [account] user = client1 pwd = strongpassword protocol = cccam group = 1 caid = 1830

Die Konvertierung ist zwar mechanisch, erfordert aber eine schrittweise Bearbeitung Zeile für Zeile. Es gibt kein automatisches Tool, das alle Sonderfälle zuverlässig abdeckt. Nehmen Sie sich eine Stunde Zeit und führen Sie die Konvertierung manuell durch – es lohnt sich für die langfristige Wartungsfreundlichkeit einer korrekten OScam-Konfiguration im Vergleich zu einer veralteten CCcam-Serverinstallation unter Linux.