MgCamd Share No Abre: Guía de Solución (OSCam/CCcam)

Si has llegado aquí buscandomgcamd: share not opening решение, ya conoces el infierno específico de ver un estado de conexión verde mientras tus canales permanecen completamente en negro. La línea parece estar conectada. MgCamd no se está bloqueando. Pero nada se decodifica. Esta guía aborda las causas reales en orden de probabilidad, comenzando con tu configuración local y terminando en el servidor.

Esto no es un recorrido de "pega esta plantilla". Cada sección a continuación asume que ya tienes MgCamd en funcionamiento y credenciales en mano, solo que no puedes obtener una palabra de tarjeta de ellos.

Lo que 'Share No Abre' Realmente Significa en MgCamd

La frase "share not opening" describe un estado de fallo específico que es completamente diferente de un error de inicio de sesión. MgCamd se autentica correctamente en el servidor newcamd: usuario, contraseña, puerto, todo está bien, pero cuando tu caja sintoniza un canal y envía un ECM (Mensaje de Verificación de Derecho), no regresa ninguna palabra de control descifrada (dcw). El canal está encriptado. El bucle de decodificación nunca comienza. Pantalla negra.

La mayoría de las guías confunden "no se puede conectar" con "share not opening" y por eso son inútiles para este problema.

Conexión activa vs. fallo de decodificación: dos problemas diferentes

Un fallo de inicio de sesión se parece a una línea que se cae inmediatamente o nunca muestra como conectada. MgCamd registrará algo comoinicio de sesión fallido o simplemente intentará reconectarse repetidamente. Verás la conexión rebotar en/var/log/mgcamd.log o donde sea que tu imagen lo registre.

Un fallo de decodificación es más silencioso. La línea aparece activa. MgCamd se considera conectado. Pero el ECM que tu caja envía no recibe respuesta. El canal nunca se abre porque nadie está devolviendo una CW válida para el período de encriptación actual, que rota cada 10 segundos en la mayoría de los sistemas.

Leyendo el registro de MgCamd: marcadores de solicitud de ECM, respuesta y tiempo de espera

Primera cosa: aumenta la verbosidad. En/var/keys/mg_cfg, encuentra la línea de depuración y configúralo en nivel 3:

G: { 03 }

Con eso habilitado, una decodificación saludable se ve algo así en el registro:

[mgcamd] ecm para caid 0x0500 pid 0x0136 proveedor 0x032820

Una rota se ve así:

[mgcamd] ecm para caid 0x0500 pid 0x0136 proveedor 0x032820

O peor, no obtienes ninguna solicitud de ECM registrada en absoluto, lo que significa que MgCamd ni siquiera está enroutando el CAID del canal a esa línea. Problema diferente, misma pantalla negra.

Flujo del protocolo Newcamd: inicio de sesión OK pero sin dcw

El apretón de manos newcamd tiene dos fases. Fase uno: conexión TCP, intercambio de clave DES, autenticación de usuario/contraseña. Fase dos: tráfico real de ECM/dcw. Puedes pasar la fase uno completamente y aún así fallar en la fase dos. Una clave DES incorrecta es el ejemplo clásico: el apretón de manos a veces se completa en un estado degradado que muestra "conectado" pero no produce nada. Una tarjeta expirada en el servidor es otra: el inicio de sesión funciona bien, la verificación de derechos devuelve vacío.

Paso 1: Verifica la Línea Newcamd y la Clave DES

Abre/var/keys/newcamd.list y mira tu línea CWS. El formato es:

CWS = hostname puerto nombredeusuario contraseña 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Ese último bloque es la clave DES. Debe ser exactamente de 14 bytes, escrita como 14 pares hexadecimales separados por espacios. Algunas configuraciones lo escriben sin espacios como una cadena hexadecimal de 28 caracteres. Ambos formatos existen; sabe cuál espera tu imagen.

Sintaxis de newcamd.list: CWS = host puerto usuario contraseña clave-DES

Una línea de trabajo completa se ve así:

CWS = myserver.example.com 17000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Después de la clave DES, puedes opcionalmente fijar un CAID y un ID de proveedor:

CWS = myserver.example.com 17000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14 0500 032820

Si el CAID/ident está incorrecto, nada para ese proveedor se decodificará en esta línea, incluso si el servidor tiene la tarjeta.

La trampa de la clave DES de 14 bytes (28 caracteres hexadecimales)

Esta es la causa más común del problema de conectado-pero-negro. Alguien copia una clave DES con un espacio al final, omite un carácter o la pega desde un PDF que sustituyó un cero por la letra O. La clave parece estar bien a simple vista. MgCamd se conecta. Nada se decodifica.

Cuenta tus caracteres. Si la clave está escrita como pares separados por espacios: cuenta 14 pares. Si es una cadena hexagonal continua: cuenta exactamente 28 caracteres. No 27. No 29. 28.

También observa las inconsistencias entre minúsculas y mayúsculas. El protocolo newcamd no distingue entre mayúsculas y minúsculas para hex, pero algunas versiones de MgCamd han mostrado comportamientos erráticos con claves de caso mixto. Normaliza a mayúsculas si estás persiguiendo un fantasma.

Probando la conectividad: telnet/nc al puerto newcamd

Antes de culpar la configuración, confirma que la conexión TCP realmente funciona desde tu equipo:

nc -zv myserver.example.com 17000

Quieres ver¡Conexión a myserver.example.com 17000 puerto [tcp/*] exitosa!. Si se agota el tiempo o se rechaza, ni siquiera estás alcanzando el servidor — MgCamd mostrando "conectado" mientras esto falla significa que hay un estado en caché/obsoleto, que se limpia al reiniciar.

Números de puerto comunes y verificaciones de firewall/NAT

Los puertos newcamd varían según la configuración del servidor, pero comúnmente funcionan entre 10000–20000. Algunos operadores utilizan 17000, 15000 o rangos personalizados. Si estás detrás de CGNAT o doble-NAT (común con internet móvil o algunos ISP), la conexión TCP desde tu equipo puede parecer establecerse localmente, pero el servidor nunca ve un socket real. El estado "conectado" en MgCamd se basa en la finalización del apretón de manos TCP local — no prueba que el socket del lado del servidor sea funcional.

Prueba desde una red diferente si sospechas problemas de NAT. También verifica que ningún firewall en tu router esté bloqueando silenciosamente las salidas en ese puerto.

Paso 2: Verifica CAID, Proveedor y Enrutamiento de ECM PID

Incluso con un newcamd.list perfecto, los ECM aún pueden no ir a ninguna parte si MgCamd los está enrutando a la línea incorrecta o el lector del servidor no lleva ese CAID. Esta es la segunda causa más común demgcamd: compartir no abriendo решение problemas — y casi siempre es invisible sin registros detallados.

Restringiendo una línea al CAID/ident correcto

En/var/keys/mg_cfg, elC: bloque define qué CAIDs maneja cada línea. Un ejemplo:

C: ( 0500 )

La segunda forma se fija a un identificador de proveedor específico dentro del CAID. Si tu servidor solo lleva el identificador 032820 pero envías ECMs para el identificador 040810, esas solicitudes no devuelven nada. Haz coincidir el identificador con lo que el servidor realmente tiene — pregunta al operador si no lo sabes, o verifica en OSCam webif.

Cuando el CAID del canal no está en el lector

Algunos canales transmiten múltiples CAIDs en el mismo transpondedor. Tu equipo podría seleccionar el CAID 0x0100 (Seca) mientras que el servidor solo tiene 0x0500 (Viaccess). La solución es forzar a tu equipo a usar el CAID que lleva el servidor, o configurar la lista de prioridades de MgCamd para preferir el correcto. En mg_cfg, elP: líneas establecen el orden de prioridad para los CAIDs cuando hay múltiples opciones disponibles.

ECM PID y transpondedores de múltiples CAID

Este caso extremo atrapa a las personas con frecuencia. Un transpondedor lleva un canal encriptado con dos sistemas CA diferentes — digamos Nagravision en PID 0x0600 e Irdeto en PID 0x0601. Tu receptor podría bloquearse en el PID de Irdeto porque está listado primero en el PMT. MgCamd envía el ECM a tu línea de Irdeto, que no tiene tarjeta. Mientras tanto, tu línea de Nagravision permanece inactiva con una tarjeta perfectamente válida que la decodificaría al instante.

Forza el ECM PID en la configuración del canal de tu receptor si tu imagen lo soporta, o configura MgCamd para enrutear ese CAID específico exclusivamente a la línea correcta.

Listas de prioridad e ignorar (entradas mg_cfg C:/P:)

LasI: (ignorar) líneas en mg_cfg son la inversa deC: — le dicen a MgCamd que nunca envíe un CAID/ident específico a una línea particular. Úsalas cuando tengas múltiples líneas y quieras evitar que una línea débil intercepte ECMs que no puede responder:

I: ( 0500:040810 )

Combinado con entradas explícitasP: de prioridad, puedes dirigir cada CAID/ident a exactamente una línea y eliminar condiciones de carrera entre múltiples entradas CWS.

Paso 3: Diagnosticar desde el lado del servidor (OSCam/CCcam)

En este punto, si tu configuración parece correcta, el problema podría no estar en tu caja en absoluto. Obtener visibilidad del lado del servidor es lo que separa una solución de 20 minutos de una sesión de depuración de 3 horas.

Servidor newcamd de OSCam: [newcamd] clave, puerto y bloque de usuario

Si el servidor ejecuta OSCam, verifica/etc/oscam/oscam.conf y/etc/oscam/oscam.server. El oyente newcamd necesita una sección dedicada enoscam.conf:

[newcamd]

Laclave = aquí debe coincidir exactamente con la clave DES en tunewcamd.list. La vinculación del puerto opcionalmente añade@CAID:ident para restringir lo que este oyente sirve. Si el CAID/ident en tu caja no coincide, OSCam puede aceptar el ECM y descartarlo inmediatamente.

Las cuentas de usuario se encuentran en/etc/oscam/oscam.user. Confirma que tu nombre de usuario tenga el CAID y el ident correctos en loscaid = yident = campos, y quedisabled = 0 .

Estado del webif de OSCam: lector, ecm y 'no encontrado' vs 'tiempo de espera'

La interfaz web de OSCam (comúnmente accesible en el puerto 8888 o 8383) es la herramienta de diagnóstico más útil que tienes. En la pestaña de historial de ECM, verás uno de tres resultados para las solicitudes de ECM entrantes:

• encontrado — la tarjeta lo decodificó, un CW válido regresó a MgCamd. Si tu caja sigue en negro, la falla es local.
• no encontrado — OSCam recibió el ECM pero ningún lector pudo responder. Tarjeta faltante, CAID incorrecto o sin derecho.
• tiempo de espera — OSCam reenvió el ECM aguas arriba pero no obtuvo respuesta dentro del tiempo de espera configurado. Problema de salto aguas arriba.

Esa división en tres vías localiza la falla con precisión. "Encontrado pero negro" es un problema local de PID/cam. "No encontrado" es un problema de tarjeta/derecho. "Tiempo de espera" es un problema de cadena aguas arriba.

CCcam nueva exportación newcamd y visibilidad compartida

Para servidores CCcam, verifica/etc/CCcam.cfg. La sección de exportación newcamd necesita unPUERTO DE ESCUCHA NEWCAMD: entrada y la correspondienteN: host puerto nombre de usuario contraseña clave-DES definiciones de cliente — o el equivalente del lado del servidor para comparticiones salientes. En las páginas de información de CCcam (generalmente puerto 16001), verifica que la tarjeta que esperas esté realmente en la lista de comparticiones y marcada como disponible localmente, no solo como una compartición remota de otro salto que podría estar caído.

Disponibilidad de la tarjeta, AU y verificación de derechos

Una configuración técnicamente perfecta aún puede producir "compartición no abierta" si la tarjeta en sí no tiene derechos válidos. Las tarjetas caducan. Los proveedores rotan claves con actualizaciones EMM. Si AU (Actualización Automática) no está funcionando — la tarjeta necesita estar físicamente en un lector conectado a un servidor que esté recibiendo EMMs activamente — los derechos se vuelven obsoletos y la decodificación se detiene aunque la tarjeta esté presente y OSCam la muestre como activa.

En OSCam, verifica el estado del lector en webif: mira la lista de derechos y la última marca de tiempo de EMM. Una tarjeta que no ha recibido un EMM en días es sospechosa.

Paso 4: Ajustar Temporización, Caché y Límites de Tasa de ECM

Si la configuración es correcta y la tarjeta tiene derechos, pero aún experimentas pantallas negras intermitentes o congelamientos después de unos segundos, el problema está relacionado con la temporización. Esto cubre la categoría más difícil demgcamd: solución de compartición no abierta problemas porque se ven diferentes cada vez.

Ajuste del tiempo de espera de ECM en mg_cfg (M: / T: valores)

El tiempo de espera de MgCamd para esperar una respuesta dcw está controlado por elM: (tiempo máximo de ecm) valor en mg_cfg, a menudo expresado en unidades de 100ms. Una configuración como:

M: { 3 }

Significa que MgCamd espera 300ms antes de rendirse en una respuesta CW. Para un servidor a dos saltos de distancia con algo de latencia, eso es ajustado. Aumenta a 6 u 8 (600–800ms) y prueba. Ir demasiado alto crea un problema diferente: podrías perder un período de rotación de CW y obtener un congelamiento en lugar de una imagen continua. Equilibra según tu latencia real del servidor.

El patrón de congelamiento después de unos segundos ocurre específicamente cuando ocurre la rotación de CW (aproximadamente cada 10 segundos) y el nuevo CW no llega a tiempo. El CW anterior expira, la imagen se congela, y dependiendo de tu caja, puede o no recuperarse. Un control de temporización más estricto del lado del servidor, o usar la caché de CW de OSCam, puede suavizar esto.

cache-ex / caché de pares causando CWs obsoletos

La función cache-ex de OSCam permite que múltiples instancias de OSCam compartan CWs decodificados. Esto es normalmente una mejora de rendimiento: un CW que acaba de ser decodificado por un servidor se sirve instantáneamente al siguiente solicitante. Pero un par de caché mal configurado puede servir un CW obsoleto del período criptográfico anterior. Tu caja recibe un CW que parece válido, lo aplica, y la imagen es basura o está congelada porque la encriptación ya ha rotado.

Si ves una imagen breve (1–2 segundos y luego congelamiento), desactiva cache-ex temporalmente y verifica si se estabiliza. Si lo hace, el par de caché está devolviendo datos incorrectos.

Limitación de tasa de ECM y estrangulación de 'demasiados ecm'

Los servidores bajo carga a menudo implementan limitación de tasa de ECM por cuenta de usuario. Si tu caja está enviando ECMs demasiado rápido (cambio de canal, mala interpretación de PMT enviando solicitudes duplicadas), el servidor comenzará a descartar solicitudes. En los registros de OSCam esto se muestra comodemasiados ecm o simplemente silencio — el ECM es recibido y descartado sin respuesta.

Las pantallas negras solo en horas pico son casi siempre esto. El lector del servidor está abrumado. No hay mucho que puedas hacer del lado del cliente excepto reducir el tráfico innecesario de ECM — no escanear canales rápidamente, asegurarte de que tu caja no esté enviando ECMs duplicados para el mismo PID, y esperar el período pico.

Interferencia de un segundo cam (prioridad de softcam)

Este es sutil y realmente causa el escenario de "funcionó ayer, roto hoy". Si se instaló o habilitó un segundo softcam — o si tu imagen tiene un decodificador incorporado que se activa en ciertos CAIDs — puede capturar el ECM antes de que MgCamd lo obtenga. El cam incorporado no logra decodificar (sin tarjeta), no devuelve nada, y MgCamd nunca ve la solicitud en absoluto porque el ECM fue consumido aguas arriba.

Verifica la configuración de prioridad de cam de tu imagen y asegúrate de que MgCamd tenga la máxima prioridad para los CAIDs que estás compartiendo. Desactiva completamente los cams competidores para esos CAIDs si tu imagen lo soporta. El síntoma es: el registro de ECM en MgCamd no muestra solicitudes en absoluto para un canal que debería estar solicitándolas.

Trabajar a través de estos pasos de manera sistemática es el único camino confiable al enfrentarmgcamd: compartir no abriendo решение errores — no hay una solución única porque la falla puede estar en seis lugares diferentes. Comience localmente (clave DES, enrutamiento CAID), pase a la verificación del lado del servidor (interfaz web de OSCam, comparticiones de CCcam), luego investigue el tiempo y la interferencia. La división "encontrado / no encontrado / tiempo de espera" de OSCam es la herramienta de diagnóstico más poderosa disponible y la mayoría de la gente nunca la utiliza.