O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve problemas de interoperabilidade quando eles surgem com a solução Cisco Unified Wireless Network (CUWN).
A Cisco recomenda que você tenha conhecimento destes tópicos:
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Observação: o público-alvo deste documento são engenheiros e administradores de rede sem fio experientes que já estão familiarizados com o uso, a configuração e a solução de problemas desses tópicos.
Pode ser comum descobrir isso, considerando os vários dispositivos clientes que existem e continuam a ser desenvolvidos. Uma variedade de problemas pode surgir com relação ao estabelecimento, manutenção ou simplesmente para obter o máximo de sua conexão com a rede sem fio e suportar a infraestrutura.
Isso pode frequentemente se resumir a um simples problema de configuração por parte do dispositivo cliente e/ou da própria infraestrutura sem fio. No entanto, em alguns casos, isso pode ser atribuído a um problema de interoperabilidade com relação a um dispositivo cliente específico e componentes que o suportam (suplicante, adaptador de WLAN, driver sem fio,...), e/ou os APs em questão. Como engenheiros sem fio, esses problemas de interoperabilidade representam uma oportunidade para identificar, solucionar problemas e resolver desafios potencialmente complexos.
Este documento descreve em detalhes quais informações precisam ser coletadas inicialmente para investigar e solucionar com eficiência esses problemas de interoperabilidade sem fio quando eles surgirem com a solução Cisco Unified Wireless Network (CUWN). A necessidade de uma abordagem tão abrangente torna-se cada vez mais importante com o crescimento constante no número e nas combinações de dispositivos de cliente sem fio e rádios de ponto de acesso (AP).Informações adicionais para o que é descrito neste artigo podem ser solicitadas e precisam ser coletadas caso a caso, dado o número ilimitado de variáveis que podem ditar tais requisitos. No entanto, as informações detalhadas aqui são uma diretriz genérica para abordar qualquer possível problema de interoperabilidade de cliente sem fio.
A primeira etapa para abordar com eficácia qualquer problema com a intenção de ser resolvido é definir com precisão o problema em questão. Para isso, certifique-se de que pelo menos uma dessas perguntas seja feita e que suas respostas sejam claramente documentadas:
Sem exceção, é absolutamente necessário coletar a configuração da WLC para uma revisão detalhada dos recursos usados pelo cliente, sua configuração específica e outros detalhes semelhantes. Para fazer isso, você deve estabelecer uma sessão Telnet/SSH para as WLCs em questão e salvar a saída desses comandos CLI em um arquivo de texto:
config paging disable show run-config
A saída completa de run-config é sempre preferida, pois inclui informações detalhadas com relação aos APs unidos e informações de RF associadas. Embora em alguns casos e situações, como quando você trabalha inicialmente com uma WLC com um grande número de APs unidos (WLC 8510 com APs 2500+). Pode ser preferível coletar inicialmente apenas a configuração da WLC sem essas informações de AP para revisão rápida, já que o show run-config completo pode levar 30 minutos ou mais para concluir o número de APs determinado. No entanto, talvez ainda seja necessário coletar a saída completa da configuração de execução mais tarde.
Para fazer isso, você pode coletar opcionalmente a saída desses comandos CLI para um arquivo de texto:
config paging disable show run-config no-ap show wlan apgroups
Além da saída de show run-config ou show run-config no-ap, também é recomendável coletar um backup completo da configuração da WLC. Isso é útil, caso a recriação de um laboratório precise ser realizada pelo escalonamento de TAC/HTTS e BU, para tentar reproduzir o problema em um ambiente de laboratório da Cisco. Um backup da WLC pode ser coletado através da GUI ou da CLI da WLC em questão, com o uso de TFTP ou FTP para salvar o arquivo de configuração no servidor TFTP/FTP externo. Este exemplo mostra o uso da GUI e da CLI para salvar um backup da WLC, com o uso do TFTP:
Commands > Upload File > Configuration > Upload conforme mostrado na imagem.
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
Neste momento, você também deseja coletar os logs atuais da WLC para revisão adicional conforme necessário. O ideal é coletar esses registros imediatamente após o teste com um cliente sem fio no qual o problema relatado é reproduzido. Se o cliente exportar os logs do WLC para um servidor syslog externo, então você deseja recuperá-los de lá. Caso contrário, você pode salvar o msglog e o traplog armazenados localmente no WLC salvando a saída desta sessão CLI em outro arquivo de texto:
config paging disable show msglog show traplog
A próxima etapa é reunir o máximo de informações e especificações com relação aos dispositivos de cliente em uso que tenham um possível problema de interoperabilidade sem fio. Essas informações devem incluir, mas não se limitam necessariamente a:
Observação: quaisquer informações ou observações adicionais com relação aos dispositivos clientes até os quais inclui capturas de tela de suas configurações relacionadas à WLAN, e assim por diante, também devem ser incluídas conforme necessário.
Para acelerar ainda mais os esforços de solução de problemas e o processo de análise da causa raiz (RCA), é sempre recomendável fornecer um diagrama detalhado e completo da topologia de rede. O diagrama da topologia da rede não deve apenas incluir detalhes sobre a rede e a infraestrutura sem fio, mas também fornecer uma visão sobre os dispositivos sem fio em questão que operam na rede ( impressoras/scanners, que VLAN(s) de cliente estão em uso,...) e suas localizações relativas entre si.
Várias ferramentas (Microsoft Visio, draw.io,...) e uma variedade de estilos podem ser usados para criar esse diagrama de rede. O aspecto importante é simplesmente garantir que as informações apropriadas sejam claramente refletidas no diagrama fornecido para análise por todas as partes envolvidas e fornecedores. Um exemplo de topologia de rede que captura informações básicas, mas úteis com relação à infraestrutura e aos dispositivos cliente, como mostrado na imagem.
Para ajudar a garantir que as informações apropriadas sejam coletadas no momento de qualquer teste com o(s) dispositivo(s) cliente(s) com o(s) qual(is) os usuários finais tenham problemas. Recomenda-se criar antecipadamente uma planilha ou similar para registrar todos os problemas do cliente e detalhes relacionados observados no momento do teste, como este exemplo:
Endereço MAC | Nome de usuário | Descrição do sintoma relatado | Hora em que o usuário final observou o sintoma | Faça ping no gateway padrão S/N | Status do sinal WiFi (Conectado/tentando se conectar) | Gravar ipconfig /all (ou equivalente) |
xxyy.aabb.0011 | test_user1 | Desconecta intermitentemente do ponto de acesso. | Conectividade de rede e associação sem fio perdidas do AP3. | N | Tentando conectar | ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 éter xx:yy:aa:bb:00:11 inet6 fe80::848:cb8f:881a:4cbf%en0 prefixlen 64 scopeid seguro 0x4 inet 192.168.10.237 máscara de rede 0xffffff00 broadcast 192.168.10.255 nd6 options=201<DESEMPENHO,DAD> mídia: seleção automática status: ativo |
O objetivo deste exercício é ajudar a documentar e determinar um padrão comum de interesse, bem como obter uma imagem precisa do(s) problema(s) em questão. Quando essa planilha estiver preparada para ser usada para coleta de dados, você estará pronto para começar os testes. Algumas considerações adicionais, embora importantes, são as seguintes:
Observação: todas as depurações e capturas de pacotes coletadas precisam ser sincronizadas com o mesmo servidor NTP para uma correlação mais fácil com os logs e devem ser feitas ao mesmo tempo para qualquer teste determinado.
Observação: forneça um timestamp preciso de quando o problema é observado e quando o problema parece se recuperar (se aplicável).
Observação: sempre colete depurações filtradas por endereço MAC do cliente no AP e na WLC.
Observação: Não execute os comandos show e debug no AP dentro da mesma sessão Telnet/SSH/console, eles são feitos separadamente em uma sessão diferente de acordo.
Observação: as depurações de AP são preferíveis em Telnet/SSH versus Console, pois o console é geralmente muito lento para ser eficaz.
Quando testes são realizados para reproduzir e solucionar possíveis problemas de interoperabilidade do cliente sem fio, é imperativo que depurações e registros adicionais sejam coletados da infraestrutura sem fio em uso. Essas duas seções podem explicar em detalhes os logs específicos e a saída de depuração inicial coletada da WLC e do(s) AP(s), respectivamente.
config sessions timeout 0
debug client <MAC_address> debug dhcp message enable
Com relação à natureza do problema em questão, você também pode adicionar essas depurações de WLC caso a caso:
Assim que o problema for reproduzido com o cliente sem fio em questão e todas as informações descritas nas seções anteriores e posteriores forem coletadas e documentadas. Para executar esses comandos CLI, você deve desabilitar as depurações no WLC.
debug disable-all
config paging disable show time show client detail <MAC_address> ping <client_IP-address> <repeat count [1-100]>
Como mencionado anteriormente, certifique-se de executar as depurações de WLC em uma sessão Telnet/SSH e coletar a saída desses comandos show em outro Telnet/SSH para a WLC. Você deve fazer o mesmo para coletar a saída dos comandos AP debug e show detalhada nesta seção.
Antes de iniciar quaisquer depurações em qualquer AP lightweight Cisco IOS® envolvido no teste, como o 2600, 2700, 3700 ou pontos de acesso Cisco modelos anteriores. Você deve primeiro executar estes comandos CLI no AP, para evitar um timeout no momento de uma sessão Telnet/SSH/console para o(s) AP(s) em questão quando seu(s) cliente(s) testar(em):
debug capwap console cli config t line vty 0 4 exec-timeout 0 session-timeout 0
Você também pode seguir estas etapas para usar a conexão do console e substituir a instrução line vty 0 4 por line console 0, a fim de desabilitar os timeouts de exec e de sessão para uma conexão serial/console adequadamente.
Antes de começar o teste, você deve primeiro coletar um exemplo desses comandos show no AP. Colete a saída desses comandos show pelo menos duas vezes para cada teste que envolva o cliente sem fio em questão, antes e depois da conclusão do teste.
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
Depois de ter coletado a saída inicial dos comandos show mencionados acima, você pode agora ativar as depurações no mesmo ponto de acesso em uma sessão Telnet/SSH separada, como mostrado. Certifique-se de salvar a saída inteira em um arquivo de texto.
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
Sinalizador | Descrição |
d0 | Rádio de 2,4 GHz (slot 0) |
d1 | Rádio de 5 GHz (slot 1) |
gerenciamento | Pacotes de gerenciamento de rastreamento |
ba | Rastrear informações ACK de bloqueio |
rcv | Rastrear pacotes recebidos |
Chaves | Chaves do conjunto de rastreamento |
rxev | Rastrear eventos recebidos |
txev | Rastrear eventos de transmissão |
txrad | Rastrear transmissão para rádio |
xmt | Rastrear pacotes de transmissão |
txfail | Rastrear falhas de transmissão |
taxas | Rastrear alterações na taxa |
Para desativar as depurações no AP uma vez que o processo de teste e coleta de dados esteja concluído, você pode executar este comando CLI no AP:
u all
Para access points com capacidade para 802.11ac wave 2 e posterior, como os access points dos modelos 1800, 2800 e 3800. Esses APs de modelos mais novos introduzem um sistema operacional completamente novo para as plataformas de access point conhecidas como AP-COS. Como tal, nem todos os comandos usados anteriormente nos pontos de acesso tradicionais leves baseados no Cisco IOS® como anteriormente detalhado ainda se aplicam. Se quando você solucionar um problema envolver um problema de interoperabilidade com vários dispositivos STA clientes e APs modelo AP-COS, essas informações deverão ser coletadas do(s) ponto(s) de acesso AP-COS envolvido(s) com o teste equivalente.
Antes de iniciar quaisquer depurações em qualquer AP modelo do AP-COS envolvido no teste. Você deve primeiro executar estes comandos CLI no AP, a fim de evitar um timeout no momento de uma sessão Telnet/SSH/console para o AP em questão quando seu cliente testar:
exec-timeout 0
Antes de começar o teste, você deve primeiro coletar um exemplo desses comandos show no AP. Colete a saída desses comandos show pelo menos duas vezes para cada teste que envolva o cliente sem fio em questão, antes e depois da conclusão do teste.
term len 0
show clock show tech
show client statistics <client_MAC-address>
show cont nss status
show cont nss stats
show log
Essas depurações são específicas para a série 18xx de pontos de acesso. Isso se deve ao fato de que os chipsets usados para a série 1800 de APs diferem dos encontrados nos access points da série 2800/3800 e, portanto, um conjunto diferente de depurações é necessário neste cenário por comparação. As depurações correspondentes para os APs da série 2800/3800 são abordadas na próxima seção.
Depois de ter coletado a saída inicial dos comandos show mencionados acima, você deve habilitar as depurações no(s) mesmo(s) access point(s) 1800 em uma sessão Telnet/SSH separada, como mostrado. Certifique-se de salvar a saída inteira em um arquivo de texto.
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>
Em alguns casos, você também pode precisar habilitar as depurações adicionais no AP 18xx para solucionar problemas adicionais de interoperabilidade do cliente. No entanto, isso deve ser feito somente se/conforme solicitado por um engenheiro do TAC da Cisco para uma solicitação/caso de serviço correspondente.
Como as depurações adicionais podem não só ser muito mais detalhadas em sua saída, mas também podem introduzir carga adicional no AP, também exige tempo adicional para a análise adequada. Quais, sob certas condições, podem potencialmente interromper o serviço, se muitos dispositivos clientes tentarem se conectar ao mesmo AP sob teste ou variáveis semelhantes.
Para desativar as depurações no ponto de acesso de variante do AP-COS - seja em um AP da série 1800 ou 2800/3800 - uma vez que o processo de teste e coleta de dados esteja concluído, você pode executar este comando CLI no AP:
config ap client-trace stop
Depois de ter coletado a saída inicial dos comandos show mencionados acima, você deve habilitar as depurações nos mesmos access points 2800/3800 em uma sessão Telnet/SSH separada, como mostrado. Certifique-se de salvar a saída inteira em um arquivo de texto.
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
Para desabilitar as depurações no AP da série 1800/2800/3800 depois que o processo de teste e coleta de dados for concluído, você pode executar este comando CLI no AP:
config ap client-trace stop
No dispositivo cliente em uso, se for um notebook, MacBook ou similar, você deve coletar a captura de pacote de modo promíscuo da interface sem fio do dispositivo cliente usado para reproduzir o problema. Utilitários comuns como Netmon 3.4 (somente Windows) ou Wireshark podem ser baixados e usados prontamente para coletar essa captura e salvá-la em um arquivo *.pcap. Depende do dispositivo, também pode haver meios para coletar um tcpdump ou similar do cliente em questão, então você pode precisar consultar o fabricante do dispositivo do cliente para obter assistência a esse respeito.
Aqui está um exemplo para configurar uma captura Wireshark para a interface sem fio em um MacBook Pro:
Assim como ocorre com qualquer captura de pacote, independentemente do utilitário usado para coletá-lo, salve o arquivo em um formato de arquivo pcap (*.pcap, *.pcapng, *.pkt,...). Isso serve para garantir que não apenas os engenheiros da Cisco em qualquer departamento possam visualizar os arquivos de captura de pacotes com facilidade, mas também os engenheiros de outros fornecedores e organizações (Intel, Apple,...). Isso permite um processo de cooperação e colaboração mais integrado, o que facilita ainda mais a Cisco e os fornecedores de dispositivos cliente para trabalharem melhor em conjunto para investigar e resolver quaisquer problemas potenciais de interoperabilidade.
Para solucionar com eficiência qualquer problema de interoperabilidade sem fio potencial ou existente, é crucial coletar uma captura de pacote OTA de qualidade do problema. Isso permite a análise detalhada da comunicação sem fio 802.11 real entre o cliente sem fio e o(s) rádio(s) do ponto de acesso em questão, além de dar mais perspectiva aos logs e depurações da infraestrutura sem fio e do lado do cliente. Essa é uma etapa crítica que deve ser realizada em cada teste de um possível problema de interoperabilidade sem fio, sem exceção.
No entanto, muitas vezes o cliente final não está equipado adequadamente ou preparado para coletar capturas de pacotes OTA. Esse é um obstáculo comum que os engenheiros sem fio normalmente enfrentam e devem trabalhar com o cliente para superá-lo de várias maneiras. Este artigo dos fóruns de suporte da Cisco pode servir como um bom ponto de partida para ajudar a orientar e educar o cliente de acordo:
farejamento sem fio 802.11 / captura de pacotes
É de suma importância que as capturas de pacotes OTA sejam coletadas em um formato de arquivo pcap (*.pcap, *.pcapng, *.pkt,..) e inclua metadados 802.11 (RSSI, canal, taxa de dados,..). O farejador OTA também deve ser mantido sempre próximo ao dispositivo cliente em questão durante o(s) teste(s), para garantir uma perspectiva precisa do tráfego enviado e recebido de/para o dispositivo cliente testado.
Observação: se o(s) teste(s) em questão envolvem um cenário de roaming de dispositivo cliente, em que mais de um canal 802.11 precisa ser monitorado em uma captura de pacote agregado. Então, não é recomendado usar atualmente o Analisador de WiFi AirMagnet da Fluke Networks.
A razão para isso é devido ao fato de que as capturas de pacotes agregados com o uso desse utilitário são salvas atualmente em um formato de arquivo proprietário, e não em um formato de estilo pcap que pode ser imediatamente visualizado no Wireshark ou outros utilitários semelhantes. Certifique-se de que sua captura de pacote OTA esteja em um formato de arquivo não proprietário, isso ajuda a garantir que todas as partes e fornecedores envolvidos possam revisar prontamente qualquer arquivo de captura em todos os momentos e, em última análise, ajudar a agilizar quaisquer esforços de resolução.
Aqui estão alguns métodos comuns para coletar uma captura de pacote OTA:
Para capturas de pacotes OTA que envolvem clientes sem fio 802.11n, há atualmente mais flexibilidade e facilidade de uso. Isso se deve a uma variedade maior de adaptadores de WLAN USB sem fio disponíveis que podem ser usados rapidamente com várias ferramentas, como OmniPeek e outras.
Anote como as capacidades do(s) adaptador(es) sem fio específico(s) usado(s) para coletar uma captura OTA 802.11n se comparam com as capacidades do chipset WLAN real usado pelo(s) dispositivo(s) cliente(s) que você tenta solucionar. Por exemplo, se o dispositivo cliente experimentar um problema potencial de interoperabilidade sem fio que use um chipset 802.11n com capacidade para 2 fluxos espaciais (2SS). Em seguida, é altamente recomendável garantir que o adaptador sem fio usado para coletar uma captura de pacote OTA seja também um adaptador 2SS ou melhor, com especificações 802.11n ou mais recentes.
Para 3 capturas de fluxo espacial (3SS) 802.11ac, você pode usar os recursos de sniffing nativos de um MacBook Pro modelo 2014 ou posterior com Mac OS X 10.10.x ou superior. Se estiver solucionando problemas de um dispositivo cliente 802.11ac de 2 fluxos espaciais, você também poderá usar um MacBook Air para capturas 802.11ac. O modelo Air do MacBooks usa apenas chipsets de WLAN 2SS no momento da elaboração deste documento. Você pode consultar o artigo dos fóruns de suporte da Cisco listado para obter instruções sobre como coletar capturas de pacotes OTA com o uso do Mac OS X, por meio de uma variedade de métodos:
Detecção sem fio com o uso do Mac OS X 10.6+
Você também pode usar um AP da série 2702/2802/3702/3802 ou similar no modo farejador para coletar uma captura de pacote 802.11ac adequada com 3SS. Consulte também o recurso listado para obter uma lista atual dos adaptadores sem fio 802.11ac disponíveis. Alguns dos quais podem ser usados com ferramentas comuns como OmniPeek e outros para coletar uma captura de pacote 802.11ac (chipsets da Ralink, Atheros,...):
https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters
Você também pode usar um AP da série 2702/2802/3702/3802 ou similar no modo farejador para coletar uma captura de pacote 802.11ac adequada com 3SS. Por conveniência, instruções passo a passo sobre como configurar um AP Cisco no modo farejador e coletar uma captura de pacote OTA podem ser encontradas no artigo dos fóruns de suporte da Cisco:
Para solucionar problemas de cenários de roaming com um dispositivo cliente sem fio, o desafio comum é coletar efetivamente uma captura de pacote OTA em vários canais. Esse método de monitorar simultaneamente vários canais 802.11 é obtido pela coleta de captura de pacotes OTA agregados. Para isso, é recomendável usar vários adaptadores WLAN USB compatíveis com 802.11ac com um software de análise de rede compatível. Alguns adaptadores de WLAN USB compatíveis com 802.11ac comuns incluem o Adaptador Savvius WiFI para OmniPeek (802.11ac), Netgear A6210 ou similar.
Aqui está uma breve recapitulação das informações que precisam ser coletadas para solucionar com eficiência um possível problema de interoperabilidade de cliente sem fio com um CUWN. Esta seção deve servir como uma seção de referência rápida, conforme necessário.
Colete isso do CLI da(s) WLC(s) em questão:
Como alternativa, você também pode coletar apenas estas saídas conforme necessário:
Backup da configuração da WLC via TFTP, FTP,... (GUI: Commands > Upload File > Configuration)
Syslogs do WLC
Observação: todos os parâmetros do cliente foram alterados em relação às configurações padrão fornecidas pelo fornecedor em questão. (estado de repouso, parâmetros de roaming, U-APSD,...)
Isso inclui uma representação e/ou detalhes com relação aos dispositivos sem fio na rede (impressoras/scanners, WLCs, etc.)
Exemplo:
Endereço MAC | Nome de usuário | Descrição do sintoma relatado | Hora em que o usuário final observou o sintoma | Faça ping no gateway padrão S/N | Status do sinal WiFi (Conectado/tentando se conectar) | Gravar ipconfig /all (ou equivalente) |
O objetivo deste exercício é ajudar a identificar um padrão comum e mostrar uma imagem mais precisa do(s) problema(s) em questão.
Colete estas depurações de WLC via CLI:
Adicione as depurações adicionais caso a caso:
Colete a saída dos comandos show da WLC através do CLI:
Quando o teste estiver concluído, use este comando para parar todas as depurações atuais no WLC:
Esta seção detalha as depurações necessárias para os access points do modelo anterior ou da série 1700/2700/3700.
Para evitar o tempo limite de uma sessão AP no momento de uma sessão Telnet/SSH/console, use estes comandos:
Antes de iniciar o teste, colete um exemplo desses comandos show no AP. No mínimo, colete duas amostras dessa saída, antes e depois da conclusão dos testes com o uso desses comandos show do AP via CLI:
Colete essas depurações de AP via CLI:
Quando o teste estiver concluído, use este comando para desativar as depurações:
Esta seção detalha as depurações necessárias para os APs da série 1800/2800/3800.
Para evitar o tempo limite de uma sessão AP no momento de uma sessão Telnet/SSH/console, use estes comandos:
Antes de iniciar o teste, colete um exemplo dos comandos show no AP. No mínimo, colete duas amostras dessa saída, antes e depois da conclusão dos testes com o uso desses comandos show do AP via CLI:
Para os pontos de acesso da série 1800, colete essas depurações de AP via CLI:
Para os access points da série 2800/3800, colete essas depurações de AP através da CLI:
Quando o teste estiver concluído, use este comando para desativar as depurações:
Colete um Netmon 3.4 promíscuo (somente Windows XP ou 7) ou uma captura de pacote Wireshark do adaptador WLAN do dispositivo cliente.
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 --
Para coletar a saída equivalente como o comando ipconfig /all em um PC Windows, você pode usar o comando Linux/Unix comum de ifconfig para listar informações detalhadas para todas as interfaces de rede em um Apple MacBook. Conforme necessário, você também pode especificar o recebimento da saída apenas para a interface sem fio nativa de um determinado MacBook (en0 ou en1, depende do modelo). Como este exemplo:
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
Para obter algumas informações rápidas mas detalhadas com relação à conexão sem fio atual em um MacBook. Você também pode selecionar o ícone WiFi no canto superior direito da área de trabalho enquanto mantém pressionado simultaneamente o botão de opção no teclado, conforme mostrado na imagem.
Outra opção útil é utilizar o utilitário de linha de comando oculto chamado airport. É altamente recomendável utilizar apenas com seu próprio MacBook ou um em uso em um ambiente de laboratório. Como alguns administradores de rede talvez não queiram conceder acesso a esse utilitário no MacBook de um usuário final, use o nível apropriado de cuidado de acordo. Para continuar, insira isso no Terminal no MacBook em questão:
sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport
Agora você pode ligar para o utilitário CLI do aeroporto com facilidade. Um exemplo disso inclui:
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
Para facilitar ainda mais o processo para coletar uma captura de pacote OTA de canal único 802.11 confiável com o uso dos recursos de um MacBook Pro ou similar. Você pode aproveitar os recursos incorporados no macOS com o uso do método Wireless Diagnostics > Sniffer ou similar, conforme discutido anteriormente, mas, opcionalmente, você também pode usar um utilitário de terceiros chamado Airtool (OS X 10.8 e posterior). O benefício é uma interface simples para coletar rapidamente uma captura de pacote OTA, que é salva diretamente na área de trabalho com apenas alguns cliques através da IU do aplicativo diretamente da barra de menu superior na sua tela.
Mais informações e links de download para o Airtool podem ser encontrados neste URL:
Revisão | Data de publicação | Comentários |
---|---|---|
2.0 |
14-Feb-2023 |
Recertificação |
1.0 |
14-May-2016 |
Versão inicial |