```html

So überprüfen Sie den CCcam-Serverstatus (Live & Offline)

Wenn Sie den CCcam-Serverstatus überprüfen müssen und Sie starren auf einen eingefrorenen Kanal oder einen schwarzen Bildschirm, ist das Schlimmste, was Sie tun können, Services zufällig neu zu starten. Es gibt drei verschiedene Diagnoseebenen, die Sie durcharbeiten müssen – und die meisten Menschen überspringen direkt zur dritten Ebene, während sie die ersten beiden ignorieren. Diese Anleitung führt Sie durch jede Methode mit tatsächlichen Befehlen und realen Konfigurationspfaden, damit Sie genau feststellen können, wo der Fehler liegt.

CCcam-Serverstatus verstehen: Was Sie tatsächlich überprüfen

Die meisten Statusprüfungs-Leitfäden behandeln „Funktioniert CCcam?" als eine einzige Ja/Nein-Frage. Das ist nicht der Fall. Es gibt drei separate Ebenen, und jede kann unabhängig von den anderen fehlschlagen.

Prozessstatus vs. Port-Status vs. Kartenstatus

Ebene 1 ist der CCcam-Prozess selbst – läuft die Binärdatei tatsächlich auf dem Betriebssystem? Ebene 2 ist der TCP-Port – horcht etwas auf Port 12000 und akzeptiert Verbindungen? Ebene 3 ist der Kartenstatus – sind die tatsächlichen Smartcard-Shares aktiv und geben gültige ECMs zurück?

Ein Server kann Ebene 1 und Ebene 2 bestehen, während er bei Ebene 3 völlig fehlschlägt. Der Prozess läuft, der Port akzeptiert Ihre Verbindung und der Handshake wird abgeschlossen – aber jede ECM-Anfrage wird abgelehnt, weil das vorgelagerte Kartenguthaben vor zwei Tagen abgelaufen ist. Dies ist das häufigste Szenario „mein CCcam ist oben, aber nichts funktioniert".

CCcam verwendet standardmäßig TCP-Port 12000 für C-Line-Clientverbindungen. Die integrierte Weboberfläche läuft auf TCP-Port 16001. Merken Sie sich beide.

Wie ein gesunder CCcam-Server auf jeder Ebene aussieht

Auf der Prozessebene: ps aux | grep CCcam gibt einen Nicht-Zombie-Prozesseintrag zurück. Auf der Port-Ebene: ss -tlnp | grep 12000 zeigt den LISTEN-Status. Auf der Kartenschicht: Die Weboberfläche /cards.html zeigt aktive Karten mit kürzlichen ECM-Antworten und Ihr Protokoll zeigt einen Strom von „ECM granted"-Einträgen anstelle von „ECM denied".

Die ECM-Antwortzeit ist eine der besten Proxy-Metriken für die Servergesundheit. Unter 500 ms ist gesund. 500–1000 ms ist grenzwertig, aber funktional. Über 1500 ms dauerhaft bedeutet, dass etwas falsch ist – entweder ist der Server überlastet, die vorgelagerte Kartenweitergabe geht zu Ende, oder es gibt ein Netzwerk-Routing-Problem zwischen Server und Client.

Häufige Statusindikatoren und ihre Bedeutung

• Prozess läuft, Port geschlossen: CCcam ist gestartet, aber sofort nach dem Start abgestürzt, oder es bindet an einen anderen Port als erwartet. Überprüfen Sie die Konfiguration.
• Port offen, Verbindungen abgelehnt: Eine IP-Whitelist über ALLOW DENY: Direktiven in CCcam.cfg blockiert Ihre Client-IP.
• Port offen, Handshake abgeschlossen, keine Entschlüsselung: Kartenschicht-Fehler. Beginnen Sie bei /tmp/CCcam.log.
• Prozess in Zombie-Status (Z in ps): Der Prozess scheint aktiv zu sein, tut aber nichts. R

```erfordert kill -9 gefolgt von einem sauberen Neustart — ein normaler Neustart löscht einen Zombie nicht.

Methode 1: Überprüfen Sie den CCcam-Prozess und den Port-Status über die Befehlszeile

Das ist Ihr Ausgangspunkt. Bevor Sie Konfigurationsdateien oder Web-Interfaces anfassen, bestätigen Sie, was tatsächlich auf OS-Ebene ausgeführt wird.

Verwendung von ps und grep zur Überprüfung, ob der CCcam-Prozess läuft

Auf einem Standard-Linux-Server:

ps aux | grep CCcam

Eine gesunde Antwort sieht so aus:

root 1234 0.4 1.2 45320 6140 ? Ss 08:22 0:12 /usr/local/bin/CCcam

Wenn Sie nur den grep-Prozess selbst zurückbekommen, wird CCcam nicht ausgeführt. Auf Enigma2-Boxen (Dreambox, VU+, Zgemma) akzeptiert busybox's ps keine aux-Flags — verwenden Sie einfach:

ps | grep CCcam

Auf Enigma2 ist die Binärdatei oft CCcam.out statt CCcam benannt, also greifen Sie nach beiden. Achten Sie auch auf Prozesse im Status Z — das ist ein Zombie. Er wird in der Ausgabe angezeigt, verarbeitet aber nichts. Beenden Sie ihn mit kill -9 <pid>.

Wenn CCcam über systemd läuft:

systemctl status CCcam

Für ältere init.d-Setups:

service CCcam status

Auf Enigma2 verwaltet normalerweise der Softcam-Manager dies:

/etc/init.d/softcam status

Docker-Hinweis: Wenn CCcam in einem Container läuft, zeigt ps aux auf dem Host nichts. Sie müssen zuerst in den Container wechseln: docker exec -it <container_name> ps aux.

Verwendung von netstat oder ss zur Bestätigung, dass Port 12000 abhört

ss -tlnp | grep 12000

Oder wenn Ihr System noch netstat hat:

netstat -an | grep 12000

Gesunde Ausgabe von ss:

LISTEN 0 128 0.0.0.0:12000 0.0.0.0:* users:(("CCcam",pid=1234,fd=5))

Eine Sache, auf die Sie achten sollten: Wenn CCcam nur an 0.0.0.0 (IPv4) bindet, aber Ihr Client sich über IPv6 verbindet, erhalten Sie eine Verbindung verweigert, obwohl der Prozess läuft und der Port "offen" ist. Überprüfen Sie, ob :::12000 auch in der ss-Ausgabe angezeigt wird, falls IPv6 im Spiel ist.

Verwendung von Telnet zum Testen der Raw-TCP-Konnektivität zum CCcam-Port

telnet <server-ip> 12000

Wenn CCcam aktiv ist, erhalten Sie innerhalb einer oder zwei Sekunden einen rohen binären Handshake-String zurück — kein lesbarer Text, aber die Verbindung wird geöffnet und Daten fließen. Wenn Sie sofort „Verbindung verweigert" erhalten, wird der Port nicht abhört. Wenn es hängen bleibt und bei Timeout, blockiert etwas die Verbindung auf einer Firewall- oder NAT-Ebene.

Lesen von Exit-Codes und was fehlgeschlagene Verbindungen anzeigen

„Verbindung verweigert" = Port hört nicht ab. „Verbindung abgelaufen" = Firewall-Drop oder Routing-Problem. „Verbunden aber keine Daten" = Port ist offen, aber CCcam ist möglicherweise nicht gesund, oder eine IP-Whitelist lässt Sie stillschweigend falleunsere Sitzung nach dem TCP-Handshake. Jeder Fehlermodus weist auf eine andere Lösung hin.

Methode 2: Verwenden Sie die CCcam-Weboberfläche zur Überwachung des Live-Status

Nachdem Sie bestätigt haben, dass der Prozess läuft und der Port aktiv ist, ist die Weboberfläche Ihr bestes Werkzeug, um zu überprüfen, was tatsächlich mit Karten und Clients passiert.

Aktivieren und Zugreifen auf die CCcam-Weboberfläche (Port 16001)

In /etc/CCcam.cfg stellen Sie sicher, dass diese Zeilen vorhanden sind:

ALLOW WEBIF: yes
WEBIF USERNAME: admin
WEBIF PASSWORD: yourpassword

Speichern Sie die Datei und starten Sie CCcam neu. Öffnen Sie dann einen Browser mit:

http://<server-ip>:16001

Wenn Port 16001 nicht antwortet, aber CCcam läuft, überprüfen Sie die ALLOW WEBIF-Direktive und stellen Sie sicher, dass nichts anderes an diesen Port gebunden ist.

Interpretation der Info-Seite: Clients, Karten, ECM-Statistiken

Die Indexseite gibt Ihnen einen schnellen Überblick — CCcam-Version, Betriebszeit, verbundene Clients und Gesamtkarten. Aber hören Sie hier nicht auf. Die nützlichen Daten befinden sich auf den Unterseiten.

Navigieren Sie zu /cards.html, um jede Karte und Freigabe anzuzeigen, die der Server kennt. Jeder Eintrag zeigt den Kartentyp, CAID, Provider, Hop-Count und ECM-Antwortstatistiken. Der Hop-Count ist wichtig: 0 bedeutet eine lokal eingefügte physische Karte, 1 bedeutet eine direkte C-Line-Freigabe, 2+ bedeutet weitergelegte Karten von weiter oben in der Kette.

Überprüfung aktiver Freigaben und verbundener C-Line-Clients

Gehen Sie zu /clients.html, um alle derzeit verbundenen C-Line-Clients zu sehen. Sie sehen ihren Benutzernamen, IP-Adresse, Verbindungsdauer und wie viele ECM-Anfragen sie gestellt haben. Ein Client, der nach mehreren Minuten 0 ECM-Anfragen anzeigt, ist entweder untätig oder falsch konfiguriert.

Überprüfen Sie /ecm.html auf ECM-Antwortzeiten pro Kanal. Eine Karte, die in /cards.html aufgelistet ist und über ein fünfminütiges Fenster null ECM-Antworten aufweist, ist praktisch tot, selbst wenn sie als verbunden angezeigt wird — die Karte oder die Upstream-Freigabe gibt keine CWs zurück.

Was die Versions- und Konfigurationsseiten über Ihr Setup offenbaren

Die Seite /version.html zeigt den genauen CCcam-Build. Die Konfigurationsseite zeigt Ihre aktiven Direktiven ohne SSH-Zugriff zu benötigen. Beide sind nützlich für Ferndiagnosen, wenn Sie nicht leicht auf Shell-Zugriff zugreifen können.

Methode 3: Diagnose der Server-Integrität über CCcam-Protokolldateien

Die Protokolldatei ist der Ort, an dem Sie herausfinden, warum etwas nicht funktioniert, nicht nur dass es nicht funktioniert.

Lokalisierung und Echtzeit-Überwachung des CCcam-Logs

Auf Enigma2-Boxen ist der standardmäßige Protokollpfad /tmp/CCcam.log. Bei Standard-Linux-Installationen kann er /var/log/CCcam.log sein, aber dies ist in CCcam.cfg über die LOG FILE:-Direktive konfigurierbar. Um es live zu beobachten:

tail -f /tmp/CCcam.log

Fügen Sie mehr Ausführlichkeit hinzu, indem Sie dies in Ihre Konfiguration einstellen:

LOG WARNINGS: yes

Eine Falle: Auf lange laufenden Servern kann /tmp/CCcam.log kann das Dateisystem füllen. Wenn dies geschieht, stoppt CCcam stillschweigend das Schreiben in das Protokoll, verarbeitet aber weiterhin ECMs. Wenn Ihre Protokolldatei stundenlang nicht aktualisiert wurde, der Prozess aber „ausgeführt" wird, überprüfen Sie df -h /tmp, bevor Sie davon ausgehen, dass das Protokoll korrekt ist.

Wichtige Protokolleinträge, die einen fehlerfreien Server bestätigen

Suchen Sie nach diesen:

• ECM granted — Entschlüsselung funktioniert
• connected to — Upstream C-Line erfolgreich verbunden
• card added — eine neue Karte oder ein neuer Share ist verfügbar

Fehlermuster, die auf Fehler beim Kartentausch hindeuten

Das sind die, die Sie erkennen möchten:

• ECM denied — Karte hat keine Berechtigung für diesen Kanal
• card not found — keine Karte verfügbar zur Verarbeitung der CAID/SID-Kombination
• timeout waiting for ECM — Upstream ist langsam oder down
• CW not found — Kontrollwort wurde nicht zurückgegeben; Entschlüsselung fehlgeschlagen
• connection refused — Upstream C-Line ist nicht erreichbar

Verwendung von grep zum Filtern von ECM-Ablehnungen, Timeouts und Neuvebindungen

Lesen Sie das vollständige Protokoll nicht manuell durch. Verwenden Sie gezieltes grep:

grep -i "ecm denied" /tmp/CCcam.log | tail -20

grep -i "timeout" /tmp/CCcam.log | tail -20

grep -i "connection refused" /tmp/CCcam.log | tail -20

grep -i "card not found" /tmp/CCcam.log | tail -20

Die Ausführung all dieser vier Befehle dauert etwa 30 Sekunden und teilt Ihnen mehr mit, als fünf Minuten lang auf das Rohprotokoll zu starren.

Methode 4: Testen der C-Line-Konnektivität von der Clientseite

Das Testen von der Clientseite isoliert, ob Sie es mit einem Serverproblem oder einem Problem mit dem lokalen Receiver zu tun haben. Dieser Schritt allein spart viel verschwendete Zeit.

Senden einer Test-C-Line über Telnet von einem Remote-Client

Von jeder Linux-Maschine im Netzwerk (oder extern, wenn der Port weitergeleitet wird):

telnet <cccam-server-ip> 12000

Ein aktiver CCcam-Server antwortet fast sofort mit einem Binär-Handshake — innerhalb von 200–300 ms in einem LAN. Wenn Sie sich extern verbinden und telnet hängt, ist das Problem die Portweiterleitung oder eine Firewall-Regel, nicht der CCcam-Prozess selbst. ICMP-Ping-Erfolg bedeutet hier nichts. Ping kann gut funktionieren, während Port 12000 vollständig blockiert ist — testen Sie immer den tatsächlichen Port.

Verwendung von OScam als Client zur Überprüfung der CCcam-Serverantwort

Wenn Sie OScam als Client ausführen, der auf einen CCcam-Server verweist, überprüfen Sie /etc/oscam/oscam.server, um zu bestätigen, dass der Reader korrekt konfiguriert ist. Die OScam-Weboberfläche (Standard-Port 8888) zeigt den Reader-Status, aktuelle ECM-Antwortzeiten in Millisekunden und ob sich der Reader im Status „OK" oder „ERROR" befindet.

Ein Reader, der auf der Statusseite von OScam „TIMEOUT" oder „NO_CARD" anzeigt, bedeutet, dass OScam den CCcam-Server auf th erreicht

e TCP level aber keine gültigen CW-Antworten erhalten — was auf einen Kartenschichtfehler auf der CCcam-Seite hindeutet.

ECM-Antwortzeiten als Servergesundheitsmetrik überprüfen

ECM-Antwortzeiten sind der klarste Echtzeit-Gesundheitsindikator:

ECM-Antwortzeit	Status
Unter 500ms	Gesund — normaler Betrieb
500ms – 1000ms	Grenzwertig — genaue Überwachung erforderlich
1000ms – 1500ms	Beeinträchtigt — wahrscheinlich Upstream-Probleme
Über 1500ms	Problematisch — Einfrieren zu erwarten

Was hohe ECM-Latenz (>1000ms) über den Server aussagt

Konstant hohe ECM-Latenz weist auf eines von drei Dingen hin: Die Upstream-Kartenfreigabe, auf die der Server angewiesen ist, ist überlastet, der Netzwerkpfad zwischen Ihrem Client und dem Server hat Routingprobleme (führen Sie einen Traceroute durch, um dies zu überprüfen), oder der CCcam-Server selbst ist mit zu vielen gleichzeitigen Clientverbindungen pro Karte überlastet. Überprüfen Sie die Hop-Anzahl in /cards.html — wenn Sie bei Hop 3 oder höher sind, fügt jeder zusätzliche Hop Latenz und Instabilität hinzu.

Fehlerbehebung: Server wird angezeigt, aber Kanäle frieren dennoch ein

Dies ist das Szenario, das fast jede andere Anleitung ignoriert. Der Server besteht alle grundlegenden Überprüfungen — Prozess läuft, Port 12000 wird abgehört, Sie können sich sogar verbinden — aber Kanäle frieren dennoch ein oder das STB zeigt „kein Signal" oder „keine CA gefunden" an.

Karte vorhanden, aber ECM-Fehler — mögliche Ursachen

Die Karte wird in /cards.html angezeigt, aber der Kanal wird nicht entschlüsselt. Erste Überprüfung: Fordern Sie eine SID an, für die die Karte tatsächlich berechtigt ist? Eine Karte kann vollständig funktionsfähig sein und gleichzeitig keine Berechtigung für einen bestimmten Kanal oder ein Paketpaket haben. Die Seite /cards.html zeigt autorisierte SIDs — wenn die SID des Kanals nicht in der Liste enthalten ist, kann die Karte sie unabhängig davon nicht entschlüsseln, wie gesund der Server ist.

Kartengültigkeiten und Abonnementgültigkeit überprüfen

Kartengültigkeiten sind an das physische Abonnement gebunden, nicht an die CCcam-Software. Wenn das Abonnement einer Karte abgelaufen ist, wird die Karte von CCcam dennoch als „vorhanden" angezeigt — aber jede ECM für einen Premium-Kanal wird abgelehnt. Das Protokoll zeigt ECM denied für diese Kanäle. Es gibt keine Softwarelösung für ein abgelaufenes Abonnement.

Überladener Server: Zu viele Clients pro Karte

CCcam hat eine SHARE LIMIT: Direktive in CCcam.cfg, die gleichzeitige ECM-Anfragen begrenzt. Wenn Sie 50 Clients haben, die eine Karte bombardieren, werden Anfragen in die Warteschlange eingereiht und viele werden gelöscht oder finden ein Timeout. Überprüfen Sie /clients.html auf die Gesamtzahl aktiver Verbindungen und vergleichen Sie diese mit Ihrer konfigurierten Freigabegrenze. Reduzieren Sie verbundene Clients oder fügen Sie eine weitere Upstream-Freigabe hinzu.

Netzwerkpfadprobleme zwischen Server und Client

Doppelt

```html

NAT ist ein häufiger Schuldiger, der leicht übersehen wird. TCP-Verbindungen werden ordnungsgemäß hergestellt, aber die Keepalive-Pakete werden irgendwo in der Mitte verworfen, wodurch der Server einen Client als verbunden anzeigt, während tatsächlich keine Daten fließen. Führen Sie traceroute vom Client zum Server aus und achten Sie auf asymmetrische Pfade oder Middleboxen, die möglicherweise eine zustandsbehaftete Überprüfung auf nicht standardmäßigen Ports durchführen.

Achten Sie auch auf NTP-Synchronisierungsfehler. Der Kryptographie-Handshake von CCcam ist zeitabhängig – wenn die Serveruhr um mehr als ein paar Minuten abweicht, werden Client-Verbindungen abgelehnt, auch wenn alles andere korrekt aussieht. Führen Sie date auf Server und Client aus, um Zeitstempel zu vergleichen.

Firewall- und NAT-Blockierung des CCcam-Verkehrs

Einige ISPs führen eine tiefe Paketüberprüfung durch und kennzeichnen oder drosseln speziell das CCcam-Protokoll-Handshake-Muster auf Port 12000. Wenn alles in Ihrem LAN funktioniert, externe Clients aber trotz korrekter Portweiterleitung nicht verbunden werden können, ist dies wahrscheinlich die Ursache. Die Lösung besteht darin, CCcams Listening-Port in CCcam.cfg zu ändern:

PORT: 443

Port 443 oder 8080 umgehen typischerweise DPI-Regeln, da sie als Standard-Webverkehr behandelt werden. Aktualisieren Sie die Portweiterleitung Ihres Routers und aktualisieren Sie alle Client-C-Linien, um den neuen Port widerzuspiegeln. Beachten Sie, dass Port 443 einen Konflikt mit einem vorhandenen HTTPS-Dienst verursachen kann – überprüfen Sie dies zuerst mit ss -tlnp | grep 443.

Überprüfen Sie auch Ihre ALLOW DENY:-Direktiven in CCcam.cfg. Eine falsch konfigurierte IP-Whitelist kann dazu führen, dass Port 12000 die TCP-Verbindung akzeptiert und sie dann sofort schließt, was von außen wie ein intermittierendes Verbindungsproblem aussieht.

Automatisierung von CCcam-Statusüberprüfungen mit Skripten und Überwachung

Das manuelle Überprüfen des CCcam-Status funktioniert für sofortige Fehlerbehebung, aber für einen unbeaufsichtigten Server benötigen Sie Automatisierung. Ein fünfminütiger Cron-Job, der sowohl die Prozess- als auch die Port-Gesundheit überprüft, erfasst Ausfallzeiten, bevor Benutzer anfangen zu beschweren.

Schreiben eines Bash-Skripts zur Überprüfung des CCcam-Prozesses und der Port-Gesundheit

#!/bin/bash
LOGFILE="/var/log/cccam_monitor.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
HOST="localhost"
PORT="12000"
EMAIL="[email protected]"
# Check process
if ! ps aux | grep -v grep | grep -q "CCcam"; then echo "$TIMESTAMP - ALERT: CCcam process not found" >> "$LOGFILE" echo "CCcam process down at $TIMESTAMP" | mail -s "CCcam DOWN" "$EMAIL" exit 1
fi
# Check port
if ! nc -z -w3 "$HOST" "$PORT"; then echo "$TIMESTAMP - ALERT: Port $PORT not responding" >> "$LOGFILE" echo "CCcam port $PORT unreachable at $TIMESTAMP" | mail -s "CCcam Port Down" "$EMAIL" exit 1
fi
echo "$TIMESTAMP - OK: CCcam process running, port $PORT accepting connections" >> "$LOGFILE"

Speichern Sie dies als /usr/local/bin/check_cccam.sh und machen Sie es ausführbar: chmod +x /usr/local/bin/check_cccam.sh.

Einrichtung eines Cron-Jobs für periodische Statusüberprüfungen

Fügen Sie dies zu Ihrer Crontab ```b (crontab -e):

*/5 * * * * /usr/local/bin/check_cccam.sh >> /var/log/cccam_monitor.log 2>&1

Dies läuft alle 5 Minuten. Passen Sie das Intervall basierend darauf an, wie schnell Sie Ausfälle erkennen müssen. Wenn Sie stattdessen Webhook-Benachrichtigungen verwenden möchten (z. B. für eine Slack- oder Telegram-Benachrichtigung), ersetzen Sie den mail-Befehl durch:

curl -s -X POST "https://your-webhook-url" -d "payload=CCcam is down"

Verwendung von nc (netcat) als leichter Port-Checker

nc -z -w3 localhost 12000 ist sauberer als telnet für skriptgesteuerte Checks. Das Flag -z läuft im Zero-I/O-Modus (testet nur Konnektivität, ohne Daten zu senden), und -w3 setzt ein 3-Sekunden-Timeout. Es beendet sich mit Code 0 bei Erfolg und 1 bei Fehler, was genau das ist, was Sie für bedingte Logik in einem Bash-Skript benötigen.

Benachrichtigungen per E-Mail oder Webhook bei CCcam-Ausfall

Auf Enigma2-Boxen mit eingeschränkten Shell-Tools sind der Befehl mail und nc möglicherweise nicht verfügbar. Verwenden Sie stattdessen wget als Liveness-Check:

wget -q --spider http://localhost:16001
if [ $? -ne 0 ]; then echo "CCcam web interface down" >> /tmp/cccam_monitor.log
fi

Dies überprüft nicht die Card-Schicht, ist aber ein angemessener Liveness-Check, wenn Ihr Toolset auf das beschränkt ist, was in der Enigma2-Busybox-Umgebung verfügbar ist.

Mit dem Prozess-Check, Port-Check, Web-Interface-Check und Log-Überwachung haben Sie jetzt alles, was Sie brauchen, um den CCcam-Serverstatus auf jeder Ebene zu überprüfen – von der Frage, ob die Binärdatei überhaupt läuft, bis hin zur Frage, ob einzelne Karten gültige CWs zurückgeben. Keine Vermutungen, kein „Neustart und Hoffnung".