\n\n

Server CCcam su Linux: Installazione Completa& Guida alla Configurazione

\n\n

Configurare un server cccam su Linux da zero è uno di quei compiti che sembra semplice fino a quando non si incontra il primo errore di compatibilità binaria alle 23:00. Questa guida copre l'intero percorso: decisioni architettoniche, installazione del binario, sintassi del file di configurazione, regole del firewall e cosa fare quando le cose si rompono. Se hai una smartcard in mano e una macchina Linux pronta, ecco esattamente cosa devi sapere.

\n\n

Cosa Fa Davvero CCcam su Linux (e Quando Hai Bisogno di un Server)

\n\n

CCcam è un demone di condivisione di schede. Una macchina lo esegue con un lettore di smartcard fisico collegato — quello è il server. Altri dispositivi sulla tua rete (o attraverso Internet) si connettono ad esso e richiedono la decrittografia ECM per i canali che stanno cercando di guardare. Il server decrittografa utilizzando la scheda fisica e invia la Control Word al client. Tutto questo avviene su TCP, porta predefinita 12000.

\n\n

L'architettura è importante perché determina la tua configurazione. Un server ha una scheda collegata localmente ed espone F-line per i client in arrivo. Un client si connette in uscita utilizzando C-line. La maggior parte delle persone si confonde perché CCcam funziona su entrambi i lati — è lo stesso binario, solo configurato in modo diverso.

\n\n

Modalità Client vs. Server: Cosa Cambia nella Configurazione

\n\n

Non esiste un flag separato per la "modalità server". La distinzione è interamente in quali righe appaiono inCCcam.cfg. Se hai F-line (che definiscono gli utenti che si connettono a te) e una riga DEVICE che punta a un lettore locale, sei un server. Se hai solo C-line (che puntano verso un altro host), sei un client. Puoi anche essere entrambi simultaneamente — collegandoti upstream mentre servi client downstream — il che è come funzionano le cascades.

\n\n

Perché Linux è il Sistema Operativo Ospitante Preferito per CCcam

\n\n

L'affidabilità è il motivo principale. Una macchina Linux che esegue CCcam come servizio systemd si riavvierà automaticamente dopo un crash e sopravvivrà ai riavvii senza intervento. Windows non ha un'infrastruttura di demoni equivalente per questo. Inoltre, la maggior parte dei ricevitori satellitari basati su ARM che le persone usano realmente — Dreambox, VU+, Zgemma — eseguono Enigma2, che è Linux. Quindi il binario, gli script di inizializzazione e i percorsi di configurazione sono gli stessi su tutte le piattaforme.

\n\n

Requisiti Hardware: CPU, RAM e Supporto per Lettori di Smartcard Fisici

\n\n

CCcam non è affamato di risorse. Un processore da 500MHz e 64MB di RAM sono davvero sufficienti per un numero limitato di client. Qualsiasi macchina Linux moderna è enormemente sovraqualificata. Il vero vincolo è il lettore di smartcard: hai bisogno di un lettore interno (comune sull'hardware Dreambox) o di un lettore USB esterno riconosciuto dal kernel. Opzioni comuni includono sc8in1, lettori in stile phoenixrc e lettori USB standard conformi a CCID. Eseguidmesg | grep tty dopo aver collegato per confermare che è apparso — apparirà come/dev/ttyUSB0,/dev/ttyACM0, o simile a seconda del chipset.

\n\n

Installazione di CCcam su Linux: Binario, Dipendenze e Primo Avvio

\n\n

CCcam 2.3.0 è l'ultima versione che è mai circolata ampiamente. È closed-source, mai aggiornata, e gli sviluppatori originali sono da tempo scomparsi. Quello che hai è un binario statico o semi-statico — e su un server Debian o Ubuntu moderno a 64 bit, ciò crea immediatamente problemi perché è un binario ELF a 32 bit.

\n\n

Scegliere il Binario CCcam Giusto per la Tua Architettura

\n\n

Eseguifile CCcam su qualsiasi binario tu abbia. Vedrai qualcosa comeELF eseguibile LSB a 32 bit, ARM, EABI5 oELF eseguibile LSB a 32 bit, Intel 80386. Abbina il binario al tuo hardware. Binari ARM per ricevitori ARM. Binari x86 a 32 bit per server PC generici. Se sei su una macchina x86 a 64 bit, hai bisogno del binario x86 a 32 bit più il layer di compatibilità — non della build ARM, anche se ARM è in qualche modo disponibile.

\n\n

Installazione delle Dipendenze delle Librerie a 32 bit su Debian/Ubuntu

\n\n

Su un sistema Debian 11/12 o Ubuntu 22.04 fresco a 64 bit, il runtime a 32 bit non è installato per impostazione predefinita. Risolvi prima questo:

\n\n

dpkg --add-architecture i386\napt-get update\napt-get install libc6-i386 lib32gcc-s1

\n\n

Su versioni più vecchie di Ubuntu (pre-20.04) potresti vedereia32-libs menzionato in vecchi guide — quel pacchetto è scomparso. Usalibc6-i386 invece. Dopo l'installazione, verifica con ldd CCcam per controllare che tutte le librerie condivise siano risolte. Se stai eseguendo un contenitore Docker che è solo a 64 bit senza supporto multiarch, salta completamente CCcam e vai direttamente a OScam (trattato nella sezione 6).

\n\n

Posizionare il binario e impostare i permessi eseguibili

\n\n

cp CCcam /usr/local/bin/CCcam\nchmod +x /usr/local/bin/CCcam\nchown root:root /usr/local/bin/CCcam

\n\n

Sulle immagini dei ricevitori Enigma2, il binario di solito si trova in /usr/bin/CCcam ed è avviato da uno script init.d. Non spostarlo su quei sistemi — i loro script di inizializzazione si aspettano che sia in quel percorso.

\n\n

Eseguire CCcam come servizio systemd per il riavvio automatico

\n\n

Crea /etc/systemd/system/cccam.service con questo contenuto:

\n\n

[Unit]\nDescription=CCcam Card Server\nAfter=network.target\n\n[Service]\nExecStartPre=/bin/sleep 10\nExecStart=/usr/local/bin/CCcam\nRestart=on-failure\nRestartSec=5\nStandardOutput=journal\nStandardError=journal\n\n[Install]\nWantedBy=multi-user.target

\n\n

Il ExecStartPre=/bin/sleep 10 non è facoltativo se il tuo lettore di smartcard ha bisogno di un momento per inizializzarsi dopo l'avvio. Senza di esso, CCcam si avvia prima che il kernel finisca di configurare il lettore USB e registra "nessuna scheda trovata" — poi non riprova mai correttamente.

\n\n

systemctl daemon-reload\nsystemctl enable cccam\nsystemctl start cccam

\n\n

Verificare che il processo stia ascoltando sulla porta 12000

\n\n

ss -tlnp | grep 12000\n# oppure\nnetstat -tlnp | grep CCcam

\n\n

Dovresti vedere CCcam legato a0.0.0.0:12000 o un IP di interfaccia specifico. Se non appare nulla, controllajournalctl -u cccam -n 50 per errori di avvio.

\n\n

CCcam.cfg Approfondimento: Ogni Direttiva Che Devi Conoscere

\n\n

Il file di configurazione si trova in/etc/CCcam.cfg per impostazione predefinita. CCcam controlla prima lì. Alcuni script di avvio passano il percorso come argomento — controlla il tuo se le modifiche non vengono rilevate. Una cosa che colpisce costantemente le persone: le terminazioni di linea di Windows (CRLF) nel file di configurazione causano silenziosi errori di parsing su Linux. Se hai modificato questo file su Windows e lo hai trasferito, eseguidos2unix /etc/CCcam.cfg prima di fare il debug di qualsiasi altra cosa.

\n\n

I commenti usano# o// — entrambi funzionano. Le direttive non fanno distinzione tra maiuscole e minuscole per la parola chiave stessa, ma i valori (nomi utente, password, nomi host) sono sensibili alle maiuscole.

\n\n

Porta del Server e Indirizzo di Ascolto: Direttive SERVERPORT e BIND

\n\n

# Ascolta le connessioni in entrata dei client CCcam\nSERVERPORT: 12000\n\n# Collega a un'interfaccia specifica (consigliato)\n# BIND: 10.8.0.1

\n\n

Se hai più interfacce di rete — ad esempio, un'interfaccia WAN e un'interfaccia VPN — CCcam si collegherà a tutte di esse per impostazione predefinita (0.0.0.0). Questo è un problema di sicurezza. Usa la direttiva BIND per bloccarlo solo all'IP dell'interfaccia VPN. Maggiori informazioni su questo nella sezione firewall.

\n\n

Definire Lettori di Schede Locali: Linee DEVICE, CARDTYPE e BOXKEY

\n\n

# Definisci il lettore di smartcard fisico\nDEVICE: /dev/ttyUSB0 SR\nCARDTYPE: 0\nBOXKEY: 00 00 00 00 00 00 00 00

\n\n

Il percorso DEVICE deve corrispondere a ciò chedmesgmostra. Se il tuo lettore appare come/dev/ttyACM0invece di/dev/ttyUSB0, la configurazione deve dire/dev/ttyACM0.Sbagliare questo è uno dei motivi più comuni per gli errori "nessuna scheda trovata". CARDTYPE 0 significa auto-rilevamento, che funziona per la maggior parte delle schede. BOXKEY è rilevante per le schede Nagravision che utilizzano una boxkey — lasciala a zero se la tua non lo fa.

\n\n

Aggiunta di Client C-line: Analisi della Sintassi C:

\n\n

Una C-line dice a questo server di connettersi verso un altro server CCcam:

\n\n

C: remote.host.example 12000 myusername mypassword {0:0:1} 01

\n\n

Analizzando:remote.host.exampleè il nome host o l'IP del server upstream.12000è la porta.myusernameemypasswordsono le tue credenziali su quel server.{0:0:1}è un filtro CAID opzionale nel formato{CAID:ProviderID:1}— un valore di0:0:1 significa accettare tutti i CAID. Il finale01 è il conteggio dei salti per la condivisione delle schede ricevute da questa linea.

\n\n

Aggiunta di utenti F-line (connessioni in entrata): F: Sintassi e limiti di salto

\n\n

Le F-line definiscono chi è autorizzato a connettersi al tuo server:

\n\n

F: client1 strongpassword 1 0 0 0 { 1830:000000:1 }\nF: client2 anotherpass 1 0 0 0 { 0:0:1 }

\n\n

I campi dopo la password sono: livello di condivisione (1 = può condividere un salto), salto minimo della scheda (0 = schede locali), gruppo CAID, gruppo ident e un blocco di filtro CAID opzionale. Il filtro{ 1830:000000:1 } limita questo utente al CAID 0x1830 solo. Usa password forti e uniche per ogni F-line — queste sono le credenziali che i tuoi clienti inseriscono nelle loro C-line.

\n\n

B-line per bloccare ID provider specifici

\n\n

B: 1234 000000

\n\n

Le B-line bloccano una specifica combinazione CAID/provider dalla condivisione. Se hai una scheda con più provider e vuoi trattenere uno, ecco come fare. Il formato èB: CAID ProviderID.

\n\n

LIMITI DI CONDIVISIONE e CONTEGGIO SALTI: Controllo della profondità di condivisione

\n\n

IL CONTEGGIO DEI SALTI controlla quante volte una scheda può essere condivisa prima che CCcam smetta di passarla ulteriormente. Impostalo nelle F-line (per utente) o globalmente:

\n\n

LIMITI DI CONDIVISIONE: 3

\n\n

Un CONTEGGIO DEI SALTI di 0 significa che la scheda è locale e non sarà condivisa affatto. Un valore di 1 significa che può andare a un salto verso i clienti, ma quei clienti non possono condividerla. Mantieni questo il più basso possibile — catene di condivisione profonde rallentano i tempi di risposta ECM e creano problemi di responsabilità.

\n\n

Direttive LOG e DEBUG per la risoluzione dei problemi

\n\n

LOGFILE: /var/log/cccam.log\nLOGLEVEL: 1\nDEBUG: 0

\n\n

LOGLEVEL 1 ti fornisce eventi di connessione e attività ECM senza sovraccaricare il disco. Imposta DEBUG su 1 temporaneamente quando stai cercando un problema specifico — è verboso e vorrai disattivarlo di nuovo. L'interfaccia web sulla porta 16001 (credenziali predefinite: admin/admin — cambiale immediatamente) mostra lo stato della scheda in tempo reale, i client connessi e il timing ECM, che è molto più facile da leggere rispetto ai log grezzi durante la diagnosi.

\n\n

Firewall, Rete e Port Forwarding per CCcam

\n\n

Qui è dove una configurazione del server cccam su Linux si blocca più comunemente. Il servizio è in esecuzione, la configurazione sembra corretta, ma i client non possono connettersi. Nove volte su dieci è una regola del firewall o un problema di NAT.

\n\n

Apertura della porta TCP 12000 con iptables e ufw

\n\n

Utilizzando iptables direttamente:

\n\n

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT\n# Salva le regole in modo che sopravvivano al riavvio:\niptables-save > /etc/iptables/rules.v4

\n\n

Oppure, se stai usando ufw:

\n\n

ufw allow 12000/tcp\nufw reload

\n\n

Se vuoi limitare solo agli IP dei client conosciuti (pratica molto migliore):

\n\n

iptables -A INPUT -p tcp --dport 12000 -s 203.0.113.45 -j ACCEPT\niptables -A INPUT -p tcp --dport 12000 -j DROP

\n\n

Collegare CCcam a un'interfaccia specifica per evitare esposizione

\n\n

Se il tuo server ha un'interfaccia pubblica (eth0) e un'interfaccia VPN (wg0 o tun0), non lasciare CCcam in ascolto su entrambe. Aggiungi la direttiva BIND in CCcam.cfg con l'IP dell'interfaccia privata/VPN. I client si connettono tramite la VPN e la porta 12000 non è mai esposta a Internet pubblico. Questo è il modo corretto di farlo.

\n\n

Utilizzare un tunnel VPN (WireGuard/OpenVPN) invece di esporre pubblicamente la porta 12000

\n\n

WireGuard è la scelta migliore in questi giorni: meno overhead rispetto a OpenVPN, configurazione più semplice e il modulo del kernel è ora integrato dal Linux 5.6. Configura un peer WireGuard tra il tuo server e ogni client, assegna loro indirizzi in una subnet privata (ad esempio, 10.8.0.0/24), collega CCcam a 10.8.0.1 e inserisci quell'indirizzo nelle C-line lato client. Nessuno che scansiona Internet vedrà mai la porta 12000.

\n\n

NAT e Port Forwarding se il Server è Dietro un Router Domestico

Se il tuo server Linux è su una rete domestica, devi inoltrare la porta TCP 12000 sul tuo router all'IP locale del server. La maggior parte dei router chiama questo "port forwarding" o "server virtuale". Imposta la porta esterna su 12000, protocollo TCP, IP interno all'indirizzo LAN del tuo server (rendilo statico, sia tramite riserva DHCP che configurazione manuale), porta interna 12000. Poi i client usano il tuo IP pubblico nelle loro C-line.

Un problema principale: se il tuo ISP utilizza CGNAT (carrier-grade NAT), in realtà non hai un IP pubblico: ne condividi uno con decine di altri clienti e non c'è modo di inoltrare le connessioni in entrata. La soluzione è affittare un VPS economico, eseguire WireGuard su di esso e tunnelare il traffico CCcam attraverso quello. Il VPS diventa il punto finale pubblico; il tuo server domestico comunica attraverso il tunnel.

DNS Dinamico per Server Senza un IP Statico

Se il tuo IP pubblico cambia, i client con il tuo vecchio IP nelle loro C-line non riusciranno a connettersi. Usa un servizio DNS dinamico e inserisci il nome host (ad esempio,myserver.ddns.net) nelle C-line invece di un IP nudo. Esegui un client di aggiornamento DDNS comeddclient

sul tuo server Linux per mantenere il record aggiornato. La maggior parte dei router domestici ha questa funzionalità integrata.

Inoltre: se il tuo ISP blocca specificamente il TCP in entrata sulla porta 12000 (alcuni lo fanno), cambia SERVERPORT in qualcosa di meno appariscente come 15000 o 8080, aggiorna la regola di port forwarding del tuo router e aggiorna ogni C-line dei client per corrispondere.

Risoluzione dei Problemi Comuni del Server CCcam su Linux

Il debug di un server cccam su Linux segue uno schema piuttosto coerente: elimina i livelli uno alla volta, partendo dal basso (il processo è anche in esecuzione?) fino al networking, poi alla configurazione, poi alla rilevazione della scheda.

CCcam Parte ma i Client Non Possono Connettersi: Lista di Controllo

• Conferma che il processo sia effettivamente in esecuzione:systemctl status cccam
• Conferma che stia ascoltando:ss -tlnp | grep 12000
• Testa localmente prima:telnet 127.0.0.1 12000 — se questo fallisce, il problema è il servizio, non la rete
• Controlla il firewall:iptables -L -n | grep 12000
• Controlla la linea F: il nome utente e la password devono corrispondere esattamente a ciò che il client utilizza nella sua linea C
• Conferma che l'IP/nome host della linea C del client si risolve correttamente dalla macchina del client

'Nessuna scheda trovata' o scheda non rilevata dopo la definizione del lettore

Inizia condmesg | tail -30 subito dopo aver collegato il lettore. Dovresti vedere una riga riguardante un nuovo dispositivo USB e il nodo del dispositivo a cui è stato assegnato. Se non lo vedi, il lettore non è riconosciuto a livello di kernel — potrebbe essere un problema di driver o un guasto hardware.

Se il lettore appare ma la scheda non viene rilevata, verifica che la riga DEVICE in CCcam.cfg punti esattamente al percorso mostrato in dmesg. Ricorda:/dev/ttyACM0 e/dev/ttyUSB0 sono dispositivi diversi e quello sbagliato fallirà silenziosamente. Controlla anche che l'utente del processo CCcam abbia permessi di lettura/scrittura sul dispositivo:ls -l /dev/ttyUSB0 e aggiungi l'utente CCcam aldialout gruppo se necessario.

Risposte ECM errate e fallimenti di decodifica (disallineamento CAID)

\n\n

Il cliente si connette, lo vedi nell'interfaccia web di CCcam sulla porta 16001, ma il canale non si decripta. Quasi sempre è un problema di mismatch CAID. Apri l'interfaccia web, controlla quali CAID il server sta effettivamente pubblicizzando. Poi controlla quale CAID utilizza il canale — lo schermo delle informazioni sul canale del tuo STB o un menu CAM mostrerà questo. Se non corrispondono, il server non può aiutare quel cliente indipendentemente dallo stato di connessione.

\n\n

Controlla anche il CONTEGGIO HOP. Se la linea F per quel cliente ha un valore di condivisione di 0 e la scheda è stata ricevuta da una linea C upstream (non locale), il cliente non ottiene nulla. CONTEGGIO HOP 0 blocca la condivisione di schede non locali.

\n\n

Carico Elevato / Tempi di Risposta ECM Lenti

\n\n

Una singola scheda fisica può elaborare solo un ECM alla volta. Se hai 10 clienti che richiedono la decrittazione simultaneamente, si mettono in coda e i tempi di risposta aumentano. Il canale può tremolare o andare nero momentaneamente. La soluzione è avere meno clienti, schede fisiche aggiuntive o linee C upstream aggiuntive con schede diverse. Non c'è soluzione software per questo — è un vincolo hardware.

\n\n

Posizione del File di Log e Come Leggere l'Output di Debug di CCcam

\n\n

Se LOGFILE è definito in CCcam.cfg, i log vanno lì. Altrimenti, quando si esegue sotto systemd, usajournalctl -u cccam -f per un tail live. Cerca righe contenenti "connesso", "ECM", "scheda" e codici di errore. Una risposta ECM di "0x00" di solito significa che la scheda ha risposto correttamente. Errori come "N/A" o messaggi di timeout indicano problemi con la scheda.

\n\n

CCcam che si Arresta all'Avvio: Correzione di Incompatibilità Binaria

\n\n

Eseguifile CCcam prima. Poi eseguildd CCcam. Se vedi "non un eseguibile dinamico" il binario è collegato staticamente e dovrebbe semplicemente funzionare. Se vedi librerie non risolte ("non trovate"), installa i pacchetti mancanti a 32 bit. Se CCcam esce immediatamente con "Errore di formato esecutivo", hai un completo mismatch di architettura — un binario ARM su x86, per esempio. Ottieni il binario giusto per la tua piattaforma.

\n\n

CCcam vs OScam come Server Linux: Quando Passare

\n\n

Se stai iniziando da zero oggi, considera seriamente OScam. CCcam 2.3.0 è un software abbandonato — nessuna patch, nessun aggiornamento, nessun codice sorgente da controllare. OScam è attivamente mantenuto, open-source (GPL) e supporta un superset di ciò che fa CCcam. L'unico motivo per rimanere su CCcam è se hai specificamente bisogno della compatibilità del client CCcam con dispositivi legacy che non supportano il protocollo nativo di OScam — e anche in quel caso, OScam gestisce questa situazione.

\n\n

Differenze Chiave nell'Architettura

\n\n

CCcam è una scatola nera. Prendi il binario, lo configuri e speri che funzioni — non c'è modo di ispezionare o modificare gli interni. OScam è completamente open source, attivamente aggiornato per nuovi tipi di schede e problemi di sicurezza, e ha un modello di configurazione molto più ricco con filtri per lettore e per utente a una granularità che CCcam non può eguagliare. L'interfaccia web in OScam è anche sostanzialmente migliore rispetto alla pagina base di CCcam sulla porta 16001.

\n\n

Filtraggio Superiore di CAID e ID Provider di OScam

\n\n

In OScam puoi filtrare per CAID, ID provider, ID servizio e persino specifici ECM pids — tutto in modo indipendente per lettore, utente e profilo. Il filtraggio di CCcam è grossolano in confronto. Se stai utilizzando una scheda con più pacchetti di provider e hai bisogno di un controllo chirurgico su ciò che ogni client può accedere, OScam è lo strumento giusto per il lavoro.

\n\n

Esecuzione di OScam come Server Protocollo CCcam (Ascoltatori cs378x / cs357x)

\n\n

OScam può parlare il protocollo CCcam nativamente. Questo significa che i tuoi client CCcam esistenti non devono cambiare affatto le loro C-line — OScam risponde sulla porta 12000 e loro non si accorgono della differenza.

\n\n

In/etc/oscam/oscam.conf, aggiungi un blocco di ascolto:

\n\n

[cs378x]\nport = 12000\nkey = 0102030405060708091011121314151617181920

\n\n

Il modulo cs378x gestisce le connessioni del protocollo CCcam versione 2.x. Usa cs357x per varianti più vecchie del protocollo CCcam. Gli utenti sono quindi definiti in/etc/oscam/oscam.user conprotocol = cccam.

\n\n

Percorso di Migrazione: Conversione di CCcam.cfg in File di Configurazione OScam

\n\n

Le C-line di CCcam diventano voci lettore in/etc/oscam/oscam.server:

\n\n

[reader]\nlabel = upstream1\nprotocol = cccam\ndevice = remote.host.example,12000\nuser = myusername\npassword = mypassword\ncaid = 1830\nident = 1830:000000

\n\n

Le F-line di CCcam diventano voci utente in/etc/oscam/oscam.user:

\n\n

[account]\nuser = client1\npwd = strongpassword\nprotocol = cccam\ngroup = 1\ncaid = 1830

\n\n

La conversione è meccanica ma richiede di andare riga per riga. Non esiste uno strumento automatico che gestisca ogni caso limite in modo affidabile. Prenditi un'ora e fallo manualmente — ne vale la pena per la manutenzione a lungo termine di una corretta configurazione OScam rispetto a un'installazione legacy di server cccam su Linux.

\n\n