Configuración de MGCamd Reshare: Configuración Completa& Guía de Newcamd

Una adecuadaconfiguración de mgcamd reshare confunde a muchas personas — y con buena razón. La mayoría de las guías en línea asumen que MGCamd funciona como un mini-servidor al que puedes apuntar otros receptores. No es así. MGCamd es un cliente. Entender esa distinción es la diferencia entre pasar una noche depurando y realmente hacer que tus cajas downstream decodifiquen.

Esta guía cubre toda la arquitectura: qué archivos controlan qué, cómo hacer un puente a través deOScam para un verdadero resharing, y cómo depurar los modos de falla más comunes, incluyendo el frustrante problema de "la fuente decodifica bien pero el downstream se congela".

Cómo Funciona Realmente el Reshare de MGCamd

MGCamd como Cliente vs. como Fuente de Reshare

MGCamd es fundamentalmente unnewcamd/cs357x cliente. Se conecta hacia arriba, recibe palabras de control (CWs) y las entrega a tu sintonizador local. Ese es su trabajo. No hay un daemon de servidor newcamd integrado escuchando conexiones downstream — MGCamd no abre un puerto al que otros receptores puedan conectarse.

Así que cuando la gente habla sobre una configuración de mgcamd reshare, lo que realmente quieren decir (ya sea que lo sepan o no) es usar MGCamd para recibir la línea de upstream y luego hacer un puente a través de algo más — típicamente OScam — para servir a los clientes downstream.

La Cadena del Protocolo Newcamd: Cliente → MGCamd → Downstream

La cadena realista se ve así: tu línea de tarjeta upstream se conecta a través del protocolo newcamd a MGCamd. MGCamd desencripta y pasa CWs localmente. OScam, que se ejecuta en la misma caja, se conecta al mismo upstream como un lector newcamd — o, si eres astuto, lee de la memoria compartida de MGCamd. OScam luego ejecuta sus propios puertos de servidor newcamd/cccam a los que se conectan los receptores downstream.

La profundidad de reshare — a veces llamada saltos — es cuántas veces se puede reenviar un CW antes de que sea bloqueado. Cada salto añade latencia. A dos saltos de profundidad ya estás mirando tiempos ECM de 400–800ms si algo en la cadena falla.

Por Qué MGCamd Solo Es Limitado para Resharing

MGCamd 1.35, 1.38 y 1.45 carecen de un listener de servidor. Puedes configurar el intercambio de caché a través de cache-ex para intercambiar CWs con pares, pero eso es un intercambio de CW lateral entre iguales, no un verdadero modelo de reshare servidor-cliente. No pierdas tiempo buscando una configuración de "puerto de reshare" en mg_cfg — no está allí.

Algunas compilaciones de MGCamd de terceros afirman tener capacidad de reshare, pero en la práctica son inestables y están mal documentadas. El puente OScam es el enfoque que realmente funciona de manera confiable.

Cuándo Emparejar MGCamd con OScam como el Servidor de Reshare

Usa este emparejamiento cuando tengas una línea upstream y quieras servir a 2–10 receptores downstream. OScam maneja la autenticación, el filtrado de CAID, los límites de maxhops y los permisos de reshare por usuario de manera limpia. MGCamd permanece como el cliente upstream si tu línea upstream lo requiere específicamente, aunque muchas configuraciones omiten completamente MGCamd y solo usan OScam como cliente y servidor.

Requisitos Previos y Diseño de Archivos

Archivos Requeridos: newcamd.list, mg_cfg, cw_list

Tres archivos hacen la mayor parte del trabajo en MGCamd.newcamd.list contiene tus líneas de conexión de servidor — una entrada CWS por línea upstream.mg_cfg controla el comportamiento en tiempo de ejecución: tiempos de espera, configuraciones de caché, verbosidad de depuración, reintento de conexión.cw_list es opcional pero útil — te permite filtrar qué CAIDs y proveedores procesa MGCamd, lo cual es importante cuando estás resharing un feed mixto y solo algunos proveedores están permitidos hacia adelante.

Rutas Comunes: /var/keys/, /var/emu/, /etc/tuxbox/

En imágenes de Enigma2 (OpenPLi, OpenATV, etc.) normalmente encontrarás la configuración de MGCamd en/var/keys/. Las imágenes más antiguas, particularmente las basadas en Gemini o las compilaciones de DreamElite, utilizan/var/emu/. Algunas compilaciones integradas colocan todo bajo/etc/tuxbox/config/.

Verifica qué directorio referencia el script de inicio de tu compilación antes de editar. Editar la copia incorrecta y preguntarse por qué nada cambia es una pérdida de tiempo clásica.

Compatibilidad de Versiones de MGCamd (1.35 / 1.38 / 1.45)

Los nombres de las banderas en mg_cfg cambiaron entre versiones. MGCamd 1.35 utiliza una sintaxis de cache-ex ligeramente diferente a la de 1.38 y 1.45. ElM: yG: la estructura de bloques es consistente, pero opciones como la definición de pares de caché cambiaron de formato. Siempre lee el archivo readme incluido con tu binario específico; no asumas que una configuración de una publicación en un foro coincide con tu versión.

Verificando que tu línea upstream esté decodificando antes de volver a compartir

No toques la configuración de reenvío hasta que la decodificación local funcione correctamente. Sintoniza un canal de pago, espera de 10 a 15 segundos y busca en tu registro de MGCamd el tiempo de ECM:grep "ecm time" /tmp/mgcamd.log. Quieres tiempos consistentes por debajo de 500 ms. Si ves tiempos de espera o "sin CW" antes de intentar volver a compartir, la configuración de reenvío solo añadirá confusión a un problema upstream.

Configurando la Línea newcamd.list

Anatomía de una Línea CWS: Host Puerto Usuario Contraseña Clave DES

Cada entrada ennewcamd.list sigue este formato:

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

La clave DES son los últimos 14 campos, cada uno un byte hexadecimal de dos dígitos, separados por espacios. Algunas compilaciones las aceptan sin espacios como una sola cadena de 28 caracteres. Ambos formatos existen en la práctica; verifica la configuración de ejemplo de tu compilación para saber cuál espera.

La sensibilidad a los espacios en blanco es real aquí. Un tabulador donde se espera un espacio, o un espacio extra antes de la nueva línea, puede romper el análisis en silencio. Usa un editor hexadecimal ocat -A para verificar caracteres ocultos si una línea se niega a conectarse.

La Clave DES de 14 Bytes y Por Qué Importan 28 Caracteres Hexadecimales

La clave DES autentica la sesión newcamd. Tiene 14 bytes, expresados como exactamente 28 caracteres hexadecimales. Un solo carácter incorrecto significa que el apretón de manos falla. El error en el registro se verá como un tiempo de espera de conexión o "inicio de sesión fallido", no como un error de formato de clave, por lo que es fácil confundirlo con un problema de red.

Tu proveedor upstream te da esta clave como parte de tus credenciales de línea. Cópiala exactamente. No la vuelvas a escribir manualmente; pégala y luego verifica el conteo de caracteres. 28 caracteres, sin espacios en la forma de 28 caracteres, sin truncamiento.

Configurando Banderas de Reenvío/Habilitar por Línea

Algunas compilaciones de MGCamd soportan banderas finales en la línea CWS:

CWS = hostname 15000 myuser mypass 01 02 03 04 05 06 07 08 09 10 11 12 13 14 01 00

Los bytes finales aquí (por ejemplo,01 00) pueden indicar el estado de habilitación/deshabilitación o pistas de reenvío dependiendo de la compilación. En MGCamd 1.38/1.45 estándar, estos bytes adicionales suelen ser ignorados. No los añadas a menos que el readme de tu versión documente específicamente lo que hacen; las banderas no documentadas añaden confusión sin beneficio.

Múltiples Líneas, Prioridad y Orden de Failover

MGCamd lee las líneas CWS de arriba hacia abajo y las prueba en ese orden. La primera línea que responde con un CW válido "gana" para ese ECM. Si tienes dos líneas que cubren diferentes CAIDs, coloca tu línea principal/más rápida primero. Si la primera línea se agota (basado en el valor de tiempo de espera en mg_cfg), MGCamd pasa a la siguiente.

El failover funciona, pero añade tiempo de ECM igual al tiempo de espera de la línea fallida. Mantén tu tiempo de espera lo suficientemente ajustado para que el failover no cause un congelamiento visible; 2000–3000 ms es un punto de partida razonable.

Banderas de mg_cfg que Afectan el Reenvío y la Estabilidad

M: (Modo de Configuración) y G: (Global) Bloques

mg_cfg está estructurado en bloques. ElM: el bloque establece el modo de operación — si MGCamd utiliza EMM local, comparte CWs, ejecuta cache-ex. ElG: bloque (o equivalente en tu versión) establece el comportamiento global como la verbosidad del registro y el tamaño de la caché. Un mg_cfg mínimo para una configuración de reenvío debería tener un nivel de registro lo suficientemente alto para ver los tiempos de ECM y el estado de conexión, pero no tan verboso que llene /tmp y cause problemas de E/S en el almacenamiento flash.

Configuraciones de Caché y Caché-EX (C: / Líneas de Caché)

La caché almacena CWs recibidos recientemente para que una segunda solicitud de ECM para la misma clave no necesite un viaje de red. En una configuración de reenvío, esto acelera la respuesta aguas abajo — pero también introduce una trampa: si dos nodos se reenvían entre sí (bucle accidental), pueden intercambiar CWs obsoletos o incorrectos que se almacenan en caché y se sirven repetidamente, causando un congelamiento persistente que parece un problema de red.

Si estás utilizando pares de cache-ex, asegúrate de que la topología sea estrictamente unidireccional. No hagas que el nodo A se conecte al nodo B y el nodo B se conecte de nuevo al nodo A a menos que hayas configurado explícitamente las banderas de detección de bucles.

Tiempo de Espera de ECM, Reintentos y Ajustes de Respaldo

El tiempo de espera de ECM en mg_cfg controla cuánto tiempo MGCamd espera por un CW antes de marcar una línea como no receptiva y probar la siguiente (o devolver sin CW). Para una topología de reenvío, este tiempo de espera también afecta a tus receptores aguas abajo — ellos esperan por MGCamd, que espera por el flujo ascendente.

Un valor de inicio seguro es 3000ms (3 segundos). Por debajo de 1500ms obtendrás tiempos de espera falsos en cualquier línea con carga moderada. Por encima de 5000ms, un solo ECM perdido causa un congelamiento visible aguas abajo. Ajusta hacia abajo una vez que la configuración esté estable.

Configuraciones de Anti-Cascada y Evitación de Congelamientos

Al algunas versiones de MGCamd incluyen comportamiento anti-cascada — limitando cuántos ECMs por segundo se reenvían hacia arriba. Esto protege a tu proveedor ascendente de una carga excesiva (y te protege de que te corten la línea). En una configuración de reenvío con varios receptores aguas abajo, la tasa de ECM puede aumentar porque cada receptor envía su propio ECM de forma independiente. Establece un límite razonable por segundo y monitorea tu tasa de ECM ascendente en el registro.

Puenteando MGCamd a OScam para Reenvío Real

Aquí es donde vive realmente una configuración funcional de reenvío de mgcamd. OScam maneja todo lo que MGCamd no puede: servir conexiones aguas abajo, permisos por usuario, filtrado de CAID y control adecuado de la profundidad de reenvío.

oscam.server: Tipo de Lector=newcamd Apuntando a Tu Línea

En/etc/oscam/oscam.server, define un lector que se conecte a tu línea ascendente utilizando el protocolo newcamd:

[reader]

Elkey campo aquí es tu clave DES de 14 bytes en 28 caracteres hexadecimales, sin espacios. Elgroup valor vincula este lector a los usuarios de OScam — un usuario en el grupo 1 puede usar este lector. Si los grupos no coinciden, no se reenvían ECMs independientemente de que todo lo demás sea correcto.

oscam.user con servidor cccam/newcamd + maxhops y reenvío

En/etc/oscam/oscam.user, cada cuenta aguas abajo necesita un permiso de reenvío y asignación de grupo:

[account]

reshare = 1 significa que esta cuenta puede compartir un nivel más.reshare = 0 significa que el cliente puede decodificar pero no puede reenviar a nadie más.cccmaxhops limita cuántos saltos de CCcam aguas abajo de este usuario puede viajar un CW.

Puertos del Servidor oscam.conf (cs378x/newcamd/cccam)

En/etc/oscam/oscam.conf, habilita los protocolos de servidor que deseas ofrecer aguas abajo:

[newcamd]

La línea del puerto newcamd incluye la vinculación de CAID e identidades —15001@0500:000000 significa que el puerto 15001 maneja CAID 0500. Puedes vincular múltiples CAIDs en puertos separados o usar un puerto genérico. Estos son los puertos a los que se conectan tus receptores downstream, y deben ser accesibles a través de cualquier firewall o NAT entre tú y tus clientes.

Configurando reshare = N y cccmaxhops correctamente

Una configuración incorrecta común: establecerreshare = 1 en el usuario pero dejarcccmaxhops = 0, o viceversa. Ambos deben permitir la profundidad deseada. Si tu proveedor upstream estableció maxhops en 1 de su lado, tu cliente downstream recibe exactamente 1 salto — no puedes anular eso desde tu lado. Solo puedes limitar más, no extender.

Para un simple compartir de dos niveles (tú → cliente),reshare = 1 ycccmaxhops = 1 en la cuenta del cliente es suficiente.

Solucionando problemas: se conecta pero no reenvía

Inicio de sesión OK pero no se reenvió ECM (desajuste de grupo/CAID)

Este es el problema más común en cualquier configuración de reenvío de mgcamd y siempre es un desajuste de grupo o CAID. En el registro de OScam (/var/log/oscam/oscam.log), busca líneas que contengan "no matching reader" o "no card for caid." Si ves "connected" para el cliente de downstream pero no hay actividad de ECM, el lector no está siendo seleccionado para las solicitudes de ese usuario.

Solución: asegúrate de que elgrupo número en tu bloque de lector oscam.server aparezca en elgrupo campo de la cuenta oscam.user. Y asegúrate de que el CAID que está solicitando el downstream esté realmente listado en ambos lugares.

Congelamientos en Downstream pero la Fuente Decodifica Bien

Cuando tu sintonizador local decodifica correctamente pero el receptor downstream se congela cada 8–15 segundos (un período criptográfico), el CW está llegando tarde o incorrecto. Tarde = tiempo de espera de ECM, incorrecto = bucle de caché sirviendo un CW obsoleto.

Grep el registro de OScam para tiempos de ECM en la cuenta downstream:grep "client1" /var/log/oscam/oscam.log | grep "ecm". Si los tiempos están aumentando a más de 2000ms intermitentemente, aumenta el tiempo de espera. Si los tiempos son rápidos pero el downstream aún se congela, sospecha de un CW incorrecto de la caché — desactiva temporalmente cache-ex para probar.

'Tarjeta No Encontrada' / No se Pasaron Derechos

Este error significa que OScam recibió la solicitud de ECM del cliente downstream pero no encontró ningún lector capaz de manejarla. O el lector no está funcionando (verifica el estado del lector de oscam), el filtro de CAID está excluyendo la solicitud, o la línea upstream no lleva ese proveedor.

Verificaoscam.server: sicaid = está configurado demasiado estrechamente, las solicitudes para otros CAIDs en la misma línea se eliminan silenciosamente. Un feed upstream de CAID mixto donde solo algunos CAIDs están autorizados para reenvío es un escenario real — el proveedor upstream puede permitir reenvío de 0500 pero no de 1800. No puedes reenviar CAIDs que el upstream ha bloqueado en su extremo.

Profundidad de Reenvío Agotada (maxhops = 0)

Si tu proveedor upstream configuró su línea a maxhops = 1, y tú reenvías a un cliente, el maxhops de ese cliente = 0 — pueden decodificar pero no pueden reenviar más. Esto no es un error de configuración de tu parte; es el upstream imponiendo límites. Ninguna cantidad de ajustes en tu configuración de OScam extenderá los saltos más allá de lo que permite el upstream.

Si la línea upstream en sí llega con maxhops = 0 (puedes ver esto en la información del lector de OScam), entonces ni siquiera tú puedes reenviarla en absoluto — el upstream la ha bloqueado explícitamente. O renegocia con tu proveedor o consigue una línea diferente con permiso de reenvío.

Problemas de NAT, Firewall y Redes de Doble Salto

Un receptor downstream detrás de un segundo enrutador NAT (doble-NAT) es un problema común. La caja downstream puede alcanzar el puerto de tu servidor OScam, pero la conexión TCP desde un cliente detrás de un CGNAT o doble-NAT puede no funcionar sin el reenvío de puertos adecuado en cada capa.

Para clientes newcamd, el servidor no inicia conexiones — el cliente se conecta a tu puerto de servidor. Así que necesitas que tu puerto de servidor (por ejemplo, 15001) sea accesible desde Internet público. En el lado downstream, no es necesario que se abran puertos. Pero si tú mismo estás detrás de CGNAT, no puedes alojar fácilmente un servidor de entrada — considera un túnel VPN (WireGuard funciona bien para esto) entre tú y tus clientes downstream.

Verifica con:nc -zv your.server.ip 15001 desde la máquina downstream. Si eso se agota, es un problema de red/firewall antes de que cualquier configuración de MGCamd o OScam sea relevante.