Server CCcam Canali: Configurazione, Config e Risoluzione dei Problemi

Se stai guardando uno schermo nero o un'immagine congelata dopo aver fatto funzionare la tua configurazione CCcam, sei nel posto giusto. Capire come funzionano effettivamente i canali del server cccam a livello di protocollo — non solo "aggiungi una C-line e speriamo bene" — è quello che separa una configurazione affidabile da una frustrante. Questa guida presuppone che tu abbia CCcam installato, che tu abbia almeno una C-line o una scheda locale configurata, e che canali specifici stiano scomparendo, congelando o rifiutandosi di decrittare.

Come CCcam Mappa le Schede ai Canali

Ecco la cosa che la maggior parte delle guide salta completamente: CCcam non ha alcun concetto di "canali" nel modo in cui lo fa la tua EPG. Non memorizza un elenco di "Sky Sports HD, BBC One, Eurosport." Quello che memorizza è un insieme di tuple numeriche — CAID, ID provider e SID — e confronta le richieste ECM con quelle tuple. Se la tupla corrisponde e la scheda può decrittare, ottieni una parola di controllo. Se no, schermo nero.

Cosa Significa un "Canale" a Livello di Protocollo

A livello DVB, ogni canale crittato trasmette un pacchetto ECM (Entitlement Control Message) insieme al flusso video. Questo ECM contiene il CAID che identifica quale sistema CA l'ha crittato. Il tuo ricevitore invia questo ECM a CCcam, che lo instrada a una scheda che riconosce il CAID. La scheda lo decritta e restituisce una parola di controllo. Quella parola di controllo descrambia il video.

Quindi "canale non funzionante" quasi sempre significa che l'instradamento ECM ha fallito da qualche parte — o il CAID non è stato abbinato, la scheda non aveva il diritto, o la risposta ha impiegato troppo tempo. Questo è il modello mentale di cui hai bisogno.

CAID, ID Provider e SID: i Tre Identificatori Importanti

Questi tre numeri definiscono completamente l'accesso ai canali in CCcam:

• CAID — Conditional Access ID. Identifica il fornitore CA. Ad esempio, 0x0500 è Viaccess, 0x0600 è Irdeto, 0x1800 è Nagravision. Questo è il primo filtro nella catena di instradamento.
• ID Provider — Uno spazio dei nomi secondario all'interno del sistema CA. Una singola scheda con CAID 0x0500 potrebbe avere ID provider 032830, 042800 e 040810 — ognuno che rappresenta un operatore o un bouquet diverso.
• SID — Service ID. L'identificatore del canale effettivo all'interno di un transponder. Questo è quello che mappa a "quel canale specifico" nell'elenco dei canali del tuo ricevitore.

CCcam instrada una richiesta ECM abbinando prima il CAID, poi l'ID provider, quindi tentando la decrittazione. Il SID non viene utilizzato per l'instradamento — è il livello di abbonamento della scheda che determina se la parola di controllo torna valida per un determinato SID.

Come CCcam Costruisce il Suo Elenco Canali Interno dalle Schede Connesse

Quando CCcam si avvia e una scheda viene inserita (o una C-line si connette), CCcam legge l'ATR della scheda ed esegue un controllo iniziale dei diritti. Crea una tabella interna di quali CAID e ID provider a cui quella scheda risponde. Questa tabella è quello che vedi in t

È importante notare che CCcam non enumera preventivamente ogni SID che una card può decrittare. Lo scopre dinamicamente solo quando arriva una richiesta ECM. Quindi l'interfaccia web ti mostra i CAID e i provider — non un elenco di canali precostruito. Non saprai che uno SID specifico è rotto finché non proverai a sintonizzarlo.

Differenza tra il Tier/Pacchetto di una Card e l'Accesso Raw CAID

Questo coglie molte persone alla sprovvista. Una card può presentare CAID 0x0919 (Nagravision) e avere visibile l'ID provider 000000 — ma avere solo un tier di abbonamento base. I canali premium su lo stesso CAID e provider restituiranno una control word non valida, o nessuna risposta, perché la card semplicemente non ha il diritto.

CCcam non può dirti in anticipo quali SID rientrano nell'abbonamento di una card. Tenterà la decrittazione e registrerà un errore. Questo è l'unico modo per scoprirlo — tentare la decrittazione e leggere la risposta ECM nel log.

Configurazione di CCcam per Condividere Canali Specifici

Il file di configurazione principale si trova in /etc/CCcam.cfg sulla maggior parte dei box Linux e ricevitori Enigma2. Tutto ciò che controlla quali canali vengono condivisi, filtrati o bloccati è qui. Passiamo in rassegna le direttive che contano davvero.

Sintassi di CCcam.cfg per il Filtraggio di Canali e CAID

La struttura di base utilizza direttive in maiuscolo seguite da due punti e dal valore. Lo spazio bianco è flessibile. I commenti usano #. Ecco un esempio minimo funzionante che gestisce il controllo a livello CAID:

# /etc/CCcam.cfg
PORT: 12000
NEWCAMD PORT: 15050 01020304050607080910111213141516
C: peer.example.com 12000 username password
IGNORE CAID: 0500
PROVIDE CAID: 0919 PROVID: 000000
PROVIDE CAID: 0919 PROVID: 000001
SHARE LIMIT: 1
DEBUG: 1
HTTP PORT: 16001

La riga IGNORE CAID: 0500 dice a CCcam di scartare qualsiasi richiesta ECM o condivisione che coinvolga Viaccess (0500). Le righe PROVIDE CAID inseriscono nella whitelist combinazioni specifiche di CAID/provider. Se usi entrambe, IGNORE ha precedenza per i suoi CAID elencati.

Uso delle Direttive IGNORE e PROVIDE per Whitelist o Blacklist di CAID

Se vuoi consentire tutto tranne un sistema CA, usa IGNORE. Se vuoi una whitelist rigorosa, combina IGNORE CAID: ALL con righe PROVIDE esplicite. La parola chiave ALL è una direttiva reale — istruisce CCcam a rifiutare tutti i CAID non esplicitamente forniti.

IGNORE CAID: ALL
PROVIDE CAID: 0919 PROVID: 000000
PROVIDE CAID: 0600 PROVID: 000000

Questo blocca il tuo server solo a quelle due combinazioni di CAID/provider. Qualsiasi altra cosa — incluso un client che richiede canali Viaccess — viene scartata silenziosamente. Utile quando stai condividendo una card specifica e non vuoi esporre CAID non correlati da peer upstream.

Limitazione della Condivisione a ID Provider Specifici

Il filtraggio dell'ID provider è più chirurgico del filtraggio CAID. Potresti avere una card con CAID 0x0500 e tre ID provider — uno per e

IGNORE CAID: 0500
PROVIDE CAID: 0500 PROVID: 032830

Questo espone solo il pacchetto provider 032830 sotto Viaccess mentre blocca gli altri provider ID dalla stessa scheda. Pulito ed efficace per condividere abbonamenti parziali.

Impostazione di SHARE LIMIT e Hop Count per controllare la propagazione dei canali

La direttiva SHARE LIMIT controlla quanti hop a valle una condivisione può viaggiare. Impostarlo a 0 significa che solo la tua scheda locale viene condivisa — nessuna ricondivisione di schede ricevute da peer upstream. Impostarlo a 1 significa che condividi la tua scheda locale un hop a valle. Valori più alti consentono più hop.

SHARE LIMIT: 1

La direttiva RESHARE a livello di utente funziona diversamente — controlla se uno specifico client connesso può ulteriormente ricondividere ciò che riceve da te. Un valore di 0 significa nessuna ricondivisione; 1 significa che possono ricondividere un hop. Questo è importante se stai vedendo i canali del tuo server cccam apparire su server che non hai autorizzato.

I file CCcam.providers e CCcam.channelinfo spiegati

Questi due file confondono le persone perché sembrano funzionali ma non lo sono. Entrambi sono solo cosmetici.

/usr/share/CCcam/CCcam.providers mappa gli ID provider a nomi di operatore leggibili dall'uomo. Fa sì che i tuoi log dicano "Viasat" invece di "042800." Non fa assolutamente nulla per influenzare quali canali vengono decriptati. La stessa storia per /usr/share/CCcam/CCcam.channelinfo — mappa i SID ai nomi dei canali per la leggibilità dei log. Utile per il debug, irrilevante per la decriptazione.

Il formato channelinfo è una voce per riga: SID in esadecimale, quindi il nome del canale. Per esempio:

1234 BBC One HD
5678 Sky Sports 1

Posiziona il file dove il tuo CCcam.cfg lo riferisce. Se manca, CCcam ritorna semplicemente a registrare i valori esadecimali grezzi.

Verifica quali canali il tuo server può decriptare

Non dovresti indovinare se il tuo server può decriptare un canale. CCcam ti fornisce un'interfaccia HTTP integrata e output di log che ti dicono esattamente cosa sta accadendo — se sai come leggerli.

Lettura dell'interfaccia Web di CCcam (Porta 16001) per ispezionare i CAID attivi

Per impostazione predefinita, CCcam espone un'interfaccia web sulla porta 16001. Assicurati che il tuo CCcam.cfg abbia:

HTTP PORT: 16001

Quindi accedi a http://<your-receiver-ip>:16001 in un browser. Vedrai sezioni per schede connesse, client attivi, condivisioni e cronologia ECM. La sezione schede è il tuo punto di partenza — elenca il CAID di ogni scheda, l'ID provider, il conteggio degli hop e il livello di ricondivisione.

Un avvertimento importante: se stai eseguendo CCcam dietro NAT e hai inoltrato la porta 12000 per le connessioni client, la porta 16001 è separata e necessita della sua propria regola di inoltro. Molte persone inoltrano la porta del client CCcam ma dimenticano

Interpretazione delle sezioni "Cards" e "Shares" nell'interfaccia web

La sezione delle carte mostra hop=0 per le carte fisiche inserite localmente. Hop=1 significa che la carta è a una C-line di distanza, hop=2 significa due hop, e così via. Man mano che il conteggio dei hop aumenta, la latenza aumenta e l'affidabilità tende a diminuire.

La sezione delle condivisioni mostra quali client downstream sono connessi e a cosa hanno acceduto. Se un client è connesso ma la tabella delle condivisioni non mostra alcuna attività su uno specifico CAID, o non lo stanno richiedendo o i tuoi filtri lo stanno eliminando prima che lo raggiungano.

Utilizzo dell'output del log di CCcam per tracciare una richiesta ECM non riuscita

Imposta DEBUG: 1 in CCcam.cfg per la traccia ECM di base. Per un output più dettagliato usa DEBUG: 3, ma aspettati file di log di grandi dimensioni. Una risposta ECM riuscita appare così:

ECM 0919/000000/1234 answered in 320ms by card 1

Un errore appare come uno di questi:

ECM 0919/000000/1234 - no card found
ECM 0919/000000/1234 - timeout after 3000ms
ECM 0919/000000/1234 - card returned error

"Nessuna carta trovata" significa che nessuna carta nel tuo pool corrisponde a quella combinazione CAID/provider — controlla i tuoi filtri IGNORE/PROVIDE. "Timeout" significa che è stata trovata una carta ma non ha risposto in tempo — problema di latenza. "La carta ha restituito un errore" di solito significa che manca l'autorizzazione dell'abbonamento per quel SID.

Correlazione del SID con un database di canali DVB

Se non sei sicuro quale CAID e SID utilizza uno specifico canale, devi guardare il PMT grezzo. I tool dvbsnoop e tzap (parte del pacchetto dvb-apps su Linux) ti permettono di sintonizzarti su un transponder e scaricare le informazioni del servizio.

tzap -c /etc/channels.conf "BBC One HD"
dvbsnoop -s pmt 1234

Il dump del PMT mostrerà le voci del descrittore CA inclusi il CAID e l'ECM PID. Confronta questi valori con ciò che CCcam mostra nell'interfaccia web. Se il CAID nel PMT non è nella tua tabella delle carte, questo è il tuo problema.

Test della decrittazione con un singolo canale noto prima di ridimensionare

Prima di aggiungere più C-line o regole di filtro complesse, testa con un canale che sai dovrebbe funzionare. Scegli un canale il cui CAID puoi verificare dal PMT, conferma che quel CAID appare nella tabella delle carte dell'interfaccia web, e prova a sintonizzarlo. Fai funzionare un canale in modo pulito, poi espandi. Questo isola i problemi di configurazione dai problemi di abbonamento.

Motivi comuni per cui i canali sono mancanti o non si decriptano

Questi sono gli errori che vedo più spesso, in ordine approssimativo di quanto spesso si verificano effettivamente. Ognuno ha un percorso diagnostico specifico.

La carta non ha il pacchetto di abbonamento per quel canale

Il CAID corrisponde, l'ID del provider corrisponde, ma il canale è nero. Il log dice "carta ha restituito un errore". Questo è un problema di livello di abbonamento — la carta semplicemente non ha l'autorizzazione per quel SID. Th

Mancata Corrispondenza CAID Tra Richiesta Client e Carta Server

Alcuni canali trasmettono su più CAID simultaneamente (chiamato overcrypt). Il tuo ricevitore potrebbe richiedere il canale utilizzando CAID 0x0606 mentre la tua carta gestisce solo CAID 0x0600. Il log mostrerà "nessuna carta trovata" anche se hai una carta per quel canale concettualmente. La correzione consiste nel controllare il PMT effettivo per tutti i descrittori CA e verificare quale CAID la tua carta gestisce. In configurazioni OScam bridged puoi configurare la priorità CAID — in pure CCcam potresti aver bisogno di forzare il client a richiedere un CAID specifico.

ID Provider Filtrato in CCcam.cfg

Controlla le tue regole IGNORE/PROVIDE. Se hai usato IGNORE CAID: ALL e hai dimenticato di aggiungere una riga PROVIDE per un ID provider, l'intero pacchetto viene silenziosamente eliminato. Il log non mostrerà alcun tentativo ECM che raggiunge quel provider. Fai un riferimento incrociato dell'ID provider dall'interfaccia web rispetto alle tue righe PROVIDE nella configurazione.

Hop Count o Livello Reshare Impostati Troppo Bassi

Se hai aggiunto una C-line a un peer e le carte di quel peer vengono visualizzate nell'interfaccia web con hop=1, ma i tuoi client downstream non riescono ad accedervi, controlla il tuo SHARE LIMIT. Un SHARE LIMIT di 0 significa che condividi solo le carte hop=0 (locali) — le carte del peer non vengono mai ricondivise ai tuoi client. Impostalo su 1 per consentire un livello di ricondivisione:

SHARE LIMIT: 1

Controlla anche il valore RESHARE assegnato al peer nella configurazione della tua C-line. Alcune build supportano il livello reshare per-peer nella sintassi della C-line.

Aggiornamenti EMM Bloccati — Titoli Carta Non Aggiornati

Questo uccide le configurazioni lentamente. Se RECEIVE EMM: no è nella tua configurazione (o assente in alcune build che disabilitano per impostazione predefinita), la carta smette di ricevere i messaggi di aggiornamento dei titoli dalla trasmissione. Nel corso del tempo i titoli dell'abbonamento scadono e i canali smettono di decrittare — spesso iniziando prima con i pacchetti premium.

RECEIVE EMM: yes

Imposta questo e riavvia CCcam. A seconda di quanto tempo EMM è stato disabilitato, potrebbero essere necessari da diversi minuti a un'ora affinché la carta riceva ed elabori tutti i suoi aggiornamenti di titoli. I titoli limitati nel tempo sono particolarmente vulnerabili qui — una carta che funzionava perfettamente può silenziosamente smettere di decrittare i canali a metà sessione mentre i suoi titoli memorizzati scadono senza rinnovo.

Latenza di Rete che Causa Timeout ECM su Canali Fast-Zapping

Il timeout ECM predefinito di CCcam è 3000ms. Su un ricevitore fast-zapping o quando si passa rapidamente tra canali, le richieste ECM devono completarsi prima del timeout o otterrai un errore "timeout". Se la tua connessione peer ha una latenza round-trip di 150-200ms e l'elaborazione della carta aggiunge altri 200-300ms, sei al limite.

Puoi regolare il timeout in CCcam.cfg:

ECM TIMEOUT: 5000

L'aumento di questo valore dà ai peer lenti più time ma possono rendere il cambio canale lento. Una soluzione migliore è ridurre la latenza effettiva — scegli peer geograficamente più vicini o su connessioni a bassa latenza.

Differenze del protocollo Newcamd o CS378X quando si esegue il bridging a OScam

Se stai eseguendo il bridging di CCcam a OScam tramite il protocollo Newcamd (configurato con NEWCAMD PORT: 15050 <DES key> in CCcam.cfg), i mismatch di versione o i mismatch della chiave DES causeranno errori silenziosi su CAID specifici. La voce /etc/oscam/oscam.server di OScam per la connessione CCcam deve corrispondere esattamente alla versione del protocollo:

[reader]
label = cccam_bridge
protocol = cccam
device = 127.0.0.1,12000
user = username
password = password
caid = 0919,0500

Se alcuni CAID funzionano attraverso il bridge e altri no, verifica il filtro CAID su entrambi i lati. OScam ha il suo filtro CAID per lettore che può bloccare i CAID indipendentemente dai filtri di CCcam. Presta attenzione anche ai mismatch di versione di CCcam tra server e client — le versioni precedenti di CCcam a volte non riescono nella negoziazione della condivisione per sistemi CA specifici quando la gestione del protocollo diverge.

Valutazione di una connessione peer CCcam remota per la copertura dei canali

Ottenere una C-line da un peer è solo l'inizio. La C-line stessa non ti dice quasi nulla su quali canali del server cccam sono effettivamente accessibili attraverso di essa.

Cosa una C-Line ti dice — e cosa non dice

Una C-line assomiglia a questa:

C: hostname.example.com 12000 myuser mypassword

È tutto. Quattro campi: host, porta, nome utente, password. La C-line contiene zero informazioni su quali CAID, ID provider o SID il peer condivide. Lo scopri solo dopo la connessione e l'ispezione della tabella delle condivisioni dell'interfaccia web. Chiunque affermi di offrire "X canali" in una descrizione C-line ti sta dicendo sulla copertura nominale dell'abbonamento della loro scheda, non quello che effettivamente riceverai — questi numeri si degradano con il conteggio dei hop, il carico del server e la configurazione dei filtri.

Come testare una C-Line prima di impegnarsi

Aggiungi la C-line al tuo CCcam.cfg, riavvia CCcam e controlla subito la porta 16001. Entro 30-60 secondi le schede del peer dovrebbero apparire nella tabella delle schede/condivisioni. Nota:

• Quali CAID appaiono — corrispondono a ciò di cui hai bisogno?
• Con quale conteggio di hop arrivano? Hop=1 è buono; hop=3 o superiore è una bandiera rossa.
• Verifica i tempi di risposta ECM nel log per un canale noto. Costantemente sotto 800ms è solido; oltre 1500ms causerà problemi.
• Osserva la stabilità della connessione per 10-15 minuti. Se il peer si disconnette e si riconnette ripetutamente, è un problema di affidabilità.

Criteri generici per valutare la qualità del canale del peer/server

Non dare per scontato che un peer sia buono solo perché si è connesso. Valutalo correttamente:

• Ping sotto 200ms all'host del server dalla tua rete
• Tempi di risposta ECM costantemente sotto 1500ms nel log di CCcam
• Le schede appaioring at hop=1 (schede direttamente collegate, non catene ricondivise)
• Nessun eccessivo ciclo di connessione visibile nel log CCcam nell'arco di un'ora
• Se il peer sostiene di servire molti client simultanei, verifica se i tempi di risposta ECM si degradano durante le ore di picco — i server sovraffollati mostrano chiaramente questo

Un peer che pubblicizza migliaia di canali attraverso molti hop è quasi sempre una catena di ricondivisione con latenza alta e affidabilità discutibile. Le schede locali a hop=0 o i peer diretti a hop=1 sono quello che desideri per i canali di cccam server affidabili.

Verifica del tempo di attività del peer e della risposta ECM tramite CCcam Web UI

La CCcam web UI mostra statistiche ECM per connessione se hai avuto registrazione di debug attiva. Guarda la sezione "clients" per il tempo di connessione e il numero ECM/tasso di successo. Un peer connesso da 20 ore con 5.000 ECM e solo 3 errori è affidabile. Un peer che mostra tassi di timeout del 40% nella cronologia ECM è spazzatura — passa oltre.

Comprensione dell'accesso a scheda condivisa rispetto a dedicata e il suo effetto sui canali

L'accesso condiviso significa che una scheda fisica sta servendo richieste ECM per molti client simultanei. Ogni richiesta ECM è sequenziale sulla scheda — la scheda elabora una alla volta. Sotto carico pesante, i tempi di risposta aumentano e i timeout aumentano. Questo è il motivo per cui i canali cccam server su un server condiviso pesantemente carico si congelano durante i tempi di visione di picco anche se il CAID è presente e la sottoscrizione è valida.

L'accesso dedicato — dove una scheda serve solo la tua connessione — elimina la contesa della coda. Le risposte ECM rimangono veloci indipendentemente da tutto il resto. Il compromesso è il costo e la disponibilità. Durante la valutazione di un peer, chiedi se la scheda è condivisa tra molti utenti o allocata specificamente per te. La risposta spiega molto su quello che sperimenterai.

Un'altra cosa da osservare: i canali DVB-S2 che utilizzano modulazione ACM o VCM richiedono hardware che supporti la codifica variabile. Se la scheda tuner del server non gestisce ACM, non può nemmeno ricevere quei transponder — il che significa che la scheda è irraggiungibile per quei canali anche se il CAID e la sottoscrizione sono perfettamente validi. Questo è un vincolo hardware all'estremità del server, non un problema di configurazione del software.