Accueil / Notes techniques / Dépannage de l'authentification sans fil

Les utilisateurs Wi-Fi ne peuvent pas s'authentifier : dépannage Portal, PSK et 802.1X

Un client qui s'associe au SSID puis échoue à se connecter peut être bloqué à l'un de ces quatre maillons — le terminal lui-même, le point d'accès (AP), le contrôleur sans fil (AC), ou le serveur d'authentification derrière lui. Voici l'ordre de diagnostic qui identifie réellement le maillon défaillant, les commandes display et de configuration réelles pour Portal, PSK et 802.1X, ainsi que les causes qui expliquent la plupart de ces tickets.

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

Pourquoi la chaîne compte plus que le message d'erreur

« Mot de passe incorrect » sur un écran de téléphone peut recouvrir quatre pannes totalement différentes — c'est précisément pourquoi parcourir la chaîne dans l'ordre bat toute tentative de devinette.

Un client Wi-Fi qui trouve le SSID, s'associe au point d'accès, puis échoue à se connecter, est un problème côté sans fil — la panne se situe dans le lien terminal-AP, le lien AP-AC (contrôleur sans fil), ou le lien AC-serveur d'authentification derrière lui : un serveur Portal pour une redirection web, ou un serveur RADIUS pour le 802.1X. C'est une chaîne différente d'un déploiement filaire, où le client est déjà branché sur un port de commutateur et où la redirection se produit au niveau du routeur ou de la passerelle lui-même — si c'est bien ce cas que vous dépannez, notre note de dépannage de l'authentification Portal sur routeur filaire couvre cette chaîne à la place.

Ce qui suit est la chaîne client-AP-AC-serveur sous forme d'arbre de diagnostic, les vérifications pour chaque étape avec les commandes exactes à exécuter sur un AC/WAC Huawei, les causes qui reviennent sans cesse sur Portal, PSK et 802.1X une fois les premières vérifications passées, et des réponses FAQ tirées du terrain.

Suivez la chaîne avant de toucher à la moindre configuration

L'authentification Wi-Fi se répartit en deux formes : soit aucun serveur n'est impliqué, soit l'AC relaie la requête vers un serveur Portal ou RADIUS quelque part derrière lui.

Placer d'abord le symptôme sur cette chaîne indique quelle section d'étape ci-dessous s'applique réellement, plutôt que de redémarrer l'AP en espérant que ça passe.

Les libellés du schéma restent en anglais par souci de clarté technique.

PSK et l'authentification ouverte se règlent entièrement entre le client et le profil de sécurité de l'AP — aucun aller-retour côté serveur via l'AC. Portal et 802.1X dépendent tous deux du relais réussi d'une requête par l'AC vers un serveur derrière lui, ce qui signifie qu'une incohérence de configuration de part et d'autre de ce relais, pas seulement côté client, peut être la véritable cause.

Parcourir chaque étape

Cinq étapes, cinq ensembles différents de points à vérifier — et la commande qui indique dans laquelle vous êtes réellement bloqué.

Étape 0 — Confirmer que le client atteint bien la politique de sécurité de l'AP

Avant de traquer Portal ou RADIUS, confirmez que le VAP auquel le client s'est associé est bien actif et exécute la politique de sécurité que vous croyez.

Vérifiez display ap all pour confirmer que l'AP est à l'état normal (nor) et en ligne sous le bon groupe d'AP — un AP bloqué en état de défaut ou standby n'acceptera pas correctement l'authentification, quels que soient les profils.
Vérifiez display vap ssid <nom-ssid> pour le SSID que le client tente de rejoindre. Status doit afficher ON ; sinon, le VAP n'a jamais été réellement créé sur cette radio et le client s'associe à rien du tout.
Lisez la colonne Auth type dans la même sortie — elle doit correspondre à ce que vous avez configuré (WPA/WPA2-PSK, WPA2-802.1X, ou Open) et à ce que le client tente réellement. Un client réglé sur WPA2-Personal face à un SSID réellement ouvert (ou l'inverse) échouera avant même d'atteindre Portal ou RADIUS.
Vérifiez la colonne STA pour confirmer qu'au moins une station est réellement associée sur ce VAP — si elle est à 0, le problème est l'association elle-même, pas l'authentification, et relève plutôt d'une investigation RF/canal/association.

<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

Étape 1 — Authentification PSK / ouverte : client ↔ AP uniquement

PSK et l'authentification ouverte ne touchent jamais la configuration côté serveur de l'AC — si cette étape est en cause, la panne est entièrement dans le profil de sécurité et la phrase de passe, rien en aval.

Vérifiez display security-profile name <profil> sur l'AC pour voir la politique de sécurité réellement appliquée — WPA/WPA2 PSK+AES, ou le mode mixte WPA2/WPA3 psk-sae plus récent. Confirmez que c'est bien la même norme que celle attendue par les paramètres réseau du client.
Si le profil de sécurité utilise security wpa-wpa2 psk pass-phrase, la phrase de passe est stockée et affichée sous forme chiffrée — une faute de frappe sur l'AC ou sur la note remise aux utilisateurs finaux n'est pas quelque chose que vous pouvez repérer en relisant la configuration en cours. Ressaisissez délibérément la phrase de passe sur l'AC et redistribuez la valeur en clair, plutôt que de supposer qu'une phrase de passe déjà distribuée est encore correcte.
Vérifiez que le security-profile référencé par le profil VAP correspond réellement au SSID que le client rejoint — dans les réseaux exécutant à la fois un SSID invité ouvert et un SSID employé protégé par PSK sur le même AP, une confusion de liaison VAP-security-profile échangera silencieusement la politique appliquée à chaque SSID.
Si le client est un appareil ancien, confirmez que l'AC n'exécute pas du WPA3 uniquement (SAE) sur ce profil — une ligne mixte wpa2-wpa3 psk-sae est ce qui permet aux clients anciens et récents de se connecter sur un même SSID ; un profil SAE pur exclut tout ce qui ne sait pas faire de 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

Étape 2 — Portal : AC ↔ serveur Portal

Si le client voit la page de connexion mais que tous les identifiants échouent, ou ne voit jamais la page du tout, c'est le tronçon AC-vers-serveur-Portal, pas le client.

Vérifiez display this sous la vue web-auth-server (ou display current-configuration) pour server-ip, port, url et shared-key sur l'AC — ils doivent correspondre exactement à l'adresse d'écoute, au port et au secret partagé propres au serveur Portal, sinon ni l'envoi de l'AC ni les réponses du serveur ne seront approuvés par l'autre partie.
Confirmez que server-detect est activé si vous comptez sur l'échappement Portal — sans cela, une panne du serveur Portal ressemble exactement à une erreur de configuration, puisque l'AC n'a aucun moyen de remarquer que le serveur est injoignable et de basculer en mode ouvert.
Vérifiez que le portal-access-profile référence bien le bon modèle web-auth-server par son nom, et que l'authentication-profile appliqué au VAP référence ce portal-access-profile — un serveur Portal correctement configuré derrière un VAP qui pointe encore vers le mauvais profil d'accès se comporte exactement comme un serveur en panne.
Si le Portal à priorité MAC est utilisé (laissant passer directement les clients à adresse MAC connue sans page de connexion), vérifiez les liaisons mac-access-profile et free-rule-template sur le même authentication-profile — une free-rule manquante pour le serveur Portal ou l'adresse DNS bloque la redirection elle-même avant même que le client n'atteigne la page de connexion.
Confirmez que l'url configurée sur le web-auth-server de l'AC pointe vers une adresse de redirection que le DNS du client peut réellement résoudre et atteindre — un nom d'hôte interne ou une adresse injoignable depuis le VLAN attribué au client produit le même symptôme de page blanche qu'un serveur réellement en panne.

[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

Étape 3 — 802.1X : AC ↔ serveur RADIUS

L'authentification 802.1X échoue entre l'AC et le serveur RADIUS bien plus souvent que sur le supplicant du client — vérifiez le secret partagé et la méthode EAP avant de toucher quoi que ce soit sur le terminal.

Vérifiez radius-server template sur l'AC — les adresses IP d'authentification et de comptabilisation, les ports (1812/1813 par défaut) et shared-key cipher doivent correspondre exactement à l'entrée client propre à cet AC sur le serveur RADIUS.
Confirmez que le authentication-scheme aaa lié au domaine utilise bien authentication-mode radius, et que le domaine lui-même lie à la fois le schéma d'authentification et le bon modèle radius-server — un client peut être envoyé vers un domaine qui ne touche jamais RADIUS si la liaison du domaine est erronée.
Les profils d'accès 802.1X utilisent par défaut l'authentification EAP — confirmez que le serveur RADIUS prend réellement en charge et est configuré pour la méthode EAP envoyée par le supplicant du client (PEAP, EAP-TLS, etc.) ; un serveur RADIUS qui n'attend que du PAP/CHAP rejettera d'emblée toute requête EAP, ce qui ressemble exactement à un mot de passe erroné du côté du client.
Vérifiez que l'authentication-profile appliqué au VAP référence le bon dot1x-access-profile et le bon access-domain force — un profil 802.1X lié au mauvais domaine envoie chaque requête vers un serveur RADIUS jamais informé de ces utilisateurs.

[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

Étape 4 — La connexion réussit, mais le trafic ne passe toujours pas

Un client qui s'authentifie proprement et ne peut toujours rien atteindre n'est plus un problème d'authentification — c'est une question de VLAN, d'ACL ou de portée de free-rule.

Vérifiez le service-vlan configuré sur le profil VAP où le client a atterri — un client authentifié dans le mauvais VLAN métier accède bien au réseau, mais pas aux ressources dont il a besoin.
Pour les déploiements Portal, vérifiez le free-rule-template lié à l'authentication-profile — des règles destinées uniquement à laisser passer le trafic pré-authentification vers le serveur Portal et le DNS peuvent avoir une portée trop large ou trop étroite, exposant des ressources avant la connexion ou bloquant du trafic légitime post-connexion qui correspond par hasard à la même règle.
Vérifiez s'il existe une politique d'isolation utilisateur ou d'ACL appliquée sur l'AC ou le commutateur en amont dont la portée cible le mauvais VLAN ou groupe d'utilisateurs — c'est fréquent après avoir copié un profil qui fonctionnait vers un nouveau SSID sans mettre à jour le VLAN qu'il isole.

[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 causes profondes qui reviennent sans cesse

Une fois que les étapes ci-dessus vous ont indiqué où se situe le problème, ces cinq causes expliquent l'essentiel de ce qui ne va vraiment pas.

1. La phrase de passe PSK ou le mode de sécurité ne correspond pas réellement

SYMPTÔMELe client affiche « authentification échouée » ou « mot de passe incorrect » immédiatement après l'association, même si l'utilisateur est certain que le mot de passe est correct.

CAUSEAvec WPA/WPA2-PSK, la phrase de passe configurée dans security wpa-wpa2 psk pass-phrase est stockée et affichée sous forme chiffrée sur l'AC — une faute de frappe commise lors de la configuration initiale, ou une phrase de passe modifiée sur l'AC mais non communiquée aux utilisateurs, n'est pas quelque chose que vous pouvez repérer en relisant la configuration en cours. Par ailleurs, si le profil a migré vers le mode mixte wpa2-wpa3 psk-sae, un client figé sur des réglages WPA2 pur peut aussi échouer même avec le bon mot de passe.

SOLUTIONRessaisissez délibérément la phrase de passe sur l'AC et redistribuez la valeur en clair, plutôt que de faire confiance à une valeur déjà distribuée ; si des clients anciens échouent après une migration WPA3, confirmez que le profil utilise le mode mixte psk-sae plutôt que SAE seul.

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

2. Serveur Portal injoignable, ou clé partagée non concordante

SYMPTÔMELa page de connexion n'apparaît jamais du tout — le navigateur expire simplement ou ne redirige nulle part — plutôt que d'apparaître et de rejeter un mot de passe correct.

CAUSEL'entrée web-auth-server de l'AC doit correspondre exactement à l'IP d'écoute, au port et à la clé partagée propres au serveur Portal ; une divergence sur l'un des trois signifie que l'envoi de l'AC n'atteint jamais le serveur, ou que la réponse du serveur n'est jamais approuvée. Si server-detect n'est pas activé, une véritable panne du serveur Portal produit le symptôme de page blanche identique, car l'AC n'a aucun battement de cœur lui indiquant que le serveur est en panne.

SOLUTIONComparez côte à côte server-ip, port et shared-key cipher sur l'AC avec la configuration propre du serveur Portal, et activez server-detect afin qu'une véritable panne soit distinguable d'une erreur de configuration.

[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. Le secret partagé RADIUS ou la méthode EAP ne concordent pas

SYMPTÔMELes clients 802.1X restent bloqués sur « authentification en cours » puis échouent, sans erreur évidente côté client pour expliquer pourquoi.

CAUSEradius-server shared-key cipher sur l'AC doit être identique caractère pour caractère au secret partagé configuré pour cet AC en tant qu'entrée client sur le serveur RADIUS ; étant stocké sous forme chiffrée, une divergence n'est pas visible en relisant la propre configuration de l'AC. Par ailleurs, les profils d'accès 802.1X utilisent par défaut l'authentification EAP — si le serveur RADIUS n'est pas configuré pour traiter la méthode EAP spécifique envoyée par le supplicant du client (PEAP, EAP-TLS, EAP-MSCHAPv2), il rejette la requête d'emblée, ce qui ressemble exactement à un mot de passe erroné du côté du client.

SOLUTIONRessaisissez la clé partagée sur l'AC et confirmez-la directement en la comparant à la configuration de l'entrée client du serveur RADIUS, et vérifiez auprès de l'administrateur RADIUS quelle méthode EAP le serveur a réellement configurée pour les requêtes de cet 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. Profil d'authentification lié au mauvais domaine d'accès — ou non lié du tout

SYMPTÔMECertains utilisateurs sur le même SSID s'authentifient sans problème tandis que d'autres sur le même AP physique échouent, ou l'authentification réussit mais les enregistrements de comptabilisation/session n'apparaissent jamais sur le serveur.

CAUSEL'authentication-profile appliqué à un VAP doit lier à la fois le bon profil d'accès (dot1x-access-profile ou portal-access-profile) et le bon access-domain force — c'est le domaine qui rattache réellement une requête à un schéma d'authentification, un schéma de comptabilisation et un modèle de serveur RADIUS ou Portal spécifiques. Un VAP dont l'authentication-profile pointe encore vers un domaine résiduel ou par défaut s'authentifie silencieusement selon le mauvais schéma, ou selon aucun schéma configuré du tout.

SOLUTIONVérifiez sur l'AC le authentication-profile pour le domaine réellement lié via access-domain force, et confirmez que ce domaine lui-même est lié au authentication-scheme, à l'accounting-scheme et au radius-server (ou web-auth-server, pour Portal) attendus.

[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. Trafic post-authentification bloqué par la portée du VLAN, de l'ACL ou de la free-rule

SYMPTÔMELe client s'authentifie avec succès — aucune erreur du tout — et ne peut toujours pas atteindre Internet ni les ressources internes.

CAUSECe n'est plus une panne d'authentification ; c'est le service-vlan configuré sur le profil VAP qui place le client dans le mauvais VLAN, une politique d'isolation utilisateur/ACL ciblant le mauvais groupe, ou — pour les déploiements Portal — un free-rule-template trop restreint pour laisser passer le trafic légitime post-connexion, car il n'a été écrit que pour autoriser le trafic pré-authentification vers le serveur Portal et le DNS.

SOLUTIONConfirmez que service-vlan sur le profil VAP correspond au VLAN dans lequel ce groupe d'utilisateurs est censé atterrir, et passez en revue le free-rule-template ainsi que toute politique d'ACL/isolation à la recherche d'une portée résiduelle d'un profil copié plutôt qu'écrite pour ce 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

Six questions qui reviennent constamment

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse toute prête.

Le client affiche immédiatement « authentification échouée » — comment savoir s'il s'agit de PSK, Portal ou 802.1X sans rien demander de plus à l'utilisateur ?

Vérifiez display vap ssid <nom-ssid> sur l'AC. La colonne Auth type indique la politique de sécurité réellement exécutée sur ce SSID — WPA/WPA2-PSK, WPA2-802.1X, ou Open (ce qui signifie que tout échec ne peut être que Portal, puisqu'il n'y a ni clé ni échange RADIUS pouvant échouer). Ce seul champ élimine immédiatement deux des trois chemins.

Tout le monde sur le SSID échoue en même temps — est-ce plus probablement PSK ou côté serveur ?

Un échec généralisé sur tout le SSID débutant à un moment précis pointe vers le côté serveur de l'AC — le serveur RADIUS, le serveur Portal, ou la liaison clé partagée/domaine entre l'AC et l'un d'eux — plutôt que vers PSK, puisqu'une phrase de passe erronée aurait échoué de façon constante depuis sa configuration, pas soudainement pour tout le monde en même temps.

Un seul utilisateur échoue alors que tous les autres sur le même SSID vont bien — où chercher ?

Ce schéma est presque toujours côté client : une phrase de passe enregistrée obsolète sur cet appareil précis, un supplicant configuré pour la mauvaise méthode EAP, ou (pour le Portal à priorité MAC) une adresse MAC qui ne correspond pas au mac-access-profile comme attendu. Il vaut rarement la peine de toucher au authentication-profile ou à la liaison de domaine de l'AC pour un symptôme touchant un seul utilisateur.

PSK et 802.1X peuvent-ils fonctionner en même temps sur le même AP ?

Oui — chacun est configuré comme son propre SSID avec son propre profil VAP, profil de sécurité et profil d'authentification, tous liés au même groupe d'AP et à la même radio. Un schéma courant est un SSID WPA2/WPA3-PSK pour les invités ou le BYOD à côté d'un SSID WPA2-802.1X pour les appareils d'entreprise gérés, sur le même AP physique.

Qu'est-ce que le Portal à priorité MAC, et pourquoi un réseau l'utiliserait-il ?

C'est un authentication-profile qui lie à la fois un mac-access-profile et un portal-access-profile — les appareils connus (déjà dans la base MAC) sont authentifiés silencieusement par adresse MAC, tandis que les appareils inconnus retombent sur la page de connexion Portal. C'est le moyen habituel de laisser les appareils gérés du personnel contourner le portail captif tout en le poussant toujours vers le trafic invité et BYOD sur le même SSID.

Un client qui échoue au 802.1X apparaît-il aussi comme un échec Portal, ou les deux journaux sont-ils totalement distincts ?

Complètement distincts, car ce sont des liaisons authentication-profile différentes sur des VAP différents — un client tentant de rejoindre un SSID WPA2-802.1X n'atteint jamais du tout le chemin de code du serveur Portal, et inversement. Si vous voyez des erreurs qui ressemblent à un mélange des deux, confirmez d'abord à quel SSID et VAP physiques le client s'est réellement associé ; il est courant de confondre deux SSID voisins pour un seul.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'articule autour du modèle de configuration de l'AC/WAC (contrôleur WLAN) Huawei et des commandes display ap all / display vap ssid / display security-profile qui l'accompagnent, plus la logique de liaison RADIUS/Portal que ce modèle utilise. Si votre contrôleur est d'un autre fournisseur, les commandes exactes changent, mais la chaîne client-AP-AC-serveur et l'ordre dans lequel la vérifier se transposent directement. Elle ne couvre pas les causes au niveau RF de l'échec d'association lui-même (canal, puissance, interférences), les interactions WIDS/confinement de point d'accès pirate, ni les plateformes d'AP gérées dans le cloud qui masquent ces vues CLI derrière une console web.

Bloqué sur un échec de connexion Wi-Fi précis ?

Dites-nous à quelle étape ça bloque — association client-AP, PSK, Portal, ou 802.1X — plus la sortie display vap ssid ou les journaux du serveur RADIUS, et nous vous aiderons à l'interpréter.

WhatsApp un ingénieur →