Condivisione di Schede Spiegata: CCcam& Guida all'Impostazione di OScam

La condivisione di schede è la distribuzione a livello di rete delle parole di controllo decrittografate da una smartcard a uno o più ricevitori satellitari. Se hai incontrato un ostacolo nel cercare di connettere le tue linee CCcam o il tuo server OScam non autentica i client, il problema è quasi sempre nei dettagli: CAID errato, blocco lettore mal configurato o una porta che non è mai stata inoltrata. Questa guida illustra la meccanica effettiva e la sintassi di configurazione reale in modo da poter diagnosticare e risolvere i problemi senza il solito tentativo ed errore.

Ho trascorso molto tempo a fissare i log di OScam e a scavare in/etc/tuxbox/config/ su varie build di Enigma2. Ciò che segue è la base tecnica che la maggior parte delle guide di configurazione salta completamente.

Cos'è realmente la Condivisione di Schede (A livello di Protocollo)

A livello di rete, la condivisione di schede funziona proxyando il processo di decrittografia della smartcard su TCP. Il tuo ricevitore normalmente comunica direttamente con una scheda locale; la condivisione di schede sostituisce quel percorso locale con un salto di rete verso una macchina che ha la scheda fisica inserita. Il risultato della decrittografia — la parola di controllo — torna indietro e il tuo ricevitore la utilizza come se nulla fosse successo.

La Parola di Controllo (CW) e Perché Deve Essere Condivisa Ogni Pochi Secondi

Ogni flusso di trasmissione crittografato è offuscato utilizzando una Parola di Controllo — due metà di 8 byte che insieme formano la chiave di 16 byte. Il broadcaster ruota questa CW circa ogni 7–10 secondi per limitare l'esposizione. La prossima CW è effettivamente incorporata nel flusso leggermente prima di quando è necessaria, all'interno di un Messaggio di Controllo dei Diritti (ECM).

Il tuo ricevitore estrae l'ECM, lo invia alla smartcard (o, in un'impostazione di condivisione di schede, attraverso la rete al server della scheda), e la scheda lo decrittografa e restituisce la CW. Se quel viaggio di andata e ritorno richiede più tempo della finestra di rotazione, ottieni un blocco. Questa è l'intera ragione per cui il tempo ECM è importante: stai correndo contro un orologio di 7 secondi.

Ruoli Client/Server e il Flusso di Richiesta ECM/EMM

In un'impostazione di condivisione di schede, il server detiene la smartcard fisica. Quando un ricevitore client si sintonizza su un canale, intercetta l'ECM dal flusso di trasmissione e lo invia a monte al server della scheda tramite il protocollo di condivisione. Il server lo passa alla scheda, ottiene la CW e la inoltra al client, che la utilizza per deoffuscare il video.

EMM — Messaggio di Gestione dei Diritti — è uno strato separato. Gli EMM portano aggiornamenti di abbonamento dal broadcaster, mantenendo attuali i diritti della scheda (eventi pay-per-view, segnali di rinnovo, aggiornamenti di livello). Se la tua impostazione non inoltra gli EMM di nuovo alla scheda, alla fine scoprirai che la scheda perde canali dopo un ciclo di rinnovo. In OScam questo è controllato dalau flag in oscam.user.

CCcam vs OScam vs MGCamd vs Newcamd a Colpo d'Occhio

OScam è quasi sempre la scelta giusta per gestire un server. È attivamente mantenuto, ha un'interfaccia di monitoraggio web, scrive log dettagliati e supporta ogni protocollo che i client potrebbero desiderare. Le C-line del protocollo CCcam per la configurazione lato client rimangono il formato più universalmente supportato per connettersi a un server.

Dove si inserisce la Smartcard fisica

La smartcard è la radice di autorizzazione effettiva. Tutto il resto è solo un proxy. La scheda contiene le chiavi concesse dal broadcaster e esegue la decrittazione ECM localmente — nessuna scheda, nessun CW. Lato server, la scheda si trova in un lettore di smartcard: uno slot per ricevitore integrato (protocollo interno in OScam), un lettore USB PCSC come un SCR3310, o un lettore seriale. Il tipo di lettore di schede determina il tuoprotocollo linea in oscam.server.

Impostare un server OScam da zero

La configurazione di OScam è suddivisa in diversi file, il che confonde la maggior parte delle configurazioni per la prima volta. L'idea chiave è che ogni funzione principale — il lettore, gli utenti, i protocolli, le impostazioni globali — vive nel proprio file. Ottieni prima i percorsi dei file corretti e tutto il resto seguirà.

Compilare o installare OScam e il layout della directory di configurazione

Su Debian/Ubuntu puoi scaricare un binario precompilato o costruire dal repository SVN di OScam. L'obiettivo di build che desideri per la maggior parte delle configurazioni del server includeWITH_LIBUSB per il supporto PCSC eWITH_SSL se prevedi di utilizzare connessioni client crittografate.

La posizione della directory di configurazione varia a seconda dell'immagine. Percorsi comuni:

• /etc/tuxbox/config/ — immagini Enigma2 (OpenATV, OpenPLi)
• /usr/local/etc/ — installazioni Linux generiche
• /var/keys/ — alcune immagini DM più vecchie

Puoi sempre dire esplicitamente a OScam dove cercare:oscam -c /your/config/path. Fai questo nel tuo script di inizializzazione così non dovrai mai indovinare quale directory viene effettivamente letta.

oscam.conf: Blocchi Webif, Global e Logging

Un minimooscam.conf per un server con l'interfaccia web abilitata:

[global]

Impostahttpallowed sul tuo intervallo LAN. Non lasciare l'interfaccia web aperta su un IP pubblico senza autenticazione. Ilnice = -1 linea aumenta leggermente la priorità dello scheduler di OScam, il che può aiutare su box sovraccarichi.

Una volta che OScam è in esecuzione, vai suhttp://serverip:8888 in un browser. L'interfaccia web mostra lo stato del lettore, gli utenti attivi, i tempi di risposta ECM per richiesta e il log live — questo è il tuo principale strumento di debug e la maggior parte delle guide lo ignora completamente.

oscam.server: Definire il tuo lettore locale (PCSC, Interno, Serial)

Questo file definisce la scheda fisica. Per un lettore integrato su una box Enigma2:

[reader]

Per un lettore USB PCSC (SCR3310 o simile):

[lettore]

Ilcaid valore è l'ID di Accesso Condizionale in esadecimale. Se sbagli, OScam vedrà la scheda ma instraderà gli ECM in modo errato, causando silenziose mancanze di decrittazione. Controlla il CAID effettivo della scheda collegandoti all'interfaccia web — sotto Lettori, una scheda rilevata mostra il suo CAID riportato. Confrontalo con quello che hai inserito nella configurazione.

Un caso limite da conoscere: se hai più lettori definiti con CAID sovrapposti, OScam cercherà di instradare gli ECM in base alle sue regole di bilanciamento del carico. Questo può significare che gli ECM vanno a una scheda secondaria che non detiene effettivamente i diritti. Assegna valori distinti digroup e utilizza le assegnazioni di gruppo in oscam.user per fissare gli utenti a lettori specifici.

oscam.user: Creazione di Account e Assegnazione CAID/Ident

[account]

Ilau campo è dove molte configurazioni falliscono silenziosamente. Deve puntare a un'etichetta di lettore da oscam.server. Senza di essa, gli EMM dal broadcaster non raggiungono la scheda, e dopo il prossimo ciclo di rinnovo dell'abbonamento la scheda smette di decrittare. I diritti della scheda scadono silenziosamente.

Ilident campo accetta identificatori del fornitore nel formatoCAID:ident1,ident2. Se il broadcaster aggiorna CAID o ident dopo un aggiornamento del software della scheda — cosa che accade — la tua configurazione precedentemente funzionante si rompe senza alcun errore di log ovvio oltre a "nessun lettore corrispondente".

Abilitare il Protocollo CCcam con [cccam] e Binding della Porta

Aggiungi questo aoscam.conf per far sì che OScam accetti connessioni client del protocollo CCcam:

[cccam]

Ilreshare valore controlla quanti salti può fare un CW da questo server. Impostarlo su 1 significa che i client possono utilizzare la scheda ma non possono condividerla ulteriormente. Ilversion ebuild campi sono importanti: una discrepanza di versione tra la versione riportata dal server e quella che il client si aspetta può causare errori di handshake, specialmente con le versioni più vecchie di CCcam per Enigma2. Se un client si connette ma si disconnette immediatamente, prova ad adattare questi valori per farli corrispondere alla versione CCcam del client.

Collegare un Client CCcam (Sintassi della Linea& Porte)

La C-line è il punto di ingresso per qualsiasi client di condivisione di schede. Ottieni il formato esattamente corretto — CCcam non perdona riguardo a spazi bianchi o ordine dei campi.

Anatomia di una C-line: C: host porta nomeutente password

C: server.example.com 12000 myuser mypassword

Analizzando ciascun token:C: dichiara questa come una linea di server CCcam. Il nome host (o IP) è successivo, poi la porta su cui il server sta ascoltando, poi nome utente e password che corrispondono a un account in oscam.user (o CCcam.cfg sul lato server). Questo è tutto per la connettività di base.

I flag estesi vengono dopo la password.no disabilita i pacchetti di risveglio; il quinto campo (un numero) controlla l'inoltro EMM. Per la maggior parte delle configurazioni, la forma a quattro token sopra è tutto ciò di cui hai bisogno.

Dove si trova CCcam.cfg e come il ricevitore lo legge

Sui box Enigma2 che eseguono CCcam, la configurazione è tipicamente in/var/etc/CCcam.cfg. Alcuni build utilizzano/etc/CCcam.cfg — SSH e controlla entrambi. Il ricevitore legge questo file all'avvio e dopo un riavvio di CCcam (tramite il menu del plugin oinit.d). Le modifiche non hanno effetto fino a quando CCcam non si riavvia.

Se stai eseguendo OScam sul ricevitore come client (collegandoti a un server OScam remoto), l'equivalente si trova inoscam.server come unprotocol = cccam blocco reader che punta all'host remoto.

F-line, N-line e limiti di rishare hop

Le F-line in CCcam.cfg definiscono cosa questo ricevitore condivide con i client downstream:

F: clientuser clientpass 1 0 { 0:0:0 }

I campi dopo le credenziali sono downhop e uphop. Downhop controlla quanto lontano il CW si propaga verso il basso da questo nodo; uphop è quanti hop indietro il client può vedere. La maggior parte dei server limita il rishare a hop 1 o 2 deliberatamente — le catene di rishare profonde aggiungono latenza a ogni hop, e se la catena è abbastanza lunga il CW può arrivare dopo la finestra di rotazione, causando congelamenti.

Le N-line sono per le connessioni del protocollo Newcamd e includono una chiave DES per utente:

N: server.host 10000 user pass 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Alti conteggi di rishare hop sono una causa comune e nascosta di congelamenti intermittenti. Una configurazione potrebbe funzionare bene con pochi spettatori e iniziare a congelare quando il server diventa più occupato, perché gli ECM in coda aggiungono qualche centinaio di millisecondi a ogni hop nella catena.

Testare una linea e leggere lo stato della connessione

Su un ricevitore Enigma2 che esegue CCcam, naviga al pannello CCcam Info (di solito sotto Plugin → Informazioni CCcam). Vedrai ogni linea del server con il suo stato di connessione, il numero di schede visibili e — soprattutto — il tempo di risposta ECM in millisecondi.

Un tempo ECM sano è generalmente sotto 400ms. Sotto 200ms è solido. Se vedi 600ms o più, aspettati congelamenti. Tempi ECM in costante aumento indicano carico del server o congestione di rete, non un problema di configurazione. Un numero alto piatto (diciamo, sempre 800ms) suggerisce distanza geografica o problemi di instradamento dei pacchetti.

Risoluzione dei problemi: nessun canale, congelamenti e 'Scheda non trovata'

La maggior parte dei problemi di condivisione delle schede rientra in tre categorie: il CW non arriva affatto, il CW è errato, o il sintonizzatore DVB stesso ha un problema di segnale che non ha nulla a che fare con la condivisione delle schede. Mischiare questi problemi fa perdere ore.

Schermo nero vs canale criptato — diagnosticare la differenza

Un'immagine criptata o a blocchi (non uno schermo nero pulito) significa che il canale si sintonizza correttamente ma la decrittazione fallisce. Il segnale è presente; il CW non c'è. Uno schermo nero pulito è più probabile che sia un problema del sintonizzatore — frequenza del transponder errata, tensione LNB scadente, o un SID che semplicemente non è nei diritti della scheda.

Prima di incolpare la condivisione delle schede per uno schermo nero, controlla la forza del segnale e SNR/BER nella diagnostica del sintonizzatore del ricevitore. La condivisione delle schede non può risolvere un segnale debole o mancante. Un problema di connessione LNB, una impostazione DiSEqC errata, o un cavo LNB guasto sembrano identici a un problema di abbonamento dalla prospettiva dell'utente, ma non hanno nulla a che fare con la scheda.

Mismatch CAID/Provider e lettura della scheda locale corretta

L'entry di log "no matching reader" in OScam è il tuo punto di partenza diagnostico. Significa che un ECM è arrivato per una combinazione CAID/ident che nessun reader è configurato per gestire. Apri l'interfaccia web di OScam, vai al log live e cerca i valori CAID e ident nella linea ECM fallita. Confrontali con il tuo blocco reader in oscam.server e l'assegnazione ident in oscam.user.

I broadcaster aggiornano occasionalmente i valori CAID o ident del provider insieme agli aggiornamenti del software della scheda. Una scheda che ha decifrato tutto bene per mesi smette improvvisamente dopo un aggiornamento OTA, e l'unico indizio è che il CAID nel log ECM non corrisponde più a oscam.server. Aggiorna i tuoi valori CAID e ident per farli corrispondere a ciò che riporta il log live.

Firewall, NAT e port forwarding per server auto-ospitati

Se stai ospitando un server OScam e i client al di fuori della tua LAN non possono connettersi, la porta deve essere inoltrata sul tuo router. Per un server in ascolto sulla porta 12000:

# esempio iptables

Sul tuo router, inoltra la porta TCP 12000 all'IP locale del server. Verifica connetstat -tlnp | grep 12000 sul server che OScam sia effettivamente legato a quella porta.

CGNAT è un problema separato. Se il tuo ISP ti mette dietro un NAT di carrier-grade, il tuo IP pubblico non è tuo — è condiviso tra più clienti. Puoi connetterti in uscita come client senza problemi, ma le connessioni in entrata al tuo IP "pubblico" non raggiungono mai il tuo server. Le uniche opzioni reali sono una VPN con un IP dedicato, un VPS come relay, o passare a un ISP che fornisce un vero indirizzo instradabile. Non esiste un trucco di port forwarding che risolva CGNAT dal lato router.

MTU, latenza e congelamenti intermittenti

Il congelamento intermittente che si verifica ogni 7-10 secondi segue quasi esattamente la rotazione della CW. La nuova parola di controllo non arriva prima che la vecchia scada. Inizia con il tempo ECM nel menu informazioni del ricevitore: se è costantemente superiore a 400 ms, questo è il tuo problema.

Le discrepanze MTU su alcune connessioni ISP possono frammentare i pacchetti TCP in un modo che aggiunge latenza specificamente ai piccoli payload sensibili al tempo come le risposte CW. Se hai escluso il carico del server e la distanza geografica, prova a impostare l'MTU sull'interfaccia di rete del tuo server a 1460 o 1452 e verifica se i tempi ECM si stabilizzano.

La perdita di pacchetti è più distruttiva della latenza qui. Anche una perdita dell'1-2% sul percorso tra client e server significa che alcune risposte CW vengono perse o ritrasmesse, e una risposta CW ritrasmessa dopo la finestra di rotazione significa un congelamento. Usamtr oping -f per controllare il percorso per la perdita prima di inseguire problemi di configurazione.

Lettura dei log OScam per individuare l'ECM che fallisce

Abilita il logging dettagliato conoscam -d 255 o tramite l'interfaccia web (Config → Logging, imposta il livello di log su debug). Poi usa grep per il SID o CAID del canale:

grep -i "no matching reader" /var/log/oscam/oscam.log

Frasi chiave da conoscere nei log: "no matching reader" significa che il routing CAID/ident è fallito. "rejected" dopo una linea utente significa che l'autenticazione sta fallendo: password errata o l'account utente non esiste. "DCW checksum error" è hardware: il lettore di smartcard sta restituendo dati corrotti, di solito a causa di contatti della scheda ossidati o di un lettore USB PCSC difettoso. Pulisci i contatti della scheda con alcol isopropilico, o prova un lettore diverso.

I problemi dell'orologio del ricevitore sono una causa sottovalutata di confusione nei log. Se l'ora di sistema del server è significativamente errata (diciamo, oltre 20 minuti), i log di autenticazione mostrano rifiuti che sembrano legati alle credenziali ma sono in realtà basati su timestamp. Eseguintpdate -u pool.ntp.org o abilita NTP nella configurazione del tuo sistema e assicurati che l'orologio sia sincronizzato prima di incolpare le credenziali.

Scegliere una fonte server: criteri, non nomi

La domanda fondamentale quando si valuta qualsiasi fonte di condivisione di schede è: quanto della catena controlli? La proprietà locale della scheda e l'affitto di linee remote sono situazioni genuinamente diverse con diversi modi di fallimento.

Scheda locale vs linea remota: cosa controlli effettivamente

Con una scheda fisica nel tuo lettore, controlli tutto. Gli aggiornamenti EMM raggiungono direttamente la scheda, puoi vedere lo stato del lettore in OScam e non dipendi dall'uptime di nessun altro. Lo svantaggio è il costo e la necessità di avere un abbonamento locale valido.

Una linea remota significa che qualcun altro possiede la scheda e gestisce il server. Ottieni una C-line, la aggiungi alla tua configurazione e funziona o non funziona. Se il loro server va giù, non hai visibilità su perché e nessun modo per risolverlo. La loro scheda deve ricevere anche gli EMM: se la configurazione del titolare della scheda non gestisce correttamente l'inoltro degli EMM, vedrai i canali cadere dopo i periodi di rinnovo dell'abbonamento anche se la connessione stessa sembra sana.

Indicatori di stabilità e uptime da valutare

Quando si valuta qualsiasi fonte di schede, il test più utile è un periodo di prova in cui osservi attivamente i tempi ECM sotto diversi carichi: il prime time serale è più difficile per un server rispetto alle ore di bassa affluenza. Una fonte che restituisce tempi ECM di 80 ms alle 2 del mattino potrebbe raggiungere 600 ms alle 20 quando i clienti simultanei raggiungono il picco.

Le disconnessioni che richiedono riavvii manuali della C-line sono un campanello d'allarme. OScam si riconnetterà automaticamente, ma un server che interrompe regolarmente le connessioni indica instabilità da qualche parte nella loro infrastruttura. Osserva la scheda "Clienti" dell'interfaccia web di OScam per cicli frequenti di connessione/disconnessione sui tuoi utenti come proxy per quanto stabile si comporta il server sotto carico.

Profondità di condivisione, copertura CAID e cosa verificare

Un fornitore che pubblicizza un lungo elenco di CAID dovrebbe essere verificato rispetto a ciò di cui hai effettivamente bisogno. Chiedi specificamente quali CAID e identi sono attivi sulla scheda, non solo ciò che dice il marketing. Collega una linea di prova, apri l'interfaccia web di OScam e guarda le informazioni sulla scheda per quel lettore. Quali CAID appaiono effettivamente? Corrispondono ai canali che stai cercando di decodificare?

La profondità di condivisione sopra il salto 2 è generalmente inutile e attivamente dannosa per i tempi ECM. Qualsiasi fonte che imposta la condivisione a salto 5 o superiore non sta pensando alla latenza o sta cercando di massimizzare il numero di clienti. Nessuna delle due è buona per la tua configurazione.

Latenza, posizione del server e qualità di peering

La prossimità geografica al server non riguarda solo il ping grezzo: riguarda il peering. Un server a 500 km di distanza su una connessione di data center ben peered può superare un server a 50 km di distanza su una connessione residenziale congestionata. Pinga l'IP del server dalla tua rete prima di impegnarti su una linea. Qualsiasi cosa sotto i 30 ms è eccellente; 30-80 ms è lavorabile; sopra i 150 ms combatterai costantemente con il timing ECM.

Dal punto di vista legale: i diritti di condivisione di schede con una scheda oltre il suo ambito di visione autorizzato — condividere un singolo abbonamento tra più famiglie, ad esempio — violano tipicamente i termini dell'accordo di abbonamento e, in alcune giurisdizioni, possono confliggere con la legge sulla trasmissione o sul copyright. I dettagli variano significativamente in base al paese e al tipo di abbonamento. Assicurati di comprendere cosa è consentito in base ai termini specifici del tuo abbonamento prima di configurare qualsiasi cosa.