Tutorial de configuración del servidor CCcam: guía paso a paso

Configurar CCcam correctamente es más difícil de lo que parece. El software se inicia sin errores, los archivos de registro parecen inactivos y, de repente, nada funciona. Los canales no se descifran, los clientes no pueden conectarse o todo funciona durante 20 minutos antes de fallar. Esta guía cubre la configuración completa, desde la estructura del archivo ccccam.cfg hasta la verificación del lado del cliente, incluyendo los modos de fallo que la mayoría de los tutoriales nunca mencionan.

¿Qué es CCcam y cómo funciona el modelo cliente-servidor?

Descripción general del protocolo CCcam

CCcam es un protocolo de intercambio de tarjetas y una aplicación de softcam. Se comunica con un lector físico de tarjetas inteligentes para obtener las palabras de control (CW), las claves de descifrado que los receptores de satélite necesitan para decodificar canales de televisión codificados. El protocolo gestiona las solicitudes ECM (Mensaje de Control de Titularidad) entre el receptor y la tarjeta, enviando las respuestas descifradas casi en tiempo real.

El protocolo se adoptó ampliamente gracias a su integración fluida con los receptores de satélite basados en Enigma2 y a su posibilidad de ejecutarse como servicio en segundo plano en Linux. Una instancia de CCcam funcional necesita dos cosas: una tarjeta inteligente válida con una suscripción activa y un lector de tarjetas con el que el software pueda comunicarse.

Explicación de los roles de servidor y cliente

Comprender cuál rol desempeña determina todo su enfoque de configuración.

Modo servidor: Tiene una tarjeta inteligente física y un lector de tarjetas. CCcam lee la tarjeta directamente, gestiona las solicitudes ECM localmente y puede compartir respuestas con las cuentas de cliente autorizadas que usted defina. Su ccccam.cfg tendrá líneas B o R que apuntan al hardware de su lector de tarjetas y líneas F que definen quién puede conectarse con usted.

Modo cliente: No tienes tarjeta local. Te conectas al servidor CCcam de otra persona mediante una línea C que esta proporciona. Tu receptor envía solicitudes ECM a su servidor y su tarjeta las procesa. Te autenticas con un nombre de usuario y contraseña. En este modo, tu configuración tiene líneas C, pero no líneas B ni configuración de tarjeta local.

Muchas configuraciones combinan ambas funciones: actúan como cliente de un servidor ascendente y, al mismo tiempo, atienden a clientes locales. Esto se denomina conexión en cascada, y el número de saltos controla la distancia que puede recorrer el intercambio de una tarjeta.

Plataformas de hardware y sistemas operativos compatibles

CCcam funciona en varias plataformas, cada una con requisitos de configuración ligeramente diferentes:

• Receptores de satélite Enigma2 (DreamBox, Vu+, Zgemma, Gigablue): la implementación más común. CCcam se instala como un paquete ipk o deb.
• Servidor VPS o dedicado Linux , generalmente Ubuntu o Debian x86/x64. Requiere un lector de tarjetas inteligentes USB si se ejecuta en modo servidor. Ideal para implementaciones de servidores centrales.
• Raspberry Pi : funciona correctamente con un lector USB. Requiere configurar reglas udev para permitir que CCcam acceda a /dev/ttyUSB0 o rutas de dispositivo similares. Sin la regla udev correcta, el servicio se inicia, pero no logra abrir el lector.
• Windows : no compatible de forma nativa. Requiere una máquina virtual Linux o WSL. No se recomienda para producción.

Consideraciones legales para uso personal

El software CCcam es en sí mismo una herramienta. Usarlo para que tu receptor acceda a una tarjeta inteligente que posees y para la que tienes una suscripción válida es un proceso de configuración técnica. Compartir el acceso a una misma tarjeta de suscripción entre varios usuarios no relacionados o recibir acceso compartido para una suscripción no pagada genera problemas legales y de condiciones de servicio.

Esta guía explica la mecánica de configuración. Nada de lo aquí expuesto pretende facilitar la distribución no autorizada del acceso a la suscripción. Verifique los términos de su proveedor de suscripción antes de compartir el acceso a la tarjeta de cualquier forma, incluso dentro de un mismo hogar.

Configuración del servidor CCcam: explicación del archivo ccccam.cfg

Cómo localizar la ruta del archivo de configuración

En los receptores Enigma2, el archivo se encuentra en /etc/CCcam.cfg . En un VPS Linux que ejecuta CCcam como servicio, suele estar en /usr/local/etc/CCcam.cfg o donde indique el script de inicio con el parámetro -c . Si tiene dudas, revise el script de inicio o el archivo de unidad systemd.

Un caso extremo crítico: si editó el archivo de configuración en una máquina Windows y lo transfirió por FTP, es casi seguro que tenga terminaciones de línea CRLF similares a las de Windows. El analizador de Linux de CCcam se bloquea silenciosamente con estas terminaciones: las líneas se leen incorrectamente y las directivas se ignoran. Siempre ejecute dos2unix /etc/CCcam.cfg después de cualquier edición en Windows antes de reiniciar CCcam.

Directivas esenciales: Línea C, Línea F, Línea N, Línea R

A continuación se muestra un ejemplo anotado que muestra los tipos de directivas principales:

# Conectarse al servidor ascendente (línea C)
# Formato: C: nombre de host puerto nombre de usuario contraseña
C: upstream.example.com 12000 miusuariocliente micontraseña
# Define un usuario local que pueda conectarse a ESTE servidor (línea F)
# Formato: F: nombre de usuario contraseña compartir maxhops [IDENT:SID ...]
F: cliente local1 contraseña secreta 1 1
# Conexión de cliente Newcamd (línea N)
# Formato: N: nombre de host puerto nombre de usuario contraseña clave DES
N: newcamd.example.com 15050 usuario n contraseña 0102030405060708091011121314
# Lector de tarjetas local (línea B para integrado, línea R para phoenix/smartreader)
B: /dev/sci0
# Lector USB Phoenix/serie
R: /dev/ttyUSB0 lector inteligente

Una línea F mal formada es uno de los modos de fallo silencioso más comunes. Si el formato es incorrecto (espacio extra, campo faltante, tabulación en lugar de espacio), CCcam lo lee sin errores, pero la cuenta de usuario simplemente no existe. Los clientes sufren errores de autenticación y no hay nada en el registro que explique el motivo. Siempre revise el formato de la línea F carácter por carácter.

Configuración del puerto de escucha y el nombre de host

Establezca el puerto en el que escucha CCcam con:

PUERTO DE SERVIDOR 12000

El puerto predeterminado es 12000. Si su ISP bloquea este puerto (algunos lo hacen, sobre todo en conexiones residenciales), cambie a algo como 8080 o incluso 443. Cualquier cambio aquí requiere actualizar cada línea C del cliente que apunte a este servidor y abrir el nuevo puerto en su firewall. No deje este puerto predeterminado en un VPS público sin control de acceso basado en IP; el puerto 12000 se escanea constantemente.

Definición de cuentas de usuario (líneas F) con saltos y compartición

El valor de recompartir de la línea F controla lo que un cliente conectado puede hacer con las tarjetas que recibe:

• Recompartir 0 : el cliente no puede compartir. Solo puede descifrar canales para sí mismo. Úselo para clientes finales.
• Recompartir 1 : el cliente puede compartir a un nivel adicional. Úselo para operadores de subservidores de confianza.
• Recompartir 2+ : el cliente vuelve a compartir en etapas posteriores de la cadena. Aumenta la latencia. Evítelo a menos que necesite específicamente la conexión en cascada multinivel.

# Usuario final: sin compartir, máximo 1 salto
F: espectador1 pase123 0 1
# Operador de subservidor: puede volver a compartir un nivel
F: subservidor1 pass456 1 2

Agregar tarjetas inteligentes locales (líneas B y líneas R)

Las líneas B hacen referencia a los lectores de tarjetas integrados en el hardware Enigma2. Las líneas R gestionan los lectores externos. Para una Raspberry Pi con un lector de tarjetas inteligentes USB:

R: /dev/ttyUSB0 lector inteligente

La ruta del dispositivo debe ser legible para el usuario que ejecuta CCcam. En una Pi, agregue una regla udev para otorgar acceso:

# /etc/udev/rules.d/99-smartcard.rules
SUBSISTEMA=="tty", ATTRS{idVendor}=="0403", MODO="0666", GRUPO="usuarios"

Reemplace el valor idVendor con el ID de proveedor real de lsusb . Recargue con udevadm control --reload-rules . Sin este paso, CCcam se inicia correctamente, pero el lector de tarjetas no se abre; no verá ninguna tarjeta en el panel de información de CCcam.

Importante: CCcam no puede interactuar con un Módulo de Acceso Condicional (CAM) insertado en la ranura CI de su receptor. Requiere una conexión directa a un lector de tarjetas inteligentes. Si utiliza un CAM, CCcam no es la herramienta adecuada para el acceso local a tarjetas.

Cascada y conteo de saltos: ¿Qué valores utilizar?

MAXHOPS limita la cantidad de saltos de red que puede recorrer una solicitud ECM. Para una configuración doméstica sencilla (un servidor y dos o tres receptores locales), configure:

MAXHOPS 1

Cada salto adicional añade latencia. Con más de 3 saltos, notará un cambio de canal lento: a veces de 3 a 5 segundos por cambio de canal en lugar de menos de 1 segundo. Aumente MAXHOPS solo cuando ejecute deliberadamente una red multicapa donde los subservidores necesiten una mayor conexión en cascada.

Guardar y aplicar cambios de configuración

CCcam no recarga su configuración en caliente. Después de editar ccccam.cfg , debe reiniciar el servicio por completo:

systemctl reiniciar cccam
# o en Enigma2:
/etc/init.d/softcam reiniciar

Siempre haga una copia de seguridad de la configuración funcional antes de realizar cambios. Un solo error de sintaxis puede provocar la caída de todo el servicio.

Configuración del lado del cliente: Conexión a su servidor CCcam

Configuración de la línea C en un receptor Enigma2

En un receptor Enigma2 que actúa puramente como cliente, su CCcam.cfg solo necesita la línea C que apunta a su servidor:

C: 192.168.1.100 12000 espectador1 pase123

Utilice la dirección IP de la LAN del servidor siempre que sea posible en lugar de un nombre de host. La resolución DNS añade un punto de fallo: si el DNS es lento o no está disponible temporalmente, la línea C se cae y los canales dejan de descifrarse de forma intermitente. Esta es una causa común de quejas del tipo "funciona bien y luego se cae durante 30 segundos". Es preferible una IP estática o una entrada DNS local fiable.

Configuración de CCcam en imágenes OpenPLi, OpenATV y DreamOS

El proceso es consistente en las imágenes populares de Enigma2, pero el administrador de paquetes difiere ligeramente:

• OpenPLi / OpenATV: Instale CCcam mediante el Administrador de Software o copiando el archivo ipk al receptor y ejecutando opkg install CCcam*.ipk . El archivo de configuración se encuentra en /etc/CCcam.cfg .
• DreamOS (nativo de DreamBox): utilice el DreamBox App Market o cargue el paquete deb con apt install .

Tras la instalación, el archivo de configuración suele estar vacío o solo contiene comentarios. Agregue su línea C y reinicie la softcam.

Uso de CCcam con un complemento de Softcam Manager

La mayoría de las imágenes de Enigma2 incluyen un administrador de Softcam, accesible desde el menú principal. Este permite iniciar, detener y cambiar de softcam sin acceso SSH. CCcam debería aparecer en la lista tras la instalación. Selecciónelo e inícielo; el administrador gestiona el script de inicio. Si CCcam no aparece, el paquete no se instaló correctamente o el binario no es ejecutable.

Prueba de la conexión con el panel de información de CCcam

El complemento CCcam Info (disponible como un paquete independiente llamado enigma2-plugin-extensions-cccaminfo ) muestra el estado del servidor en tiempo real. Tras instalarlo y abrirlo:

• Las tarjetas conectadas de su línea C deberían aparecer en "Servidores conectados".
• Las solicitudes de ECM activas muestran que el descifrado del canal está funcionando
• La sección "Acciones" muestra qué tarjetas puede ver tu servidor

Si no hay servidores conectados, significa que la línea C es incorrecta o que el servidor no está disponible. Si aparecen tarjetas pero no hay actividad ECM, significa que la tarjeta no cubre los canales que estás viendo. Esta distinción es importante para la resolución de problemas.

Interpretación de los colores y códigos del estado de la conexión

En el panel de información de CCcam, los indicadores de estado significan:

• Verde: Conectado y compartiendo activamente: las respuestas de ECM están funcionando
• Amarillo: conectado pero inactivo: el servidor es accesible pero no hay solicitudes de descifrado activas
• Rojo: La conexión falló o se perdió: verifique las credenciales de la línea C, la accesibilidad del servidor y el firewall

El amarillo es normal cuando no se ve un canal codificado. Si el rojo no se recupera tras reiniciar el servicio, indica un problema de red o autenticación, no un problema del archivo de configuración del cliente.

Solución de errores comunes del servidor CCcam

El servidor no se inicia: errores de permisos y rutas

Si CCcam se cierra inmediatamente después de iniciarse, primero verifique dos cosas. Una: el binario debe ser ejecutable ( chmod +x /usr/local/bin/CCcam ). Dos: la ruta del archivo de configuración en el comando de inicio debe coincidir con la ubicación real del archivo. Si CCcam no tiene una configuración, no le avisará claramente; simplemente se cerrará.

Ejecute CCcam manualmente en primer plano para ver la salida sin procesar: /usr/local/bin/CCcam -c /etc/CCcam.cfg . Cualquier error de inicio se imprime directamente en la terminal.

Los clientes pueden conectarse pero los canales no se descifran

Este es el modo de fallo que la mayoría de los tutoriales omiten por completo. El cliente se autentica, la información de CCcam se muestra en verde, pero los canales permanecen en negro o muestran un error de descifrado. Posibles causas:

• La tarjeta en el servidor no tiene el paquete de suscripción para el canal solicitado
• El recuento de saltos en la línea F se establece en 0, lo que significa que la tarjeta no se comparte en absoluto.
• La conexión del lector de tarjetas está rota: CCcam muestra que la tarjeta estaba presente al inicio, pero desde entonces se desconectó.
• El LÍMITE DE COMPARTICIÓN está configurado demasiado bajo en la configuración, lo que limita las respuestas de ECM

Revise /tmp/cccam.log para ver si hay líneas que contengan "can't decode" o "no provider" en el CAID/ID del canal. Una decodificación funcional muestra el tiempo de respuesta del ECM en milisegundos. Si no hay respuesta del ECM, significa que la tarjeta nunca procesó la solicitud.

Correcciones de tiempo de espera de ECM y tiempos de zapping elevados

Un cambio de canal que tarda más de 3 segundos suele deberse a una de las siguientes razones: demasiados saltos que aumentan el tiempo de ida y vuelta, congestión de la red entre el cliente y el servidor, o lentitud de respuesta de la tarjeta (algo común en algunos sistemas de acceso condicional). Comience por reducir MAXHOPS a 1 y realice pruebas locales antes de culpar a la tarjeta.

Demasiadas conexiones / Máximo de usuarios alcanzado

Si se rechazan clientes con un error de límite de conexión, verifique su línea F: puede especificar el máximo de conexiones por usuario:

# Formato: F: contraseña de usuario recompartir saltos maxcon
F: espectador1 pase123 0 1 1

El último parámetro limita a ese usuario a una conexión simultánea. Elimínelo o auméntelo si se bloquean conexiones legítimas.

CCcam se bloquea después de unas horas

Las versiones anteriores de CCcam (2.1.x y anteriores) presentan una fuga de memoria bien documentada. El proceso crece durante horas hasta que el sistema OOM-killer lo finaliza. Dos soluciones: actualizar a CCcam 2.3.x, que ofrece una mejor gestión de memoria, y configurar un servicio systemd con Restart=always para que se recupere automáticamente. El fallo en sí puede ser inevitable en versiones muy antiguas, pero el servicio debería recuperarse en segundos.

Puerto bloqueado por firewall: reglas de UFW e iptables

En un VPS que ejecuta UFW:

ufw permite 12000/tcp
recarga de ufw

Con iptables directamente:

iptables -A ENTRADA -p tcp --dport 12000 -j ACEPTAR
# Guardar reglas:
iptables-save > /etc/iptables/rules.v4

Si usa un alojamiento compartido donde el proveedor administra el firewall, no puede abrir los puertos usted mismo; contacte con su soporte. Si su ISP bloquea el puerto 12000 en conexiones residenciales, cambie SERVERPORT a 8080 o 443 y actualice todas las líneas C del cliente según corresponda. Los usuarios con CGNAT (NAT de nivel de operador) se enfrentan a un problema más complejo: el reenvío de puertos estándar a su router no funciona porque no tienen una IP pública dedicada. La solución es un túnel VPN o un proxy inverso en un VPS: el VPS tiene el puerto público y canaliza el tráfico al servidor CCcam doméstico.

Errores de sintaxis del archivo de configuración: cómo validarlos

CCcam no tiene un validador de configuración incorporado, pero un grep rápido detecta problemas de formato comunes:

# Comprobar los finales de línea de Windows
gato -A /etc/CCcam.cfg | grep '\^M'
# Enumere todas las líneas F para verificar el formato
grep '^F:' /etc/CCcam.cfg
# Verifique si hay líneas en blanco a mitad de la configuración que puedan interrumpir el análisis
grep -n '^$' /etc/CCcam.cfg

Si cat -A muestra ^M al final de línea, ejecute dos2unix /etc/CCcam.cfg inmediatamente.

Optimización del rendimiento y la seguridad del servidor CCcam

Cómo elegir la versión correcta de CCcam (2.3.x vs 2.1.x)

CCcam 2.3.x es la última versión estable y presenta mejoras significativas respecto a la 2.1.x: mejor gestión de memoria, mejor gestión multitarjeta y una recuperación de conexión ascendente más fiable. No hay desarrollo activo más allá de la 2.3.x. Si está configurando desde cero, use la 2.3.x. Si utiliza la 2.1.x y experimenta fallos, el primer paso es actualizar, no reconfigurar.

Tras la actualización, elimine por completo el binario antiguo antes de instalar el nuevo. Ejecutar dos binarios de CCcam simultáneamente provoca un conflicto de puertos: la segunda instancia no puede enlazar con el puerto 12000 y se cierra automáticamente, dejándolo depurando una nueva versión defectuosa que funcionaba correctamente.

Ejecutar CCcam como un servicio Systemd para reinicio automático

Crear /etc/systemd/system/cccam.service :

[Unidad]
Descripción=Servidor para compartir tarjetas CCcam
Después de=red.objetivo
[Servicio]
Tipo=simple
ExecStart=/usr/local/bin/CCcam -c /etc/CCcam.cfg
Reiniciar=siempre
ReinicioSec=5
Usuario=cccam
Salida estándar=diario
StandardError=diario
[Instalar]
WantedBy=multi-usuario.objetivo

Habilitar e iniciar:

recarga del demonio systemctl
systemctl habilitar cccam
systemctl iniciar cccam

La directiva Restart=always significa que CCcam se recupera automáticamente de fallos en 5 segundos. Esta es la mayor mejora de fiabilidad que se puede implementar en un servidor de producción; los tutoriales de la competencia rara vez la mencionan.

Limitación del ancho de banda del usuario y de las conexiones simultáneas

En ccccam.cfg , establezca límites de conexión por usuario en la línea F (como se muestra en la sección de solución de problemas) y utilice el LÍMITE DE COMPARTICIÓN para controlar el rendimiento general. No establezca el LÍMITE DE COMPARTICIÓN por debajo del número de canales simultáneos que sus clientes necesitan legítimamente, ya que esto provoca caídas de ECM que parecen problemas de tarjeta.

Bloqueo de rangos de IP no autorizados

CCcam admite las directivas ALLOW y DENY para el control de acceso basado en IP:

# Permitir únicamente conexiones desde su red local y una IP confiable
PERMITIR 192.168.1.0/24
PERMITIR 203.0.113.45
NEGAR 0.0.0.0/0

Las reglas DENY después de ALLOW crean una lista de permitidos. Sin esto, cualquiera que obtenga credenciales válidas puede conectarse desde cualquier lugar. En un VPS público, la restricción basada en IP es esencial: el puerto 12000 se escanea activamente.

Monitoreo de la carga del servidor con archivos de registro de CCcam

CCcam escribe en /tmp/cccam.log por defecto. En un servidor con mucha actividad, este archivo crece rápidamente. Añadir rotación de registros:

# /etc/logrotate.d/cccam
/tmp/cccam.log { a diario rotar 7 comprimir missingok notifempty postrotación systemctl reiniciar cccam final del guión
}

Sin rotación, un servidor que funciona durante semanas llenará /tmp y provocará que CCcam falle cuando no pueda escribir entradas de registro.

Prácticas recomendadas para la configuración de copias de seguridad y restauración

Antes de realizar cualquier cambio, copia la configuración funcional: cp /etc/CCcam.cfg /etc/CCcam.cfg.backup.$(date +%Y%m%d) . Mantén copias de seguridad versionadas durante al menos 7 días. Si administras varios receptores, guarda las configuraciones en un repositorio Git; así podrás comparar los cambios e identificar exactamente qué falló.

Lo que no funciona: Errores a evitar en la configuración de CCcam

Formato de línea incorrecto que provoca fallos silenciosos

Una línea F incorrecta no produce ningún error. El usuario simplemente no existe. Los clientes que se conectan con esas credenciales son rechazados, y el registro muestra un error de autenticación sin indicar que la cuenta nunca se creó. Cada línea F necesita exactamente estos elementos en orden: F: prefijo, espacio, nombre de usuario, espacio, contraseña, espacio, valor de recompartición, espacio, valor de saltos máximos. Los espacios adicionales, las tabulaciones o los valores faltantes provocan un rechazo silencioso.

Uso de CCcam en NAT sin reenvío de puertos

Si su servidor CCcam está conectado a un router doméstico, los clientes externos a su red no podrán acceder a él a menos que redireccione el puerto del servidor desde el router al equipo que ejecuta CCcam. Acceda al panel de administración de su router y cree una regla de redireccionamiento de puertos: puerto externo 12000, IP interna de su equipo CCcam, puerto interno 12000. Los clientes se conectarán usando la IP pública de la WAN de su router, no la IP de la LAN.

Los usuarios de CGNAT no reciben ninguna IP pública; el reenvío de puertos no tiene adónde apuntar. La solución alternativa es usar un VPS económico como relé. Se utiliza WireGuard entre el VPS y el servidor doméstico, y luego los clientes se conectan al VPS. Esto añade una latencia de 20 a 40 ms, pero resuelve por completo el problema de CGNAT.

Mezcla de archivos de configuración de CCcam y OSCam

OSCam utiliza archivos de configuración y una sintaxis de directivas completamente diferentes. CCcam usa CCcam.cfg con prefijos de línea C:/F:/B:. OSCam usa oscam.conf , oscam.server y oscam.user , cada uno con encabezados de sección de estilo INI. Pegar bloques de configuración de OSCam en un archivo de configuración de CCcam, o viceversa, inutiliza ambos. Si está migrando de OSCam a CCcam, comience con un archivo de configuración limpio; no intente adaptar el existente.

Valores de salto incorrectos que rompen la cadena de compartición

Configurar MAXHOPS a 0 significa que no se comparte nada; solo se realiza el descifrado local. Un servidor con MAXHOPS a 0 acepta conexiones de clientes, pero no las envía. Configurarlo a 1 significa que las tarjetas se comparten en un nivel de profundidad. Si tiene una configuración de tres niveles (upstream → su servidor → sus clientes → sus clientes) y desea que toda la cadena funcione, necesita MAXHOPS a 3. Cada nivel con un número de saltos demasiado bajo trunca silenciosamente la cadena de compartición inferior.

Ejecutar CCcam y OSCam simultáneamente en el mismo puerto

Algunos usuarios intentan ejecutar ambas softcams para mayor flexibilidad de protocolo. En el mismo receptor Enigma2 con un lector de tarjetas, ambas softcams compiten por la tarjeta física. La que primero consiga el lector gana; la otra falla silenciosamente o produce errores esporádicos. En una máquina con un solo lector de tarjetas, ejecute una softcam a la vez. Si necesita ambos protocolos, ejecute CCcam en un puerto y OSCam en otro, pero asegúrese de que solo una acceda directamente al lector de tarjetas físico. La otra debe funcionar solo como cliente.