Cortes de Wi‑Fi cada 10 minutos: la opción avanzada del controlador que lo soluciona

febrero 13, 2026 • febrero 13, 2026 • Lectura: 27 min • Views: 0

¿Te fue útil?

Estás en una videollamada. Todos te oyen hasta que—como si fuera un metrónomo—tu Wi‑Fi se corta. Diez minutos después vuelve. Diez minutos después se corta otra vez. Reinicias el router, lo maldices, te mueves tres pasos a la izquierda y por un momento crees que lo solucionaste.

Luego vuelve la desconexión mecánica. Si esto huele a “ahorro de energía” o a “temporizador de rekey/reautenticación”, ya estás en el vecindario correcto. La solución normalmente no es mística. Es un ajuste avanzado del controlador (o dos) más pruebas que demuestren que cambiaste lo correcto.

La opción avanzada del controlador que más a menudo lo soluciona

Si tu Wi‑Fi se corta con regularidad—especialmente en portátiles, especialmente con batería—la solución de mayor impacto suele ser:

Desactivar el ahorro de energía del cliente Wi‑Fi (U‑APSD / SMPS / “Modo de ahorro de energía”)

Los distintos fabricantes lo llaman de forma diferente, pero la intención es la misma: el cliente negocia un comportamiento de sueño con el punto de acceso (AP). Cuando se implementa mal (o el AP no acepta bien la negociación), obtienes paradas periódicas o desconexiones que parecen “aleatorias” a menos que notes el temporizador.

En Windows normalmente hay dos lugares:

Administración de energía del adaptador: “Permitir que el equipo apague este dispositivo para ahorrar energía” (Administrador de dispositivos → tu adaptador Wi‑Fi → Propiedades → Administración de energía).
Configuración avanzada del controlador (Administrador de dispositivos → Propiedades → Avanzado): “Power Save Mode”, “MIMO Power Save Mode”, “U-APSD support”, “Minimum Power Consumption”, “Transmit Power” o “Prefer maximum performance”.

Lo que buscas lograr es aburrido: mantener la radio despierta, detener el comportamiento “útil” de sueño y reducir el thrash de escaneo/roaming. Si tu desconexión es exactamente cada 10 minutos, también debes sospechar temporizadores de rekey/reautenticación, pero el ahorro de energía es la victoria más rápida porque depende solo del cliente y puedes validarlo sin negociar con quien administra el AP.

Un chiste corto, como limpiador de paladar: el ahorro de energía del Wi‑Fi es como el “modo eco” en un coche deportivo—ideal para el folleto, terrible en el tráfico.

Por qué ocurre “cada 10 minutos” en el mundo Wi‑Fi

Diez minutos no es magia. Es solo una escala temporal por defecto muy común en la que varias políticas de Wi‑Fi y de red hacen una vuelta:

Intervalos de rekey de la clave de grupo en entornos WPA2/WPA3 enterprise suelen medirse en minutos. Algunos entornos los configuran de forma agresiva y algunos controladores cliente manejan mal la transición.
Reautenticación 802.1X puede programarse, y si la ruta de autenticación es inestable, la “renovación” parece una caída.
Renovaciones de concesión DHCP suelen ser más largas que 10 minutos, pero las redes mal configuradas (especialmente VLANs de invitados) pueden usar concesiones cortas.
Escaneos en segundo plano del controlador y algoritmos de roaming a veces se ejecutan con temporizadores periódicos y pueden causar breves desconexiones visibles cuando las aplicaciones son sensibles.
Ticks de gestión de energía pueden alinearse con políticas del SO (ahorro de batería, transiciones de modern standby, suspensión selectiva del adaptador de red).

Hechos e historia (porque los valores por defecto tienen carga histórica)

Aquí hay puntos de contexto concretos que explican por qué tu problema de “Wi‑Fi simple” es en realidad un montón de decisiones tomadas en 25 años:

El ahorro de energía 802.11 existe desde los inicios del Wi‑Fi, pero las implementaciones modernas lo ampliaron con mecanismos como WMM Power Save (U‑APSD) para reducir latencia en voz mientras se duerme entre tramas.
WPA2 (2004) normalizó el rekey periódico como práctica de higiene de seguridad; “rotar claves” es buena seguridad, hasta que un cliente con errores lo convierte en un evento de conectividad.
El band steering se hizo común con la proliferación de APs dual-band y tri-band; los clientes pueden ser incentivados (o forzados) a 5 GHz/6 GHz, pero algunos controladores interpretan el steering como inestabilidad.
Las asistencias de roaming 802.11k/v/r existen para hacer el roaming más suave; las características medio implementadas pueden en su lugar crear un bucle de intentos de roam.
Windows “Modern Standby” cambió la semántica de sueño; está más cerca de “siempre encendido, siempre conectado”, lo que pone más presión en los estados de energía del NIC y en la corrección del controlador.
Los controladores cliente a menudo se envían con valores predeterminados OEM optimizados para benchmarks de batería, no para tu combo VPN + videollamada + AP defectuoso.
El Wi‑Fi empresarial adora los temporizadores porque adora las políticas. Los temporizadores no son malvados; son muy literales.
6 GHz (Wi‑Fi 6E) añade AFC y complejidad regulatoria en algunas regiones y hace que “voy a escanear todo” sea más costoso para los clientes.

Guion rápido de diagnóstico

El objetivo es encontrar el cuello de botella rápidamente: controlador cliente, RF/entorno, política del AP o red upstream. No adivines. Recolecta evidencia en 10–15 minutos.

Primero: demuestra que es la capa de enlace Wi‑Fi, no “internet”

Ejecuta un ping continuo al gateway por defecto. Si eso se corta, tu enlace está rompiéndose localmente (RF, controlador, AP). Si el gateway se mantiene sólido pero objetivos externos fallan, sospecha WAN/VPN/DNS.
Observa el estado de asociación: ¿el cliente se desconecta y reconecta (nuevo BSSID, nueva autenticación), o permanece asociado pero se queda bloqueado?

Segundo: busca periodicidad y el evento exacto

En Windows, genera un informe WLAN y lee los códigos de “Razón de desconexión”.
En Linux, revisa los logs de journald por razones de deauth/disassoc y por alternancias de power-save.

Tercero: cambia una configuración del cliente que elimine el ahorro de energía

Desactiva la administración de energía del adaptador Wi‑Fi en el Administrador de dispositivos y en la pestaña Avanzado del controlador.
Forza “Máximo rendimiento” (Configuración avanzada del plan de energía de Windows para Wireless Adapter Settings).

Cuarto: si sigue periódica, inspecciona temporizadores de rekey/reautenticación

Verifica si el intervalo de caída coincide con un temporizador de seguridad (600 segundos es sospechosamente “modelado por política”).
Confirma con los logs del AP/controlador si los tienes—o al menos prueba en otra red para aislar.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son los movimientos “haz esto, lee aquello, decide esto”. Listos para copiar/pegar, con salidas realistas. Úsalos para convertir “el Wi‑Fi es inestable” en un diagnóstico.

Task 1 (Windows): Identificar adaptador, versión del controlador y proveedor

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter -Physical | Where-Object {$_.Status -eq 'Up'} | Format-Table -Auto Name, InterfaceDescription, LinkSpeed"
Name   InterfaceDescription                      LinkSpeed
Wi-Fi  Intel(R) Wi-Fi 6 AX200 160MHz             780 Mbps

Qué significa: Confirma qué adaptador está activo. “Intel AX200” y similares tienen comportamientos específicos de ahorro de energía y roaming.

Decisión: Centra tu afinación en este adaptador; no pierdas tiempo en adaptadores virtuales.

Task 2 (Windows): Obtener información detallada del controlador

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object {$_.FriendlyName -like '*Wi-Fi*'} | Get-PnpDeviceProperty DEVPKEY_Device_DriverVersion"
InstanceId  : PCI\VEN_8086&DEV_2723&SUBSYS_00848086&REV_1A\3&11583659&0&10
Data        : 23.60.1.2
Type        : String

Qué significa: Versión del controlador. Algunas caídas periódicas son bugs del controlador, no imaginación tuya.

Decisión: Si estás varias versiones principales atrás, actualiza. Si estás en la versión más reciente y va peor, vuelve a una versión OEM conocida y estable.

Task 3 (Windows): Generar y abrir el informe WLAN

cr0x@server:~$ netsh wlan show wlanreport
WLAN report saved to C:\ProgramData\Microsoft\Windows\WlanReport\wlan-report-latest.html

Qué significa: Windows creó un informe HTML de asociaciones, desconexiones y motivos.

Decisión: Ábrelo y busca códigos de “Razón” que se repitan, bucles de reconexión y marcas de tiempo cada ~10 minutos.

Task 4 (Windows): Listar perfiles Wi‑Fi y comprobar si luchas contra una política

cr0x@server:~$ netsh wlan show profiles
Profiles on interface Wi-Fi:

Group policy profiles (read only)
---------------------------------
    <None>

User profiles
-------------
    All User Profile     : CorpWiFi
    All User Profile     : GuestWiFi

Qué significa: Si existen perfiles por política de grupo, tus ajustes pueden ser anulados por TI.

Decisión: Si un perfil corporativo está forzado, espera temporizadores 802.1X y cambios dirigidos por controlador; recopila evidencia antes de “arreglarlo”.

Task 5 (Windows): Vigilar eventos de WLAN AutoConfig por la razón de desconexión

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName Microsoft-Windows-WLAN-AutoConfig/Operational -MaxEvents 5 | Select-Object TimeCreated, Id, Message | Format-List"
TimeCreated : 2/4/2026 9:12:10 AM
Id          : 8003
Message     : WLAN AutoConfig service has disconnected from a wireless network. Reason: The network is disconnected by the driver.

TimeCreated : 2/4/2026 9:12:12 AM
Id          : 8001
Message     : WLAN AutoConfig service has successfully connected to a wireless network.

Qué significa: “Desconectado por el controlador” es una gran pista: ahorro de energía, decisión de roaming o bug del controlador.

Decisión: Prioriza los ajustes avanzados del controlador (ahorro de energía/roaming) antes de culpar al DNS, VPN o al router.

Task 6 (Windows): Comprobar la configuración del plan de energía inalámbrico

cr0x@server:~$ powercfg /q | findstr /i "Wireless Adapter Settings"
Subgroup GUID: 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1  (Wireless Adapter Settings)
Power Setting GUID: 12bbebe6-58d6-4636-95bb-3217ef867c1a  (Power Saving Mode)

Qué significa: Confirma que Windows gestiona el Wi‑Fi como parte del plan de energía.

Decisión: Ponlo en “Máximo rendimiento” en batería y alimentado si estás solucionando desconexiones.

Task 7 (Linux): Identificar dispositivo Wi‑Fi, controlador y firmware

cr0x@server:~$ sudo lspci -nnk | sed -n '/Network controller/,+4p'
03:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)
	Subsystem: Intel Corporation Device [8086:0084]
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

Qué significa: Confirma el controlador del kernel. Intel usa iwlwifi; Realtek a menudo usa rtw88/rtl8xxx; Qualcomm Atheros usa ath10k/ath11k.

Decisión: Aplica las palancas específicas del controlador (iwlwifi power_save, etc.).

Task 8 (Linux): Comprobar estado actual de power save

cr0x@server:~$ iw dev wlan0 get power_save
Power save: on

Qué significa: El power save está activado a nivel mac80211.

Decisión: Apágalo como prueba. Si las caídas se detienen, has encontrado la clase de bug.

Task 9 (Linux): Desactivar power saving inmediatamente (runtime)

cr0x@server:~$ sudo iw dev wlan0 set power_save off
cr0x@server:~$ iw dev wlan0 get power_save
Power save: off

Qué significa: Has desactivado el power save para la sesión actual.

Decisión: Ejecuta al menos 30 minutos. Si las caídas de 10 minutos desaparecen, hazlo persistente (siguientes tareas).

Task 10 (Linux + NetworkManager): Asegurarse de que NM no vuelva a habilitar powersave

cr0x@server:~$ sudo nmcli -f WIFI.POWERSAVE general
WIFI.POWERSAVE: 3 (enabled)

Qué significa: NetworkManager está configurado para habilitar powersave (valor 3). Esto puede anular los cambios manuales con iw.

Decisión: Ponlo a 2 (deshabilitado) para las pruebas de estabilidad.

Task 11 (Linux + NetworkManager): Deshabilitar powersave de NM de forma persistente

cr0x@server:~$ sudo bash -lc 'cat >/etc/NetworkManager/conf.d/wifi-powersave-off.conf <<EOF
[connection]
wifi.powersave = 2
EOF
systemctl restart NetworkManager'

Qué significa: Deshabilita persistentemente el powersave Wi‑Fi en NetworkManager y lo reinicia.

Decisión: Vuelve a probar las desconexiones periódicas. Si se arregla, mantenlo. Si la batería es crítica, luego experimenta con ajustes menos agresivos.

Task 12 (Linux): Revisar logs alrededor de la caída

cr0x@server:~$ sudo journalctl -u NetworkManager --since "30 min ago" | tail -n 20
Feb 04 09:12:10 laptop NetworkManager[1023]: <info>  [1707047530.1234] device (wlan0): supplicant interface state: completed -> disconnected
Feb 04 09:12:10 laptop NetworkManager[1023]: <warn>  [1707047530.1256] device (wlan0): link timed out.
Feb 04 09:12:12 laptop NetworkManager[1023]: <info>  [1707047532.8899] device (wlan0): supplicant interface state: disconnected -> scanning
Feb 04 09:12:14 laptop NetworkManager[1023]: <info>  [1707047534.2222] device (wlan0): supplicant interface state: scanning -> associating
Feb 04 09:12:16 laptop NetworkManager[1023]: <info>  [1707047536.3333] device (wlan0): supplicant interface state: associating -> completed

Qué significa: Muestra la secuencia: completed → disconnected → scanning → associating. Si se repite con un temporizador, sospecha powersave o reauth de seguridad.

Decisión: Empareja esto con los mensajes de wpa_supplicant (siguiente tarea) para ver si aparece la razón de deauth.

Task 13 (Linux): Inspeccionar mensajes de wpa_supplicant por razones de deauth

cr0x@server:~$ sudo journalctl -t wpa_supplicant --since "30 min ago" | tail -n 20
Feb 04 09:12:10 laptop wpa_supplicant[1122]: wlan0: CTRL-EVENT-DISCONNECTED bssid=aa:bb:cc:dd:ee:ff reason=4 locally_generated=1
Feb 04 09:12:12 laptop wpa_supplicant[1122]: wlan0: SME: Trying to authenticate with aa:bb:cc:dd:ee:ff (SSID='CorpWiFi' freq=5180 MHz)
Feb 04 09:12:14 laptop wpa_supplicant[1122]: wlan0: CTRL-EVENT-CONNECTED - Connection to aa:bb:cc:dd:ee:ff completed [id=0 id_str=]

Qué significa: “locally_generated=1” suele apuntar a decisiones del cliente (roam, power save, controlador). “reason=4” es “desasociado por inactividad” en muchos contextos, que es un olor clásico de desajuste de power‑save.

Decisión: Sigue insistiendo en el power‑save/roam del cliente. Si las razones indican deauth del AP, sube hacia el AP para ajustar configuraciones.

Task 14 (Cualquier SO): Demostrar si el gateway cae durante el evento

cr0x@server:~$ ping -n 200 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.14 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.06 ms
Request timeout for icmp_seq 63
Request timeout for icmp_seq 64
64 bytes from 192.168.1.1: icmp_seq=65 ttl=64 time=2.44 ms

Qué significa: Si el gateway por defecto cae, esto no es “DNS” ni “ISP.” Es conectividad Wi‑Fi local.

Decisión: Centra la atención en eventos de asociación RF/controlador/AP, no en el enrutamiento externo.

Task 15 (Cualquier SO): Comprobar si estás haciendo roaming entre APs o bandas

cr0x@server:~$ iw dev wlan0 link
Connected to aa:bb:cc:dd:ee:ff (on wlan0)
	SSID: CorpWiFi
	freq: 5180
	signal: -62 dBm
	rx bitrate: 780.0 MBit/s
	tx bitrate: 585.0 MBit/s

Qué significa: Muestra BSSID y frecuencia. Si después de una caída el BSSID cambia, estás haciendo roaming (tal vez por band steering o umbrales de señal pobres).

Decisión: Reduce la agresividad de roaming en el cliente o mejora la disposición de APs / desactiva el steering demasiado agresivo.

Windows: los mandos del controlador que importan (y los que no)

Windows ofrece al menos tres capas de “ahorro de energía”, y se apilan. Por eso la gente jura que cambió una opción y no pasó nada: cambió la capa equivocada.

Capa 1: Administrador de dispositivos → pestaña Administración de energía

Opción: “Permitir que el equipo apague este dispositivo para ahorrar energía”.

Hacer: Desmarca mientras haces pruebas. Manténlo desmarcado si valoras disponibilidad sobre supuestos ahorros de batería.

Por qué ayuda: Es un instrumento tosco. Evita que Windows suspenda selectivamente el NIC. La suspensión selectiva está bien hasta que una combinación de controlador/firmware falla al despertarlo o pierde estado.

Capa 2: Plan de energía → Wireless Adapter Settings

Opción: Power Saving Mode: Maximum Performance vs Medium/Low Power Saving.

Hacer: Pon tanto “En batería” como “Con corriente” en Máximo rendimiento durante el diagnóstico. Si corrige el problema, luego puedes decidir si relajar “En batería”.

Capa 3: Configuraciones avanzadas del controlador (los verdaderos problemáticos)

Aquí es donde a menudo se arreglan las caídas periódicas. Los nombres varían según el proveedor, pero estas son las opciones a buscar:

Power Save Mode / Minimum Power Consumption: poner en Off / Disabled.
MIMO Power Save Mode (SMPS): poner en No SMPS / Disabled (los nombres varían). SMPS agresivo puede crear extraños picos de throughput; en algunos entornos parece una caída.
U‑APSD / WMM Power Save: deshabilitar para pruebas. Si el tráfico de voz/latencia es importante, puedes reactivarlo más tarde si todo es estable.
Roaming Aggressiveness: poner en Lowest (o Medium‑Low). Alta agresividad de roaming es dramática; escanea constantemente y te “mejora” hasta desconectarte.
Preferred Band: bloquear en 5 GHz (o 6 GHz si es estable) para evitar bucles de band steering. O bloquear temporalmente en 2.4 GHz si pruebas cobertura/RF.
Transmit Power: poner en Highest. Potencia TX baja puede causar enlaces asimétricos donde oyes al AP pero el AP no te oye de forma fiable.

Dos ajustes que a la gente le encanta tocar y raramente solucionan cortes de 10 minutos:

“802.11n/ac/ax mode” cambiar puede ayudar con compatibilidad, pero no es lo primero salvo que el AP sea viejo o defectuoso.
Preferencias de ancho de canal importan para throughput e interferencia; son una afinación de segunda ronda, no una solución para cortes periódicos.

Cómo validar la solución (no te fíes de sensaciones)

Tras hacer cambios, valida con tres cosas:

Eventos de WLAN AutoConfig dejan de mostrar desconexiones iniciadas por el controlador.
Ping continuo al gateway ya no tiene un hueco cada 600 segundos.
Tu BSSID/frecuencia se mantiene estable (a menos que te muevas físicamente).

Linux: iwlwifi/ath* powersave, NetworkManager y la realidad

Linux te da honestidad: los logs te dirán qué pasó, y lo harán a las 2 AM cuando intentas dormir. Pero Linux también te da elección, y algunas de esas elecciones son “sí, el sistema volverá a activar powersave porque alguien pensó que era cortés”.

Ahorro de energía del cliente: tres mandos, un mismo resultado

mac80211 powersave vía iw (runtime, por interfaz)
NetworkManager wifi.powersave (política, persistente)
Parámetros del módulo del controlador (p. ej., iwlwifi power_save)

Para caídas periódicas, deshabilita todo durante las pruebas. Luego puedes reintroducir el ahorro de energía con cuidado si te importa.

Parámetros del módulo iwlwifi (Intel)

Los adaptadores Intel son comunes y en general buenos, pero también sofisticados. Las funciones de gestión de energía pueden interactuar con peculiaridades del AP. Una línea base estable para troubleshooting es: powersave off, sin características experimentales raras, y firmware actualizado.

cr0x@server:~$ sudo modinfo iwlwifi | grep -E "parm:|firmware"
firmware:       iwlwifi-cc-a0-77.ucode
parm:           power_save:Enable power save (default: true)
parm:           uapsd_disable:Disable U-APSD (default: false)

Qué significa: Muestra parámetros del módulo. Si ves uapsd_disable, es una pista de que puedes probar a deshabilitar U‑APSD a nivel de módulo.

Decisión: Usa opciones del módulo solo cuando NetworkManager y los cambios con iw no sean suficientes o se sigan sobrescribiendo.

cr0x@server:~$ sudo bash -lc 'cat >/etc/modprobe.d/iwlwifi-powersave-off.conf <<EOF
options iwlwifi power_save=0 uapsd_disable=1
EOF
update-initramfs -u'
update-initramfs: Generating /boot/initrd.img-6.5.0-18-generic

Qué significa: Persiste las opciones de iwlwifi a través de reinicios (se muestra la actualización de initramfs para sistemas estilo Debian/Ubuntu).

Decisión: Reinicia y confirma si las caídas se detienen. Si la estabilidad mejora, has identificado una interacción AP+U‑APSD o un comportamiento del firmware.

Segundo chiste corto (y último): Si disfrutas perseguir Wi‑Fi intermitente, te encantaría la corrupción de almacenamiento también—ambos guardan recibos, pero no del tipo que quieres.

Temporizadores y funciones del router/AP que crean cortes periódicos

La afinación del cliente arregla sorprendentemente muchos casos. Pero a veces el AP es el que te está expulsando cada 10 minutos—educadamente, de forma conforme al estándar, con un código de razón que nadie lee.

Causas comunes en el AP que provocan desconexiones periódicas

Intervalo de rekey de la clave de grupo demasiado corto o manejo defectuoso por parte del cliente de las transiciones de rekey.
Reautenticación 802.1X con una ruta RADIUS frágil o valores de timeout de sesión incorrectos.
Timeout de inactividad que no considera clientes con power‑saving (el AP piensa que estás inactivo; tú crees que estás durmiendo de forma responsable).
Band steering que intenta repetidamente mover al cliente entre bandas, especialmente si el mismo SSID está en 2.4 y 5 con umbrales agresivos.
Balanceo de carga / steering de clientes ajustado para oficinas densas, no para una oficina en casa donde “mover el cliente” significa “desconectarlo”.
Modo de transición WPA3 (WPA2/WPA3 mixto) con peculiaridades, especialmente con controladores antiguos.

Cómo saber que es política del AP sin acceso al AP

Aun así puedes inferir mucho desde el lado cliente:

Si los logs muestran deauth/disassoc iniciado por el AP (locally_generated=0 en Linux; “Reason: received deauthentication from AP” en Windows), sospecha temporizadores/steering del AP.
Si el cliente se reconecta al mismo BSSID con un handshake fresco cada ~10 minutos, sospecha reauth/rekey/timeout de inactividad.
Si el cliente se reconecta a un BSSID o banda diferente, sospecha steering o umbrales de roaming.

Cuando tienes acceso al AP, la solución suele ser: aumentar el intervalo de rekey (dentro de la política), desactivar steering excesivo para ese SSID y asegurarse de que el firmware esté al día. Los equipos de seguridad y de red discutirán esto. Siempre lo hacen. Tu trabajo es proporcionar evidencia.

Tres microhistorias corporativas de la vida en producción

Microhistoria 1: El incidente causado por una suposición errónea

Un departamento financiero se quejó de que “internet se cae cada diez minutos” durante el cierre de fin de mes. Esa frase es una trampa: invita a todos a mirar los gráficos del firewall y el circuito del ISP. Así que lo hicimos. Todo parecía bien. Sin pérdida de paquetes en el WAN, sin caídas alarmantes, nada obvio.

Alguien finalmente ejecutó un ping continuo al gateway de la oficina desde uno de los portátiles afectados. El ping tenía una latencia limpia de 1–2 ms… hasta exactamente diez minutos después de la última desconexión, cuando quedó en silencio durante 10–15 segundos. El WAN nunca lo vio porque el cliente ni siquiera estaba en la LAN durante el evento. “Internet” era inocente.

La suposición errónea fue sutil: asumimos que los fallos de aplicación significaban fallo upstream. Pero los logs (WLAN AutoConfig) decían “disconnected by the driver.” Eso no es un problema del ISP. Es tu radio, tu controlador, tu estado de energía.

Solución: deshabilitamos el ahorro de energía del adaptador en el Administrador de dispositivos y configuramos el plan inalámbrico a máximo rendimiento. Las caídas se detuvieron al instante. Más tarde descubrimos que la imagen OEM tenía un perfil de batería agresivo empujado a todos los portátiles, incluyendo escritorios en docking que nunca se movían. A veces la solución menos glamurosa es la correcta.

Microhistoria 2: La optimización que salió mal

Otra organización quiso mejor autonomía de batería en la flota. Razonable. Habilitaron ahorro de energía Wi‑Fi y aumentaron la agresividad de roaming porque la gente se quejaba de conexiones “pegajosas” al caminar por el edificio. También razonable, en teoría.

Luego comenzaron los tickets: “El Wi‑Fi se corta durante las llamadas.” El patrón era extraño—más visible en Zoom/Teams, menos visible en navegación web. Síntoma clásico de micro‑caídas y eventos de reauth: TCP oculta el problema; medios en tiempo real no.

Revisamos logs de algunas máquinas y hallamos desconexiones periódicas iniciadas por el controlador. No constantes, no aleatorias. Periódicas. La agresividad de roaming hacía escaneos frecuentes e intentos de roam en un entorno con band steering activado. El cliente seguía intentando “mejorar” su situación y terminaba re‑keyando y re‑asociándose repetidamente. Optimizaba por una métrica (velocidad de roam) a costa de la métrica que a los humanos importa (estabilidad).

Solución: bajamos la agresividad de roaming a “Low”, deshabilitamos U‑APSD en las versiones problemáticas del controlador y redujimos la agresividad de steering en el SSID de voz. La batería cayó ligeramente. La calidad de las llamadas mejoró drásticamente. La lección no fue “nunca optimices”. Fue “optimiza una variable a la vez y mide el resultado correcto”.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un gran campus tenía reportes de desconexiones intermitentes “en la misma hora cada hora”. El primer instinto fue culpar a la congestión RF: demasiados dispositivos, demasiados APs, demasiado todo. El equipo de red tenía opiniones fuertes. El equipo de escritorio tenía opiniones más fuertes.

La práctica aburrida fue esta: toma un único cliente, captura una línea de tiempo de eventos con marcas de tiempo y correlaciónala con los logs de infraestructura. No “creo”. No “se siente”. Una línea de tiempo.

Recogieron un informe WLAN de clientes Windows, más logs del controlador sobre eventos de deauth. Los tiempos de desconexión coincidían con un push periódico de políticas de seguridad que forzaba reautenticación para un subconjunto de usuarios. No le pasaba a todo el mundo porque la política aplicaba solo a ciertas VLANs y grupos de identidad. Ese detalle importó.

Solución: ajustaron el comportamiento de reauth para que no cortara sesiones activas, y validaron con un despliegue escalonado. El hardware Wi‑Fi siguió igual. Los clientes siguieron igual. La diferencia fue control de cambios y correlación. Poco sexy, efectivo y repetible.

Errores comunes: síntoma → causa raíz → solución

Estos son los patrones que veo repetidamente—especialmente cuando el intervalo de caída es sospechosamente regular.

1) Caídas cada ~10 minutos solo con batería

Síntoma: Estable con alimentación, caída periódica con batería.

Causa raíz: El modo de ahorro del adaptador inalámbrico cambia con el plan de energía; suspendido selectivo/U‑APSD/SMPS se vuelve agresivo.

Solución: Establecer ahorro inalámbrico a Máximo rendimiento en batería; deshabilitar administración de NIC; deshabilitar Power Save Mode/U‑APSD del controlador para pruebas.

2) Caídas cada ~10 minutos en un SSID pero no en otro

Síntoma: Wi‑Fi de invitados bien; Wi‑Fi corporativo se cae (o viceversa).

Causa raíz: Política específica por SSID: reauth 802.1X, rekey de clave de grupo, band steering o funciones del controlador.

Solución: Compara logs: ¿te está deautenticando el AP? Si sí, ajusta reauth/rekey/steering en ese SSID o prueba con modos WPA2-only/WPA3-only.

3) “Internet se cae” pero el ping al gateway permanece sólido

Síntoma: La llamada en Teams se corta, pero aún puedes hacer ping al router.

Causa raíz: Problema upstream: DNS, rekey de VPN, timeouts de sesión del firewall o picos en el WAN—no asociación Wi‑Fi.

Solución: Captura un ping paralelo a una IP externa y tiempos de consulta DNS. Centra la atención en logs del cliente VPN o logs del router WAN.

4) Caídas correlacionadas con roaming entre APs

Síntoma: El BSSID cambia alrededor de la caída; puede que ni te estés moviendo.

Causa raíz: Roaming de cliente demasiado agresivo + steering del AP + señal marginal.

Solución: Reduce la agresividad de roaming; bloquea la banda preferida; mejora la colocación de APs; desactiva steering para ese SSID.

5) Caídas en un intervalo fijo en muchos dispositivos

Síntoma: Varios usuarios reportan caídas periódicas similares, a menudo sincronizadas.

Causa raíz: Temporizador/política de infraestructura: reauth, rekey, optimización RF programada, bug de controlador o interferencia periódica.

Solución: Correlaciona con logs del controlador/AP. Cambia un temporizador a la vez y despliega gradualmente.

6) “Lo arreglé” cambiando canales, pero volvió

Síntoma: Cambiar canal ayuda brevemente; vuelve la periodicidad.

Causa raíz: El culpable real es la política/estado de energía del controlador; el cambio de canal solo alteró el tiempo o forzó una reconexión temporal.

Solución: Deja de cazar canales primero. Demuestra eventos de capa de enlace; deshabilita ahorro de energía del cliente; luego revisa RF.

Listas de comprobación / plan paso a paso

Paso a paso: el plan “Necesito esto estable hoy”

Mide la falla: Ejecuta un ping al gateway por defecto durante 20 minutos y anota si cae con un patrón regular.
Recoge logs del cliente: Informe WLAN de Windows o journald/wpa_supplicant de Linux para la razón de desconexión.
Deshabilita el ahorro de energía del cliente:
- Windows: desmarca “Permitir que el equipo apague este dispositivo”, pon Wireless Adapter Settings en Máximo rendimiento, deshabilita Power Save Mode/U‑APSD del controlador.
- Linux: iw ... set power_save off, deshabilita wifi.powersave en NetworkManager.
Reduce la churn de roaming: Pon roaming aggressiveness en Low; bloquea la banda preferida si hay steering implicado.
Vuelve a probar 30–60 minutos: Si el ritmo de diez minutos desaparece, mantén la configuración y documenta.
Si sigue fallando: Sospecha temporizadores de rekey/reauth y política del AP; prueba en otro SSID o hotspot para aislar cliente vs red.

Lista de comprobación: evidencia para el equipo de TI/red

Intervalo exacto (p. ej., 600 segundos) y marcas de tiempo de al menos tres caídas.
Logs del cliente mostrando si la desconexión fue iniciada por el controlador o por el AP.
BSSID/frecuencia antes y después de la caída (evidencia de roaming).
Si el ping al gateway cae (capa de enlace vs upstream).
Versión del controlador y versión del SO.
Si el problema se reproduce en otra red (un hotspot de teléfono es una buena prueba).

Lista de comprobación: qué no hacer

No reinicies el router de fábrica como primer paso. Eso es una caída planificada que te impones a ti mismo.
No cambies cinco ajustes a la vez y luego declares victoria. No sabrás cuál importó.
No asumas que “Wi‑Fi conectado” significa “Wi‑Fi funcional.” El estado de asociación puede parecer sano mientras la ruta de datos es pésima.

Preguntas frecuentes

1) ¿Por qué se corta exactamente cada 10 minutos?

Porque algo tiene un temporizador: transiciones de power‑save del cliente, escaneos/decisiones periódicas de roaming, rekey de clave de grupo o reautenticación 802.1X. Diez minutos es un intervalo de política común.

2) ¿Cuál es el ajuste único del controlador más común que arregla caídas periódicas?

Deshabilitar el ahorro de energía Wi‑Fi agresivo (Power Save Mode / U‑APSD / MIMO power save) y forzar máximo rendimiento. Elimina toda una categoría de aristas sueño/despertar.

3) ¿Desactivar el ahorro de energía arruinará mi batería?

Puedes reducir algo la batería, especialmente en portátiles. Pero si la elección es “conectividad estable” vs “quizá 5–10% de batería”, elige estabilidad primero y luego afina.

4) ¿Podría ser un problema de DNS en su lugar?

Sí, pero DNS rara vez falla con una cadencia perfecta de diez minutos. Si tu ping al gateway por defecto cae, no es DNS. Si el ping al gateway está bien pero las búsquedas de nombres fallan, entonces investiga DNS.

5) Mi Wi‑Fi dice “Conectado, asegurado” cuando se corta. ¿Cómo es eso?

La interfaz no es un capture de paquetes. Puedes permanecer asociado mientras tu ruta de datos se atasca por buffering de power‑save, problemas del controlador o eventos de política upstream. Confía más en logs y pings que en iconos.

6) ¿Es más común con ciertos chipsets?

Las caídas periódicas pueden ocurrir con cualquier proveedor, pero se reportan con frecuencia en ciertos chips Intel y Realtek en portátiles cuando los perfiles OEM de energía y los valores por defecto de U‑APSD/SMPS chocan con APs específicos.

7) ¿Debería desactivar WPA3 para arreglar esto?

Sólo como prueba controlada. El modo de transición WPA3 (mixto WPA2/WPA3) puede ser problemático con clientes antiguos. Si desactivar WPA3 lo hace estable, la solución real suele ser actualizaciones de firmware/controlador o pasar consistentemente a WPA2-only o WPA3-only.

8) ¿Cuál es la diferencia entre roaming aggressiveness y band steering?

Roaming aggressiveness es la decisión del cliente sobre cuándo largarse. Band steering es el AP empujando o forzando clientes hacia una banda. Cuando ambos son agresivos, obtienes comportamiento ping‑pong.

9) ¿Por qué la videoconferencia sufre más que la navegación web?

Los navegadores toleran pérdidas breves de paquetes mediante reintentos y buffering. El audio/video en tiempo real es sensible al jitter y a huecos, así que una reconexión de 5–15 segundos se nota al instante.

10) Cambié ajustes y sigue fallando. ¿Qué hago ahora?

Aísla: prueba en un hotspot del teléfono (variable solo cliente) y en otro portátil en el mismo SSID (variable solo red). Si solo falla un dispositivo, centrarte en el controlador/SO. Si varios dispositivos fallan, enfócate en temporizadores/firmware/política del AP.

Próximos pasos prácticos

Haz tres cosas, en orden:

Demuestra dónde vive la caída con un ping al gateway y logs del cliente. Si el gateway cae, es capa de enlace Wi‑Fi, punto.
Deshabilita el ahorro de energía Wi‑Fi de extremo a extremo (plan de energía del SO + administración de energía del dispositivo + ajustes avanzados del controlador) y vuelve a probar al menos 30 minutos.
Si la periodicidad sobrevive, trátalo como temporizador de política: rekey/reautenticación/steering. Recopila marcas de tiempo y códigos de razón, luego cambia una variable de red a la vez.

Una idea parafraseada de una figura en fiabilidad encaja aquí: idea parafraseada—John Allspaw ha enfatizado repetidamente que aprendes fiabilidad investigando fallos reales, no adivinando. Ese es el juego entero: medir, cambiar una cosa, medir otra vez.