Início / Notas técnicas / Solução de problemas de autenticação sem fio

Usuários de Wi-Fi não conseguem se autenticar: solução de problemas de Portal, PSK e 802.1X

Um cliente que se associa ao SSID e depois falha ao fazer login pode estar travado em qualquer um de quatro elos — o próprio terminal, o AP, o controlador sem fio (AC), ou o servidor de autenticação por trás dele. Esta é a ordem de diagnóstico que realmente identifica o elo quebrado, os comandos display e de configuração reais para Portal, PSK e 802.1X, e as causas que explicam a maioria desses chamados.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que a cadeia importa mais do que a mensagem de erro

«Senha incorreta» na tela de um celular pode esconder quatro falhas completamente diferentes — por isso percorrer a cadeia em ordem supera qualquer tentativa de adivinhação.

Um cliente Wi-Fi que encontra o SSID, se associa ao AP e depois falha ao fazer login é um problema do lado sem fio — a falha está no elo terminal-AP, no elo AP-AC (controlador sem fio), ou no elo AC-servidor de autenticação por trás dele: um servidor Portal para um redirecionamento web, ou um servidor RADIUS para 802.1X. É uma cadeia diferente de uma implantação cabeada, em que o cliente já está conectado a uma porta do switch e o redirecionamento acontece no próprio roteador ou gateway — se é exatamente esse o cenário que você está investigando, nossa nota de solução de problemas de autenticação Portal em roteadores cabeados cobre essa cadeia.

A seguir está a cadeia cliente-AP-AC-servidor como árvore de diagnóstico, as verificações para cada estágio com os comandos exatos a executar em um AC/WAC Huawei, as causas que aparecem repetidamente em Portal, PSK e 802.1X depois das primeiras verificações, e respostas de FAQ extraídas de casos de campo.

Siga a cadeia antes de mexer em qualquer configuração

A autenticação Wi-Fi se divide em duas formas: nenhum servidor está envolvido, ou o AC está retransmitindo a solicitação para um servidor Portal ou RADIUS em algum ponto atrás dele.

Posicionar primeiro o sintoma nessa cadeia indica qual seção de estágio abaixo realmente se aplica, em vez de reiniciar o AP e torcer para que funcione.

Client / Terminal PSK / Open AP (Fit AP) CAPWAP AC / WAC (Controller) Portal push 802.1X / RADIUS Portal Serverweb-auth-server (web push) RADIUS Serverradius-server template (EAP) Stage 4 · Post-Auth Traffic Blockedservice-vlan · ACL / isolation · free-rule scope Stage 0 · Associationsecurity-profile / auth type mismatch

Os rótulos do diagrama permanecem em inglês para maior clareza técnica.

PSK e a autenticação aberta são resolvidos inteiramente entre o cliente e o perfil de segurança do AP — sem ida e volta a nenhum servidor via AC. Portal e 802.1X dependem de o AC retransmitir com sucesso uma solicitação a um servidor por trás dele, o que significa que uma incompatibilidade de configuração em qualquer lado dessa retransmissão, não apenas no cliente, pode ser a causa real.

Percorrendo cada estágio

Cinco estágios, cinco conjuntos diferentes de itens a verificar — e o comando que revela em qual deles você realmente está travado.

Estágio 0 — Confirmar que o cliente realmente chega à política de segurança do AP

Antes de investigar Portal ou RADIUS, confirme que o VAP ao qual o cliente se associou está realmente ativo e executando a política de segurança que você imagina.

  1. Verifique display ap all para confirmar que o AP está em estado normal (nor) e on-line sob o grupo de AP correto — um AP travado em estado de falha ou standby não aceitará a autenticação corretamente, não importa o que os perfis digam.
  2. Verifique display vap ssid <nome-ssid> para o SSID ao qual o cliente está tentando se conectar. Status deve mostrar ON; caso contrário, o VAP nunca foi realmente criado naquele rádio e o cliente está se associando a nada.
  3. Leia a coluna Auth type na mesma saída — ela deve corresponder ao que você configurou (WPA/WPA2-PSK, WPA2-802.1X, ou Open) e ao que o cliente realmente está tentando. Um cliente configurado como WPA2-Personal contra um SSID que na verdade é aberto (ou o contrário) falhará antes mesmo de chegar ao Portal ou RADIUS.
  4. Verifique a coluna STA para confirmar que pelo menos uma estação está realmente associada nesse VAP — se for 0, o problema é a própria associação, não a autenticação, e pertence a uma investigação de RF/canal/associação.
<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

Estágio 1 — Autenticação PSK / aberta: apenas cliente ↔ AP

PSK e a autenticação aberta nunca tocam a configuração voltada para servidor do AC — se este estágio estiver quebrado, a falha está inteiramente no perfil de segurança e na frase-senha, nada mais adiante.

  1. Verifique display security-profile name <perfil> no AC para ver a política de segurança realmente aplicada — WPA/WPA2 PSK+AES, ou o modo misto mais recente WPA2/WPA3 psk-sae. Confirme que é o mesmo padrão esperado pelas configurações de rede do próprio cliente.
  2. Se o perfil de segurança usa security wpa-wpa2 psk pass-phrase, a frase-senha é armazenada e exibida em forma cifrada — um erro de digitação no AC ou na nota entregue aos usuários finais não é algo perceptível relendo a configuração em execução. Reinsira a frase-senha deliberadamente no AC e distribua novamente o valor em texto simples, em vez de presumir que uma frase distribuída anteriormente ainda está correta.
  3. Verifique se o security-profile referenciado pelo perfil VAP realmente corresponde ao SSID ao qual o cliente está se conectando — em redes que executam tanto um SSID de convidados aberto quanto um SSID de funcionários protegido por PSK no mesmo AP, uma confusão na vinculação VAP-security-profile trocará silenciosamente qual política cada SSID aplica.
  4. Se o cliente for um dispositivo legado, confirme que o AC não está executando apenas WPA3 (SAE) nesse perfil — uma linha mista wpa2-wpa3 psk-sae é o que permite que clientes antigos e novos se conectem a partir de um mesmo SSID; um perfil SAE puro bloqueia qualquer coisa que não suporte 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

Estágio 2 — Portal: AC ↔ servidor Portal

Se o cliente vê a página de login mas todas as credenciais falham, ou nunca vê a página, o problema está no trecho AC-para-servidor-Portal, não no cliente.

  1. Verifique display this na visão web-auth-server (ou display current-configuration) para server-ip, port, url e shared-key no AC — eles precisam corresponder exatamente ao endereço de escuta, porta e segredo compartilhado próprios do servidor Portal, ou o envio do AC e as respostas do servidor não serão confiáveis para nenhum dos lados.
  2. Confirme que server-detect esteja habilitado se você depende do escape do Portal — sem isso, uma queda do servidor Portal parece idêntica a um erro de configuração, já que o AC não tem como perceber que o servidor está inacessível e liberar o tráfego.
  3. Verifique se o portal-access-profile realmente referencia o modelo web-auth-server correto pelo nome, e se o authentication-profile aplicado ao VAP referencia esse portal-access-profile — um servidor Portal corretamente configurado atrás de um VAP que ainda aponta para o perfil de acesso errado se comporta exatamente como um servidor quebrado.
  4. Se o Portal com prioridade MAC estiver em uso (deixando passar diretamente clientes com MAC conhecido sem página de login), verifique as vinculações mac-access-profile e free-rule-template no mesmo authentication-profile — uma free-rule ausente para o servidor Portal ou endereço DNS bloqueia o próprio redirecionamento antes de o cliente chegar à página de login.
  5. Confirme que a url configurada no web-auth-server do AC aponta para um endereço de redirecionamento que o DNS do cliente consiga realmente resolver e alcançar — um nome de host interno ou um endereço inalcançável a partir da VLAN atribuída ao cliente produz o mesmo sintoma de página em branco que um servidor realmente fora do ar.
[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

Estágio 3 — 802.1X: AC ↔ servidor RADIUS

A autenticação 802.1X falha entre o AC e o servidor RADIUS com muito mais frequência do que no suplicante do cliente — verifique o segredo compartilhado e o método EAP antes de mexer em qualquer coisa no terminal.

  1. Verifique radius-server template no AC — os endereços IP de autenticação e contabilização, as portas (1812/1813 por padrão) e shared-key cipher precisam corresponder exatamente à entrada de cliente própria deste AC no servidor RADIUS.
  2. Confirme que o authentication-scheme de aaa vinculado ao domínio realmente usa authentication-mode radius, e que o próprio domínio vincula tanto o esquema de autenticação quanto o modelo radius-server correto — um cliente pode ser enviado para um domínio que nunca toca o RADIUS se a vinculação do domínio estiver errada.
  3. Os perfis de acesso 802.1X usam autenticação EAP por padrão — confirme que o servidor RADIUS realmente suporta e está configurado para o método EAP que o suplicante do cliente está enviando (PEAP, EAP-TLS, etc.); um servidor RADIUS que só espera PAP/CHAP rejeitará de imediato toda solicitação EAP, o que parece idêntico a uma senha errada do lado do cliente.
  4. Verifique se o authentication-profile aplicado ao VAP referencia o dot1x-access-profile correto e o access-domain force correto — um perfil 802.1X vinculado ao domínio errado envia cada solicitação a um servidor RADIUS que nunca foi informado sobre esses usuários.
[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

Estágio 4 — O login é bem-sucedido, mas o tráfego ainda não passa

Um cliente que se autentica corretamente e ainda assim não consegue alcançar nada já não é um problema de autenticação — é uma questão de VLAN, ACL ou escopo de free-rule.

  1. Verifique o service-vlan configurado no vap-profile em que o cliente caiu — um cliente autenticado na VLAN de negócios errada alcança a rede, só não os recursos de que precisa.
  2. Para implantações de Portal, verifique o free-rule-template vinculado ao authentication-profile — regras destinadas apenas a deixar passar o tráfego pré-autenticação até o servidor Portal e o DNS podem ter escopo amplo demais ou estreito demais, expondo recursos antes do login ou bloqueando tráfego legítimo pós-login que por acaso corresponde à mesma regra.
  3. Verifique se há uma política de isolamento de usuários ou ACL aplicada no AC ou no switch upstream cujo escopo aponte para a VLAN ou grupo de usuários errado — isso é comum depois de copiar um perfil que funcionava para um novo SSID sem atualizar a VLAN que ele isola.
[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 raiz que aparecem repetidamente

Depois que os estágios acima indicarem onde está o problema, essas cinco causas explicam a maior parte do que realmente está errado.

1. A frase-senha PSK ou o modo de segurança na verdade não coincidem

SINTOMAO cliente exibe «autenticação falhou» ou «senha incorreta» imediatamente após a associação, mesmo que o usuário tenha certeza de que a senha está correta.

CAUSACom WPA/WPA2-PSK, a frase-senha configurada em security wpa-wpa2 psk pass-phrase é armazenada e exibida em forma cifrada no AC — um erro de digitação cometido na configuração inicial, ou uma frase-senha alterada no AC mas não comunicada aos usuários, não é algo perceptível relendo a configuração em execução. Além disso, se o perfil migrou para o modo misto wpa2-wpa3 psk-sae, um cliente fixado em configurações WPA2 puro também pode falhar mesmo com a senha certa.

SOLUÇÃOReinsira a frase-senha deliberadamente no AC e distribua novamente o valor em texto simples, em vez de confiar em um distribuído anteriormente; se clientes legados falharem após uma migração para WPA3, confirme que o perfil usa o modo misto psk-sae em vez de apenas 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 inacessível, ou a chave compartilhada não corresponde

SINTOMAA página de login nunca aparece — o navegador simplesmente expira ou não redireciona para lugar nenhum — em vez de aparecer e rejeitar uma senha correta.

CAUSAA entrada web-auth-server do AC precisa corresponder exatamente ao IP de escuta, porta e chave compartilhada próprios do servidor Portal; uma incompatibilidade em qualquer um dos três significa que o envio do AC nunca chega ao servidor, ou que a resposta do servidor nunca é confiável. Se server-detect não estiver habilitado, uma queda real do servidor Portal produz o mesmo sintoma de página em branco, porque o AC não tem nenhum heartbeat avisando que o servidor está fora do ar.

SOLUÇÃOCompare lado a lado server-ip, port e shared-key cipher no AC com a própria configuração do servidor Portal, e habilite server-detect para que uma queda real seja distinguível de um erro de configuração.

[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. O segredo compartilhado RADIUS ou o método EAP não coincidem

SINTOMAOs clientes 802.1X ficam travados em «autenticando» e depois falham, sem nenhum erro óbvio do lado do cliente que explique o motivo.

CAUSAradius-server shared-key cipher no AC precisa ser idêntico caractere por caractere ao segredo compartilhado configurado para este AC como entrada de cliente no servidor RADIUS; por ser armazenado em forma cifrada, uma incompatibilidade não é visível relendo a própria configuração do AC. Além disso, os perfis de acesso 802.1X usam autenticação EAP por padrão — se o servidor RADIUS não estiver configurado para tratar o método EAP específico enviado pelo suplicante do cliente (PEAP, EAP-TLS, EAP-MSCHAPv2), ele rejeita a solicitação de imediato, o que parece idêntico a uma senha errada do lado do cliente.

SOLUÇÃOReinsira a chave compartilhada no AC e confirme-a diretamente contra a configuração da entrada de cliente do servidor RADIUS, e confirme com o administrador do RADIUS qual método EAP o servidor realmente tem configurado para as solicitações deste 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 autenticação vinculado ao domínio de acesso errado — ou não vinculado de forma alguma

SINTOMAAlguns usuários no mesmo SSID se autenticam bem enquanto outros no mesmo AP físico falham, ou a autenticação é bem-sucedida mas os registros de contabilização/sessão nunca aparecem no servidor.

CAUSAO authentication-profile aplicado a um VAP precisa vincular tanto o perfil de acesso correto (dot1x-access-profile ou portal-access-profile) quanto o access-domain force correto — o domínio é o que realmente amarra uma solicitação a um esquema de autenticação, um esquema de contabilização e um modelo de servidor RADIUS ou Portal específicos. Um VAP cujo authentication-profile ainda aponta para um domínio residual ou padrão se autentica silenciosamente com o esquema errado, ou sem nenhum esquema configurado.

SOLUÇÃOVerifique no AC o authentication-profile para o domínio realmente vinculado com access-domain force, e confirme que esse domínio em si está vinculado ao authentication-scheme, ao accounting-scheme e ao radius-server (ou web-auth-server, para Portal) esperados.

[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áfego pós-autenticação bloqueado pelo escopo de VLAN, ACL ou free-rule

SINTOMAO cliente se autentica com sucesso — sem nenhum erro — e ainda assim não consegue alcançar a internet nem os recursos internos.

CAUSAIsso já não é uma falha de autenticação; é o service-vlan configurado no vap-profile colocando o cliente na VLAN errada, uma política de isolamento de usuários/ACL com escopo no grupo errado, ou — em implantações de Portal — um free-rule-template estreito demais para deixar passar o tráfego legítimo pós-login, porque foi escrito apenas para permitir o tráfego pré-autenticação até o servidor Portal e o DNS.

SOLUÇÃOConfirme que service-vlan no vap-profile corresponde à VLAN em que este grupo de usuários deve cair, e revise o free-rule-template e qualquer política de ACL/isolamento em busca de escopo residual de um perfil copiado em vez 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

Projetos de soluções relacionadas

Seis perguntas que surgem constantemente

Extraídas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.

O cliente exibe imediatamente «autenticação falhou» — como saber se é PSK, Portal ou 802.1X sem perguntar mais nada ao usuário?

Verifique display vap ssid <nome-ssid> no AC. A coluna Auth type informa a política de segurança realmente em execução nesse SSID — WPA/WPA2-PSK, WPA2-802.1X, ou Open (o que significa que qualquer falha só pode ser Portal, já que não há chave nem troca RADIUS que possa falhar). Esse único campo elimina imediatamente dois dos três caminhos.

Todos no SSID falham ao mesmo tempo — é mais provável que seja PSK ou do lado do servidor?

Uma falha em todo o SSID que começa em um momento específico aponta para o lado do servidor do AC — o servidor RADIUS, o servidor Portal, ou a vinculação de chave compartilhada/domínio entre o AC e qualquer um deles — em vez de PSK, já que uma incompatibilidade de frase-senha teria falhado consistentemente desde que foi configurada, não subitamente para todos ao mesmo tempo.

Um usuário falha enquanto todos os demais no mesmo SSID estão bem — onde devo procurar?

Esse padrão é quase sempre do lado do cliente: uma frase-senha salva desatualizada naquele dispositivo específico, um suplicante configurado com o método EAP errado, ou (para Portal com prioridade MAC) um endereço MAC que não corresponde ao mac-access-profile como esperado. Raramente vale a pena mexer no authentication-profile ou na vinculação de domínio do AC por um sintoma de um único usuário.

PSK e 802.1X podem rodar ao mesmo tempo no mesmo AP?

Sim — cada um é configurado como seu próprio SSID com seu próprio perfil VAP, perfil de segurança e perfil de autenticação, todos vinculados ao mesmo grupo de AP e rádio. Um padrão comum é um SSID WPA2/WPA3-PSK para convidados ou BYOD ao lado de um SSID WPA2-802.1X para dispositivos corporativos gerenciados, no mesmo AP físico.

O que é Portal com prioridade MAC, e por que uma rede o usaria?

É um authentication-profile que vincula tanto um mac-access-profile quanto um portal-access-profile — dispositivos conhecidos (já no banco de dados MAC) são autenticados silenciosamente por endereço MAC, enquanto dispositivos desconhecidos caem na página de login do Portal. É a forma usual de deixar dispositivos gerenciados da equipe pularem o portal cativo, mantendo-o para convidados e tráfego BYOD no mesmo SSID.

Um cliente que falha no 802.1X também aparece como uma falha de Portal, ou os dois registros são completamente separados?

Completamente separados, porque são vinculações de authentication-profile diferentes em VAPs diferentes — um cliente tentando entrar em um SSID WPA2-802.1X nunca chega ao caminho de código do servidor Portal, e vice-versa. Se você está vendo erros que parecem uma mistura dos dois, confirme primeiro a qual SSID e VAP físicos o cliente realmente se associou; é comum confundir dois SSIDs vizinhos como se fossem um só.

Limites honestos desta nota

Limites honestos desta nota

Esta nota é construída em torno do modelo de configuração do AC/WAC (controlador WLAN) da Huawei e dos comandos display ap all / display vap ssid / display security-profile por trás dele, além da lógica de vinculação RADIUS/Portal que esse modelo usa. Se o seu controlador for de outro fabricante, os comandos exatos mudam, mas a cadeia cliente-AP-AC-servidor e a ordem de verificação se aplicam diretamente. Não cobre as causas em nível de RF da própria falha de associação (canal, potência, interferência), as interações de contenção WIDS/AP não autorizado, nem plataformas de AP gerenciadas na nuvem que escondem essas visões de CLI atrás de um console web.

Travado em uma falha de login Wi-Fi específica?

Conte-nos em qual estágio está travado — associação cliente-AP, PSK, Portal, ou 802.1X — mais a saída de display vap ssid ou os logs do servidor RADIUS, e ajudaremos você a interpretá-los.

WhatsApp com um engenheiro →

Leitura relacionada

Usamos cookies apenas para análises anônimas — sem anúncios, sem rastreamento entre sites.Política de privacidade