Um cliente que se autentica, obtém um endereço IP e só depois cai não é a mesma falha de um cliente que nunca conecta, nem de um que não consegue fazer roaming limpo entre APs — é sua própria categoria, com suas próprias seis causas-raiz: defesas WIDS agindo mal contra a própria rede, falhas de accounting, problemas de sincronização do Portal, um AP upstream com dificuldades, ajuste de rádio ruim, e uma tabela de DHCP snooping se enchendo silenciosamente em um switch intermediário.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
A definição importa aqui: trata-se de um cliente que ficou online — autenticado, obteve um endereço IP — e só depois caiu.
"Desconexão anormal" é definida com precisão por um motivo: um terminal que obteve um endereço IP e então se desconecta repentinamente. Essa é uma falha diferente de um cliente que nunca consegue se conectar — isso é um problema de autenticação, coberto em nossa nota de solução de problemas de autenticação Portal/PSK/802.1X — e diferente também de um cliente que conecta bem mas não consegue fazer handoff limpo entre APs, que é um problema de configuração de roaming, coberto em nossa nota de configuração de roaming Wi-Fi. Esta nota começa apenas depois que o cliente já está totalmente online.
A seguir estão as duas formas em que a desconexão repentina realmente se divide, as verificações para cada uma, as seis causas-raiz que respondem por quase todos esses chamados, e respostas de FAQ tiradas de casos reais de campo.
Toda desconexão repentina é ou algo que forçou deliberadamente o cliente a ficar offline, ou algo que quebrou silenciosamente por baixo de uma sessão que na verdade nunca foi encerrada de propósito.
Colocar primeiro o sintoma nesta árvore indica quais três causas verificar primeiro, em vez de adivinhar entre as seis ao mesmo tempo.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
A ramificação da esquerda é um recurso fazendo exatamente o que foi configurado para fazer, só que contra o alvo errado — WIDS, accounting ou sincronização do Portal forçando a sessão a cair de propósito. A ramificação da direita é algo completamente diferente falhando silenciosamente e derrubando a sessão Wi-Fi como efeito colateral.
Um único comando já diz muito antes mesmo de mexer no WIDS, no RADIUS ou no rádio.
<HUAWEI> display aaa abnormal-offline-record all
// look for an accounting-related reason, or "WEB user synchronize fail"
// an empty result here means the disconnect isn't an AAA/Portal event -- check WIDS, the AP link, or the radio insteadAssim que as verificações acima disserem em qual ramificação você está, uma dessas seis é quase sempre a resposta real.
SINTOMAClientes caem repentina e repetidamente, mas apenas em áreas cobertas por APs perto da fronteira entre duas ACs — e apenas quando ambas as ACs têm WIDS habilitado.
CAUSAQuando duas ACs são configuradas como um único grupo de roaming AC-para-AC e o WIDS está habilitado em ambas, o mecanismo WIDS de cada AC pode ver os próprios APs da outra AC como rádios não reconhecidos e começar a contra-atacá-los — enviando quadros de desautenticação destinados a dispositivos não autorizados para APs que na verdade pertencem à mesma rede confiável. Isso é específico de grupos de roaming multi-AC; uma implantação de AC única não tem esse modo de falha.
CORREÇÃOAdicione os APs de cada AC à whitelist WIDS da outra AC, para que nenhum controlador trate os rádios legítimos do outro como alvo de contra-ataque.
SINTOMAUm cliente ou AP específico continua sendo desconectado, e os alarmes de detecção de ataque do WIDS (força bruta de chave fraca, deauth/disassociation falsificado, inundação, IV fraco) disparam repetidamente para a mesma origem.
CAUSAA lógica de detecção está fazendo exatamente o que foi projetada para fazer — só que um padrão de cliente legítimo mas incomumente ocupado ou ruidoso está cruzando os mesmos limiares que um ataque real cruzaria. Deixada com as configurações padrão, a mesma origem recorrente também pode gerar uma enxurrada de alarmes duplicados além das desconexões.
CORREÇÃOAtive o log de detecção de ataques para confirmar que realmente é esse cliente ou AP que está disparando, use o recurso de silêncio de detecção para parar alarmes repetidos da mesma origem enquanto investiga, e desative a detecção de ataques novamente assim que confirmar o padrão — deixá-la ligada indefinidamente custa sim algum desempenho.
SINTOMAO cliente se autentica bem, obtém um endereço IP, parece totalmente online — e então cai pouco depois, sem nenhum sintoma do lado do rádio.
CAUSAO endereço ou a porta do servidor de accounting na verdade não coincidem nas duas pontas, ou o servidor RADIUS não suporta ou não habilitou o accounting — e a AC trata a própria falha de accounting como motivo para forçar a sessão a ficar offline, mesmo que a autenticação já tenha tido sucesso.
CORREÇÃOConfirme que o IP e a porta do servidor de accounting correspondem à configuração da AC, e que o accounting está realmente habilitado no servidor RADIUS. Se o servidor RADIUS ainda não suportar accounting, desative o accounting no template de accounting, ou configure uma política de permanecer online se o accounting falhar para que o usuário continue conectado de qualquer forma.
SINTOMAdisplay aaa abnormal-offline-record all mostra WEB user synchronize fail como motivo de desconexão.
CAUSAO dispositivo e o servidor Portal não conseguiram sincronizar as informações do usuário entre si, e o dispositivo força o usuário a ficar offline como resultado direto dessa falha de sincronização — independentemente de a conexão de rádio do cliente ter estado bem o tempo todo.
CORREÇÃOVerifique se o servidor Portal realmente tem a sincronização de informações habilitada; se o servidor Portal não suportar o recurso de forma alguma, desative a sincronização de informações de usuários autenticados por Portal no dispositivo em vez de deixá-la forçando os usuários a ficarem offline.
<HUAWEI> display aaa abnormal-offline-record all
// Offline reason: WEB user synchronize fail -> device-to-Portal-server sync failure, not a radio problemSINTOMAAs desconexões se concentram em APs ou rádios específicos, sem nenhum sinal de WIDS, accounting ou Portal nos logs.
CAUSAUm intervalo de beacon configurado longo demais alonga os próprios intervalos de suspensão do cliente e faz a reconexão parecer uma queda; configurado curto demais, em vez disso adiciona sobrecarga de ar desnecessária. Separadamente, se os rádios nunca foram ajustados, APs individuais podem estar com utilização de canal alta ou canais sobrepostos com APs vizinhos — ambos produzem o mesmo sintoma parecido com queda por um mecanismo completamente diferente.
CORREÇÃOAjuste o intervalo de beacon para corresponder ao número real de VAPs no rádio em vez de deixar um padrão dimensionado para outra implantação, e execute o ajuste de rádio (ajuste automático de canal/potência) para resolver a utilização de canal e a sobreposição entre APs vizinhos.
SINTOMAOs clientes se conectam, obtêm um endereço, e caem quase imediatamente depois, em toda a rede ou nas portas downstream de um switch específico — sem nenhum sinal de WIDS, accounting ou rádio para explicar.
CAUSAUm switch intermediário com dhcp snooping enable configurado mantém uma tabela de vinculação de tamanho fixo. Assim que essa tabela se enche, o switch para de encaminhar completamente qualquer outro pacote DHCP — então um cliente que já tem um lease perde a capacidade de renová-lo, e cai no instante em que o lease não pode ser renovado. Isso parece exatamente um problema de Wi-Fi, mas a falha real é um limite de tabela em um switch cabeado no caminho.
CORREÇÃOSe o DHCP snooping não for estritamente necessário nesse segmento, desative-o; se for necessário, verifique a contagem atual de entradas em relação ao limite da tabela de snooping da plataforma em vez de deixá-lo falhar silenciosamente. Não o deixe desabilitado permanentemente sem um plano — é um recurso de segurança contra servidores DHCP não autorizados, não apenas um incômodo.
[Switch] undo dhcp snooping enable
// only if the feature isn't required on this segment -- otherwise size or scope the snooping table insteadTiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
São categorias de falha diferentes com correções diferentes. Um cliente que nunca conecta está falhando na autenticação — Portal, PSK ou 802.1X — e é coberto em nossa nota de solução de problemas de autenticação sem fio. Esta nota começa apenas depois que o cliente já tem um endereço IP e estava totalmente online.
Problemas de roaming tratam de um handoff limpo entre APs enquanto o cliente permanece conectado o tempo todo — coberto em nossa nota de configuração de roaming Wi-Fi. Esta nota trata de um cliente que permanece no mesmo AP e então é desconectado diretamente, sem nenhum handoff envolvido.
Um registro vazio significa que a desconexão não foi um evento de accounting ou sincronização de Portal do ponto de vista do subsistema AAA. Verifique em seguida os logs de WIDS e detecção de ataques, e a própria conectividade do AP com sua AC — uma desconexão que o subsistema AAA nunca viu geralmente está mais a montante, no rádio ou no link AP-AC.
O contra-ataque mútuo entre APs exige especificamente duas ACs em um grupo de roaming, então uma implantação de AC única não tem esse modo de falha específico. A detecção de ataques comum ainda pode disparar erroneamente em uma única AC, porém, se seus limiares forem agressivos demais para uma rede genuinamente ocupada — verifique os logs de detecção e considere o recurso de silêncio antes de descartar o WIDS por completo.
Não como correção permanente. O DHCP snooping é um recurso de segurança que bloqueia servidores DHCP não autorizados nesse segmento, e deixá-lo desligado reabre essa exposição. A melhor correção de longo prazo é dimensionar ou restringir a tabela de snooping apenas às VLANs que realmente precisam dela, e reabilitá-la assim que o problema de capacidade subjacente for resolvido — veja nossa nota de solução de problemas de DHCP para o panorama mais amplo.
Um padrão correlacionado no tempo aponta para algo agendado ou periódico em vez de uma falha de rádio isolada — uma varredura de detecção de ataques agendada, um trabalho de accounting RADIUS em lote, uma onda de renovações de lease DHCP na troca de turno, ou um trabalho periódico de varredura/ajuste de rádio. Verifique os horários em aaa abnormal-offline-record e nos logs de WIDS/registro em relação a qualquer trabalho agendado antes de presumir que é aleatório.
Esta nota se baseia na arquitetura WLAN AC/AP da Huawei, seu modelo de classificação de desconexão anormal, e os mecanismos aaa abnormal-offline-record, WIDS e DHCP snooping por trás dela, além dos casos de campo por trás deles. Não cobre em profundidade as causas do lado do cliente — o próprio driver Wi-Fi de um dispositivo ou comportamento de economia de energia pode produzir um sintoma semelhante e está fora do que o lado da rede pode diagnosticar — nem plataformas de controlador que não sejam da Huawei.
Conte-nos o que display aaa abnormal-offline-record all mostra, se é uma ou duas ACs em um grupo de roaming, e como as quedas estão concentradas, e ajudamos você a restringir.