Dépannage des téléphones sans fil CP-8821

Options de téléchargement

  • PDF     (110.2 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (94.6 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (82.3 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:19 juillet 2021
ID du document:217219

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction

    Ce document décrit les méthodes de haut niveau permettant de résoudre différents problèmes courants liés aux téléphones sans fil, tels que les téléphones 8821 et 8821-EX.

    Conditions préalables

    Conditions requises

    Aucune spécification déterminée n'est requise pour ce document.

    Components Used

    Les informations de ce document sont basées sur un microprogramme CP-8821 sur 11.0.5-SR1.

    Les informations de ce document ont été créées à partir de périphériques dans un environnement de travaux pratiques. All of the devices used in this document started with a cleared (default) configuration. Si vous effectuez ces tâches dans un environnement de production, assurez-vous de bien comprendre l'impact potentiel de n'importe quelle commande.

    Terminologie sans fil

    Terminologie et abréviations couramment utilisées que vous devez connaître afin de résoudre différents problèmes liés à la norme 8821 :

    • Points d'accès (AP) : les points d'accès sont les périphériques avec lesquels les clients sans fil communiquent pour recevoir la connectivité. Ils contiennent les radios qui diffusent les signaux pour les clients.
    • Wireless LAN Controller (WLC) : périphérique qui gère l'association et/ou l'authentification des clients sans fil. Toutes les configurations des points d'accès sont également effectuées ici.
    • Indicateur de puissance du signal reçu (RSSI) : il s'agit d'une mesure de la force du signal pour un SSID donné (en dBm négatif). Plus ce nombre est proche de 0, plus le signal est fort.

      Note: RSSI est mesuré en dBm de sorte que la mesure est logarithmique plutôt que linéaire. Cela signifie que -3dBm représente la moitié de la puissance du signal alors que +3dBm représente le double de la puissance du signal.

    • Itinérance : lorsqu'un périphérique se déplace d'un point d'accès à un autre, généralement en raison d'un signal fort sur le point d'accès voisin.
    • Rapport signal/bruit (SNR) : mesure de la puissance du signal sans fil par rapport au niveau de bruit de fond (en dBm positif).
    • Basic Service Set (BSS) : topologie réseau qui permet aux périphériques de communiquer via un point d'accès.
    • SSID (Service Set Identifier) : nom convivial d'un ou plusieurs BSS.
    • BSSID (Basic Service Set Identifier) : identifiant de l'adresse MAC BSS d'un point d'accès pour une radio donnée.
    • Capture en vol (OTA Capture) : puisque les captures de paquets ne peuvent pas être prises directement à partir du 8821, les captures OTA sont le seul moyen de voir les paquets transmis par le point d'accès et le téléphone.
    • Contrôle d'admission des appels (CAC) : système par lequel un administrateur peut empêcher les appels qui auraient un impact négatif sur d'autres appels sur le réseau, généralement en raison de restrictions de bande passante.
    • Étude de site : étude de l'environnement permettant de planifier et de concevoir le réseau sans fil. L'enquête aide à déterminer les emplacements optimaux pour les points d'accès afin d'atteindre la couverture souhaitée, les débits de données, la capacité d'itinérance, etc.
    • Rapports de problèmes (PRT) : ensemble de journaux pouvant être généré sur le téléphone pour résoudre les problèmes.

    Dépannage

    Guide de déploiement et configuration sans fil

    La première étape du dépannage des problèmes de connectivité 8821 consiste à s'assurer que la configuration sans fil respecte le guide de déploiement 8821. Vous pouvez utiliser ces outils pour réaliser ceci :

    Outil Analyseur de configuration sans fil

    Vous trouverez plus d'informations sur l'utilisation de l'outil Wireless Config Analyzer ici :

    https://community.cisco.com/t5/wireless-mobility-documents/how-to-use-the-wireless-lan-controller-co...

    Comprendre l'étendue du problème

    L'une des premières étapes du dépannage des problèmes sans fil consiste à obtenir une description très détaillée du problème. Il est impératif que vous compreniez le problème en détail afin de pouvoir le résoudre efficacement. Afin de limiter votre attention à la bonne zone, il est essentiel de connaître le comportement attendu du téléphone. Reportez-vous aux étapes de haut niveau qu'un téléphone passe de la mise sous tension à l'enregistrement :

    1. Le téléphone est sous tension.
    2. Le téléphone analyse les canaux WiFi pour rechercher des SSID (couche 1).
    3. Le téléphone est associé à un point d'accès (couche 1/2).
    4. Authentification du téléphone (PSK ou 802.1x/EAP) (couche 2).
    5. Le téléphone acquiert une adresse IP (par DHCP ou affectation statique) (couche 3).
    6. Le téléphone tente d'établir une connexion au serveur TFTP afin de demander des fichiers.
    7. Le téléphone tente de s'enregistrer sur le noeud CUCM principal du groupe Unified CM appliqué au pool de périphériques des téléphones.

    Vous devez isoler l'étape à laquelle l'échec se produit.

    1. L'icône WiFi est-elle affichée sur l'écran du téléphone ? Si c'est le cas, le téléphone a été correctement associé à un point d'accès. Si ce n'est pas le cas, vous devez consulter les journaux du téléphone et/ou du WLC pour déterminer pourquoi le téléphone ne peut pas se connecter au point d'accès.
    2. Le téléphone acquiert-il une adresse IP ? Si ce n'est pas le cas, passez en revue les journaux téléphoniques, la capture OTA ou la capture de paquets à partir de l'interface câblée du point d'accès pour isoler l'endroit où le processus DHCP échoue. Le téléphone envoie-t-il une DÉCOUVERTE DHCP ? Le serveur DHCP répond-il par une OFFRE DHCP ?
    3. Si l'icône WiFi est visible et que le téléphone reçoit une adresse IP, attendez-vous à ce que le téléphone tente de se connecter au serveur TFTP. La page Messages d'état peut être un endroit rapide à vérifier. Des messages tels que « Liste de confiance mise à jour » ou « SEPAAAABBBCCCC.cnf.xml.sgn(HTTP)" indiquent que le téléphone peut acquérir et valider les fichiers CTL/ITL et le fichier de configuration. Assurez-vous de télécharger un rapport de problème à partir du téléphone pour rechercher toute erreur problématique sur la page Messages d'état.  Plus de détails sur la collecte des journaux sont disponibles plus loin dans ce document.
    4. Le signal est-il plus fort (plus proche de 0) que -67 dBm ? Une puissance de signal inférieure à -67 dBm est considérée comme non fiable.

    Problèmes de connectivité

    Si vous rencontrez des interruptions d'appels ou des problèmes audio, consultez immédiatement le téléphone lorsque le problème se produit. L'icône Wi-Fi disparaît-elle ? Si c'est le cas, le téléphone se dissocie du point d'accès et la défaillance est probablement due à la perte de connectivité réseau.  Si l'icône WiFi reste, il serait plus logique de dépanner le problème du point de vue de la voix sur IP (VoIP) plutôt que de la connectivité. Un moyen simple et rapide de s'assurer que le téléphone reste associé au point d'accès et sur le réseau consiste à exécuter une requête ping continue.

    Informations sur l'itinérance téléphonique

    Lorsqu'un périphérique sans fil se déplace, il passe à un nouveau point d'accès. Il y a quelques raisons pour lesquelles cela peut se produire, mais la raison la plus courante de l'itinérance est la différence dans RSSI entre le point d'accès actuel et un point d'accès voisin.

    Outre la puissance du signal, le 8821 peut être amené à se déplacer :

    1. Nombre maximal de tentatives de transmission (TX) : le téléphone ne peut pas transmettre correctement les paquets.
    2. Traffic Specification Admission Control (TSpec) - TSpec n'a pas été accordé par l'AP. (Ce paramètre est lié à CAC et QoS).
    3. BSS Loss : le point d'accès n'envoie pas ou le téléphone n'entend pas les balises. (Redémarrage RF ou AP faible, etc.).
    4. Channel Switch (Commutateur de canal) : le téléphone reçoit une annonce de commutateur de canal (CSA).  Le point d'accès envoie des réponses de sonde de balise au téléphone pour fournir de nouvelles informations de canal.
    5. Déauthentification : le point d'accès a envoyé une déauthentification au téléphone. Il peut y avoir de nombreuses raisons à cela : consultez le journal téléphonique ou captez le code de raison.
      Les codes de raison se trouvent ici, mais sont généralement décrits dans la capture :

    Mode analyse

    Le 8821 dispose de 3 options différentes pour le mode Scan qui dictent la fréquence d'analyse du téléphone pour déterminer la puissance du signal de tous les points d'accès du voisinage. Vous pouvez le trouver sur Cisco Unified CM Administration > Device > Phone > Select the 8821.

    1. Continuous : paramètre par défaut. Le téléphone analyse toutes les 2 secondes, qu'il soit en cours d'appel ou inactif. Ce paramètre utilise l'alimentation de batterie la plus élevée étant donné que le téléphone recherche constamment les points d'accès.
    2. Auto : lorsque le téléphone est en appel, il analyse toutes les 2 secondes.  Lorsque le téléphone est inactif, il n'analyse que lorsque le RSSI sur le point d'accès actuel se dégrade au-delà d'un certain point. Ce paramètre utilise moins de batterie que Continuous et peut améliorer l'autonomie des téléphones fréquemment inactifs.
    3. Point d'accès unique : analyse uniquement lorsque le téléphone est sous tension ou si la connectivité est perdue. Lorsque la connectivité est perdue, le téléphone analyse toutes les 45 secondes jusqu'à ce qu'il retrouve la connectivité. Ce paramètre utilise le moins de batterie.

    Note: Il est très important de comprendre que l'itinérance peut se produire même si le téléphone est fixe. La plupart des environnements d'entreprise comportent de nombreuses variables qui peuvent entraîner des fluctuations du RSSI même si le téléphone est fixe. Si vous soupçonnez que votre problème est dû à l'itinérance, la définition du mode d'analyse sur Point d'accès unique peut être très utile pour le prouver. De plus, n’oubliez pas que si les fluctuations du RSSI sont la cause la plus courante, il existe d’autres causes d’itinérance.

    Le périphérique n'acquiert pas d'adresse IP

    Connaissez le FN-70357 si vous avez un 8821 qui ne peut pas acquérir une adresse IP. Ceci est généralement observé dans les scénarios où ISE est mis à niveau vers une version affectée par CSCvm03681.

    Données à collecter

    Profil de journal

    Le modèle 8821 comporte divers profils de journal importants à comprendre pour résoudre les problèmes. Celles-ci se trouvent sur la page de configuration des périphériques de CUCM :

    La téléphonie est généralement préférée à la téléphonie par défaut en raison des débogages ajoutés qu'elle fournit. En cas de doute, modifiez le profil en Telephony et d'autres débogages peuvent être activés manuellement en plus de cela si nécessaire.

    Capture de paquets sans fil (capture OTA)

    Dans les cas où vous devez dépanner la connectivité 8821, les journaux de texte seuls ne suffisent pas à isoler la cause du problème.  Considérez un scénario où le 8821 envoie un SIP REGISTER à CUCM et CUCM ne répond jamais.  Vous devez déterminer quelques éléments :

    • CUCM reçoit-il ce message ?
    • CUCM répond-il à ce message ?
    • Si CUCM répond, la réponse est-elle perdue entre CUCM et le téléphone ?

    Comme les journaux de texte ne fournissent pas une visibilité suffisante sur la cause du problème, vous devez collecter des captures de paquets à partir de quelques endroits :

    • Capture de paquets par air (pour confirmer que le téléphone envoie le paquet au point d'accès)
    • Interface filaire du point d’accès (pour confirmer que le point d’accès place ce paquet sur le câble)
    • Périphériques entre le point d'accès et CUCM (pour isoler si un périphérique spécifique abandonne le paquet)
    • CUCM (pour confirmer que CUCM reçoit le message)

    Vous devez rechercher un point dans le chemin de ce paquet où un périphérique reçoit le paquet mais ne le transmet pas au périphérique suivant.  Grâce à ces connaissances, vous pouvez identifier le problème sur un périphérique spécifique ou un ensemble de périphériques.

    Pour plus d'informations sur la collecte d'une capture OTA, consultez le site : https://documentation.meraki.com/MR./Monitoring_and_Reporting/Capturing_Wireless_Traffic_from_a_Client_Machine

    Exemple d'analyse

    Vérification du journal pour un échange DHCP réussi

    %%%%% Successful DHCP exchange
7241 ERR Oct 23 12:26:47.211445 DHCP-dhcpSendReq
...
    7246 ERR Oct 23 12:26:47.218905 DHCP-dhcpSendReq(): Sending Discover...
    ...
7312 ERR Oct 23 12:26:48.395112 DHCP-dhcpRcvPkt
...
    7322 ERR Oct 23 12:26:48.402401 DHCP-dhcpRcvPkt(): Sending Request...
...
    7327 ERR Oct 23 12:26:48.500058 DHCP-dhcpRcvPkt
...
    7330 NOT Oct 23 12:26:48.500112 DHCP-dhcpRcvPkt(): ACK received
...
    7334 NOT Oct 23 12:26:48.500176 DHCP-dhcpRcvPkt(): DHCP Succeeded
7335 NOT Oct 23 12:26:48.500188 DHCP-dhcpRcvPkt(): new assigned IP addr: 0xaa401fac, configuredipaddr: 0x0

    Examen du journal pour un échange DHCP défaillant

    %%%%% DHCP Discover
2811 ERR Oct 23 12:33:17.229603 DHCP-dhcpSendReq(): Sending Discover...
2812 ERR Oct 23 12:33:17.229643 DHCP-dhcpDiscover
2813 ERR Oct 23 12:33:17.229659 DHCP-setSelectTimeout

    %%%%% No response to DHCP Discover
3253 ERR Oct 23 12:33:21.234227 DHCP-dhcpReadThrd(): response not received, try again...
...
    3258 ERR Oct 23 12:33:21.234331 DHCP-dhcpTmrExp(): Max retries of discover

    %%%%% Phone does not acquire an IP so it cannot connect to the network
3638 ERR Oct 23 12:33:24.660465 NTP->>> Send pkt to 172.16.155.3 error: [101] Network is unreachable
    ...
    3641 ERR Oct 23 12:33:25.350497 DHCP-dhcpReadThrd(): response not received, try again...
...
    3646 ERR Oct 23 12:33:25.350606 DHCP-dhcpTmrExp(): Max retries of discover
...
3776 ERR Oct 23 12:33:29.465112 DHCP-dhcpReadThrd(): response not received, try again...
...
    3785 ERR Oct 23 12:33:29.470765 DHCP-dhcpDiscover

    Examen du journal d'un événement d'itinérance

    Pour rechercher l'itinérance dans les journaux 8821, vous devez vous assurer que le profil de journal est défini sur Téléphonie. Une fois que vous avez fait cela, vous pouvez utiliser cette chaîne regex :

    wpa_supplicant\([0-9][0-9][0-9]\)-nl80211:\ Associated\ with

    Veillez à coller exactement comme indiqué. Définissez également votre éditeur de texte pour utiliser la chaîne de recherche comme regex.

    %%%%% This phone is not roaming until the MAC Address of the AP changes on line 4121
    2848 DEB Oct 25 09:49:37.303344 wpa_supplicant(940)-nl80211: Associated with 70:10:5c:b0:2a:1c
    2897 DEB Oct 25 09:49:37.683084 wpa_supplicant(940)-nl80211: Associated with 70:10:5c:b0:2a:1c
    3018 DEB Oct 25 09:49:39.680420 wpa_supplicant(940)-nl80211: Associated with 70:10:5c:b0:2a:1c
    3600 DEB Oct 25 09:49:41.676275 wpa_supplicant(940)-nl80211: Associated with 70:10:5c:b0:2a:1c
    3928 DEB Oct 25 09:49:43.669054 wpa_supplicant(940)-nl80211: Associated with 70:10:5c:b0:2a:1c
    3983 DEB Oct 25 09:49:45.672203 wpa_supplicant(940)-nl80211: Associated with 70:10:5c:b0:2a:1c
    4037 DEB Oct 25 09:49:47.674104 wpa_supplicant(940)-nl80211: Associated with 70:10:5c:b0:2a:1c
    4085 DEB Oct 25 09:49:49.671717 wpa_supplicant(940)-nl80211: Associated with 70:10:5c:b0:2a:1c
    4121 DEB Oct 25 09:49:49.766735 wpa_supplicant(940)-nl80211: Associated with b4:e9:b0:b5:05:59

    Vérification de la puissance du signal (RSSI)

    Vous voulez vous assurer que le téléphone reste connecté à un point d'accès avec une puissance de signal de -67 dBm ou supérieure (plus proche de 0). Vous pouvez facilement analyser les journaux pour cela avec cette chaîne de recherche :

    level=-

    Exemple :

    %%%%% The signal level is printed on the right end of each line.  If you see this approach or exceed -67, then jump to that line and investigate
    %%%%% In this example, the RSSI exceeded our acceptable threshhold starting on line 4008 and only came back within acceptable limits for one scan so I would start there
    3550 DEB Oct 25 11:34:08.317669 wpa_supplicant(940)-wlan0: 0: 74:a2:e6:71:73:6c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-66
    3586 DEB Oct 25 11:34:08.681122 wpa_supplicant(940)-wlan0: 0: 74:a2:e6:71:73:6c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-66
    3692 DEB Oct 25 11:34:13.484584 wpa_supplicant(940)-wlan0: 0: 74:a2:e6:71:75:ec ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-58
    3902 DEB Oct 25 11:34:18.305574 wpa_supplicant(940)-wlan0: 0: 74:a2:e6:71:75:ec ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-57
    4008 DEB Oct 25 11:34:21.310674 wpa_supplicant(940)-wlan0: 0: 74:a2:e6:71:75:ec ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-68
    4047 DEB Oct 25 11:34:21.865534 wpa_supplicant(940)-wlan0: 0: 74:a2:e6:71:75:ec ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-68
    4144 DEB Oct 25 11:34:26.311028 wpa_supplicant(940)-wlan0: 0: e8:40:40:72:29:5c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-66
    4316 DEB Oct 25 11:34:32.063243 wpa_supplicant(940)-wlan0: 0: 74:a2:e6:71:75:ec ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-68
    4467 DEB Oct 25 11:34:39.191279 wpa_supplicant(940)-wlan0: 0: 74:a2:e6:71:75:ec ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-68
    4642 DEB Oct 25 11:34:44.210987 wpa_supplicant(940)-wlan0: 0: e8:40:40:72:29:5c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-77
    4796 DEB Oct 25 11:34:50.064503 wpa_supplicant(940)-wlan0: 0: e8:40:40:72:29:5c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-77
    4911 DEB Oct 25 11:34:57.241813 wpa_supplicant(940)-wlan0: 0: e8:40:40:72:29:5c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-77
    4927 DEB Oct 25 11:34:57.453239 wpa_supplicant(940)-wlan0: 0: e8:40:40:72:29:5c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-77
    5502 DEB Oct 25 11:35:02.336313 wpa_supplicant(940)-wlan0: 0: e8:40:40:72:29:5c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-77
    5662 DEB Oct 25 11:35:10.671841 wpa_supplicant(940)-wlan0: 0: e8:40:40:72:29:5c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-77
    5673 DEB Oct 25 11:35:10.673330 wpa_supplicant(940)-wlan0: 0: e8:40:40:72:29:5c ssid='cisco-lab-voip' wpa_ie_len=0 rsn_ie_len=24 caps=0x1111 level=-77

    %%%%% After jumping to line 4642, I scroll up to look for the previous scan
    %%%%% The scan shows that there is no other AP with a stronger signal within range.  Since -77dBm is unreliable, this needs to be addressed:
    4628 DEB Oct 25 11:34:44.206227 wpa_supplicant(940)-nl80211: Drv Event 34 (NL80211_CMD_NEW_SCAN_RESULTS) received for wlan0
    4629 DEB Oct 25 11:34:44.207867 kernel-[102016.581878] [wl_dump_bss_list]: SCAN COMPLETED: scanned AP count (1)
    4630 DEB Oct 25 11:34:44.207952 kernel-[102016.581909] [wl_dump_bss_list]: SSID: "cisco-lab-voip" BSSID: e8:40:40:72:29:5c RSSI: -77 Channel: 48

    Informations connexes

    Historique de révision

    Révision Date de publication Commentaires
    1.0
    19-Jul-2021
    Première publication
    TAC Authored

    Contribution d’experts de Cisco

    • Scott Kiewert
      Cisco TAC Engineer

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco