Kein-Abonnement Satelliten-TV: CCcam& OScam Einrichtungsanleitung

Wenn Sie sich jemals gefragt haben, wie Menschen kein Abonnement Satelliten-TV auf ihren Dreambox oder VU+ Receivern betreiben, lautet die Antwort fast immer: zwei Softwareteile: CCcam und OScam. Diese Anleitung überspringt das Marketing und geht direkt zum eigentlichen Protokoll, den Konfigurationsdateien und den Fehlersuche-Schritten, die Sie benötigen. Gehen Sie davon aus, dass Sie bereits mit SSH und einem Texteditor vertraut sind — dies ist keine Hand-holding-Übung.

Wie Card Sharing tatsächlich funktioniert (CCcam vs OScam)

Das Kernkonzept ist einfacher, als die Fachbegriffe es erscheinen lassen. Eine Satellitenübertragung verschlüsselt ihren Stream mit einem schnell wechselnden Schlüssel — dem Steuerwort (CW). Um diesen Schlüssel zu erhalten, sendet Ihr Receiver eine ECM (Entitlement Control Message) an einen Server, der eine legitime Smartcard hält. Die Karte des Servers entschlüsselt die ECM, extrahiert das CW und sendet es zurück an Ihren Receiver. Ihr Receiver verwendet dieses CW, um das Video zu entschlüsseln.

Die andere Nachrichtenart, die Sie in Protokollen sehen werden, ist EMM — Entitlement Management Message. EMMs tragen das CW nicht direkt; sie werden verwendet, um die Berechtigungen auf der Karte selbst zu aktualisieren, indem sie den Zugang zu Kanälen hinzufügen oder entfernen. ECMs passieren ständig (alle paar Sekunden, während das CW rotiert). EMMs sind weniger häufig, sind aber wichtig, um das Abonnement der Karte aktuell zu halten.

Das Steuerwort und der Austausch von ECM/EMM erklärt

Ihr Receiver stimmt auf einen Kanal ein und erreicht die CA (Conditional Access) Schicht. Er kann es nicht selbst entschlüsseln, also leitet er die ECM an denjenigen weiter, der die Karte hat. Die Karte entschlüsselt sie und gibt das 8-Byte CW zurück. Der gesamte Rückweg muss in deutlich weniger als einer Sekunde erfolgen — die CW-Periode beträgt typischerweise 10 Sekunden, aber wenn Ihre ECM-Antwort zu lange dauert, erhalten Sie einen Freeze, bevor das neue CW ankommt.

Dieser Zyklus ist es, worum es bei der Überwachung der "ECM-Zeit" geht. Eine schnelle Karte in einem lokalen Netzwerk ist trivial. Eine Karte, die hinter drei Reshare-Hops mit einem langsamen Netzwerk dazwischen sitzt, ist der Punkt, an dem die Probleme beginnen.

Client-Server-Modell: was der Receiver anfordert

Der Receiver (oder die darauf laufende Softcam) fungiert rein als Client. Er weiß, dass er den Stream nicht selbst dekodieren kann, also verbindet er sich über TCP mit einem Sharing-Server. Er sendet die ECM, wartet auf das CW und entschlüsselt. Der Server erledigt die eigentliche Kartenarbeit. Deshalb ist Portweiterleitung ein serverseitiges Anliegen — der Client initiiert die Verbindung.

CCcam-Protokoll vs OScam-Protokoll vs newcamd

CCcam verwendet sein eigenes geschlossenes binäres Protokoll. Der Standardport ist 12000 (TCP). Es war jahrelang dominant, aber das Protokoll ist nicht dokumentiert und die letzte offizielle CCcam-Binärdatei stammt aus etwa 2012. Funktioniert immer noch, wird immer noch von Receivern weitgehend verstanden, aber es gab seit über einem Jahrzehnt keine aktive Entwicklung.

OScam ist Open-Source und implementiert mehrere Protokolle gleichzeitig auf verschiedenen Ports. Out of the box können Sie das cccam-Protokoll auf 12000 für die Kompatibilität mit Receivern, newcamd auf einem Port Ihrer Wahl (5000 ist üblich) und camd35, falls erforderlich, ausführen — alles von einer OScam-Instanz. Sie können auch physische Smartcard-Leser direkt darauf ausrichten.

Newcamd (Network Camd) ist ein älteres, aber immer noch verwendetes Protokoll mit seiner eigenen Verschlüsselungsschicht für den Handshake. Es ist langsamer einzurichten, wird aber von fast jedem Receiver unterstützt. Die meisten modernen Setups verwenden standardmäßig das cccam-Protokoll für Clients, da die Unterstützung durch Receiver universell ist.

Warum OScam CCcam für neue Setups weitgehend ersetzt hat

OScam liest physische Smartcards über interne oder externe Smartcard-Leser (USB oder seriell). Es hat eine Live-Weboberfläche zur Überwachung. Es wird aktiv gewartet mit Commits in 2025 und 2026. Und es behandelt die Protokollübersetzung — ein Client, der sich über das cccam-Protokoll verbindet, kann von einer Karte teilen, die OScam nativ liest. CCcam kann das nicht. Für einen neuen Serveraufbau gibt es keinen Grund, mit CCcam zu beginnen.

Einrichten eines OScam-Servers: Konfigurationsdateien und Struktur

Die Konfiguration von OScam ist auf mehrere Klartextdateien verteilt. Es sind keine binären Datenbanken oder GUIs erforderlich — nur Dateien, Berechtigungen und ein Neustart. Das Konfigurationsverzeichnis wird zur Compile-Zeit festgelegt, was das erste Problem ist, wenn Sie eine vorgefertigte Binärdatei aus einem Enigma2-Image ausführen.

Die Kernkonfigurationsdateien: oscam.conf, oscam.server, oscam.user

Drei Dateien bringen Sie zum Laufen.oscam.conf ist die Hauptkonfiguration — globale Einstellungen, Protokollports und die Weboberfläche.oscam.server definiert Ihre Leser (entweder physische Karten oder upstream Sharing-Verbindungen).oscam.user definiert, wer sich als Client verbinden kann. Zusätzliche optionale Dateien wieoscam.services undoscam.provid ermöglichen es Ihnen, nach Anbieter/Kanal zu filtern, aber Sie benötigen sie nicht, um zu starten.

Wo Konfigurationen leben (/etc/tuxbox/config oder /usr/keys)

Das hängt ganz vom Build ab. Auf den meisten Enigma2-Images (OpenPLi, OpenATV) verwendet OScam, das für dieses Image kompiliert wurde,/etc/tuxbox/config/. Auf einigen Images ist es/var/keys/. Wenn OScam nach der Installation stillschweigend nicht startet, ist das fast immer der Grund — die Binärdatei sucht ihre Dateien in einem Pfad und Sie haben sie in einem anderen abgelegt.

Finde den richtigen Pfad mit:oscam --help 2>&1 | grep config oder überprüfe das Startskript in/etc/init.d/oscam. Du kannst auch beim Start überschreiben:oscam -b -c /etc/tuxbox/config. Sobald du den richtigen Pfad kennst, lege alle deine Konfigurationsdateien dort ab.

Einen Reader in oscam.server definieren

Hier ist ein minimaler Reader-Block für eine physische Smartcard in einem internen Slot:

[reader]

DieGruppennummer ist entscheidend — sie muss mit derGruppe im entsprechendenoscam.userKonto übereinstimmen, sonst findet keine Share-Routing statt. Viele Leute richten Reader und Konten ein, sehen keine Fehler und erhalten trotzdem "keine Karte", weil die Gruppennummern nicht übereinstimmen. Überprüfe dies zuerst.

Für einen externen USB-Smartcard-Reader, tauschedevice = /dev/sci0 gegendevice = /dev/ttyUSB0 und passe mhz typischerweise auf 368 an.

Client-Konten in oscam.user erstellen

Jeder Client erhält einen Konto-Block:

[account]

au = 1 aktiviert die EMM-Weiterleitung für diesen Client (lässt die Karte aktualisieren).monlevel = 0 verbirgt dieses Konto aus der aktiven Clientliste der Weboberfläche — nützlich für die Privatsphäre. Füge so viele[account] Blöcke hinzu, wie du benötigst, einen pro Client.

Die Weboberfläche aktivieren (httpport)

Füge dies zuoscam.conf unter einem[webif] Block hinzu:

[global]

Wennhttpallowed ist nicht gesetzt oder ist an 127.0.0.1 gebunden, Sie erreichen die Weboberfläche nur von localhost — nicht von Ihrem LAN. Das ist ein häufiger Grund, warum die Benutzeroberfläche unerreichbar erscheint, obwohl OScam einwandfrei läuft.

Einen Client-Receiver mit einem Sharing-Server verbinden

Ihr Receiver muss wissen, wo er nach der Entschlüsselung fragen soll. Wenn Sie ein Softcam verwenden, das CCcam.cfg liest, ist dies eine Einzeile. Wenn Sie OScam auch auf der Client-Seite ausführen, ist es ein Reader-Block.

CCcam.cfg Client-Zeilenformat (C: Zeile)

Öffnen Sie/etc/CCcam.cfg auf Ihrem Receiver und fügen Sie eine C: Zeile hinzu:

C: hostname.example.com 12000 myusername mypassword

Das war's. Die Felder sind: C: (wörtlich), Hostname oder IP, Port, Benutzername, Passwort — durch Leerzeichen getrennt. Keine Anführungszeichen. Eine Zeile pro Server. CCcam-Clients versuchen, die Verbindungen in der Reihenfolge herzustellen, wenn Sie mehrere Zeilen haben; der erste funktionierende Server gewinnt.

Beachten Sie, dass das Softcam auf Ihrem Receiver laufen muss, damit dies funktioniert. Auf Enigma2 starten Sie es über den Softcam-Manager im Menü oder über/etc/init.d/softcam start.

OScam-Client über camd35 oder cccam-Reader

Wenn Sie OScam auf dem Client-Receiver ausführen (was Vorteile für Überwachung und Filterung hat), fügen Sie einen Reader zuoscam.serverdes Clients hinzu:

[reader]

Dies sagt OScam, dass es sich outbound mit dem Server über das cccam-Protokoll verbinden soll. Es erscheint als Reader in der Weboberfläche, genau wie eine physische Karte, was die Diagnose erheblich erleichtert.

Port-, Hostname-, Benutzername-, Passwortfelder

Hostname kann eine IP oder eine Domain sein. Wenn der Server hinter einer dynamischen IP steht und einen DDNS-Hostname verwendet, stellen Sie sicher, dass die Domain von Ihrem Netzwerk aus korrekt aufgelöst wird. Port 12000 ist der Standard-CCcam-Port, aber Server können jeden Port verwenden — bestätigen Sie den tatsächlichen Port, bevor Sie davon ausgehen, dass es 12000 ist.

Anmeldeinformationen sind groß- und kleinschreibungssensitiv. Kopieren Sie sie, anstatt sie neu einzugeben, um Tippfehler zu vermeiden. Ein falsches Passwort führt zu einer Verbindung, die sich authentifiziert und sofort abbricht — Sie sehen "abgelehnt" im OScam-Log des Servers.

Die Verbindung testen und die ECM-Zeit lesen

Öffnen Sie die OScam-Weboberfläche auf Ihrem Client oder Server unterhttp://ip-address:8888. Gehen Sie zum Abschnitt Readers. Ein funktionierender Reader zeigt den Status "verbunden" und Sie werden sehen, dass die ECM-Zählungen steigen, wenn Sie auf einen verschlüsselten Kanal umschalten.

Die ECM-Zeit wird pro Reader angezeigt. Unter 200 ms ist ausgezeichnet. Unter 400 ms ist für den täglichen Gebrauch in Ordnung. Über 1000 ms sehen Sie sichtbare Kanalstörungen. Wenn der Reader "aus" oder "Fehler" anzeigt, anstatt "verbunden", liegt das Problem bei den Anmeldeinformationen, Host/Port oder der Firewall — arbeiten Sie diese in dieser Reihenfolge ab.

Fehlerbehebung bei häufigen Card-Sharing-Problemen

Die meisten Probleme fallen in eine kleine Anzahl von Kategorien. So diagnostizieren Sie sie tatsächlich, anstatt nur Dinge neu zu starten und zu hoffen.

Kanalstörungen und hohe ECM-Zeiten

Wenn das Video alle 10 Sekunden oder so einfriert, kommt das CW nicht rechtzeitig an. Überprüfen Sie die ECM-Zeiten in der OScam-Weboberfläche für den relevanten Reader. Alles, was konstant über 800 ms liegt, ist ein Problem, das darauf wartet, zu passieren; über 1000 ms werden Störungen regelmäßig.

Ursachen: zu viele Reshare-Hops zwischen der Quellkarte und Ihrem Receiver, geografische Distanz und Latenz oder ein überlasteter Server zu Spitzenzeiten. Die Hop-Anzahl ist in der OScam-Weboberfläche sichtbar — ein Hop 1 Share bedeutet, dass der Server, mit dem Sie verbunden sind, die Karte direkt hält. Hop 3+ bedeutet, dass Sie mindestens drei Server von der Karte entfernt sind, und die Latenz summiert sich bei jedem Schritt.

Überprüfen Sie auch den Paketverlust zwischen Ihnen und dem Server. Eine Paketverlustquote von 5 % zerstört die ECM-Zuverlässigkeit, da die Anfrage oder Antwort verloren geht und erneut versucht werden muss.

'Reader nicht verbunden'-Fehler

Dies ist fast immer eines von drei Dingen: falscher Hostname oder Port, falsche Anmeldeinformationen oder eine Firewall, die die Verbindung blockiert. Testen Sie die Port-Erreichbarkeit von Ihrem Receiver aus mitnc -zv hostname 12000 oder von einem PC im selben LAN. Wenn der Port nicht antwortet, liegt das Problem auf der Serverseite — entweder läuft OScam nicht mit seinem cccam-Listener oder der Port ist blockiert.

Bestätigen Sie auf dem Server, dass der cccam-Listener aktiv ist, indem Sienetstat -tlnp | grep 12000 überprüfen. Wenn OScam läuft, der Port aber nicht aufgeführt ist, ist der[cccam] blockieren inoscam.conf könnte fehlen oder der Port könnte 0 (deaktiviert) sein.

Falsches Konfigurationsverzeichnis / OScam startet nicht

Führen Sie OScam manuell im Vordergrund mit ausführlichem Logging aus, um zu sehen, was es tut:oscam -b -c /etc/tuxbox/config -l /tmp/oscam_debug.log. Wenn es sofort ohne Protokollausgabe beendet wird, ist der Konfigurationspfad falsch und es schlägt stillschweigend fehl, bevor das Logging beginnt.

Dateiberechtigungen sind ebenfalls wichtig. Konfigurationsdateien sollten für den Benutzer des OScam-Prozesses lesbar sein.chmod 644 /etc/tuxbox/config/oscam.* undchown oscam:oscam (oder welcher Benutzer auch immer OScam ausführt) löst Berechtigungsprobleme. Überprüfen Sie mitls -la /etc/tuxbox/config/.

Außerdem: der[global] Abschnitt inoscam.conf muss vorhanden sein. Eine leere oder fehlerhafteoscam.conf führt dazu, dass OScam ohne nützlichen Fehler beendet wird.

Firewall- und NAT-Portweiterleitungsprobleme

Wenn Sie den Server hinter einem Heimrouter betreiben, müssen Sie den TCP-Port 12000 (und 8888, wenn Sie remote Webzugriff wünschen) an die interne IP des Servers weiterleiten. Der häufigste Fehler besteht darin, an die falsche LAN-IP weiterzuleiten, insbesondere wenn sich die DHCP-Lease des Servers ändert. Setzen Sie zuerst eine statische LAN-IP für die Servermaschine.

Double-NAT-Setups — bei denen Ihr ISP Ihnen eine Carrier-Grade-NAT-Adresse vor Ihrem Heimrouter gibt — sind wirklich problematisch. Die Portweiterleitung über Ihren Heimrouter funktioniert in Ihrem LAN, aber die öffentliche IP, mit der sich Ihre Clients verbinden, ist nicht erreichbar, da die NAT-Schicht des ISP sie blockiert. In dieser Situation ist ein VPN-Tunnel oder ein VPS-basierter Reverse-Proxy (wie ein WireGuard- oder SSH-Tunnel zu einem VPS mit einer echten öffentlichen IP) die einzige saubere Lösung.

Testen Sie die Port-Erreichbarkeit von außerhalb Ihres Netzwerks mit einem Tool wie canyouseeme.org oder indem Sie sich per SSH mit einem VPS verbinden und von dort aus netcat ausführen. Wenn der Port von außen nicht erreichbar ist, wird sich kein Client verbinden, egal wie korrekt die Anmeldeinformationen sind.

Lesen des OScam-Protokolls für ECM-Abweisungen

Aktivieren Sie das ausführliche Logging inoscam.conf:

[global]

Beobachten Sie das Protokoll live mittail -f /tmp/oscam.log. Wichtige Einträge, auf die Sie achten sollten:

• ECM abgelehnt — die Karte weigerte sich, dieses ECM zu entschlüsseln. Bedeutet normalerweise, dass das Abonnement der Karte diesen Anbieter nicht abdeckt oder die Karte abgelaufen ist.
• keine Karte — OScam fand keinen Leser, der dieses ECM verarbeiten kann. Fast immer ein Gruppenummer-Mismatch zwischen Leser und Benutzerkonto.
• Client getrennt — normal, aber wenn es sofort nach der Verbindung passiert, sind die Anmeldeinformationen falsch.
• Reader neu starten — der Reader ist abgestürzt und OScam versucht es erneut. Wenn dies alle 30 Sekunden wiederholt wird, verweigert der upstream Server die Verbindung.

Zeit-Synchronisierungsprobleme sind eine weitere Ursache für ECM-Ablehnungen, die ignoriert werden. Wenn Ihr STB neu gestartet wurde und die Systemuhr falsch ist (sagen wir, um Stunden abweicht, weil NTP noch nicht synchronisiert ist), lehnen einige CA-Systeme ECMs basierend auf Zeitstempelprüfungen ab. Erzwingen Sie eine NTP-Synchronisation nach dem Neustart:ntpdate pool.ntp.org oder aktivieren Sie den System-NTP-Dienst dauerhaft.

Wie man eine Sharing-Quelle bewertet (Allgemeine Kriterien)

Wenn Sie sich mit einer externen Quelle verbinden, anstatt Ihre eigene Karte lokal zu lesen, bewerten Sie im Wesentlichen einen Remote-Card-Reader. Die Kriterien sind technisch, nicht marketingorientiert.

Uptime- und Serverstabilitätsindikatoren

Eine zuverlässige Quelle sollte in der Lage sein, Ihnen Uptime-Statistiken zu zeigen oder zumindest eine Erfolgsbilanz zu haben, die Sie überprüfen können — durch Foren, Benutzerberichte oder das Testen einer Testlinie für ein paar Tage während der Hauptzeiten (Abende, Wochenenden). Ein Dienst, der um 3 Uhr morgens gut aussieht, aber um 20 Uhr, wenn alle zuschauen, stockt, ist ein bekanntes Muster bei überverkauften Setups.

Fragen Sie, ob sie eine Statusseite oder Überwachung betreiben. Betreiber, die Uptime ernst nehmen, haben normalerweise eine. Diejenigen, die das nicht tun, sind ein Warnsignal.

Lokale Karte vs. Reshare — warum es wichtig ist

Eine Hop-1-Quelle bedeutet, dass der Server, mit dem Sie sich verbinden, die Smartcard physisch hält. Eine Hop-2-Quelle bedeutet, dass Ihr Server sich mit einem anderen Server verbindet, der die Karte hält. Jeder Hop fügt Latenz und einen potenziellen Fehlerpunkt hinzu. Eine Reshare-Kette von 3 oder mehr Hops ist problematisch — Sie sind drei Server von der tatsächlichen Karte entfernt, und wenn einer dieser Links ausfällt, bricht Ihre Verbindung ab.

Dies ist eine Sache, die die meisten Setups, die kein Abonnement-Satellitenfernsehen erklären, nicht klar erläutern: Die Hop-Anzahl beeinflusst direkt die Zuverlässigkeit, unabhängig von der Servergeschwindigkeit. Ein schnelles 3-Hop-Setup ist oft schlechter als ein leicht langsameres 1-Hop-Setup.

Latenz, Hops und geografische Nähe

Für eine 10 ms ECM-Antwort muss die Karte geografisch in der Nähe sein. Ein Server im selben Land wie Sie, der eine Karte ohne Reshares betreibt, kann ECM-Zeiten an guten Tagen unter 100 ms liefern. Ein Server auf einem anderen Kontinent fügt 80-150 ms Basiskreis-Latenz hinzu, bevor die Karte überhaupt ihre Arbeit verrichtet.

Fragen Sie bei der Bewertung, wo sich die Server physisch befinden. Wenn sie das nicht beantworten können oder wollen, wird Ihnen die Latenz, die Sie in den ECM-Zeiten sehen, sowieso sagen — führen Sie eine Verbindung für eine Stunde aus und beobachten Sie die OScam-Reader-Statistiken. Konsistente 300 ms ECM-Zeiten sind in Ordnung. Spitzenwerte von 900 ms alle paar Minuten bedeuten, dass der Pfad instabil ist.

Warnsignale, die auf ein unzuverlässiges Setup hinweisen

Einige Dinge, die Sie zum Nachdenken bringen sollten, bevor Sie sich festlegen:

• Keine Testphase angeboten — Sie werden gebeten zu zahlen, ohne eine Möglichkeit zu haben, die Stabilität zu testen
• Versprechen von "unbegrenzten Linien" oder "garantierter Uptime" ohne Einzelheiten — diese sind bedeutungslos ohne ein SLA dahinter
• ECM-Zeiten, die von Tag zu Tag stark variieren — deutet darauf hin, dass der Server über mehrere Anbieter hinweg reshared wird, ohne Kapazitätsmanagement
• Support, der tagelang still bleibt — wenn Sie bei der Bewertung keine Antwort erhalten können, erwarten Sie nicht, dass es besser wird, wenn etwas kaputt geht
• Nur eine Server-IP — keine Redundanz bedeutet, wenn diese Maschine ausfällt, haben Sie nichts

Das in diesem Leitfaden beschriebene Setup gibt Ihnen die Werkzeuge, um all dies selbst zu bewerten. Sobald OScam auf Ihrem Receiver läuft, haben Sie eine Echtzeit-ECM-Überwachung und Reader-Statistiken. Nutzen Sie sie — sie sind zuverlässiger als jede Marketingbehauptung über kein Abonnement-Satellitenfernsehen.