Servidor CCcam en Linux: Guía completa de instalación y configuración

Configurar un servidor cccam en Linux desde cero es una de esas tareas que parecen sencillas hasta que te encuentras con el primer error de compatibilidad binaria a las 23:00. Esta guía cubre todo el proceso: decisiones de arquitectura, instalación de binarios, sintaxis del archivo de configuración, reglas de firewall y qué hacer cuando algo falla. Si tienes una tarjeta inteligente y un equipo Linux listo, aquí tienes justo lo que necesitas saber.

Qué hace realmente CCcam en Linux (y cuándo necesitas un servidor)

CCcam es un demonio de intercambio de tarjetas. Una máquina lo ejecuta con un lector físico de tarjetas inteligentes conectado: ese es el servidor. Otros dispositivos de la red (o de internet) se conectan y solicitan el descifrado ECM de los canales que intentan ver. El servidor descifra usando la tarjeta física y envía la palabra de control al cliente. Todo esto se realiza a través de TCP, puerto predeterminado 12000.

La arquitectura es importante porque determina tu configuración. Un servidor tiene una tarjeta conectada localmente y expone líneas F para clientes entrantes. Un cliente se conecta salientemente usando líneas C. Mucha gente se confunde porque CCcam se ejecuta en ambos extremos: es el mismo binario, solo que con una configuración diferente.

Modo cliente vs. modo servidor: ¿Qué cambios hay en la configuración?

No hay una bandera de "modo servidor" independiente. La diferencia radica únicamente en las líneas que aparecen en CCcam.cfg . Si tienes líneas F (que definen a los usuarios que se conectan contigo) y una línea DEVICE que apunta a un lector local, eres un servidor. Si solo tienes líneas C (que apuntan a otro host), eres un cliente. También puedes ser ambos simultáneamente: conectarte en sentido ascendente mientras atiendes a clientes en sentido descendente, que es como funcionan las cascadas.

¿Por qué Linux es el sistema operativo host preferido para CCcam?

La fiabilidad es la razón principal. Una máquina Linux que ejecute CCcam como servicio systemd se reiniciará automáticamente tras un fallo y sobrevivirá a los reinicios sin intervención. Windows no cuenta con una infraestructura de daemon equivalente para esto. Además, la mayoría de los receptores de satélite basados en ARM que se utilizan actualmente (Dreambox, VU+, Zgemma) ejecutan Enigma2, que es Linux. Por lo tanto, el binario, los scripts de inicio y las rutas de configuración son los mismos en todas las plataformas.

Requisitos de hardware: CPU, RAM y compatibilidad con lector de tarjetas inteligentes físico

CCcam no consume muchos recursos. Un procesador de 500 MHz y 64 MB de RAM son suficientes para unos pocos clientes. Cualquier sistema Linux moderno está sobrecalificado. La verdadera limitación es el lector de tarjetas inteligentes: se necesita un lector interno (común en el hardware de Dreambox) o un lector USB externo reconocido por el kernel. Las opciones comunes incluyen sc8in1, lectores tipo phoenixrc y lectores USB compatibles con CCID estándar. Ejecute dmesg | grep tty después de conectarlo para confirmar que se ha mostrado; aparecerá como /dev/ttyUSB0 , /dev/ttyACM0 o similar, según el chipset.

Instalación de CCcam en Linux: binario, dependencias y primer arranque

CCcam 2.3.0 es la última versión que circuló ampliamente. Es de código cerrado, nunca se actualiza y sus desarrolladores originales desaparecieron hace tiempo. Lo que se obtiene es un binario estático o semiestático, y en un servidor Debian o Ubuntu moderno de 64 bits, esto genera problemas de inmediato, ya que es un binario ELF de 32 bits.

Cómo elegir el binario CCcam adecuado para su arquitectura

Ejecuta file CCcam en cualquier binario que tengas. Verás algo como ELF 32-bit LSB executable, ARM, EABI5 o ELF 32-bit LSB executable, Intel 80386 . Adapta el binario a tu hardware. Binarios ARM para receptores ARM. Binarios x86 de 32 bits para servidores PC genéricos. Si usas una máquina x86 de 64 bits, necesitas el binario x86 de 32 bits más la capa de compatibilidad, no la compilación ARM, incluso si ARM está disponible.

Instalación de dependencias de bibliotecas de 32 bits en Debian/Ubuntu

En un sistema Debian 11/12 o Ubuntu 22.04 de 64 bits, el entorno de ejecución de 32 bits no se instala por defecto. Primero, solucione este problema:

 dpkg --add-architecture i386 apt-get update apt-get install libc6-i386 lib32gcc-s1

En versiones anteriores de Ubuntu (anteriores a la 20.04), es posible que vea referencias ia32-libs en guías antiguas; ese paquete ya no está disponible. Use libc6-i386 en su lugar. Tras la instalación, verifique con ldd CCcam para comprobar que todas las bibliotecas compartidas se resuelven. Si utiliza un contenedor Docker de solo 64 bits sin compatibilidad con multiarquitectura, omita CCcam por completo y vaya directamente a OScam (descrito en la sección 6).

Colocación del binario y configuración de permisos ejecutables

 cp CCcam /usr/local/bin/CCcam chmod +x /usr/local/bin/CCcam chown root:root /usr/local/bin/CCcam

En las imágenes del receptor Enigma2, el binario suele residir en /usr/bin/CCcam y se inicia mediante un script init.d. No lo mueva en esos sistemas; sus scripts de inicio lo esperan en esa ruta.

Ejecutar CCcam como un servicio systemd para reinicio automático

Cree /etc/systemd/system/cccam.service con este contenido:

 [Unit] Description=CCcam Card Server After=network.target [Service] ExecStartPre=/bin/sleep 10 ExecStart=/usr/local/bin/CCcam Restart=on-failure RestartSec=5 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

El ExecStartPre=/bin/sleep 10 no es opcional si el lector de tarjetas inteligentes necesita un momento para inicializarse después del arranque. Sin él, CCcam se inicia incluso antes de que el kernel termine de configurar el lector USB y registra "no se encontró tarjeta", lo que impide que vuelva a intentarlo correctamente.

 systemctl daemon-reload systemctl enable cccam systemctl start cccam

Verificando que el proceso esté escuchando en el puerto 12000

 ss -tlnp | grep 12000 # or netstat -tlnp | grep CCcam

Debería ver CCcam vinculado a 0.0.0.0:12000 o a una IP de interfaz específica. Si no aparece nada, revise journalctl -u cccam -n 50 para ver si hay errores de inicio.

Análisis profundo de CCcam.cfg: todas las directivas que necesita conocer

El archivo de configuración se encuentra en /etc/CCcam.cfg por defecto. CCcam busca allí primero. Algunos scripts de inicio pasan la ruta como argumento; revisa el tuyo si no se detectan los cambios. Algo que molesta constantemente: los finales de línea de Windows (CRLF) en el archivo de configuración causan errores de análisis silenciosos en Linux. Si editaste este archivo en Windows y lo transferiste, ejecuta dos2unix /etc/CCcam.cfg antes de depurar nada más.

Los comentarios usan # o // ambos funcionan. Las directivas no distinguen entre mayúsculas y minúsculas para la palabra clave, pero los valores (nombres de usuario, contraseñas, nombres de host) sí.

Puerto del servidor y dirección de escucha: Directivas SERVERPORT y BIND

 # Listen for incoming CCcam client connections SERVERPORT: 12000 # Bind to a specific interface (recommended) # BIND: 10.8.0.1

Si tiene varias interfaces de red (por ejemplo, una interfaz WAN y una interfaz VPN), CCcam se vinculará a todas ellas por defecto (0.0.0.0). Esto supone un problema de seguridad. Use la directiva BIND para limitarlo solo a la IP de la interfaz VPN. Encontrará más información en la sección sobre firewall.

Definición de lectores de tarjetas locales: líneas DEVICE, CARDTYPE y BOXKEY

 # Define the physical smartcard reader DEVICE: /dev/ttyUSB0 SR CARDTYPE: 0 BOXKEY: 00 00 00 00 00 00 00 00

La ruta DEVICE debe coincidir con la que muestra dmesg . Si su lector aparece como /dev/ttyACM0 en lugar de /dev/ttyUSB0 , la configuración debe indicar /dev/ttyACM0 . Un error en este parámetro es una de las razones más comunes de errores de "tarjeta no encontrada". CARDTYPE 0 significa detección automática, lo cual funciona para la mayoría de las tarjetas. BOXKEY es relevante para las tarjetas Nagravision que usan una clave de caja; déjela a cero si la suya no la usa.

Adición de clientes de línea C: C: Desglose de sintaxis

Una línea C le indica a este servidor que se conecte a otro servidor CCcam:

 C: remote.host.example 12000 myusername mypassword {0:0:1} 01

Desglosando esto: remote.host.example es el nombre de host o la IP del servidor ascendente. 12000 es el puerto. myusername y mypassword son sus credenciales en ese servidor. {0:0:1} es un filtro CAID opcional con el formato {CAID:ProviderID:1} ; un valor de 0:0:1 significa aceptar todos los CAID. El 01 final es el número de saltos para las tarjetas de recompartición recibidas desde esta línea.

Agregar usuarios de línea F (conexiones entrantes): F: Sintaxis y límites de saltos

Las líneas F definen quién puede conectarse a su servidor:

 F: client1 strongpassword 1 0 0 0 { 1830:000000:1 } F: client2 anotherpass 1 0 0 0 { 0:0:1 }

Los campos después de la contraseña son: nivel de recompartición (1 = se puede recompartir un salto), salto mínimo de tarjeta (0 = tarjetas locales), grupo CAID, grupo de identificación y un bloque de filtro CAID opcional. El filtro { 1830:000000:1 } restringe a este usuario solo al CAID 0x1830. Use contraseñas seguras y únicas para cada línea F: estas son las credenciales que sus clientes ingresan en sus líneas C.

Línea B para bloquear identificaciones de proveedores específicos

 B: 1234 000000

Las líneas B impiden que se comparta una combinación específica de CAID/proveedor. Si tiene una tarjeta con varios proveedores y desea bloquear uno, siga estos pasos: el formato es B: CAID ProviderID .

LÍMITE DE COMPARTICIÓN y CONTEO DE SALTOS: Control de la profundidad de recompartición

El conteo de saltos controla cuántas veces se puede compartir una tarjeta antes de que CCcam deje de pasarla. Se puede configurar en líneas F (por usuario) o globalmente:

 SHARE LIMIT: 3

Un valor de 0 significa que la tarjeta es local y no se compartirá. Un valor de 1 significa que puede dar un salto a los clientes, pero estos no pueden compartirla. Mantenga este valor tan bajo como sea prácticamente necesario, ya que las cadenas de recompartición profundas ralentizan los tiempos de respuesta de ECM y generan problemas de responsabilidad.

Directivas LOG y DEBUG para la resolución de problemas

 LOGFILE: /var/log/cccam.log LOGLEVEL: 1 DEBUG: 0

LOGLEVEL 1 le proporciona eventos de conexión y actividad del ECM sin saturar el disco. Configure DEBUG en 1 temporalmente al investigar un problema específico; es detallado y deberá desactivarlo. La interfaz web en el puerto 16001 (credenciales predeterminadas: admin/admin; cámbielas inmediatamente) muestra el estado de la tarjeta en vivo, los clientes conectados y la sincronización del ECM, lo cual es mucho más fácil de leer que los registros sin procesar durante el diagnóstico.

Cortafuegos, redes y reenvío de puertos para CCcam

Aquí es donde la configuración de un servidor CCCAM en Linux suele bloquearse. El servicio se ejecuta, la configuración parece correcta, pero los clientes no pueden conectarse. En nueve de cada diez casos, se debe a una regla de firewall o a un problema de NAT.

Abriendo el puerto TCP 12000 con iptables y ufw

Usando iptables directamente:

 iptables -A INPUT -p tcp --dport 12000 -j ACCEPT # Save rules so they survive reboot: iptables-save > /etc/iptables/rules.v4

O si estás usando ufw:

 ufw allow 12000/tcp ufw reload

Si desea restringir solo a direcciones IP de clientes conocidos (una práctica mucho mejor):

 iptables -A INPUT -p tcp --dport 12000 -s 203.0.113.45 -j ACCEPT iptables -A INPUT -p tcp --dport 12000 -j DROP

Vincular CCcam a una interfaz específica para evitar la exposición

Si su servidor tiene una interfaz pública (eth0) y una interfaz VPN (wg0 o tun0), no deje que CCcam escuche en ambas. Agregue la directiva BIND en CCcam.cfg con la IP de la interfaz privada/VPN. Los clientes se conectan a través de la VPN y el puerto 12000 nunca está expuesto a la red pública. Esta es la forma correcta de hacerlo.

Usar un túnel VPN (WireGuard/OpenVPN) en lugar de exponer públicamente el puerto 12000

WireGuard es la mejor opción actualmente: menor sobrecarga que OpenVPN, configuración más sencilla y el módulo del kernel se incluye en la línea principal desde Linux 5.6. Configure un par WireGuard entre su servidor y cada cliente, asígneles direcciones en una subred privada (p. ej., 10.8.0.0/24), vincule CCcam a 10.8.0.1 e introduzca esa dirección en las líneas C del lado del cliente. Nadie que explore internet verá jamás el puerto 12000.

NAT y reenvío de puertos si el servidor está detrás de un enrutador doméstico

Si su equipo Linux está en una red doméstica, debe redireccionar el puerto TCP 12000 de su router a la IP local del servidor. La mayoría de los routers lo llaman "redireccionamiento de puertos" o "servidor virtual". Configure el puerto externo en 12000, el protocolo TCP, la IP interna en la dirección LAN de su servidor (estática, ya sea mediante reserva DHCP o configuración manual) y el puerto interno 12000. Los clientes usarán su IP pública en sus líneas C.

Un problema importante: si tu ISP usa CGNAT (NAT de nivel de operador), no tienes una IP pública; la compartes con docenas de clientes y no hay forma de reenviar las conexiones entrantes. La solución es alquilar un VPS económico, ejecutar WireGuard y tunelizar el tráfico de CCcam a través de él. El VPS se convierte en el punto final público; tu servidor local responde a través del túnel.

DNS dinámico para servidores sin IP estática

Si su IP pública cambia, los clientes con su IP anterior en sus líneas C no podrán conectarse. Use un servicio de DNS dinámico e introduzca el nombre de host (p. ej., myserver.ddns.net ) en las líneas C en lugar de una IP simple. Ejecute un cliente de actualización de DDNS como ddclient en su servidor Linux para mantener el registro actualizado. La mayoría de los routers domésticos también lo tienen integrado.

Además: si su ISP bloquea el TCP entrante específicamente en el puerto 12000 (algunos lo hacen), cambie SERVERPORT a algo menos visible como 15000 o 8080, actualice la regla de reenvío de puerto de su enrutador y actualice la línea C de cada cliente para que coincida.

Solución de problemas comunes del servidor CCcam en Linux

La depuración de una configuración de servidor cccam en Linux sigue un patrón bastante consistente: eliminar capas una a la vez, comenzando desde abajo (¿se está ejecutando el proceso?), pasando por la red, luego la configuración y luego la detección de la tarjeta.

CCcam se inicia pero los clientes no pueden conectarse: lista de verificación

• Confirme que el proceso realmente se está ejecutando: systemctl status cccam
• Confirme que está escuchando: ss -tlnp | grep 12000
• Pruebe localmente primero: telnet 127.0.0.1 12000 — si esto falla, el problema es el servicio, no la red
• Comprobar el firewall: iptables -L -n | grep 12000
• Verifique la línea F: el nombre de usuario y la contraseña deben coincidir exactamente con los que el cliente usa en su línea C
• Confirme que la dirección IP/nombre de host de la línea C del cliente se resuelva correctamente desde la máquina cliente

'No se encontró tarjeta' o Tarjeta no detectada después de la definición del lector

Comience con dmesg | tail -30 justo después de conectar el lector. Debería ver una línea sobre un nuevo dispositivo USB y el nodo de dispositivo al que se le asignó. Si no la ve, el lector no se reconoce a nivel de kernel; podría deberse a un problema del controlador o de hardware.

Si el lector aparece, pero no se detecta la tarjeta, verifique que la línea DEVICE en CCcam.cfg apunte a la ruta exacta que se muestra en dmesg. Recuerde: /dev/ttyACM0 y /dev/ttyUSB0 son dispositivos diferentes, y el dispositivo incorrecto fallará silenciosamente. Compruebe también que el usuario del proceso CCcam tenga permisos de lectura y escritura en el dispositivo: ls -l /dev/ttyUSB0 y, si es necesario, añada el usuario CCcam al grupo dialout .

Respuestas ECM incorrectas y fallos de decodificación (desajuste de CAID)

El cliente se conecta; lo ves en la interfaz web de CCcam en el puerto 16001, pero el canal no se descifra. Casi siempre hay una discrepancia de CAID. Abre la interfaz web y comprueba qué CAID anuncia el servidor. Luego, comprueba qué CAID usa el canal; la pantalla de información del canal de tu decodificador o un menú de CAM lo mostrarán. Si no coinciden, el servidor no puede ayudar a ese cliente, independientemente del estado de la conexión.

También verifique el número de saltos. Si la línea F de ese cliente tiene un valor de recompartición de 0 y la tarjeta se recibió de una línea C ascendente (no local), el cliente no recibe nada. Un número de saltos de 0 bloquea la recompartición de tarjetas no locales.

Carga alta/Tiempos de respuesta del ECM lentos

Una sola tarjeta física solo puede procesar un ECM a la vez. Si tiene 10 clientes solicitando descifrado simultáneamente, se ponen en cola y los tiempos de respuesta aumentan. El canal puede fallar o quedar inactivo momentáneamente. La solución consiste en menos clientes, tarjetas físicas adicionales o líneas C ascendentes adicionales con diferentes tarjetas. No existe una solución de software para esto; es una limitación de hardware.

Ubicación del archivo de registro y cómo leer la salida de depuración de CCcam

Si LOGFILE está definido en CCcam.cfg, los registros se almacenan allí. De lo contrario, al ejecutarse en systemd, use journalctl -u cccam -f para obtener un resumen en tiempo real. Busque líneas que contengan "connected", "ECM", "card" y códigos de error. Una respuesta ECM "0x00" generalmente significa que la tarjeta respondió correctamente. Errores como "N/A" o mensajes de tiempo de espera indican problemas con la tarjeta.

CCcam se bloquea al iniciarse: solución a la incompatibilidad binaria

Ejecute primero file CCcam . Luego, ejecute ldd CCcam . Si ve el mensaje "no es un ejecutable dinámico", el binario está enlazado estáticamente y debería ejecutarse. Si ve bibliotecas sin resolver ("no encontradas"), instale los paquetes de 32 bits que faltan. Si CCcam se cierra inmediatamente con el mensaje "Error de formato de ejecución", la arquitectura es completamente incompatible (por ejemplo, un binario ARM en x86). Obtenga el binario adecuado para su plataforma.

CCcam vs OScam como servidor Linux: ¿Cuándo cambiar?

Si empiezas desde cero hoy, considera seriamente usar OScam. CCcam 2.3.0 es software abandonado: sin parches, actualizaciones ni código fuente que auditar. OScam se mantiene activamente, es de código abierto (GPL) y ofrece una gran variedad de funciones. La única razón para seguir usando CCcam es si necesitas específicamente compatibilidad con el cliente CCcam en dispositivos antiguos que no son compatibles con el protocolo nativo de OScam; incluso en ese caso, OScam lo gestiona.

Diferencias clave en la arquitectura

CCcam es una caja negra. Se toma el binario, se configura y se espera que funcione; no hay forma de inspeccionar ni modificar los componentes internos. OScam es completamente de código abierto, se actualiza constantemente para nuevos tipos de tarjetas y problemas de seguridad, y cuenta con un modelo de configuración mucho más completo, con filtrado por lector y por usuario con una granularidad que CCcam no puede igualar. La interfaz web de OScam también es considerablemente mejor que la página básica del puerto 16001 de CCcam.

Filtrado superior de CAID e ID de proveedor de OScam

En OScam, puede filtrar por CAID, ID de proveedor, ID de servicio e incluso por PID de ECM específicos, todo de forma independiente por lector, usuario y perfil. En comparación, el filtrado de CCcam es burdo. Si utiliza una tarjeta con varios paquetes de proveedor y necesita un control preciso sobre el acceso de cada cliente, OScam es la herramienta ideal.

Ejecución de OScam como servidor de protocolo CCcam (escuchas cs378x/cs357x)

OScam puede hablar el protocolo CCcam de forma nativa. Esto significa que sus clientes CCcam actuales no necesitan cambiar sus líneas C en absoluto: OScam responde en el puerto 12000 y nunca notan la diferencia.

En /etc/oscam/oscam.conf , agregue un bloque de escucha:

 [cs378x] port = 12000 key = 0102030405060708091011121314151617181920

El módulo cs378x gestiona las conexiones del protocolo CCcam versión 2.x. Utilice cs357x para variantes anteriores del protocolo CCcam. Los usuarios se definen en /etc/oscam/oscam.user con protocol = cccam .

Ruta de migración: conversión de CCcam.cfg a archivos de configuración de OScam

Las líneas C de CCcam se convierten en entradas de lector en /etc/oscam/oscam.server :

 [reader] label = upstream1 protocol = cccam device = remote.host.example,12000 user = myusername password = mypassword caid = 1830 ident = 1830:000000

Las líneas F de CCcam se convierten en entradas de usuario en /etc/oscam/oscam.user :

 [account] user = client1 pwd = strongpassword protocol = cccam group = 1 caid = 1830

La conversión es mecánica, pero requiere ir línea por línea. No existe una herramienta automática que gestione todos los casos excepcionales de forma fiable. Tómese una hora y hágalo manualmente; vale la pena por el mantenimiento a largo plazo de una configuración correcta de OScam en lugar de una instalación tradicional de servidor CCCAM en Linux.