Server CCcam Sri Lanka: Guida di configurazione, impostazioni e latenza

Se stai cercando di impostare un server cccam affidabile in Sri Lanka, la geografia lavora contro di te fin dall'inizio. La maggior parte dell'infrastruttura di condivisione card si trova in Europa e dovrai affrontare tempi di andata e ritorno di 180-250ms prima che la tua richiesta ECM venga elaborata. Non è un problema decisivo, ma significa che la tua configurazione non può essere copiata da una guida scritta per un utente in Germania. Questo articolo affronta ciò che conta davvero per la tua posizione — archi satellitari, peculiarità dell'ISP, ottimizzazione della configurazione e come capire quando la tua connessione sta morendo rispetto a quando la tua configurazione è semplicemente sbagliata.

Perché la geografia è importante per le prestazioni del server CCcam in Sri Lanka

La condivisione card funziona inviando un ECM (Entitlement Control Message) a un server remoto, aspettando che la CW (control word) decriptata torni indietro e usandola per decriptare il flusso video. L'intero percorso deve essere completato prima che il decoder rinunci e generi un errore di decriptazione. Questa soglia è tipicamente intorno ai 500ms sulla maggior parte del firmware del ricevitore, anche se alcuni sono più tolleranti.

Da Colombo, un ping a un server a Francoforte o Amsterdam di solito si attesta tra 180ms e 250ms a seconda del tuo ISP e del routing quel giorno. Aggiungi il tempo di elaborazione del server, l'attesa in coda e la latenza di lettura della card — stai regolarmente raggiungendo 350-450ms. È sostenibile ma non lascia quasi alcun margine. Un picco di congestione a monte del tuo ISP e stai ottenendo frame congelati.

Copertura dell'impronta satellitare rilevante per lo Sri Lanka

Lo Sri Lanka si trova all'incirca a 7°N, 81°E, il che lo colloca direttamente nell'impronta di diverse posizioni orbitali utili. I principali archi che vale la pena conoscere:

• 75,0°E — Eutelsat 8 West B (sì, la numerazione orbitale è confusa — questo è l'Eutelsat che serve l'IPTV dell'Asia meridionale e i contenuti FTA regionali). Segnale forte in tutta l'isola.
• 78,5°E — Thaicom 5/6. TV a pagamento regionale, contenuti del Sud-Est asiatico.
• 83,0°E — Insat 4A / SES-7. I principali transponder DTH indiani vivono qui. Molto rilevante per gli utenti dello Sri Lanka.
• 91,5°E — Measat-3/3a. Impronta del Sud-Est asiatico, segnale decente nella Sri Lanka occidentale.
• 100,5°E — AsiaSat 5. Richiede un po' più di parabola per una ricezione affidabile dallo Sri Lanka ma fattibile con 90cm+.

Il punto pratico: se la tua linea CCcam è supposta decriptare canali sui transponder DTH indiani 83.0°E, un server ospitato a Singapore o in India avrà accesso a card molto migliore per quegli CAID rispetto a un server a Varsavia che esegue una linea ricondivisa tre hop in profondità.

Latenza di andata e ritorno: Sri Lanka verso server CCcam europei

Esegui un test veloce prima di impegnarti con nessun server. Da un terminale Linux o dal telnet del tuo ricevitore:

ping -c 20 your-server-hostname
traceroute your-server-hostname

Server EU: prevedi 180-270ms RTT. Server a Singapore o in India: 30-80ms. UAE/Midd

le East: 80-130ms. La differenza tra un server ospitato a Singapore e uno a Francoforte è spesso la differenza tra una decrittazione pulita e un congelamento costante dei canali, in particolare sui canali sportivi con zapping veloce dove i tempi ECM sono stretti.

Come il Tempo di Risposta ECM Influisce su Zapping di Canali e Decrittazione

Ogni volta che cambi canale, il ricevitore invia una nuova richiesta ECM. La parola di controllo deve tornare prima della scadenza della CW corrente — in genere ogni 10 secondi sulla maggior parte dei sistemi, ma alcuni operatori utilizzano rotazioni CW di 5 secondi o anche 2 secondi (gli operatori DTH indiani sono notori per questo). Con una rotazione di 2 secondi e un RTT di 250ms, stai utilizzando il 12,5% della tua finestra solo per il transito. Aggiungi qualsiasi ritardo in coda o di elaborazione e sei nei guai.

La pagina statistiche ECM di OScam ti mostrerà esattamente questo — tempi di risposta per lettore registrati al millisecondo. Se il tuo tempo ECM medio mostra 420ms consistentemente su un server europeo, il passaggio a un server regionale con media di 90ms sarà immediatamente evidente.

Caratteristiche ISP Locali: SLT, Dialog, Hutch e il Loro Impatto su Connessioni Tunnelate

Dialog Broadband utilizza una gestione della sessione TCP piuttosto aggressiva. Le connessioni inattive che sembrano flussi di dati in testo semplice a volte vengono interrotte dopo pochi minuti di bassa attività — che è esattamente quello che accade durante una sessione CCcam crittografata quando nessun canale viene guardato. SLT (Sri Lanka Telecom) FTTH è generalmente più stabile per connessioni TCP di lunga durata, ma il loro instradamento verso alcuni data center asiatici può essere subottimale.

Hutch (ora Hutchison Telecommunications Lanka) 4G è utilizzabile, ma la rotazione di IP dinamici sul loro broadband mobile significa che il tuo DDNS deve aggiornarsi in modo aggressivo. Più informazioni su questo di seguito. Tutti e tre gli ISP sono stati osservati per eseguire un certo livello di DPI (Deep Packet Inspection) che può interferire con il protocollo CCcam sulla porta standard 12000.

Configurazione Server CCcam per Ricevitori dello Sri Lanka

La maggior parte dei box Enigma2 che eseguono OpenATV, OpenPLi o OpenViX memorizzano la configurazione CCcam in /etc/CCcam.cfg. Alcuni build più vecchi o installazioni manuali la posizionano in /usr/local/etc/CCcam.cfg. Controlla quale sia effettivamente letto dal tuo softcam — il percorso sbagliato significa un errore silenzioso senza alcun messaggio di errore utile.

Struttura del File CCcam.cfg: C-lines, N-lines e Impostazioni Lato Server

Una C-line ti connette a un server CCcam utilizzando il protocollo CCcam nativo:

C: yourserver.example.com 12000 yourusername yourpassword

Una N-line si connette tramite il protocollo newcamd più vecchio — meno efficiente ma supportato da alcuni ricevitori più vecchi che non parlano CCcam nativo:

N: yourserver.example.com 15000 yourusername yourpassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14

La chiave DES a 14 byte alla fine della N-line è fornita dall'operatore del server. Se stai configurando una nuova connessione nel 2024, insisti per C-lines — sono più efficienti e hanno una migliore gestione degli errori.

Numeri di porta consigliati e regole del firewall per un funzionamento stabile

La porta CCcam predefinita è 12000/TCP. Le alternative comuni che vedrai sono 15000, 16000 e talvolta 8080 o 443 per aggirare i filtri ISP. Se stai eseguendo iptables su un server Linux, apri la porta in questo modo:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT
iptables -A INPUT -p tcp --dport 12000 -m state --state NEW,ESTABLISHED -j ACCEPT

Per regole persistenti su Debian/Ubuntu, usa iptables-persistent o inserisci le regole in /etc/iptables/rules.v4. Se il tuo server CCcam upstream funziona su una porta non standard come 16000, non è necessaria alcuna modifica di configurazione lato client — basta aggiornare la porta nella tua C-line.

Configurazione del conteggio degli hop e dei limiti di condivisione per l'affidabilità regionale

Nel tuo CCcam.cfg, l'impostazione MAXIMUM DISTANCE controlla quanti hop di distanza può essere una carta ricondivisa. Ogni hop aggiunge latenza. Per una connessione dello Sri Lanka a un server già distante:

MAXIMUM DISTANCE: 1

Questo dice a CCcam di utilizzare solo carte che sono a un hop di distanza — cioè direttamente connesse. Impostare questo a 2 o superiore significa che potresti ricevere CW da una carta che è stata ricondivisa attraverso un intermediario, aggiungendo altri 50-200ms al tuo tempo ECM. È davvero pessimo per le connessioni ad alta latenza.

Configurazione della ricondivisione e della cache ECM per compensare la latenza

L'impostazione MINIMUM CACHE WAIT dice a CCcam quanto tempo aspettare un cache hit prima di inoltrare l'ECM a una carta. Se un altro client sullo stesso server ha già richiesto lo stesso ECM, il CW memorizzato in cache può tornare quasi istantaneamente:

MINIMUM CACHE WAIT: 300

Impostare questo a 300-400ms su una configurazione client dello Sri Lanka significa che CCcam aspetta fino a 300ms per un cache hit prima di andare alla carta. Dato che il tuo RTT è probabilmente 200ms+ comunque, questo spesso non ti costa nulla ma risparmia tempo di lettura della carta su cache hit. Su un server occupato con molti spettatori simultanei questo può fare una vera differenza.

Esempio di configurazione client-side CCcam.cfg per connessione dello Sri Lanka

# Configurazione client CCcam - ottimizzata per lo Sri Lanka
# Percorso del file: /etc/CCcam.cfg
C: yourserver.example.com 12000 username password
MINIMUM CACHE WAIT: 350
MAXIMUM DISTANCE: 1
KEEPALIVE: 1
RECV TIMEOUT: 2000
SEND TIMEOUT: 2000
BLOCKING MODE: 0
# Limita le ricondivisioni da questo client
RESHARE DISTANCE: 0

KEEPALIVE: 1 invia pacchetti TCP keepalive periodici per evitare che la tua connessione Dialog o SLT timeout della sessione inattiva. RESHARE DISTANCE: 0 significa che non stai ricondividendo con nessuno a valle, che è l'impostazione corretta per un client puro.

OScam come sostituto drop-in: guida alla migrazione per gli utenti dello Sri Lanka

OScam gestisce le connessioni ad alta latenza notevolmente meglio del binario CCcam. La logica di riconnessione è più aggressiva, il sistema di cache è più flessibile e in modo critico — ottieni un'interfaccia web che ti mostra esattamente cosa sta accadendo

apertura con ogni richiesta ECM. Per una configurazione di un server cccam nello Sri Lanka dove stai risolvendo i problemi di latenza, questa visibilità da sola vale la migrazione.

Perché OScam Supera CCcam su Connessioni ad Alta Latenza

Il comportamento di riconnessione del binario CCcam su una connessione interrotta è lento e talvolta richiede un riavvio completo del softcam. OScam si ricollega entro pochi secondi e gestisce i guasti del lettore con grazia ricorrendo ad altri lettori configurati o alla cache. Su broadband Dialog dove le sessioni TCP possono cadere senza preavviso, questo ha molta importanza nella pratica.

OScam ha anche il supporto corretto per cache.ex per la condivisione di CW in cache tra più istanze di OScam su una rete locale — utile se hai più ricevitori in casa e vuoi evitare che duplicate richieste ECM vadano a monte.

Percorsi e Struttura dei File oscam.conf, oscam.server e oscam.user

I file di configurazione si trovano in /etc/oscam/ sulla maggior parte delle immagini Enigma2 e /usr/local/etc/oscam/ sugli install manuali di Linux. I file principali:

• oscam.conf — impostazioni globali, logging, cache, rete
• oscam.server — definizioni dei lettori a monte (la tua riga CCcam va qui)
• oscam.user — account client se OScam sta servendo client downstream

Una sezione oscam.conf [global] di base ottimizzata per lo Sri Lanka:

[global]
logfile = /tmp/oscam.log
maxlogsize = 512
cachedelay = 300
preferlocalcards = 1
waitforcards = 1
nice = -1

cachedelay = 300 significa che OScam aspetta 300ms per un cache hit prima di andare al lettore. Con un RTT di 200ms verso il tuo server a monte, questo è quasi gratuito — stai aspettando comunque. preferlocalcards = 1 assicura che qualsiasi scheda fisica nel tuo lettore locale abbia priorità rispetto a quelle remote.

Configurazione di un Lettore CCcam in OScam per Connettersi a Monte

In /etc/oscam/oscam.server, aggiungi un blocco lettore per il tuo upstream CCcam:

[reader]
label = cccam_upstream
protocol = cccam
device = yourserver.example.com:12000
user = yourusername
password = yourpassword
reconnecttimeout = 30
group = 1
cccversion = 2.3.0
ccckeepalive = 1
prefetch = 1

prefetch = 1 dice a OScam di pre-richiedere il prossimo CW atteso prima che quello attuale scada — questo è specificamente utile quando il tuo RTT è abbastanza alto da far sì che l'attesa di una richiesta ECM su richiesta sia troppo rischiata. ccckeepalive = 1 impedisce al server upstream di eliminare la tua connessione inattiva.

Impostazione della Cache ECM (cache.ex) e Prefetch per Gestire i Picchi di Latenza

cache.ex consente a più istanze di OScam sulla tua LAN di condividere direttamente i CW in cache. Aggiungi al tuo oscam.conf:

[cacheex]
mod

Modalità 2 significa push-and-pull — la tua istanza OScam sia invia che riceve CW memorizzati dai peer sulla porta 2500/UDP. Se hai un secondo ricevitore in un'altra stanza, configura lo stesso blocco su quella macchina e aggiungi gli indirizzi IP l'uno dell'altro all'elenco dei peer in oscam.user. Il risultato: se un ricevitore ha già decodificato l'ECM, il secondo ne ottiene istantaneamente il CW dalla cache.

Interfaccia Web OScam: Monitoraggio dei Tempi ECM e dei Cache Hit da Remoto

L'interfaccia web integrata di OScam viene eseguita sulla porta 8888 per impostazione predefinita. Abilitala in oscam.conf:

[webif]
httpport = 8888
httpuser = admin
httppwd = tuapassword
httprefresh = 10
httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255

Accedivi a http://your-receiver-ip:8888. La pagina Readers mostra il conteggio ECM per lettore, il tempo di risposta medio e il rapporto dei cache hit. Dopo 30 minuti di visione normale, il tuo lettore upstream dovrebbe mostrare i tempi ECM medi. Se stai vedendo 400ms+ in modo coerente, questo è il tuo problema — o il server è sovraccarico o il routing è scarso. I rapporti di cache hit inferiori al 20% suggeriscono che non stai beneficiando di alcun caching lato server.

Risoluzione dei Problemi Comuni di Connessione CCcam dallo Sri Lanka

La maggior parte dei problemi con una connessione cccam server sri lanka rientra in un piccolo numero di modelli riconoscibili. L'output del registro ti dice in quale categoria sei — ma solo se sai cosa cercare.

Errori di Timeout ECM: Diagnosi dell'Output del Registro in CCcam e OScam

In CCcam, controlla /tmp/cccam.log o /var/log/cccam.log. Un timeout appare così:

2024/03/15 14:23:41 ECM time out (500ms) for SID 1234 CAID 0604 PROV 000000
2024/03/15 14:23:42 can not connect to server yourserver.example.com:12000

La prima riga è un problema di latenza — il tuo server sta rispondendo ma troppo lentamente. La seconda è un problema di connettività. Soluzioni diverse. Per timeout ECM: sintonizza MINIMUM CACHE WAIT e considera di passare a un server più vicino. Per errore di connessione: controlla il firewall, il DNS e se il servizio è effettivamente in esecuzione sul server.

Nei registri OScam (/tmp/oscam.log):

[2024-03-15 14:25:10] r cccam_upstream: reader got wrong password
[2024-03-15 14:25:11] c (client): no card found for CAID 0604

"Password sbagliata" — ovvio. "Nessuna carta trovata" significa che il server non gestisce quel CAID o il tuo account non è autorizzato.

Blocco delle Porte da parte degli ISP: Rilevamento e Soluzione Alternativa Utilizzando Porte Non Standard

Per verificare che la tua porta CCcam non sia bloccata da Dialog o SLT a livello ISP:

netstat -an | grep 12000

Se la connessione è visualizzata come SYN_SENT e non raggiunge mai ESTABLISHED, è probabile che la porta sia bloccata. Prova a passare alla porta 16000 o 8080 primt. Se nulla funziona, fai un tunnel tramite stunnel sulla porta 443 — il traffico HTTPS non viene quasi mai bloccato.

Esempio di /etc/stunnel/stunnel.conf lato client:

[cccam-tunnel]
client = yes
accept = 127.0.0.1:12001
connect = yourserver.example.com:443
verify = 0

Quindi indirizza la tua C-line a 127.0.0.1 12001 invece del server reale. Il lato server necessita di stunnel configurato per decomprimere la porta 443 e inoltrare alla porta 12000 di CCcam. Questo aggira completamente l'ispezione DPI perché il traffico sembra HTTPS.

Errori di Risoluzione DNS per i Nomi Host del Server Remoto

Se il tuo server CCcam è fornito come nome host anziché come IP, un errore di risoluzione DNS apparirà identico a un errore di connessione nei log. Testalo direttamente:

nslookup yourserver.example.com
dig yourserver.example.com

Se la risoluzione fallisce, prova ad aggiungere 8.8.8.8 o 1.1.1.1 alle impostazioni DNS del tuo ricevitore. Alcuni server DNS degli ISP dello Sri Lanka hanno problemi di caching o bloccano determinati TLD. Puoi codificare direttamente l'IP del server nella C-line se il DNS è inaffidabile, anche se perderai la flessibilità del cambio IP del server.

Card Not Found vs. No ECM Response: Come Distinguerli nei Log

Questi richiedono soluzioni completamente diverse e vengono comunemente confusi:

Problemi di Sincronizzazione dell'Ora del Ricevitore che Causano Errori di Autenticazione

Alcune implementazioni del server CCcam includono la convalida del timestamp nell'handshake di autenticazione. Se l'orologio del tuo ricevitore è sfasato di più di 60 secondi, la connessione viene rifiutata — ma il log degli errori spesso dice solo "authentication failed" senza menzionare l'ora. Risolvilo:

ntpdate pool.ntp.org

Sui box Enigma2, puoi anche impostare NTP nel menu in Sistema → Ora. Assicurati che il tuo fuso orario sia impostato su Asia/Colombo (UTC+5:30). Un ricevitore che è stato offline per settimane con una batteria CMOS scarica avrà una deriva notevole.

Gestione dei Guasti al Handshake CGI e DES nelle Connessioni OScam-to-CCcam

Quando OScam si connette a un server CCcam, l'handshake comporta una versione st

cccversion = 2.1.4

Inoltre, le connessioni N-line (newcamd) utilizzano la crittografia DES per la sessione. Se la chiave DES di 14 byte nella tua N-line non corrisponde esattamente a quella che il server si aspetta — inclusi gli zeri finali — la decrittazione fallisce silenziosamente e ottieni un errore di tipo "password sbagliata". Controlla doppiamente la chiave byte per byte.

Valutazione di un fornitore di server CCcam: criteri tecnici (senza nomi)

Trovare una decent fonte upstream per la tua configurazione cccam server sri lanka è principalmente questione di porre le giuste domande tecniche ed eseguire i tuoi test prima di impegnare denaro. Ecco cosa conta davvero.

Posizione del server rispetto allo Sri Lanka: quale soglia di ping richiedere

Prima di sottoscrivere qualsiasi prova, ottieni il nome host o l'IP del server e testalo tu stesso:

ping -c 50 server-hostname
traceroute server-hostname

Soglie di riferimento: Singapore/India — sotto 80ms è buono. Emirati Arabi/Medio Oriente — sotto 150ms è accettabile. Europa — 180ms+ è praticabile solo con buone impostazioni di cache e prefetch, e sarà sempre più fragile. Qualsiasi server dove ping mostra perdita di pacchetti superiore al 2% su un test di 50 pacchetti è una bandiera rossa indipendentemente dalla posizione.

Test di una riga di prova: comandi e metriche da registrare

Quando ricevi una C-line di prova, non limitarti a controllare se i canali vengono riprodotti — è il minimo indispensabile. Apri l'interfaccia web di OScam e osserva le statistiche del lettore per 30 minuti di visualizzazione effettiva. Registra:

• Tempo medio di risposta ECM (obiettivo: sotto 300ms)
• Tempo massimo di risposta ECM (picchi oltre 800ms?)
• Rapporto di hit della cache (più alto è meglio — significa che il server è abbastanza occupato da avere CW memorizzati)
• Disconnessioni del lettore durante la sessione (dovrebbero essere zero)

Testa anche la velocità di cambio canale. Sintonizzati su 10 canali diversi rapidamente — se ottieni più di 2-3 secondi di blocco ad ogni cambio di canale, la latenza ECM è troppo alta per un uso confortevole.

Bandiere rosse nella configurazione lato server che indicano overselling

Un'impostazione RESHARE: 0 lato server significa che la scheda non viene ricondivisa oltre — è una connessione diretta alla scheda effettiva. Se il server di un fornitore sta ricondividendo 3+ hop di profondità, ogni hop aggiunge latenza e introduce un altro punto di guasto. A volte puoi rilevare questo nelle statistiche del lettore OScam — se i tuoi tempi ECM sono altamente variabili (50ms a volte, 800ms altre volte), probabilmente stai colpendo una catena di reshare sovraccarica invece di una scheda diretta.

Gli alti conteggi di connessione per scheda indicano anche overselling. La pratica standard è 1 connessione per linea. Se un server sta eseguendo 10 connessioni simultanee su una scheda fisica, i tempi di coda ECM si accumulano e lo vedrai nelle tue statistiche.

Comprensione della profondità hop della C-line e del perché si degrada

Prestazioni ades

La DISTANZA MASSIMA in CCcam si riferisce ai hop di ricondivisione. Una card a distanza 1 è direttamente collegata al tuo server. Distanza 2 significa che è passata attraverso un intermediario. Ogni hop: aggiunge 20-100ms minimo, più il rischio che quell'intermediario si disconnetta. Per lo Sri Lanka dove hai già una latenza geografica, la profondità hop si traduce direttamente in frame di congelamento. Chiedi sempre ai provider se le loro card sono locali o ricondivise.

Specifiche di Limite di Larghezza di Banda e Connessione da Chiedere Prima di Sottoscrivere

Il protocollo CCcam stesso utilizza una larghezza di banda minima — lo scambio ECM/CW è costituito da pacchetti microscopici. Ma se un server ha hosting con larghezza di banda limitata, molti utenti simultanei possono comunque causare congestione. Chiedi specificamente: quante connessioni simultanee supporta l'infrastruttura del tuo server? Ogni linea di sottoscrizione è uno slot di connessione dedicato? Cosa succede quando il server è sovraccarico — mette in coda o scarta gli ECM? I provider che non riescono a rispondere chiaramente a queste domande di solito gestiscono infrastrutture condivise sovravendute.

Configurazione di un Server CCcam Locale: Gestione del Tuo Server su una Rete dello Sri Lanka

Gestire il tuo server con una smartcard fisica è la soluzione più pulita — nessuna latenza verso un server upstream, nessun problema di fiducia, controllo totale sulla configurazione. La barriera è più bassa di quanto la maggior parte delle persone pensi se hai una conoscenza di base di Linux.

Opzioni Hardware: Raspberry Pi, PC Vecchio, o Box Enigma2 Dedicato come Server

Un Raspberry Pi 3 o 4 con Raspberry Pi OS è una scelta solida — basso consumo energetico, sempre acceso, economico. Pi Zero W funziona anche ma nota la differenza di architettura: OScam compilato per ARMv7 non funzionerà silenziosamente su un Pi Zero (ARMv6). Scarica il binario corretto per il tuo hardware. Controlla con uname -m — armv6l vs armv7l.

Un PC vecchio con Debian funziona bene e ha il vantaggio di porte USB standard e nessuna ambiguità di architettura. Un box Enigma2 dedicato può fungere sia da server che da client, il che è conveniente per l'uso di una singola famiglia.

Installazione del Binario CCcam su Linux: Passaggi Debian/Ubuntu

# Scarica il binario CCcam per la tua architettura
wget https://your-source/CCcam.x86 -O /usr/local/bin/CCcam
chmod +x /usr/local/bin/CCcam
# Crea directory e file di configurazione
mkdir -p /etc/CCcam
touch /etc/CCcam.cfg
# Crea unità systemd
cat > /etc/systemd/system/cccam.service << 'EOF'
[Unit]
Description=CCcam Card Sharing Daemon
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/CCcam
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable cccam
systemctl start cccam

Configurazione di un Lettore di Card Locale con una Smartcard Fisica

I lettori USB di smartcard generalmente appaiono come /dev/ttyUSB0 su Linux. I lettori di card DVB integrati su alcuni hardware utilizzano /dev/sci0. In oscam.server di OScam, configura un lettore di card locale:

[reader]
label = local_card
protocol

Se si utilizza un modulo DVB-CI (Common Interface) invece di un lettore smartcard diretto, il protocollo cambia in ci e il percorso del dispositivo cambia nel dispositivo dello slot CI. Verificare dmesg | grep -i sci dopo l'avvio per confermare il percorso del dispositivo.

Configurazione del DNS dinamico per indirizzi IP residenziali dello Sri Lanka

La maggior parte delle connessioni residenziali nello Sri Lanka (Dialog, SLT) hanno IP dinamici. Hai bisogno di DDNS affinché la tua famiglia o i tuoi clienti possano raggiungere il tuo server. DuckDNS è gratuito e affidabile. Installa ddclient:

apt-get install ddclient

Quindi configura /etc/ddclient.conf:

protocol=duckdns
login=your-duckdns-token
password=your-duckdns-token
server=www.duckdns.org
your-subdomain.duckdns.org

Imposta l'intervallo di aggiornamento a massimo 5 minuti — soprattutto se sei su Dialog 4G dove gli IP possono cambiare ogni sessione:

daemon=300

Port Forwarding su modelli di router comuni dello Sri Lanka (ADSL2+, Fiber ONT)

Inoltra la porta TCP 12000 all'IP locale del tuo server nelle impostazioni NAT del tuo router. Gli utenti SLT FTTH con dispositivi ONT a volte scoprono che l'interfaccia web non espone il port forwarding — in quel caso, imposta l'ONT in modalità bridge e utilizza un router separato, oppure abilita DMZ puntando all'IP del tuo server (meno ideale ma funzionale).

Rilevamento CGNAT — critico per gli utenti di Dialog broadband prepagato. Esegui questo sul tuo server:

curl ifconfig.me

Confronta l'IP restituito con l'IP WAN mostrato nella pagina di stato del tuo router. Se sono diversi, sei dietro CGNAT — il tuo router ha un IP privato sulla rete dell'ISP e le connessioni in entrata da internet non ti raggiungeranno mai. Soluzioni: richiedi un aggiornamento IP statico a Dialog (disponibile su piani aziendali), oppure configura un relay VPS a Singapore o in India. Il VPS riceve le connessioni in entrata e le instrada al tuo server domestico tramite un tunnel SSH persistente:

# Sul tuo server domestico, stabilisci tunnel inverso a VPS
ssh -N -R 12000:localhost:12000 user@your-vps-ip

Quindi punta le tue C-lines all'IP VPS invece che al tuo IP domestico.