f = 1/T
f = 1/T

Résolution des differents problèmes liés au Client Wi-Fi

Type de problèmes rencontrés sur  un réseau Wi-Fi

Introduction

Afin de bien réaliser le troubleshooting des differents problèmes Wi-Fi, l'administrateur (ingénieur) doit avoir au moins les compétences de troubleshooting et aussi savoir les differentes opérations protocolaires du Wi-Fi.

 

Avant de se lancer dans le traitement d’un incident, il est important de connaitre le périmètre (architecture) et le type d’équipement sur lequel on est censé analyser le problème.

 

Une  méthodologie permet de définir le procèss de traitement d’un problème et d’apporter aussi une expérience sur la façon de résoudre les différents problèmes rencontrés.

C’est pour cela, il est important de :

 

  • Identifier le problème (par le biais  des informations obtenues)
  •  Définir l’étendue du problème
  • Définir les  causes  probable du problème
  • Réduire le champ des causes potentiels
  • Créer un plan d’action ou escalader le problème
  • Appliquer le plan de correction (Résolution)
  • Valider la solution
  • Documenter le résultat

Pour résoudre un problème lié à la connection  d’un client en Wi-Fi, on peut utiliser  un  des équipements ci-dessous, en fonction du type d'architecture déployée :

 

  • Controleur
  • Cisco Prime
  • AP Autonome

 

Un certain nombre de questions peut etre posé afin de recueillir des informations qui pourront nous aider pendant la phase des investigations, tel que :

 

  • Quel est le problème rencontré (Description du problème)
  • Quel type de  réseau le client rencontre des problèmes (Authentification)
  • Le client à t’il une adresse ip
  • Quel type d’équipement est utilisé
  • Est-il possible d’avoir l’adresse mac du client (Très important)
  • Dans d’autres cas, chercher le client par son nom 

 

Analyse depuis le controleur

 

Les différents status rencontrés lors de la connexion d’un utilisateur peuvent être :

 

Start à Début du process d’accès au réseau.

802.1X_REQD àClient bloqué au niveau authentification 802.1X (Echec Authentification : mauvais username /Password, ou Compte non autorisé)

DHCP_REQD à Client n’arrive pas à obtenir l’adresse ip (Problème d’adresse ip

RUN à Tout est fonctionnel (Client s’est bien authentifié et a une obtenu une adresse ip).

Input : On peut demander l’adresse mac du client

Pour pouvoir investiguer sur un client qui rencontre des soucis de connexion, il est souhaitable de lui demander l’adresse mac (Conf. Adresse_mac_Peripheriques) de son équipement.

 

Avec l’adresse mac de l’utilisateur, Se connecter sur le Contrôleur.

  1. Monitor
  2. Client
  3. Change Filter
  4. Dans le champ Mac address, renseigner l’adresse Mac du Client
    1. Vous pouvez aussi filtrer par nom ou par adresse mac du client.

 

Dans la page qui s’ouvre, on a les informations concernant le clien:  adresse mac, adresse ip, l’AP d'association, le ssid, le status (associated), auth (YES, s’il est bien authentifié), .. 

  • Si le client à une adresse ip, mais se plaint des lenteurs ou deconnexion :
    • Cliquer sur l’adresse mac
    • Chercher Client Statistics
    • Chercher RSSI /SNR du client

 

Vérifier les valeurs RSSI /SNR, (SI ‘ -75 ‘/ ‘ < 20’ , cela peut signifier

que le client est dans une zone où la  couverture est faible ou qu’il y a beaucoup de

bruits ou voir meme loin de l'AP , ...) .

Demander au client de se deplacer et changer de zone par exemple pour voir si cela

resoud le problème.

  • Se connecter en cli sur le controleur  et taper la commande :
    • Show client detail @mac

Cela permet de voir les details de connexion du client, ainsi les APs voisins  avec leurs differentes puissances vu par le terminal du client.

 

Si l’équipement client voit un autre AP avec un meilleur signal  (RSSI /SNR) que l’AP sur lequel il est raccordé, l’équipement client va alors effectué un roaming sur cette AP.

 

Lancer la commande ci –dessous afin de voir les raisons du roaming du client.

  •  Debug client @mac

Si le problème concerne plusieurs équipements dans une meme  zone , il est probable qu’il y a un problème d’interférence dans cette zone.

Dans ce cas une analyse spectrale peut etre necessaire afin de determiner s’il y a des sources d’interférence (CMX peut aussi etre utiliser pour voir s’il y a des interference tout autour)

 

Dans un premier temps, vérifier la configuration des APs sur le périmètre concerné.

 

  • Wireless
  • Access Points
    • 802.11b/g/n
    • Change filter
    • AP Name : AP sur lequel le client est connecté
    • Find
  • On verifie la puissance et le canal utilisé par l’AP
  • On peut vérifier si l’AP voit les interferences
    • On clique sur le petit triangle à droite et detail
    • Tout en bas de la page on cherhe Persistent Devices

Dans ce cas, on a un Microwave Oven sur le canal 11, avec un Duty cycle de 11 % et un RSSI de -74 dBm

 

N.B : Pour aller plus loin, lancer l’analyse en  mettant  l’AP en mode SE-Connect

 

Lien: Cisco Spectrum Expert

 

  • Si le client n’a pas d’adresse ip (0.0.0.0)
    • Cliquer sur l’adrese MAC
    • Dans le champ : ip address, il y a 0.0.0.0
    • Descendre jusqu’au Policy Manager State :
      • On aura un état parmi ceux décrit en haut.
      • Dans ce cas : DHCP_REQD
      • Vérifier coté configuration PC
      • Vérifier qu’il est en DHCP et non avec une IP Static

 

  • Vérifier qu’il y a des ip de dispo

Sur le server dhcp

 

  • Si policy Manager State est : 802.1X_REQD
    • Vérifier que le client a mis les bons paramètres d’authentification
    • Vérifier si le compte client est bien autorisé à se connecté a ce réseau

 

 

Si le SSID est en FlexConnect , il faut s’assurer que ce dernier soit bien paramétré dans l’AP Group et FlexConnect Group le mapping WLAN / VLAN soit bien défini ,  il faut aussi s’assurer que les APs censés diffuser ce dernier soit bien en FlexConnect Mode

 

 

Troubleshooot depuis la page HOME du WLC

 

A partir de  la  version   8.2 du WLC CISCO, plusieurs diagnostiques Wi-Fi peuvent être réalisés depuis la page Home..

  • Clic sur Home                                                   à

 

La fenêtre est subdivisée en plusieurs parties dont  2 parties plus utilisées pour réaliser les diagnostiques

  • Résumé du réseau (AP et Clients)
  • Bureau (Regroupe les Performances des APs et Clients)

 

Pour la partie troubleshoot, on s’appuie sur Wireless Dashboard.

 

Pour les differentes performances:

Clic sur AP performance

 

  • Indique les performance sur differents APs
    • Les APs ayant les canaux plus chargés
    • Les APs les plus chargés
    • Les APs les plus interférés
    • Les APs qui couvrent plus

 

  • Cliquer sur un graphe (AP) pour avoir plus de detail
  • Cliquer sur Client Performance,
    • Presente les perfomance des clients selon  plusieurs paramètres
      • RSSI (Force du signal)
      • Debit de connexion
      • La qualité du signal
      • Status de connexion
      • Un clic sur une indication affiche le nombre de clients ainsi leur résumé
  • Cliquer sur le client pour avoir plus de detail.

On peut relever plusieurs indications sur le client et on peut aussi lancer la capture des packets sur le client afin de les analyser dans les détails, pour cela :

  • Cliquer sur packet Capture
  • renseigner les packets qu’on veut capturer
  • Renseigner les paramètres du server FTP
  • Renseigner le chemin sur server
  • Cliquer sur Start

On peut relever plusieurs indications sur le client et on peut aussi lancer la capture des packets sur le client afin de les analyser dans les détails, pour cela :

  • Cliquer sur packet Capture
  • Renseigner les packets qu’on veut capturer
  • Renseigner les paramètres du server FTP
  • Renseigner le chemin sur server
  • Cliquer sur Start

Troubleshoot du Client sur un SSID en MODE LOCAL

 

La procédure de  connexion 802.11

 

Ci-dessous les différentes étapes de connexion 802.11 et la separation des roles entre l’AP et le Contrôleur.

 

Debug Client (CLI sur WLC)

 

Le macro debug montre toutes les étapes lors de la connexion du client

On peut lancer le debug sur 10 clients à la fois.

 

(Cisco Controller) >debug client @mac

 

(Cisco Controller) >show debug

 

 

MAC Addr1.................................. @mac

Flex-AP Client Debugging ................... disabledFlex-Group Client Debugging ................ disabled

Debug Flags Enabled:

dhcp packet enabled.

dot11 mobile enabled.

dot11 state enabled

dot1x events enabled.

dot1x states enabled.

mobility client handoff enabled

.pem events enabled.

pem state enabled.

802.11r event debug enabled.

802.11w event debug enabled.

CCKM client debug enabled.

 

Plusieurs debugs existent pour l’analyse d’un client en Wi-Fi  au niveau radio.

Depuis un AP on peut avoir:

 

debug dot11 <do0/do1> monitor addr<client mac address>

debug dot11 <d0/d1> trace print client mgmt. keys rxev txev rcv xmt

debug dot11 wpa-cckm-km-dot1x

debug dot11 events

debug capwap client mgmt

 

Type d’authenfication

 

Pendant la première phase, le client est associé (Open authentification), après l'association vient la phase  d'authentification.

Plusieurs type d'authentification existent:

 

 

Authentification par clé partagée : PSK

 

Si la clé n’est pas identique= Echec authen

Le client ne peut pas se connecté

 

Authentification par clé partagée : PSK

 

Si la clé n’est pas identique= Echec authen

Le client ne peut pas se connecté

 

Authentification via le serveur radius : 802.1x authentication

 

 

L’utilisateur s’authentifie via le serveur radius.

Si mauvais credentials = Echec

 

 

 

Une fois le client authentifié, il procède à la demande d’une adresse ip via le serveur dhcp ou une configuration statique de cette dernière.

 

 

Le WLC peut être défini comme server dhcp ce qui n’est pas recommandé

Il peut être défini comme étant un relai dhcp.

 

 

 

Webauth-Walkthrough

 

Les types de problèmes liés au Webauth

 

  • Pas de résolution DNS
    • Résolution : Vérifier ARP/DNS fonctionne avant toute chose
  • Pas de default Gateway
  • HTTPS redirection activée (Enabled)
  • Le site web utilise beaucoup de cookies, la taille max de http GET est de 2000 byte
  • Le navigateur a des problèmes avec les plugin
  • La requête client se fait sur un autre port
    • Utilisation du proxy web
  • Problème de Certificat (Untrested Cert, OCSP)
    • Resolution : Si webauth est se fait sur un server externe , vérifier que les certificats sont autorisés des deux côtés (WLC & Server externe)
    • Si Preauth ACL est configuré, vérifier que les règles sont bidirectionnelles.
  • Lenteur réseau : session time  très lente

 

 

 

Le debug/capture peuvent aider à déterminer l’origine du problème

 

#debug web-authredirect enable mac <mac addr>

 

#Capture des packets/logs côté client

 

 

Commentaires

Aucune entrée disponible
Veuillez entrer le code.
* Champs obligatoires