Inicio / Notas técnicas / Solución de problemas de autenticación inalámbrica

Los usuarios de Wi-Fi no pueden autenticarse: solución de problemas de Portal, PSK y 802.1X

Un cliente que se asocia al SSID y luego falla al iniciar sesión puede estar atascado en cualquiera de cuatro eslabones — el propio terminal, el AP, el controlador inalámbrico (AC), o el servidor de autenticación detrás de él. Este es el orden de diagnóstico que realmente identifica el eslabón roto, los comandos display y de configuración reales para Portal, PSK y 802.1X, y las causas que explican la mayoría de estos casos.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué la cadena importa más que el mensaje de error

«Contraseña incorrecta» en la pantalla de un teléfono puede significar cuatro fallos completamente distintos debajo — por eso recorrer la cadena en orden supera con creces al método de prueba y error.

Un cliente Wi-Fi que encuentra el SSID, se asocia con el AP y luego falla al iniciar sesión es un problema del lado inalámbrico — el fallo está en el enlace terminal-AP, el enlace AP-AC (controlador inalámbrico), o el enlace AC-servidor de autenticación detrás de él: un servidor Portal para una redirección web, o un servidor RADIUS para 802.1X. Es una cadena distinta de un despliegue cableado, donde el cliente ya está conectado a un puerto del switch y la redirección ocurre en el propio router o gateway — si es justamente eso lo que está resolviendo, nuestra nota de solución de problemas de autenticación Portal en routers cableados cubre esa cadena en su lugar.

A continuación se presenta la cadena cliente-AP-AC-servidor como árbol de diagnóstico, las verificaciones para cada etapa con los comandos exactos a ejecutar en un AC/WAC Huawei, las causas que aparecen una y otra vez en Portal, PSK y 802.1X una vez superadas las primeras comprobaciones, y respuestas de FAQ tomadas del campo.

Siga la cadena antes de tocar cualquier configuración

La autenticación Wi-Fi se divide en dos formas: no interviene ningún servidor en absoluto, o el AC está retransmitiendo la solicitud a un servidor Portal o RADIUS en algún punto detrás de él.

Ubicar primero el síntoma en esta cadena indica qué sección de etapa a continuación aplica realmente, en lugar de reiniciar el AP y esperar que funcione.

Las etiquetas del diagrama se mantienen en inglés para mayor claridad técnica.

PSK y la autenticación abierta se resuelven completamente entre el cliente y el perfil de seguridad del AP — sin ida y vuelta hacia ningún servidor a través del AC. Portal y 802.1X dependen ambos de que el AC retransmita con éxito una solicitud a un servidor detrás de él, lo que significa que un desajuste de configuración en cualquiera de los dos lados de ese traspaso, no solo en el cliente, puede ser la causa real.

Recorriendo cada etapa

Cinco etapas, cinco conjuntos distintos de aspectos a revisar — y el comando que indica en cuál está realmente atascado.

Etapa 0 — Confirmar que el cliente realmente llega a la política de seguridad del AP

Antes de perseguir Portal o RADIUS, confirme que el VAP al que se asoció el cliente realmente está activo y ejecutando la política de seguridad que usted cree.

Verifique display ap all para confirmar que el AP está en estado normal (nor) y en línea bajo el grupo de AP correcto — un AP atascado en estado de fallo o standby no aceptará correctamente la autenticación sin importar lo que digan los perfiles.
Verifique display vap ssid <nombre-ssid> para el SSID al que el cliente intenta unirse. Status debe mostrar ON; si no es así, el VAP nunca se creó realmente en esa radio y el cliente se está asociando con nada.
Lea la columna Auth type en la misma salida — debe coincidir con lo que configuró (WPA/WPA2-PSK, WPA2-802.1X, u Open) y con lo que el cliente realmente está intentando. Un cliente configurado en WPA2-Personal contra un SSID que en realidad es abierto (o viceversa) fallará antes incluso de llegar a Portal o RADIUS.
Verifique la columna STA para confirmar que al menos una estación está realmente asociada en ese VAP — si es 0, el problema es la asociación en sí, no la autenticación, y corresponde a una investigación de RF/canal/asociación.

<AC1> display ap all
Total AP information:
nor : normal           [1]
Total: 1
-----------------------------------------------------------------------------------------------------------------------
ID MAC               Name          Group      IP          Type           State STA Uptime
-----------------------------------------------------------------------------------------------------------------------
0    00e0-fc76-e360 area_1           ap-group1 10.23.100.254 AirEngine5776-26 nor 1
-----------------------------------------------------------------------------------------------------------------------

<AC1> display vap ssid wlan-net
WID : WLAN ID
Total: 2
--------------------------------------------------------------------------------
AP ID AP name RfID WID BSSID                   Status Auth type        STA SSID
--------------------------------------------------------------------------------
0    area_1 0 1          00E0-FC76-E360 ON            WPA/WPA2-PSK 1            wlan-net
0    area_1 1 1          00E0-FC76-E370 ON            WPA/WPA2-PSK 0            wlan-net
------------------------------------------------------------------------------------
// Status ON confirms the VAP was created on this radio; Auth type confirms the running security policy; STA is the associated-client count

Etapa 1 — Autenticación PSK / abierta: solo cliente ↔ AP

PSK y la autenticación abierta nunca tocan la configuración orientada a servidor del AC — si esta etapa falla, el fallo está enteramente en el perfil de seguridad y la frase de contraseña, nada más adelante.

Verifique display security-profile name <perfil> en el AC para ver la política de seguridad realmente aplicada — WPA/WPA2 PSK+AES, o el modo mixto más reciente WPA2/WPA3 psk-sae. Confirme que es el mismo estándar que esperan los ajustes de red del propio cliente.
Si el perfil de seguridad usa security wpa-wpa2 psk pass-phrase, la frase de contraseña se almacena y se muestra en forma cifrada — un error de tipeo en el AC o en la nota entregada a los usuarios finales no es algo que pueda detectar releyendo la configuración en ejecución. Vuelva a introducir la frase de contraseña deliberadamente en el AC y entregue de nuevo el valor en texto plano, en lugar de asumir que una frase distribuida previamente sigue siendo correcta.
Verifique que el security-profile referenciado por el perfil VAP realmente coincida con el SSID al que se une el cliente — en redes que ejecutan a la vez un SSID de invitados abierto y un SSID de personal protegido con PSK en el mismo AP, una confusión en el enlace VAP-security-profile intercambiará silenciosamente qué política aplica cada SSID.
Si el cliente es un dispositivo antiguo, confirme que el AC no está ejecutando solo WPA3 (SAE) en ese perfil — una línea mixta wpa2-wpa3 psk-sae es lo que permite que clientes antiguos y nuevos se conecten desde un mismo SSID; un perfil SAE puro deja fuera a todo lo que no sepa hacer WPA3.

[AC1] wlan
[AC1-wlan] security-profile name wlan-net
[AC1-wlan-sec-prof-wlan-net] security wpa-wpa2 psk pass-phrase YsHsjx_202206 aes
[AC1-wlan-sec-prof-wlan-net] quit
// mixed WPA2/WPA3 profile that still accepts SAE-capable clients on the same SSID:
[AC1-wlan] security-profile name wlan-net
[AC1-wlan-sec-prof-wlan-net] security wpa2-wpa3 psk-sae pass-phrase YsHsjx_202206 aes

Etapa 2 — Portal: AC ↔ servidor Portal

Si el cliente ve la página de inicio de sesión pero fallan todas las credenciales, o nunca ve la página en absoluto, este es el tramo AC-a-servidor-Portal, no el cliente.

Verifique display this bajo la vista web-auth-server (o display current-configuration) para server-ip, port, url y shared-key en el AC — deben coincidir exactamente con la dirección de escucha, el puerto y el secreto compartido propios del servidor Portal, o el envío del AC y las respuestas del servidor no serán confiados por ninguna de las partes.
Confirme que server-detect esté habilitado si depende del escape de Portal — sin ello, una caída del servidor Portal se ve idéntica a un error de configuración, ya que el AC no tiene forma de notar que el servidor es inalcanzable y abrir el paso.
Verifique que el portal-access-profile realmente referencie la plantilla web-auth-server correcta por su nombre, y que el authentication-profile aplicado al VAP referencie ese portal-access-profile — un servidor Portal correctamente configurado detrás de un VAP que aún apunta al perfil de acceso equivocado se comporta exactamente como uno averiado.
Si se usa Portal con prioridad MAC (dejando pasar directamente a los clientes con MAC conocida sin página de inicio de sesión), verifique los enlaces mac-access-profile y free-rule-template en el mismo authentication-profile — una free-rule faltante para el servidor Portal o la dirección DNS bloquea la propia redirección antes de que el cliente llegue a la página de inicio de sesión.
Confirme que la url configurada en el web-auth-server del AC apunte a una dirección de redirección que el DNS del cliente pueda realmente resolver y alcanzar — un nombre de host interno o una dirección inalcanzable desde la VLAN asignada al cliente produce el mismo síntoma de página en blanco que un servidor realmente caído.

[AC1] web-auth-server server-source all-interface
[AC1] web-auth-server abc
[AC1-web-auth-server-abc] server-ip 172.16.1.1
[AC1-web-auth-server-abc] shared-key cipher YsHsjx_202206
[AC1-web-auth-server-abc] port 50200
[AC1-web-auth-server-abc] url https://172.16.1.1:8445/portal
[AC1-web-auth-server-abc] server-detect
[AC1-web-auth-server-abc] quit
[AC1] portal-access-profile name portal1
[AC1-portal-access-profile-portal1] web-auth-server abc
[AC1-portal-access-profile-portal1] quit
[AC1] free-rule-template name default_free_rule
[AC1-free-rule-default_free_rule] free-rule 1 destination ip 172.16.1.2 mask 24
[AC1-free-rule-default_free_rule] quit
[AC1] authentication-profile name p2
[AC1-authentication-profile-p2] portal-access-profile portal1
[AC1-authentication-profile-p2] mac-access-profile mac1
[AC1-authentication-profile-p2] free-rule-template default_free_rule
[AC1-authentication-profile-p2] access-domain example.com force
// server-ip, port and shared-key must match the Portal server's own listening configuration exactly

Etapa 3 — 802.1X: AC ↔ servidor RADIUS

La autenticación 802.1X falla entre el AC y el servidor RADIUS con mucha más frecuencia que en el suplicante del cliente — verifique el secreto compartido y el método EAP antes de tocar nada en el terminal.

Verifique radius-server template en el AC — las direcciones IP de autenticación y contabilidad, los puertos (1812/1813 por defecto) y shared-key cipher deben coincidir exactamente con la entrada de cliente propia de este AC en el servidor RADIUS.
Confirme que el authentication-scheme de aaa vinculado al dominio realmente use authentication-mode radius, y que el propio dominio vincule tanto el esquema de autenticación como la plantilla radius-server correcta — un cliente puede ser enviado a un dominio que nunca toca RADIUS si el enlace del dominio está mal.
Los perfiles de acceso 802.1X usan por defecto autenticación EAP — confirme que el servidor RADIUS realmente admite y está configurado para el método EAP que envía el suplicante del cliente (PEAP, EAP-TLS, etc.); un servidor RADIUS que solo espera PAP/CHAP rechazará de plano toda solicitud EAP, lo cual se ve idéntico a una contraseña incorrecta desde el lado del cliente.
Verifique que el authentication-profile aplicado al VAP referencie el dot1x-access-profile correcto y el access-domain force correcto — un perfil 802.1X vinculado al dominio equivocado envía cada solicitud a un servidor RADIUS que nunca fue informado sobre estos usuarios.

[AC1] radius-server template radius_huawei
[AC1-radius-radius_huawei] radius-server authentication 10.23.200.1 1812
[AC1-radius-radius_huawei] radius-server accounting 10.23.200.1 1813
[AC1-radius-radius_huawei] radius-server shared-key cipher YsHsjx_202206mc@1
[AC1-radius-radius_huawei] quit
[AC1] aaa
[AC1-aaa] authentication-scheme scheme1
[AC1-aaa-authen-scheme1] authentication-mode radius
[AC1-aaa-authen-scheme1] quit
[AC1-aaa] domain example.com
[AC1-aaa-domain-example.com] authentication-scheme scheme1
[AC1-aaa-domain-example.com] radius-server radius_huawei
[AC1-aaa-domain-example.com] quit
[AC1-aaa] quit
[AC1] dot1x-access-profile name d1
[AC1-dot1x-access-profile-d1] quit
[AC1] authentication-profile name p1
[AC1-authentication-profile-p1] dot1x-access-profile d1
[AC1-authentication-profile-p1] access-domain example.com force
// 802.1X access profiles use EAP authentication by default -- the RADIUS server must support EAP, or every request is rejected

Etapa 4 — El inicio de sesión funciona, pero el tráfico sigue sin pasar

Un cliente que se autentica limpiamente y aun así no puede alcanzar nada ya no es un problema de autenticación — es cuestión de VLAN, ACL o alcance de free-rule.

Verifique el service-vlan configurado en el vap-profile donde recayó el cliente — un cliente autenticado en la VLAN de negocio equivocada alcanza la red, simplemente no los recursos que necesita.
Para despliegues de Portal, verifique el free-rule-template vinculado al authentication-profile — reglas pensadas solo para dejar pasar el tráfico previo a la autenticación hacia el servidor Portal y DNS pueden tener un alcance demasiado amplio o demasiado estrecho, exponiendo recursos antes del inicio de sesión o bloqueando tráfico legítimo posterior al inicio de sesión que coincide por casualidad con la misma regla.
Verifique si hay una política de aislamiento de usuarios o ACL aplicada en el AC o en el switch aguas arriba cuyo alcance apunte a la VLAN o grupo de usuarios equivocado — esto es común después de copiar un perfil que funcionaba a un nuevo SSID sin actualizar la VLAN que aísla.

[AC1] wlan
[AC1-wlan] vap-profile name wlan-net2
[AC1-wlan-vap-prof-wlan-net2] forward-mode tunnel
[AC1-wlan-vap-prof-wlan-net2] service-vlan vlan-id 101
[AC1-wlan-vap-prof-wlan-net2] security-profile wlan-net2
[AC1-wlan-vap-prof-wlan-net2] ssid-profile wlan-net2
[AC1-wlan-vap-prof-wlan-net2] authentication-profile p2
// confirm service-vlan is the VLAN this user group is actually supposed to land on, not a leftover from a copied profile

5 causas raíz que aparecen una y otra vez

Una vez que las etapas anteriores le han indicado dónde está el problema, estas cinco causas explican la mayor parte de lo que realmente falla.

1. La frase de contraseña PSK o el modo de seguridad en realidad no coinciden

SÍNTOMAEl cliente muestra «autenticación fallida» o «contraseña incorrecta» inmediatamente después de la asociación, aunque el usuario esté seguro de que la contraseña es correcta.

CAUSACon WPA/WPA2-PSK, la frase de contraseña configurada en security wpa-wpa2 psk pass-phrase se almacena y se muestra en forma cifrada en el AC — un error de tipeo cometido en la configuración inicial, o una frase de contraseña cambiada en el AC pero no comunicada a los usuarios, no es algo detectable releyendo la configuración en ejecución. Además, si el perfil migró al modo mixto wpa2-wpa3 psk-sae, un cliente fijado a ajustes WPA2 puro también puede fallar aunque la contraseña sea correcta.

SOLUCIÓNVuelva a introducir la frase de contraseña deliberadamente en el AC y entregue de nuevo el valor en texto plano, en lugar de confiar en uno distribuido previamente; si clientes antiguos fallan tras una migración a WPA3, confirme que el perfil usa el modo mixto psk-sae en lugar de solo SAE.

[AC1-wlan] security-profile name wlan-net
[AC1-wlan-sec-prof-wlan-net] security wpa-wpa2 psk pass-phrase YsHsjx_202206 aes

2. Servidor Portal inalcanzable, o la clave compartida no coincide

SÍNTOMALa página de inicio de sesión nunca aparece — el navegador simplemente agota el tiempo o no redirige a ningún lado — en lugar de aparecer y rechazar una contraseña correcta.

CAUSALa entrada web-auth-server del AC debe coincidir exactamente con la IP de escucha, el puerto y la clave compartida propios del servidor Portal; un desajuste en cualquiera de los tres significa que el envío del AC nunca llega al servidor, o que la respuesta del servidor nunca es confiada. Si server-detect no está habilitado, una caída real del servidor Portal produce el mismo síntoma de página en blanco, porque el AC no tiene ningún latido que le indique que el servidor está caído.

SOLUCIÓNCompare lado a lado server-ip, port y shared-key cipher en el AC contra la propia configuración del servidor Portal, y habilite server-detect para que una caída real se distinga de un error de configuración.

[AC1] web-auth-server abc
[AC1-web-auth-server-abc] server-ip 172.16.1.1
[AC1-web-auth-server-abc] shared-key cipher YsHsjx_202206
[AC1-web-auth-server-abc] port 50200
[AC1-web-auth-server-abc] server-detect
// Warning: The shared-key complexity is low. It is recommended that the password contain at least sixteen characters...

3. El secreto compartido RADIUS o el método EAP no coinciden

SÍNTOMALos clientes 802.1X se quedan colgados en «autenticando» y luego fallan, sin ningún error evidente del lado del cliente que explique por qué.

CAUSAradius-server shared-key cipher en el AC debe ser idéntico carácter por carácter al secreto compartido configurado para este AC como entrada de cliente en el servidor RADIUS; al almacenarse en forma cifrada, un desajuste no es visible releyendo la propia configuración del AC. Además, los perfiles de acceso 802.1X usan por defecto autenticación EAP — si el servidor RADIUS no está configurado para manejar el método EAP específico que envía el suplicante del cliente (PEAP, EAP-TLS, EAP-MSCHAPv2), rechaza la solicitud de plano, lo cual se ve idéntico a una contraseña incorrecta desde el lado del cliente.

SOLUCIÓNVuelva a introducir la clave compartida en el AC y confírmela directamente contra la configuración de la entrada de cliente del servidor RADIUS, y confirme con el administrador de RADIUS qué método EAP tiene realmente configurado el servidor para las solicitudes de este AC.

[AC1] radius-server template radius_huawei
[AC1-radius-radius_huawei] radius-server shared-key cipher YsHsjx_202206mc@1
[AC1-radius-radius_huawei] quit
[AC1] dot1x-access-profile name d1
// 802.1X access profiles use EAP authentication by default; confirm the RADIUS server supports the client's EAP method

4. Perfil de autenticación vinculado al dominio de acceso equivocado — o no vinculado en absoluto

SÍNTOMAAlgunos usuarios en el mismo SSID se autentican bien mientras otros en el mismo AP físico fallan, o la autenticación tiene éxito pero los registros de contabilidad/sesión nunca aparecen en el servidor.

CAUSAEl authentication-profile aplicado a un VAP debe vincular tanto el perfil de acceso correcto (dot1x-access-profile o portal-access-profile) como el access-domain force correcto — el dominio es lo que realmente ata una solicitud a un esquema de autenticación, un esquema de contabilidad y una plantilla de servidor RADIUS o Portal específicos. Un VAP cuyo authentication-profile aún apunta a un dominio residual o predeterminado se autentica silenciosamente con el esquema equivocado, o sin ningún esquema configurado en absoluto.

SOLUCIÓNVerifique en el AC el authentication-profile para el dominio realmente vinculado con access-domain force, y confirme que ese dominio en sí esté vinculado al authentication-scheme, al accounting-scheme y al radius-server (o web-auth-server, para Portal) que espera.

[AC1] aaa
[AC1-aaa] domain example.com
[AC1-aaa-domain-example.com] authentication-scheme scheme1
[AC1-aaa-domain-example.com] accounting-scheme scheme2
[AC1-aaa-domain-example.com] radius-server radius_huawei
[AC1-aaa-domain-example.com] quit
[AC1-aaa] quit
[AC1] authentication-profile name p1
[AC1-authentication-profile-p1] dot1x-access-profile d1
[AC1-authentication-profile-p1] access-domain example.com force

5. Tráfico posterior a la autenticación bloqueado por el alcance de VLAN, ACL o free-rule

SÍNTOMAEl cliente se autentica con éxito — sin ningún error — y aun así no puede alcanzar internet ni los recursos internos.

CAUSAEsto ya no es un fallo de autenticación; es el service-vlan configurado en el vap-profile que coloca al cliente en la VLAN equivocada, una política de aislamiento de usuarios/ACL con alcance sobre el grupo equivocado, o — en despliegues de Portal — un free-rule-template demasiado estrecho para dejar pasar el tráfico legítimo posterior al inicio de sesión, porque se escribió solo para permitir el tráfico previo a la autenticación hacia el servidor Portal y el DNS.

SOLUCIÓNConfirme que service-vlan en el vap-profile coincide con la VLAN en la que este grupo de usuarios debe caer, y revise el free-rule-template y cualquier política de ACL/aislamiento en busca de un alcance residual de un perfil copiado en lugar de escrito para este SSID.

[AC1-wlan] vap-profile name wlan-net2
[AC1-wlan-vap-prof-wlan-net2] service-vlan vlan-id 101
[AC1-wlan-vap-prof-wlan-net2] authentication-profile p2

Seis preguntas que surgen constantemente

Tomadas directamente del campo — aquellas para las que vale la pena tener una respuesta lista.

El cliente muestra inmediatamente «autenticación fallida» — ¿cómo sé si es PSK, Portal o 802.1X sin preguntarle nada más al usuario?

Verifique display vap ssid <nombre-ssid> en el AC. La columna Auth type indica la política de seguridad realmente en ejecución en ese SSID — WPA/WPA2-PSK, WPA2-802.1X, u Open (lo que significa que cualquier fallo solo puede ser Portal, ya que no hay clave ni intercambio RADIUS que pueda fallar). Ese único campo descarta de inmediato dos de las tres rutas.

Todos en el SSID fallan a la vez — ¿es más probable que sea PSK o del lado del servidor?

Un fallo generalizado en todo el SSID que comienza en un momento específico apunta al lado del servidor del AC — el servidor RADIUS, el servidor Portal, o el enlace de clave compartida/dominio entre el AC y cualquiera de ellos — en lugar de PSK, ya que un desajuste de frase de contraseña habría fallado consistentemente desde que se configuró, no repentinamente para todos a la vez.

Un usuario falla mientras todos los demás en el mismo SSID están bien — ¿dónde busco?

Ese patrón es casi siempre del lado del cliente: una frase de contraseña guardada obsoleta en ese dispositivo, un suplicante configurado con el método EAP equivocado, o (para Portal con prioridad MAC) una dirección MAC que no coincide con el mac-access-profile como se esperaba. Rara vez vale la pena tocar el authentication-profile o el enlace de dominio del AC por un síntoma de un solo usuario.

¿Pueden PSK y 802.1X funcionar al mismo tiempo en el mismo AP?

Sí — cada uno se configura como su propio SSID con su propio perfil VAP, perfil de seguridad y perfil de autenticación, todos vinculados al mismo grupo de AP y radio. Un patrón común es un SSID WPA2/WPA3-PSK para invitados o BYOD junto a un SSID WPA2-802.1X para dispositivos corporativos gestionados, en el mismo AP físico.

¿Qué es el Portal con prioridad MAC, y por qué lo usaría una red?

Es un authentication-profile que vincula tanto un mac-access-profile como un portal-access-profile — los dispositivos conocidos (ya en la base de datos MAC) se autentican silenciosamente por dirección MAC, mientras que los dispositivos desconocidos caen en la página de inicio de sesión de Portal. Es la forma habitual de dejar que los dispositivos gestionados del personal se salten el portal cautivo mientras se sigue empujando a los invitados y al tráfico BYOD en el mismo SSID.

¿Un cliente que falla en 802.1X también aparece como un fallo de Portal, o los dos registros están completamente separados?

Completamente separados, porque son enlaces de authentication-profile distintos en VAP distintos — un cliente que intenta unirse a un SSID WPA2-802.1X nunca llega en absoluto a la ruta de código del servidor Portal, y viceversa. Si está viendo errores que parecen una mezcla de ambos, confirme primero a qué SSID y VAP físicos se asoció realmente el cliente; es común confundir dos SSID vecinos con uno solo.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se construye alrededor del modelo de configuración del AC/WAC (controlador WLAN) de Huawei y los comandos display ap all / display vap ssid / display security-profile detrás de él, más la lógica de vinculación RADIUS/Portal que usa ese modelo. Si su controlador es de otro fabricante, los comandos exactos cambian, pero la cadena cliente-AP-AC-servidor y el orden en que revisarla se trasladan directamente. No cubre las causas a nivel de RF del propio fallo de asociación (canal, potencia, interferencia), las interacciones de contención WIDS/AP no autorizado, ni las plataformas de AP gestionadas en la nube que ocultan estas vistas de CLI detrás de una consola web.

¿Atascado en un fallo de inicio de sesión Wi-Fi específico?

Cuéntenos en qué etapa está atascado — asociación cliente-AP, PSK, Portal, o 802.1X — más la salida de display vap ssid o los registros del servidor RADIUS, y le ayudaremos a interpretarlo.

WhatsApp a un ingeniero →