Estás recorriendo una tienda de segunda mano y te encuentras un router viejo en diez dólares. Sin valor, ¿no? Pero en este caso era un Google OnHub, que en su momento fue bastante premium y todavía no es algo para descartar a la ligera. Claro, Google lo abandonó hace tiempo y corre Chrome, así que paso, ¿verdad? Por supuesto que no. De hecho, compré dos por menos de 20 dólares. La pregunta siempre es la misma: ¿qué hacer con esto?
OpenWrt corre en el dispositivo. Es un buen comienzo, pero solo cambiar el firmware no es mucho proyecto. La pregunta más interesante es si el hardware todavía puede hacer algo útil. Tenía una necesidad específica: conectar un workstation por cable a una red WiFi razonablemente distante sin tirar cable Ethernet y sin sufrir los típicos dolores de cabeza del double-NAT que aparecen cuando convertís el router en otra subred más. Para esto, el OnHub resultó casi perfecto.
El hardware
El OnHub fue el primer router WiFi de Google, fabricado por TP-Link y ASUS en versiones distintas. El mío era el modelo TP-Link, con un poco de plástico del cobertor faltando. Bajo el capó tiene un Qualcomm IPQ8064 dual-core, un ARMv7 de dos núcleos, varias radios, gigabit Ethernet y memoria suficiente para correr OpenWrt cómodamente: 1 GB de RAM y 4 GB de flash. El procesador también tiene dos network offload processors, aunque no es claro que el build estándar de OpenWrt los use.
Estos equipos eran caros cuando nuevos, pero hoy aparecen regularmente en tiendas de segunda mano y remates de excedentes. Instalar OpenWrt fue directo. Hay que sacar un tornillo que cubre el "magic switch" en el fondo, pero no es gran problema. Podés simplemente despegar la pata de goma si no querés removerlo. Lo interesante vino después.
Acá está lo que Google decía en su momento sobre el equipo, aunque podés preferir un teardown completo.
El objetivo
El objetivo era engañosamente simple. Quería conectar el OnHub a mi red WiFi y tener uno o dos puertos Ethernet. No quería repetir WiFi a WiFi porque es notoriamente lento. También quería que los PCs conectados por Ethernet "se sintieran" en la red principal, no en alguna subred NAT'eada. Eso significa que el OnHub tenía que reenviar DHCP además del tráfico normal de forma transparente.
El caso de querer rebroadcast inalámbrico a otra red inalámbrica es fácil pero lento. Otro caso fácil es crear una nueva subred y dejar que el router maneje tráfico entre vos y el router principal, igual que tu router normal rutea tráfico hacia Internet. Pero tener double-NAT es ineficiente y muy poco práctico. El port forwarding es un dolor. El descubrimiento de dispositivos se complica. Lo que realmente quería era un puente cableado a inalámbrico.
Aparece relayd
OpenWrt provee un paquete llamado relayd que crea esencialmente un pseudo-bridge entre una interfaz cliente inalámbrica y una LAN cableada. Digo "pseudo" porque un bridge real de Capa 2 no es posible con la mayoría de los modos cliente de WiFi. En cambio, relayd realiza una colección de trucos que involucran proxy ARP, DHCP relaying y packet forwarding para crear la ilusión de que todo está en la misma red.
Cuando funciona, funciona sorprendentemente bien. La configuración por defecto tenía una interfaz LAN, una WWAN, una WAN y una WAN6. Para mis propósitos, quería conectar la WiFi normal a WWAN y dejar la LAN en una subred distinta de mi 192.168.1.x principal. Configuré la LAN a 192.168.10.1 y forcé el DNS a 8.8.8.8 para que el router pudiera acceder a Internet temporalmente a través de WWAN, que era la única con un DNS server entregado por el router principal. También le indiqué a la LAN que dejara de repartir direcciones DHCP. Eso significó que, temporalmente, tuve que forzar mi PC a 192.168.10.2 para poder hablarle al router.
La razón de toda esta configuración es que relayd no viene instalado por defecto, así que usé el gestor de paquetes del router para instalarlo junto con otros útiles. Podés usar opkg desde la línea de comandos o la interfaz web LuCI. Para eso, la LAN necesitaba acceso a Internet y resolución DNS.
Una vez instalado, es bastante fácil crear una interfaz relay. La mayoría de los settings por defecto estaban bien; solo tuve que indicarle que puenteara LAN: y WWAN:. Sin embargo, hay un campo "Local IPv4 address" que se supone te da un escape para hablarle al router, porque una vez que el bridge funciona ya no podés volver a la red 192.168.10.x.
Esta dirección IP es la que el relay reconoce como no enrutable. Sin embargo, no la encontré confiable. Mi primer intento fue modificar el DHCP del router principal para que dejara de repartir direcciones por encima de .250. Eso me daría algunas IPs sin riesgo de conflicto, y elegí 192.168.1.252.
A veces funcionaba. A veces no. Nunca descifré por qué. En cambio, simplemente creé una interfaz de IP estática para 192.168.1.252. Eso fue suficiente para asegurar que siempre pudiera acceder al OnHub vía esa dirección. Hay una pega, eso sí. No querés que ningún otro tráfico vaya por ahí, así que es importante configurar esa interfaz con 192.168.1.252 y máscara 255.255.255.255. En otras palabras, esa interfaz es SOLO para esa dirección.
El workstation recibió una dirección del router principal y podía comunicarse normalmente con dispositivos en otros puntos de la red. Al menos para IPv4.
¿Y qué pasa con IPv6?
Noté que mi workstation solo estaba recibiendo dirección IPv4, pero generalmente obtiene IPv4 e IPv6. En la práctica no importaba, pero quería entender qué pasaba. Después de varios packet captures, me di cuenta de que además de la interfaz WWAN por defecto, necesitaba una interfaz WWAN6 que usara DHCPv6. Esto era análogo a la interfaz WAN6 por defecto que no estaba usando.
También tuve que modificar la configuración del servidor DHCP IPv6 en WWAN y LAN aunque tenía el servidor DHCP apagado. En particular, la interfaz WWAN6 se volvió el "designated master", y tanto WWAN6 como LAN tenían todas las modalidades IPv6 configuradas en "relay mode" para que pasaran el tráfico de setup desde la red principal a la red subordinada.
Al principio no funcionaba. Resultó que había creado una interfaz WWAN6 para IPv6, pero esa interfaz no estaba asignada a la zona de firewall WAN. Apenas WWAN6 se agregó a la zona WAN, todo empezó a funcionar.
El resultado
¿Puede un router de hace una década seguir siendo útil? Sorprendentemente, sí.
La conexión inalámbrica negoció alrededor de 700 Mbps de PHY rate usando canales de 80 MHz contra un router TP-Link WiFi 7. El throughput real fue cerca de 250 Mbps. No es performance récord, pero es más que adecuado para web browsing, SSH, desarrollo remoto, backups y uso general de red. También fue mucho mejor que el WiFi de la motherboard o varios adaptadores USB.
Hubo algunos tweaks. Uno pensaría que habilitar packet steering debería mejorar performance distribuyendo trabajo entre CPUs. En este hardware, aumentó el jitter notoriamente. Deshabilitarlo produjo latencia más consistente con poco impacto en throughput.
Después de bastante debugging, el sistema final funcionaba. Por supuesto, tuve que seguir. Borré interfaces no usadas y agregué un montón de extras de OpenWrt como minidlna y tailscale. El servidor minidlna planteó algunos problemas pequeños.
Conectar minidlna a la LAN hizo que anunciara una dirección 192.168.10.x que, por supuesto, era inalcanzable. Conectarlo a WWAN funcionó mejor. De nuevo, tcpdump es tu amigo. El otro problema es que si hay un USB stick conectado al encender, intenta bootear desde él. Todavía estoy resolviéndolo. En cuanto a tailscale, asegurate de apagar el DNS de tailscale o lo vas a lamentar. También ocultó los servidores DLNA de la red, así que arreglarlo queda para otro día.
Como referencia, esa fue mi lista final de interfaces. La moraleja: la próxima vez que veas un router abandonado en una tienda de segunda mano, no preguntes solo si OpenWrt corre en él. Pregunta qué problema puede resolver. A la segunda unidad pienso convertirla en un setup usbip.
