Qué hacer si tras una actualización de Linux el WiFi deja de funcionar

Cuando instalas una actualización en tu distribución GNU/Linux y, de repente, el WiFi desaparece o se niega a conectar, la sensación es de puro drama: el portátil funcionaba perfecto el día anterior, aceptas lo que te sugiere el gestor de actualizaciones, reinicias y… adiós conexión inalámbrica. Toca tirar de cable Ethernet, del móvil o directamente quedarse sin internet en esa máquina.

Lo bueno es que, aunque asuste, la mayoría de fallos de WiFi tras una actualización tienen solución sin tener que reinstalar el sistema desde cero. A partir de varios casos reales en Linux Mint, Ubuntu, Fedora y otros sabores, vamos a desgranar qué suele romperse exactamente (kernel, controladores, gestor de red, parámetros del sistema…) y cómo puedes ir atacando cada posible causa de forma ordenada.

Por qué el WiFi se rompe tras actualizar Linux

En muchos equipos, las cosas van rodando durante meses hasta que, un día, aceptas una actualización que incluye un kernel nuevo o paquetes de gráficos y ahí empieza la fiesta. Un usuario de Linux Mint, por ejemplo, llevaba un año con su portátil sin problemas, aplicando lo que salía en el gestor de actualizaciones. Después de un paquete que mencionaba algo de “gráficos”, al reiniciar se encontró con que la red inalámbrica había desaparecido de la práctica.

El síntoma más común es que el sistema “ve” la red (o incluso todas las redes disponibles) pero no logra establecer la conexión. A veces sigue recordando el nombre de tu WiFi doméstica, otras aparece el icono de red pero sin posibilidad de escanear redes, y en otros casos más extremos el icono de WiFi desaparece por completo de la bandeja del sistema.

En Linux Mint Cinnamon 21.1 se ha dado el típico escenario en el que, tras actualizar al kernel 5.15.0-164-generic, primero fallan los gráficos (pantalla llena de líneas de colores) y después el WiFi deja de funcionar. Arrancando con un kernel anterior, como el 5.15.0-56-generic, todo vuelve a la normalidad: imagen y WiFi operativos. Eso ya es una pista clarísima de que el problema viene ligado al kernel nuevo, bien por el driver de red, bien por algún módulo relacionado.

En Ubuntu también se han visto casos donde, después de pasar de una versión a otra (por ejemplo de Ubuntu 16.10 a 17.04), las redes aparecen en el applet de NetworkManager, intenta autenticarse con la red de siempre y acto seguido se desconecta sin dar mucha explicación. Ni es un problema de contraseña mal escrita ni de hardware estropeado, sino de cómo está gestionando la autenticación el sistema tras el cambio de versión.

En otros equipos, sobre todo con adaptadores USB WiFi basados en ciertos chipsets Realtek, como un Guillemot Hercules HWNUm-300 Wireless N mini (chip RTL8191SU con driver r8712u), lo que ocurre es que tras la actualización el dispositivo sigue estando listado, pero el icono de WiFi en la barra de tareas se esfuma y te quedas sin internet inalámbrico. El sistema ve el USB (inxi muestra el dispositivo perfectamente), pero la capa de red de escritorio decide que ahí no hay nada que gestionar.

Comprobar si el hardware WiFi sigue siendo detectado

Antes de entrar en cambios más profundos, lo primero es verificar si la tarjeta inalámbrica sigue siendo reconocida por el sistema. Si el adaptador no aparece en absoluto, la cosa apunta a un driver ausente o roto; si sí aparece, seguramente el problema esté en la autenticación, región WiFi, gestor de red o configuración.

Para un diagnóstico básico puedes tirar de herramientas clásicas de red. En muchas guías todavía se ve ifconfig para listar interfaces y iwconfig para ver el estado de las interfaces inalámbricas. Aunque ifconfig esté algo deprecado en favor de ip, sigue siendo útil para comprobar, por ejemplo, si aparece una interfaz tipo wlan0, wlp2s0 o similar y si tiene dirección IP.

Con iwconfig puedes ver si el adaptador WiFi está activo, el modo en que funciona (Managed, Monitor, etc.) y si está asociado a alguna red. En los casos comentados, la interfaz inalámbrica aparecía viva y coleando, con nombre del estilo wlx00805a4dfde6, así que no era un problema de tarjeta inexistente, sino de que no conseguía enlazar con el punto de acceso.

Si quieres una vista más completa y moderna, herramientas como inxi con parámetros detallados (por ejemplo inxi -zv8) muestran el adaptador, el driver en uso, el tipo de bus (USB, PCI), velocidad, estado de la interfaz y servicios relacionados como NetworkManager o wpa_supplicant. En el ejemplo del Hercules HWNUm-300 se veía claramente el driver r8712u cargado, la interfaz en estado “up” y los servicios de red activos, lo que subraya que el problema no era tanto de detección como de gestión.

Si en tu caso no se detecta la tarjeta inalámbrica en absoluto, es muy posible que el kernel que has instalado ya no traiga el módulo necesario, o que el módulo se haya deshabilitado. Ahí ya entrarías en terreno de instalar drivers adicionales, recompilar módulos o, según tu distribución (Ubuntu, Fedora, Arch, openSUSE, etc.), recurrir al método específico para buscar controladores propietarios o de la comunidad.

Mirar los mensajes del sistema: qué dice dmesg del WiFi

Cuando el hardware se ve pero la conexión falla en la fase de autenticación, el registro de mensajes del kernel es tu mejor amigo. Ejecutar dmesg tras intentar conectarte a la WiFi puede revelar mensajes muy concretos sobre lo que está yendo mal.

En un caso de Ubuntu tras actualizar de 16.10 a 17.04, al revisar dmesg destacaban dos tipos de mensajes: errores relacionados con IPv6 al intentar enlazar la interfaz de red y una línea del estilo “aborting authentication with xx:xx:xx:xx:xx:xx by local choice (Reason: 3=DEAUTH_LEAVING)”. Este mensaje indica que el propio sistema está abortando el proceso de autenticación con el punto de acceso, lo que suele apuntar a problemas de parámetros de red o a cómo interactúa NetworkManager con el driver o con wpa_supplicant.

Ese tipo de pistas te permite acotar muchísimo: si ves errores de IPv6 o mensajes de desautenticación por “local choice”, puedes centrarte en desactivar IPv6, revisar la configuración de país/región WiFi o incluso probar un gestor de conexiones distinto que trate mejor la negociación.

También puede suceder que el log muestre advertencias de que la región regulatoria es genérica (país 00) y no específica, o que hay canales o potencias que no se pueden usar. Todo eso influye en qué canales ve tu tarjeta, cómo se comporta al escanear redes y, en ocasiones, en si consigue o no finalizar la autenticación con el router.

Conviene que, tras cada cambio que pruebes (desactivar IPv6, cambiar región, cambiar de gestor de red, etc.), vuelvas a lanzar dmesg para ver si los mensajes de error cambian. A veces desaparece un error pero aparece otro distinto, lo que te da una hoja de ruta de por dónde seguir mirando.

Desactivar IPv6 cuando da problemas con la conexión WiFi

IPv6 debería convivir con IPv4 sin dar guerra, pero en la práctica hay redes domésticas y combinaciones de router + distribución Linux donde IPv6 provoca inestabilidades. En el caso de Ubuntu que comentábamos, en el registro se veía claramente que el sistema intentaba enlazar la interfaz usando IPv6 y fracasaba, mientras que en IPv4 la red hubiera funcionado de sobra.

Antes de desactivar nada conviene comprobar si el soporte IPv6 está activo en tu kernel. Un comando sencillo como test -f /proc/net/if_inet6 && echo «Running kernel is IPv6 ready» te dirá si el kernel está preparado para IPv6. Si al ejecutarlo ves ese mensaje, significa que IPv6 está habilitado y en uso.

Si sospechas que IPv6 está detrás del problema y no usas IPv6 en tu red local (algo muy habitual), puedes optar por deshabilitar IPv6 a nivel de kernel. Una forma clásica es editar el archivo /etc/sysctl.conf y añadir las líneas correspondientes para desactivar IPv6 globalmente. Después, aplicas los cambios al vuelo con sysctl -p, y si vuelves a ejecutar el test anterior ya no deberías ver el mensaje de “IPv6 ready”.

Para que el ajuste sobreviva a los reinicios, muchos usuarios también tocan el archivo /etc/default/grub añadiendo el parámetro ipv6.disable=1 a la línea GRUB_CMDLINE_LINUX_DEFAULT. Tras guardar, hay que actualizar el cargador con update-grub y reiniciar. A partir de ahí, IPv6 quedaría completamente fuera de juego y solo se usaría IPv4 en las conexiones. Si necesitas configurar IP manualmente consulta cómo asignar IP estática en Linux.

En el caso concreto que nos sirve de ejemplo, desactivar IPv6 no terminó de resolver el fallo de WiFi, pero sí eliminó parte de los mensajes de error de dmesg. Es decir, a veces quitar IPv6 es suficiente para que la red se estabilice; en otras, simplemente te quita ruido del log y te ayuda a ver el siguiente problema real que hay que atacar.

Ajustar la región WiFi (CRDA) para tu país

Otro factor que pasa bastante desapercibido y que puede liarla tras una actualización es la configuración de país o región regulatoria del WiFi. Cada estado impone límites sobre qué canales y potencias se pueden utilizar, y el kernel Linux respeta esas normas mediante una especie de “código de país” que aplica restricciones al driver inalámbrico.

Si esa región se queda en un valor genérico, como el famoso “00”, tu tarjeta puede verse limitada en canales o potencia, lo que en algunos casos provoca que la autenticación con ciertos routers falle o sea muy inestable. Es algo que se ha visto tras actualizaciones de sistema donde, de repente, la configuración de país se pierde y vuelve al valor genérico.

Para comprobar la región actual puedes usar iw reg get y fijarte en el código de país que aparece. Si en lugar de ver “ES” (España), “FR” (Francia) o el que corresponda, aparece “00”, es buena idea probar a fijar la región adecuada de forma explícita.

Desde terminal, un paso inicial es ejecutar, por ejemplo, sudo iw reg set ES para establecer España como país regulatorio. Tras esto, puedes intentar reconectar al WiFi para ver si mejora el comportamiento. En el caso citado, aun así la conexión seguía sin establecerse, pero es un ajuste que conviene dejar bien puesto igualmente.

Para que esa región se mantenga tras los reinicios, puedes hacer el cambio permanente editando el archivo /etc/default/crda e indicando el código de país adecuado en la variable que corresponde. Así, aunque haya futuras actualizaciones de kernel o de tools de red, el sistema sabrá de antemano qué límites aplicar a tu tarjeta.

Cambiar de gestor de red: de NetworkManager a wicd

Ubuntu, Linux Mint y muchas otras distros modernas utilizan NetworkManager como pieza central para gestionar conexiones (cable, WiFi, VPN, etc.). Normalmente funciona muy bien, se integra con el escritorio y ofrece un icono muy cómodo en la bandeja del sistema. Pero también es cierto que en los foros abundan casos donde NetworkManager y ciertos drivers WiFi no se llevan del todo bien.

En uno de los escenarios descritos, después de probar con IPv6, región regulatoria y otros ajustes sin éxito, la solución definitiva fue sustituir NetworkManager por wicd como gestor de conexiones. Wicd es un gestor alternativo, más sencillo en apariencia, pero que da bastante control sobre cada interfaz de red y permite modos más avanzados sin tener que meterse tanto en archivos de configuración.

El proceso típico consistió en, primero, instalar wicd estando conectado por cable o habiendo descargado los paquetes en otro equipo. Los comandos utilizados fueron del estilo sudo apt-get clean, sudo apt-get update y sudo apt-get install wicd, lo que añadió paquetes como wicd, wicd-daemon y wicd-gtk. Para quien prefiere trabajar en consola existe incluso wicd-curses como interfaz en modo texto.

Durante la instalación apareció un formulario para elegir qué usuarios iban a poder gestionar las conexiones con wicd. Es importante marcar a todos los usuarios que vayan a usar el gestor, porque si no luego no verás opciones o no te dejará tocar la configuración. En cualquier momento se puede reconfigurar esa parte con sudo dpkg-reconfigure wicd-daemon.

Antes de arrancar wicd por primera vez, es crucial detener y deshabilitar NetworkManager para evitar conflictos entre ambos. Se hizo con algo como sudo systemctl stop NetworkManager.service y sudo systemctl disable NetworkManager.service. Así te aseguras de que solo un gestor está “mandando” sobre las interfaces.

Una vez listo, se abrió Wicd Network Manager desde el menú de aplicaciones, dentro de la sección de Internet, se detectó la SSID de la red doméstica, se entró en Propiedades y se introdujo la contraseña WiFi. Tras pulsar en Conectar, la conexión se estableció correctamente y, en ese caso concreto, el problema quedó resuelto de forma estable. A partir de entonces, el usuario pudo seguir usando su WiFi sin más cortes ni misterios.

Volver a un kernel anterior cuando el nuevo rompe el WiFi

Una de las ventajas de muchas distribuciones es que no borran automáticamente el kernel anterior al actualizar. Eso te permite, desde el menú de arranque avanzado de GRUB, seleccionar una versión más vieja y comprobar si el problema de WiFi (o de gráficos) solo está presente en el kernel nuevo.

El caso de Linux Mint con el kernel 5.15.0-164-generic es muy ilustrativo: con esa versión la pantalla se llenaba de líneas de colores y el WiFi no funcionaba, mientras que arrancando con 5.15.0-56-generic todo volvía a funcionar como siempre. Eso implica casi seguro que el fallo viene de un cambio introducido en el kernel nuevo, ya sea en el módulo de la tarjeta gráfica, de la WiFi o en cómo interactúan entre sí.

Arrancar con un kernel anterior es una solución de emergencia muy útil: te permite seguir usando tu portátil con WiFi y gráficos estables mientras investigas o esperas a que la distribución publique un kernel corregido. Lo que muchos usuarios no quieren es tener que entrar continuamente en “Opciones avanzadas” de GRUB y pulsar manualmente sobre el kernel viejo cada vez que encienden el equipo.

Si confirmas que con el kernel antiguo todo funciona, puedes plantearte mantener ese kernel como predeterminado mientras tanto o incluso desinstalar solo el kernel problemático si sabes bien lo que estás haciendo (y la distro lo permite sin dejarte tirado). Otra opción es bloquear temporalmente las actualizaciones de kernel hasta que salga una versión que resuelva el problema.

En Fedora, por ejemplo, algún usuario comentaba que tras ejecutar dnf history list ya no veía la actualización en cuestión porque había seguido instalando paquetes, y que incluso volviendo a un kernel anterior seguía sin disponer de opciones WiFi. En esos casos quizás el problema no es únicamente el kernel, sino también cambios en paquetes de red que ya no se deshacen volviendo al kernel viejo. Aun así, probar otro kernel es un paso de diagnóstico casi obligado.

Cuando el adaptador WiFi no se reconoce tras la actualización

Otro panorama diferente es cuando, directamente, la tarjeta inalámbrica deja de ser reconocida como tal tras la actualización. Ahí no ves redes disponibles, el icono de WiFi puede no aparecer, y las herramientas de red indican que solo tienes interfaz de cable o ninguna inalámbrica.

Las causas habituales suelen ser que el driver que antes funcionaba ya no se carga con el nuevo kernel, se ha cambiado de nombre el módulo o se ha eliminado soporte para cierto chipset. En adaptadores USB como el ya mencionado Realtek RTL8191SU, el módulo r8712u es el encargado de hacerlos funcionar. Si ese módulo desaparece o deja de ser compatible con el kernel, el dispositivo se queda “mudo”.

Cómo buscar e instalar de nuevo los controladores adecuados depende muchísimo de la distribución que estés utilizando. En Ubuntu y derivados existe el apartado de controladores adicionales; en Fedora se suele recurrir a repositorios externos o a módulos empaquetados para el nuevo kernel; en Arch o Manjaro es frecuente tirar de AUR o de módulos DKMS que se recompilan para cada actualización de kernel; en openSUSE hay herramientas propias y repos repositorios específicos de hardware.

Si tras la actualización el adaptador no aparece, lo más prudente es acudir a las opciones de soporte oficial o comunitario de tu distribución: listas de correo, foros, chats en línea, etc. Allí suelen conocer al dedillo qué chipsets concretos dan guerra en cada versión de kernel y te pueden indicar si hay que instalar un paquete extra, activar un repositorio externo o pasar a un kernel LTS más conservador.

Mientras tanto, puede ser necesario recurrir a soluciones temporales como conectarte por cable Ethernet o compartir internet desde el móvil mediante USB. Eso te dará el margen de maniobra necesario para descargar los drivers que falten o para cambiar de kernel sin quedarte completamente desconectado.

En cuanto a herramientas como kernel-lts o similares, que permiten usar kernels de soporte extendido sin conexión a internet, es un terreno algo más avanzado: en muchos casos necesitarás al menos descargar los paquetes en otro equipo y transferirlos mediante USB para instalarlos offline en la máquina problemática.

Al final, cuando tu WiFi deja de funcionar tras una actualización en Linux, lo más eficaz es enfocar el problema por capas: comprobar si el hardware se ve, leer dmesg, revisar IPv6 y región WiFi, probar otro gestor de red y, si hace falta, volver a un kernel anterior. Con esas piezas, más la ayuda puntual de la comunidad de tu distribución para drivers específicos, casi siempre se consigue recuperar una conexión estable sin tener que formatear ni renunciar a las actualizaciones futuras.