Dépannage des problèmes d'interopérabilité client sans fil avec CUWN

Introduction

Ce document décrit les problèmes d'interopérabilité qui surviennent avec la solution Cisco Unified Wireless Network (CUWN). 

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Points d'accès sans fil Cisco
• Contrôleurs LAN sans fil (WLC)
• Périphériques réseau associés

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Remarque : ce document s'adresse aux ingénieurs et administrateurs réseau sans fil expérimentés qui connaissent déjà l'utilisation, la configuration et le dépannage de ces rubriques.

Informations générales

Il peut être courant de constater que, compte tenu des divers périphériques clients qui existent et continuent d'être développés. Divers problèmes peuvent survenir en ce qui concerne l'établissement, la maintenance ou simplement pour tirer le meilleur parti de leur connexion au réseau sans fil et pour prendre en charge l'infrastructure.

Cela peut souvent se traduire par un simple problème de configuration de la part du périphérique client et/ou de l'infrastructure sans fil elle-même. Cependant, dans certains cas, cela peut être attribué à un problème d'interopérabilité concernant un périphérique client spécifique et les composants qui le prennent en charge (demandeur, adaptateur WLAN, pilote sans fil,...), et/ou les points d'accès en question. En tant qu'ingénieurs sans fil, ces problèmes d'interopérabilité offrent l'opportunité d'identifier, de dépanner et de résoudre des problèmes potentiellement complexes.

Ce document décrit en détail les informations qui doivent être collectées initialement pour examiner et résoudre efficacement de tels problèmes d'interopérabilité sans fil lorsqu'ils surviennent avec la solution Cisco Unified Wireless Network (CUWN). La nécessité d'une telle approche globale devient de plus en plus importante avec la croissance constante du nombre et des combinaisons de périphériques clients sans fil et de radios de point d'accès (AP).Des informations supplémentaires à ce qui est décrit dans cet article pourraient être demandées et nécessaires pour être collectées au cas par cas, étant donné le nombre illimité de variables qui pourraient dicter de telles exigences. Cependant, les informations détaillées ici constituent une directive générique pour résoudre tout problème potentiel d'interopérabilité du client sans fil.

I. Définition du problème

La première étape pour aborder efficacement tout problème avec l'intention de le résoudre consiste à définir précisément la question à l'étude. Pour ce faire, assurez-vous qu'au moins ces questions sont posées et que leurs réponses sont clairement documentées :

• Le problème est-il limité à un modèle spécifique de points d'accès et/ou de type radio (2,4 GHz contre 5 GHz) ?
• Le problème est-il observé uniquement sur des versions spécifiques du logiciel WLC ?
• Le problème se pose-t-il uniquement avec des versions spécifiques de type(s) client(s) et/ou de logiciel (version du système d'exploitation, version du pilote WLAN, etc.) ?
• Y a-t-il d'autres périphériques sans fil qui ne rencontrent pas ce problème ? Dans l'affirmative, lesquels ?
• Le problème peut-il être reproduit lorsque le client est connecté à une configuration sans fil simplifiée, telle qu'un SSID ouvert, avec une largeur de canal de 20 MHz et 802.11ac désactivé ? (autrement dit, le problème se produit-il uniquement en mode 802.11n et uniquement en mode 802.11ac ?).
• Si le problème n'est pas reproductible avec un SSID ouvert, à quelle configuration de sécurité minimale le problème est-il détecté ? (PSK ou 802.1X sur le WLAN).
• Quelles étaient les versions précédentes de la configuration et du logiciel, dont le fonctionnement a été vérifié ?

II. Configuration WLC et journaux généraux

Run-Config

Sans exception, il est absolument nécessaire de collecter la configuration du WLC pour un examen détaillé des fonctionnalités utilisées par le client, de leur configuration spécifique, et d'autres détails de ce type. Pour ce faire, vous devez établir une session Telnet/SSH vers le ou les WLC en question et enregistrer le résultat de ces commandes CLI dans un fichier texte :

config paging disable

show run-config

La sortie complète de la configuration d'exécution est toujours préférée, car elle inclut des informations détaillées concernant les points d'accès joints et les informations RF associées. Bien que dans certains cas et situations, comme lorsque vous travaillez initialement avec un WLC avec un grand nombre d'AP joints (8510 WLC avec plus de 2500 AP). Il peut être préférable de collecter initialement uniquement la configuration du WLC sans ces informations d'AP pour une révision rapide, car la commande complète show run-config peut prendre 30 minutes ou plus pour compléter le nombre donné d'AP. Cependant, il peut être nécessaire de collecter la sortie complète de la configuration d'exécution ultérieurement.

Pour ce faire, vous pouvez éventuellement collecter le résultat de ces commandes CLI dans un fichier texte :

config paging disable

show run-config no-ap

show wlan apgroups

Fichier de configuration WLC

En plus de la sortie show run-config ou show run-config no-ap, il est également recommandé de collecter une sauvegarde complète de la configuration WLC. Cela peut s'avérer utile si une recréation de TP doit être effectuée à la fois par le TAC/HTTS et par la remontée des unités opérationnelles, pour tenter de reproduire le problème dans un environnement de TP Cisco. Une sauvegarde du WLC peut être collectée via l'interface graphique ou l'interface de ligne de commande du WLC en question, avec l'utilisation de TFTP ou de FTP pour enregistrer le fichier de configuration sur le serveur TFTP/FTP externe. Cet exemple montre l'utilisation de l'interface graphique et de l'interface de ligne de commande pour enregistrer une sauvegarde du WLC, avec l'utilisation de TFTP :

IUG

Commandes > Télécharger le fichier > Configuration > Télécharger comme indiqué dans l'image.

CLI 

transfer upload datatype config

transfer upload mode tftp

transfer upload serverip <TFTP-Server_IP-address>

transfer upload path /

transfer upload filename <desired-filename>

transfer upload start

Syslogs à partir du WLC

À ce stade, vous souhaitez également collecter les journaux actuels du WLC pour une révision supplémentaire si nécessaire. Idéalement, vous souhaitez collecter ces journaux immédiatement après votre test avec un client sans fil afin de reproduire le problème signalé. Si le client exporte les journaux WLC vers un serveur syslog externe, alors vous voulez les récupérer de là. Sinon, vous pouvez enregistrer le msglog et le traplog actuellement stockés localement sur le WLC en enregistrant cette sortie de session CLI dans un autre fichier texte :

config paging disable

show msglog

show traplog

III. Informations et détails sur le périphérique client

L'étape suivante consiste à recueillir autant d'informations et de détails concernant le ou les périphériques clients utilisés qui rencontrent un problème potentiel d'interopérabilité sans fil. Ces informations doivent inclure, sans s'y limiter, les éléments suivants :

• Type de client (tablette, smartphone, ordinateur portable,...)
• Marque et modèle du périphérique
• version du système d'exploitation
• Modèle de carte WLAN
• Version du pilote de carte WLAN
• Demandeur utilisé (Windows Zero Config / Auto Config, Intel PROSet,...)
• Sécurité configurée pour une utilisation par le client sans fil et le WLAN (Open, PSK, EAP-PEAP/MSCHAPv2,...)
• Notez les paramètres client qui ont été modifiés par rapport aux paramètres par défaut fournis par le fournisseur en question (état de veille, paramètres d'itinérance, U-APSD,...).

Remarque : toute information ou remarque supplémentaire concernant le ou les périphériques clients jusqu'à laquelle inclut des captures d'écran de sa ou ses configurations liées au WLAN, et ainsi de suite, doit également être incluse si nécessaire.

IV. Topologie du réseau

Pour accélérer davantage les efforts de dépannage et le processus d’analyse des causes premières (RCA), il est toujours recommandé de fournir un schéma de topologie de réseau détaillé et complet. Le schéma de topologie du réseau doit non seulement inclure des détails sur le réseau et l'infrastructure sans fil, mais également fournir un aperçu du ou des périphériques sans fil en question qui fonctionnent au sein du réseau (imprimantes/scanners, quels VLAN clients sont utilisés,...) et leur emplacement relatif.

Un certain nombre d'outils (Microsoft Visio, draw.io,...) et une variété de styles peuvent être utilisés pour créer un tel diagramme de réseau. L'important est simplement de s'assurer que les informations appropriées sont clairement reflétées dans le schéma fourni pour examen par toutes les parties et tous les fournisseurs concernés. Exemple de topologie de réseau qui capture des informations de base, mais utiles, relatives à l'infrastructure et aux périphériques clients, comme illustré dans l'image.

V. Suivre les détails supplémentaires et les spécifications

Garantir que les informations appropriées sont collectées au moment de tout test avec le ou les périphériques clients avec lesquels les utilisateurs finaux rencontrent des problèmes. Il est recommandé de créer de manière préventive une feuille de calcul ou similaire pour enregistrer tous les problèmes du client et les détails associés observés au moment du test, comme dans l'exemple suivant :

Adresse MAC :	Nom d’utilisateur	Description des symptômes signalés	Symptôme observé par l'utilisateur final	Envoyez une requête ping à la passerelle par défaut O/N	État du signal WiFi (Connecté/tentative de connexion)	Enregistrer ipconfig /all (ou équivalent)
xxyy.aabb.0011	utilisateur_test1	Se déconnecte par intermittence du point d'accès.	Perte de connectivité réseau et d'association sans fil du point d'accès 3.	n	Tentative de connexion	ifconfig en0 en0 : flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500     éther xx:yy:aa:bb:00:11     inet6 fe80::848:cb8f:881a:4cbf%en0 prefixlen 64 id d'étendue sécurisé 0x4     inet 192.168.10.237 netmask 0xffffff00 broadcast 192.168.10.255     nd6 options=201<PERFORMNUD,DAD>     média : sélection automatique     état : actif

L'objectif de cet exercice est d'aider à documenter et à déterminer un modèle commun d'intérêt, ainsi que d'obtenir une image précise de la ou des questions en jeu. Une fois que cette feuille de calcul est prête à être utilisée pour la collecte de données, vous êtes prêt à commencer vos tests. Voici d'autres considérations, mais néanmoins importantes :

Remarque : tous les débogages et les captures de paquets collectés doivent être synchronisés sur le même serveur NTP pour faciliter la corrélation avec les journaux et doivent être effectués en même temps pour tout test donné.

Remarque : fournissez un horodatage précis du moment où le problème est observé et du moment où le problème semble se résoudre (le cas échéant).

Remarque : collectez toujours les débogages filtrés par adresse MAC client sur le point d'accès et le WLC.

Remarque : n'exécutez pas les commandes show et debug sur l'AP dans la même session Telnet/SSH/console, elles sont effectuées séparément dans une session différente en conséquence.

Remarque : les débogages AP sont préférables sur Telnet/SSH par rapport à la console, car la console est généralement trop lente pour être efficace.

VI. WLC - Commandes Show et Debug

Lorsque des tests sont effectués pour reproduire et dépanner des problèmes potentiels d'interopérabilité client sans fil, il est impératif que des débogages et des journaux supplémentaires soient collectés à partir de l'infrastructure sans fil utilisée. Ces deux sections peuvent expliquer en détail les journaux spécifiques et la sortie de débogage initiale qui est collectée à partir du WLC et des AP, respectivement.

Commandes de débogage WLC

config sessions timeout 0
debug client <MAC_address>
debug dhcp message enable

En ce qui concerne la nature du problème en cours, vous pouvez également ajouter ces débogages WLC au cas par cas :

• debug aaa detail enable - utilisez cette option en cas de problèmes d'authentification avec le serveur AAA
• debug aaa events enable - utilisez cette option en cas de problèmes d'authentification avec le serveur AAA
• debug aaa all enable - utilisez ceci pour les problèmes d'authentification ; le résultat de ce débogage est explicite donc utilisez-le seulement quand absolument nécessaire (pour les cas de priorité AAA,...)
• debug mobility handoff - utilisation en cas de problèmes d'itinérance entre les WLC

Une fois le problème reproduit avec le client sans fil en question, et toutes les informations décrites dans les sections précédentes et suivantes sont collectées et documentées. Afin d'exécuter ces commandes CLI, vous devez désactiver les débogages sur le WLC.

debug disable-all

Commandes show du WLC

config paging disable

show time

show client detail <MAC_address>

ping <client_IP-address> <repeat count [1-100]>

Comme mentionné précédemment, assurez-vous d'exécuter les débogages WLC dans une session Telnet/SSH et de collecter le résultat pour ces commandes show dans une autre session Telnet/SSH vers le WLC. Vous devez faire la même chose pour collecter les résultats des commandes show et debugs AP détaillés dans ces sections.

VII. AP - Commandes Show et Debug

Points d'accès Cisco IOS® légers

Avant de commencer tout débogage sur un ou plusieurs points d'accès Cisco IOS® légers impliqués dans le test, tels que les points d'accès Cisco 2600, 2700, 3700 ou modèles antérieurs. Vous devez d'abord exécuter ces commandes CLI sur le point d'accès, afin d'éviter un délai d'attente au moment d'une session Telnet/SSH/console vers le ou les points d'accès en question lorsque votre client teste :

debug capwap console cli

config t

line vty 0 4

exec-timeout 0

session-timeout 0

Vous pouvez également suivre ces étapes pour utiliser la connexion console et remplacer l'instruction line vty 0 4 par line console 0, afin de désactiver les délais d'exécution et de session pour une connexion série/console en conséquence.

• line console 0 - à utiliser pour modifier les paramètres de délai d'expiration de session série
• line vty 0 4 - à utiliser pour modifier les paramètres de délai d’attente de session Telnet/SSH

Commandes show AP

Avant de commencer le test, vous devez d'abord recueillir un échantillon de ces commandes show sur l'AP. Collectez le résultat de ces commandes show au moins deux fois pour chaque test impliquant le client sans fil en question, avant et après la fin du test.

term len 0

show clock

show tech

show capwap client mn

show int do1 dfs

show logging

more event.log

show trace dot11_rst display time format local

show trace dot11_rst

show trace dot11_bcn display time format local

show trace dot11_bcn 

Commandes de débogage AP

Une fois que vous avez collecté le résultat initial des commandes show mentionnées ci-dessus, vous pouvez maintenant activer les débogages sur le même point d'accès dans une session Telnet/SSH séparée comme indiqué. Veillez à enregistrer l'intégralité du résultat dans un fichier texte.

debug dot11 {d0|d1} monitor addr <client_MAC-address>

debug dot11 {d0|d1} trace print clients mgmt keys rxev txev rcv xmt txfail ba

term mon

Drapeau	Description
d0	Radio 2,4 GHz (logement 0)
D1	Radio 5 GHz (logement 1)
gestion	Tracer les paquets de gestion
barre	Informations ACK du bloc de suivi
RVC	Suivre les paquets reçus
keys	Suivre les touches définies
rxev	Suivre les événements reçus
txev	Suivre les événements de transmission
txrad	Suivre la transmission vers la radio
xmt	Suivre les paquets de transmission
échec fiscal	Suivre les défaillances de transmission
tarifs	Suivre les variations de taux

Pour désactiver les débogages sur l'AP une fois le processus de test et de collecte de données terminé, vous pouvez exécuter cette commande CLI sur l'AP :

u all

Points d'accès AP-COS

Pour les points d'accès compatibles 802.11ac phase 2 et versions ultérieures, tels que les points d'accès modèles 1800, 2800 et 3800. Ces AP de modèle plus récent introduisent un tout nouveau système d'exploitation pour les plates-formes de point d'accès appelées AP-COS. Par conséquent, toutes les commandes précédemment utilisées sur les points d'accès légers traditionnels basés sur Cisco IOS®, comme indiqué précédemment, ne s'appliquent toujours pas. Si, lorsque vous dépannez un problème impliquant un problème d'interopérabilité avec divers périphériques STA client et AP-COS, ces informations doivent être collectées auprès du ou des points d'accès AP-COS impliqués dans le test équivalent.

Avant de commencer tout débogage sur un AP de modèle AP-COS impliqué dans le test. Vous devez d'abord exécuter ces commandes CLI sur le point d'accès, afin d'éviter un délai d'attente au moment d'une session Telnet/SSH/console vers le ou les points d'accès en question lorsque votre client teste :

exec-timeout 0

Commandes show AP-COS

Avant de commencer le test, vous devez d'abord recueillir un échantillon de ces commandes show sur l'AP. Collectez le résultat de ces commandes show au moins deux fois pour chaque test impliquant le client sans fil en question, avant et après la fin du test.

term len 0

show clock

show tech

show client statistics <client_MAC-address>

show cont nss status

show cont nss stats

show log

Gamme 1800 | Commandes de débogage AP-COS

Ces débogages sont spécifiques à la gamme de points d'accès 18xx. Cela est dû au fait que le ou les chipsets utilisés pour la série 1800 de points d'accès diffèrent de ceux trouvés dans les points d'accès de la série 2800/3800, et donc un ensemble différent de débogages sont requis dans ce scénario par comparaison. Les débogages correspondants pour les AP de la gamme 2800/3800 sont traités dans la section suivante.

Une fois que vous avez collecté le résultat initial des commandes show mentionnées ci-dessus, vous devez maintenant activer les débogages sur le(s) même(s) point(s) d'accès 1800 dans une session Telnet/SSH distincte, comme indiqué. Veillez à enregistrer l'intégralité du résultat dans un fichier texte.

debug dot11 client level events addr <client_MAC-address>

debug dot11 client level errors addr <client_MAC-address>

debug dot11 client level critical addr <client_MAC-address>

debug dot11 client level info addr <client_MAC-address>

debug dot11 client datapath eapol addr <client_MAC-address>

debug dot11 client datapath dhcp addr <client_MAC-address>

debug dot11 client datapath arp addr <client_MAC-address>

Dans certains cas, vous devrez peut-être également activer les débogages supplémentaires sur le point d'accès 18xx pour résoudre les problèmes d'interopérabilité client. Toutefois, cette opération ne doit être effectuée que si/comme demandé par un ingénieur du centre d'assistance technique Cisco pour une demande/un dossier de service correspondant.

Comme des débogages supplémentaires peuvent non seulement être beaucoup plus prolixes dans leur sortie, mais peuvent également introduire une charge supplémentaire sur l'AP ainsi donc cela nécessite plus de temps pour une analyse correcte. Ce qui, dans certaines conditions, peut potentiellement perturber le service, si de nombreux périphériques clients tentent de se connecter au même AP sous test ou des variables similaires.

Pour désactiver les débogages sur le point d'accès de variante AP-COS - que ce soit sur un AP de la gamme 1800 ou 2800/3800 - une fois le processus de test et de collecte de données terminé, vous pouvez exécuter cette commande CLI sur l'AP :

config ap client-trace stop 

Gammes 2800/3800 | Commandes de débogage AP-COS

Une fois que vous avez collecté le résultat initial des commandes show mentionnées ci-dessus, vous devez maintenant activer les débogages sur le ou les mêmes points d'accès 2800/3800 dans une session Telnet/SSH distincte, comme indiqué. Veillez à enregistrer l'intégralité du résultat dans un fichier texte.

config ap client-trace address add <client_MAC-address>
 
config ap client-trace filter all enable 

config ap client-trace output console-log enable 

config ap client-trace start 

term mon

Pour désactiver les débogages sur l'AP de la gamme 1800/2800/3800 une fois le processus de test et de collecte de données terminé, vous pouvez exécuter cette commande CLI sur l'AP :

config ap client-trace stop

VIII. Captures de paquets côté client

À partir du périphérique client utilisé s'il s'agit d'un ordinateur portable, d'un MacBook ou similaire, vous devez collecter la capture de paquets en mode de proximité à partir de l'interface sans fil du périphérique client utilisé pour reproduire le problème. Les utilitaires courants tels que Netmon 3.4 (Windows uniquement) ou Wireshark peuvent être facilement téléchargés et utilisés pour collecter cette capture et l'enregistrer dans un fichier *.pcap. Cela dépend du périphérique, il peut également y avoir des moyens de collecter un tcpdump ou similaire auprès du client en question, donc vous devrez peut-être consulter le fabricant du périphérique client pour obtenir de l'aide à cet égard.

Voici un exemple de configuration d'une capture Wireshark pour l'interface sans fil sur un MacBook Pro :

Comme pour toute capture de paquets, quel que soit l'utilitaire utilisé pour la collecter, veillez à enregistrer le fichier dans un format de fichier pcap (*.pcap, *.pcapng, *.pkt,...). Cela permet de s'assurer que les ingénieurs Cisco de n'importe quel service peuvent afficher facilement les fichiers de capture de paquets, mais aussi les ingénieurs d'autres fournisseurs et organisations (Intel, Apple,...). Cela permet une coopération et un processus de collaboration plus transparents, ce qui facilite encore davantage la collaboration entre Cisco et le ou les fournisseurs de périphériques clients pour mieux étudier et résoudre les éventuels problèmes d'interopérabilité.

IX. Captures de paquets OTA (Over-the-Air)

Afin de dépanner efficacement tout problème d'interopérabilité sans fil potentiel ou existant, il est essentiel de collecter une capture de paquet OTA de qualité du problème. Cela permet l'analyse détaillée de la communication sans fil 802.11 réelle entre le client sans fil et la ou les radio de point d'accès en question, en plus de donner une perspective plus approfondie du côté client et des journaux d'infrastructure sans fil, et des débogages. Il s'agit d'une étape essentielle qui doit être réalisée pour chaque test d'un problème potentiel d'interopérabilité sans fil, sans exception.

Cependant, il arrive souvent que le client final ne soit pas correctement équipé ou préparé pour collecter des captures de paquets OTA. Il s'agit d'un obstacle commun auquel les ingénieurs sans fil sont souvent confrontés et ils doivent travailler avec le client pour surmonter ce problème de différentes manières. Cet article des forums d'assistance Cisco peut servir de point de départ pour guider et éduquer le client en conséquence :

Détection/capture de paquets sans fil 802.11

Il est primordial que la ou les captures de paquets OTA soient collectées dans un format de fichier pcap (*.pcap, *.pcapng, *.pkt,..) et incluent les métadonnées 802.11 (RSSI, canal, débit,..). L'analyseur OTA doit également être maintenu à proximité du périphérique client en question à tout moment pendant les tests, afin de garantir une perspective précise du trafic envoyé et reçu vers/depuis le périphérique client testé.

Remarque : si le ou les tests en question impliquent un scénario d'itinérance de périphérique client, dans lequel plusieurs canaux 802.11 doivent être surveillés dans une capture de paquets agrégée. Il n'est pas recommandé d'utiliser AirMagnet WiFi Analyzer de Fluke Networks.

La raison en est que les captures de paquets agrégées avec l'utilisation de cet utilitaire sont actuellement enregistrées dans un format de fichier propriétaire, et non dans un format de style pcap qui peut être facilement visualisé dans Wireshark ou d'autres utilitaires similaires. Assurez-vous que votre capture de paquets OTA est dans un format de fichier non propriétaire, ce qui permet de garantir que toutes les parties et tous les fournisseurs impliqués peuvent facilement examiner tous les fichiers de capture à tout moment, et finalement aider à accélérer les efforts de résolution.

Voici quelques méthodes courantes pour collecter une capture de paquets OTA :

• AirPCAP avec Wireshark
• MacBook Pro
• OmniPeek Professional, OmniPeek Enterprise,...
• OmniPeek Remote Assistant (ORA)
• Point d'accès Cisco en mode Sniffer

Captures 802.11n

Pour les captures de paquets OTA impliquant des clients sans fil 802.11n, il y a actuellement plus de flexibilité et de facilité d'utilisation. Cela est dû à une plus grande variété d'adaptateurs WLAN USB sans fil disponibles qui peuvent être facilement utilisés avec un certain nombre d'outils, tels que OmniPeek et d'autres.

Prenez note de la comparaison entre les capacités des cartes sans fil spécifiques utilisées pour collecter une capture OTA 802.11n et celles du chipset WLAN réel utilisé par le ou les périphériques clients que vous tentez de dépanner. Par exemple, si le périphérique client rencontre un problème potentiel d'interopérabilité sans fil qui utilise un chipset 802.11n compatible 2SS. Ensuite, il est fortement recommandé de s'assurer que la carte sans fil utilisée pour collecter une capture de paquets OTA est également une carte 2SS ou supérieure, avec des spécifications 802.11n ou plus récentes.

Captures OTA 802.11ac

Pour 3 captures de flux spatial (3SS) 802.11ac, vous pouvez utiliser les fonctionnalités de détection natives d'un modèle 2014 MacBook Pro ou ultérieur avec Mac OS X 10.10.x ou ultérieur. Si vous dépannez un périphérique client 802.11ac à 2 flux spatiaux, vous pouvez également utiliser un MacBook Air pour les captures 802.11ac. Le modèle Air des MacBook utilise uniquement des chipsets WLAN 2SS au moment de la rédaction de ce document. Vous pouvez vous reporter à l'article des forums d'assistance Cisco répertoriés pour obtenir des instructions sur la façon de collecter des captures de paquets OTA avec l'utilisation de Mac OS X, par le biais d'une variété de méthodes :

Détection sans fil avec l'utilisation de Mac OS X 10.6+

Vous pouvez également utiliser un point d'accès de la gamme 2702/2802/3702/3802 ou un point d'accès similaire en mode renifleur pour collecter une capture de paquets 802.11ac appropriée avec 3SS. Vous pouvez également vous reporter à la ressource répertoriée pour obtenir la liste à jour des adaptateurs sans fil 802.11ac disponibles. Certains d'entre eux peuvent potentiellement être utilisés avec des outils courants comme OmniPeek et d'autres pour collecter une capture de paquets 802.11ac (chipsets de Ralink, Atheros,...) :

https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters

Vous pouvez également utiliser un point d'accès de la gamme 2702/2802/3702/3802 ou un point d'accès similaire en mode renifleur pour collecter une capture de paquets 802.11ac appropriée avec 3SS. Pour plus de commodité, des instructions détaillées sur la façon de configurer un point d'accès Cisco en mode renifleur et de collecter une capture de paquets OTA sont disponibles dans l'article des forums d'assistance Cisco :

Point d'accès Cisco en mode Sniffer

Pour le dépannage des scénarios d'itinérance avec un périphérique client sans fil, le défi commun consiste à collecter efficacement une capture de paquets OTA sur plusieurs canaux. Cette méthode de surveillance simultanée de plusieurs canaux 802.11 est obtenue par la collecte de la capture de paquets OTA agrégés. Pour ce faire, il est recommandé d'utiliser plusieurs adaptateurs WLAN USB compatibles 802.11ac avec un logiciel d'analyse de réseau compatible. Certains adaptateurs WLAN USB compatibles 802.11ac courants incluent l'adaptateur WiFi Savvius pour OmniPeek (802.11ac), Netgear A6210 ou similaire.

X. Résumé

Voici un bref résumé des informations qui doivent être collectées pour résoudre efficacement un problème potentiel d'interopérabilité du client sans fil avec un CUWN. Cette section est destinée à servir de section de référence rapide, si nécessaire.

I. Définition du problème

• Le problème est-il limité à un modèle spécifique de point d'accès et/ou de type radio (2,4 GHz contre 5 GHz) ?
• Le problème est-il observé uniquement sur des versions spécifiques du logiciel du contrôleur LAN sans fil (WLC) ?
• Le problème se pose-t-il uniquement avec des versions spécifiques de type(s) client(s) et/ou de logiciel (version du système d'exploitation, version du pilote WLAN, etc.) ?
• Y a-t-il d'autres périphériques sans fil qui ne rencontrent pas ce problème ? Dans l'affirmative, lesquels ?
• Le problème peut-il être reproduit lorsque le client est connecté à un SSID ouvert, une largeur de canal de 20 MHz et la norme 802.11ac désactivée ? (Le problème se produit-il uniquement en mode 11n ou 11ac ?)
• Si le problème n'est pas reproductible avec un SSID ouvert, à quelle configuration de sécurité minimale le problème est-il détecté ? (PSK ou 802.1X sur le WLAN)
• Quelles étaient les versions précédentes de la configuration et du logiciel, dont le fonctionnement a été vérifié ?

II. Configuration et journaux WLC

Collectez ceci à partir de l'interface de ligne de commande du ou des WLC en question :

• config paging disable
• show run-config

Sinon, vous pouvez également collecter uniquement ces informations si nécessaire :

• config paging disable
• show run-config no-ap
• show wlan apgroups

Sauvegarde de la configuration WLC via TFTP, FTP,...(GUI : Commands > Upload File > Configuration)

Syslogs à partir du WLC

III. Informations sur le périphérique client

• Type de client (tablette, smartphone, ordinateur portable,...)
• Marque et modèle du périphérique
• version du système d'exploitation
• Modèle de carte WLAN
• Version du pilote de carte WLAN
• Demandeur utilisé (Windows Zero Config / Auto Config, Intel PROSet,...)
• Sécurité configurée pour une utilisation par le client sans fil et le WLAN (Open, PSK, EAP-PEAP/MSCHAPv2,...)

Remarque : tous les paramètres client ont été modifiés par rapport aux paramètres par défaut fournis par le fournisseur en question. (état de veille, paramètres d'itinérance, U-APSD,...)

IV. Schéma de topologie du réseau

Ceci inclut une représentation et/ou des détails concernant les périphériques sans fil dans le réseau (imprimantes/scanners, WLC,...)

V. Créer une feuille de calcul pour enregistrer tous les problèmes du client

Exemple :

Adresse MAC :	Nom d’utilisateur	Description des symptômes signalés	Symptôme observé par l'utilisateur final	Envoyez une requête ping à la passerelle par défaut O/N	État du signal WiFi (Connecté/tentative de connexion)	Enregistrer ipconfig /all (ou équivalent)

L'objectif de cet exercice est d'aider à identifier un modèle commun et de présenter une image plus précise de la ou des questions en jeu.

VI. Commandes Show et Debug sur le WLC

Collectez ces débogages WLC via l'interface de ligne de commande :

• config sessions timeout 0
• debug client <adresse_MAC>
• debug dhcp message enable

Ajoutez les débogages supplémentaires au cas par cas :

• debug aaa detail enable - utilisez cette option en cas de problèmes d'authentification avec le serveur AAA
• debug aaa events enable - utilisez cette option en cas de problèmes d'authentification avec le serveur AAA
• debug aaa all enable - utilisez ceci pour les problèmes d'authentification ; ceci est explicite donc utilisez-le seulement quand nécessaire (pour les cas de remplacement AAA et similaires)
• debug mobility handoff - utilisation en cas de problèmes d'itinérance entre les WLC

Collectez le résultat des commandes show du WLC via l'interface de ligne de commande :

• config paging disable
• show time
• show client detail <adresse MAC du client> (notez l’état du client sur le WLC)
• Envoyez une requête ping au client depuis le WLC

Une fois le test terminé, utilisez cette commande pour arrêter tous les débogages actuels sur le WLC :

• debug disable-all

VII. Commandes Show et Debug sur l'AP

AP Cisco IOS® légers

Cette section détaille les débogages requis pour les points d'accès des gammes 1700/2700/3700 ou des modèles antérieurs.

Pour éviter un délai d'expiration de session AP au moment d'une session Telnet/SSH/console, utilisez ces commandes :

• debug capwap console cli
• config t
• line console 0 - à utiliser pour modifier les paramètres de délai d'expiration de session série
• line vty 0 4 - à utiliser pour modifier les paramètres de délai d’attente de session Telnet/SSH
• exec-timeout 0
• session-timeout 0
• terme len 0

Avant de commencer le test, collectez un échantillon de ces commandes show sur le point d'accès. Recueillez au minimum deux échantillons de ce résultat, avant et après la fin des tests avec l'utilisation de ces commandes AP show via l'interface de ligne de commande :

• terme len 0
• show clock
• show tech
• show capwap client mn
• show int do1 dfs
• show logging
• autres événements.log
• show trace dot11_rst display time format local
• show trace dot11_rst
• show trace dot11_bcn affichage heure format local
• show trace dot11_bcn

Collectez ces débogages AP via l'interface de ligne de commande :

• debug dot11 { d0 | d1 } monitor addr <adresse_MAC>
• debug dot11 { d0 | d1 } trace print clients clés de gestion rxev txev rcv xmt txfail ba
• terme mon

Une fois le test terminé, utilisez cette commande pour désactiver les débogages :

• u tous

AP-COS AP

Cette section détaille les débogages requis pour les AP de la gamme 1800/2800/3800.

Pour éviter un délai d'expiration de session AP au moment d'une session Telnet/SSH/console, utilisez ces commandes :

• exec-timeout 0

Avant de commencer le test, collectez un échantillon des commandes show sur l'AP. Recueillez au minimum deux échantillons de ce résultat, avant et après la fin des tests avec l'utilisation de ces commandes AP show via l'interface de ligne de commande :

• terme len 0
• show clock
• show tech
• show client statistics <adresse_MAC_client>
• show cont nss status
• show cont nss stats
• show log

Pour les points d'accès de la gamme 1800, collectez ces débogages AP via l'interface de ligne de commande :

• debug dot11 client level events addr <adresse_MAC_client>
• debug dot11 client level errors addr <adresse_MAC_client>
• debug dot11 client level critical addr <adresse_MAC_client>
• debug dot11 client level info addr <adresse_MAC_client>
• debug dot11 client datapath eapol addr <adresse_MAC_client>
• debug dot11 client datapath dhcp addr <adresse_MAC_client>
• debug dot11 client datapath arp addr <adresse_MAC_client>
• terme mon

Pour les points d'accès de la gamme 2800/3800, collectez ces débogages AP via l'interface de ligne de commande :

• config ap client-trace address add <adresse_MAC_client>
• config ap client-trace filter all enable
• config ap client-trace output console-log enable
• config ap client-trace start
• terme mon

Une fois le test terminé, utilisez cette commande pour désactiver les débogages :

• config ap client-trace stop

VIII. Captures côté client

Collectez une capture de paquets Netmon 3.4 (Windows XP ou 7 uniquement) ou Wireshark à partir de l'adaptateur WLAN du périphérique client.

IX. Captures OTA

Captures 802.11n

• AirPCAP avec Wireshark
• MacBook Pro
• OmniPeek Professional, Enterprise,...
• OmniPeek Remote Assistant (ORA)
• Point d'accès Cisco en mode Sniffer

Captures 802.11ac

• Pour les captures 11ac 3SS, vous pouvez utiliser un Macbook Pro 2014 ou version ultérieure exécutant 10.10.x ou version ultérieure (n'utilisez pas MacBook Air pour les captures 11ac si possible, car il s'agit actuellement d'un périphérique 2SS uniquement).
• Vous pouvez également utiliser un point d'accès Cisco 2702, 3702 ou similaire en mode renifleur.
• Pour les scénarios d'itinérance et avec l'utilisation d'un logiciel d'analyse réseau professionnel tel qu'OmniPeek de Savvius. Il est recommandé d'utiliser plusieurs adaptateurs WLAN USB compatibles 802.11ac, tels que l'adaptateur WiFi Savvius pour OmniPeek (802.11ac), Netgear A6210 ou similaire.

XI. Annexe A - Conseils et astuces supplémentaires

Fenêtres

Collecter des informations supplémentaires sur la connexion sans fil actuelle et d'autres détails connexes directement à partir d'un PC Windows. Vous pouvez utiliser ces commandes relatives à netsh wlan dans la ligne de commande Windows (CMD) :

C:\Users\engineer>netsh wlan show ?
These commands are available:
Commands in this context:
show all       - Shows complete wireless device and networks information.
show allowexplicitcreds - Shows the allow shared user credentials settings.
show autoconfig - Shows whether the auto configuration logic is enabled or
                 disabled.
show blockednetworks - Shows the blocked network display settings.
show createalluserprofile - Shows whether everyone is allowed to create all
                 user profiles.
show drivers   - Shows properties of the wireless LAN drivers on the system.
show filters   - Shows the allowed and blocked network list.
show hostednetwork - Show hosted network properties and status.
show interfaces - Shows a list of the wireless LAN interfaces on
                 the system.
show networks  - Shows a list of networks visible on the system.
show onlyUseGPProfilesforAllowedNetworks - Shows the only use GP profiles on GP
configured networks setting.
show profiles  - Shows a list of profiles configured on the system.
show settings  - Shows the global settings of wireless LAN.
show tracing   - Shows whether wireless LAN tracing is enabled or disabled.

C:\Users\engineer>netsh wlan show interfaces
There are 3 interfaces on the system:

    Name                   : Wireless Network Connection 8
    Description            : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter #5
    GUID                   : 6beec9b0-9929-4bb4-aef8-0809ce01843e
    Physical address       : c8:d7:19:34:d5:85
    State                  : disconnected

    Name                   : Wireless Network Connection 4
    Description            : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter
    GUID                   : 23aa09d4-c828-4184-965f-4e30f27ba359
    Physical address       : 48:f8:b3:b7:02:6e
    State                  : disconnected

    Name                   : Wireless Network Connection
    Description            : Intel(R) Centrino(R) Advanced-N 6200 AGN
    GUID                   : 8fa038f8-74e0-4167-98f9-de0943f0096c
    Physical address       : 58:94:6b:3e:a1:d0
    State                  : connected
    SSID                   : snowstorm
    BSSID                  : 00:3a:9a:e6:28:af
    Network type           : Infrastructure
    Radio type             : 802.11n
    Authentication         : WPA2-Enterprise
    Cipher                 : CCMP
    Connection mode        : Profile
    Channel                : 157
    Receive rate (Mbps)    : 300
    Transmit rate (Mbps)   : 300
    Signal                 : 80%
    Profile                : snowstorm

    Hosted network status  : Not started

C:\Users\engineer>netsh wlan show networks bssid | more

Interface name : Wireless Network Connection
There are 21 networks currently visible.

SSID 1 : snowstorm
    Network type            : Infrastructure
    Authentication          : WPA2-Enterprise
    Encryption              : CCMP
    BSSID 1                 : 00:3a:9a:e6:28:af
         Signal             : 99%
         Radio type         : 802.11n
         Channel            : 157
         Basic rates (Mbps) : 24 39 156
         Other rates (Mbps) : 18 19.5 36 48 54
    BSSID 2                 : 00:3a:9a:e6:28:a0
         Signal             : 91%
         Radio type         : 802.11n
         Channel            : 6
         Basic rates (Mbps) : 1 2
         Other rates (Mbps) : 5.5 6 9 11 12 18 24 36 48 54

-- More  --

macOS (anciennement OS X)

Afin de collecter la sortie équivalente comme la commande ipconfig /all sur un PC Windows, vous pouvez plutôt utiliser la commande commune Linux/Unix de ifconfig pour lister des informations détaillées pour toutes les interfaces réseau sur un MacBook Apple. Si nécessaire, vous pouvez également spécifier de recevoir la sortie pour l'interface sans fil native uniquement pour un MacBook donné (en0 ou en1, cela dépend du modèle). Comme dans cet exemple :

bash-3.2$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 14:10:9f:de:df:f3 
	inet6 fe80::1610:9fff:fede:dff3%en0 prefixlen 64 scopeid 0x4 
	inet 10.150.128.40 netmask 0xffffe000 broadcast 10.150.159.255
	nd6 options=1<PERFORMNUD>
	media: autoselect
	status: active

Afin d'obtenir des informations rapides mais détaillées en ce qui concerne la connexion sans fil actuelle sur un MacBook. Vous pouvez également sélectionner l'icône Wi-Fi dans l'angle supérieur droit du bureau tout en maintenant simultanément enfoncée la touche d'option sur votre clavier, comme illustré dans l'image.

Une autre option utile consiste à utiliser l'utilitaire de ligne de commande masqué appelé airport. Il est fortement recommandé de l'utiliser uniquement avec votre propre MacBook ou un MacBook utilisé dans un environnement de travaux pratiques. Comme certains administrateurs réseau peuvent ne pas vouloir accorder l'accès à cet utilitaire sur le MacBook d'un utilisateur final, utilisez le niveau de prudence approprié en conséquence. Pour continuer, entrez ceci dans Terminal sur le MacBook en question :

sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport 

Vous pouvez désormais utiliser l'utilitaire ILC de l'aéroport en toute simplicité. En voici un exemple :

bash-3.2$ airport -I
     agrCtlRSSI: -61
     agrExtRSSI: 0
    agrCtlNoise: -90
    agrExtNoise: 0
          state: running
        op mode: station 
     lastTxRate: 216
        maxRate: 300
lastAssocStatus: 0
    802.11 auth: open
      link auth: wpa2
          BSSID: 0:3a:9a:e6:28:af
           SSID: snowstorm
            MCS: 13
        channel: 157,1

Pour faciliter davantage le processus de collecte d'une capture de paquets OTA fiable et à canal unique 802.11 avec l'utilisation des fonctionnalités d'un MacBook Pro ou similaire. Vous pouvez soit exploiter les fonctionnalités intégrées de macOS en utilisant la méthode Wireless Diagnostics > Sniffer ou une méthode similaire, comme indiqué précédemment, mais vous pouvez également utiliser un utilitaire tiers appelé Airtool (OS X 10.8 et versions ultérieures). L'avantage est une interface simple pour collecter rapidement une capture de paquets OTA, qui est enregistrée directement sur le bureau en quelques clics à travers l'interface utilisateur de l'application directement à partir de la barre de menu supérieure sur votre écran.

 Pour plus d'informations et des liens de téléchargement pour Airtool, consultez la page suivante :

https://www.adriangranados.com/apps/airtool