Solução de problemas de telefones sem fio CP-8821

Introduction

Este documento descreve métodos de alto nível para solucionar vários problemas comuns com telefones sem fio, como o 8821 e o 8821-EX.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas em um firmware CP-8821 em 11.0.5-SR1.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório. All of the devices used in this document started with a cleared (default) configuration. Se você estiver executando essas tarefas em um ambiente de produção, certifique-se de entender o impacto potencial de qualquer comando.

Terminologia sem fio

Terminologia e abreviações usadas com frequência que você precisa saber para solucionar vários problemas do 8821:

• Access Points (AP) - Os APs são os dispositivos com os quais os clientes sem fio se comunicam para receber conectividade. Eles contêm os rádios que transmitem os sinais para os clientes.
• Wireless LAN Controller (WLC) - o dispositivo que lida com a associação e/ou autenticação de clientes sem fio. Todas as configurações dos access points também são feitas aqui.
• Indicador de intensidade do sinal recebido (RSSI) - é uma medida de quão forte o sinal é para um SSID específico (em dBm negativo). Quanto mais próximo esse número estiver de 0, mais forte será o sinal.

  Note: O RSSI é medido em dBm de modo que a medição é logarítmica em vez de linear. Isso significa que -3dBm é metade da intensidade do sinal, enquanto +3dBm é o dobro da intensidade do sinal.

• Roaming - é quando um dispositivo se move de um AP para outro, normalmente devido a um sinal forte no AP vizinho.
• Signal to Noise Ratio (SNR - Signal to Noise Ratio) - é uma medida da intensidade do sinal sem fio comparada ao nível de ruído de fundo (em dBm positivo).
• Basic Service Set (BSS) - topologia de rede que permite que os dispositivos se comuniquem via um AP.
• Service Set Identifier (SSID) - nome amigável de um ou mais BSS.
• BSSID (Basic Service Set Identifier) - identificador do MAC BSS de um AP para um determinado rádio.
• Captura por excesso de ar (Captura OTA) - como as capturas de pacotes não podem ser obtidas diretamente do 8821, as capturas OTA são a única maneira de ver os pacotes transmitidos pelo AP e pelo telefone.
• Call Admission Control (CAC) - um sistema pelo qual um administrador pode impedir chamadas que afetariam negativamente outras chamadas na rede, geralmente devido a restrições de largura de banda.
• Estudo do local - Um estudo do ambiente para ajudar a planejar e projetar a rede sem fio. A pesquisa ajuda a determinar os locais ideais para os APs para alcançar a cobertura desejada, as taxas de dados, a capacidade de roaming, etc.
• Problem Reports (PRT) - um pacote de log que pode ser gerado no telefone para solucionar problemas.

Troubleshoot

Guia de implantação e configuração sem fio

A primeira etapa para solucionar problemas de conectividade do 8821 é garantir que a configuração sem fio esteja de acordo com o guia de implantação do 8821. Você pode usar essas ferramentas para ajudar a realizar isso:

Ferramenta Wireless Config Analyzer

Mais informações sobre como usar a ferramenta Wireless Config Analyzer podem ser encontradas aqui:

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

Entender o escopo do problema

Uma das primeiras etapas para solucionar problemas de conexões sem fio é obter uma descrição detalhada do problema. É imperativo que você entenda o problema em detalhes para que possa solucioná-lo com eficiência. Para reduzir seu foco para a área correta, o conhecimento do comportamento esperado do telefone é vital. Veja os passos de alto nível que um telefone executa desde o início até o registro:

1. O telefone está ligado.
2. O telefone verifica os canais WiFi para procurar SSIDs (Camada 1).
3. O telefone se associa a um AP (Camada 1/2).
4. O telefone autentica (PSK ou 802.1x/EAP) (Camada 2).
5. O telefone adquire um endereço IP (por DHCP ou atribuição estática) (Camada 3).
6. O telefone tenta estabelecer uma conexão com o servidor TFTP para solicitar arquivos.
7. O telefone tenta se registrar no nó principal do CUCM no grupo do Unified CM aplicado ao pool de dispositivos de telefones.

Você precisa isolar a etapa na qual a falha ocorre.

1. O ícone WiFi está na tela do telefone? Se sim, o telefone foi associado com êxito a um AP. Caso contrário, você deve rever os registros do telefone e/ou da WLC para determinar por que o telefone não pode se conectar ao AP.
2. O telefone adquire um IP? Caso contrário, revise os registros do telefone, a captura OTA ou a captura de pacotes da interface com fio do AP para isolar onde o processo DHCP falha. O telefone envia uma DESCOBERTA DHCP? O servidor DHCP responde com uma OFERTA DHCP?
3. Se o ícone WiFi estiver visível e o telefone receber um IP, então espere que o telefone tente se conectar ao servidor TFTP. A página Mensagens de status pode ser um local rápido para verificar isso. Mensagens como "Lista confiável atualizada" ou "SEPAAABBBCCCC.cnf.xml.sgn(HTTP)" indicam que o telefone pode adquirir e validar os arquivos CTL/ITL e o arquivo de configuração. Certifique-se de fazer o download de um relatório de problemas do telefone para investigar quaisquer erros problemáticos na página Mensagens de status.  Mais detalhes sobre a coleta de logs são apresentados mais adiante neste documento.
4. O sinal é mais forte (mais próximo de 0) que -67 dBm? Uma intensidade de sinal inferior a -67dBm é considerada não confiável.

Problemas de conectividade

Se você tiver problemas intermitentes de quedas de chamada ou de áudio, verifique imediatamente o telefone quando o problema ocorrer. O ícone WiFi desaparece? Em caso afirmativo, o telefone se desassocia do AP e a falha é provavelmente devido à perda de conectividade de rede.  Se o ícone WiFi permanecer, então faria mais sentido solucionar o problema da perspectiva de Voz sobre IP (VoIP) em vez de conectividade. Uma maneira rápida e fácil de garantir que o telefone permaneça associado ao AP e na rede é executar um ping contínuo.

Informações de roaming do telefone

Quando um dispositivo sem fio faz roaming, ele muda para um novo AP. Há algumas razões para que isso possa ocorrer, mas a razão mais comum para o roaming é a diferença no RSSI entre o AP atual e um AP vizinho.

Além da intensidade do sinal, há outros gatilhos para o 8821:

1. Máx. de tentativas de transmissão (TX) - O telefone não consegue transmitir pacotes com êxito.
2. Controle de Admissão de Especificação de Tráfego (TSpec - TSpec não foi concedida do AP. (Essa configuração está relacionada ao CAC e QoS).
3. Perda de BSS - O AP não envia ou o telefone não ouve os beacons. (Reinicialização de RF ou AP fraca, etc.).
4. Switch de canal - O telefone é enviado para o Channel Switch Announement (CSA).  O AP envia respostas de sondagem de beacon ao telefone para fornecer novas informações de canal.
5. Desautenticação - O AP enviou uma desautenticação para o telefone. Pode haver muitos motivos para isso: verifique o registro do telefone ou capture o código de razão.
   Os códigos de razão podem ser encontrados aqui, mas geralmente são descritos na captura:
   

Modo de digitalização

O 8821 tem 3 opções diferentes para o modo de digitalização que determinam a frequência com que o telefone verifica para determinar a intensidade do sinal de todos os APs nas proximidades. Isso pode ser encontrado em Cisco Unified CM Administration > Device > Phone > Select the 8821.

1. Continuous - (Contínuo) Esta é a configuração padrão. O telefone verifica a cada 2 segundos se está em uma chamada ativa ou ociosa. Essa configuração utiliza a maior quantidade de energia da bateria, pois o telefone procura APs constantemente.
2. Auto - Quando o telefone está em uma chamada, ele verifica a cada 2 segundos.  Quando o telefone está inativo, ele só verifica quando o RSSI no AP atual se degrada além de um certo ponto. Essa configuração usa menos bateria do que Continuous e pode melhorar a vida útil da bateria em telefones frequentemente inativos.
3. AP único - As verificações só ocorrem quando o telefone é ligado ou se a conectividade é perdida. Quando a conectividade é perdida, o telefone verifica a cada 45 segundos até recuperar a conectividade. Essa configuração usa a menor quantidade de bateria.

Note: É muito importante entender que o roaming pode ocorrer mesmo que o telefone esteja parado. A maioria dos ambientes empresariais tem muitas variáveis que podem fazer o RSSI flutuar mesmo se o telefone estiver parado. Se você suspeitar que seu problema é devido ao roaming, definir o modo de digitalização como AP único pode ser muito útil para provar isso. Além disso, tenha em mente que, embora a flutuação do RSSI seja a causa mais comum, há outras causas para o roaming também.

O dispositivo não adquire um IP

Esteja ciente do FN-70357 se você tem um 8821 que não pode adquirir um IP. Isso geralmente ocorre em cenários em que o ISE é atualizado para uma versão afetada pelo CSCvm03681.

Dados a serem coletados

Perfil de log

O 8821 tem vários perfis de log que são importantes para entender a solução de problemas. Eles são encontrados na página de configuração do dispositivo no CUCM:

A telefonia normalmente é preferida em relação ao padrão devido às depurações adicionadas que ela fornece. Em caso de dúvida, altere o perfil para Telefonia e depurações adicionais podem ser ativadas manualmente, além disso, se necessário.

Captura de pacote sem fio (Captura OTA)

Nos casos em que você precisa solucionar problemas de conectividade 8821, os registros de texto sozinhos não são suficientes para isolar a causa do problema.  Considere um cenário em que o 8821 envia um REGISTRO SIP para o CUCM e o CUCM nunca responde.  Você precisa determinar algumas coisas:

• O CUCM recebe esta mensagem?
• O CUCM responde a esta mensagem?
• Se o CUCM responder, a resposta é perdida entre o CUCM e o telefone?

Como os registros de texto não fornecem ampla visibilidade sobre a causa do problema, você precisa coletar capturas de pacotes de alguns lugares:

• Através da captura de pacote de ar (para confirmar que o telefone envia o pacote ao AP)
• Interface com fio do AP (para confirmar se o AP coloca esse pacote no fio)
• Dispositivos entre o AP e o CUCM (para isolar se um dispositivo específico descarta o pacote)
• CUCM (para confirmar se o CUCM recebe a mensagem)

Você deve procurar um ponto no caminho desse pacote em que um dispositivo receba o pacote, mas não o transmita para o próximo dispositivo.  Com esse conhecimento, você pode identificar o problema em um dispositivo específico ou conjunto de dispositivos.

Mais informações sobre como coletar uma captura OTA podem ser encontradas aqui: https://documentation.meraki.com/MR./Monitoring_and_Reporting/Capturing_Wireless_Traffic_from_a_Client_Machine

Exemplo de análise

Análise de log para um DHCP Exchange bem-sucedido

%%%%% 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

Análise de log para um DHCP Exchange com falha

%%%%% 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

Análise de log para um evento de roaming

Para pesquisar o roaming em registros 8821, é necessário verificar se o perfil de log está definido como Telefonia. Depois de fazer isso, você pode usar esta string regex:

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

Não se esqueça de colar isso exatamente como está sendo exibido. Além disso, defina seu editor de texto para usar a string de pesquisa como 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

Verificando a intensidade do sinal (RSSI)

Verifique se o telefone permanece conectado a um AP com uma intensidade de sinal de -67dBm ou melhor (mais próxima de 0). Você pode facilmente digitalizar os registros para isso com esta string de pesquisa:

level=-

Exemplo:

%%%%% 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

Informações Relacionadas

• Solução de problemas de telefone sem fio Cisco 8821
• Captura de tráfego sem fio de uma máquina cliente - Meraki
• Suporte Técnico e Documentação - Cisco Systems