OScam WebIf: Cómo Monitorear Lectores y Clientes Activos (Guía 2026)

Si tienes OScam en funcionamiento y el WebIf abierto en una pestaña del navegador, pero aún no puedes saber si tus lectores están haciendo algo, no estás solo. Esta guía sobreoscam webif: cómo monitorear lectores y clientes activos repasa cada columna en la página de Estado, lo que significan los códigos de registro y qué archivo de configuración abrir cuando algo está roto. He ejecutado OScam en todo, desde una Raspberry Pi hasta un viejo Vu+ Solo2, y el WebIf te dice casi todo lo que necesitas — solo tienes que saber cómo leerlo.

Esto no es un tutorial de configuración. Supongo que oscam.conf, oscam.server y oscam.user ya existen y que el daemon está en funcionamiento. El objetivo aquí es el diagnóstico: mapear lo que está en pantalla a una línea específica en un archivo de configuración, para que puedas solucionarlo en lugar de adivinar.

Habilita el OScam WebIf Antes de Poder Monitorear Cualquier Cosa

Un gran número de personas que buscan este tema en realidad tienen un WebIf que no carga en absoluto. Así que antes de entrar en la lectura de columnas, asegurémonos de que la página se abra. Aquí hay un bloque mínimo funcional[webif] para oscam.conf:

[webif]

httprefresh controla con qué frecuencia la página se recarga automáticamente, en segundos. Establece en 0 cuando estés leyendo un registro o una tabla de estado y no quieras que la página salte bajo tu cursor — yo hago esto constantemente cuando intento atrapar un reconexión en el acto.

Si pones un+ delante del puerto, comohttpport = +8888, OScam cambia a HTTPS. Eso requiere unoscam.pem archivo en el mismo directorio de configuración. Sin él, el daemon se negará a enlazar y el WebIf simplemente no aparecerá — sin diálogo de error, sin pista obvia, solo una conexión rechazada en tu navegador.

Las rutas de configuración no son universales, y esto confunde a más personas de lo que debería. En imágenes de Enigma2, normalmente encontrarás cosas bajo/etc/tuxbox/config/ o/etc/tuxbox/config/oscam/. En una caja Linux genérica, suele ser/usr/local/etc/. Algunas compilaciones de OpenWrt lo guardan en/var/etc/. En lugar de adivinar, verifica el script de inicio o la unidad de systemd para el-c bandera — eso te dice exactamente qué directorio está leyendo OScam. He visto a personas editar oscam.conf durante veinte minutos preguntándose por qué nada cambia, solo para descubrir que el proceso en ejecución se inició con-c /etc/oscam2/ en su lugar.

Confirma que tu compilación realmente tiene soporte para WebIf compilado:

oscam --build-info | grep -i webif

Si eso regresa vacío, el daemon está funcionando bien — solo que el puerto nunca escucha, porque WEBIF no fue incluido en el tiempo de compilación. Esta es una causa común de una "página en blanco" que la gente confunde con un problema de configuración. La otra causa común es que el puerto ya esté en uso por una segunda instancia de OScam (más sobre eso más adelante) o por otro servicio.

Leyendo la Página de Estado: Lo Que Cada Columna Realmente Significa

Esta es la parte que casi nadie explica correctamente. La mayoría de los escritos toman una captura de pantalla de la página de Estado y dicen "aquí están tus lectores", sin decirte lo que CARDOK versus CONNECTED versus IDLE realmente implica. Así que vamos columna por columna, porque esta es la verdadera respuesta a oscam webif: cómo monitorear lectores y clientes activos.

Cliente vs lector vs filas proxy

Cada fila en la página de Estado tiene una letra de tipo.c es un cliente — una entrada de oscam.user conectándose para solicitar ECMs.p es un lector proxy — una conexión de red hacia otro servidor de cardsharing (cccam, newcamd, camd35, cs378x, gbox).r es un lector local — una tarjeta física a través de PCSC o un lector serial como un Smargo.m es la fila de monitor, que es solo el puerto de monitor de OScam.

Una cosa que confunde a la gente: un par configurado en ambos lados — tú les alimentas y ellos te alimentan — aparece dos veces. Una vez como fila de cliente, una vez como fila de lector. Si cuentas eso como dos personas separadas, contarás en exceso tus conexiones activas.

La columna de Estado

Este es el campo en el que la gente mira más tiempo. Aquí está lo que cada estado significa en la práctica:

• CONECTADO — el socket está abierto y autenticado, pero esto solo no te dice si los datos están fluyendo.
• INICIO DE SESIÓN — en medio del apretón de manos, debería ser transitorio. Si se queda aquí, es probable que las credenciales o la versión del protocolo sean incorrectas.
• INACTIVO — conectado, autenticado, simplemente no está sirviendo activamente un ECM en este instante. Completamente normal.
• APAGADO — no conectado. Para un lector, verifica la ruta de red y las credenciales. Para un lector local, verifica que la tarjeta esté realmente colocada.
• TARJETA OK — específico para lectores locales y proxy: la tarjeta fue leída con éxito y OScam tiene su ATR y derechos.
• DESCONECTADO — estaba conectado, ahora no. Combinado con un recuento de reconexiones en aumento, esto apunta a un problema de red o de keepalive.

Un lector que está en TARJETA OK con un recuento de ECM en aumento constante es saludable — esa es la imagen que deseas. Un lector atrapado en CONECTADO con cero ECMs enviados nunca es seleccionado realmente por el balanceador de carga, generalmente debido a un desajuste de CAID o ident, o porque otro lector es más rápido y siempre gana la carrera. Un lector que sigue alternando entre CONECTADO y APAGADO cada minuto o dos es un problema de red o de credenciales, no un problema de tarjeta.

AU: la columna que todos malinterpretan

AU significa Actualización Automática — si esta conexión está permitida para enviar EMMs para mantener actualizada la suscripción de una tarjeta.ENCENDIDO significa que se permiten EMMs.APAGADO significa que están completamente bloqueados. Si ves un valor de CAID en su lugar, AU está restringido solo a ese CAID — útil cuando un cliente tiene múltiples tarjetas detrás de él pero solo deseas actualizaciones automáticas para una. Esto se establece conau = 1 en oscam.user, oau = para vincular actualizaciones a un lector específico.

Tiempo de ECM, Último Canal y el indicador de LB

El Tiempo de ECM se mide en milisegundos y es el número de rendimiento más útil en la página. Por debajo de aproximadamente 300 ms y cambiar de canal se siente instantáneo. Entre 300 y 800 ms es utilizable pero notarás un retraso antes de que la imagen se aclare. Pasado 1000 ms de manera consistente, verás congelamiento visible al cambiar de canal, y si sube más allá de tuecmtimeout configuración (comúnmente 3000 ms por defecto), OScam abandona ese ECM por completo.

Comparar el tiempo de ECM entre lectores que tienen el mismo CAID es exactamente cómo decides la prioridad del lector para el balanceador de carga: se debe preferir el más rápido, y el motor de estadísticas de OScam rastrea esto automáticamente si lb_mode está habilitado (más sobre eso en un minuto).

El último canal se muestra comoCAID:provid:sid en hexadecimal. Sin unarchivo oscam.srvid en tu directorio de configuración, eso es todo lo que verás: números en bruto, sin nombres de canales. Coloca un archivo oscam.srvid (o oscam.srvid2) adecuado allí y el WebIf resolverá esos IDs a nombres de canales reales. He visto a personas asumir que el WebIf está roto simplemente porque este archivo nunca se agregó.

Temporizador de inactividad y por qué un cliente puede estar conectado con cero ECMs

La columna de inactividad cuenta los segundos desde la última solicitud de esa conexión. Un cliente puede estar en CONECTADO durante horas con un temporizador de inactividad en aumento y cero ECMs procesados: eso solo significa que no han cambiado de canal o no están viendo nada descifrado a través de tu caja. No es un error, simplemente está en silencio.

Acertijos de caché y lectores cache-ex

Esta es la parte que casi todas las demás guías omiten, y causa confusión real. Si estás ejecutando intercambio de caché (cacheex), algunos lectores existen puramente para compartir respuestas de ECM en caché entre servidores: pueden legítimamente nunca procesar un solo ECM "real" contra una tarjeta. Sus contadores permanecen en cero para siempre, y eso es intencional, no un lector roto. No persigas un problema fantasma en un lector solo de cacheex que muestra cero ECMs; verifica su configuración de modo cacheex en oscam.server en lugar de asumir que está muerto.

Monitoreo de registro en vivo: filtrando el ruido para encontrar el ECM fallido

La página de estado te dice el estado de las cosas en este momento. El registro te dice por qué. Aquí hay una línea de ECM anotada real, en términos de formato (los valores son marcadores de posición ilustrativos, no están vinculados a ningún sistema de tarjeta real):

2026/07/14 21:14:02 c (cliente) nombre de usuario ECM 0100:000000 sid 4A21 pid 0834 de reader1 (0 ms) rc=1 (encontrado)

Desglosando eso: caid es0100, provid es000000, sid es el ID de servicio4A21, pid es el PID de la corriente elemental0834, el lector que respondió fuereader1, yrc=1 (encontrado) es el código de retorno, lo que significa que el ECM se descifró con éxito. El número entre paréntesis antes de rc es el tiempo de respuesta en milisegundos, que es el mismo número reflejado en la columna de tiempo de ECM de la página de estado para ese lector.

Códigos de retorno que realmente verás

• encontrado — descifrado con éxito, todo bien.
• no encontrado — cada lector que probaste no lleva esa combinación de CAID/provid. Verifica la página de derechos para confirmar.
• cache1 / cache2 / cache3 — la respuesta vino de la caché, no de tocar una tarjeta en absoluto. Esto es normal y rápido; también es por eso que un lector puede parecer "inactivo" en el estado mientras el canal se descifra bien.
• tiempo de espera — el lector tardó demasiado en responder. No solo aumentes ecmtimeout para cubrir esto: verifica la latencia de red real hacia ese lector y considera si ecmtimeout (por defecto a menudo 3000 ms) es realista para esa conexión.
• rechazado — casi siempre hay un grupo, CAID o desajuste de ident entre oscam.user y oscam.server. El grupo del cliente en oscam.user debe superponerse al grupo del lector, o la solicitud nunca se reenvía.

Niveles de depuración: usa la máscara de bits, no 255

Los niveles de depuración de OScam son una máscara de bits, y establecer la depuración en 255 volcará todo de una vez. En un servidor ocupado, eso es una inundación, y en una caja de baja RAM que escribe en almacenamiento flash, puede llenar genuinamente el disco o activar un reinicio del watchdog. He bloqueado una sesión de esta manera en un viejo decodificador con un chip flash de 512 MB: no hagas eso.

Usa los bits específicos que necesitas:2 para la actividad de lector/ATR,4 para conexiones de cliente,16 para el manejo de EMM,64 para el flujo de ECM. Si estás persiguiendo un canal que no se puede descifrar,debug = 64 solo suele ser suficiente. Establecelogfile para apuntar a algún lugar en un sistema de archivos real, no en flash, establecemaxlogsize para limitarlo, y vuelve a bajar debug a 0 en el momento en que encuentres tu respuesta.

La página de Live Log en el WebIf te permite filtrar por un solo cliente o nombre de lector en lugar de leer toda la transmisión, lo cual es mucho más rápido que buscar en un enorme archivo oscam.log cuando ya sabes qué conexión está fallando.

Salud del Lector: Derechos, Tarjetas y la Vista del Balanceador de Carga

La forma más rápida de responder "¿mi tarjeta está realmente activa?" es la vista de Derechos en la página de Lectores. Enumera cada CAID, identificador de proveedor, clase y fecha de caducidad que informa la tarjeta. Para un lector local — PCSC, una ranura interna, un Smargo — esto proviene directamente de la tarjeta misma. Para un lector de red (una conexión proxy cccam o newcamd), estás viendo lo que el servidor ascendente publicita, que puede o no corresponder a una tarjeta física real en su extremo.

He visto un lector permanecer en CARDOK durante semanas, el tiempo de ECM luciendo perfectamente saludable, y el derecho real había expirado dos días antes — la tarjeta seguía respondiendo ECMs para CAIDs a los que ya no tenía derechos, devolviendo no encontrado en lugar de un error que notarías en el Estado. El único lugar donde aparece es en la columna de caducidad de la página de Derechos.

La página de estadísticas del Balanceador de Carga es historia, no una vista en vivo

Esta es la parte que la mayoría de las guías competidoras omiten por completo, y es por eso que un lector que parece estar perfectamente saludable puede estar en cero ECMs. La página del balanceador de carga muestra estadísticas de rendimiento acumuladas por lector — tiempo promedio de ECM, conteo de fallos — y OScam utiliza esa historia para decidir qué lector se prueba primero para una combinación dada de CAID/proveedor. Un lector que está bien ahora pero tiene un mal historial de hace una hora seguirá perdiendo la carrera frente a un lector con un mejor historial, hasta que suficientes datos cambien eso.

Claves relevantes en oscam.conf:

• lb_mode = 1 — habilita el balanceo de carga, priorizando el lector más rápido.
• lb_save — persiste estadísticas en disco para que sobrevivan a un reinicio.
• lb_nbest_readers — cuántos lectores principales intentar por solicitud.
• lb_retrylimit — milisegundos antes de que OScam se rinda con el primer lector y pruebe el siguiente. Esto interactúa directamente con el tiempo de ECM que ves en el Estado: si lb_retrylimit es menor que el tiempo de respuesta típico de un lector, ese lector casi nunca ganará, incluso si eventualmente habría respondido bien.
• lb_stat_cleanup — horas antes de que las estadísticas antiguas se eliminen.

Si arreglas un lector lento — digamos que lo moviste a un mejor camino de red — sus estadísticas antiguas aún están en su contra. Restablece las estadísticas del balanceador de carga desde el WebIf después de la reparación, de lo contrario OScam seguirá evitando un lector que ya no es realmente lento. Y silb_save llevó estadísticas de una configuración de hardware anterior, puedes terminar con OScam aún dirigiendo ECMs hacia un lector que ya no existe — eso aparece como ECMs fallando silenciosamente sin causa obvia hasta que revisas la página del balanceador de carga y ves una entrada fantasma.

Automatizando la Monitorización: API HTTP, Estado JSON y Herramientas Externas

Casi nadie cubre esta parte, pero OScam expone una API legible por máquina a través del WebIf, así que no tienes que raspar HTML para verificar el estado del lector. Accede con curl:

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

La respuesta es un objeto JSON con un array de clientes — cada entrada lleva tipo, nombre, protocolo, estado de conexión y último canal, estructuralmente la misma información que la página de Estado pero procesable por un script. También haypart=readers para datos específicos del lector. Esto es genuinamente útil si quieres consultar el estado del lector desde cron cada cinco minutos y enviar una alerta cuando un lector se desconecta.

Antes de conectar esto a cualquier cosa, asegúralo: crea una cuenta de WebIf separada y restringida en lugar de reutilizar tu inicio de sesión de administrador, y restringehttpallowed solo a la IP de la máquina que está haciendo la consulta. El WebIf puede reiniciar el daemon y reescribir archivos de configuración; no es algo que debas exponer ampliamente solo porque quieras un panel de control.

Para la monitorización a nivel de proceso — ¿está OScam incluso en ejecución, no solo "¿está el lector conectado?" — confía en systemd (systemctl status oscam) o en el comportamiento de reinicio al fallar de tu script init.d en lugar del WebIf, ya que el WebIf obviamente no puede decirte nada si todo el proceso está caído.

Síntomas Comunes de Monitorización y Lo Que Realmente Significan

Aquí hay una tabla de síntomas a solucionar, porque esto es generalmente lo que la gente realmente vino a buscar cuando buscó oscam webif: cómo monitorizar lectores y clientes activos.

Un par de casos extremos que vale la pena señalar directamente. Si estás ejecutando dos instancias de OScam a la vez — una lanzada por la imagen de la caja, una que iniciaste manualmente — cada una tiene su propio WebIf en un puerto diferente, y es fácil monitorizar la incorrecta mientras te preguntas por qué tus cambios nunca parecen tener efecto. Verificaps aux | grep oscam si la página de Estado parece estar atascada en el tiempo.

También verifica tu reloj del sistema. Si NTP no se ha sincronizado desde el último reinicio, verás tiempos de inicio de sesión falsos, temporizadores de inactividad negativos, y — si estás ejecutando HTTPS en el WebIf — fallos en la validación del certificado, ya que la ventana de validez de oscam.pem depende de que el reloj esté aproximadamente correcto.