Come controllare lo stato del server CCcam (Online e Offline)

Se hai bisogno di controllare lo stato del server CCcam e stai guardando un canale bloccato o uno schermo nero, la cosa peggiore che puoi fare è iniziare a riavviare casualmente i servizi. Ci sono tre livelli diagnostici distinti che devi affrontare — e la maggior parte delle persone salta direttamente al livello tre ignorando i primi due. Questa guida percorre ogni metodo, con comandi effettivi e percorsi di configurazione reali, così puoi individuare esattamente dove si trova il problema.

Comprendere lo stato del server CCcam: cosa stai effettivamente controllando

La maggior parte delle guide di controllo dello stato trattano "CCcam funziona?" come una semplice domanda sì/no. Non lo è. Ci sono tre livelli separati, e ognuno può fallire indipendentemente dagli altri.

Stato del processo vs. Stato della porta vs. Stato della scheda

Il livello 1 è il processo CCcam stesso — il binario sta effettivamente funzionando sul sistema operativo? Il livello 2 è la porta TCP — qualcosa sta ascoltando sulla porta 12000 e accettando connessioni? Il livello 3 è lo stato della scheda — le condivisioni effettive della smartcard sono attive e restituiscono ECM validi?

Un server può superare il livello 1 e il livello 2 mentre fallisce completamente il livello 3. Il processo funziona, la porta accetta la tua connessione, e l'handshake si completa — ma ogni richiesta ECM viene negata perché l'abbonamento della scheda upstream è scaduto due giorni fa. Questo è lo scenario più comune di "il mio CCcam è attivo ma nulla funziona".

CCcam utilizza per impostazione predefinita la porta TCP 12000 per le connessioni client C-line. L'interfaccia web incorporata funziona sulla porta TCP 16001. Ricorda entrambe.

Come appare un server CCcam sano a ogni livello

A livello di processo: ps aux | grep CCcam restituisce una voce di processo non zombie. A livello di porta: ss -tlnp | grep 12000 mostra lo stato LISTEN. A livello di scheda: la pagina dell'interfaccia web /cards.html mostra schede attive con risposte ECM recenti, e il tuo log mostra un flusso di voci "ECM concesso" anziché "ECM negato".

Il tempo di risposta ECM è una delle migliori metriche proxy per la salute del server. Sotto i 500ms è sano. 500–1000ms è marginale ma funzionale. Oltre i 1500ms costantemente significa che qualcosa non va — o il server è sovraccarico, la condivisione della scheda upstream si sta spegnendo, o c'è un problema di routing di rete tra server e client.

Indicatori di stato comuni e cosa significano

• Processo in esecuzione, porta chiusa: CCcam avviato ma crash immediato dopo il lancio, oppure è vincolato a una porta diversa da quella che ti aspetti. Controlla la configurazione.
• Porta aperta, connessioni rifiutate: Un whitelist IP tramite direttive ALLOW DENY: in CCcam.cfg sta bloccando il tuo IP client.
• Porta aperta, handshake completo, nessuna decrittografia: Errore a livello di scheda. Inizia da /tmp/CCcam.log.
• Processo in stato zombie (Z in ps): Il processo sembra attivo ma non sta facendo nulla. R

Metodo 1: Controllare lo Stato del Processo CCcam e della Porta tramite Riga di Comando

Questo è il tuo punto di partenza. Prima di toccare i file di configurazione o le interfacce web, conferma cosa sta effettivamente girando a livello del sistema operativo.

Utilizzo di ps e grep per Verificare che il Processo CCcam Sia in Esecuzione

Su un server Linux standard:

ps aux | grep CCcam

Una risposta sana assomiglia a:

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

Se ottieni solo il processo grep stesso, CCcam non è in esecuzione. Su box Enigma2 (Dreambox, VU+, Zgemma), il ps di busybox non accetta i flag aux — usa semplicemente:

ps | grep CCcam

Su Enigma2, il binario è spesso denominato CCcam.out anziché CCcam, quindi cerca entrambi. Inoltre, fai attenzione ai processi nello stato Z — è uno zombie. Appare nell'output ma non sta elaborando nulla. Eliminalo con kill -9 <pid>.

Se CCcam viene eseguito tramite systemd:

systemctl status CCcam

Per configurazioni init.d più vecchie:

service CCcam status

Su Enigma2, il gestore softcam generalmente gestisce questo:

/etc/init.d/softcam status

Nota Docker: Se CCcam gira all'interno di un contenitore, ps aux sull'host non mostrerà nulla. Devi prima entrare nel contenitore: docker exec -it <container_name> ps aux.

Utilizzo di netstat o ss per Confermare che la Porta 12000 Sia in Ascolto

ss -tlnp | grep 12000

O se il tuo sistema ha ancora netstat:

netstat -an | grep 12000

Output sano da ss:

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

Una cosa da osservare: se CCcam è associato solo a 0.0.0.0 (IPv4) ma il tuo client si sta connettendo tramite IPv6, otterrai una connessione rifiutata anche se il processo è in esecuzione e la porta è "aperta." Controlla se :::12000 appare anche nell'output di ss se IPv6 è in gioco.

Utilizzo di Telnet per Testare la Connettività TCP Raw alla Porta CCcam

telnet <server-ip> 12000

Se CCcam è attivo, riceverai una stringa di handshake binaria grezza entro un secondo o due — non testo leggibile, ma la connessione si aprirà e i dati fluiranno. Se ricevi immediatamente "Connection refused", la porta è chiusa. Se si blocca e scade il timeout, qualcosa sta bloccando la connessione a livello di firewall o NAT.

Lettura dei Codici di Uscita e Cosa Indicano le Connessioni Non Riuscite

"Connection refused" = porta non in ascolto. "Connection timed out" = firewall drop o problema di routing. "Connected but no data" = la porta è aperta ma CCcam potrebbe non essere sano, o una whitelist IP sta silenziosamente eliminando tla nostra sessione dopo l'handshake TCP. Ogni modalità di errore punta a una correzione diversa.

Metodo 2: Usa l'interfaccia web di CCcam per monitorare lo stato live

Una volta confermato che il processo è in esecuzione e la porta è attiva, l'interfaccia web è il tuo miglior strumento per controllare cosa sta effettivamente accadendo con le schede e i client.

Abilitazione e accesso all'interfaccia web di CCcam (porta 16001)

In /etc/CCcam.cfg, assicurati che queste righe siano presenti:

ALLOW WEBIF: yes
WEBIF USERNAME: admin
WEBIF PASSWORD: tuapassword

Dopo aver salvato, riavvia CCcam. Quindi apri un browser a:

http://<server-ip>:16001

Se la porta 16001 non risponde ma CCcam è in esecuzione, ricontrolla la direttiva ALLOW WEBIF e conferma che nient'altro è vincolato a quella porta.

Interpretazione della pagina Info: client, schede, statistiche ECM

La pagina dell'indice ti dà una rapida panoramica — versione di CCcam, uptime, client connessi e schede totali. Ma non fermarti qui. I dati utili si trovano nelle sottopagine.

Vai a /cards.html per vedere ogni scheda e condivisione che il server conosce. Ogni voce mostra il tipo di scheda, CAID, provider, hop count e statistiche di risposta ECM. L'hop count è importante: 0 significa una scheda fisica inserita localmente, 1 significa una condivisione diretta C-line, 2+ significa schede condivise da più in alto nella catena.

Controllo delle condivisioni attive e dei client C-line connessi

Vai a /clients.html per vedere ogni client C-line attualmente connesso. Vedrai il loro nome utente, indirizzo IP, durata della connessione e quante richieste ECM hanno effettuato. Un client che mostra 0 richieste ECM dopo diversi minuti è inattivo o non configurato correttamente.

Controlla /ecm.html per i tempi di risposta ECM per canale. Una scheda elencata in /cards.html con zero risposte ECM in una finestra di cinque minuti è effettivamente morta anche se risulta connessa — la scheda o la condivisione upstream non sta restituendo CW.

Cosa rivelano le pagine di versione e configurazione sulla tua configurazione

La pagina /version.html mostra la build esatta di CCcam. La pagina di configurazione mostra le tue direttive attive senza richiedere accesso SSH. Entrambe sono utili per la diagnosi remota quando non riesci a ottenere facilmente l'accesso shell.

Metodo 3: Diagnostica la salute del server tramite i file di log di CCcam

Il file di log è dove scopri perché qualcosa non funziona, non solo che non funziona.

Individuazione e visualizzazione del log di CCcam in tempo reale

Sui box Enigma2, il percorso di log predefinito è /tmp/CCcam.log. Negli installazioni Linux standard potrebbe essere /var/log/CCcam.log, ma questo è configurabile in CCcam.cfg tramite la direttiva LOG FILE:. Per guardarlo live:

tail -f /tmp/CCcam.log

Aggiungi più verbosità impostando questo nella tua configurazione:

LOG WARNINGS: yes

Un avvertimento: su server a lungo termine, /tmp/CCcam.log può riempire il filesystem. Quando succede, CCcam smette silenziosamente di scrivere nel log mentre continua a elaborare gli ECM. Quindi se il tuo file di log non si è aggiornato da ore ma il processo è "in esecuzione," controlla df -h /tmp prima di assumere che il log sia accurato.

Voci di Log Chiave Che Confermano un Server Sano

Cerca questi:

• ECM granted — la decriptazione funziona
• connected to — C-line upstream collegato con successo
• card added — una nuova card o condivisione è diventata disponibile

Pattern di Errore Che Indicano Fallimenti della Condivisione Card

Questi sono quelli che vuoi rilevare:

• ECM denied — la card non ha autorizzazione per questo canale
• card not found — nessuna card disponibile per gestire la combinazione CAID/SID
• timeout waiting for ECM — upstream è lento o non raggiungibile
• CW not found — la control word non è stata restituita; decriptazione fallita
• connection refused — C-line upstream non è raggiungibile

Usare grep per Filtrare Negazioni ECM, Timeout e Riconnessioni

Non leggere il log completo manualmente. Usa grep mirati:

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

Eseguire tutti e quattro questi comandi richiede circa 30 secondi e ti dice più di cinque minuti di staring al log grezzo.

Metodo 4: Testare la Connettività C-line dal Lato Client

Testare dal lato client isola se stai affrontando un problema al server o un problema al receiver locale. Questo passaggio da solo risparmia molto tempo sprecato.

Inviare una C-line di Test via Telnet da un Client Remoto

Da qualsiasi macchina Linux sulla rete (o esternamente se la porta è inoltrata):

telnet <cccam-server-ip> 12000

Un server CCcam attivo risponde con un handshake binario quasi immediatamente — entro 200–300ms su una LAN. Se ti stai collegando esternamente e telnet si blocca, il problema è l'inoltro delle porte o una regola firewall, non il processo CCcam stesso. Il successo del ping ICMP non significa nulla qui. Ping può tornare bene mentre la porta 12000 è completamente bloccata — testa sempre la porta effettiva.

Usare OScam come Client per Verificare la Risposta del Server CCcam

Se stai eseguendo OScam come client puntato a un server CCcam, controlla /etc/oscam/oscam.server per confermare che il reader sia configurato correttamente. L'interfaccia web di OScam (porta predefinita 8888) mostra lo stato del reader, i tempi di risposta ECM attuali in millisecondi, e se il reader è nello stato "OK" o "ERROR".

Un reader che mostra "TIMEOUT" o "NO_CARD" nella pagina di stato di OScam significa che OScam sta raggiungendo il server CCcam a the livello TCP ma non ricevo risposte CW valide — il che indica un errore a livello di scheda sul lato CCcam.

Controllo dei tempi di risposta ECM come metrica di salute del server

I tempi di risposta ECM sono l'indicatore di salute in tempo reale più chiaro:

Cosa ti dice un'alta latenza ECM (>1000ms) sul server

Una latenza ECM costantemente alta indica una di tre cose: la condivisione di scheda a monte su cui il server si basa è sovraccarica, il percorso di rete tra il tuo client e il server ha problemi di routing (esegui un traceroute per verificare), oppure il server CCcam stesso è sovraccarico con troppi client simultanei per scheda. Controlla il conteggio degli hop in /cards.html — se sei all'hop 3 o superiore, ogni hop aggiuntivo aggiunge latenza e instabilità.

Risoluzione dei problemi: il server è online ma i canali si bloccano comunque

Questo è lo scenario che quasi tutte le altre guide ignorano. Il server passa tutti i controlli di base — il processo è in esecuzione, la porta 12000 è in ascolto, puoi persino connetterti — ma i canali si bloccano comunque o l'STB mostra "nessun segnale" o "nessun CA trovato".

Scheda presente ma errori ECM — cause possibili

La scheda compare in /cards.html ma il canale non si decripta. Primo controllo: stai richiedendo un SID per il quale la scheda ha effettivamente diritti? Una scheda può essere completamente funzionante mentre ha zero diritti per un canale specifico o un livello di pacchetto. La pagina /cards.html mostra i SID autorizzati — se il SID del canale non è nell'elenco, la scheda letteralmente non può decriptarlo indipendentemente da quanto il server sia sano.

Controllo dei diritti della scheda e validità dell'abbonamento

I diritti della scheda sono legati all'abbonamento fisico, non al software CCcam. Se l'abbonamento di una scheda è scaduto, CCcam mostrerà comunque la scheda come "presente" — ma ogni ECM per un canale premium verrà rifiutato. Il log mostrerà ECM denied per quei canali. Non c'è una correzione software per un abbonamento scaduto.

Server sovraccarico: troppi client per scheda

CCcam ha una direttiva SHARE LIMIT: in CCcam.cfg che limita le richieste ECM simultanee. Se hai 50 client che bombardano una scheda, le richieste si mettono in coda e molte vengono eliminate o scadono. Controlla /clients.html per le connessioni attive totali e confrontale con il limite di condivisione configurato. Riduci i client connessi o aggiungi un'altra condivisione a monte.

Problemi di percorso di rete tra server e client

Doppio

PORT: 443

#!/bin/bash
LOGFILE="/var/log/cccam_monitor.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
HOST="localhost"
PORT="12000"
EMAIL="[email protected]"
# Controlla processo
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
# Controlla porta
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"

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

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

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