Desconexiones aleatorias de Wi‑Fi: la opción de roaming que Windows oculta

Qué es realmente el roaming (y por qué parece una desconexión)

El roaming es cuando el cliente decide: “Actualmente estoy asociado al AP A; el AP B podría ser mejor; me voy a mover.”
En términos Wi‑Fi, eso implica una reasociación (y a menudo un handshake de clave) que puede tardar decenas a cientos de milisegundos.
Si es limpio y rápido, apenas lo notas. Si es desordenado, tus aplicaciones ven pérdida de paquetes, bloqueos de TCP y la VPN renegociando.

Las “desconexiones aleatorias” a menudo son simplemente “roaming mal ejecutado”. Se siente como una desconexión porque tus aplicaciones no se preocupan por la semántica de Wi‑Fi.
Les importa que el socket dejó de mover datos. VoIP, videoconferencia, RDP y VPN son los primeros en quejarse.

Aquí viene lo incómodo: las decisiones de roaming son mayormente del lado del cliente. Tu AP puede fomentar, empujar o presionar (más adelante hablaremos de eso),
pero la pila Wi‑Fi de Windows y el controlador deciden al final cuándo abandonar el BSSID actual y engancharse a otro.

Puedes tener una cobertura excelente y aun así tener roaming malo. Puedes tener señal fuerte y aun así que te expulsen. También puedes tener
un sistema mesh “ayudando” a empujarte entre bandas, mientras Windows interpreta el mundo mediante RSSI, SNR, tasas de reintento,
resultados de escaneo y heurísticas del controlador.

La opción de Windows que importa: Agresividad de roaming

En muchos controladores de adaptadores Wi‑Fi (especialmente Intel, pero no solo Intel), existe una propiedad avanzada generalmente llamada
Agresividad de roaming. Windows no la muestra en una pantalla amigable de “Red e Internet”.
Está enterrada en las propiedades del controlador del adaptador, y la redacción exacta varía según el proveedor.

Qué hace: desplaza el umbral para el roaming. Mayor agresividad significa que el cliente escanea más y realiza roaming antes,
a menudo hacia una señal “mejor”. Menor agresividad implica un comportamiento más “pegajoso”: quedarse donde está a menos que el AP actual empeore claramente.

La trampa es que “señal mejor” no es lo mismo que “mejor experiencia”. Un AP cercano puede tener un RSSI fuerte y aun así estar
sobrecargado, mal configurado o en un canal ruidoso. Por el contrario, un AP algo más débil puede ofrecer un enlace mucho más estable con menos reintentos.

Si tu síntoma son “caídas” periódicas mientras no te mueves (o te mueves muy poco), el roaming excesivamente agresivo es un sospechoso principal.
Windows puede decidir hacer roaming porque ve un candidato marginalmente mejor, disparar una reasociación y tus aplicaciones en tiempo real interpretarlo
como “se cayó Internet”.

Qué hacer, en general:

• Si estás en un entorno estable (oficina en casa, escritorio fijo, un AP cercano): configura la agresividad de roaming más baja.
• Si eres realmente móvil (almacén, hospital, campus) y tienes APs empresariales diseñados para ello: puede que quieras medio.
• No la pongas al máximo solo porque “roaming suena bien”. No es una meta de fitness.

Broma #1: El roaming de Wi‑Fi es como el hot‑desking en la oficina—genial en teoría, caótico cuando todos siguen cambiando de asiento en medio de una reunión.

Por qué ocurren las “desconexiones aleatorias”: los modos reales de fallo

1) El roaming excesivo provoca micro‑cortes

Si el controlador escanea y hace roaming con demasiada frecuencia, la calidad de tu conexión se vuelve una sierra. Un poco de pérdida de paquetes provoca una retrocesión de TCP.
Un pequeño retraso se convierte en “Teams se está reconectando”. La interfaz de Windows puede mostrar una desconexión, o puede simplemente mostrar el SSID continuamente mientras
tus aplicaciones caducan.

2) El ahorro de energía te engaña

Windows y la gestión de energía del controlador pueden poner la NIC en estados de menor consumo, reducir la potencia de transmisión o aumentar el sueño.
En batería, es más agresivo. El resultado puede parecer “desconexiones aleatorias”, especialmente con bajo throughput (chats inactivos)
seguidos por demanda en tiempo real repentina (empieza una llamada).

3) Band steering y “smart connect” hacen que los clientes roten

Los sistemas mesh de consumo suelen usar band steering: el mismo SSID para 2.4 GHz y 5 GHz (y a veces 6 GHz), con el sistema intentando
empujar a los clientes a bandas “mejores”. Esto puede funcionar—hasta que no. Si el AP es demasiado insistente (o tiene fallos), obtienes deauths repetidos,
reasociaciones fallidas y un usuario que cree que su ISP lo odia personalmente.

4) Bugs de controladores y funciones “avanzadas”

Funciones como U-APSD, “Throughput Booster”, “Preferred Band”, “MIMO power save” y asistencia de roaming del proveedor pueden interactuar mal
con firmware específico de AP. La peor clase de bug es la que solo se reproduce los martes a las 10:03 durante una llamada.
Pero los logs no mienten; solo necesitas extraer los correctos.

5) Seguridad y latencia del handshake

WPA2‑Enterprise (802.1X) puede ser rápido si tu entorno está afinado (caché PMK, OKC, 802.11r donde esté soportado).
También puede ser un desastre en cámara lenta si la ruta RADIUS es lenta, si los certificados están mal gestionados o si el cliente se ve forzado
a hacer reautenticaciones completas demasiado a menudo.

6) Clientes pegajosos: el problema opuesto

A veces la “caída” es en realidad el cliente negándose a hacer roaming cuando debería, aferrándose a un AP moribundo hasta que el enlace se desintegra.
Entonces finalmente hace roaming, tarde, y tu app lo llama desconexión. Bajar la agresividad de roaming puede empeorar esto en entornos de alta movilidad.
Por eso diagnosticas primero y ajustas después.

7) Renovaciones DHCP y problemas en capa IP que se hacen pasar por Wi‑Fi

Un roam puede desencadenar un cambio de conectividad breve que expone una configuración DHCP débil, una puerta de enlace poco fiable o una VPN que no tolera
transiciones de interfaz. El enlace Wi‑Fi puede estar bien; es la pila IP la que se cae.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando un usuario dice “se cae el Wi‑Fi”, no empiezas reinstalando controladores como si fuera 2009. Trías como un SRE:
confirma el síntoma, estrecha la capa y luego cambia una variable a la vez.

Primero: prueba si es roaming/desconexión en capa enlace vs IP/VPN/app

• Extrae el informe WLAN de Windows y los logs de Visor de eventos. Busca Roaming, disconnected, deauth, reason codes.
• Correlaciona las marcas de tiempo con los informes del usuario y los logs de VPN.
• Si el BSSID cambia en la marca de tiempo de la “caída”, estás en ámbito de roaming. Si no cambia, probablemente sea ahorro de energía, reintentos RF o capa superior.

Segundo: comprueba la calidad de señal y el comportamiento de reintentos en el momento del problema

• Revisa el porcentaje tipo RSSI, tasa de transmisión/recepción y canal.
• Busca alta utilización de canal u obvios síntomas de interferencia co‑canal (tasas colapsando, intentos de roaming repetidos).

Tercero: aisla el desencadenante con cambios controlados

• Configura la agresividad de roaming un paso más baja (no “la más baja para siempre”, solo un paso). Prueba.
• Desactiva el ahorro de energía del adaptador durante la ventana de prueba. Prueba.
• Si estás en mesh con band steering, prueba separando SSIDs temporalmente (2.4 vs 5). Prueba.
• Si es enterprise: prueba 802.11r activado/desactivado, valida la latencia RADIUS y asegúrate del comportamiento de caché PMK.

Tareas prácticas: comandos, salidas y decisiones

Estas son las tareas que realmente ejecuto cuando un portátil Windows “se cae aleatoriamente”. Cada tarea incluye un comando realista,
una salida de ejemplo, lo que significa y la decisión que tomas. Ejecútalas en un terminal elevado cuando sea necesario.

Task 1: Generar un informe WLAN (roams, desconexiones, códigos de razón)

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

Qué significa: Windows creó un informe HTML con la línea de tiempo de conexión, razones de desconexión e información del adaptador.
Decisión: Abre el informe y busca desconexiones/roams repetidos a intervalos iguales. Si ves “Reason: The network is disconnected by the driver”
o muchos eventos de roam, estás en territorio de controlador/roaming, no de “corte del ISP”.

Task 2: Volcar el estado de la interfaz (BSSID, canal, tasas)

cr0x@server:~$ netsh wlan show interfaces
There is 1 interface on the system:

    Name                   : Wi-Fi
    Description            : Intel(R) Wi-Fi 6 AX201 160MHz
    GUID                   : 2c3a6b2d-1f45-4a8b-9c0a-0f1b1c0d1234
    Physical address       : 34:ab:cd:ef:12:34
    State                  : connected
    SSID                   : CorpNet
    BSSID                  : a0:bb:cc:dd:ee:f0
    Network type           : Infrastructure
    Radio type             : 802.11ax
    Authentication         : WPA2-Enterprise
    Connection mode        : Profile
    Channel                : 36
    Receive rate (Mbps)    : 866.7
    Transmit rate (Mbps)   : 780.0
    Signal                 : 72%
    Profile                : CorpNet

Qué significa: Tienes el AP actual (BSSID), la banda (canal) y las tasas de enlace.
Decisión: Cuando ocurra la próxima “caída”, ejecuta esto otra vez. Si el BSSID cambia, es un roam. Si las tasas se desploman antes de la caída,
sospecha RF/interferencia o ahorro de energía. Si la señal es fuerte pero el rendimiento es malo, sospecha contención o bugs de steering.

Task 3: Ver perfiles guardados y confirmar que no te conectas a la variante equivocada del SSID

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

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

User profiles
-------------
    All User Profile     : CorpNet
    All User Profile     : CorpNet-Guest
    All User Profile     : CorpNet_24G

Qué significa: Existen múltiples perfiles similares.
Decisión: Si ves “CorpNet” y “CorpNet_24G/5G”, decide si quieres selección de banda explícita para pruebas.
Si se recuerda un SSID de invitado y la conexión automática está activada, puede “roamearte” a la red equivocada en el aparcamiento.

Task 4: Verificar el controlador actual y la versión (los bugs de controladores son reales)

cr0x@server:~$ pnputil /enum-drivers | findstr /i wifi
Published Name : oem42.inf
Original Name  : Netwtw10.inf
Provider Name  : Intel
Class Name     : Net
Class GUID     : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver Version : 23.30.0.6
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Qué significa: Puedes identificar el INF del proveedor y la versión.
Decisión: Si estás en un controlador conocido por problemas para tu parque, estandariza en una versión probada.
No hagas “actualizar al último” a ciegas si tu entorno es sensible; prueba primero.

Task 5: Inspeccionar capacidades de gestión de energía y plan activo (el comportamiento en batería importa)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Qué significa: Estás en Balanced, lo que tiende a activar un ahorro de energía más agresivo.
Decisión: Para solucionar, cambia temporalmente a High performance o establece la configuración del adaptador inalámbrico en Maximum Performance.
Si el problema desaparece con la corriente pero aparece con batería, tienes una interacción entre política de energía/controlador.

Task 6: Comprobar la configuración de energía por adaptador (modo de ahorro del adaptador inalámbrico)

cr0x@server:~$ powercfg /q 381b4222-f694-41f0-9685-ff5bb260df2e 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1 12bbebe6-58d6-4636-95bb-3217ef867c1a | findstr /i "Current AC Power Setting Index"
Current AC Power Setting Index: 0x00000002

Qué significa: El índice numérico se mapea al modo de ahorro del adaptador inalámbrico (varía por build/controlador), donde más alto suele significar más ahorro.
Decisión: Si persigues estabilidad, configúralo en máximo rendimiento tanto para AC como para DC mientras diagnosticas.
Si eso lo arregla, luego puedes ajustar a una opción menos agresiva en lugar de vivir en modo de alto consumo.

Task 7: Extraer eventos de WLAN AutoConfig (la verdad está en las marcas de tiempo)

cr0x@server:~$ wevtutil qe Microsoft-Windows-WLAN-AutoConfig/Operational /c:10 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WLAN-AutoConfig
  Event ID: 8001
  Level: Information
  Description:
    WLAN AutoConfig service has successfully connected to a wireless network.

Event[1]:
  Provider Name: Microsoft-Windows-WLAN-AutoConfig
  Event ID: 8003
  Level: Warning
  Description:
    WLAN AutoConfig service has disconnected from a wireless network.
    Reason: The network is disconnected by the driver.

Qué significa: Puedes ver eventos de conexión/desconexión y razones sin adivinar.
Decisión: “Disconnected by the driver” apunta a comportamiento de controlador/firmware/gestión de energía/roaming.
Si ves “Explicit EAP failure”, estás en territorio 802.1X/RADIUS.

Task 8: Comparar continuidad en capa IP (¿se cae el Wi‑Fi o se rompe IP?)

cr0x@server:~$ ipconfig /all
Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . : Intel(R) Wi-Fi 6 AX201 160MHz
   Physical Address. . . . . . . . : 34-AB-CD-EF-12-34
   DHCP Enabled. . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . : 10.44.12.87(Preferred)
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . : Monday, 10:12:01 AM
   Lease Expires . . . . . . . . . : Monday, 06:12:01 PM
   Default Gateway . . . . . . . . : 10.44.12.1
   DNS Servers . . . . . . . . . . : 10.44.0.10
                                       10.44.0.11

Qué significa: Confirmas DHCP, tiempos de lease, gateway y DNS.
Decisión: Si las “caídas” se correlacionan con renovaciones DHCP o una puerta de enlace que cambia, puede que estés viendo
churn de IP en lugar de roaming Wi‑Fi. Si la IP se mantiene estable pero las aplicaciones se caen, mira el roaming/ahorro de energía/VPN.

Task 9: Ping continuo para detectar micro‑cortes (mide, no vibes)

cr0x@server:~$ ping -n 50 10.44.12.1
Pinging 10.44.12.1 with 32 bytes of data:
Reply from 10.44.12.1: bytes=32 time=3ms TTL=64
Reply from 10.44.12.1: bytes=32 time=4ms TTL=64
Request timed out.
Request timed out.
Reply from 10.44.12.1: bytes=32 time=5ms TTL=64

Ping statistics for 10.44.12.1:
    Packets: Sent = 50, Received = 48, Lost = 2 (4% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 48ms, Average = 6ms

Qué significa: Ves picos breves de pérdida de paquetes—clásico roam o comportamiento de reintentos RF.
Decisión: Si la pérdida ocurre en ráfagas de 1–3 segundos y se alinea con los logs de eventos, sospecha roaming.
Si es pérdida sostenida sin eventos de roaming, sospecha congestión RF/interferencia o inestabilidad del AP.

Task 10: Traceroute para ver si la “caída” está río arriba

cr0x@server:~$ tracert -d 8.8.8.8
Tracing route to 8.8.8.8 over a maximum of 30 hops

  1     3 ms     2 ms     3 ms  10.44.12.1
  2     6 ms     5 ms     6 ms  10.44.0.1
  3    12 ms    11 ms    13 ms  192.0.2.10
  4    14 ms    13 ms    14 ms  203.0.113.22
  5    16 ms    15 ms    16 ms  8.8.8.8

Trace complete.

Qué significa: Ruta de enrutamiento base. Durante una “caída”, esto puede fallar o cambiar.
Decisión: Si el salto 1 (gateway) falla durante las caídas, es Wi‑Fi/LAN local. Si el salto 1 está bien pero saltos posteriores fallan,
tratas con problemas WAN/VPN/política río arriba.

Task 11: Comprobar flaps en la interfaz VPN (la VPN puede amplificar el dolor del roaming)

cr0x@server:~$ netsh interface show interface
Admin State    State          Type             Interface Name
-------------------------------------------------------------------------
Enabled        Connected      Dedicated        Ethernet
Enabled        Connected      Dedicated        Wi-Fi
Enabled        Disconnected   Dedicated        MyCorp VPN

Qué significa: El estado de la interfaz VPN es visible y puede flaquear durante las transiciones Wi‑Fi.
Decisión: Si la VPN se reconecta justo cuando el Wi‑Fi hace roaming, considera políticas de split tunneling, configuraciones del cliente VPN,
y si la VPN puede tolerar interrupciones cortas de interfaz. A veces la solución es “hacer el roaming más rápido”, no “desactivar roaming”.

Task 12: Validar capacidades Wi‑Fi reportadas por el controlador (aquí empiezan las rarezas 802.11r/ax)

cr0x@server:~$ netsh wlan show drivers
Interface name: Wi-Fi

    Driver                    : Intel(R) Wi-Fi 6 AX201 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 1/12/2025
    Version                   : 23.30.0.6
    Radio types supported     : 802.11b 802.11g 802.11n 802.11ac 802.11ax
    FIPS 140-2 mode supported : Yes
    802.11w Management Frame Protection supported : Yes
    Hosted network supported  : No
    Wireless Display Supported: Yes (Graphics Driver: Yes, Wi-Fi Driver: Yes)

Qué significa: El controlador anuncia estándares y características de seguridad soportadas.
Decisión: Si tu red usa 802.11w u estándares más nuevos, confirma que el cliente los soporte.
Las desalineaciones pueden causar bucles de deauth o patrones de “conectar y luego caer”.

Task 13: Desactivar y volver a activar el adaptador para limpiar un estado atascado (quirúrgico, no supersticioso)

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=disabled
Ok.

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=enabled
Ok.

Qué significa: Reinicias la interfaz sin reiniciar el equipo.
Decisión: Si esto “lo arregla por un rato”, a menudo es una fuga del controlador/firmware o una máquina de estados de roaming atascada.
Usa esto como pista diagnóstica—no como estilo de vida.

Task 14: Comprobar problemas “pegajosos” de DNS tras un roam (las apps dicen que Wi‑Fi se cayó, DNS dice otra cosa)

cr0x@server:~$ nslookup internal-service
Server:  10.44.0.10
Address: 10.44.0.10

Name:    internal-service.corp.example
Address: 10.44.20.15

Qué significa: La resolución DNS funciona ahora mismo.
Decisión: Si el Wi‑Fi “se cae” pero el ping a la puerta de enlace funciona mientras DNS falla, tu problema es resolución de nombres,
interceptación de portal cautivo o política split‑DNS/VPN—no agresividad de roaming.

Controles de Windows que influyen en la estabilidad (y cuáles evitar)

Dónde vive Agresividad de roaming

Usualmente: Device Manager → Network adapters → your Wi‑Fi adapter → Properties → Advanced tab → Roaming Aggressiveness.
A veces se llama “Roaming Sensitivity”, “Roaming Decision” o “Roam Tendency”.
Si no lo ves, tu controlador puede no exponerlo, o tu OEM lo ocultó detrás de un paquete personalizado.

Mi consejo operativo: comienza un escalón por debajo del valor por defecto. Prueba durante un día. Si mejora la estabilidad sin causar “pierdo Wi‑Fi al ir a una sala de reuniones”,
mantenlo. Si causa comportamiento de cliente pegajoso, sube un escalón.

Preferred Band: útil, pero peligroso como solución permanente

Configurar “Preferred Band” a 5 GHz puede reducir problemas de interferencia de 2.4 GHz, que es básicamente un parque público donde todos gritan.
Pero si tu cobertura 5 GHz es irregular, provocarás más roams y enlaces marginales.

Usa preferred band como un interruptor de diagnóstico. Si forzar 5 GHz arregla las caídas, sugiere que tu entorno de 2.4 GHz está congestionado o que el band steering del AP está roto.
Luego arregla la red. No pegues cada portátil a 5 GHz y finjas que “optimizaste”.

Potencia de transmisión: no la subas sin pensar

Incrementar la potencia de transmisión puede hacer que tu cliente “hable más fuerte”, pero no mejora la capacidad del AP para escucharte si la potencia de transmisión y sensibilidad del AP no coinciden.
Puedes crear enlaces asimétricos: el cliente escucha bien al AP; el AP no escucha bien al cliente. Eso produce reintentos, caídas de tasa y la ilusión de “desconexiones aleatorias”.

Gestión de energía: la casilla que arruina tu tarde

El clásico: “Permitir que el equipo apague este dispositivo para ahorrar energía”. No siempre es la causa directa, pero puede amplificar problemas del controlador.
Para diagnosticar, desactívala. Si la estabilidad mejora, entonces decides si la duración de batería importa más que no caerse durante llamadas.

Modo 802.11ax y funciones tipo “Throughput Booster”

A veces deshabilitar 802.11ax (forzar 802.11ac) es una solución legítima cuando un firmware de AP y un controlador cliente no se llevan bien sobre OFDMA o comportamiento de ahorro de energía.
No es elegante. A veces es efectivo.

Los conmutadores “booster” del proveedor suelen ser un eufemismo para “ignorar equidad e intentar acaparar airtime”. En redes concurridas, eso puede empeorar la experiencia de todos.
Si estás solucionando estabilidad, desactiva primero los boosters.

Controles del AP y la red que provocan mal comportamiento en Windows

Band steering: cuando “inteligente” es solo terco

Band steering funciona rechazando asociaciones en una banda, retrasando respuestas o deautenticando clientes para “animarlos” a moverse.
Eso no es roaming; es coerción. Windows puede reaccionar mal—especialmente si la agresividad de roaming también es alta y el cliente sigue escaneando.

Si ves deauths repetidos, considera aflojar la agresividad del steering, separar SSIDs para una prueba o desactivar steering en un subconjunto de APs.
En entornos corporativos, el band steering suele ser menos predecible que diseñar una cobertura 5 GHz adecuada.

802.11r (Fast BSS Transition): genial cuando es consistente, horrible cuando está medio habilitado

802.11r puede reducir significativamente el tiempo de roaming, lo cual importa para voz y aplicaciones en tiempo real.
El problema es las implementaciones parciales: algunos APs lo soportan, otros no; algunos clientes sí, otros no; y obtienes fallos intermitentes que parecen “aleatorios”.

Trata 802.11r como un flag de característica: o lo despliegas correctamente y pruebas clientes, o lo mantienes apagado.
El estado “algo activado” es donde nacen los tickets.

802.11k/v: informes de vecinos y steering de cliente

802.11k ayuda a los clientes a encontrar candidatos de roaming más rápido. 802.11v puede sugerir a los clientes que se muevan.
Windows y los controladores varían en cómo usan estas pistas. Si tu AP es demasiado insistente con 11v, puedes provocar roams que el cliente no necesitaba.

Canales DFS: poderosos y a veces una trampa

Los canales DFS (en 5 GHz) pueden ofrecer espectro más limpio, pero vienen con requisitos de detección de radar.
Cuando un AP detecta radar (o cree detectarlo), debe abandonar el canal. Los clientes se desconectan y reconectan en otro lugar. Los usuarios lo llaman “desconexiones aleatorias”.

Si las caídas ocurren en racimos y afectan a múltiples clientes simultáneamente, investiga eventos DFS en el AP/controlador.
La “solución” puede ser mover SSIDs críticos fuera de DFS en regiones propensas a radar, no cambiar la agresividad de roaming.

RSSI mínimo y desautenticación forzada

Algunas redes aplican RSSI mínimo expulsando clientes por debajo de un umbral.
Bien hecho, reduce clientes pegajosos. Mal hecho, crea un efecto ping‑pong: expulsa al cliente, se reconecta, lo expulsan otra vez.

Windows con alta agresividad de roaming más un RSSI mínimo agresivo es la tormenta perfecta. Ajusta uno u otro, no ambos al “máximo rigor”.

Temporizadores de reauth de WPA2‑Enterprise y latencia RADIUS

Si fuerzas reautenticaciones frecuentes, crearás “caídas” periódicas que se correlacionan con tus temporizadores.
Si la ruta RADIUS es lenta o se congestiona ocasionalmente, esas reauths fallarán intermitentemente.
El cliente parece culpable; el backend de autenticación es quien falla.

Tres microhistorias corporativas desde las trincheras del roaming

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

Una empresa mediana desplegó una nueva red Wi‑Fi 6 en dos pisos. El piloto fue bien: unos pocos portátiles de TI, algunos teléfonos, tráfico de prueba moderado.
Luego volvió el resto de la oficina. Empezaron a caer las llamadas y el tablero de helpdesk se iluminó como un árbol de Navidad.

La suposición fue sencilla y errónea: “Si la señal es fuerte en todas partes, el roaming será estable.”
El plano tenía buen RSSI, pero el plan de canales creó fuerte contención co‑canal en la oficina abierta. Los clientes veían múltiples APs “buenos” todo el tiempo.
Los portátiles Windows con configuración de roaming por defecto seguían encontrando candidatos “ligeramente mejores” y saltando.

El equipo persiguió la capa equivocada durante dos días. Reemplazaron un firewall de borde (dos veces), cambiaron un circuito de ISP y discutieron sobre DNS.
La pista estuvo en los logs de WLAN AutoConfig: los eventos de roam se alineaban perfectamente con las caídas de llamadas, aun cuando el SSID nunca cambió.

La solución no fue heroica. Redujeron la superposición de canales, ajustaron la potencia de transmisión de los AP para reducir el tamaño de las celdas y afinaron la agresividad de roaming del cliente un escalón en el modelo más afectado.
Las llamadas dejaron de caer. La red no se volvió “más fuerte”. Se volvió más tranquila.

Microhistoria 2: La optimización que se volvió contra ellos

Otra organización tenía un brillante despliegue mesh Wi‑Fi en una oficina renovada—paredes de vidrio, techos expuestos, todo el catálogo moderno.
Alguien activó un band steering agresivo porque “5 GHz es más rápido” y fijó una política de RSSI mínima porque “los clientes pegajosos son malos”.
Dos ideas razonables, combinadas en un resultado irrazonable.

Portátiles cerca del borde de cobertura se asociaban a 5 GHz, eran empujados, luego expulsados cuando el RSSI bajaba por un momento.
Caían a 2.4 GHz, volvían a ser steerados, y así repetían. Los usuarios describían “el Wi‑Fi se muere cada vez que me levanto”.
Lo cual sonaba ridículo hasta que lo reproducimos empujando una silla hacia atrás.

El contragolpe fue psicológico también: la red “parecía” optimizada en papel—más asociaciones 5 GHz, menos clientes de “bajo RSSI”.
Mientras tanto, la experiencia humana era un carrusel de reconexiones. Fue una optimización orientada a una métrica, no a un nivel de servicio.

La recuperación fue aflojar el band steering, elevar el umbral de RSSI mínimo solo donde la cobertura era realmente densa, y dejar de forzar a los clientes a tomar decisiones perfectas en RF imperfecto.
También estandarizaron versiones de controladores Windows porque una línea de portátiles tenía un bug de bucle de roaming que empeoró todo.

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

Una firma financiera tenía una política: siempre que se reportaban problemas Wi‑Fi, el primer respondedor debía recopilar los mismos tres artefactos—informe WLAN, logs de AutoConfig y una muestra de ping/pérdida de 10 minutos al gateway.
Sin excepciones. La gente refunfuñaba porque parecía lento. Era lo contrario: evitaba búsquedas fantasmas de semanas.

Un lunes, los traders empezaron a reportar “desconexiones aleatorias de Wi‑Fi”. Pánico, porque los pisos de trading no tienen paciencia.
El primer respondedor siguió el guion aburrido. El informe WLAN mostró desconexiones simultáneas en múltiples clientes en las mismas marcas de tiempo.
Eso descartó inmediatamente la “agresividad de roaming de un portátil”.

Los logs apuntaron a vaciados de canal DFS en un clúster de APs. Una fuente de radar cercana había empezado a activar la detección.
El equipo movió el SSID crítico fuera de canales DFS para esa área y programó un estudio RF adecuado.
El incidente se cerró rápido porque la evidencia se recogió consistentemente, no porque alguien tuviera intuición mística sobre Wi‑Fi.

Broma #2: Lo único más aleatorio que el Wi‑Fi es la invitación del calendario para la reunión sobre por qué el Wi‑Fi fue aleatorio.

Hechos e historia interesantes para usar en discusiones

• El roaming Wi‑Fi está diseñado para ser controlado por el cliente: 802.11 históricamente deja las decisiones de roaming a la estación (cliente), no al AP.
• El roaming empresarial temprano era lento: antes de las transiciones rápidas modernas, el roaming WPA2‑Enterprise a menudo requería autenticación completa, causando glitches audibles en VoIP.
• 802.11r existe porque la voz lo demandó: la transición rápida BSS fue impulsada por aplicaciones en tiempo real que no toleran handshakes de varios segundos.
• 2.4 GHz tiene solo tres canales no superpuestos de 20 MHz en muchas regiones: por eso está congestionado aun cuando tus “barras” se ven bien.
• DFS no es “complejidad opcional”, es regulación: los APs deben vaciar ciertos canales si se detecta radar, y eso puede parecer desconexiones masivas.
• RSSI es un instrumento toscamente afinado: muchos clientes aún usan la intensidad de señal como entrada principal de roaming, aunque la interferencia y la utilización de airtime importan más.
• Band steering no es un estándar: muchas implementaciones son comportamientos propietarios encima de las reglas de asociación 802.11.
• 802.11k/v son “pistas”, no órdenes: los clientes pueden ignorarlas, y diferentes pilas de controladores las interpretan de forma distinta.
• Los logs de red de Windows mejoraron con el tiempo: las versiones modernas hacen que los eventos de WLAN AutoConfig y la generación de informes WLAN sean sorprendentemente útiles—si te tomas la molestia de leerlos.

Una idea parafraseada de una voz de fiabilidad que merece ser escuchada: Idea parafraseada: “La esperanza no es una estrategia; mide y verifica.” — atribuida a varios líderes de operaciones, común en prácticas de ingeniería.

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

“Se cae cada 10–20 minutos, como un reloj.”

Causa raíz: temporizadores de reauth/reauthenticación periódicos (WPA2‑Enterprise), problemas de renovación DHCP o un ciclo de ahorro de energía del controlador.

Solución: correlaciona marcas de tiempo en los logs de WLAN AutoConfig y el informe WLAN. Si los eventos EAP se alinean, ajusta temporizadores de reauth y valida la salud de RADIUS.
Si DHCP se alinea, inspecciona el comportamiento del lease y la puerta de enlace. Si ninguno se alinea, prueba con el ahorro de energía del adaptador desactivado.

“Se cae cuando me muevo entre habitaciones.”

Causa raíz: latencia de roaming, 802.11r mal configurado o comportamiento de cliente pegajoso.

Solución: en enterprise, valida la consistencia de 11r y caché PMK; en mesh de consumo, considera separar SSIDs para pruebas.
Si el roam ocurre demasiado tarde, sube la agresividad de roaming ligeramente; si ocurre con demasiada frecuencia, bájala.

“Señal fuerte, pero Teams sigue reconectando.”

Causa raíz: contención co‑canal, reintentos o churn por band steering; RSSI se ve bien mientras el airtime está saturado.

Solución: compara las tasas de enlace a lo largo del tiempo y busca eventos de roaming. Reduce la agresividad del band steering, ajusta el plan de canales y evita canales excesivamente anchos en áreas densas.

“Solo con batería, es horrible.”

Causa raíz: modo de ahorro del adaptador y/o configuración del plan de energía de Windows.

Solución: configura Wireless Adapter Settings en Maximum Performance en batería para una prueba; desactiva la casilla de ahorro de energía del NIC en Device Manager; vuelve a probar.

“Empezó después de que activamos WPA3 / protección de tramas de gestión.”

Causa raíz: brechas de compatibilidad cliente/controlador, o problemas de configuración en modo mixto.

Solución: valida netsh wlan show drivers para capacidades y estandariza versiones de controladores. Considera ejecutar WPA2 únicamente en un SSID de prueba para confirmar.

“Se cae para todos a la vez.”

Causa raíz: reinicio/caída del AP, vaciado de canal DFS, problema de controlador, interrupción LAN/WAN río arriba.

Solución: deja de tocar clientes. Extrae logs del AP/controlador para eventos DFS, reinicios o cambios de canal. Confirma la salud del gateway y errores en puertos del switch.

“Solo en un modelo de portátil.”

Causa raíz: regresión de versión de controlador, paquete de controlador OEM personalizado o incompatibilidad de características avanzadas.

Solución: compara versiones de controlador vía pnputil. Haz rollback o estandariza. Desactiva funciones avanzadas como throughput boosters para ese modelo.

“Se ‘corta’ pero Wi‑Fi sigue mostrando conectado.”

Causa raíz: fallos de DNS, interceptación de portal cautivo, renegociación del túnel VPN o enrutamiento/política río arriba.

Solución: prueba ping al gateway + lookup DNS durante el evento. Si el ping al gateway está bien pero DNS falla, arregla DNS/split‑DNS de VPN/reglas de portal cautivo.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar un portátil Windows que “se cae aleatoriamente”

1. Captura evidencia primero.
   Genera el informe WLAN y extrae los últimos 10–50 eventos de AutoConfig. Anota la marca de tiempo de la caída visible para el usuario.
2. Confirma si es roaming.
   Comprueba si el BSSID cambia alrededor del evento. Si sí, hay roaming. Si no, mira ahorro de energía, reintentos y capa IP.
3. Desactiva los sospechosos fáciles para una ventana de prueba controlada (30–60 minutos).
   Quita la casilla de ahorro de energía del adaptador; establece Wireless Adapter Settings en Maximum Performance; desactiva cualquier función “booster”.
4. Ajusta Agresividad de roaming un escalón.
   Si los roams son frecuentes sin movimiento, baja. Si el cliente se aferra a un AP débil mientras caminas, súbela (con cuidado).
5. Prueba supuestos de band steering.
   Si estás en mesh de consumo, separa temporalmente SSIDs por banda. Si la estabilidad mejora, tu steering es el problema, no Windows.
6. Estandariza versiones de controladores.
   Elige un controlador conocido como bueno para tu entorno. Actualiza/haz rollback en el cohort afectado, no en un caso aislado.
7. Si es 802.1X enterprise: valida temporizadores de reauth, latencia RADIUS y características de roaming rápido (11r/OKC/caché PMK).
8. Tras los cambios, revisa los logs de nuevo.
   Quieres menos eventos de desconexión, menos thrash de roaming y ráfagas de pérdida de paquetes reducidas.

Checklist: señales de que debes ajustar la agresividad de roaming (lado cliente)

• Los roams ocurren mientras el usuario está estacionario.
• Múltiples APs visibles con señales similares (despliegue denso, oficina abierta).
• Eventos de desconexión/reconexión muestran desconexiones iniciadas por el driver sin pérdida RF obvia.
• Band steering está habilitado y el cliente cambia frecuentemente de canal/banda.

Checklist: señales de que debes dejar de tocar el cliente y arreglar la red

• Muchos clientes se caen simultáneamente.
• Los logs del AP muestran vaciados DFS, reinicios o cambios de canal en los tiempos de caída.
• La alcanzabilidad del gateway falla para cableados e inalámbricos al mismo tiempo.
• Errores RADIUS/autenticación aparecen en varios usuarios durante la misma ventana.

Preguntas frecuentes

1) ¿Dónde exactamente está “Agresividad de roaming” en Windows?

Normalmente en Device Manager → Network adapters → (tu adaptador Wi‑Fi) → Properties → Advanced tab.
Si no está allí, tu paquete de controlador/OEM puede no exponerlo. En ese caso, la elección de versión de controlador importa aún más.

2) ¿Qué ajuste debo elegir: Lowest, Medium, Highest?

Para un portátil atado a un escritorio en una red estable, un escalón por debajo del valor predeterminado es un buen punto de partida.
Lowest puede crear problemas de clientes pegajosos si te mueves. Highest tiende a crear churn de roaming en despliegues densos.

3) ¿Por qué se cae incluso con señal al 80–90%?

Porque la intensidad de señal no es lo mismo que la calidad del enlace. La congestión, la interferencia, los reintentos y la carga del AP pueden hacer que un enlace de señal fuerte funcione mal.
Windows puede hacer roaming persiguiendo un “mejor” enlace, creando micro‑cortes en el proceso.

4) ¿Es esto un problema de Windows o de la red Wi‑Fi?

A menudo es una interacción mala de ambos. Windows toma decisiones de roaming; la red influye en las opciones y a veces empuja a los clientes.
Si muchos clientes se caen juntos, probablemente sea del lado de la red. Si solo modelos específicos se caen, suele ser del lado del controlador/cliente.

5) ¿Debería desactivar 802.11ax (Wi‑Fi 6) para arreglar caídas?

Como prueba temporal, sí—a veces aísla una incompatibilidad driver/AP.
Como solución permanente, no, a menos que hayas confirmado que el entorno no soporta ax de forma fiable y hayas documentado por qué.

6) ¿Separar SSIDs (2.4 y 5 GHz) ayuda?

Puede ayudar. Es una gran herramienta diagnóstica para comprobar churn por band steering.
Para operación a largo plazo, es un trade‑off: más control, pero más confusión de usuarios y más carga de soporte.

7) Mi VPN se cae cuando el Wi‑Fi hace roaming. ¿Es normal?

Es común. Muchos clientes VPN tratan las interrupciones breves de interfaz como “cambio de red” y renegocian.
La solución puede ser roaming más rápido (11r bien implementado) o configuraciones de VPN que toleren breves interrupciones—no solo “desactivar roaming”.

8) ¿Cuál es el mejor log para mirar primero?

El informe WLAN de netsh wlan show wlanreport, porque proporciona una línea de tiempo que puedes correlacionar con el dolor del usuario.
Combínalo con eventos de WLAN AutoConfig para códigos de razón.

9) ¿Podría Bluetooth estar causando las caídas de Wi‑Fi?

A veces, especialmente en 2.4 GHz por problemas de coexistencia. Si forzar 5 GHz o 6 GHz hace que el problema desaparezca,
tienes una pista fuerte. Luego arregla el uso de canales/bandas en lugar de culpar a “Windows por ser Windows”.

10) Si bajo la agresividad de roaming, ¿puedo romper algo?

Puedes crear comportamiento de cliente pegajoso: aferrarse a un AP más débil por más tiempo del ideal, especialmente al caminar.
Por eso lo cambias un paso a la vez y validas con logs y medidas de pérdida.

Siguientes pasos que realmente funcionan

Si quieres el camino más corto a menos “caídas” de Wi‑Fi, haz esto en orden:

1. Genera el informe WLAN y extrae eventos de WLAN AutoConfig. Confirma si estás haciendo roaming, desconectándote o solo perdiendo IP/DNS.
2. Ejecuta netsh wlan show interfaces antes y después de una caída. Sigue cambios de BSSID y desplazamientos de canal/tasa.
3. Desactiva temporalmente el ahorro de energía del adaptador y pon Wireless Adapter Settings en Maximum Performance. Si la estabilidad regresa, encontraste una palanca.
4. Ajusta Agresividad de roaming un escalón más bajo si ves thrash de roaming estando estacionario.
5. Si estás en mesh con “smart connect”, prueba separando SSIDs. Si mejora, afina el steering—no sigas castigando al cliente.
6. Estandariza y prueba versiones de controladores Wi‑Fi en tu parque. La aleatoriedad a menudo tiene número de versión.

El roaming no es malvado. Las opciones ocultas no son automáticamente mágicas tampoco.
Pero cuando Windows toma decisiones de roaming en silencio en tu nombre, o instrumentas y lo afinas—o seguirás teniendo “caídas” que en realidad no son aleatorias.