
🌐 También en: English · Deutsch · Français
Todo homelab llega tarde o temprano al punto en que te quedas sin servidores que romper y empiezas a mirar de reojo al router. El mío es una FRITZ!Box 7690, ahí tranquila haciendo sus cosas de wifi e internet, nunca auditada de verdad, nunca cuestionada de verdad. Una noche pensé: ¿por qué no darle a Claude los datos de acceso y ver qué encuentra? Una regla, innegociable: mirar, no tocar. Ningún cambio, solo una inspección honesta.
Lo que salió fue más interesante de lo que esperaba – y respaldado por registros reales del router, no por corazonadas. 🧾
🔑 Entrar con educación
Primer detalle curioso: la FRITZ!Box nunca pide realmente la contraseña por la red – ni una sola vez. En lugar de «dime tu contraseña para que pueda comprobarla», juega a un pequeño juego de verificación: primero la caja envía una pieza de puzle aleatoria. La contraseña se mezcla con esa pieza, se revuelve decenas de miles de veces en un proceso deliberadamente lento, y solo se devuelve el resultado revuelto – nunca la contraseña en sí. La caja hace exactamente el mismo proceso por su lado con la contraseña que tiene guardada, y si ambos resultados coinciden, estás dentro.
La contraseña en sí no viaja por la red en ningún momento ni de ninguna forma. Incluso alguien conectado a la misma wifi capturando cada paquete solo vería la pieza del puzle y la respuesta revuelta – y a partir de ninguna de las dos se puede reconstruir la contraseña real. Tampoco hace falta un navegador para nada de esto – basta un poco de scripting que haga los mismos cálculos que haría un navegador. Friki, pero tranquilizador: el inicio de sesión en sí es sólido.
Una vez dentro, el backend de la interfaz web de la caja (data.lua) resultó ser una mina de oro – exactamente el mismo JSON que usa la propia interfaz de administración, solo que consultable directamente. Sin necesidad de ir haciendo clic por los menús. 😌
📶 Las tres cosas que vale la pena arreglar
Lo que pasa con los ajustes de wifi es que suenan abstractos hasta que los traduces a algo cotidiano. Así que aquí va la versión «explicado a mi amigo que no es informático» de lo que señaló Claude – y por qué.
1. La calle de 3 carriles (ancho de canal en 2,4 GHz)
Imagina la banda de 2,4 GHz como una calle estrecha con exactamente 3 carriles que no se solapan (canales 1, 6, 11 – todos los demás se solapan con alguno de ellos). Normalmente tu wifi usa un carril. Mi caja estaba configurada para coger dos carriles a la vez («40 MHz») para ganar velocidad – solo que, con 3 carriles en toda la calle, eso es casi toda la calzada, y la wifi de algún vecino está casi seguro aparcada también en uno de esos carriles.
Lo mejor: hay una función integrada de «sé educado» (coexistencia 20/40 MHz) que vuelve automáticamente a un solo carril cuando detecta a un vecino – y estaba desactivada. Así que la caja ocupaba dos carriles, chocaba igualmente con los vecinos y no recuperaba nada de la ventaja de velocidad prometida, porque las colisiones obligan a retransmitir y a bajar a velocidades de respaldo más lentas. Lo peor de ambos mundos. 🚗💥🚗
2. La autopista ancha con un control sorpresa (5 GHz, 160 MHz + DFS)
La banda de 5 GHz tiene muchos más carriles, así que la congestión con los vecinos no es realmente el problema ahí. Mi caja circulaba por la autopista más ancha posible – 160 MHz, 8 carriles agrupados, máxima velocidad teórica. Aunque con dos pegas: parte de ese espectro (canales 52–64) se comparte con radares meteorológicos y de aviación. Si la caja detecta un radar, tiene que abandonar ese canal inmediatamente, sin negociación – como una carretera que se corta en el acto para que pase una ambulancia. Y un canal tan ancho reparte la misma potencia de transmisión de forma más fina, lo que normalmente te cuesta algo de alcance y de capacidad para atravesar paredes en comparación con un canal más estrecho de 80 MHz.
No es que esté mal, exactamente – solo un compromiso entre velocidad y estabilidad que no sabía que había hecho.
3. La llave de repuesto debajo del felpudo (WPS)
WPS es el atajo de emparejamiento de «pulsas un botón en el router, pulsas un botón en el dispositivo, listo». Cómodo – como dejar una llave de repuesto debajo del felpudo para las visitas. La pega: hace unos años, unos investigadores encontraron un fallo en la forma de comprobar el PIN de WPS que permite descifrarlo mucho más rápido de lo que debería un PIN de 8 dígitos. Si no lo usas activamente para emparejar dispositivos nuevos, es una llave de repuesto bajo el felpudo sin ningún motivo.
📊 Pruebas, no corazonadas
Aquí es donde dejó de ser teórico. Claude sacó el registro del sistema de la propia FRITZ!Box – 1.088 entradas a lo largo de tres semanas – y resulta que en realidad tengo una pequeña red mesh (puntos de acceso en la planta baja, el 1.º y el 2.º piso, no una sola caja). Las cifras:
- 314 radares detectados en los canales DFS de 5 GHz (120–124), repartidos entre los dos AP de arriba, en tres semanas. Eso son aproximadamente 15 veces al día.
- 308 cambios de canal forzados como consecuencia directa e inmediata de esas detecciones de radar.
- 138 veces «detectada fuente de interferencia muy fuerte» en los canales 1 y 11 de 2,4 GHz – exactamente el problema de colisión con los vecinos del punto 1, registrado negro sobre blanco.
- 12 veces la lógica automática de calidad de la propia caja estuvo tan descontenta con las condiciones de 2,4 GHz que redujo por su cuenta el ancho de canal, en pleno funcionamiento.
Así que no era un «podría causar problemas en algún sitio, en teoría». Llevaba semanas pasando varias veces al día, en silencio, sin que yo notara nada más que algún que otro «vaya, la wifi ha ido lenta un segundo». 🤷
🎓 La moraleja (de momento)
Nada de esto tiene que ver con radiación, salud o «demasiada wifi» – el ancho de canal no tiene nada que ver con la potencia de transmisión, es puramente una cuestión de compartir espectro y de velocidad frente a estabilidad. Pero es un buen recordatorio de que «funciona perfectamente» y «está bien configurado de verdad» son dos afirmaciones muy distintas, y a veces solo descubres cuál es cierta apuntando una IA a los registros de tu propio router y pidiéndole que simplemente mire. 😅
🛠️ Actualización: ahora sí, a tocar los interruptores
De vuelta para el segundo asalto, esta vez con permiso para tocar. Resulta que el punto 1 escondía un giro de guion: la «interferencia del vecino» en el canal 1 no era de ningún vecino. Un escaneo nuevo del entorno wifi mostró cero redes de 2,4 GHz realmente ajenas cerca – cada «otra red» señalada llevaba el prefijo MAC del fabricante de mi propio router. Dos de mis cuatro radios mesh (caja principal más repetidores en tres plantas) se habían colocado discretamente en exactamente el mismo canal, chocando consigo mismas desde distintas plantas de la misma casa. Los vecinos eran inocentes desde el principio. 🤦
La solución acabó siendo más sencilla que el ajuste de coexistencia que había planeado: fijé manualmente el canal de 2,4 GHz en el 6, que estaba completamente vacío. El canal 1 ya no aparece como activo en la tabla de canales de la caja; el 6, sí. No es un reparto 1/6/11 perfectamente limpio entre las cuatro radios – el canal sigue teniendo 40 MHz de ancho, así que todavía invade un poco el espectro vecino –, pero es una mejora real frente a dos de mis propios AP compartiendo literalmente un canal.
WPS: desactivado por completo. Pequeña nota para ser precisos – lo que esta caja ofrece en realidad es WPS por Push-Button, no la versión basada en PIN con la debilidad ante fuerza bruta descrita arriba. El modo de botón necesita a alguien físicamente delante de la caja durante una ventana de emparejamiento activa, así que aquí nunca fue explotable a distancia. Desactivado de todos modos, simplemente porque ya no lo necesito.
🚧 El que se escapó
El punto 2 – estrechar esa autopista de 160 MHz a 80 – es donde esto deja de ser una historia de éxito redondita. Sabemos exactamente qué queremos cambiar. Solo que no encontramos ningún sitio donde cambiarlo.
Fuimos a buscar el ajuste, y aquí la cosa se vuelve realmente rara: el campo sigue estando ahí, sin duda. Leer los datos internos de la caja directamente desde su API muestra claramente ht160: active = true — el ajuste existe en el modelo de configuración, presente y en su sitio. Lo que no existe es forma alguna de llegar a él. Ni desde la interfaz web (ni escondido tras un interruptor de «vista avanzada», ni metido en una sección plegada – AVM ha eliminado discretamente de la interfaz todo control detallado del ancho de canal en las versiones recientes de FRITZ!OS), ni desde esa misma API: ese backend JSON te deja leer el campo sin problema, pero la parte de escritura – los parámetros exactos que necesitaría una petición de guardado para cambiarlo – no está documentada en ninguna parte, e incluso Claude, hurgando en los mismos endpoints que usa la propia interfaz web, no logró dar con una forma confirmada y segura de llamarlo. Adivinar parámetros POST no documentados contra un endpoint de guardado de configuración en producción parecía exactamente el peor sitio para improvisar – si te equivocas, no solo no cambias el ancho de canal, sino que te arriesgas a restablecer en silencio algún ajuste que no tiene nada que ver y que nunca quisiste tocar.
La única vía que sigue funcionando y que alguien ha encontrado es una herramienta de terceros que edita directamente el archivo de exportación en bruto de la configuración de la caja y lo vuelve a importar – y los relatos de la comunidad en los que eso salió mal (una configuración corrupta, sacada directamente de un hilo de un foro de soporte) son justo el tipo de riesgo que no merece la pena correr con un router del que depende toda la casa. Un hipo de la wifi, vale. Una caja que deja de responder por completo, no.
Así que, por ahora, este punto sigue sin resolver – no porque la solución en sí esté en duda, sino porque actualmente no hay ningún camino hasta ella que no implique más riesgo del que vale el ajuste. Archivado en «vigilar»: si una futura actualización de firmware recupera un control en la interfaz, o aparece una vía de API documentada y más segura, será lo primero que vuelva a revisar.
🍂 Mirando al futuro: FRITZ!OS 8.5 este otoño
Lo que, muy oportunamente, nos lleva al verdadero motivo para seguir atentos: hay prevista una actualización a FRITZ!OS 8.5 para otoño, y su función estrella es el bloqueo de anuncios y rastreadores al estilo Pi-hole integrado directamente en la caja. Ahora mismo, ese tipo de filtrado a nivel de DNS implica tener un dispositivo aparte en la red; tenerlo de forma nativa en el router que ya está en el centro de todo sería una simplificación realmente agradable. La temporada de actualizaciones de firmware es también la temporada de «a lo mejor el ajuste del ancho de canal vuelve discretamente» – más sobre ambas cosas en cuanto llegue de verdad la 8.5.





