Guida al ricevitore TV satellitare 2026: configurazione CCcam e OScam

Questa guida al ricevitore TV satellitare 2026 copre ciò che devi effettivamente sapere prima di toccare un file di configurazione — compatibilità hardware, percorsi di configurazione, differenze di protocollo e come diagnosticare gli errori quando le cose vanno male. Che tu stia valutando un nuovo decoder o cercando di far funzionare correttamente una configurazione esistente, i dettagli tecnici qui si basano su veri deployment Enigma2, non su testo pubblicitario.

CCcam e OScam non sono plug-and-play. L'hardware del ricevitore, l'immagine firmware e l'architettura binaria devono essere allineati. Se sbagli uno qualsiasi di questi aspetti passerai ore a debuggare qualcosa che avrebbe dovuto richiedere 20 minuti.

Cosa rende un ricevitore compatibile con CCcam/OScam nel 2026

La risposta breve: se il tuo ricevitore non esegue Linux, avrai una brutta esperienza. CCcam e OScam sono binari Linux. Dipendono da chiamate di sistema Linux, percorsi di file e interfacce di dispositivi che semplicemente non esistono su firmware closed proprietario — indipendentemente da cosa dicono le specifiche della scatola sulla confezione.

Firmware basato su Linux: la linea di base non negoziabile

CCcam e OScam hanno bisogno di un vero spazio utente Linux — procfs, albero /dev, filesystem scrivibile e la capacità di eseguire binari. I ricevitori economici che eseguono firmware proprietario derivato da Android o completamente closed non possono ospitare questi processi nativamente. Dovresti prima flashare un'immagine di terze parti, e non tutti i chipset lo supportano.

Le immagini basate su Enigma2 come OpenATV, OpenPLi e OpenVix ti forniscono un vero ambiente Linux già pronto all'uso. Queste immagini includono gestori di pacchetti, accesso SSH e la giusta struttura di directory (/etc/, /tmp/, /var/log/) che CCcam e OScam si aspettano.

Enigma2 vs sistema operativo proprietario: differenze chiave per la condivisione di schede

I ricevitori con firmware proprietario — soprattutto i marchi più economici venduti con vari marchi privati — bloccano il sistema operativo. Niente SSH, niente /etc scrivibile, nessun modo di inserire un binario personalizzato e farlo eseguire all'avvio. Alcuni sono stati violati con firmware della comunità, altri no. Enigma2, al contrario, è open source e progettato per accettare binari plugin e client softcam.

La differenza funzionale è immediata: su Enigma2 puoi installare CCcam tramite un pacchetto .ipk o inserire manualmente il binario, configurarlo in /etc/CCcam.cfg e avviarlo con uno script init. Su firmware proprietario, nessuno di questi percorsi esiste.

Architetture hardware: supporto MIPS, ARM ed emulazione

I ricevitori satellitari più vecchi — Dreambox DM800, vari decoder clonati — usano processori MIPS. La maggior parte dell'hardware dal 2020 in poi usa ARM (tipicamente ARMv7 o AArch64). La distinzione è importante perché i binari CCcam e OScam sono compilati per architettura. Un binario MIPS non funzionerà su un ricevitore ARM e viceversa.

Famiglie di chipset degne di nota: serie Broadcom BCM7xxx (supporto driver solido, comune in Dreamb

ox e hardware Vu+), HiSilicon Hi35xx (trovato in box Zgemma, buon supporto Enigma2), e Amlogic S905/S922 (comune in box Android ibridi, il supporto Enigma2 dipende dall'immagine). Tutti e tre supportano CCcam/OScam quando abbinati a un'immagine Enigma2 corretta.

Modalità lettore scheda interno vs client solo in rete

Se vuoi ospitare una smartcard fisica localmente, il tuo ricevitore ha bisogno di un lettore di schede interno esposto come /dev/sci0 (o /dev/sci1 per uno slot secondario). OScam ha bisogno di quel percorso del dispositivo per leggere la scheda. Se non esiste, il lettore non si inizializzerà indipendentemente da come configuri oscam.server.

I lettori di schede esterni collegati tramite USB compaiono come /dev/ttyUSB0 o simili. Hanno bisogno che i moduli kernel siano caricati prima che OScam possa vederli — comunemente cp210x per gli adattatori Silicon Labs o pl2303 per i chip Prolific. Caricali con modprobe cp210x e verifica con dmesg | tail.

La modalità solo client (nessuna scheda fisica, puro client di rete) è più semplice — hai solo bisogno del binario per funzionare e dello stack di rete per raggiungere il tuo server remoto. Nessun /dev/sci0 richiesto.

Verificare il chipset del tuo ricevitore rispetto agli elenchi noti e affidabili

Prima di acquistare qualsiasi cosa, controlla le pagine di compatibilità hardware di OpenPLi o OpenATV — elencano i chipset supportati e la disponibilità delle immagini. Se il tuo box non è in nessuno dei due elenchi, stai giocando d'azzardo. I forum della comunità per Vu+, Dreambox e Zgemma sono anche affidabili per confermare quali immagini Enigma2 sono attivamente mantenute per un determinato modello.

Esegui uname -m su SSH per confermare l'architettura dopo il flashing. Otterrai mipsel, armv7l o aarch64 — corrispondilo esattamente quando scarichi i binari.

Installazione e configurazione di CCcam su ricevitori Enigma2

CCcam è più vecchio di OScam e più semplice nella struttura. La sua config è un singolo file, il suo output di log è leggibile ed è ben compreso. Per configurazioni solo client che si collegano a un server remoto, funziona ancora bene nel 2026 purché il server supporti il protocollo CCcam 2.3.x.

Ottenere il binario CCcam corretto per la tua architettura

I binari CCcam sono disponibili compilati per MIPS (mipsel), ARMv7 (arm) e AArch64. Verifica sempre con file CCcam dopo il download — ti mostrerà l'architettura ELF. Confrontalo rispetto all'output di uname -m sul tuo ricevitore. Eseguire quello sbagliato produce immediatamente un Exec format error, facile da diagnosticare ma che spreca tempo se non sai cosa cercare.

Posiziona il binario in /usr/bin/CCcam e rendilo eseguibile: chmod 755 /usr/bin/CCcam. Alcuni gestori softcam Enigma2 si aspettano che sia lì specificamente.

Posizione file di configurazione: /etc/CCcam.cfg spiegato riga per riga

La configurazione principale si trova in /etc/CCcam.cfg. Una configurazione minima funzionante per una configurazione solo client è simile a questa:# Configurazione client CCcam C: server.example.com 12000 myuser mypass yes RESHARE = 0 MINIMIZE RESSOURCES = yes NEWCAMD STANDARD = yes LOG FILE = /tmp/CCcam.log LOG LEVEL = 5

Questo è l'intero file per un client di base. Tutto il resto è facoltativo o necessario solo se stai ricondividendo ai client downstream.

Sintassi C-line e F-line: cosa significa ogni campo

Una C-line connette il tuo ricevitore a un server CCcam remoto. Il formato:

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

Scomponendolo con un esempio reale:

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

• server.example.com — hostname o IP del server remoto
• 12000 — porta TCP predefinita di CCcam
• myuser / mypass — credenziali fornite dal server
• yes — richiedi inoltro EMM (necessario per il rinnovo della scheda)
• 1830:000000 — filtro facoltativo CAID e ID provider; lascia vuoto per richiedere tutti i CAID disponibili

Una F-line definisce un client locale che stai servendo — per ricondividere a un'altra box sulla tua LAN:

F: peeruser peerpass 1 0 0 0

I campi dopo le credenziali sono il livello di ricondivisione, i flag di condivisione EMM e le impostazioni AU. Per una configurazione domestica tipica probabilmente non hai bisogno di F-line.

Impostazione CAID, ID provider e limiti di ricondivisione

RESHARE = 0 impedisce al tuo ricevitore di ricondividere le schede downstream. Imposta questo a meno che tu non abbia un motivo specifico per ricondividere — riduce il carico e evita abusi del protocollo da misconfigurazioni. I valori CAID (come 0604 per Irdeto, 1830 per Nagravision, 0B00 per Conax) dicono a CCcam quali sistemi di crittografia richiedere. Se lasciato vuoto nella C-line, il server condividerà quello a cui ha accesso.

Abilitazione debug logging: /tmp/CCcam.log e flag di livello log

LOG LEVEL = 5 fornisce output dettagliato. Visualizzalo in tempo reale:

tail -f /tmp/CCcam.log

Il livello 1 riguarda solo gli errori. Il livello 5 include richieste ECM, risposte, timing e eventi di connessione. Usa il livello 5 per la diagnostica, scendi al livello 1 per l'operazione normale per evitare di riempire /tmp.

Avvio di CCcam come servizio: init.d vs systemd su immagini moderne

La maggior parte delle immagini Enigma2 attuali utilizza ancora SysVinit. Lo script init va in /etc/init.d/CCcam. Uno di base:

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

Nota: le immagini Enigma2 spesso forniscono un plugin softcam manager. Se lo usi per avviare CCcam, non avviare anche CCcam manualmente — entrambe le istanze tenteranno di associare la porta 12000 e una avrà esito negativo silenziosamente. Verifica con ps aux | grep CCcam per confermare che è in esecuzione solo un'istanza.

Alcuni nuovi

```r immagini (OpenATV 7.x, late OpenPLi builds) si sono spostate verso systemd. Posizionare un file di unità in /etc/systemd/system/CCcam.service e abilitare con systemctl enable CCcam.

Inoltre: se il tuo ricevitore esegue busybox sh invece di bash, gli script init che utilizzano sintassi specifica di bash ([[, $((...)), ecc.) falliranno silenziosamente. Scrivi script compatibili POSIX o ti chiederai perché CCcam non si avvia mai al riavvio.

Configurazione OScam per ricevitori satellitari: modalità server e client

OScam è più capace di CCcam in ogni modo misurabile — registrazione migliore, controlli per utente, filtro canale, supporto di più protocolli. Il compromesso è più file di configurazione e più luoghi in cui qualcosa può andare storto. Dedica un'ora a comprendere la struttura una volta e ripagherà.

Struttura del file di configurazione OScam: oscam.conf, oscam.server, oscam.user, oscam.services

I file di configurazione si trovano in /etc/oscam/ sulla maggior parte delle immagini Enigma2. Alcuni build personalizzati utilizzano /usr/local/etc/oscam/. Se non sei sicuro: find / -name oscam.conf 2>/dev/null.

I quattro file che avrai sempre bisogno:

• oscam.conf — impostazioni globali, binding delle porte, webif, registrazione
• oscam.server — definizioni dei lettori (server remoti o lettori di schede locali)
• oscam.user — account per i client che si collegano alla tua istanza OScam
• oscam.services — regole di filtro canale e CAID

Configurazione del lettore newcamd in oscam.server

Un blocco lettore che si connette a un server newcamd remoto:

[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

Il campo key è la chiave NM_key di 14 byte utilizzata nell'handshake DES di newcamd. Il valore predefinito sopra (0102030405060708091011121314) è quello che utilizza la maggior parte dei server — il tuo provider specificherà se è diverso. Se la chiave è sbagliata, OScam registra login incorrect e il lettore rimane offline.

Sezione globale oscam.conf: logfile, binding delle porte e 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

Il binding della porta [newcamd] 10000@1830:000000 dice a OScam di ascoltare sulla porta TCP 10000 per i client newcamd che richiedono CAID 1830 provider 000000. La sezione [cs378x] abilita la compatibilità del protocollo CCcam — maggiori dettagli di seguito.

Attenzione: se il tuo Dreambox o una scatola simile esegue la propria interfaccia web sulla porta 8888, l'interfaccia web di OScam non riuscirà a collegarsi. Cambia httpport in qualcosa come 8080 o 8889 in quel caso.

oscam.user: definire i client con filtri au, caid e ident

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

au = 1 abilita l'inoltro EMM (Entitlement Management Message) per questo utente. I messaggi EMM sono il modo in cui il provider della carta invia i rinnovi delle chiavi alla carta — senza questo, una carta fisica potrebbe smettere di funzionare dopo la scadenza della chiave corrente. Se stai eseguendo la modalità solo client senza carta locale, au non è rilevante.

oscam.services: limitare l'accesso ai canali per SID e CAID

Questo file ti consente di inserire nella whitelist o nella blacklist specifici ID servizio (identificatori canale). Un blocco base che consente tutto:

[services]
label = allowed
caid = 1830
sids = 

Lascia sids vuoto per consentire tutti gli SID per il CAID. Compilalo con valori SID specifici se desideri limitare l'accesso a canali particolari — utile per configurazioni multi-utente in cui account diversi dovrebbero vedere pacchetti di canali diversi.

Utilizzare l'interfaccia web di OScam sulla porta 8888 per monitorare lo stato della carta

Dopo aver avviato OScam, accedi a http://<receiver-ip>:8888. L'interfaccia web mostra lo stato del lettore, i tempi di risposta ECM, le connessioni attive e l'output del registro in tempo reale. È il modo più veloce per confermare che un lettore è online e sta decifrando. I tempi di risposta ECM superiori a 600ms nell'interfaccia web indicano latenza lato server o ritardo nella rotazione delle chiavi — previsto occasionalmente, ma valori cronici al di sopra di questo significano che qualcosa non va con il server o il percorso di rete.

OScam come bridge del protocollo CCcam: listener cs378x vs newcamd

Questo è qualcosa che la maggior parte delle guide ignora completamente. OScam può parlare il protocollo CCcam nativamente tramite il modulo cs378x. Abilita [cs378x] in oscam.conf con una porta (ad esempio, 9000) e OScam accetterà i client CCcam su quella porta mentre internamente utilizza newcamd o qualsiasi altro protocollo di lettore per recuperare le chiavi. Non devi scegliere tra CCcam e OScam — OScam può servire entrambi contemporaneamente.

Un avvertimento: OScam deve essere compilato con il supporto SSL affinché le connessioni TLS di cs378x funzionino. Verifica i tuoi flag di compilazione: oscam --build. Se vedi SSL: no nell'output, le connessioni cs378x che richiedono TLS falliranno silenziosamente senza un messaggio di errore utile. Avrai bisogno di una compilazione compilata con --enable-ssl.

Valutare un provider di server cardsharing: solo criteri tecnici

Questa guida del ricevitore televisivo satellitare 2026 non sarebbe completa senza affrontare il lato server. La tua configurazione locale può essere perfetta e otterrai comunque canali bloccati se il server è scadente. Ecco come valutare senza rimanere scottato.

Protocollo

supporto: CCcam 2.x vs OScam newcamd vs cs378x

Cerca provider che offrano almeno due opzioni di protocollo — tipicamente CCcam sulla porta 12000 e newcamd sulla porta 10000. I provider che supportano cs378x ti offrono una migliore integrazione nativa di OScam senza dover utilizzare un binario CCcam. I server con protocollo singolo sono un segnale d'allarme per la flessibilità; se quella porta viene bloccata dal tuo ISP, non hai un'alternativa.

Benchmark del tempo di risposta ECM: quali numeri contano davvero

Un tempo di risposta ECM inferiore a 300ms è buono. 300-600ms è accettabile per la maggior parte dei contenuti. Oltre 800ms causa artefatti di congelamento visibili — il decoder riceve la chiave di decodifica troppo tardi e perde fotogrammi. Vedrai questi tempi in /tmp/CCcam.log come valori in millisecondi accanto a ogni risposta ECM, o più chiaramente nella tabella del reader della webif di OScam.

Profondità di reshare e indicatori di ridondanza dei peer

In CCcam.log, cerca i valori di conteggio HOP accanto alle risposte ECM. Un HOP di 1 significa che il server ha un lettore di scheda diretto — latenza più bassa, più affidabile. Un HOP di 2-3 significa schede condivise che passano attraverso server intermedi — ogni hop aggiunge ~50-150ms e introduce un ulteriore punto di errore. Evita server con conteggi HOP costantemente superiori a 3.

I provider che pubblicizzano più server di schede ridondanti (failover) sono teoricamente più stabili. Ma verifica osservando intenzionalmente cosa succede durante le ore di punta — se il failover funziona, i tempi di risposta ECM non aumenteranno drammaticamente. Se lo fanno, la ridondanza è solo marketing.

Test di stabilità: come interpretare i rapporti ECM/EMM di CCcam.log

Esegui una prova di 24-48 ore e tail del log. Due metriche contano:

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

Calcola il rapporto. Più del 5% di ECM 'not found' è un problema — significa che il server non dispone delle chiavi per i canali che stai cercando di guardare. Questo è diverso da un problema di connettività; la connessione è attiva ma il server non riesce a decodificare quello che stai richiedendo. Potrebbe essere un mancato CAID, potrebbe essere una scheda che non ha il pacchetto di cui hai bisogno.

Sicurezza della connessione: tunnel crittografati vs rischi di protocollo in chiaro

Newcamd e CCcam in chiaro trasmettono credenziali e dati ECM in formati in chiaro o debolmente crittografati. Per configurazioni paranoiche, avvolgere la connessione in un tunnel VPN (WireGuard funziona bene sulle moderne immagini Enigma2) elimina l'esposizione. Se il provider offre cs378x avvolto in TLS e la tua build OScam supporta SSL, usalo. Altrimenti, assicurati almeno di non utilizzare NM_keys predefinite o password facilmente indovinabili.

Valutazione dei periodi di prova senza impegnarsi in abbonamenti lunghi

Qualsiasi server che valga la pena utilizzare offre una prova di 24-48 ore. Usa quella finestra per eseguire l'analisi del log sopra, controllare i tempi di risposta ECM durante le ore di punta e non, e verificare che i CAID e SID specifici di cui ti importa funzionino effettivamente. Non valutare in base a un canale per cinque minuti — questo non ti dice nulla sulla stabilità.

Troublesh

Risoluzione dei problemi comuni del ricevitore e dei guasti del protocollo

La maggior parte dei guasti seguono pattern prevedibili. Ecco come diagnosticare ogni problema senza indovinare.

ECM non trovato: mancata corrispondenza CAID vs scadenza chiave lato server

Pattern di log da cercare:

grep 'not found' /tmp/CCcam.log

Se questo si verifica ripetutamente per un canale specifico, il CAID o l'ID del provider nella tua C-line non corrisponde a quello offerto dal server. Confronta il CAID utilizzato dal canale (visibile nell'interfaccia web OScam o tramite le informazioni zap) con il filtro della tua C-line. Se il CAID corrisponde ma è ancora "non trovato", la scheda del server non ha accesso al pacchetto di quel canale — un problema di abbonamento/provider, non di configurazione.

Canali congelati: timeout ECM vs diagnosi della latenza di rete

Il congelamento con la connessione che mostra attiva di solito significa che le risposte ECM arrivano troppo lentamente. Controlla i tempi di risposta nel log. Inoltre esegui:

ping -c 100 server.example.com

Cerca variabilità (variazione nei tempi di ping), non solo latenza media. Una media di 10ms con picchi di 200ms causerà congelamenti periodici. Se la variabilità è bassa ma i tempi ECM sono alti, il problema è l'elaborazione lato server — la scheda è lenta o il server è sovraccarico.

CCcam il binario si blocca all'avvio: correzione della mancata corrispondenza dell'architettura

Se CCcam esce immediatamente con Exec format error, esegui:

file /usr/bin/CCcam
uname -m

file dirà qualcosa come ELF 32-bit LSB executable, MIPS o ELF 32-bit LSB executable, ARM. Confronta questo con l'output uname -m del tuo ricevitore. Inoltre nota: un binario MIPS a 32 bit non funzionerà su un ricevitore MIPS a 64 bit anche se entrambi dicono "MIPS" — l'ABI deve corrispondere esattamente.

Il lettore OScam mostra "offline": connessione rifiutata vs errore di autenticazione

Controlla /var/log/oscam/oscam.log:

• connect to [ip]:port failed — server non raggiungibile, controlla IP/porta e firewall
• login incorrect — credenziali errate o NM_key sbagliato in oscam.server
• connection refused — porta 10000 (o 12000) bloccata; controlla iptables -L -n sul ricevitore e su qualsiasi router tra te e il server

I ricevitori con dual-boot Android/Enigma2 sono un problema specifico qui — le regole del firewall di Android possono persistere nell'avvio Enigma2, bloccando le connessioni in uscita su quelle porte. Controlla con iptables -L -n | grep 12000.

Ritardo di zapping superiore a 3 secondi: problema del conteggio degli hop di reshare

Le modifiche lente dei canali (>3s) con decrittazione eventualmente riuscita indicano conteggi degli hop di reshare elevati. Ogni hop aggiunge latenza a ogni richiesta ECM. Guarda i valori HOP in CCcam.log quando fai zapping — se vedi HOP:3 o superiore in modo coerente, il tuo server sta facendo reshare attraverso più livelli. Ciò è intrinseco alla topologia del server; non puoi risolverlo dal lato client. Trova un server con di

rect card access (HOP:1).

EMM non inoltrato: au=0 o filtro EMM lettore bloccante

Se una scheda locale fisica smette di essere aggiornata, controlla due cose. Primo: in oscam.user, l'account client necessita au = 1. Secondo: il lettore in oscam.server necessita l'elaborazione EMM abilitata. Cerca emmcache = 1 e verifica che non ci sia blockemm-unknown = 1 che blocca tipi EMM sconosciuti. Senza l'inoltro EMM, le schede di accesso condizionato che richiedono aggiornamenti periodici delle chiavi smetteranno di funzionare dopo la scadenza del periodo di validità corrente.

Lo sfasamento dell'orologio del ricevitore interrompe gli handshake del protocollo crittografato

Questo causa misteriose connessioni newcamd fallite senza errori ovvi. L'handshake di Newcamd include un passaggio di verifica del timestamp. Se l'orologio del tuo ricevitore è sfasato di più di pochi minuti, l'handshake fallisce e OScam registra qualcosa di non descrittivo. Correggilo:

ntpdate pool.ntp.org

Oppure configura ntpd per mantenere l'orologio sincronizzato permanentemente. La maggior parte delle immagini Enigma2 hanno ntpd disponibile — assicurati solo che sia abilitato nelle impostazioni dell'immagine o avviato al boot. Questo non è quasi mai menzionato in altre guide ed è una modalità di errore sorprendentemente comune quando i ricevitori perdono alimentazione e le batterie RTC muoiono.

Chiave ES per l'autenticazione (specificata esplicitamente nella riga N o nel config oscam.server), mentre CCcam utilizza il proprio handshake proprietario. OScam può servire client su entrambi i tipi di protocollo simultaneamente tramite porte listener separate in oscam.conf.