OScam WebIf: Come Monitorare Lettori e Clienti Attivi (Guida 2026)

Se hai OScam in esecuzione e il WebIf aperto in una scheda del browser, ma non riesci ancora a capire se i tuoi lettori stanno effettivamente facendo qualcosa, non sei solo. Questa guida suoscam webif: come monitorare lettori e clienti attivi attraversa ogni colonna della pagina di Stato, cosa significano i codici di log e quale file di configurazione aprire quando qualcosa non funziona. Ho eseguito OScam su tutto, da un Raspberry Pi a un vecchio Vu+ Solo2, e il WebIf ti dice quasi tutto ciò di cui hai bisogno — devi solo sapere come leggerlo.

Questo non è un tutorial di configurazione. Presumo che oscam.conf, oscam.server e oscam.user esistano già e che il demone sia in esecuzione. L'obiettivo qui è la diagnosi: mappare ciò che è sullo schermo a una riga specifica in un file di configurazione, in modo da poterlo correggere invece di indovinare.

Abilita il WebIf di OScam Prima di Potere Monitorare Qualsiasi Cosa

Una grande parte delle persone che cercano questo argomento ha effettivamente un WebIf che non si carica affatto. Quindi prima di entrare nella lettura delle colonne, assicuriamoci che la pagina si apra. Ecco un blocco minimo funzionante[webif] per oscam.conf:

[webif]

httprefresh controlla con quale frequenza la pagina si ricarica automaticamente, in secondi. Impostalo su 0 quando stai leggendo un log o una tabella di stato e non vuoi che la pagina salti sotto il tuo cursore — lo faccio costantemente quando cerco di catturare un riconnessione in atto.

Se metti un+ davanti alla porta, comehttpport = +8888, OScam passa a HTTPS. Questo richiede unoscam.pem file situato nella stessa directory di configurazione. Senza di esso, il demone rifiuterà di legarsi e il WebIf semplicemente non si aprirà — nessun dialogo di errore, nessun indizio ovvio, solo una connessione rifiutata nel tuo browser.

I percorsi di configurazione non sono universali, e questo confonde più persone di quanto dovrebbe. Sulle immagini Enigma2 troverai tipicamente le cose sotto/etc/tuxbox/config/ o/etc/tuxbox/config/oscam/. Su una generica macchina Linux di solito è/usr/local/etc/. Alcuni build di OpenWrt lo nascondono in/var/etc/. Piuttosto che indovinare, controlla lo script di init o l'unità systemd per il-c flag — questo ti dice esattamente quale directory OScam sta effettivamente leggendo. Ho visto persone modificare oscam.conf per venti minuti chiedendosi perché nulla cambi, solo per scoprire che il processo in esecuzione era stato avviato con-c /etc/oscam2/ invece.

Conferma che la tua build ha effettivamente il supporto per WebIf compilato:

oscam --build-info | grep -i webif

Se questo torna vuoto, il demone sta funzionando bene — è solo che la porta non ascolta mai, perché WEBIF non è stato incluso al momento della compilazione. Questa è una causa comune di una "pagina vuota" che le persone scambiano per un problema di configurazione. L'altra causa comune è che la porta sia già in uso da un'altra istanza di OScam (ne parleremo più avanti) o da un altro servizio.

Leggere la Pagina di Stato: Cosa Significa Ogni Colonna

Questa è la parte che quasi nessuno spiega correttamente. La maggior parte dei documenti screenshot della pagina di Stato e dice "ecco i tuoi lettori", senza dirti cosa implica realmente CARDOK rispetto a CONNECTED rispetto a IDLE. Quindi andiamo colonna per colonna, perché questa è la vera risposta a oscam webif: come monitorare lettori e clienti attivi.

Client vs lettore vs righe proxy

Ogni riga nella pagina di stato ha una lettera di tipo.c è un client — un'entrata da oscam.user che si connette per richiedere ECM.p è un lettore proxy — una connessione di rete verso un altro server di cardsharing (cccam, newcamd, camd35, cs378x, gbox).r è un lettore locale — una scheda fisica tramite PCSC o un lettore seriale come un Smargo.m è la riga del monitor, che è semplicemente la porta di monitoraggio di OScam.

Una cosa che confonde le persone: un peer configurato su entrambi i lati — lo stai alimentando e ti stanno alimentando — appare due volte. Una volta come riga client, una volta come riga lettore. Se lo conti come due persone separate, sovrastimerai le tue connessioni attive.

La colonna Stato

Questo è il campo su cui le persone fissano più a lungo. Ecco cosa significa effettivamente ogni stato nella pratica:

• CONNESSO — il socket è aperto e autenticato, ma questo da solo non ti dice se i dati stanno fluendo.
• ACCESSO — in fase di handshake, dovrebbe essere transitorio. Se rimane qui, le credenziali o la versione del protocollo sono probabilmente errate.
• INATTIVO — connesso, autenticato, solo non sta attivamente servendo un ECM in questo istante. Completamente normale.
• SPENTO — non connesso. Per un lettore, controlla il percorso di rete e le credenziali. Per un lettore locale, controlla che la scheda sia effettivamente inserita.
• CARDOK — specifico per lettori locali e proxy: la scheda è stata letta con successo e OScam ha il suo ATR e i diritti.
• DISCONNESSO — era connesso, ora non lo è. Combinato con un conteggio di riconnessione in aumento, questo indica un problema di rete o di keepalive.

Un lettore che si trova in CARDOK con un conteggio di ECM in aumento costante è sano — questa è l'immagine che desideri. Un lettore bloccato in CONNESSO con zero ECM mai inviati è raggiungibile ma non selezionato dal bilanciatore di carico, di solito a causa di un CAID o di un mismatch di identità, o perché un altro lettore è più veloce e vince sempre la corsa. Un lettore che continua a passare da CONNESSO a SPENTO ogni minuto o due è un problema di rete o di credenziali, non un problema di scheda.

AU: la colonna che tutti interpretano male

AU sta per Aggiornamento Automatico — se questa connessione è autorizzata a inviare EMM per mantenere attuale l'abbonamento di una scheda.ON significa che gli EMM sono consentiti.OFF significa che sono completamente bloccati. Se vedi invece un valore CAID, AU è limitato a quel CAID — utile quando un client ha più schede dietro di esso ma desideri solo aggiornamenti automatici per una. Questo è impostato conau = 1 in oscam.user, oau = per legare gli aggiornamenti a un lettore specifico.

Tempo ECM, Ultimo Canale e l'indicatore LB

Il Tempo ECM è misurato in millisecondi ed è il numero di prestazioni più utile sulla pagina. Sotto circa 300 ms e lo zapping sembra istantaneo. Tra 300 e 800 ms è utilizzabile ma noterai un battito prima che l'immagine si chiarisca. Oltre 1000 ms costantemente, vedrai congelamenti visibili al cambio di canale, e se supera il tuoecmtimeout impostazione (comunemente 3000 ms per impostazione predefinita), OScam abbandona quell'ECM completamente.

Confrontare il tempo ECM tra lettori che portano lo stesso CAID è esattamente come si decide la priorità del lettore per il bilanciatore di carico — quello più veloce dovrebbe essere preferito, e il motore statistico di OScam tiene traccia di questo automaticamente se lb_mode è abilitato (ne parleremo tra un minuto).

Ultimo canale mostra comeCAID:provid:sid in esadecimale. Senza unoscam.srvid file nella tua directory di configurazione, questo è tutto ciò che vedrai mai — numeri grezzi, nessun nome di canale. Inserisci un file oscam.srvid (o oscam.srvid2) appropriato lì e il WebIf risolve quegli ID in nomi di canale reali. Ho visto persone assumere che il WebIf fosse rotto semplicemente perché questo file non era mai stato aggiunto.

Timer di inattività e perché un client può essere connesso con zero ECM

La colonna Idle conta i secondi dall'ultima richiesta da quella connessione. Un client può rimanere in CONNESSO per ore con un timer di inattività che aumenta e zero ECM elaborati — questo significa solo che non hanno cambiato canale o non stanno attualmente guardando nulla decrittato attraverso la tua box. Non è un difetto, è solo silenzioso.

Cache hits e lettori cache-ex

Questo è il pezzo che quasi tutte le altre guide saltano, e causa vera confusione. Se stai eseguendo lo scambio di cache (cacheex), alcuni lettori esistono puramente per condividere risposte ECM memorizzate nella cache tra server — potrebbero legittimamente non elaborare mai un singolo "vero" ECM contro una scheda. I loro contatori rimangono a zero per sempre, ed è così che è progettato, non un lettore rotto. Non inseguire un problema fantasma su un lettore solo cacheex che mostra zero ECM; controlla l'impostazione della modalità cacheex in oscam.server invece di assumere che sia morto.

Monitoraggio del log live: filtrare il rumore per trovare l'ECM che fallisce

La pagina di stato ti dice lo stato delle cose in questo momento. Il log ti dice perché. Ecco una vera riga ECM annotata, in termini di formato (i valori sono segnaposto illustrativi, non legati a nessun sistema di schede reale):

2026/07/14 21:14:02 c (client) username ECM 0100:000000 sid 4A21 pid 0834 da reader1 (0 ms) rc=1 (trovato)

Scomponendo: caid è0100, provid è000000, sid è l'ID del servizio4A21, pid è il PID del flusso elementare0834, il lettore che ha risposto erareader1, erc=1 (trovato) è il codice di ritorno — il che significa che l'ECM è stato decrittato con successo. Il numero tra parentesi prima di rc è il tempo di risposta in millisecondi, che è lo stesso numero riflesso nella colonna Tempo ECM della pagina di stato per quel lettore.

Codici di ritorno che vedrai effettivamente

• trovato — decrittato con successo, tutto bene.
• non trovato — ogni lettore che hai provato non porta quella combinazione di CAID/provid. Controlla la pagina delle autorizzazioni per confermare.
• cache1 / cache2 / cache3 — la risposta è arrivata dalla cache, non toccando affatto una scheda. Questo è normale e veloce — è anche il motivo per cui un lettore può apparire "inattivo" nello stato mentre il canale si decritta bene.
• timeout — il lettore ha impiegato troppo tempo per rispondere. Non alzare semplicemente ecmtimeout per coprire questo — controlla la latenza di rete effettiva verso quel lettore e considera se ecmtimeout (di default spesso 3000 ms) sia realistico per quella connessione.
• rifiutato — quasi sempre un gruppo, CAID o mismatch di identità tra oscam.user e oscam.server. Il gruppo del client in oscam.user deve sovrapporsi al gruppo del lettore, altrimenti la richiesta non viene mai inoltrata.

Livelli di debug — usa il bitmask, non 255

I livelli di debug di OScam sono un bitmask, e impostare il debug a 255 scarica tutto in una volta. Su un server occupato è un'inondazione, e su una box a bassa RAM che scrive su memoria flash, può effettivamente riempire il disco o attivare un riavvio del watchdog. Ho bloccato una sessione in questo modo su un vecchio set-top box con un chip flash da 512 MB — non farlo.

Usa i bit specifici di cui hai bisogno:2 per l'attività reader/ATR,4 per le connessioni client,16 per la gestione EMM,64 per il flusso ECM. Se stai inseguendo un canale che non si decripta,debug = 64 da solo è di solito sufficiente. Impostalogfile per puntare da qualche parte su un filesystem reale, non flash, impostamaxlogsize per limitarlo, e riporta debug a 0 non appena hai trovato la tua risposta.

La pagina Live Log nel WebIf ti consente di filtrare per un singolo client o nome reader invece di leggere l'intero stream, il che è molto più veloce rispetto a greppare un enorme file oscam.log quando sai già quale connessione sta dando problemi.

Salute del Reader: Diritti, Schede e Vista del Bilanciatore di Carico

Il modo più veloce per rispondere a "la mia scheda è effettivamente attiva" è la vista Diritti nella pagina Readers. Elenca ogni CAID, identificativo del provider, classe e data di scadenza che la scheda riporta. Per un reader locale — PCSC, uno slot interno, un Smargo — questo proviene direttamente dalla scheda stessa. Per un reader di rete (una connessione proxy cccam o newcamd), stai vedendo ciò che il server upstream pubblicizza, che potrebbe o meno corrispondere a una scheda fisica reale dalla loro parte.

Ho visto un reader rimanere a CARDOK per settimane, il tempo ECM sembrava perfettamente sano, e il diritto effettivo era scaduto due giorni prima — la scheda continuava a rispondere agli ECM per CAID a cui non aveva più diritti, restituendo not-found invece di un errore che avresti notato su Status. L'unico posto in cui appare è la colonna di scadenza nella pagina Diritti.

La pagina delle statistiche del Bilanciatore di Carico è storia, non una vista dal vivo

Questo è il pezzo che la maggior parte delle guide concorrenti salta completamente, ed è il motivo per cui un reader che sembra perfettamente sano può rimanere a zero ECM. La pagina del bilanciatore di carico mostra le statistiche di prestazione accumulate per reader — tempo medio ECM, conteggio dei fallimenti — e OScam utilizza quella storia per decidere quale reader provare per primo per una data combinazione CAID/provid. Un reader che va bene adesso ma ha una cattiva storia di un'ora fa continuerà a perdere la corsa contro un reader con un miglior curriculum, fino a quando abbastanza dati cambiano.

Chiavi rilevanti in oscam.conf:

• lb_mode = 1 — abilita il bilanciamento del carico, dando priorità al reader più veloce.
• lb_save — persiste le statistiche su disco in modo che sopravvivano a un riavvio.
• lb_nbest_readers — quanti top reader provare per richiesta.
• lb_retrylimit — millisecondi prima che OScam si arrenda sul primo reader e provi il successivo. Questo interagisce direttamente con il tempo ECM che vedi su Status: se lb_retrylimit è inferiore al tempo di risposta tipico di un reader, quel reader quasi mai vincerà, anche se alla fine avrebbe risposto bene.
• lb_stat_cleanup — ore prima che le vecchie statistiche scadano.

Se risolvi un reader lento — diciamo che lo hai spostato su un percorso di rete migliore — le sue vecchie statistiche pesano ancora contro di esso. Ripristina le statistiche del bilanciatore di carico dal WebIf dopo la correzione, altrimenti OScam continua a evitare un reader che non è più effettivamente lento. E selb_save ha portato statistiche da una configurazione hardware precedente, puoi finire con OScam che continua a indirizzare gli ECM verso un reader che non esiste più — questo si manifesta come ECM che falliscono silenziosamente senza una causa ovvia fino a quando non controlli la pagina del bilanciatore di carico e vedi un'entrata fantasma.

Automatizzare il Monitoraggio: API HTTP, Stato JSON e Strumenti Esterni

Quasi nessuno copre questa parte, ma OScam espone un'API leggibile dalla macchina attraverso il WebIf, quindi non devi estrarre HTML per controllare lo stato del reader. Colpiscilo con curl:

curl --user admin:your_password_here "http://192.168.1.50:8888/oscamapi.json?part=status"

La risposta è un oggetto JSON con un array client — ogni voce contiene tipo, nome, protocollo, stato di connessione e ultimo canale, strutturalmente le stesse informazioni della pagina Status ma analizzabili da uno script. C'è anchepart=readers per dati specifici del reader. Questo è genuinamente utile se vuoi interrogare lo stato del reader da cron ogni cinque minuti e inviare un avviso quando un reader si disconnette.

Prima di collegarlo a qualsiasi cosa, bloccalo: crea un account WebIf separato e ristretto invece di riutilizzare il tuo accesso da amministratore, e limitahttpallowed solo all'IP della macchina che effettua il polling. Il WebIf può riavviare il demone e riscrivere i file di configurazione — non è qualcosa da esporre ampiamente solo perché vuoi un cruscotto.

Per il monitoraggio a livello di processo — OScam è effettivamente in esecuzione, non solo "il lettore è connesso" — fai affidamento su systemd (systemctl status oscam) o sul comportamento di riavvio dello script init.d in caso di crash piuttosto che sul WebIf, poiché il WebIf ovviamente non può dirti nulla se l'intero processo è inattivo.

Sintomi comuni di monitoraggio e cosa significano realmente

Ecco una tabella sintomi-fix, perché di solito è questo che le persone cercano quando cercano oscam webif: come monitorare lettori e client attivi.

Un paio di casi limite da segnalare direttamente. Se stai eseguendo due istanze di OScam contemporaneamente — una avviata dall'immagine del box, una che hai avviato manualmente — ciascuna ha il proprio WebIf su una porta diversa, ed è facile monitorare completamente quello sbagliato mentre ti chiedi perché le tue modifiche non sembrano mai avere effetto. Controllaps aux | grep oscam se la pagina di stato sembra bloccata nel tempo.

Controlla anche l'orologio del tuo sistema. Se NTP non si è sincronizzato dall'ultimo riavvio, vedrai orari di accesso errati, timer di inattività negativi, e — se stai eseguendo HTTPS sul WebIf — errori di convalida del certificato, poiché la finestra di validità di oscam.pem dipende dall'orologio che è grosso modo corretto.