Miglior configurazione OScam Reader: guida alla configurazione di oscam.server 2026

Se ti sei mai ritrovato a fissare un file oscam.server appena creato chiedendoti perché metà dei parametri siano persino importanti, non sei il solo. La maggior parte delle guide si limita a incollare un blocco funzionante e a dirti di sostituire le tue credenziali. Questo ti fa connettere. Non ti fa decodificare in modo affidabile, e di certo non spiega perché il tuo reader mostra "CARD OK" mentre ogni canale continua a dare un errore ECM.

Questo è il mio tentativo di un vero e proprio walkthrough sulla miglior configurazione di un oscam reader — non un blocco copia-incolla, ma il ragionamento dietro ogni riga, così potrai fare debug da solo tra sei mesi quando qualcosa si romperà alle 2 di notte. Ho fatto girare OScam su di tutto, da un Raspberry Pi 3 a un VPS dedicato, e i pattern di errore si ripetono costantemente. Iniziamo dalla struttura del file, perché è lì che nasce la maggior parte della confusione.

Cos'è realmente un OScam Reader (e in cosa differisce da un Account)

Le persone usano "account," "line" e "reader" come se fossero intercambiabili. In OScam non lo sono. Un reader è una fonte di decodifica ECM/EMM — punto. Può essere una smartcard fisica inserita in un dispositivo Phoenix o Smargo collegato al tuo box, oppure può essere una connessione remota alla scheda di qualcun altro tramite un protocollo di rete. In entrambi i casi, dal punto di vista di OScam, un reader è semplicemente qualcosa a cui può chiedere "puoi decodificare questo ECM per me?"

La confusione di solito nasce dal confondere i tre file di configurazione che fanno funzionare un'installazione di OScam. oscam.conf contiene le impostazioni globali — modalità di load balancing, logging, porte webif, cose di questo tipo. oscam.user definisce i client che servi, cioè i box o i software che si connettono alla tua istanza OScam. E oscam.server è dove vivono i reader — ogni sorgente di scheda, locale o remota, ottiene un blocco [reader] in questo file. Sbaglia questa separazione e passerai ore a modificare il file sbagliato chiedendoti perché nulla cambia.

Reader vs. account vs. user: i tre file di configurazione

Pensala come una pipeline. Un client si connette usando le credenziali definite in oscam.user. Quell'utente viene assegnato a un gruppo. OScam quindi cerca in oscam.server qualsiasi reader che condivida quello stesso numero di gruppo e sia in grado di decodificare il caid richiesto. Se ne trova uno, l'ECM viene inoltrato a quel reader — che sia una scheda locale o un peer a tre salti di distanza — e il CW decodificato torna giù lungo la catena fino al client.

Quel collegamento di gruppo è l'elemento più trascurato in ogni tutorial sulla "miglior configurazione oscam reader" che io abbia letto. La gente configura un blocco reader perfetto, dimentica di impostare il numero di gruppo in modo che corrisponda al proprio user, e poi passa un'ora a risolvere un problema di connessione fantasma che non è mai stato un problema di connessione.

Reader di scheda locali vs. reader di rete (proxy)

Un reader locale comunica con hardware fisico — device = /dev/ttyUSB0 per un reader Phoenix seriale, ad esempio, con detect=CD o simile. Un reader di rete, a volte chiamato reader proxy, si connette via TCP/IP a un server OScam o CCcam remoto usando un protocollo come cccam, newcamd o cs378x. La maggior parte delle persone che oggi configura il cardsharing ha a che fare quasi esclusivamente con reader di rete, dato che l'hardware fisico delle smartcard è diventato meno comune al di fuori delle card farm dedicate.

Dove vivono i reader: oscam.server e il suo ruolo nella pipeline

Ogni reader ottiene la propria sezione [reader] in oscam.server, identificata da un'etichetta unica. OScam analizza questo file all'avvio (o al ricaricamento tramite webif) e tenta di stabilire ogni connessione reader in modo indipendente. La configurazione "migliore" qui non consiste nel stipare ogni parametro opzionale — consiste nello scrivere voci compatte, minime e con lo scope corretto, così che OScam non sprechi mai tempo o banda interrogando una fonte che non potrà mai rispondere.

Costruire il Reader di Rete Ideale in oscam.server

Ecco un esempio completo annotato per un reader con protocollo cccam. Analizzerò ogni riga dopo.

[reader]

La riga device è host,porta — e voglio essere chiaro, non esiste una porta standard universale per i protocolli di cardsharing. Vedrai 12000 usata comunemente per cccam e qualcosa nel range dei 5000 o 8000 per newcamd o cs378x, ma queste sono interamente definite dall'operatore. Chiunque gestisca la fonte ti dice la porta. Non dare per scontato che 12000 funzioni ovunque solo perché è comune.

Blocco [reader] completo: label, protocol, device, user, password, key

label è solo un identificatore interno — rendilo descrittivo, dato che lo leggerai costantemente nei log. protocol dice a OScam quale handshake usare. device è host,porta per i reader di rete. user e password sono le tue credenziali di accesso. Per i reader newcamd avrai bisogno anche di una riga key= contenente la chiave DES, di cui parlerò tra un attimo perché fa inciampare molte persone.

Scegliere protocol: cccam vs. newcamd vs. cs378x vs. mgcamd

cccam è il protocollo più comune per la condivisione peer-to-peer perché così tanti box e pannelli lo parlano nativamente. newcamd è più vecchio ma ancora ampiamente supportato, e richiede uno scambio di chiavi DES — tipicamente una chiave hex di 14 byte, e se la incolli male (troppo corta, spazi extra, maiuscole/minuscole sbagliate) il reader spesso resterà lì a fallire silenziosamente invece di dare un errore evidente.

cs378x vale la pena conoscerlo in particolare se stai collegando due box OScam tra loro — è essenzialmente camd35 su TCP con un controllo di integrità dei messaggi aggiunto, rispetto al più vecchio camd35 basato su UDP che non ne ha nessuno. Se entrambe le estremità fanno girare OScam, cs378x o newcamd tendono a essere più puliti e con meno overhead rispetto a cccam. Il supporto mgcamd esiste soprattutto per compatibilità all'indietro con box più vecchi che parlano solo varianti newcamd/cccam — non imposterai protocol=mgcamd in oscam.server stesso, dato che mgcamd è un'applicazione lato client, non un protocollo reader di OScam.

group, caid, ident e label routing per percorsi di decodifica puliti

Questa è la parte che quasi ogni guida salta, ed è esattamente il motivo per cui così tante persone finiscono con un reader che si connette bene ma non decodifica mai nulla. group collega il reader a utenti specifici — se il tuo user in oscam.user ha group = 1 e il tuo reader ha group = 1, OScam considera quel reader idoneo a servire quel client. Nessun numero di gruppo condiviso, nessun ECM raggiunge mai quel reader, indipendentemente da quanto correttamente sia configurato tutto il resto.

caid limita per quali sistemi di crittografia il reader viene interrogato. Se sai che la tua fonte trasporta solo Viaccess (0500) e Nagravision (0100), non lasciare caid vuoto — impostalo esplicitamente. ident va un livello più in profondità, restringendo a specifici ID provider all'interno di un caid, formattato come coppie caid:ident. Filtrare in modo aggressivo qui non è solo una configurazione ordinata — riduce direttamente gli errori ECM, perché OScam smette di sprecare cicli chiedendo a un reader canali per cui non avrebbe mai potuto rispondere in primo luogo.

cccversion, cccmaxhops, cccwantemu spiegati

cccversion deve corrispondere a ciò che il peer si aspetta — 2.3.0 e 2.3.2 sono le versioni comuni in circolazione. Sbaglia questo e spesso vedrai il reader connettersi con successo ma segnalare un conteggio schede sbagliato, oppure zero share del tutto, il che sembra un problema di permessi ma è in realtà un mismatch nell'handshake del protocollo. cccmaxhops limita quanti salti di ricondivisione di distanza può avere una scheda ed essere ancora accettata — valori più bassi significano che sei più vicino alla scheda sorgente, generalmente più veloce e stabile. cccwantemu controlla se vuoi includere schede emulate/basate su softcam; lascialo a 0 a meno che tu non voglia specificamente includerle nel tuo feed.

Ottimizzazione del Reader Best-Practice: Timeout, Caching, Fallback e Hop

Una volta che il reader si connette e decodifica, il livello successivo è la messa a punto — è qui che una configurazione semplicemente funzionante diventa una vera configurazione oscam reader setup best configuration affidabile, che regge le ore di punta e lo zapping tra canali senza scattare.

ecmtimeout / ecmwhitelist e perché 3000ms è un buon punto di partenza

ecmtimeout controlla per quanto tempo OScam attende la risposta di un reader prima di arrendersi e passare a un fallback. 3000ms è un valore di partenza ragionevole per la maggior parte delle fonti remote. Se lo imposti troppo basso otterrai un fallback prematuro — il reader stava per rispondere ma è stato interrotto, causando ritardi di zapping inutili e spreco di CPU mentre OScam ritenta altrove. Se lo imposti troppo alto ottieni il problema opposto: blocchi visibili sullo schermo mentre OScam attende pazientemente un reader lento o morto prima di passare finalmente al fallback.

fallback e fallback_percaid per la ridondanza

Un reader di fallback viene interrogato solo dopo che il reader primario fallisce o va in timeout — non serve per il bilanciamento del carico, è un'assicurazione. Configura questo in oscam.user o tramite impostazioni di fallback compatibili con lb_mode, e usa fallback_percaid quando vuoi un comportamento di fallback diverso per ogni sistema di cifratura invece di un unico reader di fallback generico per tutto.

le modalità cacheex 1/2/3 e quando un reader dovrebbe fare push o pull

Lo scambio di cache è davvero utile per velocizzare le decodifiche ripetute su una rete di box, ma è anche il punto in cui ho visto configurazioni implodere completamente. Le modalità: 1 è solo push, 2 è solo pull, 3 è push e pull in entrambe le direzioni. L'errore che le persone commettono costantemente è impostare cacheex mode 3 su entrambi i lati di una relazione peer — questo crea un loop in cui ciascuna parte continua a rispingere avanti e indietro le stesse voci di cache, intasando i log e a volte bloccando l'intera catena.

Lo schema corretto è asimmetrico. Se il box A è il tuo primario e il box B vuole la cache di A, B dovrebbe impostare cacheex mode 2 (pull) verso A, e A non dovrebbe essere impostato contemporaneamente per fare pull da B per lo stesso caid/dati. Se non stai risolvendo attivamente un problema specifico di latenza, lascia cacheex disattivato. Non è una funzione attiva per impostazione predefinita — è un'ottimizzazione mirata per topologie di rete specifiche.

lb_weight, lb_force_fallback e la strategia globale di loadbalance

Il bilanciamento del carico stesso è configurato globalmente in oscam.conf con lb_mode — la modalità 1 seleziona il reader più veloce in base al tempo di risposta misurato. Ma i singoli reader hanno lb_weight, che influenza quanto spesso OScam sceglie quel reader rispetto ad altri che servono lo stesso caid. Se hai due reader entrambi capaci di decodificare lo stesso caid ed entrambi di velocità simile, puoi finire con OScam che oscilla tra di loro, il che si manifesta come tempi di decodifica incredibilmente incoerenti nella webif da uno zap all'altro. Impostare una chiara differenza di lb_weight — diciamo 100 sul reader preferito e 50 su quello secondario — dice a OScam quale privilegiare effettivamente invece di trattarli come equivalenti.

audisabled, aureader e la gestione EMM

audisabled=1 dice a OScam di non elaborare gli aggiornamenti EMM tramite quel reader — cioè non tenterà di scrivere i pacchetti di aggiornamento sulla card. Questo conta molto con le card fisiche locali: se hai più reader in qualche modo puntati sulla stessa card fisica (insolito, ma capita con certi setup multi-client), lasciare che più di uno elabori le scritture EMM contemporaneamente può davvero corrompere lo stato interno della card. La soluzione è semplice — scegli un reader come scrittore EMM e imposta audisabled=1 su ogni altro reader che tocca la stessa card.

Verifica e risoluzione dei problemi di un reader che non decodifica

Ecco l'ordine diagnostico che uso realmente, ogni volta, prima di toccare un singolo valore di configurazione.

Lettura di oscam.log e della pagina webif Readers/Status

La prima tappa è sempre la scheda Readers nella webif. Lo stato mostra verde per connesso, rosso per non connesso. Se è rosso, si tratta puramente di un problema a livello di connessione — non perdere tempo a controllare i filtri caid ancora. Controlla la raggiungibilità di host/porta, conferma che il firewall consenta il traffico TCP in uscita su quella porta, verifica nome utente/password e conferma che la versione del protocollo corrisponda a quella attesa dal peer.

Connesso ma 'CARD OK' senza decodifica: mismatch dei filtri caid/ident

Se lo stato mostra connesso e persino "CARD OK", ma canali specifici continuano a non decodificare, questo quasi mai è un problema di connessione. Torna alle tue righe caid= e ident= e controlla di non aver escluso accidentalmente il caid usato da quel canale. Controlla anche che il numero di gruppo corrisponda effettivamente tra il reader e l'utente richiedente — ho risolto esattamente questo problema più volte di quante possa contarne, ed è sempre una di queste due cose.

'connesso' che sfarfalla: mismatch di versione o password/chiave DES

Un reader che si connette, poi si disconnette, poi si riconnette qualche secondo dopo — ripetutamente — di solito indica un mismatch di cccversion o, su newcamd, una chiave DES malformata. Controlla attentamente la lunghezza della chiave; dovrebbe essere esattamente 14 byte esadecimali senza caratteri estranei. Se il reader rimane connesso solo subito dopo un riavvio di OScam e poi si disconnette poco dopo, guarda i tuoi valori di reconnecttimeout e inactivitytimeout — un timeout troppo aggressivo interromperà connessioni che in realtà sono a posto, solo momentaneamente inattive.

Errori ECM, timeout ECM e diagnosi di 'no matching reader'

"No matching reader" nel log significa che OScam non è riuscito a trovare alcun reader nel gruppo giusto con lo scope caid/ident giusto per quell'ECM — vai a ricontrollare i tuoi filtri. Un vero e proprio timeout ECM nel log (rispetto a un rifiuto) significa che il reader era raggiungibile e nello scope ma non ha risposto in tempo, il che rimanda alla regolazione di ecmtimeout o a una latenza di rete reale verso quella fonte.

Usare il loglevel di oscam.log e i flag di debug -d in sicurezza

loglevel in oscam.conf controlla la verbosità — alzalo temporaneamente quando insegui un problema specifico, ma non lasciare attivo il logging a livello debug permanentemente, poiché farà gonfiare i tuoi file di log e può oscurare la vera riga di errore nel rumore. Usa i flag -d (come -d 1 per il debug del client, -d 2 per il debug del reader) dalla riga di comando per una breve sessione diagnostica, poi riabbassalo una volta trovato quello che cercavi.

Come valutare una fonte di card in modo generico (senza nomi)

Non ti dirò quale provider usare — non è davvero questo lo scopo di una buona scrittura tecnica, e francamente non invecchierebbe bene comunque. Quello che ti dirò è esattamente cosa misurare così puoi giudicare qualsiasi fonte da solo, usando nient'altro che la tua webif OScam.

Segnali di una fonte stabile: tempo di decodifica costante, bassa percentuale di errori ECM

Apri la pagina di stato Readers e osserva la colonna del tempo medio di decodifica per un'intera serata di uso reale, non solo un test di cinque minuti. Qualsiasi valore costantemente sotto i 300ms è solido. Se vedi oscillazioni ampie — 150ms in un momento, 2000ms in quello successivo — è una fonte con capacità backend instabile, e questo si manifesterà come blocchi durante i cambi di canale veloci anche se "funziona" in un test rapido.

Trasparenza sul protocollo/versione e cccversion corrispondente

Una fonte ben gestita ti dice esattamente quale protocollo, porta e versione usare — senza bisogno di indovinare. Se una fonte è vaga su quale cccversion impostare, o devi continuamente procedere per tentativi con la porta, questo è già un segnale su come viene gestita l'intera operazione.

Numero di hop, profondità di condivisione e perché meno hop decodificano più velocemente

Il numero di hop indica quante volte una card è stata ricondivisa prima di raggiungerti. Hop 1 significa che stai parlando con qualcosa di vicino alla card reale. Numeri di hop più alti indicano più livelli di ricondivisione tra te e la fonte, il che generalmente significa più latenza e più punti di guasto. Questo è genuinamente uno dei numeri più utili e misurabili che hai a disposizione, ed è visibile direttamente nei dettagli del reader nel webif.

Segnali d'allarme: hop elevati forzati, riconnessioni instabili, EMM disabilitato ovunque

Fai attenzione alle fonti che forzano un numero di hop insolitamente alto senza spiegazione, ai reader che si riconnettono continuamente senza una causa di rete chiara dalla tua parte, o alle configurazioni in cui la gestione EMM risulta completamente disabilitata su tutta la linea senza alcun percorso di aggiornamento della card. Nessuno di questi elementi è automaticamente squalificante da solo, ma insieme delineano un quadro a cui vale la pena prestare attenzione prima di dedicarci del tempo reale di configurazione.