🇬🇧 ⚠️ Disclaimer legal: Este contenido es exclusivamente educativo. Modificar firmware de dispositivos de telecomunicaciones puede vulnerar los términos de tu contrato con el ISP y potencialmente regulaciones locales de telecomunicaciones. La Ley General de Telecomunicaciones en Chile establece condiciones sobre el uso de equipos en redes del operador. Consulta la normativa vigente en tu país antes de replicar este procedimiento. El autor no se responsabiliza por daños al equipo ni por consecuencias contractuales o legales.
Entel Chile tiene un servicio de empresa bastante decente. IP estática incluida, latencias estables, algo que en los planes hogar de Movistar ni soñar. El problema es que el técnico que vino a instalar la fibra trajo un ONT Huawei que es, en términos técnicos, una caja negra que solo responde a órdenes del ISP y no a las tuyas.
Le pedí al técnico que lo pusiera en bridge mode. Me miró como si le hubiera pedido que preparara un café. Llamé al soporte de Entel. Sonaban profesionales hasta que mencioné bridge mode, momento en que la conversación tomó el tono amistoso de "eso no existe para clientes empresa ni residenciales".
Bien. Si el ISP decide que en tu propia infraestructura las reglas son las suyas — aunque el hardware esté en tu casa y lo pagues tú — que así sea. Existe el otro camino: el método Alpha 😎.
El descubrimiento: transceptores SFP GPON
Investigando alternativas encontré los transceptores SFP que funcionan como miniONT: dispositivos en formato SFP que insertas directamente en el slot del router y que negocian con la OLT del ISP sin un ONT separado.
El candidato: Ubiquiti UFiber UF-Instant. Un miniONT SFP basado en el chipset Realtek RTL9601CI. De fábrica solo negocia con infraestructura UFiber de Ubiquiti — vendor lock-in dentro del vendor lock-in, encantador — pero la comunidad de hack-gpon.org ya había documentado cómo liberarlo. El repositorio de stich86 tenía un rootfs modificado específicamente para este stick. Solo había que instalarlo correctamente y configurar la identidad GPON para que la OLT de Entel lo aceptara como si fuera el ONT Huawei original.
El hardware necesario
⚠️ El adaptador UART TTL debe ser 3.3V obligatoriamente. El hardware del UF-Instant no tolera 5V — con 5V lo quemas.
Fuente: stich86/UF-Instant-Mod — créditos al autor original.
Anatomía del UF-Instant: el mapa antes de meter mano
El UF-Instant corre Linux sobre el RTL9601CI. Su flash SPI tiene diez particiones, pero las que importan son estas:
mtd0 → U-Boot (256KB) — Bootloader. Nunca se toca.
mtd1 → U-Boot env 1 (8KB) — Variables de arranque (sw_active, sw_commit, bootlimit)
mtd2 → U-Boot env 2 (8KB) — Copia de seguridad de las variables
mtd3 → /var/config (240KB) — Config persistente ⚠️ se borra al flashear imagen nueva
mtd4 → kernel0 / k0 (3MB) — Kernel imagen 0 — el Ubiquiti original, nuestro respaldo
mtd5 → rootfs0 / r0 (6MB) — Rootfs imagen 0 — firmware original Ubiquiti
mtd6 → kernel1 / k1 (3MB) — Kernel imagen 1 — aquí va el kernel clonado
mtd7 → rootfs1 / r1 (4.5MB)— Rootfs imagen 1 — aquí va el MOD de stich86
mtd8 → europa.data — Calibración del láser ⚠️ ÚNICA POR DISPOSITIVO, JAMÁS SE TOCA
mtd9 → sec — Parámetros del firmware Ubiquiti originalEl sistema de arranque dual:
nv getenv sw_active sw_commit ← ver cuál imagen está activa
sw_active=0 + sw_commit=0 → arranca mtd4 (kernel0) + mtd5 (rootfs0)
sw_active=1 + sw_commit=1 → arranca mtd6 (kernel1) + mtd7 (rootfs1)La estrategia: imagen 0 queda intacta con el firmware original de Ubiquiti como respaldo de emergencia. Todo el MOD va en imagen 1. Si algo sale mal, un setenv sw_active 0 desde U-Boot y el stick vuelve a la vida.
⚠️ mtd8 nunca se toca. Contiene la calibración del láser, grabada de fábrica, única por dispositivo. Borrarla deja el stick inservible sin ninguna posibilidad de recuperación.
Acceso por UART: la consola de todo
Por UART corre todo el proceso. Sin GUI, sin app, sin intermediarios. Todo el proceso de flash se hace desde aquí.
El UF-Instant expone pads UART en la PCB. La conexión es directa:
Adaptador UART TTL (3.3V) → UF-Instant PCB
TX del adaptador → RX del stick (pad marcado RX o R)
RX del adaptador → TX del stick (pad marcado TX o T)
GND del adaptador → GND del stick (pad marcado GND o G)Configuración del puerto serie en el host:
# macOS
screen /dev/tty.usbserial-XXXXX 115200
# Linux
screen /dev/ttyUSB0 115200
# Con minicom (más estable para sesiones largas)
minicom -D /dev/ttyUSB0 -b 115200 -8 --noinitParámetros: 115200 baudios, 8 bits de datos, sin paridad, 1 stop bit (8N1).
Al encender el stick con UART conectado, el terminal muestra el output completo de U-Boot. Si presionas cualquier tecla en los primeros segundos, interrumpes el arranque y quedas en el prompt de U-Boot (9601C#). Desde ahí puedes flashear particiones directamente con los comandos sf (SPI Flash).
La ejecución: flash, spoofing y O5
Todo se ejecuta por UART. Sin interfaces web, sin apps, sin magia. Un terminal serie, el bootloader U-Boot y comandos Linux.
Qué preparar en el host antes de empezar
Necesitas estos archivos listos en el directorio del servidor TFTP:
El rootfs MOD descargado directamente del repositorio stich86/UF-Instant-Mod — el binario squashfs tal como viene, sin modificar
uImage_ubiquiti_v4.4.2— el kernel original de Ubiquiti v4.4.2 (en la carpetaOriginal Firmwares/v4.4.2.1248del mismo repo)
Y un servidor TFTP corriendo en el host. En macOS:
# Con tftp-now (más simple)
sudo tftp-now
# O con el TFTP nativo de macOS
sudo launchctl load -F /System/Library/LaunchDaemons/tftp.plist
# Los archivos deben estar en /private/tftpboot/El stick y el host deben estar en la misma red. La IP del host es la que usarás en los comandos tftpboot de U-Boot.
¿Cuándo necesitas Docker? Solo si vas a modificar el rootfs: extraerlo con
unsquashfs, hacer cambios y reempaquetarlo. En macOS,mksquashfsno puede recrear device nodes (/dev/console,/dev/null, etc.) sin parámetros explícitos, y el rootfs resultante no arranca. Si usas el binario de stich86 tal como lo descargaste, flashéalo directo — no necesitas Docker.
Paso 1: Flashear kernel y rootfs via UART (U-Boot)
Conecta el UART. Enciende el stick. Interrumpe el boot en cuanto aparezca el contador de U-Boot (presiona cualquier tecla). Estarás en el prompt 9601C#.
Inicializa el controlador de flash SPI:
sf probe 0Flashear el kernel en imagen 1 (mtd6 — dirección 0x4e0000, tamaño 3MB):
El kernel de Ubiquiti v4.4.2 ya está en imagen 0 (mtd4). Puedes clonarlo directamente a imagen 1 sin necesidad de TFTP:
# Leer kernel0 completo a RAM (3MB desde 0x50000)
sf read 0x81000000 0x50000 0x300000
# Borrar kernel1 y escribir el clon
sf erase 0x4e0000 0x300000
sf write 0x81000000 0x4e0000 0x300000Alternativamente, si prefieres transferirlo via TFTP:
tftpboot 0x81000000 [IP_HOST]:uImage_ubiquiti_v4.4.2
sf erase 0x4e0000 0x300000
sf write 0x81000000 0x4e0000 ${filesize}Flashear el rootfs MOD en imagen 1 (mtd7 — dirección 0x7e0000, tamaño 4.5MB):
# Transferir el rootfs directamente desde el servidor TFTP
tftpboot 0x81000000 [IP_HOST]:[nombre_del_rootfs_stich86]
# Borrar rootfs1 y escribir el MOD
sf erase 0x7e0000 0x480000
sf write 0x81000000 0x7e0000 ${filesize}Activar imagen 1 como la imagen de arranque:
setenv sw_active 1
setenv sw_commit 1
saveenv
bootEl stick arranca con el MOD de stich86 en imagen 1. Si el arranque falla, vuelves a U-Boot y ejecutas setenv sw_active 0 && setenv sw_commit 0 && saveenv && boot para volver a imagen 0 con el firmware original intacto.
Paso 2: Configurar la identidad GPON desde Linux (UART)
Una vez que el stick arranca con el MOD, conecta el UART al sistema Linux (credenciales: admin/admin — algunos builds usan ubnt/ubnt). Ahora configuras el spoofing de identidad con los datos del ONT Huawei original de tu instalación:
# === IDENTIDAD GPON — sustituir con los datos reales de tu ONT Huawei ===
# El serial GPON tiene formato HWTC + 8 caracteres hexadecimales
# Lo encuentras en la etiqueta del ONT o en su interfaz web bajo "GPON SN"
flash set GPON_SN HWTC[XXXXXXXX]
# El vendor ID siempre es HWTC para equipos Huawei
flash set PON_VENDOR_ID HWTC
# Modo OMCI: 1 = compatible con OLT Huawei
flash set OMCI_OLT_MODE 1
# OMCI_FAKE_OK: el stick responde OK a los mensajes OMCI de la OLT
flash set OMCI_FAKE_OK 1
# Versión de software del ONT — campo "SW Version" en la interfaz del ONT
flash set OMCI_SW_VER1 [VERSION_SW_ONT]
flash set OMCI_SW_VER2 [VERSION_SW_ONT]
# Versión de hardware del ONT — campo "HW Version"
flash set HW_HWVER [VERSION_HW_ONT]
# Modelo del ONT — campo "Device Model" o "Product Model"
flash set GPON_ONU_MODEL [MODELO_ONT]
# MAC del ONT — sin dos puntos, todo mayúsculas (ej: 803C2089B104)
flash set ELAN_MAC_ADDR [MAC_ONT_SIN_PUNTOS]Paso 3: Neutralizar el bootlimit (importante)
El firmware original de Ubiquiti que está en imagen 0 tiene bootlimit=10 por defecto. Esta variable hace que U-Boot borre mtd3 (la configuración persistente) y trate de hacer recovery TFTP si el stick falla 10 veces seguidas. Para que no interfiera:
nv setenv bootcount 0
nv setenv bootlimit 0Paso 4: Reiniciar y verificar el estado GPON
rebootDespués del reinicio, desde UART (Linux):
# El objetivo: O5 = Operation State = la OLT aceptó el stick como ONT válido
diag gpon get onu-state
# Respuesta esperada: ONU state: Operation State(O5)
# Confirmar que la OLT reconoció el vendor correcto
omcicli mib get 131
# OltVendorId: 0x48575443 ← HWTC en ASCII = Huawei/Entel Chile ✓
# Ver las VLANs que la OLT provisionó automáticamente
omcicli mib get 84VLANs que provisiona la OLT de Entel Chile:
Paso 5: Configurar el router Ubiquiti UniFi Fiber
Con el stick en O5 y la OLT reconociéndolo, la configuración del router es directa:
¿De dónde vienen estos datos? De esos rincones de las instalaciones donde la información aparece para quien sabe dónde mirar. Los probé el 2026-04-23 y funcionaron. Entel puede rotarlos cuando quiera.
🎥 La despedida oficial del módem de Entel
El camino hasta aquí: los errores que me costaron días
Esta sección no es necesaria para replicar el proceso. Es el registro honesto de por qué llegué a la solución de esa manera y no de una más directa.
El primer error: leer las instrucciones a medias
La documentación de stich86 indicaba flashear el rootfs MOD en mtd5 (rootfs0). Lo que hice fue flashear también mtd4 (kernel0), dejando imagen 0 sin kernel válido.
El resultado:
Wrong Image Format for bootm command
ERROR: can't get kernel image!Recuperación por TFTP: Desde U-Boot (accesible por UART incluso con imagen corrupta), configuré el servidor TFTP en el Mac y restauré los binarios originales desde el directorio Original Firmwares/v4.4.2.1248-550.220304.1317/extracted/ del repo stich86:
# En U-Boot via UART
sf probe 0
tftpboot 0x81000000 [IP_HOST]:uImage # kernel original
sf erase 0x50000 0x300000
sf write 0x81000000 0x50000 0x300000
tftpboot 0x81000000 [IP_HOST]:rootfs # rootfs original
sf erase 0x1e0000 0x4b0000
sf write 0x81000000 0x1e0000 0x4b0000
setenv sw_active 0
setenv sw_commit 0
saveenv
resetLos comandos predefinidos del UF-Instant simplifican esto:
run upk # flashea uImage en mtd4
run upr # flashea rootfs en mtd5El stick volvió a la vida. El aprendizaje: leer todo antes de ejecutar nada.
Intento 1: stich86 MOD + MC220L = kernel panic
El rootfs MOD de stich86 se instaló en imagen 1. El stick arrancó. Pero en cuanto conecté el cable ethernet al TP-Link MC220L (que usaba como media converter para tener acceso ethernet desde el stick), kernel panic:
Modules linked in: europa_drv(P) igmp_drv pf_rtk omcidrv
Kernel panic - not syncing: Fatal exception in interrupt
El driver europa_drv (el controlador del láser óptico) crasheaba al recibir interrupts de link-up desde el MC220L. Bug documentado en el issue #24.
Intento 2: rootfs del V-SOL V2801F
El V-SOL V2801F es otro dispositivo RTL960x con firmware más abierto. En teoría, su rootfs debería ser compatible con el hardware del UF-Instant.
En la práctica:
cat /proc/kmsg | grep -i pon # silencio
lsmod | grep europa # vacío
cat /proc/lan_sds/lan_sds_ident # serial vacío, OUI 0:0:0El europa_drv no cargaba. La librtk.so del V2801F no era compatible con el hardware del UF-Instant. GPON nunca superó O1.
Intento 3: firmware híbrido V2801F + binarios Ubiquiti
La idea era mezclar lo mejor de ambos: el rootfs del V2801F (con configuración OMCI más flexible) reemplazando los binarios críticos con los de Ubiquiti (europa_drv.ko, librtk.so, sfpapp). El proceso requería reempaquetar con mksquashfs en macOS (de ahí el paso de Docker que sigue siendo necesario) y usar gtar en lugar del tar nativo porque el script del V2801F no era compatible.
El resultado:
startup: can't resolve symbol 'getConfigurationMac'
insmod: cannot insert 'europa_drv.ko': unknown symbol in moduleIncompatibilidad de ABI entre los binarios de Ubiquiti y las librerías del V2801F. El enfoque era incorrecto de raíz.
La frustración del punto medio
Hubo un período de varios días donde el stick arrancaba, el firmware no explotaba, pero el GPON nunca llegaba a O5. Cada ciclo de diagnóstico: encender el stick, esperar el boot, conectar UART, ejecutar comandos, leer logs, volver a fallar de manera ligeramente distinta.
No es el tipo de problema que se resuelve con más horas. Se resuelve parando, documentando todo lo que ya se sabe, y volviendo fresco.
La respuesta estaba en un issue antiguo del repo: el kernel panic del europa_drv con el MC220L era específico a ese hardware. Conectado directamente al slot SFP+ del Ubiquiti, sin ningún intermediario, el driver inicializaba sin problema.
Había estado diagnosticando el problema equivocado. El MC220L nunca fue compatible con el MOD de stich86. El kernel panic lo enmascaraba todo lo demás.
Ventajas y desventajas: sin omitir lo incómodo
✓ Ventajas
Sin doble NAT: El router maneja PPPoE directamente. Control total sobre el tráfico, QoS y VLANs.
Sin hardware del ISP: El ONT de Entel desaparece de la ecuación física y lógica.
Dual WAN nativo: El slot SFP+ del Ubiquiti funciona como WAN con el stick, sin hardware adicional.
IPv4 + IPv6: Ambas funcionales desde el primer handshake con la OLT.
Sin overhead adicional: Sin NAT extra, sin latencia adicional de un segundo hop.
✗ Desventajas y riesgos
El proceso requiere UART y comandos U-Boot: No hay interfaz gráfica. Si no tienes experiencia con consola serie y bootloaders, la curva de entrada es real.
Un flash mal dirigido puede brick el stick: La recuperación existe (TFTP desde U-Boot) pero requiere que U-Boot siga respondiendo.
Spoofing de identidad: El stick se presenta ante la OLT como un dispositivo que no es. Entel no lo detecta actualmente, pero es lo que ocurre técnicamente.
Sin soporte del ISP: Si reportas problemas de conexión, Entel no tiene visibilidad del ONT real. El diagnóstico corre por tu cuenta.
Solo con slot SFP+ en el router: Si tu router no tiene SFP+, este approach no aplica directamente.
Actualizaciones de firmware del ISP: Entel puede actualizar remotamente los ONT Huawei activos. Si el modelo o versión que clonas queda desactualizado, puede haber problemas de autenticación futuros.
Glosario técnico
Próximos pasos (trabajo en progreso)
La solución funciona. El proceso es manual y requiere UART. Los planes para mejorar eso:
Firmware dedicado para el UF-Instant: Una WebUI donde puedas editar el SN, la MAC, los parámetros OMCI y las VLANs directamente, sin necesitar UART. El objetivo es que el proceso completo tome 10 minutos desde un navegador.
Documentar más ISPs: Entel Chile funciona. Movistar Chile usa una OLT diferente (posiblemente ZTE). Los parámetros de spoofing cambian entre vendors. Hay trabajo pendiente.
Si quieres colaborar, revisar el código o discutir el proceso, el Discord está abierto.
¿Te interesa un stick con el boot ya modificado?
Si quieres un UF-Instant con el firmware de stich86 ya instalado y listo para que solo configures los parámetros GPON de tu ONT, déjamelo saber en los comentarios. Tengo algunos disponibles. No prometo respuesta inmediata, pero sí respuesta.
💌 Agradecimientos Especiales
A una chica que, sin saberlo, me empujó a seguir creando y programando en mi tiempo libre. A quien alguna vez fue mi chispa: para “YLP”, con gratitud… y con cicatrices que también enseñan.
☕ Si este contenido te sirvió y quieres apoyar más trabajo como este: buymeacoffee.com/alpha018
¿Tu ISP también te negó el bridge mode? ¿Lo resolviste de otra manera, o todavía tienes ese módem ocupando espacio en tu rack?
Para quien tampoco aceptó el "no se puede" como respuesta final: este post existe porque me dijeron que no lo lograría. Y porque la fibra llega al router sin pasar por ningún equipo que no sea el mío. Nadie decide eso por mí.
🖕 Fuck you, Entel. Tus devs de pacotilla no me dicen qué conectar en mi propia red. Y tú, Movistar — estate quieta. Sé que usas ZTE y lo tengo en el radar.