Compartición de Tarjetas Explicada: CCcam& Guía de Configuración de OScam

La compartición de tarjetas es la distribución a nivel de red de palabras de control descifradas desde una tarjeta inteligente a uno o más receptores de satélite. Si te has encontrado con un obstáculo al intentar conectar tus líneas de CCcam o tu servidor OScam no autentica a los clientes, el problema casi siempre está en los detalles: CAID incorrecto, bloque de lector mal configurado o un puerto que nunca fue redirigido. Esta guía explica la mecánica real y la sintaxis de configuración para que puedas diagnosticar y solucionar problemas sin el habitual método de prueba y error.

He pasado mucho tiempo mirando los registros de OScam y revisando/etc/tuxbox/config/ en varias compilaciones de Enigma2. Lo que sigue es la base técnica que la mayoría de las guías de configuración omiten por completo.

Lo que la Compartición de Tarjetas Realmente Es (A Nivel de Protocolo)

A nivel de red, la compartición de tarjetas funciona mediante la intermediación del proceso de descifrado de la tarjeta inteligente a través de TCP. Tu receptor normalmente se comunica directamente con una tarjeta local; la compartición de tarjetas reemplaza ese camino local con un salto de red a una máquina que tiene la tarjeta física insertada. El resultado del descifrado — la palabra de control — regresa y tu receptor la utiliza como si nada hubiera pasado.

La Palabra de Control (CW) y Por Qué Debe Compartirse Cada Pocos Segundos

Cada transmisión de broadcast encriptada se desordena utilizando una Palabra de Control — dos mitades de 8 bytes que juntas forman la clave de 16 bytes. El broadcaster rota esta CW aproximadamente cada 7–10 segundos para limitar la exposición. La próxima CW está realmente incrustada en el flujo ligeramente antes de cuando se necesita, dentro de un Mensaje de Control de Derecho (ECM).

Tu receptor extrae el ECM, lo envía a la tarjeta inteligente (o, en una configuración de compartición de tarjetas, a través de la red al servidor de tarjetas), y la tarjeta lo descifra y devuelve la CW. Si ese viaje de ida y vuelta toma más tiempo que la ventana de rotación, obtienes un congelamiento. Esa es la razón por la que el tiempo de ECM importa: estás compitiendo contra un reloj de 7 segundos.

Roles de Cliente/Servidor y el Flujo de Solicitud de ECM/EMM

En una configuración de compartición de tarjetas, el servidor tiene la tarjeta inteligente física. Cuando un receptor cliente sintoniza un canal, intercepta el ECM del flujo de broadcast y lo envía hacia arriba al servidor de tarjetas a través del protocolo de compartición. El servidor lo pasa a la tarjeta, obtiene la CW de vuelta y la reenvía al cliente, que la utiliza para desordenar el video.

EMM — Mensaje de Gestión de Derechos — es una capa separada. Los EMM llevan actualizaciones de suscripción del broadcaster, manteniendo los derechos de la tarjeta actualizados (eventos de pago por visión, señales de renovación, actualizaciones de niveles). Si tu configuración no reenvía los EMM de vuelta a la tarjeta, eventualmente descubrirás que la tarjeta pierde canales después de un ciclo de renovación. En OScam esto se controla mediante elau bandera en oscam.user.

CCcam vs OScam vs MGCamd vs Newcamd a Primera Vista

OScam es casi siempre la elección correcta para ejecutar un servidor. Está activamente mantenido, tiene una interfaz de monitoreo web, escribe registros detallados y habla todos los protocolos que los clientes podrían desear. Las C-lines del protocolo CCcam para la configuración del lado del cliente siguen siendo el formato más universalmente soportado para conectarse a un servidor.

Dónde encaja la tarjeta inteligente física

La tarjeta inteligente es la raíz de autorización real. Todo lo demás es solo un proxy. La tarjeta contiene las claves otorgadas por el broadcaster y realiza la descifrado ECM localmente — sin tarjeta, sin CW. En el lado del servidor, la tarjeta se encuentra en un lector de tarjetas inteligentes: una ranura de receptor incorporada (protocolo interno en OScam), un lector USB PCSC como un SCR3310, o un lector serial. El tipo de lector de tarjetas determina tuprotocolo línea en oscam.server.

Configurando un servidor OScam desde cero

La configuración de OScam está dividida en varios archivos, lo que confunde a la mayoría de las configuraciones de primera vez. La clave es que cada función principal — el lector, los usuarios, los protocolos, la configuración global — vive en su propio archivo. Consigue primero las rutas de los archivos correctas y todo lo demás seguirá.

Compilando o instalando OScam y la disposición del directorio de configuración

En Debian/Ubuntu puedes obtener un binario precompilado o construirlo desde el repositorio SVN de OScam. El objetivo de construcción que deseas para la mayoría de las configuraciones de servidor incluyeWITH_LIBUSB para soporte de PCSC yWITH_SSL si planeas usar conexiones de cliente encriptadas.

La ubicación del directorio de configuración varía según la imagen. Rutas comunes:

• /etc/tuxbox/config/ — Imágenes de Enigma2 (OpenATV, OpenPLi)
• /usr/local/etc/ — instalaciones genéricas de Linux
• /var/keys/ — algunas imágenes DM más antiguas

Siempre puedes indicarle a OScam explícitamente dónde buscar:oscam -c /tu/ruta/de/configuración. Haz esto en tu script de inicio para que nunca estés adivinando qué directorio se está leyendo realmente.

oscam.conf: Bloques de Webif, Global y Registro

Un mínimooscam.conf para un servidor con la interfaz web habilitada:

[global]

Establecehttpallowed a tu rango de LAN. No dejes la interfaz web abierta en una IP pública sin autenticación. Elnice = -1 línea aumenta ligeramente la prioridad del programador de OScam, lo que puede ayudar en cajas cargadas.

Una vez que OScam esté en funcionamiento, accede ahttp://serverip:8888 en un navegador. La interfaz web muestra el estado del lector, los usuarios activos, los tiempos de respuesta ECM por solicitud y el registro en vivo — esta es tu herramienta principal de depuración y la mayoría de las guías la ignoran por completo.

oscam.server: Definiendo tu lector local (PCSC, Interno, Serial)

Este archivo define la tarjeta física. Para un lector incorporado en una caja Enigma2:

[reader]

Para un lector USB PCSC (SCR3310 o similar):

[lector]

Elcaid valor es el ID de Acceso Condicional en hex. Si esto es incorrecto, OScam verá la tarjeta pero dirigirá los ECMs a ella incorrectamente, causando fallos de descifrado silenciosos. Verifique el CAID real de la tarjeta conectándose a la interfaz web: bajo Lectores, una tarjeta detectada muestra su CAID reportado. Verifíquelo con lo que ingresó en la configuración.

Un caso extremo que vale la pena conocer: si tiene múltiples lectores definidos con CAIDs superpuestos, OScam intentará dirigir los ECMs según sus reglas de balanceo de carga. Esto puede significar que los ECMs vayan a una tarjeta secundaria que en realidad no tiene los derechos. Asigne valores degrupo distintos y use asignaciones de grupo en oscam.user para asignar usuarios a lectores específicos.

oscam.user: Creando Cuentas y Asignación de CAID/Ident

[cuenta]

Elau campo es donde muchas configuraciones fallan silenciosamente. Necesita apuntar a una etiqueta de lector de oscam.server. Sin ello, los EMMs del broadcaster no llegan a la tarjeta, y después del siguiente ciclo de renovación de suscripción, la tarjeta deja de descifrar. Los derechos de la tarjeta simplemente expiran silenciosamente.

Elident campo acepta identificadores de proveedor en el formatoCAID:ident1,ident2. Si el broadcaster actualiza CAID o ident después de una actualización de software de la tarjeta — lo cual sucede — su configuración previamente funcional se rompe sin ningún error de registro obvio más allá de "no hay lector coincidente".

Habilitando el Protocolo CCcam con [cccam] y Vinculación de Puertos

Agregue esto aoscam.conf para hacer que OScam acepte conexiones de clientes del protocolo CCcam:

[cccam]

Elreshare valor controla cuántas saltos puede viajar un CW desde este servidor. Configurarlo en 1 significa que los clientes pueden usar la tarjeta pero no pueden compartirla más. Elversion ybuild campos son importantes: un desajuste de versión entre la versión reportada del servidor y lo que el cliente espera puede causar fallos en el apretón de manos, especialmente con versiones más antiguas de CCcam en Enigma2. Si un cliente se conecta pero se desconecta inmediatamente, intente ajustar estos para que coincidan con la versión de CCcam del cliente.

Conectando un Cliente CCcam (Sintaxis de Línea& Puertos)

La línea C es el punto de entrada para cualquier cliente de compartición de tarjetas. Obtenga el formato exactamente correcto: CCcam no es indulgente con los espacios en blanco o el orden de los campos.

Anatomía de una línea C: C: host puerto nombre_usuario contraseña

C: server.example.com 12000 myuser mypassword

Desglosando cada token:C: declara esto como una línea de servidor CCcam. El nombre del host (o IP) es el siguiente, luego el puerto en el que el servidor está escuchando, luego el nombre de usuario y la contraseña que coinciden con una cuenta en oscam.user (o CCcam.cfg en el lado del servidor). Eso es todo para la conectividad básica.

Las banderas extendidas vienen después de la contraseña.no desactiva los paquetes de activación; el quinto campo (un número) controla el reenvío de EMM. Para la mayoría de las configuraciones, la forma de cuatro tokens anterior es todo lo que necesitas.

Dónde vive CCcam.cfg y cómo lo lee el receptor

En cajas Enigma2 que ejecutan CCcam, la configuración está típicamente en/var/etc/CCcam.cfg. Algunas versiones utilizan/etc/CCcam.cfg — Conéctate por SSH y verifica ambas. El receptor lee este archivo al inicio y después de un reinicio de CCcam (a través del menú del plugin oinit.d). Los cambios no tienen efecto hasta que CCcam se reinicia.

Si estás ejecutando OScam en el receptor como cliente (conectándose a un servidor OScam remoto), el equivalente se encuentra enoscam.server como unprotocol = cccam bloque de lector que apunta al host remoto.

Líneas F, líneas N y límites de salto de reenvío

Las líneas F en CCcam.cfg definen lo que este receptor reenvía a los clientes aguas abajo:

F: clientuser clientpass 1 0 { 0:0:0 }

Los campos después de las credenciales son downhops y uphops. Downhops controla cuán lejos se propaga el CW hacia abajo desde este nodo; uphops es cuántos saltos hacia atrás puede ver el cliente. La mayoría de los servidores limitan el reenvío a 1 o 2 saltos deliberadamente; las cadenas de reenvío profundas añaden latencia en cada salto, y si la cadena es lo suficientemente larga, el CW puede llegar después de la ventana de rotación, lo que causa congelamientos.

Las líneas N son para conexiones del protocolo Newcamd e incluyen una clave DES por usuario:

N: server.host 10000 user pass 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Altos conteos de saltos de reenvío son una causa oculta común de congelamientos intermitentes. Una configuración puede funcionar bien con pocos espectadores y comenzar a congelarse cuando el servidor se vuelve más ocupado, porque los ECM en cola añaden unos cientos de milisegundos a cada salto en la cadena.

Probando una línea y leyendo el estado de la conexión

En un receptor Enigma2 que ejecuta CCcam, navega al panel de información de CCcam (generalmente bajo Plugins → Información de CCcam). Verás cada línea de servidor con su estado de conexión, el número de tarjetas visibles y, lo más importante, el tiempo de respuesta del ECM en milisegundos.

Un tiempo de ECM saludable es generalmente inferior a 400 ms. Menos de 200 ms es sólido. Si ves 600 ms o más, espera congelamientos. Los tiempos de ECM que aumentan de manera constante apuntan a carga del servidor o congestión de red, no a un problema de configuración. Un número alto constante (digamos, siempre 800 ms) sugiere distancia geográfica o problemas de enrutamiento de paquetes.

Solución de problemas: Sin canales, congelamientos y 'Tarjeta no encontrada'

La mayoría de los problemas de compartir tarjetas caen en tres categorías: el CW no llega en absoluto, el CW es incorrecto o el sintonizador DVB tiene un problema de señal que no tiene nada que ver con el compartir tarjetas. Mezclar estos problemas desperdicia horas.

Pantalla negra vs canal encriptado — Diagnosticar la diferencia

Una imagen encriptada o pixelada (no una pantalla negra limpia) significa que el canal está sintonizando correctamente pero la decriptación está fallando. La señal está ahí; el CW no. Una pantalla negra limpia es más probable que sea un problema del sintonizador: frecuencia de transpondedor incorrecta, voltaje de LNB malo o un SID que simplemente no está en los derechos de la tarjeta.

Antes de culpar al compartir tarjetas por una pantalla negra, verifica la fuerza de la señal y SNR/BER en los diagnósticos del sintonizador del receptor. Compartir tarjetas no puede arreglar una señal débil o ausente. Un problema de conexión de LNB, una configuración incorrecta de DiSEqC o un cable LNB dañado se ven idénticos a un problema de suscripción desde la perspectiva del usuario, pero no tienen nada que ver con la tarjeta.

Desajuste de CAID/proveedor y lectura de la tarjeta local correcta

La entrada de registro "sin lector coincidente" en OScam es tu punto de partida diagnóstico. Significa que un ECM llegó para una combinación de CAID/ident que ningún lector está configurado para manejar. Abre la interfaz web de OScam, ve al registro en vivo y busca los valores de CAID e ident en la línea de ECM fallida. Compáralos con tu bloque de lector en oscam.server y la asignación de ident en oscam.user.

Los broadcasters ocasionalmente actualizan los valores de CAID o ident de proveedor junto con las actualizaciones de software de la tarjeta. Una tarjeta que decodificó todo bien durante meses de repente deja de funcionar después de una actualización OTA, y la única pista es que el CAID en el registro de ECM ya no coincide con oscam.server. Actualiza tus valores de CAID e ident para que coincidan con lo que informa el registro en vivo.

Firewall, NAT y reenvío de puertos para servidores autoalojados

Si estás alojando un servidor OScam y los clientes fuera de tu LAN no pueden conectarse, el puerto necesita ser reenviado en tu enrutador. Para un servidor que escucha en el puerto 12000:

# ejemplo de iptables

En tu enrutador, reenvía el puerto TCP 12000 a la IP local del servidor. Verifica connetstat -tlnp | grep 12000 en el servidor que OScam está realmente vinculado a ese puerto.

CGNAT es un problema separado. Si tu ISP te coloca detrás de NAT de grado de operador, tu IP pública no es tuya — se comparte entre múltiples clientes. Puedes conectarte saliendo como cliente sin problemas, pero las conexiones entrantes a tu IP "pública" nunca llegan a tu servidor. Las únicas opciones reales son una VPN con una IP dedicada, un VPS como relé o cambiar a un ISP que proporcione una dirección enrutada real. No hay truco de reenvío de puertos que solucione CGNAT desde el lado del enrutador.

MTU, latencia y congelamientos intermitentes

El congelamiento intermitente que ocurre cada 7–10 segundos sigue casi exactamente la rotación de la CW. La nueva palabra de control no está llegando antes de que expire la antigua. Comienza con el tiempo de ECM en el menú de información del receptor; si es consistentemente superior a 400 ms, ese es tu problema.

Las discrepancias de MTU en ciertas conexiones de ISP pueden fragmentar paquetes TCP de una manera que añade latencia específicamente a cargas útiles pequeñas y sensibles al tiempo, como las respuestas de CW. Si has descartado la carga del servidor y la distancia geográfica, intenta configurar el MTU en la interfaz de red de tu servidor a 1460 o 1452 y verifica si los tiempos de ECM se estabilizan.

La pérdida de paquetes es más destructiva que la latencia aquí. Incluso una pérdida del 1–2% en el camino entre el cliente y el servidor significa que algunas respuestas de CW se pierden o se retransmiten, y una respuesta de CW retransmitida después de la ventana de rotación significa un congelamiento. Usamtr oping -f para verificar el camino en busca de pérdidas antes de perseguir problemas de configuración.

Leyendo los registros de OScam para identificar el ECM fallido

Habilita el registro detallado conoscam -d 255 o a través de la interfaz web (Config → Logging, establece el nivel de registro en depuración). Luego busca el SID o CAID del canal:

grep -i "no matching reader" /var/log/oscam/oscam.log

Frases clave de registro que debes conocer: "no matching reader" significa que la ruta CAID/ident falló. "rejected" después de una línea de usuario significa que la autenticación está fallando: contraseña incorrecta o la cuenta de usuario no existe. "DCW checksum error" es un problema de hardware: tu lector de tarjeta inteligente está devolviendo datos corruptos, generalmente por contactos de tarjeta oxidados o un lector USB PCSC defectuoso. Limpia los contactos de la tarjeta con alcohol isopropílico, o prueba con un lector diferente.

Los problemas de reloj del receptor son una causa subestimada de confusión en los registros. Si el tiempo del sistema del servidor está significativamente desfasado (digamos, más de 20 minutos), los registros de autenticación muestran rechazos que parecen relacionados con credenciales pero que en realidad se basan en la marca de tiempo. Ejecutantpdate -u pool.ntp.org o habilita NTP en la configuración de tu sistema y asegúrate de que el reloj esté sincronizado antes de culpar a las credenciales.

Elegir una fuente de servidor: criterios, no nombres

La pregunta fundamental al evaluar cualquier fuente de intercambio de tarjetas es: ¿cuánto de la cadena controlas? La propiedad local de la tarjeta y el alquiler de línea remota son situaciones genuinamente diferentes con diferentes modos de falla.

Tarjeta local vs línea remota: lo que realmente controlas

Con una tarjeta física en tu propio lector, controlas todo. Las actualizaciones de EMM llegan directamente a la tarjeta, puedes ver el estado del lector en OScam y no dependes del tiempo de actividad de nadie más. La desventaja es el costo y la necesidad de tener una suscripción local válida.

Una línea remota significa que alguien más posee la tarjeta y ejecuta el servidor. Obtienes una C-line, la agregas a tu configuración y o funciona o no. Si su servidor se cae, no tienes visibilidad sobre por qué y ninguna forma de solucionarlo. Su tarjeta también necesita recibir EMMs: si la configuración del titular de la tarjeta no maneja correctamente el reenvío de EMM, verás que los canales caen después de los períodos de renovación de suscripción, incluso si la conexión en sí parece saludable.

Indicadores de estabilidad y tiempo de actividad para evaluar

Al evaluar cualquier fuente de tarjetas, la prueba más útil es un período de prueba en el que observes activamente los tiempos de ECM bajo diferentes cargas: la hora pico de la tarde es más dura para un servidor que las horas fuera de pico. Una fuente que devuelve tiempos de ECM de 80 ms a las 2 a.m. puede alcanzar 600 ms a las 8 p.m. cuando los clientes concurrentes alcanzan su punto máximo.

Las caídas de conexión que requieren reinicios manuales de C-line son una señal de alerta. OScam se reconectará automáticamente, pero un servidor que cae conexiones regularmente indica inestabilidad en alguna parte de su infraestructura. Observa la pestaña "Clientes" de la interfaz web de OScam para ciclos frecuentes de conexión/desconexión en tus propios usuarios como un proxy de cuán estable se comporta el servidor bajo carga.

Profundidad de reenvío, cobertura de CAID y qué verificar

Un proveedor que publicita una larga lista de CAID debe ser verificado en función de lo que realmente necesitas. Pregunta específicamente qué CAIDs e identidades están activos en la tarjeta, no solo lo que dice el marketing. Conecta una línea de prueba, abre la interfaz web de OScam y mira la información de la tarjeta para ese lector. ¿Qué CAIDs aparecen realmente? ¿Coinciden con los canales que intentas decodificar?

La profundidad de reenvío por encima del salto 2 es generalmente inútil y perjudicial para los tiempos de ECM. Cualquier fuente que establezca el reenvío en salto 5 o superior no está pensando en la latencia o está tratando de maximizar la cantidad de clientes. Ninguna de las dos es buena para tu configuración.

Latencia, ubicación del servidor y calidad de peering

La proximidad geográfica al servidor no se trata solo de ping bruto; se trata de peering. Un servidor a 500 km de distancia en una conexión de centro de datos bien interconectada puede superar a un servidor a 50 km de distancia en una conexión residencial congestionada. Haz ping a la IP del servidor desde tu red antes de comprometerte con una línea. Cualquier cosa por debajo de 30 ms es excelente; 30–80 ms es manejable; por encima de 150 ms estarás luchando constantemente con el tiempo de ECM.

En el lado legal: los derechos de intercambio de tarjetas con una tarjeta más allá de su alcance de visualización con licencia — compartir una sola suscripción entre varios hogares, por ejemplo — generalmente viola los términos del acuerdo de suscripción y, en algunas jurisdicciones, puede entrar en conflicto con la ley de transmisión o derechos de autor. Los detalles varían significativamente según el país y el tipo de suscripción. Asegúrate de entender lo que está permitido bajo los términos específicos de tu suscripción antes de configurar cualquier cosa.