Satellite-TV-Receiver-Anleitung 2026: CCcam & OScam-Einrichtung

Diese Satellite-TV-Receiver-Anleitung 2026 behandelt das, was Sie wirklich wissen müssen, bevor Sie eine Konfigurationsdatei anfassen — Hardware-Kompatibilität, Konfigurationspfade, Protokollunterschiede und wie Sie Fehler diagnostizieren, wenn etwas schiefgeht. Unabhängig davon, ob Sie eine neue Box bewerten oder versuchen, eine vorhandene Einrichtung ordnungsgemäß zum Laufen zu bringen, basieren die technischen Details hier auf echten Enigma2-Bereitstellungen, nicht auf Marketingkopien.

CCcam und OScam sind nicht sofort einsatzbereit. Ihre Receiver-Hardware, das Firmware-Image und die binäre Architektur müssen alle übereinstimmen. Wenn Sie einen dieser Punkte falsch verstehen, werden Sie Stunden damit verbringen, etwas zu debuggen, das 20 Minuten hätte dauern sollen.

Was einen Receiver im Jahr 2026 CCcam/OScam-kompatibel macht

Die kurze Antwort: Wenn Ihr Receiver nicht unter Linux läuft, werden Sie eine schwere Zeit haben. CCcam und OScam sind Linux-Binärdateien. Sie hängen von Linux-Systemaufrufen, Dateipfaden und Geräte-Schnittstellen ab, die auf proprietärer geschlossener Firmware einfach nicht vorhanden sind — unabhängig davon, was die Box-Spezifikationen auf der Verpackung sagen.

Linux-basierte Firmware: die nicht verhandelbare Grundlinie

CCcam und OScam benötigen einen echten Linux-Userspace — procfs, /dev-Baum, beschreibbares Dateisystem und die Möglichkeit, Binärdateien auszuführen. Budget-Receiver mit proprietärem Android-abgeleitetem oder vollständig geschlossenem Firmware können diese Prozesse nicht nativ hosten. Sie müssten zuerst ein Third-Party-Image flashen, und nicht jeder Chipsatz unterstützt das.

Enigma2-basierte Images wie OpenATV, OpenPLi und OpenVix bieten dir sofort eine richtige Linux-Umgebung. Diese Images werden mit Paketmanagern, SSH-Zugriff und der richtigen Verzeichnisstruktur (/etc/, /tmp/, /var/log/) geliefert, die CCcam und OScam erwarten.

Enigma2 vs proprietäres OS: Schlüsseldifferenzen für Card-Sharing

Proprietäre Firmware-Receiver — besonders billigere Marken, die unter verschiedenen Hausmarken verkauft werden — sperren das Betriebssystem. Kein SSH, kein beschreibbares /etc, keine Möglichkeit, eine benutzerdefinierte Binärdatei abzulegen und sie beim Start ausführen zu lassen. Einige wurden mit Community-Firmware geknackt, einige nicht. Enigma2 hingegen ist Open Source und wurde entwickelt, um Plugin-Binärdateien und Softcam-Clients zu akzeptieren.

Der funktionale Unterschied ist sofort wichtig: Bei Enigma2 können Sie CCcam über ein .ipk-Paket installieren oder die Binärdatei manuell ablegen, sie in /etc/CCcam.cfg konfigurieren und mit einem Init-Skript starten. Bei proprietärer Firmware existiert dieser Pfad nicht.

Hardware-Architekturen: MIPS, ARM und Emulationsunterstützung

Ältere Satellitenreceiver — Dreambox DM800, verschiedene Clone-Boxen — verwenden MIPS-Prozessoren. Die meiste Hardware von 2020 an verwendet ARM (typischerweise ARMv7 oder AArch64). Der Unterschied ist wichtig, da CCcam- und OScam-Binärdateien pro Architektur kompiliert werden. Eine MIPS-Binärdatei wird auf einem ARM-Receiver nicht ausgeführt und umgekehrt.

Chipsatz-Familien, die es lohnt zu kennen: Broadcom BCM7xxx-Serie (solide Treiberunterstützung, häufig in Dreamb

ox und Vu+ Hardware), HiSilicon Hi35xx (in Zgemma-Boxen zu finden, gute Enigma2-Unterstützung) und Amlogic S905/S922 (häufig in Android-Hybrid-Boxen, Enigma2-Unterstützung ist bildabhängig). Alle drei unterstützen CCcam/OScam, wenn sie mit einem korrekten Enigma2-Image gekoppelt sind.

Interner Kartenleser vs. reine Netzwerk-Client-Modi

Wenn Sie eine physische Smartcard lokal hosten möchten, benötigt Ihr Receiver einen internen Kartenleser, der als /dev/sci0 (oder /dev/sci1 für einen zweiten Slot) verfügbar gemacht wird. OScam benötigt diesen Gerätepfad zum Lesen der Karte. Wenn er nicht vorhanden ist, wird sich der Leser nicht initialisieren, unabhängig davon, wie Sie oscam.server konfigurieren.

USB-verbundene externe Kartenleser werden als /dev/ttyUSB0 oder ähnlich angezeigt. Diese benötigen geladene Kernel-Module, bevor OScam sie sehen kann — normalerweise cp210x für Silicon Labs-Adapter oder pl2303 für Prolific-Chips. Laden Sie diese mit modprobe cp210x und überprüfen Sie mit dmesg | tail.

Der reine Client-Modus (keine physische Karte, reiner Netzwerk-Client) ist einfacher — Sie benötigen nur die ausführbare Datei und einen funktionierenden Netzwerk-Stack, um Ihren Remote-Server zu erreichen. Kein /dev/sci0 erforderlich.

Überprüfung des Chipsets Ihres Receivers anhand bekannter Listen

Überprüfen Sie vor dem Kauf die Hardware-Kompatibilitätsseiten von OpenPLi oder OpenATV — sie listen unterstützte Chipsets und Bildverfügbarkeit auf. Wenn sich Ihre Box nicht auf einer der beiden Listen befindet, spielen Sie mit dem Feuer. Die Community-Foren für Vu+, Dreambox und Zgemma sind auch zuverlässig, um zu bestätigen, welche Enigma2-Images für ein bestimmtes Modell aktiv gepflegt werden.

Führen Sie uname -m über SSH aus, um die Architektur nach dem Flashen zu bestätigen. Sie erhalten mipsel, armv7l oder aarch64 — stimmen Sie genau damit überein, wenn Sie Binärdateien herunterladen.

Installation und Konfiguration von CCcam auf Enigma2-Receivern

CCcam ist älter als OScam und strukturell einfacher. Seine Konfiguration ist eine einzelne Datei, seine Log-Ausgabe ist lesbar und es ist gut verstanden. Für reine Client-Setups, die eine Verbindung zu einem Remote-Server herstellen, funktioniert es 2026 immer noch einwandfrei, solange der Server das CCcam-2.3.x-Protokoll unterstützt.

Erhalten der korrekten CCcam-Binärdatei für Ihre Architektur

CCcam-Binärdateien sind kompiliert für MIPS (mipsel), ARMv7 (arm) und AArch64 verfügbar. Überprüfen Sie immer mit file CCcam nach dem Herunterladen — es zeigt Ihnen die ELF-Architektur. Vergleichen Sie mit der uname -m-Ausgabe auf Ihrem Receiver. Das Ausführen der falschen Datei erzeugt sofort einen Exec format error, was leicht zu diagnostizieren ist, aber Zeit kostet, wenn Sie nicht wissen, worauf Sie achten müssen.

Platzieren Sie die Binärdatei unter /usr/bin/CCcam und machen Sie sie ausführbar: chmod 755 /usr/bin/CCcam. Einige Enigma2-Softcam-Manager erwarten sie speziell dort.

Konfigurationsdatei-Speicherort: /etc/CCcam.cfg Zeile für Zeile erklärt

Die Hauptkonfiguration befindet sich unter /etc/CCcam.cfg. Eine minimale Arbeitskonfiguration für ein reines Client-Setup sieht folgendermaßen aus:

```html

# CCcam-Clientkonfiguration
C: server.example.com 12000 myuser mypass yes
RESHARE = 0
MINIMIZE RESSOURCES = yes
NEWCAMD STANDARD = yes
LOG FILE = /tmp/CCcam.log
LOG LEVEL = 5

Das ist die gesamte Datei für einen einfachen Client. Alles andere ist optional oder nur erforderlich, wenn Sie Downstream-Clients versorgen.

C-line und F-line Syntax: Was jedes Feld bedeutet

Eine C-line verbindet Ihren Receiver mit einem Remote-CCcam-Server. Das Format:

C: <hostname> <port> <username> <password> <wantEMM> [caid:provid,...]

Aufschlüsselung mit einem echten Beispiel:

C: server.example.com 12000 myuser mypass yes 1830:000000

• server.example.com — Remote-Server-Hostname oder IP-Adresse
• 12000 — Standard-CCcam-TCP-Port
• myuser / mypass — vom Server bereitgestellte Anmeldedaten
• yes — EMM-Weiterleitung anfordern (erforderlich für Kartenerneuerung)
• 1830:000000 — optionaler CAID- und Provider-ID-Filter; leer lassen, um alle verfügbaren CAIDs anzufordern

Eine F-line definiert einen lokalen Client, dem Sie dienen — für die Weiterleitung an ein anderes Gerät in Ihrem LAN:

F: peeruser peerpass 1 0 0 0

Die Felder nach den Anmeldedaten sind Weiterleitungsebene, EMM-Freigabe-Flags und AU-Einstellungen. Bei einem typischen Home-Setup benötigen Sie wahrscheinlich gar keine F-lines.

CAID, Provider-ID und Weiterleitungslimits festlegen

RESHARE = 0 verhindert, dass Ihr Receiver Karten Downstream weiterleitet. Setzen Sie dies, es sei denn, Sie haben einen bestimmten Grund zum Weitergeben — es reduziert die Last und vermeidet Protokollmissbrauch durch Fehlkonfigurationen. CAID-Werte (wie 0604 für Irdeto, 1830 für Nagravision, 0B00 für Conax) teilen CCcam mit, welche Verschlüsselungssysteme angefordert werden sollen. Wenn in der C-line leer gelassen, wird der Server alles freigeben, auf das er Zugriff hat.

Debug-Logging aktivieren: /tmp/CCcam.log und Log-Level-Flags

LOG LEVEL = 5 gibt ausführliche Ausgabe. Verfolgen Sie es in Echtzeit:

tail -f /tmp/CCcam.log

Level 1 ist nur Fehler. Level 5 umfasst ECM-Anforderungen, Antworten, Timing und Verbindungsereignisse. Verwenden Sie Level 5 zur Diagnose, reduzieren Sie auf Level 1 für den normalen Betrieb, um zu vermeiden, dass /tmp vollläuft.

CCcam als Service starten: init.d vs systemd auf modernen Images

Die meisten aktuellen Enigma2-Images verwenden immer noch SysVinit. Ihr Init-Skript befindet sich unter /etc/init.d/CCcam. Ein einfaches:

#!/bin/sh
case "$1" in start) /usr/bin/CCcam & ;; stop) killall CCcam ;;
esac

Hinweis: Enigma2-Images werden oft mit einem Softcam-Manager-Plugin ausgeliefert. Wenn Sie es zum Starten von CCcam verwenden, starten Sie CCcam nicht auch manuell — beide Instanzen versuchen, Port 12000 zu binden, und eine schlägt stillschweigend fehl. Überprüfen Sie mit ps aux | grep CCcam, ob nur eine Instanz ausgeführt wird.

Einige neuere

```r Images (OpenATV 7.x, späte OpenPLi-Builds) haben sich dem Systemd zugewandt. Platzieren Sie eine Unit-Datei unter /etc/systemd/system/CCcam.service und aktivieren Sie diese mit systemctl enable CCcam.

Auch: Falls Ihr Receiver Busybox sh anstelle von Bash ausführt, werden Init-Skripte mit Bash-spezifischer Syntax ([[, $((...)), usw.) stillschweigend fehlschlagen. Schreiben Sie POSIX-kompatible Skripte, sonst fragen Sie sich, warum CCcam beim Neustart nie startet.

OScam-Konfiguration für Satellitenempfänger: Server- und Client-Modi

OScam ist in jeder messbaren Hinsicht fähiger als CCcam — besseres Logging, Kontrollen pro Benutzer, Kanalfilterung, Unterstützung mehrerer Protokolle. Der Kompromiss besteht in mehr Konfigurationsdateien und mehr Stellen, wo etwas schiefgehen kann. Verbringen Sie eine Stunde damit, die Struktur einmal zu verstehen, und es zahlt sich aus.

OScam-Konfigurationsdateistruktur: oscam.conf, oscam.server, oscam.user, oscam.services

Konfigurationsdateien befinden sich unter /etc/oscam/ auf den meisten Enigma2-Images. Einige benutzerdefinierte Builds verwenden /usr/local/etc/oscam/. Falls Sie sich nicht sicher sind: find / -name oscam.conf 2>/dev/null.

Die vier Dateien, die Sie immer benötigen:

• oscam.conf — globale Einstellungen, Port-Bindungen, Webif, Logging
• oscam.server — Reader-Definitionen (Remote-Server oder lokale Kartenleser)
• oscam.user — Konten für Clients, die sich mit Ihrer OScam-Instanz verbinden
• oscam.services — Kanal- und CAID-Filterungsregeln

Einrichten des Newcamd-Readers in oscam.server

Ein Reader-Block, der sich mit einem Remote-Newcamd-Server verbindet:

[reader]
label = myserver
protocol = newcamd
device = server.example.com:10000
key = 0102030405060708091011121314
user = myuser
password = mypass
caid = 1830
ident = 1830:000000
group = 1
emmcache = 1

Das Feld key ist der 14-Byte-NM_key, der in Newcamds DES-Handshake verwendet wird. Der oben angegebene Standardwert (0102030405060708091011121314) ist das, was die meisten Server verwenden — Ihr Anbieter wird angeben, falls er anders ist. Falls der Schlüssel falsch ist, protokolliert OScam login incorrect und der Reader bleibt offline.

oscam.conf globaler Abschnitt: Logfile, Port-Bindungen und Webif

[global]
logfile = /var/log/oscam/oscam.log
maxlogsize = 500
nice = -1
[webif]
httpport = 8888
httpuser = admin
httppwd = changeme
httprefresh = 10
[newcamd]
port = 10000@1830:000000
[cs378x]
port = 9000

Die [newcamd] Port-Bindung 10000@1830:000000 teilt OScam mit, dass es auf TCP-Port 10000 für Newcamd-Clients lauschen soll, die CAID 1830 Provider 000000 anfordern. Der Abschnitt [cs378x] aktiviert die CCcam-Protokollkompatibilität — mehr dazu weiter unten.

Vorsicht: wenn dein Dreambox oder ein ähnliches Gerät seine eigene Weboberfläche auf Port 8888 ausführt, wird die Weboberfläche von OScam nicht gebunden werden können. Ändere in diesem Fall httpport auf etwas wie 8080 oder 8889.

oscam.user: Definieren von Clients mit au-, caid- und ident-Filtern

[account]
user = localclient
pwd = clientpass
group = 1
caid = 1830
ident = 1830:000000
au = 1

au = 1 ermöglicht die EMM-Weiterleitung (Entitlement Management Message) für diesen Benutzer. EMM-Nachrichten sind die Art und Weise, wie der Kartenanbieter Schlüsselerneuerungen an die Karte übermittelt – ohne diese kann eine physische Karte nach Ablauf des aktuellen Schlüssels nicht mehr funktionieren. Wenn du den Client-Only-Modus ohne lokale Karte ausführst, ist au irrelevant.

oscam.services: Einschränkung des Kanalzugriffs nach SID und CAID

Mit dieser Datei kannst du bestimmte Service-IDs (Kanalkennung) auf die Whitelist oder Blacklist setzen. Ein einfacher Block zum Zulassen aller:

[services]
label = allowed
caid = 1830
sids = 

Lass sids leer, um alle SIDs für die CAID zuzulassen. Fülle es mit spezifischen SID-Werten, wenn du den Zugriff auf bestimmte Kanäle einschränken möchtest – nützlich für Multi-User-Setups, in denen verschiedene Konten unterschiedliche Kanalpakete sehen sollten.

Verwende OScam-Weboberfläche auf Port 8888 zur Überwachung des Kartenstatus

Nach dem Starten von OScam navigiere zu http://<receiver-ip>:8888. Die Weboberfläche zeigt den Reader-Status, ECM-Antwortzeiten, aktive Verbindungen und Live-Log-Ausgabe an. Es ist die schnellste Möglichkeit, um zu bestätigen, dass ein Reader online ist und dekodiert. ECM-Antwortzeiten über 600ms in der Weboberfläche deuten auf serverseitige Latenz oder Schlüsselwechselverzögerung hin – dies ist gelegentlich zu erwarten, aber chronische Werte darüber bedeuten, dass etwas mit dem Server oder dem Netzwerkpfad nicht stimmt.

OScam als CCcam-Protokoll-Bridge: cs378x vs. newcamd-Listener

Das ist etwas, das die meisten Leitfäden vollständig übersehen. OScam kann das CCcam-Protokoll nativ über das cs378x-Modul sprechen. Aktiviere [cs378x] in oscam.conf mit einem Port (z. B. 9000) und OScam wird CCcam-Clients auf diesem Port akzeptieren, während es intern newcamd oder ein anderes Reader-Protokoll verwendet, um Schlüssel abzurufen. Du musst dich nicht zwischen CCcam und OScam entscheiden – OScam kann beide gleichzeitig bedienen.

Ein Fallstrick: OScam muss mit SSL-Unterstützung kompiliert werden, damit cs378x TLS-Verbindungen funktionieren. Überprüfe deine Build-Flags: oscam --build. Wenn du SSL: no in der Ausgabe siehst, schlagen cs378x-Verbindungen mit erforderlichem TLS stillschweigend ohne eine hilfreiche Fehlermeldung fehl. Du brauchst einen Build, der mit --enable-ssl kompiliert wurde.

Bewertung eines Cardsharing-Server-Anbieters: Nur technische Kriterien

Dieser Satelliten-TV-Receiver-Leitfaden 2026 wäre nicht vollständig ohne Betrachtung der Serverseite. Deine lokale Konfiguration kann perfekt sein und du wirst immer noch Bildschirmeinfrierungen bei Kanälen bekommen, wenn der Server schlecht ist. So bewertest du ihn, ohne hereinzufallen.

Protokoll

support: CCcam 2.x vs OScam newcamd vs cs378x

Suchen Sie nach Anbietern, die mindestens zwei Protokolloptionen anbieten — typischerweise CCcam auf Port 12000 und newcamd auf Port 10000. Anbieter, die cs378x unterstützen, bieten Ihnen eine bessere native OScam-Integration ohne die Notwendigkeit einer CCcam-Binärdatei. Single-Protocol-Server sind ein rotes Tuch für Flexibilität; wenn dieser Port von Ihrem ISP blockiert wird, haben Sie kein Fallback.

ECM-Antwortzeit-Benchmarks: Welche Zahlen zählen wirklich

Unter 300ms ECM-Antwortzeit ist gut. 300-600ms ist für die meisten Inhalte akzeptabel. Über 800ms verursacht sichtbare Freeze-Artefakte — der Decoder erhält den Descrambling-Schlüssel zu spät und verwirft Frames. Sie sehen diese Zeiten in /tmp/CCcam.log als Millisekunden-Werte neben jeder ECM-Antwort oder deutlicher in der OScam-Webif-Lesertabelle.

Reshare-Tiefe und Redundanzindikatoren für Peers

In CCcam.log suchen Sie nach HOP-Zählwerten neben ECM-Antworten. Ein HOP von 1 bedeutet, dass der Server über einen direkten Card-Reader verfügt — niedrigste Latenz, am zuverlässigsten. Ein HOP von 2-3 bedeutet neu freigegebene Karten, die durch Zwischenserver geleitet werden — jeder Hop fügt ~50-150ms hinzu und führt einen zusätzlichen Fehlerpunkt ein. Vermeiden Sie Server mit HOP-Zählwerten, die durchgehend über 3 liegen.

Anbieter, die mehrere redundante Card-Server (Failover) bewerben, sind theoretisch stabiler. Aber überprüfen Sie das, indem Sie absichtlich beobachten, was in Stoßzeiten passiert — wenn das Failover funktioniert, werden die ECM-Antwortzeiten nicht dramatisch ansteigen. Wenn doch, ist die Redundanz nur Marketing.

Stabilitätstests: Wie man CCcam.log ECM/EMM-Verhältnisse interpretiert

Führen Sie einen 24-48-Stunden-Test durch und verfolgen Sie das Protokoll. Zwei Kennzahlen sind wichtig:

grep -c 'not found' /tmp/CCcam.log
grep -c 'found' /tmp/CCcam.log

Berechnen Sie das Verhältnis. Mehr als 5% 'not found'-ECMs ist ein Problem — das bedeutet, dass dem Server Schlüssel für Kanäle fehlen, die Sie sich ansehen möchten. Dies unterscheidet sich von einem Konnektivitätsproblem; die Verbindung besteht, aber der Server kann nicht entschlüsseln, was Sie anfordern. Könnte ein CAID-Fehler sein, könnte eine Karte sein, die das benötigte Paket nicht hat.

Verbindungssicherheit: Verschlüsselte Tunnel vs. Risiken des reinen Protokolls

Plain newcamd und CCcam übertragen Anmeldedaten und ECM-Daten in Klartext oder schwach verschlüsselten Formaten. Für paranoid eingestellte Setups eliminiert das Umhüllen der Verbindung in einen VPN-Tunnel (WireGuard funktioniert gut auf modernen Enigma2-Images) die Exposition. Wenn der Anbieter TLS-verpacktes cs378x anbietet und Ihr OScam-Build SSL unterstützt, verwenden Sie es. Andernfalls stellen Sie zumindest sicher, dass Sie nicht die Standard-NM_keys verwenden oder leicht zu erratende Passwörter.

Bewertung von Testversionen ohne Verpflichtung zu langen Abonnements

Jeder Server, der etwas wert ist, bietet eine 24-48-Stunden-Testversion. Nutzen Sie dieses Zeitfenster, um die obige Protokollanalyse durchzuführen, überprüfen Sie ECM-Antwortzeiten in Stoß- und Schwachlastzeiten und überprüfen Sie, ob die spezifischen CAIDs und SIDs, die Sie interessieren, wirklich funktionieren. Bewerten Sie nicht basierend auf einem Kanal für fünf Minuten — das sagt nichts über Stabilität aus.

Troublesh

Beheben häufiger Receiver- und Protokollfehler

Die meisten Fehler folgen vorhersehbaren Mustern. So können Sie jeden einzelnen ohne Raten diagnostizieren.

ECM nicht gefunden: CAID-Nichtübereinstimmung vs. serverseitige Schlüsselverfallsprobleme

Zu suchender Logeintrag:

grep 'not found' /tmp/CCcam.log

Wenn dies wiederholt für einen bestimmten Kanal auftritt, stimmt die CAID oder Provider-ID in Ihrer C-Leitung nicht mit dem überein, was der Server anbietet. Vergleichen Sie die CAID, die der Kanal verwendet (sichtbar in der OScam-Weboberfläche oder über zap Info), mit Ihrem C-Leitung-Filter. Wenn die CAID übereinstimmt, aber es ist immer noch „nicht gefunden", hat die Serverkarte keinen Zugriff auf das Paket dieses Kanals — ein Abonnement-/Provider-Problem, kein Konfigurationsproblem.

Einfrieren von Kanälen: ECM-Timeout vs. Netzwerklatenz-Diagnose

Das Einfrieren bei aktiver Verbindung bedeutet normalerweise, dass ECM-Antworten zu langsam ankommen. Überprüfen Sie die Antwortzeiten im Log. Führen Sie auch aus:

ping -c 100 server.example.com

Achten Sie auf Jitter (Schwankungen in den Ping-Zeiten), nicht nur auf die durchschnittliche Latenz. Ein Durchschnitt von 10 ms mit Spitzen von 200 ms führt zu periodischem Einfrieren. Wenn der Jitter gering ist, aber die ECM-Zeiten hoch sind, ist das Problem serverseitig — die Karte ist langsam oder der Server ist überlastet.

CCcam-Binary stürzt beim Start ab: Behebung der Architektur-Nichtübereinstimmung

Wenn CCcam sofort mit Exec format error beendet wird, führen Sie aus:

file /usr/bin/CCcam
uname -m

file sagt etwas wie ELF 32-bit LSB executable, MIPS oder ELF 32-bit LSB executable, ARM. Vergleichen Sie dies mit der uname -m Ausgabe Ihres Receivers. Beachten Sie auch: Eine 32-Bit-MIPS-Binärdatei läuft nicht auf einem 64-Bit-MIPS-Receiver, obwohl beide „MIPS" sagen — die ABI muss genau übereinstimmen.

OScam-Reader zeigt „Offline": Verbindung abgelehnt vs. Authentifizierungsfehler

Überprüfen Sie /var/log/oscam/oscam.log:

• connect to [ip]:port failed — Server nicht erreichbar, überprüfen Sie IP/Port und Firewall
• login incorrect — falsche Anmeldedaten oder falscher NM_key in oscam.server
• connection refused — Port 10000 (oder 12000) blockiert; überprüfen Sie iptables -L -n auf dem Receiver und auf allen Routern zwischen Ihnen und dem Server

Dual-Boot-Android/Enigma2-Receiver sind hier ein besonderes Problem — die Firewall-Regeln von Android können in den Enigma2-Boot fortbestehen und ausgehende Verbindungen auf diesen Ports blockieren. Überprüfen Sie mit iptables -L -n | grep 12000.

Zap-Verzögerung über 3 Sekunden: Reshare-Hop-Count-Problem

Langsame Kanalwechsel (>3s) mit letztendlich erfolgreicher Entschlüsselung deuten auf hohe Reshare-Hop-Anzahlen hin. Jeder Hop addiert Latenz zu jeder ECM-Anfrage. Beobachten Sie die HOP-Werte in CCcam.log beim Zappen — wenn Sie durchgehend HOP:3 oder höher sehen, teilt Ihr Server durch mehrere Schichten. Dies ist von der Topologie des Servers inhärent; Sie können es von der Clientseite nicht beheben. Suchen Sie einen Server mit direct card access (HOP:1).

EMM nicht weitergeleitet: au=0 oder Reader EMM-Filter blockiert

Wenn eine physische lokale Karte nicht mehr aktualisiert wird, überprüfen Sie zwei Dinge. Erstens: In oscam.user benötigt das Client-Konto au = 1. Zweitens: Der Reader in oscam.server benötigt EMM-Verarbeitung aktiviert. Suchen Sie nach emmcache = 1 und überprüfen Sie, ob es kein blockemm-unknown = 1 gibt, das unbekannte EMM-Typen blockiert. Ohne EMM-Weiterleitung funktionieren Conditional-Access-Karten, die regelmäßige Schlüsselaktualisierungen benötigen, nach Ablauf der aktuellen Gültigkeitsdauer nicht mehr.

Receiver-Zeitabweichung bricht verschlüsselte Protokoll-Handshakes

Dies verursacht mysteriös fehlgeschlagene Newcamd-Verbindungen ohne offensichtlichen Fehler. Der Newcamd-Handshake beinhaltet einen Zeitstempel-Verifizierungsschritt. Wenn die Uhr Ihres Receivers um mehr als einige Minuten abweicht, schlägt der Handshake fehl und OScam protokolliert etwas Nicht-Aussagekräftiges. Beheben Sie es:

ntpdate pool.ntp.org

Oder konfigurieren Sie ntpd, um die Uhr dauerhaft synchronisiert zu halten. Die meisten Enigma2-Images haben ntpd verfügbar — stellen Sie einfach sicher, dass es in den Image-Einstellungen aktiviert oder beim Starten gestartet wird. Dies wird in anderen Anleitungen fast nie erwähnt und es ist ein überraschend häufiger Fehlermodus, wenn Receiver den Strom verlieren und RTC-Batterien leerwerden.

ES-Schlüssel zur Authentifizierung (explizit in der N-Zeile oder in der Datei oscam.server angegeben), während CCcam seinen eigenen proprietären Handshake verwendet. OScam kann Clients beider Protokolltypen gleichzeitig über separate Listener-Ports in oscam.conf bedienen.