Impostazione di MGCamd Reshare: Configurazione Completa& Guida Newcamd

Una correttaimpostazione di mgcamd reshare crea problemi a molte persone — e per una buona ragione. La maggior parte delle guide online presume che MGCamd funzioni come un mini-server a cui puoi semplicemente puntare altri ricevitori. Non è così. MGCamd è un client. Comprendere questa distinzione fa la differenza tra passare una serata a fare debug e ottenere effettivamente i tuoi decoder downstream in funzione.

Questa guida copre l'architettura completa: quali file controllano cosa, come collegarsi attraversoOScam per un vero resharing, e come fare debug delle modalità di errore più comuni, incluso il frustrante problema "la sorgente decodifica bene ma il downstream si blocca".

Come Funziona Realmente il Resharing di MGCamd

MGCamd come Client vs. come Sorgente di Reshare

MGCamd è fondamentalmente unclient newcamd/cs357x. Si connette a monte, riceve parole di controllo (CW), e le passa al tuo sintonizzatore locale. Questo è il suo compito. Non c'è un demone server newcamd integrato che ascolti le connessioni downstream — MGCamd non apre una porta a cui altri ricevitori possono connettersi.

Quindi, quando le persone parlano di un'impostazione di mgcamd reshare, ciò che intendono realmente (che lo sappiano o meno) è utilizzare MGCamd per ricevere la linea a monte e poi collegarla attraverso qualcos'altro — tipicamente OScam — per servire i client downstream.

La Catena del Protocollo Newcamd: Client → MGCamd → Downstream

La catena realistica appare così: la tua linea di scheda a monte si connette tramite protocollo newcamd a MGCamd. MGCamd decripta e passa le CW localmente. OScam, in esecuzione sulla stessa macchina, si connette allo stesso upstream come lettore newcamd — oppure, se sei astuto, legge dalla memoria condivisa di MGCamd. OScam poi esegue i propri server newcamd/cccam porte a cui si connettono i ricevitori downstream.

La profondità del reshare — a volte chiamata salti — è quante volte una CW può essere inoltrata prima di essere bloccata. Ogni salto aggiunge latenza. A due salti di profondità stai già guardando tempi ECM di 400–800ms se qualcosa nella catena si inceppa.

Perché MGCamd da Solo È Limitato per il Resharing

MGCamd 1.35, 1.38 e 1.45 mancano tutte di un listener server. Puoi configurare la condivisione della cache tramite cache-ex per scambiare CW con i peer, ma si tratta di uno scambio di CW laterale tra pari, non di un vero modello di reshare server-client. Non perdere tempo a cercare un'impostazione "porta di reshare" in mg_cfg — non è lì.

Alcune build di MGCamd di terze parti affermano di avere capacità di reshare, ma in pratica sono instabili e poco documentate. Il ponte OScam è l'approccio che funziona realmente in modo affidabile.

Quando Abbinare MGCamd con OScam come Server di Reshare

Utilizza questo abbinamento quando hai una linea a monte e vuoi servire 2–10 ricevitori downstream. OScam gestisce l'autenticazione, il filtraggio CAID, i limiti di maxhops e i permessi di reshare per utente in modo pulito. MGCamd rimane come client a monte se la tua linea a monte lo richiede specificamente, anche se molte configurazioni saltano completamente MGCamd e usano solo OScam sia come client che come server.

Prerequisiti e Layout dei File

File Richiesti: newcamd.list, mg_cfg, cw_list

Tre file fanno la maggior parte del lavoro in MGCamd.newcamd.list contiene le linee di connessione del tuo server — un'entrata CWS per ogni linea a monte.mg_cfg controlla il comportamento a runtime: timeout, impostazioni della cache, verbosità del debug, tentativi di connessione.cw_list è facoltativo ma utile — ti consente di filtrare quali CAID e fornitori MGCamd elabora, il che è importante quando stai resharing un feed misto e solo alcuni fornitori sono autorizzati a proseguire.

Percorsi Comuni: /var/keys/, /var/emu/, /etc/tuxbox/

Su immagini Enigma2 (OpenPLi, OpenATV, ecc.) troverai tipicamente la configurazione di MGCamd in/var/keys/. Le immagini più vecchie, in particolare quelle basate su Gemini o DreamElite, usano/var/emu/. Alcune build incorporate mettono tutto sotto/etc/tuxbox/config/.

Controlla quale directory fa riferimento lo script di avvio della tua build prima di modificare. Modificare la copia sbagliata e chiedersi perché nulla cambia è un classico spreco di tempo.

Compatibilità della Versione MGCamd (1.35 / 1.38 / 1.45)

I nomi dei flag in mg_cfg sono cambiati tra le versioni. MGCamd 1.35 utilizza una sintassi cache-ex leggermente diversa rispetto a 1.38 e 1.45. IlM: eG: la struttura del blocco è coerente, ma opzioni come la definizione del peer della cache hanno cambiato formato. Leggi sempre il readme incluso con il tuo specifico binario — non assumere che una configurazione da un post del forum corrisponda alla tua versione.

Verificare che la tua linea upstream stia decodificando prima di condividere nuovamente

Non toccare la configurazione di condivisione finché la decodifica locale non funziona correttamente. Sintonizzati su un canale a pagamento, aspetta 10–15 secondi e cerca nel tuo log di MGCamd il tempo ECM:grep "ecm time" /tmp/mgcamd.log. Vuoi tempi coerenti sotto i 500ms. Se vedi timeout o "no CW" prima di provare a condividere nuovamente, la configurazione di condivisione aggiungerà solo confusione a un problema upstream.

Configurare la linea newcamd.list

Anatomia di una linea CWS: Host Porta Utente Password DES-Key

Ogni voce innewcamd.list segue questo formato:

CWS = hostname port username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

La chiave DES è costituita dagli ultimi 14 campi, ciascuno un byte esadecimale a due cifre, separati da spazi. Alcune build le accettano senza spazi come una singola stringa di 28 caratteri. Entrambi i formati esistono in circolazione — controlla la configurazione di esempio della tua build per sapere quale si aspetta.

La sensibilità agli spazi bianchi è reale qui. Un tab dove è previsto uno spazio, o uno spazio extra prima della nuova riga, può interrompere silenziosamente l'analisi. Usa un editor esadecimale ocat -A per controllare caratteri nascosti se una linea si rifiuta di connettersi.

La chiave DES di 14 byte e perché 28 caratteri esadecimali sono importanti

La chiave DES autentica la sessione newcamd. È di 14 byte — espressa esattamente come 28 caratteri esadecimali. Un singolo carattere errato significa che il handshake fallisce. L'errore nel log apparirà come un timeout di connessione o "login fallito", non come un errore di formato della chiave, quindi è facile confonderlo con un problema di rete.

Il tuo fornitore upstream ti fornisce questa chiave come parte delle credenziali della tua linea. Copiala esattamente. Non riscriverla manualmente — incollala, poi verifica il conteggio dei caratteri. 28 caratteri, nessuno spazio nella forma di 28 caratteri, nessuna troncatura.

Impostare i flag di condivisione/abilitazione per linea

Alcune build di MGCamd supportano flag finali sulla linea CWS:

CWS = hostname 15000 myuser mypass 01 02 03 04 05 06 07 08 09 10 11 12 13 14 01 00

I byte finali qui (ad es.,01 00) possono indicare lo stato di abilitazione/disabilitazione o suggerimenti di condivisione a seconda della build. Nella MGCamd vanilla 1.38/1.45, questi byte extra vengono tipicamente ignorati. Non aggiungerli a meno che il readme della tua versione non documenti specificamente cosa fanno — i flag non documentati aggiungono confusione senza alcun beneficio.

Linee multiple, priorità e ordinamento di failover

MGCamd legge le linee CWS dall'alto verso il basso e le prova in quell'ordine. La prima linea che risponde con un CW valido "vince" per quell'ECM. Se hai due linee che coprono CAID diversi, metti la tua linea principale/più veloce per prima. Se la prima linea va in timeout (basato sul valore di timeout in mg_cfg), MGCamd passa alla successiva.

Il failover funziona, ma aggiunge un tempo ECM pari al timeout della linea fallita. Mantieni il tuo timeout abbastanza stretto affinché il failover non causi un congelamento visibile — 2000–3000ms è un punto di partenza ragionevole.

Flag mg_cfg che influenzano la condivisione e la stabilità

M: (Modalità Config) e G: (Globale) Blocchi

mg_cfg è strutturato in blocchi.M: il blocco imposta la modalità operativa — se MGCamd utilizza EMM locale, condivide CW, esegue cache-ex. IlG: blocco (o equivalente nella tua versione) imposta il comportamento globale come la verbosità del log e la dimensione della cache. Un mg_cfg minimo per una configurazione di reshare dovrebbe avere un livello di log sufficientemente alto per vedere i tempi ECM e lo stato della connessione, ma non così verboso da riempire /tmp e causare problemi di I/O su memoria flash.

Impostazioni Cache e Cache-EX (C: / Linee Cache)

La cache memorizza i CW ricevuti di recente in modo che una seconda richiesta ECM per la stessa chiave non necessiti di un round-trip di rete. In una configurazione di reshare, questo accelera la risposta a valle — ma introduce anche una trappola: se due nodi si risharedano a vicenda (loop accidentale), possono scambiarsi CW obsoleti o errati che vengono memorizzati nella cache e serviti ripetutamente, causando un blocco persistente che sembra un problema di rete.

Se stai utilizzando peer cache-ex, assicurati che la topologia sia rigorosamente unidirezionale. Non avere il nodo A che si collega al nodo B e il nodo B che si collega di nuovo al nodo A a meno che tu non abbia impostato esplicitamente i flag di rilevamento dei loop.

Timeout ECM, Retry e Ottimizzazione Fallback

Il timeout ECM in mg_cfg controlla quanto a lungo MGCamd attende un CW prima di contrassegnare una linea come non responsiva e provare la successiva (o restituire no-CW). Per una topologia di reshare, questo timeout influisce anche sui tuoi ricevitori a valle — attendono MGCamd, che attende upstream.

Un valore di partenza sicuro è 3000ms (3 secondi). Sotto 1500ms otterrai timeout falsi su qualsiasi linea con carico moderato. Sopra 5000ms un singolo ECM mancato causa un blocco visibile a valle. Ottimizza verso il basso una volta che la configurazione è stabile.

Impostazioni Anti-Cascade e Prevenzione del Freeze

Al alcune versioni di MGCamd includono un comportamento anti-cascade — limitando quanti ECM al secondo vengono inoltrati a monte. Questo protegge il tuo fornitore upstream da un carico eccessivo (e ti protegge dal rischio di avere la tua linea tagliata). In una configurazione di reshare con diversi ricevitori a valle, il tasso di ECM può aumentare perché ogni ricevitore invia il proprio ECM in modo indipendente. Imposta un limite ragionevole al secondo e monitora il tuo tasso di ECM upstream nel log.

Collegare MGCamd a OScam per un vero Reshare

Qui è dove vive effettivamente una configurazione di reshare funzionante di mgcamd. OScam gestisce tutto ciò che MGCamd non può: servire connessioni a valle, permessi per utente, filtraggio CAID e controllo della profondità di reshare appropriato.

oscam.server: Tipo Lettore=newcamd Puntando alla tua Linea

In/etc/oscam/oscam.server, definisci un lettore che si collega alla tua linea upstream utilizzando il protocollo newcamd:

[reader]

Ilkey campo qui è la tua chiave DES di 14 byte in 28 caratteri esadecimali, senza spazi. Ilgroup valore collega questo lettore agli utenti di OScam — un utente nel gruppo 1 può utilizzare questo lettore. Se i gruppi non corrispondono, nessun ECM viene inoltrato indipendentemente da tutto il resto che è corretto.

oscam.user con server cccam/newcamd + maxhops e reshare

In/etc/oscam/oscam.user, ogni account a valle ha bisogno di un permesso di reshare e di un'assegnazione di gruppo:

[account]

reshare = 1 significa che questo account può condividere un livello ulteriore.reshare = 0 significa che il client può decodificare ma non può rishare a nessun altro.cccmaxhops limita quanti salti CCcam a valle da questo utente un CW può percorrere.

oscam.conf Porte Server (cs378x/newcamd/cccam)

In/etc/oscam/oscam.conf, abilita i protocolli server che desideri offrire a valle:

[newcamd]

La linea della porta newcamd include il binding di CAID e ident —15001@0500:000000 significa che la porta 15001 gestisce CAID 0500. Puoi associare più CAID su porte separate o utilizzare una porta generica. Queste sono le porte a cui si connettono i tuoi ricevitori downstream, e devono essere raggiungibili attraverso qualsiasi firewall o NAT tra te e i tuoi clienti.

Impostare reshare = N e cccmaxhops correttamente

Una configurazione errata comune: impostarereshare = 1 sull'utente ma lasciarecccmaxhops = 0, o viceversa. Entrambi devono consentire la profondità prevista. Se il tuo fornitore upstream ha impostato maxhops a 1 dal loro lato, il tuo cliente downstream ottiene esattamente 1 hop — non puoi sovrascrivere questo dal tuo lato. Puoi solo limitare ulteriormente, non estendere.

Per una condivisione semplice a due livelli (tu → cliente),reshare = 1 ecccmaxhops = 1 sull'account del cliente è sufficiente.

Risoluzione dei problemi: si connette ma non condivide

Accesso OK ma nessun ECM inoltrato (Mismatch di Gruppo/CAID)

Questo è il problema più comune in qualsiasi configurazione di condivisione mgcamd ed è sempre un errore di gruppo o CAID. Nel log di OScam (/var/log/oscam/oscam.log), cerca righe che contengono "no matching reader" o "no card for caid." Se vedi "connected" per il client downstream ma nessuna attività ECM, il lettore non viene selezionato per le richieste di quell'utente.

Correzione: assicurati che ilgruppo numero nel tuo blocco lettore oscam.server appaia nel campogruppo dell'account oscam.user. E assicurati che il CAID richiesto dal downstream sia effettivamente elencato in entrambi i luoghi.

Blocchi sul downstream ma la sorgente decodifica bene

Quando il tuo sintonizzatore locale decodifica correttamente ma il ricevitore downstream si blocca ogni 8–15 secondi (un periodo crittografico), il CW arriva in ritardo o è errato. Ritardo = timeout ECM, errato = ciclo di cache che serve un CW obsoleto.

Cerca nel log di OScam i tempi ECM sull'account downstream:grep "client1" /var/log/oscam/oscam.log | grep "ecm". Se i tempi aumentano a 2000ms+ in modo intermittente, aumenta il timeout. Se i tempi sono rapidi ma il downstream si blocca ancora, sospetta un CW errato dalla cache — disabilita temporaneamente cache-ex per testare.

'Card Not Found' / Nessun diritto passato

Questo errore significa che OScam ha ricevuto la richiesta ECM dal client downstream ma non ha trovato alcun lettore in grado di gestirla. O il lettore non è in esecuzione (controlla lo stato del lettore oscam), il filtro CAID sta escludendo la richiesta, o la linea upstream non trasporta quel fornitore.

Controllaoscam.server: secaid = è impostato troppo in modo restrittivo, le richieste per altri CAID sulla stessa linea vengono silenziosamente scartate. Un feed upstream con CAID misti in cui solo alcuni CAID sono autorizzati per la condivisione è uno scenario reale — il fornitore upstream può consentire la condivisione 0500 ma non 1800. Non puoi condividere CAID che l'upstream ha bloccato dalla sua parte.

Profondità di condivisione esaurita (maxhops = 0)

Se il tuo fornitore upstream ha impostato la sua linea su maxhops = 1, e tu condividi con un client, il maxhops di quel client = 0 — possono decodificare ma non possono condividere ulteriormente. Questo non è un errore di configurazione da parte tua; è l'upstream che impone limiti. Nessuna quantità di modifica della tua configurazione OScam estenderà i salti oltre ciò che l'upstream consente.

Se la linea upstream stessa arriva con maxhops = 0 (puoi vedere questo nelle informazioni del lettore di OScam), allora nemmeno tu puoi condividerla affatto — l'upstream l'ha esplicitamente bloccata. O rinnegozia con il tuo fornitore o ottieni una linea diversa con permesso di condivisione.

Problemi di NAT, Firewall e Networking a doppio salto

Un ricevitore downstream dietro un secondo router NAT (doppio NAT) è un problema comune. La scatola downstream può raggiungere la porta del tuo server OScam, ma la connessione TCP da un client dietro un CGNAT o doppio NAT potrebbe non funzionare senza un corretto port forwarding a ogni livello.

Per i client newcamd, il server non avvia connessioni — il client si connette alla porta del tuo server. Quindi hai bisogno che la tua porta del server (ad es., 15001) sia raggiungibile da Internet pubblico. Dalla parte downstream, non è necessario aprire porte. Ma se sei tu stesso dietro CGNAT, non puoi facilmente ospitare un server in entrata — considera un tunnel VPN (WireGuard funziona bene per questo) tra te e i tuoi client downstream.

Controlla con:nc -zv your.server.ip 15001 dalla macchina downstream. Se scade, è un problema di rete/firewall prima che qualsiasi configurazione MGCamd o OScam sia rilevante.