Guía de Configuración de GBox Radegast: Config, Puertos& Soluciones 2026

Si has pasado una noche persiguiendo "peer offline" en un registro de GBox sin ninguna explicación, no estás solo. Esta es una de esas configuraciones donde cada publicación en el foro asume que ya conoces el paso que falta. He reconstruido este puente en cajas Enigma2, un par de VMs de Debian y un receptor basado en ARM muy obstinado, y los modos de fallo se repiten casi cada vez. Esta guía recorre gbox radegast настройка: настройка (configuración de GBox Radegast) desde una caja limpia hasta un lector funcional, incluyendo elOScam lado que la mayoría de las páginas omiten por completo.

Cubrirá las directivas de configuración reales, los puertos que se confunden entre sí, las estrofas del puente OScam que nadie escribe y los comandos de diagnóstico que te dicen si el problema es tu configuración o tu red. Sin IDs de pares copiados y pegados, sin números de tiempo de actividad falsos, solo lo que realmente se rompe y cómo comprobarlo.

Qué son realmente GBox y Radegast (y cómo difieren)

Las personas confunden estos dos constantemente, así que vamos a separarlos. GBox es un daemon de intercambio peer-to-peer con su propia lista de pares, su propio modelo de contraseña y su propio protocolo para intercambiar ECMs entre cajas que confían entre sí.CCcam funciona de manera diferente: cliente/servidor, con una lista de compartición enviada a los clientes. Los pares de GBox son más o menos iguales; cada uno puede servir tarjetas y solicitar tarjetas de los demás dependiendo de cómo lo configures.

Radegast es algo completamente diferente. No es un daemon de intercambio; es un protocolo delgado y en texto plano para llevar solicitudes y respuestas de ECM a través de TCP. Sin cifrado, sin intercambio de contraseñas, nada. El control de acceso es la lista de IP permitidas que le agregas en el firewall o en la configuración del daemon. Eso es todo. TCP 6666 es el puerto al que todos recurren por convención, pero no hay nada mágico al respecto: es configurable en ambos extremos.

La mayoría de las personas que escriben esta consulta en un cuadro de búsqueda no están tratando de ejecutar dos instancias de GBox juntas. Están tratando de hacer que un viejo cliente solo de GBox hable con un lector moderno de OScam, o conectar una red de pares de GBox a una caja de OScam que tiene la tarjeta física. Radegast es el pegamento para exactamente esa situación: un protocolo de puente, no algo que elegirías como tu enlace principal de intercambio si tuvieras opciones modernas de OScam a OScam disponibles.

GBox como un daemon de intercambio peer-to-peer vs el modelo cliente/servidor de CCcam

En CCcam, una caja es el servidor y todos los demás se conectan como clientes con un nombre de usuario/contraseña de la línea C:. En GBox, cada par se define individualmente con su propia IP, puerto, ID y par de contraseñas. No hay una lista de cuentas central: son todas relaciones de confianza punto a punto.

Radegast como un protocolo de solicitud de tarjeta simple y sin cifrado

Radegast envía una solicitud de ECM, recibe una palabra de control de vuelta, listo. No hay una capa de cifrado de sesión como la de CCcam, y no hay intercambio de inicio de sesión como el de newcamd de OScam. Cualquiera que pueda alcanzar el puerto y no esté bloqueado por filtrado de IP puede hablar con él.

Por qué Radegast se utiliza como un puente, no como un enlace principal de intercambio

Porque no tiene autenticación propia y no tiene ruta EMM (más sobre eso más adelante), es mejor tratarlo como una capa de traducción entre dos sistemas que de otro modo no podrían comunicarse, no como tu protocolo principal de distribución a una docena de cajas descendentes.

Cuándo necesitas GBox en absoluto vs quedarte completamente dentro de OScam

Si cada caja en tu configuración ejecuta OScam, probablemente no necesites GBox: OScam a OScam a través de su propio protocolo o newcamd hará el trabajo con menos sobrecarga. GBox gana su lugar cuando tienes clientes heredados o relaciones de pares que específicamente esperan el protocolo GBox en un extremo.

Preparando la Caja: Archivos, Rutas y Permisos Antes de Editar Cualquier Cosa

Antes de tocar una sola directiva, confirma qué archivos está leyendo realmente el binario en ejecución. Esto suena obvio, pero es el único hundimiento de tiempo más común en gbox radegast настройка: настройка (configuración de GBox Radegast): la gente edita una configuración que el daemon nunca abre.

Dónde GBox busca su configuración: /etc/gbox.cfg, /var/keys/, y sobrescrituras específicas de la imagen

En muchas imágenes de Enigma2, la configuración funcional vive bajo/var/keys/, mientras que una compilación genérica predetermina a/etc/gbox.cfg. Algunas imágenes crean un enlace simbólico de una a la otra; algunas no. No asumas: verifica.

Localizando gbox.ident, gbox.cfg y los archivos de compartir/pares

Mata el daemon en ejecución, luego inícialo manualmente en primer plano:

/usr/bin/gbox -c /etc/gbox.cfg

Observa las líneas de inicio: un binario correctamente construido registra las rutas exactas que abre para la configuración, el archivo de identificación y la lista de pares. Si comienza en silencio sin imprimir una ruta, verifica el script de inicio en su lugar.

Localizando gbox.ident, gbox.cfg y los archivos de compartir/pares

Busca en el script de inicio la ruta real:

grep -i gbox /etc/init.d/* 2>/dev/null

O en una caja de systemd:

systemctl cat gbox.service

Esto te dice el exacto-c bandera o directorio de trabajo con el que se inicia el demonio — que es la configuración que realmente lee, independientemente de lo que esté en/etc.

Comprobando tu imagen: Enigma2 (OpenATV/OpenPLi) vs una caja Debian/Ubuntu simple

Los receptores Enigma2 tienden a ejecutar todo como root con un sistema de archivos plano, por lo que los errores de permisos son raros, pero la confusión de rutas es común. Una caja Debian o Ubuntu ejecutando GBox como un servicio tiene el problema opuesto: los permisos te afectan constantemente, la confusión de rutas rara vez lo hace.

Arquitectura binaria: las compilaciones mipsel, ARM y x86 no son intercambiables

Si colocas un binario mipsel en un receptor basado en ARM, obtendrás un error críptico de formato de ejecución que no se parece en nada a un problema de permisos o configuración. Verifica confile /usr/bin/gbox antes de perder una hora editando una configuración que nunca iba a ejecutarse.

Estableciendo permisos ejecutables y confirmando que el demonio se inicia al arrancar

chmod 755 /usr/bin/gbox en el binario,chmod 644 en los archivos de configuración. En una caja Debian, no ejecutes el demonio como root a menos que la imagen del proveedor lo requiera genuinamente — crea en su lugar una cuenta de servicio dedicada. También verifica el espacio libre en la partición flash condf -h; en receptores más antiguos, una flash llena trunca silenciosamente una configuración escrita a mitad de archivo, y no recibirás un error por ello.

Escribiendo la Configuración de GBox: Cada Línea Explicada

Aquí hay un esqueleto anotado. Reemplaza cada IP, ID y contraseña a continuación — estos son marcadores de posición, no algo que copiar literalmente en producción.

Identidad de par local, líneas de contraseña y nombre de host

ElN: yP: las líneas identifican quién eres para los pares y qué contraseña presentarás al conectarte hacia afuera. Esto es separado de lo que un par te envía — que es la parte que confunde a la gente.

Definiendo pares remotos: IP, puerto, ID de par y el par de contraseñas compartidas

CadaC: línea necesita un par coincidente — la contraseña que el par espera de ti, y la contraseña que tú esperas de ellos. Si obtienes una de las dos al revés, obtienes un fallo de conexión silencioso sin nada útil en el registro. No hay un error de "contraseña incorrecta" la mayor parte del tiempo; el par simplemente nunca aparece.

Configurando el puerto de escucha y vinculando a la interfaz correcta

Verifica si tu compilación se vincula a0.0.0.0 (todas las interfaces) o127.0.0.1 (solo loopback) por defecto. Vincularse a loopback y luego preguntarse por qué un cliente de LAN no puede alcanzar el puerto es uno de los errores más comunes en toda esta configuración.

Filtros de tarjeta y CAID/proveedor: compartiendo solo lo que pretendes compartir

Elcaid: yident: líneas restringen lo que se ofrece a un par. Dejar estos completamente abiertos no es exactamente un error de configuración, pero es descuidado — y hace que depurar "por qué este canal no se decodifica" sea mucho más difícil después porque no puedes descartar el filtrado de un vistazo.

Límites de saltos, distancia y configuraciones de caché que previenen tormentas de solicitudes

Elhops: valor controla cuán lejos se permite que una solicitud viaje a través de la malla de pares antes de ser descartada. Cualquier cosa por encima de 2 o 3 tiende a contaminar la caché de ECM con entradas obsoletas y genera solicitudes muertas que nunca se resuelven — no te da más canales, solo añade ruido.

Habilitando el oyente de Radegast y eligiendo su puerto

Esta es la parte que la gente pierde constantemente: el oyente de Radegast es un servicio completamente separado del puerto de par de GBox arriba.radegast_port: 6666 no tiene nada que ver conport: 12000. Cada uno necesita su propia regla de firewall, y olvidar esto es la razón por la que la mitad de las publicaciones de "no está funcionando" en línea son realmente dos puertos diferentes con solo uno de ellos abierto.

Puenteando GBox y OScam a través de Radegast

Esta es la sección que la mayoría de las guías omiten por completo — lanzan un gbox.cfg y se detienen, dejándote adivinar el lado de OScam. Aquí están ambas direcciones.

Configurando un lector de OScam con protocolo = radegast

En/etc/oscam/oscam.server, define un lector que hable Radegast al par de GBox:






caid = 0500
ident = 0500:000000
inactivitytimeout = 30

El bloque oscam.server correspondiente: dispositivo, IP, puerto, grupo y CAID

Eldispositivo toma IP y puerto separados por comas, no por dos puntos; si te equivocas, OScam se negará a cargar el lector por completo, no solo fallará en conectarse. Elcaid yident los filtros aquí importan porque Radegast en sí no lleva negociación de identificación de proveedor; si no los configuras explícitamente, OScam no tiene forma de saber para qué es realmente bueno el lector.

Agregar un usuario de radegast en oscam.user con el grupo correcto

En/etc/oscam/oscam.user, cualquier cliente que necesite las tarjetas de este lector tiene que estar en el mismo número de grupo:

Esta coincidencia de número de grupo es el punto de falla más común en todo el puente. Si el grupo 4 está en el lector y el grupo 5 en el usuario, OScam mostrará el lector como conectado, el registro se verá completamente limpio y el conteo de ECM se mantendrá en cero para siempre. No hay error para esto; simplemente es un enrutamiento no silencioso.

Habilitando el servidor OScam Radegast en oscam.conf y configurando la IP permitida

Si OScam es el que está sirviendo tarjetas a través de Radegast (en lugar de consumirlas), agrega esto a/etc/oscam/oscam.conf:

Dado que Radegast no tiene intercambio de contraseñas,permitido es toda tu capa de autenticación aquí. No lo dejes en blanco.

Verificando el enlace en la interfaz web de estado del lector de OScam

Abre la interfaz web de OScam, generalmente en el puerto 8888, y verifica la página de estado del lector. "Conectado" solo te dice que el socket está activo. El número que realmente quieres es el contador de solicitudes ECM en ese lector; si está subiendo cuando cambias de canal, el puente está enrutando tráfico genuinamente. Si está atascado en cero, vuelve a los números de grupo antes de tocar cualquier otra cosa.

Dirección inversa: GBox como la fuente de la tarjeta, OScam como el cliente

Si GBox tiene la tarjeta y OScam está aguas abajo, invierte: GBox ejecuta el oyente Radegast (radegast: 1,radegast_port: 6666) y el lector OScam conprotocolo = radegast apunta a la IP de GBox y ese puerto. Las mismas advertencias de grupo/CAID se aplican en el lado de OScam de cualquier manera.

Redes: Puertos, NAT, IPs dinámicas y cortafuegos

Una vez que la configuración es correcta, la mayoría de los fallos restantes son de red, no de GBox o OScam en absoluto.

Qué puertos abrir: el puerto de pares de GBox y el puerto de Radegast son diferentes

Dilo de nuevo porque merece ser repetido: el puerto de pares de GBox (en el ejemplo anterior, 12000) y el puerto de escucha de Radegast (6666) son servicios no relacionados. Abre ambos si necesitas ambos. Abrir solo uno y asumir que el otro funciona es un error muy común.

Reenvío de puertos en el router y el problema de doble NAT / CGNAT

Verifica la IP WAN del router con lo que informa una verificación pública de "cuál es mi IP". Si no coinciden, estás detrás de CGNAT: tu ISP está compartiendo una dirección pública entre muchos clientes, y ningún reenvío de puerto que configures será accesible desde fuera. En esa situación, los únicos caminos realistas son un túnel VPN saliente o hacer que el otro extremo inicie la conexión en lugar de ti.

DNS dinámico cuando tu ISP rota tu dirección

Si tu IP WAN cambia (solo que no a través de CGNAT — una asignación dinámica regular), un nombre de host DDNS apuntado a tu router te ahorra tener que volver a editar las IPs de los pares cada vez que tu ISP te reasigna.

Confirmando la accesibilidad con nc, telnet y ss/netstat

Desde la caja que ejecuta el demonio, confirma que realmente está escuchando:

ss -tulpn | grep -E '6666|12000'

Verifica la columna de dirección local —0.0.0.0:6666 significa todas las interfaces,127.0.0.1:6666 significa solo bucle invertido y nada fuera de la caja puede alcanzarlo. Desde el lado del par, prueba si el paquete siquiera llega:

nc -vz 192.168.1.20 6666

Este único comando separa "el demonio está roto" de "el paquete nunca llegó" más rápido que mirar los registros.

Tunelizando Radegast sobre WireGuard u OpenVPN en lugar de exponerlo

Debido a que Radegast no autentica nada por sí mismo, no lo reenvíes directamente a Internet. Coloca un túnel de WireGuard u OpenVPN entre los dos extremos y ejecuta Radegast dentro de eso en su lugar: obtienes la conveniencia de un par remoto sin que el puerto esté abierto a cualquiera que lo escanee.

Solución de problemas: Leer los registros y arreglar los fallos comunes

Trabaja a través de estos en orden: síntoma, causa probable, comando para confirmar, solución.

Activando el registro detallado y dónde se encuentra el archivo de registro

La mayoría de las compilaciones aceptan un-d o bandera de depuración en la línea de comandos, o una directiva de nivel de registro en la configuración. Ejecútalo en primer plano primero (/usr/bin/gbox -c /etc/gbox.cfg -d) antes de confiar en lo que termine en un archivo de registro: verás los intentos de conexión desplazarse en tiempo real.

El par muestra desconectado: desajuste de contraseña, ID de par incorrecto o UDP bloqueado

Verifica nuevamente el par de contraseñas descrito anteriormente: un desajuste no produce un error explícito, solo un par que nunca se activa. También confirma que el ID de par coincide exactamente en ambos lados; un error tipográfico aquí falla de la misma manera silenciosa.

Par en línea pero cero ECMs: desajuste de grupo, filtro CAID o límite de salto

Cubierto anteriormente en la sección del puente OScam, pero vale la pena repetirlo como una lista de verificación: número de grupo en el lector vs usuario, filtro CAID/ident que excluye el canal, o un límite de salto que está descartando la solicitud antes de que llegue a la tarjeta. El contador de ECM del lector OScam es tu diagnóstico más rápido: míralo mientras cambias de canal.

Congelamiento y retraso en el cambio de canal: tiempo de respuesta de ECM por encima del presupuesto de ~1.5s

Por debajo de aproximadamente 500ms se siente limpio. Pasado alrededor de 1000-1500ms verás congelamiento visible al cambiar de canal, y una vez que superes el tiempo de ciclo de la palabra de control, la respuesta es inútil sin importar cuán rápido llegue eventualmente. Verifica los tiempos de respuesta en las estadísticas del lector de OScam: este es un problema de red/origen, no algo que una directiva de configuración solucione.

Solicitudes duplicadas o en bucle causadas por dos cajas compartiendo un ID de par

Si dos receptores en tu red están accidentalmente configurados con el mismo ID de par, verás caídas intermitentes, aparentemente aleatorias, que solo tienen sentido una vez que correlacionas los registros de ambas cajas lado a lado. Dale a cada caja un ID único, sin excepciones.

Procedimiento de reinicio limpio que evita archivos de bloqueo obsoletos

Antes de reiniciar después de un fallo o un apagado no limpio, verifica si hay un proceso zombi que aún esté ocupando el puerto:

ps aux | grep gbox
ss -tulpn | grep 6666

Mata el proceso obsoleto, elimina cualquier archivo de bloqueo sobrante que use el binario y luego comienza de nuevo. Saltarse este paso es la razón por la que a veces un reinicio parece no hacer nada en absoluto.

Lo que no funciona (y consejos comunes que deberías ignorar)

Parte de lo que circula en los hilos del foro sobre esto es simplemente incorrecto o está desactualizado desde hace años.

Configuraciones de foro copiadas y pegadas con los IDs de pares y puertos de otra persona

Las configuraciones de hilos antiguos hacen referencia a IDs de pares, puertos e incluso rutas de archivos que pertenecían a la configuración de otra persona, posiblemente hace años. Trátalas como plantillas para entender la estructura, nunca como algo para pegar directamente.

Aumentar el conteo de saltos para "obtener más canales"

Este es un mal consejo que sigue repitiéndose. Un mayor conteo de saltos no añade canales; degrada las tasas de aciertos de caché para todos en la malla y genera solicitudes ECM que se agotan antes de ser útiles.

Exponer el puerto de Radegast a Internet sin una lista de permitidos de IP

Debido a que no hay autenticación en el protocolo en sí, un puerto de Radegast abierto es una puerta abierta. Siempre combínalo con una lista de permitidos de IP, idealmente combinada con una regla de restricción de origen de iptables como segunda capa.

Mezclar binarios de GBox construidos para una arquitectura diferente o una imagen diferente

Un binario mipsel en un receptor ARM, o una construcción de Enigma2 colocada en una caja Linux genérica, falla con un error de formato de ejecución que se confunde constantemente con un problema de configuración. Verificael archivo en el binario primero.

Esperar que Radegast maneje EMMs o gestione escrituras de tarjetas

Radegast es solicitud/respuesta solo para ECMs; no hay un camino EMM en el protocolo. Las actualizaciones de tarjetas deben ocurrir en la caja que sostiene físicamente el lector, no a través del enlace de Radegast. La gente pierde días enteros asumiendo lo contrario.

Perseguir un protocolo "más rápido" cuando el verdadero cuello de botella es la latencia ascendente

Si la tarjeta ascendente está a 400 ms de distancia a través de un enlace congestionado, cambiar de protocolos no lo solucionará. Ninguna directiva de configuración compensa la latencia física de la red.

Elegir una fuente de tarjeta o par sin quemarse

Si estás evaluando un nuevo par o fuente de tarjeta en lugar de ejecutar tu propio lector de extremo a extremo, júzgales según criterios medibles, no según afirmaciones de marketing.

Criterios técnicos: tiempo de respuesta ECM medible, tiempo de actividad y distancia de salto

Pide una ventana de prueba corta y mide realmente los tiempos de respuesta ECM durante las horas pico de la tarde en tus propios registros, no en su página de marketing. Cualquier cosa consistentemente por debajo de 500 ms es sólida; cualquier cosa regularmente por encima de 1500 ms no será utilizable independientemente de lo que esté bien en la configuración.

Soporte de protocolo: ¿ofrece la fuente realmente un enlace compatible con Radegast u OScam?

Confirma que realmente soportan el protocolo que necesitas antes de comprometer tiempo a la configuración. Algunas fuentes solo hablan newcamd o CCcam y te dirán que Radegast funciona "con un poco de ajuste"; eso generalmente significa que no lo hace.

Banderas rojas: sin período de prueba, sin canal de soporte, conteos de canales poco realistas

Sin período de prueba, sin forma de hacer una pregunta técnica, o un conteo de canales que suena demasiado amplio para una configuración de tarjeta plausible son razones para alejarse.

Tarjeta local vs par remoto: las compensaciones en costo, latencia y fiabilidad

Una tarjeta que sostienes físicamente no tiene dependencia de red y la latencia más baja posible, a costa de tu propio hardware y suscripción. Un par remoto es más flexible pero hereda cada bit de la fiabilidad y distancia de red de ese par.

Realidad legal: debes tener una suscripción válida para el contenido que descifras

En algún lugar de esta cadena, una tarjeta inteligente genuina y pagada tiene que estar haciendo el descifrado legítimamente. Compartir claves de descifrado sin una suscripción válida para ese contenido es ilegal en la mayoría de las jurisdicciones, y esta guía asume que estás configurando hardware y tarjetas que posees o a las que te suscribes legítimamente.