❓ Preguntas Frecuentes

ECM (Entitlement Control Message) es el mensaje cifrado que el canal DVB emite cada 10-15 segundos con la "pregunta" que el sistema CAS debe resolver para obtener la clave de descifrado de imagen.

CW (Control Word) es la clave de 16 bytes que descifra la imagen. Es la respuesta al ECM. Sin ella el decodificador muestra pantalla negra.

Candela intercepta los ECMs via DVBAPI, los envía a la fuente de decodificacion configurada (red P2P, tarjeta local o SoftCam.Key) y devuelve el CW al decodificador antes de que expire.

CAID identifica el sistema CAS del canal. Ejemplos comúnes:

• 1810 / 1830 = Nagravision
• 0500 = Viaccess
• 0100 = Seca/Mediaguard
• 0900 = NDS/Videoguard
• 0604 = Irdeto

PROVID identifica al proveedor dentro del sistema CAS. Por ejemplo, dentro de Viaccess (0500) el PROVID 004101 corresponde a Movistar Espana.

NewCamd y MGcamd tienen soporte desde R40: Candela puede actuar como servidor NewCamd/MGcamd (aceptar conexiónes de NCam, OSCam u otros clientes) y también como cliente (conectarse a servidores NewCamd/MGcamd externos para resolver ECMs).

CCcam, Camd3 y el resto de protocolos legacy no están soportados ni están previstos.

El motor de resolución ECM sigue una cadena de prioridad configurable:

1. Cache RAM (respuesta inmediata si el CW ya fue resuelto recientemente)
2. SoftCam.Key (emulador de llaves estaticas para BISS, Viaccess, etc.)
3. Lector físico local (tarjeta ISO-7816 conectada al dispositivo)
4. Lectores NewCamd / MGcamd externos (si hay newcamd_readers o mgcamd_readers configurados)
5. Red P2P Candela (peers configurados, selecciónados por NRS)

El orden exacto se controla con el parámetro preferlocalcards en candela.json.

Es un archivo de texto (config/SoftCam.Key) con llaves estaticas para sistemas que no requieren tarjeta: BISS, Viaccess estático, PowerVU, Nagravision estático, Irdeto, DRE Crypt y SECA/Abertis.

Cada línea sigue el formato TIPO PROVID 00 CLAVE_HEX. Por ejemplo para BISS: F CCCCSSSS 00 AABBCCDDEEFF0011.

Puedes editar el archivo directamente o usar el editor íntegrado en el WebIF.

{
  "port": 15000,
  "web_port": 8080,
  "http_user": "admin",
  "http_pwd": "TU_PASSWORD_AQUI",
  "enable_dvbapi": 1,
  "dvbapi_listen_socket": "/tmp/camd.socket",
  "servers": [
    {
      "ip": "peer.ejemplo.com",
      "port": 15000,
      "user": "tu_usuario",
      "pass": "tu_pass"
    }
  ]
}

• 1 = Local primero, luego cache, luego red (por defecto)
• 2 = Cache primero, luego local, luego red
• 3 = Consulta simultánea a local y red, gana quien responda primero

Para Instalaciónes con tarjeta local de alta calidad usa 1. Para Instalaciónes que priorizan la velocidad de cache usa 2. El modo 3 reduce la latencia máxima a costa de más trafico de red.

Segundos adicionales que Candela sirve un CW cacheado si el peer que lo origino se ha desconectado. Permite aguantar desconexiónes breves sin pantalla negra.

Valor recomendado: 30 para canales con período ECM de 10 s, 15 para canales con período de 5 s.

• Enigma2: cualquier STB que use la libreria libdvbcsa y el socket DVBAPI (/tmp/camd.socket)
• Linux x86_64: servidores, PCs, VMs
• Linux ARMv7: Raspberry Pi, STBs ARM de gama media
• Linux ARM64: STBs modernos, SBCs arm64
• Linux MIPSEL: routers con OpenWrt, decos legacy
• Android arm64-v8a: compilado con NDK
• Windows: compilado con MSYS2 / MinGW64

Si. Candela soporta hasta 8 demux simultáneos por instancia. Cada demux puede pedir ECMs de diferentes canales de forma completamente independiente.

No hay configuración adicional necesaria: Candela detecta automáticamente las peticiónes multi-demux del cliente DVBAPI.

Si. TVheadend utiliza el protocolo DVBAPI en modo TCP en lugar del socket Unix. Para conectar Candela con TVheadend:

1. En TVheadend: Configuración → DVB Inputs → CA → External CA (DVBAPI)
2. Protocolo: TCP, Host: 127.0.0.1, Puerto: 9000 (o el que tengas en dvbapi_port)
3. En candela.json: asegúrate de tener "enable_dvbapi": 1 y "dvbapi_mode": "tcp"

Si. Desde R40 Candela puede actuar como servidor NewCamd: acepta conexiónes de NCam, OSCam, CCcam (en modo newcamd) u otros clientes que soporten el protocolo NewCamd.

Configura la sección newcamd_servers en candela.json:

"newcamd_servers": [
  {
    "enabled": 1,
    "port": 15000,
    "deskey": "0102030405060708091011121314",
    "caid": "0500",
    "users": [
      { "user": "ncam1", "pass": "clave1" },
      { "user": "ncam2", "pass": "clave2" }
    ]
  }
]

Cada entrada corresponde a un CAID/puerto. Los filtros por cuenta (services, max_ecm_rate, etc.) se aplican de forma individual a cada usuario autenticado.

Si. Candela puede actuar como cliente NewCamd y conectarse a servidores externos NCam, OSCam, etc. Configura newcamd_readers en candela.json:

"newcamd_readers": [
  {
    "enabled": 1,
    "host": "192.168.1.10",
    "port": 15000,
    "user": "candela",
    "pass": "mipass",
    "deskey": "0102030405060708091011121314",
    "caid": "0500"
  }
]

Los CWs obtenidos via NewCamd se almacenan en la cache de Candela y se distribuyen al decodificador vía DVBAPI igual que cualquier otra fuente.

NewCamd usa un puerto TCP independiente por cada CAID. Un servidor que tenga cuatro CAIDs activos necesita cuatro puertos distintos. El handshake usa DES/3DES con una deskey de 14 bytes.

MGcamd usa un único puerto para todos los CAIDs. El servidor anuncia en el login qué CAIDs soporta (MSG_CARD_DATA multi-CAID). El handshake es idéntico al de NewCamd.

Para conectar NCam u OSCam a Candela, usa NewCamd si tu cliente requiere un puerto por CAID, o MGcamd si prefieres un único punto de acceso.

Si. Cada cliente NewCamd/MGcamd que se autentica con su usuario y contraseña queda identificado individualmente. Los filtros por cuenta (services, max_ecm_rate, reshare, etc.) se aplican de forma independiente a cada usuario, igual que con los peers P2P nativos de Candela.

El sistema de estadísticas, logs y WebIF también muestra la actividad por usuario NewCamd/MGcamd de forma individual.

No. La mensajería P2P cifrada (CMD_MSG_SEND) es exclusiva del protocolo Candela nativo. Los clientes NewCamd/MGcamd no tienen acceso al buzón de mensajes.

El motivo es técnico: el sistema de mensajería requiere una sesión ECDH Candela activa (X25519 + ChaCha20-Poly1305). Las conexiónes NewCamd/MGcamd usan su propio handshake DES/3DES y no participan en peer_list[] donde residen los peers Candela nativos.

Desde R40, cada entrada de servidor o reader NewCamd/MGcamd tiene un campo candela_mode. Con valor 1, Candela activa una capa adicional ChaCha20 sobre el DES/3DES estándar del protocolo. Solo funcióna cuando ambos extremos son nodos Candela con ese campo activo. Si el otro extremo es NCam, OSCam u otro softcam, la conexión funcióna en modo legado automáticamente sin ningúna configuración adicional.

Ejemplo en candela.json para un servidor:

"newcamd_servers": [
  {
    "port": 15000, "caid": "0500",
    "user": "peer1", "pass": "clave1",
    "deskey": "0102030405060708091011121314",
    "allowed": "10.0.0.0/24",
    "max_clients": 10,
    "keepalive_enabled": 1,
    "candela_mode": 1,
    "enabled": 1
  }
]

Y para un reader (upstream):

"newcamd_readers": [
  {
    "host": "10.0.0.5", "port": 15000,
    "user": "candela", "pass": "clave1",
    "deskey": "0102030405060708091011121314",
    "caid": "0500",
    "candela_mode": 1,
    "enabled": 1
  }
]

En el WebIF, el campo aparece como Modo Candela (ChaCha20 anti-DPI) en los paneles de servidor y de reader NewCamd/MGcamd.

El cliente Candela añade 12 bytes extra al final del payload de login NewCamd: 4 bytes ASCII CNDL (magic) + 8 bytes del NodeID en binario. Los servidores NCam/OSCam ignoran esos bytes extra porque el protocolo NewCamd solo parsea usuario\0 md5[16] del payload y el resto es inerte para ellos.

Si el servidor Candela ve el magic CNDL y tiene candela_mode=1, responde en el ACK con CNDL + sus 8 bytes de NodeID. Ese ACK es la confirmación: a partir de ese momento todos los mensajes (CARD_DATA, ECMs, CWs) se procesan con doble capa.

Si el servidor remoto es NCam/OSCam, el ACK llega vacío (sin CNDL). El cliente detecta la ausencia y activa modo legado automáticamente: ningúna rotura de conexión, ningúna interrupción de imagen.

La clave ChaCha20 se deriva como SHA-256(session_key14 || "CANDELA_LAYER_V1") sobre los 14 bytes de session key DES ya negociados durante el handshake estándar. No hay intercambio adicional de clave: ambos extremos calculan el mismo resultado de forma independiente.

El Modo Candela mejora significativamente la situación frente al DES/3DES puro, pero no llega al nivel de protección del protocolo nativo Candela. Hay que entender exactamente lo que aporta y lo que no:

Lo que el Modo Candela sí consigue:

• El contenido de los mensajes (ECMs, CWs, datos de tarjeta) queda cifrado bajo ChaCha20 además de DES/3DES. Sin la session key DES y la derivación, un observador no puede leer el contenido incluso si rompe el DES/3DES externo con hardware dedicado.
• Los patrónes de payload cambian respecto al NewCamd estándar. Un sistema DPI entrenado para detectar la estructura de mensajes NewCamd verá el payload externo correctamente formateado como NewCamd, pero el contenido interno será opaco.
• El coste de análisis para un observador activo aumenta considerablemente respecto al DES/3DES puro.

Lo que el Modo Candela no consigue:

• No oculta la firma del protocolo NewCamd/MGcamd. El handshake, las cabeceras de mensaje, el padding y la estructura de tramas son idénticos al estándar. Un sistema DPI que busque el patrón de handshake NewCamd lo detectará. El Modo Candela solo cifra el payload, no cambia la estructura del protocolo.
• No hay Perfect Forward Secrecy (PFS). La clave ChaCha20 se deriva de la session key DES, que a su vez se negocia con DES/3DES. No hay intercambio X25519 efímero: si alguien obtiene la deskey de configuración, puede derivar todas las claves de sesión pasadas.
• DES/3DES sigue siendo la capa exterior y sigue siendo vulnerable a ataques de fuerza bruta con hardware especializado (FPGAs, ASICs dedicados a DES). La capa ChaCha20 protege el contenido pero no el mecanismo de establecimiento de sesión.
• Los metadatos de tráfico son visibles. Los tiempos de conexión, la frecuencia de mensajes (un ECM cada 10-15 segundos), los tamaños de paquete y el número de conexiónes son observables. Ante una operadora con correlación de tráfico pasivo, la firma temporal del DVB sigue siendo reconocible.

allowed: lista de IPs o rangos separados por coma que pueden conectarse al servidor. Soporta IP exacta (192.168.1.10), CIDR (192.168.0.0/24) y comodín de octeto (192.168.*). Vacío = cualquier IP. Las conexiónes de IPs no permitidas se cierran inmediatamente. Útil para limitar el servidor a una red local o a IPs de confianza conocidas.

max_clients: número máximo de clientes TCP simultáneos que acepta el servidor. Valor 0 = usar el límite compilado (64). Permite ajustar el límite a la carga esperada: un servidor de uso personal puede tener 2-5, un servidor compartido puede necesitar 20-30. Las conexiónes que superan el límite se rechazan con log de aviso.

keepalive_enabled: con valor 0 el servidor no envía mensajes de keepalive y cierra la conexión ante el primer timeout de inactividad. Con valor 1 (por defecto) mantiene la conexión viva con pings periódicos. Desactivar el keepalive puede ser útil en entornos con muchos clientes de corta duración o cuando se quiere detectar desconexiónes rápidamente sin esperar al timeout del SO.

Desde R40, si un nodo tiene activo un servidor NewCamd o MGcamd, anuncia el flag legacy_proto a toda la red via gossip (CMD_NODE_INFO / CMD_NET_MAP). El resto de nodos Candela que lo reciben:

• Aplican una penalización de -8 puntos sobre el NRS Score de ese nodo. No excluye al nodo de la red, pero lo relega ligeramente en el ranking frente a nodos equivalentes sin legacy activo.
• Muestran el icono 🔓 (candado abierto) junto al score NRS en el panel de nodos y en la tabla del mapa de red.

La penalización es informativa, no punitiva: el operador puede desactivar los servidores legacy en cualquier momento y el flag desaparece en el siguiente anuncio.

Cada nodo Candela tiene un NodeID único y se conecta a otros nodos directamente. No hay servidor central: si un peer cae, el trafico ECM se redistribuye automáticamente entre los demas.

A partir de R37, el sistema NETMAP descubre la topología completa de la red por gossip P2P puro, sin necesidad de intercambiar credenciales entre nodos intermedios.

LAN Discovery (R37) detecta otras instancias Candela en la misma red local via beacon UDP en el puerto 52700.

NSS (Node Status Signal, R37) permite que un nodo anuncie un apagado planificado a sus peers antes de desconectarse. Los peers reciben la notificación y reencaminan los ECMs a otros upstreams sin esperar al timeout.

Para desconexiónes abruptas, el sistema detecta la perdida del peer por timeout y lo marca como no disponible. El NRS actualiza el scoring y AMPE distribuye las peticiónes entre los peers restantes.

Un ataque de eclipse consiste en rodear un nodo con peers maliciosos del mismo bloque de red /24 para controlar todas sus rutas ECM.

Candela limita el número de peers activos del mismo bloque /24 mediante el parámetro max_peers_per_subnet. Si un bloque de red supera ese límite, los nuevos peers de ese bloque se rechazan independientemente de sus credenciales.

AMPE (Adaptive Multi-Path ECM) envía cada petición ECM en paralelo a los N mejores peers (selecciónados por HLS y NRS) simultáneamente. Gana el que responda primero con una CW válida.

Se configura con ecm_multipath en candela.json. El valor indica cuántos peers reciben la ECM en paralelo: 1 = un solo peer (consulta clasica), N = los N mejores por score, 0 = todos los peers elegibles simultáneamente.

Ventajas: latencia máxima reducida, sin bloqueo por peers lentos, failover inmediato ante fallos de respuesta. A partir de R42 el valor por defecto es 3.

NRS (Node Reputation Score) asigna a cada peer upstream una puntuacion de 0 a 100 en tiempo real, combinando tres factores:

• Latencia (peso 50%): EWMA de las ultimás respuestas ECM. 0 ms = 100 puntos, 500 ms = 0 puntos.
• Estabilidad (peso 30%): ratio de conexiónes éxitosas sobre el total. Requiere al menos 3 conexiónes para salir del neutro.
• Actividad (peso 20%): ECMs resueltas (capped a 100).

Confianza progresiva: sin historial suficiente, el score parte de 50 (neutro) y se aproxima al valor real conforme se acumulan datos. Se necesitan aproximadamente 10 datos (conexiónes + ECMs) para que el score refleje el comportamiento real del peer.

Bonus contribuidor: los nodos con pir_auto_connect=1 e IPs no anonimizadas reciben +10 puntos (tope 100). Aparecen marcados con el icono 🔥 en el mapa de red.

El watchdog de reconexión ordena los servidores upstream de mayor a menor NRS. AMPE usa este ranking para selecciónar los peers de cada consulta multi-path. Los peers con NRS bajo quedan al final de la cola automáticamente.

A partir de R42, los lectores NewCamd cliente, MGcamd cliente y hardware físico llevan un historial de latencia por EMA (Media Móvil Exponencial: 70% historial, 30% muestra nueva). Cuando varios lectores son compatibles con el mismo CAID:PROVID, Candela elige automáticamente el que tiene menor latencia media histórica. Los demás actúan como failover en orden de velocidad.

Para lectores hardware, la priorización por latencia solo aplica cuando MCRR está desactivado. Con MCRR activo se respeta la asignación determinista por SRVID.

El historial de cada reader es visible en la pestaña Diagnóstico (card Sparklines de latencia), que muestra las últimas 20 mediciones en una mini-gráfica SVG por reader.

card_hop_limit descarta en recepción las entradas del card_map de un peer cuyo campo hop supere el límite configurado. Una tarjeta con hop=0 es del peer directo; hop=1 viene de un peer de segundo nivel, y así sucesivamente.

Valor 0 (por defecto) significa sin límite: se aceptan tarjetas hasta hop 10 (límite absoluto de propagación anómala). Valor 1 acepta solo tarjetas directas. Útil para evitar que tarjetas lleguen a nodos no deseados en redes grandes.

El control está en Config > sección AMPE, campo numérico de rango 0-10.

Monitor muestra el flujo operativo en tiempo real: ECMs que llegan ahora, CWs que salen ahora, peers activos en este momento. Es como un log visual del daemon.

Diagnóstico acumula histórico y responde a "¿por qué falla este canal?" de forma estructurada: causa raíz por canal, carga de lectores, hit rate de caché, estado CW, actividad EMM y feed de eventos. Es la herramienta de depuración.

La edad de la CW (Control Word) indica cuántos segundos llevan sin renovarse las claves de descifrado de ese canal. El criptoperíodo habitual es de 10 segundos, aunque varía por CAS.

Verde (<8s): normal. Naranja (8-12s): la siguiente CW debería llegar pronto; si no llega a tiempo el canal se corta brevemente. Rojo (>12s): la CW lleva más de un criptoperíodo sin rotar, lo que significa que el canal ya puede estar cortado o que la ECM para la siguiente CW no se está resolviendo.

Causas habituales de CW age alta: peer lento, lector saturado (reader_ocupado), canal filtrado por candela.prio, o caída del peer que servía ese canal.

El ECM PID es el identificador del flujo MPEG-TS que lleva las ECMs de un canal. Está definido en la PMT (Program Map Table) que el receptor DVB envía a Candela al abrir el canal.

Saber el ECM PID permite identificar qué sistema CA está activo para el canal. En canales con múltiples CA (por ejemplo Viaccess y Nagra en el mismo multiplex), cada sistema tiene su propio PID. Si el ECM PID aparece como 0000, el receptor aún no ha enviado la PMT o el canal es FTA.

Depende del CAS. Algunos sistemas como Viaccess o Irdeto envían EMMs con frecuencia para actualizar derechos o rotar claves. Una tasa de 1-5 EMMs/min es habitual en operadoras que usan renovación continua.

Una tasa superior a 10 EMMs/min puede indicar: renovación forzada por la operadora (respuesta a un uso masivo), inicio de un periodo de validación de suscripción, o actividad anómala del sistema CA (poco común). Si la tasa sube de forma repentina y el canal deja de descifrar poco después, la tarjeta puede estar siendo revocada.

Sí. El motor CSA de Candela soporta AES-128-CBC (DVB-CISSA), AES-128-ECB y AES-128-CTR además del clásico DVB-CSA1. El fichero candela.aeskeys permite configurar la clave por SRVID de tres formas:

• Clave estática: 16 bytes en hex directamente en el fichero.
• URL HTTP/HTTPS: Candela fetchea la clave automáticamente al arrancar (compatible con el estándar HLS EXT-X-KEY).
• Auto (sin clave): el canal se resuelve por el pipeline ECM normal (P2P, lector local, NewCamd, MGcamd).

El StreamRelay detecta automáticamente si el stream usa DVB-CSA1 o AES-128 y aplica el algoritmo correcto sin configuración adicional cuando hay una clave configurada.

MultiPID hace que Candela parsee todos los sistemas CA disponibles en la PMT del canal (hasta 8) y lance ECMs a todos en paralelo. La primera CW válida que llega se entrega al receptor; el resto se descartan.

Conviene activarlo cuando:

• El canal emite con varios sistemas CA simultáneos (Viaccess + Nagra, SECA + Irdeto, etc.).
• El sistema CA principal no tiene lector ni peer disponible pero sí hay uno para el secundario.
• Se trabaja con plataformas cable o IPTV de operadores que usan múltiples CAS.

No conviene activarlo si todos tus canales son single-CA (TV por satélite estándar): generaría ECMs innecesarias y aumentaría ligeramente la carga de lectores.

QuickECM permite definir un timeout de respuesta ECM diferente para CAIDs concretos, sobreescribiendo el timeout global/adaptativo solo para ese sistema CA. Por defecto está vacío y todos los CAIDs usan el timeout adaptativo (ETO + client_timeout).

Es útil cuando un operador tiene un ciclo ECM mucho más rápido o lento que el estándar DVB (~10s). Por ejemplo, algunos sistemas IPTV renuevan la CW cada 2 segundos: con el timeout global por defecto (5s) puede parecer que el canal falla, cuando en realidad la CW ya caducó antes de que llegara la respuesta.

Sí. Candela incluye un proxy HTTP compatible con la API de udpxy directamente en el daemon, sin necesidad de instalar ni configurar ningún proceso externo. Activa Proxy IPTV en la pestaña CSA del WebIF y configura el puerto (por defecto 8088).

El STB usa exactamente la misma URL que usaría con udpxy:

http://ip_candela:8088/udp/239.0.5.185:8208

Candela se une al grupo multicast, recibe los paquetes UDP/RTP y los reenvía al STB por HTTP. Si hay clave AES en candela.aeskeys para ese stream, el descifrado es transparente.

También funciona con streams sin puerto (/udp/239.x.x.x usa el puerto 1234 por defecto) y con relay HTTP directo de streams unicast.

Son dos módulos distintos para dos tipos de streaming distintos:

• Proxy IPTV (puerto 8088): para streams de transporte UDP/RTP (multicast o unicast). El STB pide paquetes TS en tiempo real. Equivalente a udpxy.
• Proxy HLS (puerto 8089): para streams sobre HTTP con manifiestos m3u8 y segmentos .ts. El player descarga fragmentos de vídeo. Equivalente a un desencriptador HLS transparente.

Si tu lista IPTV tiene URLs tipo udp://@239.x.x.x:puerto - usa el proxy IPTV. Si tiene URLs tipo http://cdn.tv/stream/playlist.m3u8 - usa el proxy HLS.

Sustituye la URL del stream en el player anteponiendo la dirección del proxy:

Original:   http://stream.tv/live/playlist.m3u8
Via proxy:  http://ip_candela:8089/http://stream.tv/live/playlist.m3u8

O usando el parámetro url=:

http://ip_candela:8089/?url=http://stream.tv/live/playlist.m3u8

Candela descarga el manifiesto m3u8, reescribe las URLs de los segmentos para que pasen por el proxy, y descifra cada segmento AES-128-CBC antes de servirlo al player. El player recibe TS limpio como si fuera un stream FTA.

Sí, en este orden:

1. Busca la clave en candela.aeskeys por SRVID derivado de la URL del stream.
2. Si no está, descarga la clave desde la URI del #EXT-X-KEY del manifiesto (HTTP o HTTPS).
3. Guarda la clave descargada automáticamente en candela.aeskeys para sesiones futuras.

Una vez descargada, la clave se mantiene en caché durante la sesión, sin re-descargar en cada segmento.

Si el stream rota la clave a lo largo del m3u8 (varios bloques #EXT-X-KEY), Candela gestiona la rotación automáticamente.

Lo más probable es un problema de IV (Initialization Vector). En AES-128-CBC, cada segmento tiene su propio IV. Si el IV es incorrecto, los primeros 16 bytes del segmento (aproximadamente un paquete TS) salen corruptos.

Candela calcula el IV correcto por segmento según RFC 8216:

• Si el #EXT-X-KEY incluye IV=0x... - usa ese IV explícito.
• Si no incluye IV - lo calcula como media_sequence + índice_segmento en big-endian de 16 bytes, y lo codifica en la URL del segmento para garantizar que llega correcto al descifrador.

Si sigues viendo artefactos, verifica que el manifiesto m3u8 incluye #EXT-X-MEDIA-SEQUENCE. Si el stream lo omite, Candela asume secuencia 0 y puede haber desfase.

Sí. El proxy parsea el header RTP completo según RFC 3550: longitud base (12 bytes) más los campos CSRC (CC×4 bytes) y, si el bit X está activo, la extensión de cabecera (4 bytes de descriptor + longitud en palabras de 32 bits). El payload TS empieza siempre en el offset correcto, sin importar el tamaño del header.

Con el offset fijo de 12 bytes (como hacen algunas implementaciones simples), los streams con CSRC o extensiones pierden el byte de sincronismo 0x47 y producen imagen corrupta. Candela evita ese problema.

Candela mantiene una cache RAM de pares (ECM hash → CW). Cuando llega un ECM ya resuelto, el CW se devuelve desde cache en menos de 1 ms sin consultar la red ni la tarjeta.

El tamaño máximo se controla con cw_cache_memory (en KB). Por defecto es suficiente para la mayoria de Instalaciónes; en dispositivos con poca RAM puede reducirse.

Si. El motor HLS (Heuristic Latency Scoring) seleccióna el peer óptimo para cada ECM usando la latencia EWMA como métrica principal. Los peers con tarjeta local declarada (hop=0) reciben una ventaja de ×10 en el score - se intentan primero. Entre peers sin tarjeta local, gana el de menor latencia media. El NRS ordena el pool de servidores antes de que HLS elija dentro de él.

Algunos sistemas CAS (especialmente BISS y ciertos Viaccess) rotan las CWs de forma periódica y predecible. El CW Predictor detecta ese patrón y calcula la siguiente CW antes de que el canal la emita.

Cuando el predictor tiene confianza suficiente, el decodificador recibe la CW antes del ECM real, eliminando la latencia de resolución para esos canales.

El predictor está diseñado para funciónar con cualquier sistema CAS que presente rotaciones predecibles, incluidos Nagravision y sistemas similares. Si detectas que un canal concreto no se predice correctamente, repórtalo en el foro de soporte.

El parámetro ecm_ratelimit fija el máximo de SIDs (canales) simultáneos que puede pedir un mismo cliente. Superar ese límite provoca que las peticiónes adicionales sean rechazadas o encoladas.

Además, el parámetro reshare por cuenta limita cuántos hops puede redistribuir un cliente el CW que recibe. Con reshare: 0 el cliente puede usar el CW pero no redistribuirlo.

EFG (ECM Flow Guard, R35) activa Strict Cache Mode automáticamente en peers que superen el umbral de peticiónes por período.

BorraOff es un sistema de penalización progresiva para peers que llevan mucho tiempo desconectados. Tiene tres niveles configurables:

• borraoff_warn_h: horas offline para nivel AVISO
• borraoff_penalty_h: horas offline para nivel PENALIZADO (prioridad reducida)
• borraoff_block_h: horas offline para BLOQUEADO (excluido de resoluciónes)

Se activa con enable_borraoff: 1. Útil en redes con peers poco fiables que generan timeouts frecuentes.

Cada sesion negocia un par de claves X25519 efimero. La clave compartida derivada alimenta HKDF-SHA256 para generar las claves de sesion. Todo el trafico (credenciales, ECMs, CWs) se cifra con ChaCha20-Poly1305, un cifrado AEAD moderno que garantiza confidencialidad e integridad.

La propiedad PFS (Perfect Forward Secrecy) garantiza que si se compromete la clave a largo plazo, las sesiones pasadas siguen siendo secretas porque cada una uso claves efimeras independientes.

CTC (Candela Transport Camouflage) es la capa de camuflaje del protocolo. Envuelve el trafico Candela en una emulacion de TLS 1.3 con:

• Record Layer TLS 1.3 con longitudes realistas
• Cipher suites aleatorios en cada conexión
• SNI sintético aleatorio: prefijo hex de 8 caracteres + sufijo de CDN real (akamaized.net, cloudfront.net, fastly.net, edgekey.net...) - generado por RAND_bytes en cada conexión, sin derivar del NodeID
• ALPN con valores HTTP/2 estándar

Para cualquier firewall o sistema DPI, el trafico Candela es indistinguible de una sesion HTTPS normal.

PIR (Peer Intelligence Ring, R36) es un sistema de inteligencia compartida entre nodos autenticados. Cuando un nodo banea una IP por comportamiento malicioso (CWs falsas, ECM flooding, intentos de autenticación fallidos), puede compartir ese baneo con el resto de nodos autenticados de la red.

Los nodos que reciben la notificación aplican el baneo de forma preventiva, protegiendo la red entera sin que cada nodo tenga que detectar el ataque de forma independiente.

El WebIF esta disponible en http://[IP_DISPOSITIVO]:[web_port]. Por defecto el puerto es 8080.

Las credenciales se configuran con http_user y http_pwd en candela.json.

• Estado de peers conectados y su NRS en tiempo real
• Contadores de ECMs resueltos, latencia media y tasa de acierto de cache
• Logs de sesion y eventos de autenticación
• Estado de los demux activos y canales en descifrado
• Editor de SoftCam.Key
• Configuración editable en tiempo real (sin reiniciar)

candela [opciones]

  -c <archivo>   Config JSON (defecto: config/candela.json)
  -d             Modo debug: todos los logs por consola
  -s             Silent: sin salida a consola
  -b             Background / daemon (solo Linux)
  -v             Mostrar version y salir
  -h             Mostrar esta ayuda y salir

Ejemplos:

candela -b -c /etc/candela/candela.json   # daemon en background
candela -d -c ./config/candela.json       # debug verbose en consola
candela -s -c /etc/candela/candela.json   # silent (logs solo a syslog)
candela -v                                # mostrar version y salir

La forma más común en Enigma2 es un script en /etc/init.d/. El formato exacto depende de la distribución (OE2.0, OE2.5, opkg, etc.), pero el esquema básico es:

#!/bin/sh
case "$1" in
  start)
    /usr/bin/candela -b -c /etc/candela/candela.json
    ;;
  stop)
    killall candela
    ;;
  restart)
    $0 stop; sleep 1; $0 start
    ;;
esac

Activa el servicio con update-rc.d candela defaults o el equivalente en tu distribución. Consulta la wiki para configuraciónes específicas por imagen.

El ECM Idle Watchdog desconecta automáticamente los peers que no han envíado ningún ECM en las ultimás N horas. Se activa con el parámetro ecm_idle_timeout_h (0 = desactivado).

Útil para eliminar peers "zombie" que mantienen la conexión abierta pero no generan actividad real, liberando recursos.

Si. Candela soporta lectores Phoenix (RS-232), SmartReader+ y lectores PC/SC (USB). Se configuran en la sección local_readers de candela.json.

El sistema detecta automáticamente el CAID y PROVID de la tarjeta insertada y la incorpora como fuente de resolución local con la máxima prioridad.

Si. Cada instancia debe usar un archivo de configuración distinto con puertos diferentes:

• port (P2P Candela): diferente en cada instancia
• web_port (WebIF): diferente en cada instancia
• Puertos NewCamd/MGcamd: diferentes en cada instancia (si están activos)

candela -b -c /etc/candela/instancia1.json
candela -b -c /etc/candela/instancia2.json

Candela usa un PID file (candela.pid en el directorio de configuración) para detectar arranques accidentales de la misma instancia. Si arrancas dos veces con el mismo archivo de configuración, la segunda ejecución se detiene con un error indicando el PID del proceso ya en marcha.

Si el proceso anterior terminó de forma inesperada y el PID file quedó huerfano, bórralo manualmente y vuelve a arrancar.

Candela está diseñado para dispositivos embebidos de gama baja. En uso normal:

• CPU: prácticamente 0% en reposo; picos de 1-3% en resolución activa de ECMs (ARMv7 a 1 GHz). El consumo de CPU es similar en decos y en PC.
• RAM en decos: entre 4 MB y 12 MB según el número de peers conectados y el tamaño de la cache configurada.
• RAM en PC, servidor dedicado o VPS: el consumo es mayor porque el sistema operativo asigna paginas de memoria más grandes y la glibc reserva mas heap de forma proactiva. En pruebas sobre PC se han medido hasta ~30 MB de RAM, aunque el uso funciónal es identico al de un deco. Si ejecutas Candela en un PC o servidor y ves un consumo alto de RAM, es normal: el rendimiento y la funciónalidad no se ven afectados.
• Red: trafico mínimo (cada ECM+CW son paquetes de pocos cientos de bytes).

En dispositivos con menos de 32 MB de RAM libre reduce cw_cache_memory a 512 o 256 KB.

El canal oficial de soporte esta en LonasDigital. Para reportar bugs o sugerencias puedes usar el fórmulario de contacto.

Para consultar la documentacion técnica completa: Wiki Técnica de Candela.