Kali Linux+Wireshark - activar modo wireless sniffer

Primeiro é necessário ajustar o interface de wireless para modo sniffer. Isso é conseguido através do comando airmon-ng

http://www.aircrack-ng.org/doku.php?id=airmon-ng

Usage

usage: airmon-ng <start|stop> <interface> [channel] or airmon-ng <check|check kill>

Where:

• <start|stop> indicates if you wish to start or stop the interface. (Mandatory)
• <interface> specifies the interface. (Mandatory)
• [channel] optionally set the card to a specific channel.
• <check|check kill> “check” will show any processes that might interfere with the aircrack-ng suite. It is strongly recommended that these processes be eliminated prior to using the aircrack-ng suite. “check kill” will check and kill off processes that might interfere with the aircrack-ng suite. For “check kill” see

airmon-ng check - para ver o estado

airmon-ng check kill - matar processos que tenham impacto com o airmon-ng

airmon-ng start wlan0 - inicia o modo monitor

entrar no wireshark e activar a captura através do interface wlan0mon

terminada a recolha fazer, reactivar o modo rede no interface wlan0:

airmon-ng stop wlan0mon  ou  sudo airmon-ng stop
service network-manager start

WLPC_EU 2017 - as minhas notas e opiniões

Evento fantástico! Foi ótimo rever e conversar com velhos amigos, fazer novos amigos e conhecer pessoalmente os autores de alguns dos blogs favoritos, assim como algumas pessoas que sigo no twitter.

Há um genuíno sentimento de comunidade e partilha de informação e experiências.


As sessões já estão disponíveis no youtube:
https://www.youtube.com/channel/UCIzBSS46vcqhwmBZ7ZpY-yg


Ekahau Sidekick
   - Que ferramenta fantástica! Fui um dos privilegiados que segurou um protótipo durante o primeiro evento de Ekahau Masters, em Setembro de 2017. Já nessa altura fiquei com água na boca mas agora que finalmente foi oficialmente lançada, não perdi tempo e avancei com as diligências necessárias junto ao meu atual empregador para avançarmos com a aquisição dessa ferramenta.

https://www.ekahau.com/products/sidekick/overview/

Muito resumidamente; é passar de iluminação por uma luz estroboscópica (varrimentos a casa meio segundo) para uma luz constante (1 varrimento por cada micro segundo).

 CWNE Round Table
    - Quantos mais oiço esta apresentação. Quanto mais conheço pessoas que numa altura das suas vidas decidiram seguir o caminho da especialização, mais pontos em comum descubro com o meu próprio caminho e motivações.

ODROID
    - Adorei. Assim como todos os meus colegas quando perceberam o potencial da caixinha que tinha na palma da minha mão. Ainda vou fazer um blog só para essa ferramenta.

IoT Eye opener
   - O nome faz jus à apresentação. Agora que começam a aparecer todo o tipo de equipamentos wifi, há que ter muito cuidado com o que deixamos ligado nas nossas casas.

WLA (Wireless LAN Association )
   - Inscrevi-me mal cheguei a casa

802.11 k/v/r/ai
   - muito interessante. Já tenho alguns clientes a correr k/v/r mas só os equipamentos Apple tiram partido dessas funcionalidades, mas no futuro próximo deverá ser algo que quase se ative por defeito.

Protocol Analysis
  - O Peter falou uma hora e seria capaz de falar o triplo para explicar cada detalhe e cada pacote dos exemplos que apresentou. Muito bom.

CWNE 244 - Vasco Costa

CONSEGUIIIIIII! CWNE#244
Obrigado a todos os colegas, clientes e membros da comunidade Wi-Fi que me ajudaram nesta caminhada.
Obrigado a todos os autores dos quatro soberbos manuais de cursos (CWNA, CWAP, CWDP, CWSP).
Obrigado à CWNP por todas as iniciativas e por todo o apoio.



E um muito obrigado à minha esposa, por ter ajudado em tornar este sonho em realidade.

Próximo objetivo; passar o lab do CCIE-Wireless à segunda tentativa.

Wi-Fi coverage within a train - The "fastest" survey I have ever done

First, a disclosure; unfortunantly I can't give much details about the solution. However there are some info published by diferent manufacturers on out to deploy solutions such as this:

The train had already a Wi-Fi solution for passengers but it's very outdated and unstable.

Coverage
One AP per carriage will suffice.

We can consider 2 APs if a carriage has more passengers but one must not forget the gateway capacity or it would end up deploying something like this:

Noise and Spectrum Availability
I noticed all kind of noise and interference at the 2,4Ghz spectrum, specially when passing through big cargo train terminals.

- Bluetooth
- Motion sensors
- Wi-Fi cameras
- Continuous transmitters
- MW oven used at the bar carriage
- Passengers with their own Wi-Fi equipment. Most of them broadcasting at 20Mhz but there's always one at 40Mhz...

5 Ghz vs 2,4Ghz availability (sorry for my "paint skilz"...)

Not only the air quality was terrible at the 2,4Ghz spectrum, but also most of the passengers were using G and 2,4G N equipment's.

As for 5Ghz spectrum... it was a breeze. No interference, no DFS alarms, no more than 4 equipments registered. We were a team of four engineers, each with 3 Wi-Fi equipment's. There were several times that we noticed connectivity problems in the 2,4G-only equipments while those that were connected to a 5Ghz channel were ok, even at 224 Km/h.

It's hard to have a steady hand wile traveling in a train at such speeds...

The 5Ghz equipments were perfect to detect connectivity issues with the mobile gateways. If a 5Ghz equipment failed, there was always something wrong with the 3G/4G coverage.

So, in conclusion:

- 2,4 Ghz is "abused" by everyone; Wi-Fi and non-Wi-Fi
- 5 Ghz FTW

- Don't forget the capacity of the gateways when planning the throughput of the WiFi network.
- Considerer deploying client managing smart tools.

Cisco AP - Converter Autonomous em Lightweight e Lightweight em Autonomous

Converter AP Autonomous em AP Lightweight

Informação prévia necessária:
       - credenciais de acesso ao AP (default: Cisco/Cisco)
       - IP do servidor de TFTP
       - uma imagem *rcvk9w8*.tar

Aplicar o comando
ap# archive download-sw /overwrite /reload tftp://<ip tftp>/*-rcvk9W8-*.tar
 
Ex:
archive download-sw /overwrite /reload tftp://192.168.24.1/ap3g2-rcvk9w8-tar.152-4.JB6.tar
archive download-sw /reload tftp://192.168.1.10/ap3g2-rcvk9w8-tar.153-3.JBB.tar
archive download-sw /over /reload tftp://192.168.4.111/c1240-rcvk9w8-tar.124-25e.JAN1.tar


Converter AP Lightweight em Autonomous


Processo feito através de um WLC
#############################


Aceder à linha de comandos do WLC e aplicar comando:

config ap tftp-downgrade <tftp-server-ip-address> <filename> <access-point-name>
ex:
tftp server - 192.168.24.111
imagem autonomous - c1200-k9w7-tar.122-15.JA.tar
nome do AP - AP5
config ap tftp-downgrade 192.168.24.111 c1200-k9w7-tar.122-15.JA.tar AP5

Processo sem recorrer a um WLC
#############################
Este processo é usado quando queremos converter rapidamente um AP para modo Autonomous e não há um WLC disponível.

Simplifica bastante o processo se o AP estiver alimentado com um adaptador AC em vez de estar a ser alimentado por PoE. Também ajuda haver acesso AP através da porta de consola para assim conseguirmos acompanhar todo o processo e confirmar que está a correr corretamente.

Neste exemplo estou a considerar o cenário mais simples, um laptop a ser utilizador como TFTP server e a porta de rede do AP liga diretamente à porta de rede do laptop.

1. Configurar um equipamento com o servidor de TFTP com um endereço de IP entre 10.0.0.2 e 10.0.0.3
2. Garantir que o TFTP server tem a imagem correta (por exemplo; c1200-k9w7-tar.122-15.JA.tar para a um AP 1200) e que o serviço de TFTP está ativo.
3. Convém configurar o TFTP server com um timeout de 30 segundos.
4. Renomear o ficheiro da imagem do AP para tar.default, por exemplo:
   nome da imagem: c1200-k9w7-tar.122-15.JA.tar terá de ser renomeado para c1200-k9w7-tar.default
5. Usar um cabo RJ45 para ligar o laptop ao AP.
6. Desligar a alimentação do AP (ex: desligar o cabo de alimentação).
7. Pressionar o botão MODE (geralmente está localizado junto à porta de console) enquanto se volta a ligar o cabo de alimentação no AP.
8. Continuar a pressionar o botão MODE durante cerca de 20 a 30 segundos, ou até o LED mudar para vermelho.
           se houver acesso de consola ao AP, o surgimento da mensagem "mode button pressed. waiting for release" é o melhor indicativo da altura ideal para deixar de pressionar o botão MODE
9. O processo de transferência de software inicia automaticamente.
10. Após o reboot, o AP arranca em modo autonomous e já é possível configurar por CLI.

AirTimeFairness - Client Fair Sharing (Phase 2)

A rede wifi sempre foi conhecida por ficar muito lenta quando estamos associados a um AP e alguém começa a fazer um download mais "pesado" ( > 2Gbs). Isso acontece porque o sistema DCF (Distributed Coordination Function) atribui com indiscriminada igualdade o acesso à rede wireless.

A partir da versão 8.2, é possível ativar a funcionalidade denominada ATF (AirTimeFairness). O propósito desta ferramenta é garantir equidade no fluxo de tráfego para todo os clientes associados a um determinado AP e evitar que haja açambarcamento da rede wifi por um único utilizador.

Esta ferramenta permite configurar políticas de equidade entre SSIDs

O processo é relativamente simples de configurar:

Entrar em modo configuração num WLC -> Wireless -> ATF -> Policy Configuration e definimos que tipo de política queremos implementar:

exemplo de política 2, com o nome blog20, com peso 20 e a fazer Client Fair Sharing

Depois escolhemos se queremos só monitorizar ou se queremos efetivamente forçar uma política de equidade na rede. Para forçar uma política é necessário configurar o seguinte:

Selecionar se a política deverá ser implementada num determinado AP, ou num determinado AP Group ou a um tipo de rede (11a ou 11b)

Depois escolhemos se queremos uma política optimized ou seja, "podes ir alem da tua quota desde que a remanescente esteja disponível" ou strict "cumpre a tua quota. não interessa que a remanescente esteja ás moscas"

Clicar no Enable

Para ativar a política, é necessário identificar a WLAN através do WLAN id (o SSID name é preenchido automaticamente) e identificar a política que deve ser aplicada através do Policy Id (o policy name é preenchido automaticamente)

E pronto, depois é só seguir a evolução do ATF analisando a informação no Wireless -> ATF -> ATF Statistics ou efetuando os comandos

Informação do fabricante:
https://www.cisco.com/c/en/us/td/docs/wireless/technology/mesh/8-2/b_Air_Time_Fairness_Phase1_and_Phase2_Deployment_Guide.html

CWDP - Desgin de Redes - Levantamento de requisitos

"Trabalhas com wireless?! Então que rede de wireless é que achas que devo implementar?"
Como em acontece muitas vezes quando se trata de wireless, a resposta é "bom... depende... o que é que queres ao certo?"

Imaginem o que responderiam se vos perguntassem: "Eu que é que eu preciso para ir de casa para outro sítio?"

A resposta mais generalista e segura seria "um carro de 5 lugares e com bagageira" mas ás vezes essa está longe de ser a melhor opção.


- "Eu só preciso de ir ao café da esquina, depois devo passar nos correios lá mais abaixo para deixar umas cartas e depois volto para casa." Uma bicicleta seria suficiente.
- "Eu quero chegar ao centro da cidade o mais rapidamente possível e não posso estar dependente do trânsito!" Uma mota ou, se houver orçamento, um helicóptero.
- "Eu quero levar a minha família e os meus amigos à pesca" Um barco.
- "Eu quero levar 300 pessoas para o Porto e chegar lá em menos de 1 hora" Um avião. "Isso é muito caro! E se for em menos de 4 horas?" Um comboio "Hmm, ainda está um pouco acima do nosso orçamento... E se for menos de 4 horas e só 50 pessoas?" Um autocarro.

Cada solução tem as suas vantagens e desvantagens e só identificando as necessidades é que podemos propor a solução ideal.


Levantamento de requisitos

• Tipo de serviço

      - Serviço de dados? E que tipo de dados estamos a falar? emails e net? multicast?
      - Quais os requisitos de tráfego de rede?
      - Voz?
      - Localização? Hiper-localização (ex: Cisco Hyperlocation)?

• Utilizadores

      - Quantidade de utilizadores
      - Quantos utilizadores são esperados simultaneamente
      - Qual a localização dos utilizadores? É expectável haver concentrações temporárias de utilizadores?
      - Que tipo de equipamentos vão ser utilizados? Quais os requisitos desses equipamentos?
CWNPTV - Wireless Clients - The Real Story
http://clients.mikealbano.com/
https://wikidevi.com/wiki/Main_Page

• Ambiente de rede

       - Escritório?
       - Armazém e que tipo de materiais serão armazenados?
       - Indústria? Que tipo de industria?
       - Outdoor, jardins/parques?
      

• Infraestrutura

       - Qual o estado da cablagem?
       - Há equipamento "velho" que terá de ser reciclado? O equipamento "velho" é compatível com a nova solução?
       - O equipamento de rede providencia PoE? Que tipo de PoE é necessário para o equipamento de wireless; PoE, PoE+?

• Gestão de rede

      - Como será feita a gestão da rede?
      - Qual o nível de conhecimento técnico das pessoas que vão suportar a rede?
      - É necessário implementar um sistema de alarmística?
      - Qual o tipo e nível de segurança pretendidos?

• Orçamento

      - Há limitações no orçamento?

WLPC_EU Lisbon 2017 ; SIM! SIM! SIM! SIM! SIM!

Excelente oportunidade para rever malta amiga, saber as últimas novidades, aprender métodos e trocar impressões com especialistas de renome mundial.E tudo isto a apenas 15 minutos de casa!!

No que toca ao meu desenvolvimento técnico este ano está a ser nada menos que espetacular. Senão vejamos:
    - Aproveitei o tempo de "descanso forçado" (convalescença de cirurgia a um joelho) para me agarrar aos livros e dedicar-me quase exclusivamente ás certificações da CWNP. CWNA em Janeiro, CWAP, CWDP em Abril e CWSP em Junho.Submeti a minha aplicação ao CWNE em Julho e aguardo com expectativa o resultado.
   - Cisco PVT Enterprise, em Maio, na Cisco Portugal.
   - Quando souber o resultado da aplicação do CWNE, será a altura de enfrentar de novo o laboratório de CCIE-Wireless, entretanto renovado para algo mais próximo da realidade (nada de converged controllers, mais CMX e mais Mobility Express)
   - E agora a WLPC vai decorrer em Lisboa.

é... até parece que a montanha veio a Maomé... :-D

Agenda:
https://www.wlanpros.com/conferences/wlpceulisbon2017/#pricinganchor

LOS (Line of Sight) e Zonas de Fresnel

Quando se trata de montar redes no exterior, especialmente quando se trata de usar duas wireless bridge para interligar dois pontos por wireless, é necessário ter em conta que Linha de Vista (Line of Sight ou LOS):

"Hey, se eu estou junto à antena de uma bridge e vejo a antena da outra bridge daqui, isso que dizer que as antenas estão em LOS"

Não é bem assim pois LOS também inclui a zona de Fresnel. A zona de Fresnel é uma área que identifica o caminho possível que as ondas eletromagnéticas percorrem até chegarem ao destinatário.

As fórmulas para calcularem o raio da área de Fresnel são as seguintes:

D1 - distância do transmissor
D2 - distância até ao receptor
F - frequência
D - distância entre o transmissor e o receptor.

Um exemplo prático; supondo que queremos calcular o tamanho da primeira zona Fresnel no meio de um link wireless de 2Km entre duas bridges, transmitindo a no canal 6 (2,437Ghz):

r = 17,31 * sqrt ((1000 * 1000) / (2437 * 2000)) 
r = 17,31 * sqrt (1000000 / 4874000) 

r = 17,31 * sqrt (0,2052)

r = 17,31 * 0,453
r = 7,84 metros

Por exemplo, se as antenas estiverem instaladas a uma altura de 10m, isso que dizer que no ponto intermédio das duas antenas, o limite da primeira zona de Fresnel está a 2,16m do chão..

"Então e se as antenas estiverem mais baixas? Ou se houver obstáculos no caminho?"

Não é fácil termos as condições prefeitas para garantir um link sem qualquer obstrução por isso, tentamos garantir que pelo menos 60% do raio da primeira zona de Fresnel esteja desobstruído. Recuperando o exemplo anterior:

r = 0,6 * 17,31 sqrt ((1000 * 1000) / (2437 * 2000)) 

r = 4,70 metros

Isso quer dizer que mesmo que se no meio do link houvesse um obstáculo com 5,3 metros de altura, este só iria afetar 40% da primeira zona de Fresnel, ou seja, em teoria estaríamos dentro do limite necessário para existir uma ligação entre as duas wireless bridges.

Complicado?
"Não haverá por aí uma app ou um site que façam estas contas?" Claro que sim, tentem isto:

airLink Outdoor Wireless Link Calculator , da Ubiquiti
https://airlink.ubnt.com/

É necessário saber quais os pontos exatos das duas wireless bridges, saber a altura a que as antenas estão instaladas, quais as frequências que estão a ser utilizadas e a ferramenta indica se o link cumpre ou não os requisitos de LOS.

Só tem antenas da Ubiquiti e não consideram a altimetria do terreno. É necessário ter em consideração obstáculos que não aparecem no Google Earth como árvores, edifícios ou mesmo navios se a ligação for entre as margens de um rio ou lago, ou mesmo à beira mar.

CWSP - 802.1X - componentes principais - o Supplicant, o Authenticator e o Authentication Server

Os 3 pricipais actores do protocol 802.1X são o Supplicant, o Authenticator e o Authentication Server.


Supplicant - o que quer entrar.

Authenticatior - o que deixa ou não deixa entrar.

Authentication Server - o que confirma ao authenticator que o supplicant cumpre os requisitos para entrar.


Imaginem um cenário em que o José Joaquim vai ter uma reunião com o António Antunes num edifício que tem rececionista. Chega à receção e identifica-se:

- Bom dia! Sou o José Joaquim, sou da empresa Coisas&Cenas e tenho uma reunião marcada com o António Antunes.

Neste cenário o José Joaquim é o Supplicant e o rececionista/segurança é o Authenticator.

O rececionista verifica se o José Joaquim faz parte da uma lista de pessoas autorizadas para entrar ou liga para o António Antunes:

- Bom dia sr António Antunes. Daqui fala o rececionista Pedro Pedrosa. Olhe, tenho aqui um José Joaquim, da empresa Coisas&Cenas que diz que tem uma reunião marcada consigo. Confirma?
 
Neste exemplo, o Authenticatior "Pedro Pedrosa" identificou-se ao Authentication Server "António Antunes" e de seguida pediu-lhe se autorizava o Supplicant "José Joaquim"

Das duas uma, ou o António Antunes responde:
AA- Sim senhor! Deixe-o entrar, ele que vá ter à sala de reuniões do Piso 4.
PP - Ok sr. António Antunes. Obrigado e até logo" - desliga o telefone e diz para o José Joaquim- "Pode subir ao Piso 4 e esperar na Sala de Reuniões. Aqui tem o cartão de visita, por favor coloque-o enquanto cá estiver e devolva-o quando sair"

Não só o Authentication Server autenticou o Supplicant como ainda lhe atribuiu uma VLAN (sala de reuniões do Piso 4). O Authenticator passa as credenciais de autenticação ao Supplicant e encaminha-o para uma VLAN (Sala de Reuniões do Piso 4)


Ou então o António Antunes responde:
AA- Quem?! Não faço ideia de quem seja esse José Joaquim!
PP - Ok sr. António Antunes. Obrigado e até logo" - desliga o telefone e diz - "Desculpe mas não vou poder deixa-lo entrar."

Neste exemplo, o Authentication Server não autenticou o Supplicant e consequentemente o Authenticator nega o acesso à rede.


Na grande maioria dos casos das redes wifi empresariais os Supplicants são os utilizadores dos equipamentos de de cliente (laptops, smartphones, tablets ) , os Authenticators são os Wireless LAN Controllers e os Authentication Servers são os equipamentos onde reside a base de dados de utilizadores e correspondentes credenciais como os Identity Service Engine (ISE) , ou Active Directory (AD) server ou o Lightweight Directory Access Protocol (LDAP) server.

Não só é necessário que os Supplicants estejam acreditados no Authentication Server, como também é necessário que o Authentication Server reconheça o Authenticator.

Cisco PVT Enterprise Networking 17 - Wireless Troubleshooting

Evento muito positivo! Deu para trocar umas impressões com especialistas de renome, brincar um pouco com os novos WLC 3504, e as novas versões de ferramentas de gestão (PI 3.4 e CMX 10.3).
as o ponto alto foi ouvir as palavras sábias do mestre Javier Contreras Albesa. A primeira vez que ouvi foi no CLEUR 2013 e foi mais um daqueles momentos que me apercebi o quanto ainda tinha de aprender sobre wireless e equipamentos Cisco, apesar de na altura já ter o CCNP-Wireless.

Notas tiradas da apresentação:

Garantir que as versões a correr nos equipamentos são as versões aconselhadas pelo TAC:
https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-TAC-Recommended-AireOS.html

Praticar uma gestão pro-ativa do bom estado da rede, analisando os seguintes Key Performance Indicators:
Memória - a utilização da memória incrementa regularmente?
CPU - Há alguma tarefa que dispara a utilização do CPU?
Canais de rádio - Há a tendência de alta ocupação dos canais de rádio?

Quais os recursos a analisar?:
- CPU
- Memória
- Timers
- tabelas de ARP
- Clientes
- Queues
- CAPWAP

A utilização da rede é a expectável?

Como é possível controlar o estado da rede?
O Prime Infraestruture é uma excelente ferramenta mas há certos detalhes que lhe "escapam" e por vezes é necessário uma análise mais profunda.

Por onde começar a análise do WLC?
Primeiro, seguir sempre os passos e métodos que falei num post anterior cwap-capitulo 1-processos de troubleshooting . Se o problema persistir e for necessário analisar o WLC com mais detalhe por onde começamos? Pelo Data Plane ou pelo Control Plane?

Control Plane
- Queues
- Per process CPU
- CPU per core
- DHCP stats
-Timers
- ARP switch/kernel
- Memória
- Mbufs
- número de clientes
- número de PMK

Data Plane
- State monitoring
- DP-CP Drops
- Fragmentação
- Pools de pacotes

CONTROL PLANE
Qual o estado do CPU?
(Cisco Controller) >show cpu
Verificar se não há nada de anormal nos valores de Individual CPU Load. Se houver algum valor suspeito verificar os processos.

(Cisco Controller) >show process cpu
Verificar qual o processo que está com o comportamento anormal.

Qual o estado das Queues?
(Cisco Controller) >show queue-info
Verificar se a coluna de "Breached" está toda a zero. Breached significa "quantas vezes a queue ultrapassou 95% de capacidade". Verificar a coluna "inuse" e "maxalowed"

E o que quer dizer cada queue? Qual a sua importância?

Dtlarpqueue: Data transformation layer ARP queue

SNMP-Q: SNMP requests

Debugger/logger-q: Debug and Syslog Messages

SPAM: Messages between AP and WLC

NMSP*: location

Dot1x: all authentication (PSK/dot1x)

APF*: 802.11 client state machine

BCAST*: multicast/broadcast

(Cisco Controller) >show radius queue
Verificar o estado das comunicações com o servidor de Radius

Se o Auth Alloc Err e o Acct Alloc Err for diferente de 0 então há problemas no servidor de Radius.Os valores de Auth Alloc deverão ser semelhantes aos de Auth Free , assim como os valores de Acct Alloc deverão ser semelhantes aos de Acct Free.

Qual o estado da memória?
(Cisco Controller) >show memory history
Verificar se os valores de memória disponível não decrementam constantemente. Este comando também identifica há quanto tempo é que o sistema está operacional.
Na secção do comando que analisa a "Pmalloc Pools Information" verificar se chucks-in-pool e chucks-in-use não incrementam a cada dia.

Qual o estado do AP?
(Cisco Controller) >show ap uptime
Há quanto tempo estão em cima e há quanto estão associados ao WLC.

O WLC fez algum reset? Será que guardou o coredump?
(Cisco Controller) >show coredump summary
Verificar quando é que o WLC fez um reset e que nome atribuiu ao ficheiro coredump, a "blackbox" dos WLCs.

Como estão os timers do WLC?
(Cisco Controller) >show system timers summary
Verificar quantos ainda estão livres. Se Alloc Failures for diferente de 0 é porque temos problema...

No caso de WLCs 5520/8540; como estão as fan's?
(Cisco Controller) >show imm chassis fan
Este problema acontecia nas primeiras versões do 5520 mas já há algum tempo que está resolvido. De qualquer maneira, se arrancarem o 5520 e parecer que têm um F16 no bastidor, vejam os RPM das fans

Como estão os clientes?
(Cisco Controller) >show client state summary
Verificar em que estado estão os clientes.
802.1x_req - clientes que não concluíram a negociação de 802.1x. Na grande maioria das vezes acontece por se enganarem nas passwords.
DHCP_Req - clientes que concluíram a autenticação mas não ganharam IP. Verificar o estado da rede e servidor de DHCP
Webauth_Req - clientes, geralmente guests,  que por alguma razão ainda não concluíram o processo de acesso ao webauth. Tanto pode ser um cliente que tenha colocado credenciais erradas como um utilizador que ligou o wifi mas ainda não se submeteu ao processo de autenticação do portal.

Como está o fastroaming dos clientes?
(Cisco Controller) >show pmk-cache all
Evidentemente que os WLC terão de pretencer ao mesmo Roaming Group para o fastroaming funcionar corretamente.

Como está o ARP do WLC?
(Cisco Controller) >show arp stats    show arp kernel
Verificar as entradas na tabela de ARP e o detalhe de cada entrada.

É suposto o WLC estar ligado à rede em modo LAG (Link AGgregation)?
(Cisco Controller) >show lag summary
Alteração do LAG implica um reset ao WLC

DATA PLANE

Como estão os buffers?
(Cisco Controller) >debug fastpath dump fpapool
Deverá estar na _GREENZONE.
YELLOWZONE significa que o houve uma altura que o buffer ficou muito carregado. Geralmente resultante de picos de tráfego.
ORANGEZONE significa que o buffer chegou a atingir o seu limite de processamento de comunicações.  Multicast é descartado e CAPWAP passa a ser a prioridade
_REDZONE, significa que o buffer ficou de tal modo carregado que passou só a tratar do CAPWAP
BLACKZONE.... significa... puff! fez-se o chocapic...

RED e BLACK implicam uma recuperação por crash

O Data Plane "fala" com o Control Plane?
(Cisco Controller) >debug fastpath dump dpcp-stats
Verificar a existência de DROPS

Então e se o problema não for no WLC? Como é que vejo que está tudo bem com o AP?
- CPU
- Memória
- Interfaces
- Radios
- CAPWAP

O que é que o AP está a propagar?
#show controller d0 | d1
Este comando gera um "testamento". Verificar:
- interface status
- qual o canal atribuído?
- o estado do PoE. Há alarme de LowPoE?
- QBSS load. Se tiver acima de 80% ( 0xCC) há problemas
- há txblocks?
- existem muitos resets counts?
- foi detetado algum jammer?
- há beacon stops?
- silent radio hang? quanto há clientes mas não há tráfego enviado/recebido
- PCI resets? Se há, temos problemas.

O método é o mesmo para os novos APs 1800/2800/3800/1560 que são AP-COS (linux kernel?
Mais ou menos, as estruturas são semelhantes mas alguma mudaram.

#show tech
Verificamos:
- memória
- cpu
- temperatura do equipamento e do ambiente

#show flash cores

Houve crash? Onde é que está a "blackbox" para tentarmos perceber o que se passou?

#show flash syslogs
Verificar o syslogs do AP

#show dot11 clients
Como estão os meus clientes? Em que WLAN estão ligados? Com que sinal estão a chegar ao AP?

#show client summary
Como estão os clientes associados ao AP?

#show controllers dot11radio 0|1 client <mac>
Detalhes e estatísticas de um determinado cliente

#show rrm neighbor-list
Qual o estado dos APs vizinhos?

#show history interface dot11radio all reset
Houve resets ao radio? Porquê?

#show controllers nss stats
Verificar as estatísticas do Data Plane do AP

#show interfaces dot11radio 0|1 wlan <wlan id> statistics
Estatísticas de uma WLAN num radio

Resumidamente:
- Mais vale prevenir que remediar
- Há várias maneiras de detetar o que se passa na rede antes de rebentar
- key metrics são excelentes para saber o que se passa e como se passa



Mais sobre o apresentador:
Wireless LAN Controller Config Analyzer (WLCCA)
Ferramenta obrigatória para qualquer pessoa que tenha de analisar configurações de WLCs

Apresentações no CiscoLive
BRKEWN-3011 - Advanced Troubleshooting of Wireless LANs
BRKEWN-3012 - Performance Monitoring on AireOS controllers and APs