Newcamd vs CCcam Protocol: Qual è il migliore nel 2026?

Se stai scegliendo tra newcamd e CCcam per un'installazione OScam nel 2026, ecco la risposta prima di leggere un altro articolo di 300 parole: Newcamd è un protocollo di emulazione della scheda che espone esattamente una scheda per porta, progettato per spostare un singolo lettore di smartcard attraverso una LAN. CCcam è un protocollo proxy che multiplexa molte schede su una singola connessione TCP, con conteggio dei salti e condivisione integrata. Quando le persone chiedono protocollo newcamd vs protocollo cccam: quale è migliore nel 2026, di solito stanno ponendo la domanda sbagliata: questi risolvono problemi diversi, e la scelta giusta dipende interamente dalla tua topologia.

Ho utilizzato entrambi in configurazioni di condivisione in produzione, e la versione breve è questa: se possiedi la scheda e desideri un accesso deterministico e a bassa latenza da una seconda box, usa Newcamd. Se stai aggregando CAID da più fonti su un singolo link, usa CCcam. Questo articolo esplora gli interni reali del protocollo, ti fornisce blocchi di configurazione OScam copiabili e copre le modalità di errore che nessuno si preoccupa di spiegare.

Newcamd vs CCcam a colpo d'occhio: la vera differenza tecnica

Newcamd è stato progettato attorno a un'idea semplice: prendere una smartcard fisica seduta in un lettore e renderla disponibile su una connessione di rete come se fosse locale. Una scheda, una porta di ascolto. Non è una limitazione che qualcuno ha dimenticato di risolvere: è l'architettura. Un server con 5 schede fisiche che esegue Newcamd ha bisogno di 5 porte di ascolto separate, e ogni client che desidera accedere a tutte e 5 le schede ha bisogno di 5 blocchi separati[lettore] nel suooscam.server, uno per porta.

CCcam adotta l'approccio opposto. Un login ti dà una connessione, e il server invia un elenco completo delle schede: ogni CAID e ID fornitore che è disposto a condividere, ciascuno contrassegnato con un valore di salto. Il client può quindi condividere quelle stesse schede ai propri client downstream al salto 2, salto 3, e così via. Questo è il punto principale di CCcam: è un protocollo di peer-to-peer e aggregazione, non un collegamento di schede punto a punto.

Newcamd: un protocollo di scheda punto a punto

Pensa a Newcamd come a un prolungamento di rete per una scheda fisica. Il client si connette, si autentica e ottiene traffico ECM/CW per esattamente i CAID e gli ID fornitore configurati su quella porta. Nessuna negoziazione dell'elenco delle schede, nessuna logica di condivisione. È deliberatamente semplice, e questa è una caratteristica.

CCcam: un protocollo proxy/peer multi-scheda

I client CCcam non sanno in anticipo cosa stanno ricevendo: il server lo dice loro al momento della connessione. Questo è ciò che rende CCcam efficace nell'aggregazione: una connessione può trasportare una dozzina di CAID da una dozzina di diverse schede fisiche dietro quel server, possibilmente condivise da ulteriori upstream.

Perché 'quale è migliore' è la domanda sbagliata

Nel 2026, quasi ogni configurazione seria là fuori è OScam che parla con OScam, e OScam parla entrambi i protocolli nativamente. Nessuno dei due è più una limitazione software: è puramente una decisione architettonica che prendi in base a quante schede hai, chi le possiede e quanti salti sei disposto a tollerare. Chiedere protocollo newcamd vs protocollo cccam: quale è migliore nel 2026 senza specificare la tua topologia è come chiedere se una chiave inglese è migliore di un set di chiavi a bussola senza dire quale bullone stai girando.

Tabella di decisione rapida: topologia, conteggio schede, esigenze di salto

Interni del protocollo: crittografia, handshake, porte e flusso dei pacchetti

Qui è dove la maggior parte degli articoli si ferma e il mio continua, perché gli interni sono esattamente ciò che spiega il comportamento che vedrai nei tuoi log in seguito.

Newcamd: handshake della chiave DES, la chiave DES di 14 byte, autenticazione login/password

Quando un client Newcamd si connette, presenta un login e una password. Il server deriva una chiave di sessione da una chiave DES di 14 byte configurata — scritta come 28 caratteri esadecimali nella tua configurazione — e entrambe le parti usano quella chiave derivata per crittografare lo scambio ECM/CW per il resto della sessione. Se sbagli un carattere esadecimale da una delle due parti, non ricevi un errore utile. Ricevi un errore di autenticazione silenzioso. Il socket si connette, l'handover si completa a livello TCP, e poi nulla si decodifica. Questo crea problemi a più configurazioni per la prima volta rispetto a qualsiasi altro singolo errore di configurazione in Newcamd.

Newcamd trasporta esattamente un CAID e ID provider per porta. Il client deve conoscerli in anticipo dall'operatore del server, o leggerli dalla connessione quando OScam esegue il suo handshake iniziale e riporta i diritti.

CCcam: ID nodo, nome utente/password, incapsulamento offuscato di CCcam

L'autenticazione CCcam è nome utente/password come Newcamd, ma l'incapsulamento sottostante utilizza il proprio schema di offuscamento di CCcam piuttosto che DES, e il server si identifica con un ID nodo come parte dell'handover. Una volta autenticato, il server invia immediatamente l'elenco delle schede — CAID, ID provider e conteggio dei salti per ogni scheda che offre — e l'istanza OScam del client costruisce la sua mappa interna dei lettori da quell'elenco al volo.

Intervalli di porte predefiniti e convenzionali

Newcamd non ha una porta ufficiale — convenzionalmente la vedrai funzionare da qualche parte nell'intervallo 34000-34009, una porta per scheda, anche se molti operatori usano ciò che è libero. CCcam tradizionalmente si trova da qualche parte nell'intervallo 12000-13000, più comunemente 12000 o 15963 a seconda della build, ma ancora una volta questa è convenzione, non un requisito di specifica. Controlla il tuooscam.conf oCCcam.cfg piuttosto che presumere.

Come viaggiano effettivamente le richieste ECM: richiesta, inoltro, ritorno CW

Sotto Newcamd: il tuo ricevitore sintonizza un canale, OScam genera una richiesta ECM, la invia attraverso il socket Newcamd al server della scheda, la scheda fisica la elabora, e la parola di controllo torna direttamente attraverso lo stesso socket. Un salto, un viaggio di andata e ritorno.

Sotto CCcam: il tuo ricevitore genera la stessa richiesta ECM, ma ora OScam deve scegliere un lettore tra potenzialmente diversi candidati che offrono quel CAID a diverse profondità di salto. Se la scheda a cui stai accedendo è essa stessa una condivisione da un altro server CCcam a monte, la tua richiesta ECM deve viaggiare verso quella scatola, essere elaborata dalla scheda fisica, e la CW deve tornare attraverso la stessa catena. Ogni salto aggiunge un intero viaggio di andata e ritorno.

Conteggio dei salti e condivisione delle schede — un concetto esclusivo di CCcam

Newcamd non ha concetto di salti perché è strutturalmente incapace di condivisione — non c'è un elenco di schede da passare, solo una scheda su una porta. Il conteggio dei salti esiste puramente in CCcam perché la condivisione è l'intero design. Una scheda al salto 1 proviene direttamente dal lettore fisico. Una scheda al salto 3 è stata condivisa due volte, il che significa che la tua richiesta ECM ora dipende da tre scatole separate che devono essere online e reattive contemporaneamente.

Keepalives, timeout e perché un protocollo cade per primo

Le impostazioni diinactivitytimeout ereconnecttimeout di OScam si applicano a entrambi i tipi di protocollo, ma si comportano in modo diverso nella pratica. Un lettore Newcamd senza traffico per la finestra di inattività configurata si riconnette semplicemente — è un collegamento singolo, quindi il recupero è veloce e ovvio. Un lettore CCcam che diventa silenzioso potrebbe stare aspettando un salto a monte che è lento piuttosto che effettivamente morto, quindi una scheda può rimanere in uno stato degradato più a lungo prima che OScam decida di riconnettersi. Impostareconnecttimeout deliberatamente piuttosto che lasciare i valori predefiniti se stai concatenando più salti.

Configurare entrambi i protocolli in OScam (Blocchi di configurazione funzionanti)

Prima di toccare qualsiasi cosa, conferma da dove OScam sta effettivamente leggendo la sua configurazione. I candidati comuni sono/etc/tuxbox/config/,/usr/local/etc/, e su alcuni ricevitori embedded/var/keys/. La risposta definitiva è qualunque percorso il tuo script di inizializzazione passa con il-c flag — controllaps aux | grep oscam se non sei sicuro, modifica la configurazione a cui punta effettivamente il flag, non quella che sembra corretta.

Layout del file OScam

Stai lavorando con almeno tre file:oscam.conf per i listener del protocollo,oscam.server per le definizioni dei lettori (sia le schede che possiedi sia quelle a cui ti connetti da remoto), eoscam.user per gli account che stai servendo.

Server Newcamd: il blocco [newcamd] e la mappatura delle schede per porta

Inoscam.conf:

[newcamd]

Lalinea port collega 34000 a CAID 0500, provider 000000. Se stai servendo una seconda scheda, ci sarà una seconda linea di porta con il proprio paio CAID/provider — questa è la regola di una porta per scheda in pratica. Lakey è la tua chiave DES di 28 caratteri esadecimali; il valore sopra è un segnaposto, genera la tua.

Client Newcamd: un blocco [reader] con protocol = newcamd525

Inoscam.server sulla macchina client:

[reader]

des_key qui deve corrispondere alkey della server linea carattere per carattere. Questo è il punto di fallimento silenzioso più comune nelle configurazioni Newcamd.

Server CCcam: blocco [cccam], porta, impostazioni di condivisione e stealth

[cccam]

Dal lato account inoscam.user, puoi sovrascrivere la profondità di condivisione per utente:

[account]

Client CCcam: [reader] con protocol = cccam, cccversion e cccmaxhops

[reader]

Voci [account] per utente, corrispondenza di gruppo e perché group = 1 non corrisponde silenziosamente

Ecco la cosa che rompe più tentativi iniziali di qualsiasi altra cosa in tutto questo articolo: ilgroup numero nel tuo[lettore] blocco e ilgruppo numero nell'entrata corrispondente[account] devono sovrapporsi, altrimenti OScam non instraderà mai un ECM a quel lettore per quell'utente. Non c'è errore per questo. Il lettore mostra CONNESSO, l'account mostra valido, e nulla viene decodificato. Se il tuo lettore ègruppo = 1 e il tuo account ègruppo = 2, semplicemente non comunicano tra loro per quanto riguarda la logica di instradamento di OScam. I gruppi sono un bitmask, non un confronto di un singolo numero — il gruppo 3 corrisponde sia a 1 che a 2.

Verifica con l'interfaccia web di OScam e il log in tempo reale

Apri il webif, porta predefinita 8888, e controlla la pagina Lettori. Un lettore funzionante mostra CONNESSO e la sua lista di Diritti dovrebbe mostrare il CAID e il provider che ti aspetti — se i diritti sono vuoti, il problema è dalla parte della scheda, non nell'instradamento. Quindi imposta il livello di debug 1 (ECM) nel log e osserva uno zap reale: dovresti vedere l'ECM uscire verso quel lettore per etichetta, e un CW tornare con un tempo reale in millisecondi. Quel numero in millisecondi è l'unico tempo ECM di cui dovresti mai fidarti — non qualsiasi cosa pubblicata su un forum.

Sintassi Legacy CCcam.cfg per lettori che mantengono vecchie scatole

Se stai ancora toccando una scatola che esegue CCcam nativo piuttosto che OScam, la configurazione è/etc/CCcam.cfg, e utilizza una sintassi di linea completamente diversa:C: righe per i client a cui ti connetti,F: righe per gli account che servi.

C: share.example-host 12000 myuser mypass

Non cercare di incollare unoscam.server [lettore] blocco inCCcam.cfg o viceversa — non sono sintassi intercambiabili, e questa confusione è uno dei post di configurazione rotta più comuni che vedrai nei forum.

Latenza, Stabilità e Failover: Come si Comportano Sotto Carico Reale

La maggior parte delle lamentele "CCcam è instabile" non riguardano effettivamente CCcam come protocollo — riguardano la profondità del salto. Una scheda a salto 3 significa che la tua richiesta ECM dipende da tre scatole separate che sono online, reattive e non sovraccariche, tutte contemporaneamente. Non è un difetto del protocollo, è matematica. Collega abbastanza salti e qualcosa nella catena sarà alla fine lento o giù.

Newcamd, al contrario, fallisce rumorosamente. Una scheda, un link — quando si rompe, il lettore si disconnette e lo sai immediatamente. Questo è genuinamente utile per la risoluzione dei problemi anche se sembra peggio nel momento.

Dove va effettivamente il tempo ECM

Scomponilo: tempo di andata e ritorno della rete tra le scatole, il tempo di elaborazione della scheda fisica stessa, e qualsiasi coda se la scheda o la CPU è occupata a gestire più richieste simultanee. Controlla il campo del tempo ecm nel tuo log di OScam per vedere quale di questi è effettivamente il tuo collo di bottiglia piuttosto che indovinare.

Perché la lista delle schede di CCcam può nascondere una scheda morta

Un server CCcam può continuare a pubblicizzare una scheda nella sua lista anche dopo che la scheda fisica dietro di essa è diventata non responsiva a monte. Il tuo client vede la scheda nei suoi diritti, cerca di usarla e non riceve nulla — perché la lista delle schede stessa non porta dati sulla salute in tempo reale, solo una pubblicità di ciò che è teoricamente disponibile.

Comportamento fail-fast di Newcamd vs degradazione silenziosa di CCcam

Questa è la differenza comportamentale principale sotto carico. Newcamd ti avvisa rapidamente: lettore disconnesso, risolvilo. CCcam può degradare silenziosamente — il lettore rimane connesso, i diritti mostrano ancora, ma le richieste individuali iniziano a scadere o tornare vuote perché una scheda a tre salti di distanza è in difficoltà.

Costruire il failover: più lettori, lettori di fallback e cache

OScam supporta lettori di fallback — configura un lettore primario e uno secondario per lo stesso CAID, imposta valori direconnecttimeout sensati, e lascia che OScam faccia il failover automaticamente. Combina questo con cacheex se stai eseguendo un cluster di scatole OScam, poiché lo scambio di cache condivide le parole di controllo piuttosto che l'accesso alla scheda e aggiunge resilienza sopra a qualsiasi protocollo tu stia utilizzando sotto.

Velocità di zapping, congelamento e la differenza tra una scheda lenta e un link lento

Se i cambi di canale sono lenti ma i tempi ECM nel log sembrano a posto, è un problema di link — RTT, congestione o un cattivo salto di condivisione. Se i tempi ECM stessi sono costantemente alti anche su una connessione diretta, è la scheda, non la rete.

Cosa misurare e dove

Non aggiungere lettori perché "di più dovrebbe essere meglio." Ogni lettore che OScam ha come candidato per un dato CAID è una cosa in più che potrebbe provare durante uno zapping, e nel peggiore dei casi aumenta il tempo di zapping piuttosto che migliorarlo. Controlla la pagina delle statistiche ECM per lettore nell'interfaccia web e pota i lettori che costantemente non performano invece di accumularne di più.

Quando scegliere quale: scenari concreti

Una scheda, due ricevitori nella stessa casa → Newcamd

Questo è il caso Newcamd da manuale. Diretto, una porta, un blocco lettori a ciascun estremo, fallisci rapidamente se qualcosa va storto. Non c'è motivo di introdurre il meccanismo di condivisione di CCcam per una configurazione senza bisogno di aggregazione.

Aggregare più CAID da diverse fonti → CCcam

Se stai estraendo schede da tre fonti fisiche diverse e vuoi una singola connessione client per vederle tutte, il modello di lista schede di CCcam è lo strumento giusto. Cercare di farlo con Newcamd significa gestire un blocco lettori e una porta separati per ogni singola scheda, il che non scala oltre un pugno.

Fornire a una scatola di un amico un singolo servizio → Newcamd (minima esposizione)

Quando stai condividendo esattamente una scheda con esattamente un'altra persona, Newcamd espone la superficie minima — una porta, un CAID, nessun percorso di condivisione per loro per passare accidentalmente (o deliberatamente) la tua scheda più a valle.

Client legacy che parla solo CCcam → CCcam o un ponte di protocollo

Alcuni vecchi decoder hanno ricevuto solo un client CCcam costruito per loro e non hanno mai avuto un'opzione Newcamd. Se sei bloccato a servire uno di quelli, esegui un listener CCcam sulla tua scatola OScam specificamente per quel client, anche se tutto il resto che esegui è Newcamd.

Eseguire entrambi simultaneamente su un'istanza OScam

Questo vale la pena ripeterlo perché quasi nessuno lo menziona: OScam può eseguire un[newcamd] listener e un[cccam] listener contemporaneamente, su porte diverse, servendo gli stessi lettori sottostanti a clienti diversi. Non devi scegliere un protocollo per l'intera configurazione — scegli per cliente in base a ciò di cui quel cliente ha bisogno.

Scegliere un link provider: cosa valutare tecnicamente, non da chi acquistare

Se stai valutando un link da una fonte esterna, giudicalo in base al merito tecnico, non al marketing. Pubblica un valore di salto reale invece di nasconderlo? Permette o vieta la condivisione, ed è dichiarato in anticipo? Ti daranno una linea di prova in modo da poter misurare i tempi ECM tu stesso prima di impegnarti? Il CAID e il set di provider corrispondono effettivamente alla tua scheda e regione? C'è trasparenza riguardo al tempo di attività e supportano la configurazione di una linea di fallback insieme alla principale? Qualsiasi link che non puoi verificare nel tuo log OScam — tempo ecm reale, diritti reali, ritorni CW reali — è un link che stai prendendo interamente sulla fede.

Cosa non funziona: miti comuni e consigli errati

'Newcamd è criptato quindi è sicuro' — DES qui è offuscamento, non sicurezza

La chiave di sessione DES di Newcamd è un meccanismo degli anni '90 per offuscare lo scambio ECM/CW tra due endpoint fidati. Non è mai stata progettata per resistere a un attaccante determinato, e trattarla come un confine di sicurezza è un errore. Se ti interessa davvero che qualcuno osservi o manometta quel link, mettilo all'interno di un tunnel WireGuard o OpenVPN, o avvolgilo con stunnel, e firewallizza la porta grezza in modo che non sia raggiungibile da Internet aperto.

'Versione ccc più alta significa più veloce' — non è così

versione ccc è una stringa di compatibilità che dice al peer quale dialetto di protocollo stai parlando. Non ha alcun effetto sulla latenza ECM. Impostarla più alta non sblocca una modalità più veloce — può effettivamente rompere un handshake con un peer più vecchio che non riconosce quella stringa di versione.

'Alza semplicemente cccmaxhops per ottenere più schede' — ottieni più fallimenti

Alzarecccmaxhops non rende migliori le schede esistenti, ammette solo schede più profonde, più lente e meno affidabili nella tua lista di candidati. Una lista di schede più lunga costruita in questo modo non è più sana — è più superficie per voci di schede morte e congelamenti.

Copiare e incollare una configurazione da un forum con i numeri di gruppo sbagliati

I numeri di gruppo non sono etichette arbitrarie, sono il meccanismo di instradamento tra lettori e account. Una configurazione di forum scritta per lo schema di gruppo di qualcun altro, incollata parola per parola, è uno dei modi più affidabili per finire con un lettore CONNESSO che non decodifica mai nulla.

Utilizzare una chiave DES pubblica/predefinita

Se la tua chiave Newcamd è una che è stata pubblicata pubblicamente o fornita come predefinita in qualche immagine firmware, non hai un link privato — hai una porta aperta con una serratura a cui tutti hanno la chiave.

Aspettarsi che la sintassi CCcam.cfg funzioni all'interno di oscam.server

C: eF: le righe appartengono al formato di configurazione nativo di CCcam.oscam.server utilizza parentesi[reader] blocchi con coppie chiave = valore. Mescolare i due è una garanzia di errore di parsing o, peggio, una configurazione che si carica a metà e ignora silenziosamente le parti che non comprende.

Casi limite da conoscere

Alcune situazioni si presentano abbastanza spesso da essere menzionate direttamente. Se il tuo client e server sono entrambi dietro CGNAT o doppio NAT, la porta di condivisione semplicemente non è raggiungibile in entrata — il port forwarding non aiuterà perché non c'è un IP pubblico da inoltrare dal tuo lato. La soluzione è organizzare il port forwarding su quale che sia l'estremità che ha effettivamente un IP instradabile, o costruire un design solo in uscita con un tunnel VPN tra i due dispositivi in modo che nessun lato abbia bisogno di una porta di ingresso aperta.

Se il CAID di una scheda appare attraverso più fornitori e OScam continua a scegliere il lettore sbagliato per un canale, non aggiungere più lettori — aggiungicaid eident filtraggio direttamente nel blocco lettore in modo che OScam consideri solo quel lettore per l'ID fornitore esatto che desideri.

I vecchi client CCcam su set-top box antichi a volte parlano solo una versione legacycccversion e rifiuteranno completamente una stretta di mano con un server OScam moderno — questo è un limite di compatibilità, non un errore di configurazione, e la soluzione è solitamente un listener dedicato a una versione inferiore per quel singolo client.

Se il tuo firewall consente solo una singola porta in uscita o in entrata e hai più schede fisiche di quelle che quella politica consente, questo da solo può costringere a un design CCcam puramente per motivi di politica di rete, poiché una porta CCcam può trasportare molte schede dove Newcamd avrebbe bisogno di una porta ciascuna.

Un lettore che mostra CONNESSO con diritti elencati ma non restituisce CW è quasi sempre un problema lato scheda — scheda non accoppiata, fornitore errato su quella scheda, o la scheda stessa è morta. Questo non è un bug di protocollo in nessuna direzione.

IP dinamico sul lato server combinato con client configurati tramite IP raw invece di nome host è un classico generatore di errori silenziosi — ogni rilascio ISP rompe ogni client fino a quando qualcuno non se ne accorge e aggiorna l'IP, o meglio, passa a un nome host con DNS dinamico.

Controlla anche che OScam stia girando come un utente con accesso effettivo in scrittura alla sua directory di configurazione — se non lo è, le modifiche webif appariranno come se si salvassero con successo e poi svaniranno al successivo riavvio, il che è frustrante da debugare se non sai di controllare prima i permessi. E se stai eseguendo due istanze OScam su un host, assicurati che non stiano entrambe cercando di legare la stessa porta di ascolto o di acquisire lo stesso nodo dispositivo lettore di schede fisiche — solo un processo può detenere uno dei due alla volta.

Lo scostamento dell'orologio su un ricevitore embedded può rompere silenziosamente la logica di timeout e produrre disconnessioni fantasma che sembrano un problema di rete ma sono in realtà un orologio di sistema errato. E su reti solo IPv6 o preferite IPv6, controlla che il tuo demone di condivisione sia effettivamente legato all'interfaccia che i tuoi client stanno utilizzando — molte versioni più vecchie di OScam predefiniscono solo IPv4 e rifiuteranno silenziosamente le connessioni solo IPv6.

Qualunque sia la tua topologia, la domanda sottostante del protocollo newcamd vs protocollo cccam: quale è migliore nel 2026 si riduce a far corrispondere il design effettivo del protocollo al tuo numero di schede e tolleranza ai salti — non scegliere quello che un post del forum ha chiamato "più facile".