Publicado: 2024-07-19 (actualizado 2024-08-02)
Etiquetas: Linux, Self-hosting
En este artículo voy a contar cómo me puse a montar un servidor casero y terminé investigando porqué el wifi de algunos de mis ordenadores parecía ir extremadamente lento. Al final era una tontería pero pasé una semana investigando, probando cosas y aprendiendo.
Hace un mes aproximadamente compré un miniordenador Slimbook Zero. Slimbook es una empresa de Valencia especializada en ordenadores para Linux. Supongo que empezaron vendiendo portátiles y por eso tienen book en el nombre. Ahora tienen un poco de todo. Ya llevaba un tiempo pensando en actualizar la Raspberry a algo más potente y vi que tenían Slimbook Zero de oferta. Este modelo es un ordenador minúsculo (aunque 2 o 3 veces más grande que la Pi), que consume poco y es silencioso porque no necesita ventiladores. "Designed in Spain. Made in China" pone en la caja.
Yo lo elegí con Debian 12 Bookworm preinstalado. El día que me llegó lo estuve probando un poco enchufado al monitor. Cuando ya comprobé que funcionaba bien le instalé el mismo Debian desde cero. No creo que hubiera nada malo pero me parecía más seguro hacerlo yo todo desde cero porque no sabía qué habían tocado antes de enviarlo. Así fue como empezaron mis "problemas" con el wifi.
Una vez instalado Debian desconecté el Slimbook Zero del monitor y me puse a trabajar con él remotamente por SSH. Noté inmediatamente que había un pequeño retardo al escribir los comandos en la terminal. No era mucho pero se notaba. Me propuse llegar hasta el fondo del problema porque no sabía si era un fallo de hardware o de mi wifi y si tenía que devolver la Slimbook tenía que hacerlo rápido. Spoiler: no era problema de Slimbook Zero ni del wifi.
La conexión SSH iba perfectamente desde mi portátil a la Raspberry Pi pero tenía un pequeño retardo desde mi portátil al Slimbook Zero. Estando este último justo al lado del portátil, siendo más potente que Pi y además teniendo unas antenas bastante grandes no tenía mucho sentido.
Estuve buscando alguna forma de medir la latencia del SSH pero todas las opciones que vi requerían instalar cosas y a mí no me gusta nada instalar paquetes. Al final, alguien de Mastodon mencionó ping y caí en la cuenta de que podía medir el retardo con ese comando que para eso está.
Desde mi portátil (Ubuntu, arquitectura Intel) el ping a Raspberry Pi 4B (Debian, ARM) era de 6.7 milisegundos de media mientras que a Slimbook Zero (Debian, Intel) era de unos 264 milisegundos de media muy inestables. Aquí noté una cosa rara: desde Slimbook si había ping a Raspberry Pi la respuesta era también de unos pocos milisegundos pero si lo hacía al reves el ping era elevadísimo. Algo muy raro.
Por si acaso fuera un problema de Debian decidí instalar Ubuntu ya que estoy más familiarizado con este último. Por supuesto, el ping elevado seguía presente. En ese momento mi hipótesis era que el wifi tenía algún problema. Probé a mover el miniordenador cerca del router y lo conecté con cable de red. El ping ahora era muy bueno pero mi intención era configurar el sistema y luego dejarlo en el trastero junto a la Raspberry Pi por lo que no quería depender de cables. Lo volví a poner con wifi y seguí investigando.
Por curiosidad, me puse a medir tiempos de respuesta entre los 3 ordenadores que tengo en la red local. Envié unos 30 paquetes ping y anoté el tiempo medio de respuesta. En el siguiente diagrama se pueden ver los resultados.
Gracias a este diagrama me di cuenta de algo: ¡el problema del ping elevado también le ocurría a mi portátil! El ping de la Raspberry al portátil era muy elevado mientras que al revés era casi inexistente. Nunca lo había probado así que no me había dado cuenta. En todo caso esto era una prueba más de que el problema no estaba en el nuevo Slimbook Zero.
¿Era algo del hardware? Los dos ordenadores "lentos" tenían CPU Intel aunque uno era i7 y el otro i5.
El portátil tiene Windows 10 instalado aunque no lo use nunca. Reinicié y probé a hacer ping. No respondía. Resulta que Windows no responde al ping en su instalación por defecto. Hay que configurar el Windows Defender antes según una guía que encontré. Windows 10 sí que respondía bien al ping. No había 300ms de retardo como con Ubuntu. Eso descartaba que fuera un problema del hardware del portátil o del wifi.
No tenía ningún Windows para instalarlo en el Slimbook Zero pero sí que tenía descargada una imagen de instalación de FreeBSD 14.1 que quería probar en una máquina virtual. Hace 20 años FreeBSD era el sistema que más usaba por encima de Linux y me gusta bastante. Al instalarlo y probar a hacer tanto ping como SSH pasó lo mismo que con Windows: funcionaba a la perfección. ¿Tenía Linux algún problemas con los drivers para tarjetas de red que no ocurría en Windows o FreeBSD? Eso era absurdo. Quizá podría ir mejor en Windows pero que FreeBSD tuviera mejor soporte que Linux era imposible.
Estuve unas cuantas horas comparando el Linux de Raspberry Pi que funcionaba bien con el del portátil que tenía mucho retardo al responder al ping.
Ya hacía días que había descartado que fuera cosa del firewall. No había ningún firewall activo en los sistemas que funcionaban mal. Llegó el momento de inspeccionar el Linux a fondo para intentar averiguar qué ocurría.
Raspberry tenía un kernel 6.1 algo antiguo. Le había ido instalando actualizaciones pero no lo había reiniciado en casi un año así que seguía con esa versión. Mi portátil tenía un kernel más reciente: 6.5. Descargué esa misma versión del kernel, reinicié el portátil y la inicié con GRUB pero el problema del ping seguía ahí. No entiendo mucho de drivers en Linux pero no parecía haber ningún driver alternativo para mi wifi.
El siguiente paso fue comparar la configuración del kernel. Linux expone un montón de información interna en el directorio /proc/. En concreto en /proc/sys/net/ se puede ver la configuración del hardware de red. Por ejemplo, ¿qué puertos puede abrir un proceso que no es root? Con el siguiente comando podemos ver que sin ser root solo podemos abrir puertos más altos de 1024.
$ cat /proc/sys/net/ipv4/ip_unprivileged_port_start
1024
Comparé los cientos de valores de configuración del kernel entre los dos sistemas. Las únicas diferencias eran el tamaño de algunos buffers pero no parecía importante.
Durante las noches en las que estuve investigando los problemas de latencia iba escribiendo mis descubrimientos en Mastodon y comentándolo con algunos amigos con las esperanza de que alguien supiera qué pasaba. Mensajes poco útiles que me indicaban comprobar cosas que ya había mirado como el firewall o que me sugerían conectarlo por cable y pasar del wifi.
En una de mis tantas pruebas con el comando ping me di cuenta de algo que había estado allí desde el principio y que había pasado por alto: el primer paquete del ping siempre tenía latencia muy baja y los siguientes muy alta.
Este es un ejemplo. El primer ping tarda 3.11ms, los siguientes 40 veces más.
$ ping 192.168.0.15
PING 192.168.0.15 (192.168.0.15) 56(84) bytes of data.
64 bytes from 192.168.0.15: icmp_seq=1 ttl=64 time=3.11 ms
64 bytes from 192.168.0.15: icmp_seq=2 ttl=64 time=115 ms
64 bytes from 192.168.0.15: icmp_seq=3 ttl=64 time=138 ms
64 bytes from 192.168.0.15: icmp_seq=4 ttl=64 time=160 ms
Si en vez de dejar que ping hiciera peticiones continuamente era yo el que llamaba repetidamente a ping cada vez enviando un paquete la latencia siempre era baja.
$ ping -c 1 192.168.0.15
PING 192.168.0.15 (192.168.0.15) 56(84) bytes of data.
64 bytes from 192.168.0.15: icmp_seq=1 ttl=64 time=2.92 ms
--- 192.168.0.15 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.916/2.916/2.916/0.000 ms
$ ping -c 1 192.168.0.15
PING 192.168.0.15 (192.168.0.15) 56(84) bytes of data.
64 bytes from 192.168.0.15: icmp_seq=1 ttl=64 time=3.45 ms
--- 192.168.0.15 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.445/3.445/3.445/0.000 ms
Que cosa más rara. La conexión iba bien al principio pero a partir del segundo paquete se degradaba.
Este último descubrimiento parece que encendió la bombilla de un amigo con el que había comentado la situación y dijo que seguramente el tiempo de respuesta era más alto a partir del segundo paquete porque, para ahorrar energía, el chip del wifi se quedaba en espera durante un momento antes de procesar nuevos paquetes.
Los chips para wifi de Intel tienen un modo de ahorro de energía que llaman Power Management. Al estar usando un portátil y a pesar de que está conectado a la luz el 100% del tiempo, el Network Manager había activado esa opción. Se puede comprobar usando el comando iwconfig. Si aparece la frase Power Management:on el chip procesará las conexiones entrantes un poco más lentamente para que la batería dure más.
El Slimbook Zero no es un portátil pero supongo que, por el hardware que usa, Network Manager pensaba que era un dispositivo portátil y también le activó el modo ahorro. Tras desactivar este modo, por fin pude empezar a montar los servicios que quería en mi nuevo servidor casero.
He escrito una guía que va más al grano sobre cómo ver si tienes el power management activado y cómo apagarlo temporal o definitivamente.
Algo tan simple como el modo ahorro de energía del wifi me tuvo varios días investigando. Por un lado me alegra que no me rendí conectado el ordenador con cable y decidí llegar al fondo del asunto. He aprendido bastante en el proceso. Quizá si hubiera sabido expresar el problema de una mejor manera hubiera conseguido encontrar la solución antes (o quizá no porque parece que buscadores como Google han empeorado mucho sus resultados en los últimos años).