Un client qui s'authentifie, obtient une adresse IP, puis se déconnecte plus tard n'est pas la même panne qu'un client qui ne se connecte jamais du tout, ou qu'un client qui ne peut pas basculer proprement entre les AP — c'est sa propre catégorie, avec ses propres six causes racines : les défenses WIDS qui se retournent contre votre propre réseau, les échecs de comptabilité, les problèmes de synchronisation Portal, un AP en amont en difficulté, un mauvais réglage radio, et une table DHCP snooping qui se remplit discrètement sur un switch intermédiaire.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
La définition compte ici : il s'agit d'un client qui est passé en ligne — authentifié, a obtenu une adresse IP — et qui a chuté seulement après.
« Déconnexion anormale » est défini avec précision pour une raison : un terminal qui a obtenu une adresse IP puis se déconnecte soudainement. C'est une panne différente d'un client qui ne parvient jamais à se connecter du tout — cela relève d'un problème d'authentification, couvert dans notre note de dépannage Portal/PSK/802.1X — et différente encore d'un client qui se connecte bien mais ne peut pas basculer proprement entre AP, ce qui est un problème de configuration d'itinérance, couvert dans notre note de configuration d'itinérance Wi-Fi. Cette note ne commence qu'après que le client est déjà pleinement en ligne.
Voici les deux formes dans lesquelles la déconnexion soudaine se décompose réellement, les vérifications pour chacune, les six causes racines qui expliquent presque tous ces tickets, et des réponses de FAQ tirées de cas réels de terrain.
Chaque déconnexion soudaine est soit quelque chose qui a délibérément forcé le client hors ligne, soit quelque chose qui s'est silencieusement cassé sous une session qui n'a en réalité jamais été volontairement rompue.
Placer d'abord le symptôme sur cet arbre indique quelles trois causes vérifier en premier, au lieu de deviner parmi les six à la fois.
Les légendes du schéma restent en anglais pour la clarté technique.
La branche de gauche est une fonctionnalité qui fait exactement ce pour quoi elle a été configurée, mais contre la mauvaise cible — WIDS, comptabilité, ou synchronisation Portal forçant délibérément la session hors ligne. La branche de droite est quelque chose de complètement différent qui échoue silencieusement et fait tomber la session Wi-Fi en effet secondaire.
Une seule commande vous en dit beaucoup avant même de toucher au WIDS, au RADIUS, ou à la radio.
<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 insteadUne fois que les vérifications ci-dessus vous ont indiqué dans quelle branche vous êtes, l'une de ces six est presque toujours la véritable réponse.
SYMPTÔMELes clients chutent soudainement et à répétition, mais seulement dans les zones couvertes par des AP proches de la frontière entre deux AC — et seulement quand les deux AC ont WIDS activé.
CAUSELorsque deux AC sont configurés en un seul groupe d'itinérance AC-à-AC et que WIDS est activé sur les deux, le moteur WIDS de chaque AC peut voir les propres AP de l'autre AC comme des radios non reconnues et commencer à les contre-attaquer — en envoyant des trames de désauthentification destinées à des appareils pirates vers des AP qui appartiennent en réalité au même réseau de confiance. Ceci est spécifique aux groupes d'itinérance multi-AC ; un déploiement à un seul AC n'a pas ce mode de défaillance.
CORRECTIFAjoutez les AP de chaque AC à la liste blanche WIDS de l'autre AC, afin qu'aucun contrôleur ne traite les radios légitimes de l'autre comme une cible de contre-attaque.
SYMPTÔMEUn client ou un AP spécifique continue d'être déconnecté, et les alarmes de détection d'attaque WIDS (force brute de clé faible, désauthentification/désassociation usurpée, inondation, IV faible) se déclenchent à répétition pour la même source.
CAUSELa logique de détection fait exactement ce pour quoi elle est conçue — c'est juste qu'un schéma de client légitime mais inhabituellement chargé ou bruyant franchit les mêmes seuils qu'une véritable attaque. Laissée avec les paramètres par défaut, la même source répétée peut aussi générer un flot d'alarmes en double en plus des déconnexions.
CORRECTIFActivez la journalisation de détection d'attaque pour confirmer que c'est bien ce client ou cet AP qui la déclenche, utilisez la fonction de silence de détection pour arrêter les alarmes répétées de la même source pendant votre enquête, et désactivez à nouveau la détection d'attaque une fois le schéma confirmé — la laisser active indéfiniment coûte tout de même en performance.
SYMPTÔMELe client s'authentifie correctement, obtient une adresse IP, semble pleinement en ligne — puis chute peu après, sans aucun symptôme côté radio.
CAUSEL'adresse ou le port du serveur de comptabilité ne correspondent en fait pas des deux côtés, ou le serveur RADIUS ne prend pas en charge ou n'a pas activé la comptabilité du tout — et l'AC traite l'échec de comptabilité lui-même comme une raison de forcer la session hors ligne, même si l'authentification a déjà réussi.
CORRECTIFConfirmez que l'IP et le port du serveur de comptabilité correspondent à la configuration de l'AC, et que la comptabilité est réellement activée sur le serveur RADIUS. Si le serveur RADIUS ne prend pas encore en charge la comptabilité, désactivez la comptabilité dans le modèle de comptabilité, ou configurez une politique de maintien en ligne en cas d'échec de comptabilité pour que l'utilisateur reste connecté quoi qu'il arrive.
SYMPTÔMEdisplay aaa abnormal-offline-record all affiche WEB user synchronize fail comme raison de déconnexion.
CAUSEL'appareil et le serveur Portal n'ont pas réussi à synchroniser les informations utilisateur entre eux, et l'appareil force l'utilisateur hors ligne en conséquence directe de cet échec de synchronisation — indépendamment du fait que la connexion radio du client était correcte tout du long.
CORRECTIFVérifiez si le serveur Portal a réellement la synchronisation d'informations activée ; si le serveur Portal ne prend pas du tout en charge cette fonctionnalité, désactivez la synchronisation d'informations des utilisateurs authentifiés par Portal sur l'appareil au lieu de la laisser forcer les utilisateurs hors ligne.
<HUAWEI> display aaa abnormal-offline-record all
// Offline reason: WEB user synchronize fail -> device-to-Portal-server sync failure, not a radio problemSYMPTÔMELes déconnexions se regroupent sur des AP ou radios spécifiques, sans aucun signal WIDS, comptabilité ou Portal dans les journaux.
CAUSEUn intervalle de balise configuré trop long allonge les propres intervalles de sommeil du client et fait ressembler la reconnexion à une chute ; configuré trop court, il ajoute plutôt une surcharge d'antenne inutile. Séparément, si les radios n'ont jamais été réglées, certains AP peuvent avoir une utilisation de canal élevée ou des canaux qui se chevauchent avec des AP voisins — les deux produisent le même symptôme de type déconnexion par un mécanisme complètement différent.
CORRECTIFAjustez l'intervalle de balise pour correspondre au nombre réel de VAP sur la radio plutôt que de laisser une valeur par défaut dimensionnée pour un autre déploiement, et exécutez le réglage radio (ajustement automatique du canal/de la puissance) pour résoudre l'utilisation du canal et le chevauchement entre AP voisins.
SYMPTÔMELes clients se connectent, obtiennent une adresse, et chutent presque immédiatement après, sur tout le réseau ou sur les ports en aval d'un switch spécifique — sans aucun signal WIDS, comptabilité ou radio pour l'expliquer.
CAUSEUn switch intermédiaire avec dhcp snooping enable configuré conserve une table de liaison de taille fixe. Une fois cette table pleine, le switch cesse complètement de transférer tout paquet DHCP supplémentaire — ainsi, un client qui a déjà un bail perd la capacité de le renouveler, et chute dès que le bail ne peut plus être rafraîchi. Cela se lit exactement comme un problème Wi-Fi, mais la panne réelle est une limite de table sur un switch filaire dans le chemin.
CORRECTIFSi le DHCP snooping n'est pas strictement nécessaire sur ce segment, désactivez-le ; s'il l'est, vérifiez le nombre d'entrées actuel par rapport à la limite de table du snooping de la plateforme plutôt que de le laisser échouer silencieusement. Ne le laissez pas désactivé en permanence sans plan — c'est une fonctionnalité de sécurité contre les serveurs DHCP pirates, pas juste une nuisance.
[Switch] undo dhcp snooping enable
// only if the feature isn't required on this segment -- otherwise size or scope the snooping table insteadTirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Ce sont des catégories de panne différentes avec des correctifs différents. Un client qui ne se connecte jamais échoue à l'authentification — Portal, PSK ou 802.1X — et est couvert dans notre note de dépannage d'authentification sans fil. Cette note ne commence qu'après que le client a déjà une adresse IP et était pleinement en ligne.
Les problèmes d'itinérance concernent un basculement propre entre AP tandis que le client reste connecté tout du long — couvert dans notre note de configuration d'itinérance Wi-Fi. Cette note concerne un client qui reste sur le même AP puis se fait carrément déconnecter, sans aucun basculement impliqué.
Un enregistrement vide signifie que la déconnexion n'était pas un événement de comptabilité ou de synchronisation Portal du point de vue du sous-système AAA. Vérifiez ensuite les journaux WIDS et de détection d'attaque, ainsi que la connectivité propre de l'AP vers son AC — une déconnexion que le sous-système AAA n'a jamais vue se situe généralement plus en amont, dans la radio ou la liaison AP-AC.
La contre-attaque mutuelle entre AP nécessite spécifiquement deux AC dans un groupe d'itinérance, donc un déploiement à un seul AC n'a pas ce mode de défaillance particulier. La détection d'attaque ordinaire peut cependant encore mal réagir sur un seul AC si ses seuils sont trop agressifs pour un réseau réellement chargé — vérifiez les journaux de détection et envisagez la fonction de silence avant d'écarter entièrement le WIDS.
Pas comme correctif permanent. Le DHCP snooping est une fonctionnalité de sécurité qui bloque les serveurs DHCP pirates sur ce segment, et le laisser désactivé rouvre cette exposition. Le meilleur correctif à long terme consiste à dimensionner ou limiter la portée de la table de snooping aux seuls VLAN qui en ont réellement besoin, et à la réactiver une fois le problème de capacité sous-jacent résolu — voir notre note de dépannage DHCP pour la vue d'ensemble.
Un schéma corrélé dans le temps indique quelque chose de planifié ou périodique plutôt qu'un incident radio ponctuel — un balayage de détection d'attaque planifié, une tâche de comptabilité RADIUS par lots, une vague de renouvellements de bail DHCP au changement d'équipe, ou une tâche périodique de scan/réglage radio. Vérifiez les horodatages dans aaa abnormal-offline-record et les journaux WIDS/enregistrement par rapport à toute tâche planifiée avant de supposer que c'est aléatoire.
Cette note s'appuie sur l'architecture WLAN AC/AP de Huawei, son modèle de classification de déconnexion anormale, et les mécanismes aaa abnormal-offline-record, WIDS et DHCP snooping qui la sous-tendent, ainsi que sur les cas de terrain qui les sous-tendent. Elle ne couvre pas en profondeur les causes côté client — le pilote Wi-Fi ou le comportement d'économie d'énergie propre d'un appareil peut produire un symptôme similaire et échappe à ce que le côté réseau peut diagnostiquer — ni les plateformes de contrôleur non-Huawei.
Dites-nous ce qu'affiche display aaa abnormal-offline-record all, s'il s'agit d'un AC ou de deux dans un groupe d'itinérance, et comment les chutes sont regroupées, et nous vous aiderons à cibler.