El puente que hablaba el idioma de la PSP
Periodo narrado:* del 22 de agosto al 10 de septiembre de 2026
Hay proyectos que nacen para sostener una casa, custodiar documentos o asegurar la continuidad de servicios importantes. Y hay otros que empiezan porque una consola portátil fabricada hace dos décadas se niega, con toda la dignidad de su edad, a hablar el idioma de las redes modernas.
legacy-gw pertenece a esta segunda estirpe.
No nació de una necesidad crítica de Cerberon ni pretendía convertirse en una pieza esencial de Il Regno Mori. Fue, desde el comienzo, un divertimento: el deseo de que una vieja Sony PSP continuara siendo un objeto vivo y no una reliquia condenada a funcionar únicamente sin conexión. Pero los proyectos pequeños tienen una costumbre peligrosa: a veces esconden detrás de una pregunta inocente todo un tratado sobre compatibilidad, drivers, firmware, paciencia y el verdadero significado de conservar la tecnología.
La pregunta inicial parecía sencilla. La respuesta tardó diecinueve días.
22 de agosto: una pregunta desde otro tiempo
El 22 de agosto, L’Architetto planteó la posibilidad de crear desde un teléfono Android un punto de acceso con WPA. En realidad, detrás de aquella petición había una PSP cuyo hardware inalámbrico pertenece a una época en la que 802.11b, WEP y WPA con TKIP todavía formaban parte del paisaje cotidiano.
Android moderno ya había cerrado casi todas esas puertas. Sus interfaces habituales ofrecen WPA2 o WPA3, y aunque en otros tiempos algunos fabricantes permitieron WEP o WPA1, forzar hoy esa configuración exigiría root, modificaciones del sistema y una confianza excesiva en que el chipset del teléfono siguiera admitiendo algo que la industria lleva años tratando de retirar.
Entonces apareció una idea más atractiva: utilizar a Cerberon para
crear un punto de acceso deliberadamente antiguo. Una máquina virtual Linux
podría ejecutar hostapd, ofrecer DHCP, enrutar el tráfico y aislar la red débil
del resto de la casa. La inseguridad de WPA1 no se negaría ni se maquillaría; se
encerraría en un territorio propio, construido únicamente para los dispositivos
que la necesitaran.
La PSP no era, además, la única habitante prevista. Ocho días después, cuando el proyecto retomó forma concreta, apareció una segunda condición: la PSP debía poder comunicarse con una PlayStation 3 sin obligar a esta última a renunciar a su conexión rápida. La primera arquitectura imaginada separaba la red doméstica normal de una red legado y permitía únicamente los caminos necesarios entre ambas. Ya no se trataba sólo de conseguir Internet, sino de tender un puente controlado entre dos consolas.
30 de agosto: la compra del adaptador correcto que no era el adaptador correcto
El 30 de agosto, ocho días después del planteamiento inicial, el Cerberon estaba listo para comenzar las pruebas. La inspección reveló que no disponía de una interfaz inalámbrica adecuada, de modo que el proyecto necesitaba un adaptador USB capaz de trabajar como punto de acceso en 2,4 GHz y conservar compatibilidad con WEP o WPA1.
No servía comprar simplemente “un Wi-Fi USB”. En este caso, el chipset importaba mucho más que la marca, la velocidad anunciada o la generación comercial. La búsqueda condujo al Ralink RT5370, una pieza suficientemente antigua para tener sentido en este experimento y conocida por su relación con Linux, 802.11b/g y el modo AP. Ese mismo día, L’Architetto compró en Amazon un dispositivo anunciado expresamente como Ralink RT5370 USB WiFi Adapter (RT5370 WiFi Chipset).
Parecía una decisión conservadora. Cuatro días después descubriríamos que la etiqueta comercial y el silicio no siempre comparten la misma opinión.
3 de septiembre: llegó Ralink y respondió Realtek
El adaptador fue recibido el 3 de septiembre, cuatro días después de la compra,
y conectado a Cerberon. lsusb puso fin de inmediato a cualquier ilusión:
0bda:0179 Realtek Semiconductor Corp. RTL8188ETV
El supuesto RT5370 era en realidad un Realtek RTL8188ETV.
Podíamos haberlo devuelto y dado por terminado el episodio. Pero el dispositivo
ya estaba allí y Linux lo reconocía. Antes de descartarlo, había que preguntarle
a la infraestructura qué era capaz de hacer realmente. El driver automático
rtl8xxxu sólo anunciaba los modos managed y monitor; faltaba precisamente
el modo AP que justificaba toda la compra.
Comenzó entonces la primera excavación. Hubo que obtener las cabeceras exactas
del kernel 7.0.2-6-pve, corregir el acceso a los repositorios de Proxmox —las
fuentes Enterprise respondían con errores porque no existía suscripción— y
habilitar los repositorios comunitarios apropiados. Después compilamos un driver
8188eu externo. Aparecieron avisos de compatibilidad, diferencias de API y una
firma de función que el kernel moderno ya no aceptaba. El código fue examinado,
parcheado y recompilado.
Finalmente, iw list mostró lo que queríamos ver: AP y AP/VLAN.
Fue una victoria real, aunque sólo duró hasta la siguiente capa del problema.
4 de septiembre: nació legacy-gw
Durante la madrugada del 4 de septiembre, apenas unas horas después de conectar
el adaptador, diseñamos la máquina virtual dedicada. Primero fue una idea llamada
WEP/WPA1-GW; enseguida recibió el nombre que conservaría: legacy-gw.
La VMID 102 nació con Debian 13, una CPU, memoria modesta, una interfaz VirtIO
hacia la LAN y el USB Realtek entregado directamente a la máquina virtual. El
objetivo era mantener Proxmox limpio: el host sólo debía prestar el hardware; la
VM asumiría drivers, hostapd, DHCP, NAT y cualquier concesión necesaria al
pasado.
La instalación tampoco quiso ser invisible. El particionador declaró que no
podía satisfacer sus propias restricciones. La consola web de Proxmox no
permitía copiar y pegar. El usuario administrativo no pertenecía todavía a
sudoers. El agente QEMU respondió unas veces y otras no. Secure Boot rechazó
un módulo externo con un terminante Key was rejected by service. Cada pequeño
obstáculo fue resuelto: recreamos discos, ajustamos el arranque UEFI, quitamos
claves preinstaladas, recuperamos acceso por SSH y devolvimos al agente invitado
su capacidad de informar.
El primer driver compilado necesitó además adaptarse al kernel 6.12 de Debian 13.
Una firma de cfg80211_rtw_set_monitor_channel había cambiado; corregimos la
condición de versión, recompilamos y logramos cargar el módulo. La interfaz
wlx9c443d1c7b4a apareció y hostapd consiguió colocarla formalmente en modo
AP.
En los registros todo parecía alentador:
type AP
ssid Mori-Legacy-Test
txpower 13.00 dBm
En el aire, sin embargo, no había nada. Ni el móvil ni la PSP encontraban el SSID. Los contadores de transmisión permanecían en cero. El software afirmaba haber levantado un faro que no emitía una sola luz.
Un descenso por las capas del driver
Lo que siguió durante aquella madrugada fue una investigación cada vez más
profunda. Probamos el árbol rtl8188eus de Aircrack-ng; una primera carga terminó
con símbolos desconocidos. Recompilamos contra el kernel correcto, cambiamos
módulos, descargamos unos con rmmod porque modprobe aseguraba que no existían
aun cuando lsmod los mostraba, y encontramos más de una vez el frustrante:
insmod: ERROR: could not insert module ...: File exists
Luego recurrimos al repositorio histórico de Larry Finger, lwfinger/rtl8188eu,
que incluía su propia versión modificada de hostapd 2.9 y el backend
rtl871xdrv. Aquello parecía acercarnos al lenguaje nativo del RTL8188ETV, pero
trajo consigo nuevas incompatibilidades. El binario incluido no encontraba la
versión de OpenSSL de la distribución; hubo que recompilarlo. La configuración
rechazó ieee80211n porque aquella compilación no lo había habilitado. El canal
6 figuraba en la lista y, a la vez, era declarado no permitido para AP porque el
driver no rellenaba correctamente allowed_bw.
Corregimos esa estructura. El error del canal desapareció.
Entonces apareció otro:
ioctl[RTL_IOCTL_HOSTAPD]: Operation not supported
La pesquisa llegó hasta la tabla de handlers privados del driver. El índice
0x1C, reservado expresamente para hostapd, estaba asignado a NULL. Añadimos
un wrapper para entregar la llamada a rtw_hostapd_ioctl(), recompilamos de
nuevo el módulo y repetimos toda la ceremonia de descarga, carga y preparación
de la interfaz.
Esta vez ocurrió algo extraordinariamente prometedor:
AP-ENABLED
iwconfig decía Mode:Master. hostapd_cli decía state=ENABLED. El SSID tenía
nombre, canal y BSSID. La interfaz estaba UP, LOWER_UP. Habíamos descendido
desde la configuración de usuario hasta una ioctl privada del kernel y habíamos
cerrado un hueco real en el código.
Pero la red seguía sin aparecer.
El contador terminó contando la historia mejor que todas las declaraciones de estado: un paquete transmitido, 104 bytes. Un beacon cada cien milisegundos debería haber producido decenas o cientos de transmisiones; aquel único paquete era apenas el ademán de una radio que nunca empezó a anunciarse.
Tres Debian para una sola PSP
El kernel moderno continuaba siendo sospechoso. Puesto que legacy-gw sólo iba
a servir a dispositivos antiguos, no había obligación alguna de exigirle una
distribución contemporánea. Debian 13 cedió su lugar a Debian 12 y su kernel
6.1. Volvimos a compilar el módulo de 28 MiB, verificamos firmware, Wireless
Extensions y soporte AP, y repetimos las pruebas con nl80211 y
rtl871xdrv.
El resultado mejoró en apariencia y permaneció idéntico en esencia:
hostapd alcanzaba AP-ENABLED; la interfaz se declaraba Master; el SSID no
existía para ningún receptor.
Todavía dimos un paso más hacia atrás. La VMID 102 fue conservada como
legacy-gw-old y una nueva VMID 103 heredó el nombre legacy-gw. Instalamos
Debian 9 Stretch, sin repositorios funcionales al principio, con kernel 4.9 y
Wireless Extensions de la misma época que el driver Realtek. Hubo que desmontar
la ISO, retirar la entrada cdrom: de APT, apuntar a los repositorios archivados
y desactivar la validación temporal correspondiente. Hasta una comilla mal
cerrada convirtió 99archive en un archivo sintácticamente inválido. La consola
de Proxmox, sin capacidades para copiar y pegar, hizo que cada carácter importara más de lo
habitual.
Una vez recuperados los repositorios y el acceso SSH, compilamos otra vez
8188eu.ko; su vermagic coincidía exactamente con 4.9.0-13-amd64. Construimos
también hostapd v2.9 for Realtek rtl871xdrv. Probamos el driver estándar
r8188eu, el driver externo 8188eu, nl80211, las ioctl privadas y las
configuraciones de referencia incluidas en el propio proyecto.
En Debian 9, como en sus sucesores, el sistema podía afirmar:
interface state UNINITIALIZED->ENABLED
AP-ENABLED
Y la radio podía afirmar:
Mode:Master
ESSID:"Mori-Legacy-Test"
Pero los contadores apenas avanzaban y ningún dispositivo veía la red.
Habíamos probado kernels 6.12, 6.1 y 4.9; drivers nativos y externos; dos
interfaces de hostapd; parches en API de kernel, selección de canal y tablas
de ioctl; ahorro energético desactivado; IOL del firmware deshabilitado;
interfaces renombradas; canales 6 y 11; configuraciones mínimas y la configuración
de referencia de Realtek. Incluso verificamos que el adaptador podía escanear y
ver correctamente las redes vecinas. Recibía el mundo: sencillamente no lograba
anunciarse a él.
Llegó entonces una frase saludable: “Ya es demasiado trasteo.”
No fue una rendición. Fue el reconocimiento de que el propósito del experimento era conservar una PSP, no convertir un dongle mal etiquetado en una tesis doctoral sobre Wireless Extensions.
4 y 5 de septiembre: una solución nacida en la época correcta
El mismo 4 de septiembre apareció una alternativa mucho más acorde con el problema: un ASUS RT-N12 D1 usado, disponible por 10 euros más gastos de envío. Era un router 2,4 GHz de la generación adecuada, capaz de ofrecer modos b/g y WPA con TKIP sin pedir disculpas a ningún kernel moderno.
La fotografía de su etiqueta confirmó el dato esencial: H/W Ver. D1. El modelo exacto importaba porque las revisiones del RT-N12 no comparten siempre firmware ni procedimientos. El 5 de septiembre, un día después del hallazgo, el router ya estaba en camino.
La arquitectura también se simplificó. El ASUS tendría una WAN conectada a la red doméstica moderna y una LAN propia para los dispositivos antiguos. La PSP y la PS3 podrían habitar el mismo segmento cuando necesitaran comunicarse, mientras la red principal conservaría su seguridad actual. La debilidad de TKIP quedaría encerrada detrás de NAT y dedicada a un propósito concreto.
Parecía que la parte difícil había terminado. El router todavía no había llegado.
9 de septiembre: el router que sólo respondía a medias
El RT-N12 D1 fue recibido el 9 de septiembre, cuatro días después de quedar en
camino. Se conectó una notebook al puerto LAN 1, se dejó la WAN desconectada y se
realizó un restablecimiento de fábrica. El móvil veía una red abierta llamada
ASUS. Todo sugería que bastaría con visitar 192.168.1.1.
Pero la página no respondió. Tampoco router.asus.com.
Comenzó una investigación distinta, esta vez desde Windows y, durante los
momentos sin conectividad, desde Termux en el teléfono. La notebook recibió por
DHCP la dirección 192.168.1.231, máscara /24 y gateway 192.168.1.1. La
tabla ARP confirmó que esa dirección correspondía al ASUS: la MAC terminaba en
F8, coherente con la familia de direcciones de la etiqueta del equipo. El
enlace físico funcionaba y el router respondía en capa 2.
Sin embargo, no contestaba a ICMP. HTTP y HTTPS expiraban. Tampoco estaban abiertos SSH, Telnet, DNS, 81, 8080, 8443 ni 9999. Liberar y renovar la concesión demostró que el DHCP del propio ASUS seguía vivo, pero nada más parecía escuchar. Incluso un borrado completo mediante WPS dejó el mismo panorama.
El diagnóstico fue un soft brick parcial: el switch, la radio, ARP y DHCP arrancaban, pero el plano de administración no. No era el cable —probamos dos, uno recién comprado— ni la notebook. El firmware levantaba suficiente sistema para prometer que estaba vivo, pero no lo bastante para permitir que alguien lo administrara.
Así, después de haber escapado de tres kernels Linux y un driver obstinado, terminamos frente a otro firmware que también necesitaba ser rescatado.
La puerta de rescate
Descargamos el firmware oficial exacto para la revisión D1:
RT-N12_D1_3.0.0.4_380_8293-ge166eaae217.trx
El archivo medía 7.245.824 bytes. Instalamos ASUS Firmware Restoration para
Windows 10, compatible también con Windows 11, y configuramos temporalmente la
Ethernet de la notebook como 192.168.1.10/24, sin gateway ni DNS.
El primer intento de carga falló:
Failed to upload the firmware.
Please check the connection between your computer and router.
El LED de LAN estaba encendido y el de encendido parpadeaba como correspondía al modo Rescue. Los cables no eran el problema. En la notebook seguían existiendo varias rutas posibles: Wi-Fi, Tailscale y dos adaptadores virtuales de VMware. Los desactivamos, dejamos únicamente Ethernet, limpiamos ARP y repetimos la entrada al cargador de rescate manteniendo presionado Reset desde antes de alimentar el equipo.
Finalmente, Firmware Restoration encontró su destino y escribió la imagen.
El RT-N12 D1 volvió a arrancar completo. La interfaz web apareció. Lo que había llegado como un router usado y parcialmente bloqueado recuperó su firmware oficial sin abrir la carcasa, soldar pines ni recurrir a una consola serie. El bootloader, silenciosamente intacto durante todo el episodio, había conservado la última puerta.
10 de septiembre: Legacy-GW
En las primeras horas del 10 de septiembre, diecinueve días después de la pregunta inicial, el resto fue casi serenamente sencillo.
El ASUS recibió por su WAN la dirección 192.168.1.171 del router del proveedor
y quedó conectado a Internet. Su LAN pasó a 192.168.2.1/24, separada de la red
doméstica. La red inalámbrica fue configurada con parámetros que hoy parecen
arqueología, pero que la PSP reconoce como su lengua materna:
- SSID
Legacy-GW; - modo
Legacy, con protección b/g; - canal 10;
- WPA-Personal;
- cifrado TKIP;
- rotación de clave cada 3600 segundos.
Al seleccionar TKIP, el propio firmware desactivó WPS. Era una combinación deliberadamente antigua y deliberadamente contenida. No debía convertirse en la red habitual de la casa; debía existir para que unos pocos dispositivos pudieran atravesar el tiempo.
La PSP inició un escaneo.
Esta vez, el SSID apareció.
Aceptó la clave. Obtuvo una dirección. Alcanzó Internet. Y entonces hizo algo
mucho más elocuente que cualquier AP-ENABLED: encontró y descargó su propia
actualización oficial.
Durante noches enteras habíamos visto interfaces que aseguraban estar en modo Master, demonios que declaraban el punto de acceso habilitado y contadores que se negaban a transmitir más de 104 bytes. La comprobación final no fue una línea de log. Fue una PSP real, sobre una mesa, mostrando en su pantalla que estaba conectada y preparada para instalar una nueva versión.
Lo que quedó al otro lado del puente
El experimento no demostró que todo problema merezca diecinueve días de trabajo. Demostró algo más útil: que conservar tecnología antigua exige respetar la época en la que fue construida. A veces puede levantarse un puente nuevo con software; otras veces el camino más sensato es recuperar una pieza contemporánea al dispositivo y darle un lugar seguro dentro de la arquitectura actual.
El intento con el RTL8188ETV no fue inútil. Reveló una falsa identificación
comercial, expuso los límites reales de rtl8xxxu, obligó a comprender la
relación entre cfg80211, Wireless Extensions, nl80211, rtl871xdrv, las
ioctl privadas y la emisión de beacons. También dejó una lección esencial: que
un estado declarado no sustituye a una observación física. AP-ENABLED no
significa que haya un punto de acceso si ningún receptor puede verlo y los
contadores no se mueven.
La recuperación del ASUS añadió otra enseñanza. Un equipo puede parecer muerto en las capas visibles y conservar, debajo de ellas, un mecanismo elemental de rescate. Inspeccionar antes de descartar permitió distinguir un fallo de firmware de un fallo físico y devolver a la vida no sólo una PSP, sino también el router que debía ayudarla.
Queda todavía una comprobación pendiente: conectar la PS3 al mismo ASUS y verificar la comunicación efectiva entre ambas consolas. No debe presentarse como logrado aquello que aún no hemos probado. Pero el objetivo que puso en marcha toda esta historia sí está cumplido: la PSP vuelve a entrar en Internet sin debilitar la red principal y sin exigir que el presente renuncie a sus propias protecciones.
legacy-gw no es una infraestructura crítica. Es algo quizá más entrañable: una
pequeña puerta lateral de Mori, construida para que los objetos que todavía
tienen algo que ofrecer no queden fuera del bosque sólo porque hablan una lengua
antigua.
Al final, el proyecto no consistió en obligar a la PSP a hacerse moderna.
Consistió en que el presente aprendiera, por un momento, a hablar con ella.