Impostazione CCcam Radegast: Configurazione Completa& Guida alle Porte

Se sei arrivato qui, hai già un box CCcam o OScam in funzione e qualcosa riguardo al lato Radegast della tua catena è rotto. La documentazione è scarsa, i thread del forum si contraddicono e nessuno sembra essere d'accordo su quale file di configurazione faccia cosa. Questo articolo copre il completoimpostazione e configurazione del protocollo CCcam radegast processo — dal binding della porta lato server fino ai log di debug e al tunneling. Niente fronzoli, niente benchmark falsi. Solo le righe di configurazione che funzionano realmente.

Cosa è realmente il Protocollo Radegast (e perché confonde le persone)

La confusione inizia quasi sempre con la nomenclatura. Le persone vedono "Radegast," "newcamd," e "CCcam" usati in modo intercambiabile nello stesso post del forum e assumono che siano varianti della stessa cosa. Non lo sono — e confonderli ti farà perdere ore di tempo.

Protocollo Radegast vs newcamd vs CCcam

Newcamd è un protocollo crittografato che utilizza 3DES. Ogni connessione richiede una chiave condivisa (la chiave DES di 14 byte nella configurazione del client), e l'autenticazione avviene a livello di handshake. Il protocollo nativo di CCcam è il suo formato binario con un handshake diverso e il proprio strato di crittografia. Radegast non è nessuno di questi. È un protocollo di scambio di parole di controllo (CW) in gran parte in chiaro — progettato per la semplicità, non per la sicurezza.

La differenza pratica: con newcamd hai un nome utente di accesso, una password e una chiave DES. Con Radegast, non c'è nulla di tutto ciò. Il server consente il tuo IP o non lo fa. Questo è l'intero modello di controllo degli accessi.

Dove si inserisce Radegast in una catena CCcam/OScam

La maggior parte delle configurazioni reali che coinvolgono Radegast appare così: un'istanza OScam si trova tra l'hardware della scheda (o la fonte upstream) e il resto della rete. OScam espone un listener Radegast a cui i client locali o LAN possono connettersi. Se il dispositivo downstream finale parla solo il protocollo nativo CCcam, colleghi un'istanza CCcam locale al lettore OScam.

CCcam puro a Radegast senza OScam nel mezzo è tecnicamente possibile ma poco supportato. La gestione Radegast di CCcam è limitata rispetto a OScam, che ha avuto supporto Radegast di prima classe per anni. Se stai cercando di far funzionare CCcam come un server Radegast nativo direttamente, ti imbatterai rapidamente in ostacoli. Il percorso funzionante è OScam come endpoint Radegast.

La denominazione cs357x (Radegast) e cs378x (Radegast-over-camd35/HTTP)

Qui è dove la maggior parte della documentazione si sgretola completamente. Nella terminologia di OScam,cs357x è il protocollo lettore Radegast classico — quello in chiaro. Il nome deriva dalle convenzioni storiche delle porte.cs378x è una bestia diversa: è una variante camd35-over-TCP (a volte chiamata Radegast-over-HTTP) che aggiunge uno strato protettivo leggero sopra.

Quando modifichioscam.server, imposteraiprotocol = radegast per le connessioni cs357x eprotocol = cs378x per la variante camd35/HTTP. La maggior parte delle guide non spiega mai questa distinzione, ed è per questo che le persone finiscono per provare parole chiave casuali finché qualcosa non funziona. Quando vediprotocol = cs357x — quella è una notazione più vecchia e non universalmente accettata tra le build. Usaprotocol = radegast nel blocco lettore per il protocollo classico.

Design in chiaro, non autenticato e cosa implica

Radegast non ha crittografia e nessuna autenticazione utente per design. L'intento originale era una semplice distribuzione di CW a bassa latenza su reti locali fidate. Funziona bene per quel caso d'uso. Ma questa scelta di design significa che chiunque possa raggiungere la porta può richiedere parole di controllo. Nessun nome utente, nessuna password, nessuno scambio di chiavi — solo una connessione TCP aperta.

Ecco perché Radegast è appropriato su una LAN fidata ed è davvero una cattiva idea su Internet aperto senza un tunnel. Maggiori informazioni su questo nella sezione sicurezza.

Configurazione lato server: Esporre una Porta Radegast

Il lato server vive in due file OScam:oscam.conf (ascoltatore globale) e potenzialmenteoscam.server (dove mappi lettori specifici all'output di Radegast). Prima di tutto, imposta correttamente il blocco dell'ascoltatore.

Blocco radegast di OScam oscam.conf

Apri/etc/oscam/oscam.conf e aggiungi un[radegast] se non esiste già. Un blocco minimo funzionante appare così:

[radegast]

Questo è il minimo. OScam ascolterà sulla porta TCP 8888 e accetterà connessioni solo da localhost e dalla subnet 192.168.0.x. Non lasciareallowed vuoto — in alcune versioni predefinite accetta tutte le connessioni, il che è esattamente ciò che non vuoi.

Puoi anche aggiungerenodeid ouser parametri a seconda della tua versione di OScam, ma per una configurazione LAN di base le due righe sopra ti faranno partire. Salva, poi riavvia OScam.

Impostare la porta di ascolto e gli intervalli IP consentiti

La porta 8888 è convenzionale per Radegast ma non è obbligatoria — puoi usare qualsiasi cosa sopra 1024 che non sia già occupata. Controlla prima cosa altro è in esecuzione:ss -tlnp ti dà un elenco completo delle porte vincolate. Se stai anche eseguendo l'interfaccia web di OScam, fai attenzione ai conflitti — l'interfaccia web spesso gira sulla porta 8888 o 16002 a seconda della tua versione. Imposta una di esse su qualcos'altro.

Il campo allowed accetta IP singoli, intervalli in stile CIDR o intervalli separati da trattini. Per un singolo host remoto fidato:allowed = 192.168.1.50. Per una subnet completa:allowed = 192.168.1.0-192.168.1.255. Mantienilo ristretto.

Pensa anche a quale interfaccia stai collegando. Per impostazione predefinita, OScam si collega a tutte le interfacce (0.0.0.0). Se la tua macchina ha sia una NIC esterna che una NIC LAN interna, collegarsi a tutte le interfacce significa che la porta Radegast è tecnicamente raggiungibile anche dall'esterno — le tue regole del firewall potrebbero bloccarlo, ma la difesa in profondità conta. Puoi aggiungerebindaddr = 192.168.0.1 all'interno del[radegast] blocco per fissarlo solo all'interfaccia LAN.

Mappare un lettore/CAID all'output di Radegast

OScam instrada automaticamente le richieste ECM attraverso il suo pool di lettori in base al matching CAID. Non hai bisogno di cablaggi espliciti tra un lettore e l'ascoltatore Radegast — finché il tuo lettore inoscam.server è in un gruppo a cui i client Radegast possono accedere, l'instradamento avviene internamente.

Se vuoi limitare quali schede un client Radegast può interrogare, imposta icaid eident filtri sull'entry del lettore e configura i gruppi con attenzione. Un utente client Radegast (creato automaticamente o definito inoscam.user) può essere limitato a gruppi specifici che contengono solo i lettori che vuoi che vedano.

Riavviare e confermare che la porta è in ascolto

Dopo aver riavviato OScam, esegui questo sul server:

ss -tlnp | grep 8888

O se il tuo sistema è più vecchio:

netstat -tlnp | grep 8888

Dovresti vedere qualcosa come0.0.0.0:8888 (o il tuo specifico indirizzo di binding) con il PID di OScam. Se non appare nulla, OScam non è riuscito a analizzare il blocco di configurazione o la tua build non include il modulo Radegast. Controlla il log di avvio di OScam — registra quali listener ha attivato.

Per confermare che il modulo è compilato in:oscam --show-info 2>&1 | grep -i radegast. Se non ricevi nulla, il tuo binario non ha il lettore/server Radegast compilato. Avrai bisogno di una build diversa. Questo è più comune di quanto le persone si rendano conto con le build preconfezionate.

Configurazione lato client: Lettura di un feed Radegast

Una volta confermato che il server è in ascolto, il lato client è dove avviene la maggior parte della risoluzione dei problemi quotidiana. La configurazione va nel file della macchina client/etc/oscam/oscam.server.

Lettore OScam cs357x in oscam.server

Ecco un blocco lettore completo e funzionante per una sorgente Radegast (cs357x):

[reader]

Ildevice campo è IP e porta come coppia separata da virgola — senza spazi. Ilcaid campo dice a OScam di chiedere solo a questo lettore i servizi CAID 0x0500. Senza di esso, OScam interrogherà questo lettore per tutto e riceverai timeout ECM su CAID che la sorgente non può fornire.

Campi richiesti: device (host,port), protocol, caid, ident

Saltarecaid eident è l'errore di configurazione più comune che ho visto. Il lettore si connetterà bene, ma OScam instrada ogni ECM sconosciuto attraverso di esso, il che aggiunge latenza e riempie i tuoi log con query fallite. Filtra sempre ciò che la sorgente effettivamente trasporta.

Ilident il formato del campo èCAID:ProviderID. Se non conosci l'ID del provider, inizia con000000 come catch-all, poi restringilo una volta che puoi vedere gli ID dei provider effettivi nel log ECM. Un filtraggio di identità eccessivamente rigoroso è una delle cause di "connesso ma nessuna scheda" — trattato nella sezione di risoluzione dei problemi.

cs378x per la variante camd35/HTTP e quando preferirla

Il blocco lettore cs378x appare quasi identico, ma la parola chiave del protocollo e l'autenticazione cambiano:

[reader]

cs378x aggiunge uno strato di nome utente/password ed è più amichevole con il NAT perché il client avvia la connessione in uscita — utile quando il lato server è dietro un firewall che consente il traffico in uscita ma non in entrata. Gestisce anche alcuni casi limite relativi alla codifica CW multi-byte che le implementazioni più vecchie di Radegast sbagliano. Per qualsiasi collegamento che attraversa Internet (anche tramite un tunnel), cs378x è la scelta meno problematica.

Su una LAN fidata dove controlli entrambe le estremità, il classico Radegast (cs357x) va bene e ha meno sovraccarico.

Gruppo, fallback e filtraggio CAID/provider

OScam utilizza gruppi per controllare quali lettori sono disponibili per quali utenti. Se stai concatenando OScam → CCcam sulla stessa macchina, l'istanza locale di CCcam di solito appare come un utente auto-creato in OScam con accesso al gruppo definito inoscam.user. Assicurati che il gruppo sul lettore Radegast corrisponda a quello a cui quell'utente ha accesso.

Impostarefallback = 1 su un lettore Radegast dice a OScam di usarlo solo quando altri lettori falliscono. Utile se hai una scheda locale primaria e la sorgente Radegast è un backup — previene l'inoltro ECM non necessario al remoto quando la scheda locale può gestirlo.

Risoluzione dei problemi: Nessuna scheda, Nessun decodifica, Connessione rifiutata

Questa è la sezione che conta davvero. La maggior parte delle guide fornisce un blocco di configurazione e lo considera fatto. Il vero lavoro inizia quando la configurazione è in atto e qualcosa non funziona ancora.

Lettura dei log di OScam con livello di debug 4 per il traffico del lettore

Primo passo: aumenta il logging. Inoscam.conf sotto la[global] sezione:

[global]

Poi riavvia con livello di debug:oscam -d 255 (dalla riga di comando) o aggiungidebuglevel = 255 al[global] blocco per il logging di debug persistente. A livello 4+ vedrai singole righe ECM che mostrano il CAID, l'ID del provider, l'ECM esadecimale stesso e se il lettore ha restituito una CW o una risposta "non trovato". A 255 ottieni tutto — rumoroso ma completo.

Una riga ECM che ha successo appare all'incirca così:ECM 0500<hexstring> CW trovata (127ms) da radegast_lan. Un fallimento appare così:ECM 0500<hexstring> CW non trovato. La distinzione tra "non trovato" e "nessuna risposta" è importante — vedi sotto.

'Connessione rifiutata' vs 'connesso ma nessuna risposta ECM'

"Connessione rifiutata" significa una cosa: la connessione TCP è fallita. La porta non sta ascoltando, oppure un firewall ha bloccato il SYN. Controlla il server conss -tlnp | grep 8888, poi controlla iptables/nftables sul lato server. Verifica anche laconsentita lista inoscam.conf — OScam rifiuta le connessioni da IP non presenti in quella lista prima che il lettore le veda, e questo può sembrare un rifiuto del firewall dal lato client.

"Connesso ma nessuna risposta ECM" è un problema completamente diverso. Il percorso TCP è a posto. Qualcosa a livello di protocollo è sbagliato. Il mismatch di CAID o ident è la causa più comune — la fonte upstream semplicemente non ha una scheda in grado di decrittografare il servizio richiesto. Controlla con tcpdump:tcpdump -i any port 8888 -X mentre il client cerca di decodificare. Se vedi pacchetti ECM arrivare al server e nulla tornare indietro, il server ha ricevuto la richiesta ma non è riuscito a trovare un CW.

Mismatch di CAID/provider e liste di schede vuote

Un lettore che si connette ma restituisce liste di schede vuote ha quasi sempre un problema di filtraggio. O ilcaid campo sul lettore non corrisponde a quello che la fonte trasmette, oppure ilident campo ha un ID provider che non esiste sulla scheda.

Apri l'interfaccia web di OScam sul server (porta 8888 o 16002 — non la stessa porta di Radegast, scegli valori diversi per ciascuna) e controlla lo stato del lettore. Dovrebbe mostrare quali CAID e ID provider la scheda riporta. Confronta questo con la tua configurazione del lettore sul client. Anche un singolo carattere esadecimale errato nell'ID provider produrrà un risultato vuoto senza messaggio di errore.

Inoltre: alcune versioni di OScam hanno il modulo Radegast compilato ma con enumerazione CAID leggermente rotta. Se tutto il resto è a posto e stai ancora ricevendo liste vuote, prova a rimuovere completamentecaid eident — se le schede appaiono, i tuoi valori di filtraggio erano errati. Aggiungili di nuovo uno alla volta.

Problemi di MTU, NAT e firewall su Internet

Se stai eseguendo Radegast su un collegamento WAN (già un'idea sbagliata per il plaintext, ma facciamo il debug comunque), la frammentazione MTU può corrompere silenziosamente i payload ECM. Il sintomo classico è la decodifica intermittente — alcuni canali funzionano, altri no, e sembra casuale. Eseguiping -M do -s 1400 remote_server_ip dal client per testare il MTU del percorso. Se ricevi risposte di frammentazione necessaria, abbassa il tuo MTU sul tunnel o aggiungi una regola di clamp.

CGNAT è un problema più difficile. Se la macchina client è dietro un NAT di carrier-grade, le connessioni in arrivo a quella macchina semplicemente non funzioneranno — cs357x richiede che il server sia raggiungibile. Usa cs378x (il client avvia la connessione in uscita) oppure imposta un tunnel WireGuard che crea un percorso stabile e instradabile.

Congelamenti e CW-non-trovato su canali ad alta bitrate

Il congelamento dopo pochi secondi, specialmente su canali ad alta bitrate, è quasi sempre un problema di latenza. I periodi crittografici DVB-S2 durano circa 10 secondi. Il client deve ricevere un CW fresco prima che quello attuale scada. Se il tuo lettore Radegast è su un collegamento WAN lento con RTT di oltre 200 ms, il round-trip ECM può consumare abbastanza di quella finestra affinché il CW arrivi troppo tardi.

I canali UHD sono peggiori — a volte usano periodi crittografici più brevi e una frequenza ECM più alta. Un collegamento che va bene per SD si congelerà su UHD. Misura i tempi di risposta ECM effettivi nel log di debug (il valore di tempo nella riga ECM). Qualsiasi cosa oltre 2-3 secondi è un problema per la maggior parte dei canali. Risolvi il routing sottostante prima di incolpare il protocollo.

Firmware mixed-endian su ricevitori più vecchi è un caso limite separato. Alcuni firmware STB più vecchi leggono male i CW da una fonte Radegast — i byte arrivano invertiti — producendo uno schermo nero intermittente che si cancella e si ricongela su un ciclo di circa 10 secondi. Se vedi questo su un ricevitore specifico ma non su altri, il firmware STB è il sospetto, non la tua configurazione OScam.

Rafforzamento della sicurezza e dell'affidabilità per Radegast

Questa parte viene saltata nella maggior parte dei resoconti, ed è parte del motivo per cui Radegast ha una reputazione di essere intrinsecamente insicuro. Non è colpa del protocollo — è stato progettato per una LAN fidata. Il problema è che le persone lo usano oltre quel contesto senza alcuna protezione aggiuntiva.

Non esporre mai una porta Radegast in chiaro a Internet aperto

Radegast raw su un IP pubblico significa che chiunque possa raggiungere la porta 8888 può inviare richieste ECM e ricevere CW. Il tuo firewallconsentita lista aiuta, ma lo spoofing IP e l'hijacking sono reali su Internet aperto. Oltre al problema di controllo degli accessi, i dati stessi sono in chiaro sul cavo — visibili a chiunque sul percorso tra client e server.

Se hai la porta 8888 aperta nelle regole di port forwarding del tuo router e legata a un IP pubblico, chiudila ora. Usa invece un tunnel.

Tunnelizzazione di Radegast su SSH o WireGuard/OpenVPN

Il port forwarding locale SSH è la soluzione più rapida se hai già accesso SSH al server:

ssh -L 8888:127.0.0.1:8888 user@your_server_ip -N

Questo lega la porta 8888 localmente sulla macchina client e la inoltra attraverso la connessione SSH crittografata al localhost:8888 del server. Il tuo lettore OScam sul client punta quindi a127.0.0.1,8888 invece dell'IP del server. Il traffico di Radegast è crittografato end-to-end e non raggiunge mai Internet aperto come testo in chiaro. Lalista consentita del server dovrebbe includere127.0.0.1 affinché questo funzioni.

WireGuard è l'opzione più pulita per una configurazione persistente. Una volta stabilito il tunnel WireGuard, il lettore Radegast punta all'IP interno WireGuard del server (ad esempio,10.0.0.1,8888), e tutto il traffico transita automaticamente attraverso il tunnel crittografato. Non c'è bisogno di mantenere una sessione SSH. Su un Raspberry Pi o una scatola simile a bassa potenza, WireGuard aggiunge un sovraccarico CPU minimo rispetto a OpenVPN.

Rafforzare la lista di accesso 'consentita' e i gruppi per lettore

Anche su una LAN, non lasciareconsentita impostata su un ampio intervallo a meno che ogni dispositivo in quell'intervallo non debba avere accesso. Se solo una macchina deve connettersi, metti solo l'IP di quella macchina nella lista. OScam registra i tentativi di connessione rifiutati, quindi puoi vedere se qualcosa di inaspettato sta cercando di connettersi.

Il sistema di gruppi di OScam è anche tuo amico qui. Se le credenziali di un client (o l'IP, per l'accesso basato su IP di Radegast) vengono compromesse, una configurazione di gruppo ben configurata limita il raggio d'azione. Quella connessione compromessa può raggiungere solo i lettori nei suoi gruppi assegnati — non l'intero pool di schede.

Preferire cs378x quando un collegamento remoto è inevitabile

Se devi assolutamente eseguire un collegamento in stile Radegast su Internet e un tunnel non è un'opzione, cs378x è la scelta migliore rispetto al raw cs357x. Lo strato di autenticazione significa che un IP casuale non può semplicemente connettersi e iniziare a estrarre CW — ha bisogno di credenziali valide. Non è crittografia nel senso forte, ma è significativamente migliore rispetto a Radegast aperto.

Combina cs378x con unalista consentita ristretta che limita all'IP statico del client, e hai una configurazione che è almeno difendibile per un laboratorio domestico privato.

Ottenere la configurazione e l'impostazione del protocollo CCcam radegast corretta riguarda principalmente la comprensione di quale livello risieda un problema — TCP/firewall, instradamento CAID, o il protocollo stesso — e avere gli strumenti di debug giusti per distinguerli. Le righe di configurazione sopra sono la base funzionante. Quando qualcosa si rompe, il log ECM di OScam e un rapido tcpdump ti diranno esattamente dove si è interrotta la catena.

Un ultimo caso limite degno di nota: se stai facendo una configurazione e impostazione del protocollo CCcam radegast da zero e OScam ignora silenziosamente il tuo [radegast] blocco, controlla sempre prima oscam --show-info . Un binario compilato senza READER-RADEGAST analizzerà il file di configurazione senza errori e semplicemente non attiverà il listener — nessun avviso, nessuna voce di log, solo una porta che non si apre mai. Questo coglie molte persone che utilizzano pacchetti precompilati da repository che compilano con un set di funzionalità minimo.