Configuración de CCcam Radegast& Guía de Puertos

Si has llegado aquí, ya tienes una caja CCcam u OScam en funcionamiento y algo sobre el lado de Radegast de tu cadena está roto. La documentación es escasa, los hilos del foro se contradicen entre sí y nadie parece estar de acuerdo sobre qué archivo de configuración hace qué. Este artículo cubre el completoproceso de configuración y ajuste del protocolo CCcam radegast — desde la vinculación de puertos del lado del servidor hasta los registros de depuración y el túnel. Sin relleno, sin benchmarks falsos. Solo las líneas de configuración que realmente funcionan.

Lo que realmente es el Protocolo Radegast (y por qué confunde a la gente)

La confusión casi siempre comienza con la nomenclatura. La gente ve "Radegast", "newcamd" y "CCcam" usados indistintamente en la misma publicación del foro y asume que son variantes de lo mismo. No lo son, y confundirlos te hará perder horas de tu tiempo.

Radegast vs newcamd vs protocolo CCcam

Newcamd es un protocolo encriptado que utiliza 3DES. Cada conexión requiere una clave compartida (la clave DES de 14 bytes en la configuración del cliente), y la autenticación ocurre a nivel de apretón de manos. El protocolo nativo de CCcam es su propio formato binario con un apretón de manos diferente y su propia capa de encriptación. Radegast no es ninguno de esos. Es un protocolo de intercambio de palabras de control (CW) en gran medida en texto plano, diseñado para la simplicidad, no para la seguridad.

La diferencia práctica: con newcamd tienes un nombre de usuario de inicio de sesión, contraseña y clave DES. Con Radegast, no hay nada de eso. El servidor permite tu IP o no. Ese es todo el modelo de control de acceso.

Dónde encaja Radegast en una cadena CCcam/OScam

La mayoría de las configuraciones del mundo real que involucran Radegast se ven así: una instancia de OScam se encuentra entre el hardware de la tarjeta (o fuente ascendente) y el resto de la red. OScam expone un oyente Radegast al que los clientes locales o de LAN pueden conectarse. Si el dispositivo final de downstream solo habla el protocolo nativo de CCcam, encadenas una instancia local de CCcam al lector de OScam.

CCcam puro a Radegast sin OScam en el medio es técnicamente posible pero mal soportado. El manejo de Radegast de CCcam es limitado en comparación con OScam, que ha tenido soporte de Radegast de primera clase durante años. Si intentas hacer que CCcam actúe como un servidor Radegast nativo directamente, te encontrarás con muros rápidamente. El camino que funciona es OScam como el punto final de Radegast.

La nomenclatura cs357x (Radegast) y cs378x (Radegast sobre camd35/HTTP)

Aquí es donde la mayoría de la documentación se desmorona por completo. En la terminología de OScam,cs357x es el protocolo de lector Radegast clásico — el de texto plano. El nombre proviene de convenciones históricas de puertos.cs378x es una bestia diferente: es una variante camd35 sobre TCP (a veces llamada Radegast sobre HTTP) que añade una ligera capa de protección encima.

Cuando estés editandooscam.server, establecerásprotocol = radegast para conexiones cs357x yprotocol = cs378x para la variante camd35/HTTP. La mayoría de las guías nunca explican esta distinción, que es por qué la gente termina intentando palabras clave al azar hasta que algo funciona. Cuando veasprotocol = cs357x — esa es una notación más antigua y no universalmente aceptada en todas las compilaciones. Usaprotocol = radegast en el bloque del lector para el protocolo clásico.

Diseño en texto plano, no autenticado y lo que eso implica

Radegast no tiene encriptación y no tiene autenticación de usuario por diseño. La intención original era una distribución de CW simple y de bajo costo en redes locales de confianza. Hace bien su trabajo para ese caso de uso. Pero esta elección de diseño significa que cualquiera que pueda alcanzar el puerto puede solicitar palabras de control. Sin nombre de usuario, sin contraseña, sin intercambio de claves — solo una conexión TCP abierta.

Por eso Radegast es apropiado en una LAN de confianza y una idea genuinamente mala sobre Internet abierto sin un túnel. Más sobre eso en la sección de seguridad.

Configuración del lado del servidor: Exponiendo un puerto Radegast

El lado del servidor vive en dos archivos de OScam:oscam.conf (escucha global) y potencialmenteoscam.server (donde mapeas lectores específicos a la salida de Radegast). Primero, configura correctamente el bloque de escucha.

Bloque radegast de OScam oscam.conf

Abre/etc/oscam/oscam.conf y añade un[radegast] sección si no existe ya. Un bloque mínimo funcional se ve así:

[radegast]

Ese es el mínimo. OScam escuchará en el puerto TCP 8888 y aceptará conexiones solo desde localhost y la subred 192.168.0.x. No dejespermitido vacío — en algunas compilaciones eso por defecto acepta todas las conexiones, que es exactamente lo que no quieres.

También puedes añadirnodeid ouser parámetros dependiendo de tu versión de OScam, pero para una configuración básica de LAN las dos líneas anteriores te ponen en marcha. Guarda, luego reinicia OScam.

Configurando el puerto de escucha y los rangos de IP permitidos

El puerto 8888 es convencional para Radegast, pero no es obligatorio — puedes usar cualquier cosa por encima de 1024 que no esté ya ocupada. Verifica qué más está corriendo primero:ss -tlnp te da una lista completa de puertos vinculados. Si también estás ejecutando la interfaz web de OScam, ten cuidado con los conflictos — la interfaz web a menudo se ejecuta en el puerto 8888 o 16002 dependiendo de tu compilación. Configura uno de ellos a algo diferente.

Elcampo permitido acepta IPs individuales, rangos estilo CIDR, o rangos separados por guiones. Para un único host remoto de confianza:permitido = 192.168.1.50. Para una subred completa:permitido = 192.168.1.0-192.168.1.255. Mantenlo ajustado.

También piensa en qué interfaz estás vinculando. Por defecto, OScam se vincula a todas las interfaces (0.0.0.0). Si tu máquina tiene tanto una NIC externa como una NIC LAN interna, vincular a todas las interfaces significa que el puerto de Radegast es técnicamente accesible desde el lado externo también — tus reglas de firewall podrían bloquearlo, pero la defensa en profundidad importa. Puedes añadirbindaddr = 192.168.0.1 dentro del[radegast] bloque para fijarlo solo a la interfaz LAN.

Mapeando un lector/CAID a la salida de Radegast

OScam enruta las solicitudes ECM a través de su grupo de lectores automáticamente basado en la coincidencia de CAID. No necesitas un cableado explícito entre un lector y el oyente de Radegast — mientras tu lector enoscam.server esté en un grupo al que los clientes de Radegast puedan acceder, el enrutamiento ocurre internamente.

Si deseas restringir qué tarjetas puede consultar un cliente Radegast, establece elcaid yident filtros en la entrada del lector, y configura los grupos cuidadosamente. Un usuario del cliente Radegast (creado automáticamente o definido enoscam.user) puede ser restringido a grupos específicos que solo contengan los lectores que deseas que vea.

Reiniciando y confirmando que el puerto está escuchando

Después de reiniciar OScam, ejecuta esto en el servidor:

ss -tlnp | grep 8888

O si tu sistema es más antiguo:

netstat -tlnp | grep 8888

Deberías ver algo como0.0.0.0:8888 (o tu dirección de enlace específica) con el PID de OScam. Si no aparece nada, OScam no pudo analizar el bloque de configuración o tu compilación no incluye el módulo Radegast. Revisa el registro de inicio de OScam: registra qué oyentes activó.

Para confirmar que el módulo está compilado en:oscam --show-info 2>&1 | grep -i radegast. Si no obtienes nada, tu binario no tiene el lector/servidor Radegast compilado. Necesitarás una compilación diferente. Esto es más común de lo que la gente se da cuenta con compilaciones empaquetadas.

Configuración del lado del cliente: Leyendo un feed de Radegast

Una vez que se confirma que el servidor está escuchando, el lado del cliente es donde ocurre la mayor parte de la resolución de problemas diaria. La configuración va en el/etc/oscam/oscam.server archivo.

Lector OScam cs357x en oscam.server

Aquí hay un bloque de lector completo y funcional para una fuente Radegast (cs357x):

[reader]

Eldevice campo es IP y puerto como un par separado por comas — sin espacios. Elcaid campo le dice a OScam que solo pregunte a este lector sobre los servicios CAID 0x0500. Sin él, OScam consultará a este lector por todo y recibirás tiempos de espera de ECM en CAIDs que la fuente no puede servir.

Campos requeridos: device (host,puerto), protocol, caid, ident

Saltarcaid yident es el error de configuración más común que he visto. El lector se conectará bien, pero OScam enruta cada ECM desconocido a través de él, lo que añade latencia y llena tus registros con consultas fallidas. Siempre filtra a lo que la fuente realmente lleva.

Elident el formato del campo esCAID:ProviderID. Si no conoces el ID del proveedor, comienza con000000 como un comodín, luego estrecha una vez que puedas ver los IDs de proveedor reales en el registro ECM. Un filtrado de ident demasiado estricto es una de las causas de "conectado pero sin tarjetas" — cubierto en la sección de solución de problemas.

cs378x para la variante camd35/HTTP y cuándo preferirlo

El bloque de lector cs378x se ve casi idéntico, pero la palabra clave del protocolo y la autenticación cambian:

[reader]

cs378x añade una capa de nombre de usuario/contraseña y es más amigable con NAT porque el cliente inicia la conexión saliente — útil cuando el lado del servidor está detrás de un firewall que permite tráfico saliente pero no entrante. También maneja algunos casos extremos alrededor de la codificación CW de múltiples bytes que las implementaciones más antiguas de Radegast manejan incorrectamente. Para cualquier enlace que cruce Internet (incluso a través de un túnel), cs378x es la opción menos problemática.

En una LAN de confianza donde controlas ambos extremos, Radegast clásico (cs357x) está bien y tiene menos sobrecarga.

Grupo, retroceso y filtrado de CAID/proveedor

OScam utiliza grupos para controlar qué lectores están disponibles para qué usuarios. Si estás encadenando OScam → CCcam en la misma caja, la instancia local de CCcam generalmente aparece como un usuario auto-creado en OScam con acceso al grupo definido enoscam.user. Asegúrate de que el grupo en el lector Radegast coincida con lo que ese usuario tiene acceso.

Configurandofallback = 1 en un lector Radegast le dice a OScam que solo lo use cuando otros lectores fallen. Útil si tienes una tarjeta local primaria y la fuente de Radegast es una copia de seguridad — evita el reenvío innecesario de ECM al remoto cuando la tarjeta local puede manejarlo.

Solución de problemas: Sin tarjetas, Sin decodificación, Conexión rechazada

Esta es la sección que realmente importa. La mayoría de las guías arrojan un bloque de configuración y dicen que está hecho. El verdadero trabajo comienza cuando la configuración está en su lugar y algo aún no funciona.

Leyendo registros de OScam con nivel de depuración 4 para tráfico de lectores

Primer paso: aumentar el registro. Enoscam.conf bajo la[global] sección:

[global]

Luego reinicia con nivel de depuración:oscam -d 255 (desde la línea de comandos) o añadedebuglevel = 255 al[global] bloque para registro de depuración persistente. En el nivel 4+ verás líneas ECM individuales mostrando el CAID, ID del proveedor, el hex ECM en sí, y si el lector devolvió una CW o una respuesta de "no encontrado". En 255 obtienes todo — ruidoso pero completo.

Una línea ECM que tiene éxito se ve aproximadamente así:ECM 0500<hexstring> CW encontrado (127ms) por radegast_lan. Un fallo se ve así:ECM 0500<hexstring> CW no encontrado. La distinción entre "no encontrado" y "sin respuesta" es importante — ver abajo.

'Conexión rechazada' vs 'conectado pero sin respuesta de ECM'

"Conexión rechazada" significa una cosa: la conexión TCP falló. El puerto no está escuchando, o un firewall descartó el SYN. Verifica el servidor conss -tlnp | grep 8888, luego verifica iptables/nftables en el lado del servidor. También verifica lapermitida lista enoscam.conf — OScam descarta conexiones de IPs que no están en esa lista antes de que el lector las vea, y esto puede parecer un rechazo del firewall desde el lado del cliente.

"Conectado pero sin respuesta de ECM" es un problema completamente diferente. La ruta TCP está bien. Algo en la capa de protocolo está mal. La discrepancia de CAID o ident es la causa más común — la fuente ascendente simplemente no tiene una tarjeta que pueda descifrar el servicio solicitado. Verifica con tcpdump:tcpdump -i any port 8888 -X mientras el cliente intenta decodificar. Si ves paquetes de ECM llegando al servidor y nada regresando, el servidor recibió la solicitud pero no pudo encontrar un CW.

Discrepancia de CAID/proveedor y listas de tarjetas vacías

Un lector que se conecta pero devuelve listas de tarjetas vacías casi siempre tiene un problema de filtrado. O elcaid campo en el lector no coincide con lo que lleva la fuente, o elident campo tiene un ID de proveedor que no existe en la tarjeta.

Accede a la interfaz web de OScam en el servidor (puerto 8888 o 16002 — no el mismo puerto que Radegast, elige valores diferentes para cada uno) y verifica el estado del lector. Debería mostrar qué CAIDs y IDs de proveedor informa la tarjeta. Compara eso con tu configuración de lector en el cliente. Incluso un solo dígito hexadecimal incorrecto en el ID de proveedor producirá un resultado vacío sin mensaje de error.

Además: algunas versiones de OScam tienen el módulo Radegast compilado pero con enumeración de CAID sutilmente rota. Si todo lo demás está bien y aún obtienes listas vacías, prueba concaid yident eliminados por completo — si aparecen tarjetas, tus valores de filtrado estaban mal. Agrégales de nuevo uno a la vez.

Problemas de MTU, NAT y firewall a través de internet

Si estás ejecutando Radegast a través de un enlace WAN (ya es una mala idea para texto plano, pero vamos a depurarlo de todos modos), la fragmentación de MTU puede corromper silenciosamente las cargas útiles de ECM. El síntoma clásico es la decodificación intermitente — algunos canales funcionan, otros no, y parece aleatorio. Ejecutaping -M do -s 1400 remote_server_ip desde el cliente para probar la MTU de la ruta. Si recibes respuestas de fragmentación necesaria, baja tu MTU en el túnel o agrega una regla de clamp.

CGNAT es un problema más difícil. Si la máquina cliente está detrás de un NAT de grado de operador, las conexiones entrantes a esa máquina simplemente no funcionarán — cs357x requiere que el servidor sea accesible. Usa cs378x (el cliente inicia la conexión saliente) o configura un túnel WireGuard que cree una ruta estable y enrutable.

Congelaciones y CW-no-encontrado en canales de alta tasa de bits

Congelar después de unos segundos, especialmente en canales de alta tasa de bits, es casi siempre un problema de latencia. Los períodos de criptografía DVB-S2 duran alrededor de 10 segundos. El cliente necesita recibir un CW fresco antes de que el actual expire. Si tu lector Radegast está en un enlace WAN lento con RTT de 200 ms o más, el viaje de ida y vuelta de ECM puede consumir suficiente de esa ventana para que el CW llegue demasiado tarde.

Los canales UHD son peores — a veces utilizan períodos de criptografía más cortos y una frecuencia de ECM más alta. Un enlace que está bien para SD se congelará en UHD. Mide los tiempos de respuesta de ECM reales en el registro de depuración (el valor de tiempo en la línea de ECM). Cualquier cosa superior a 2-3 segundos es un problema para la mayoría de los canales. Arregla el enrutamiento subyacente antes de culpar al protocolo.

Firmware de orden mixto en receptores más antiguos es un caso límite separado. Algunos firmware de STB más antiguos leen incorrectamente los CW de una fuente Radegast — los bytes llegan invertidos — produciendo una pantalla negra intermitente que se despeja y se vuelve a congelar en un ciclo de aproximadamente 10 segundos. Si ves esto en un receptor específico pero no en otros, el firmware de STB es el sospechoso, no tu configuración de OScam.

Fortalecimiento de seguridad y fiabilidad para Radegast

Esta parte se omite en la mayoría de los escritos, que es parte de por qué Radegast tiene una reputación de ser inherentemente inseguro. No es culpa del protocolo — fue diseñado para una LAN de confianza. El problema son las personas que lo utilizan más allá de ese contexto sin ninguna protección adicional.

Nunca expongas un puerto Radegast en texto plano a internet abierto

Radegast en bruto en una IP pública significa que cualquiera que pueda alcanzar el puerto 8888 puede enviar solicitudes de ECM y recibir CWs. Tu firewallpermitida lista ayuda, pero el spoofing de IP y el secuestro son reales en internet abierto. Más allá del problema de control de acceso, los datos en sí son texto plano en el cable — visibles para cualquiera en el camino entre el cliente y el servidor.

Si tienes el puerto 8888 abierto en las reglas de reenvío de puertos de tu router y vinculado a una IP pública, ciérralo ahora. Usa un túnel en su lugar.

Túnel de Radegast sobre SSH o WireGuard/OpenVPN

El reenvío de puerto local SSH es la solución más rápida si ya tienes acceso SSH al servidor:

ssh -L 8888:127.0.0.1:8888 user@your_server_ip -N

Esto vincula el puerto 8888 localmente en la máquina cliente y lo reenvía a través de la conexión SSH cifrada al localhost:8888 del servidor. Tu lector OScam en el cliente luego apunta a127.0.0.1,8888 en lugar de la IP del servidor. El tráfico de Radegast está cifrado de extremo a extremo y nunca llega a Internet abierto como texto plano. Lalista permitida del servidor debe incluir127.0.0.1 para que esto funcione.

WireGuard es la opción más limpia para una configuración persistente. Una vez que se establece el túnel de WireGuard, el lector de Radegast apunta a la IP interna de WireGuard del servidor (por ejemplo,10.0.0.1,8888), y todo el tráfico transita automáticamente a través del túnel cifrado. No es necesario mantener una sesión SSH. En una Raspberry Pi o caja de bajo consumo similar, WireGuard agrega un mínimo de sobrecarga de CPU en comparación con OpenVPN.

Endurecer la lista de acceso 'permitido' y grupos por lector

Incluso en una LAN, no dejespermitido configurado a un rango amplio a menos que cada dispositivo en ese rango deba tener acceso. Si solo una máquina debe conectarse, pon solo la IP de esa máquina en la lista. OScam registra los intentos de conexión rechazados, por lo que puedes ver si algo inesperado está intentando conectarse.

El sistema de grupos de OScam también es tu amigo aquí. Si las credenciales de un cliente (o IP, para el acceso basado en IP de Radegast) se ven comprometidas, una configuración de grupo bien configurada limita el radio de explosión. Esa conexión comprometida solo puede alcanzar lectores en sus grupos asignados — no tu conjunto completo de tarjetas.

Preferir cs378x cuando un enlace remoto es inevitable

Si absolutamente debes ejecutar un enlace estilo Radegast a través de Internet y un túnel no es una opción, cs378x es la mejor elección sobre cs357x en bruto. La capa de autenticación significa que una IP aleatoria no puede simplemente conectarse y comenzar a extraer CWs — necesitan credenciales válidas. No es cifrado en el sentido fuerte, pero es significativamente mejor que Radegast abierto.

Combina cs378x con unalista permitida que restrinja a la IP estática del cliente, y tendrás una configuración que al menos es defendible para un laboratorio privado en casa.

Obteniendola configuración y el establecimiento del protocolo CCcam radegast correctamente se trata principalmente de entender en qué capa vive un problema: TCP/firewall, enrutamiento de CAID, o el protocolo en sí — y tener las herramientas de depuración adecuadas para diferenciarlos. Las líneas de configuración anteriores son la base de trabajo. Cuando algo falla, el registro de ECM de OScam y un rápido tcpdump te dirán exactamente dónde se rompe la cadena.

Un último caso límite que vale la pena mencionar: si estás haciendo unaconfiguración y establecimiento del protocolo CCcam radegast desde cero y OScam ignora silenciosamente tu[radegast] bloque, siempre verifica primerooscam --show-info. Un binario compilado sinREADER-RADEGAST analizará el archivo de configuración sin error y simplemente no activará el oyente: sin advertencia, sin entrada en el registro, solo un puerto que nunca se abre. Esto atrapa a muchas personas que utilizan paquetes precompilados de repositorios que se compilan con un conjunto mínimo de características.