Sie sind auf Seite 1von 3

Relatório

O ambiente:

Foram usados 3 computadores, 1 hub e 1 roteador wireless. 1 computador conectado e


compartilhando a internet. Os outros dois computadores rodando o Wireshark, sendo 1 wireless e o
outro no hub. Em outra situção, dois computadores usando wireless.

A captura de dados

Situação 1 – Hub

Com o computador que estava no hub, o wireshark esta capturando dados que eram gerados
pelo computador que estava via wireless. Consegui capturar apenas broadcast vindo do roteador
wireless, apesar de estar abrindo paginas, vídeo do Youtube e ARP (comando arp -a). O tipo de
solicitação é ARP, conforme figura 1 abaixo.

Figura 1 - Captura (Destination: Broadcast – ff:ff:ff:ff:ff:ff / Source: Type ARP)

Situação 2 – Wireless

Com os dois computadores na rede wireless, todas as requisições e respostas foram


capturadas. Realizado os mesmos testes, abertura de paginas, vídeo do Youtube e ARP. Nesta
situação em que não foi realizado no mesmo computador a captura, tive de realizar o tratamento dos
dados, clicando com o botão direito do mouse na área do Packet List e selecionando Decode AS. Na
janela que abriu, cliquei na aba Link, selecionei o filtro IP e cliquei no botão OK. Com esse
tratamento, fica mais fácil identificar origem e destino.
Das informações constam requisições de DNS, pacotes de confirmação ACK, HTTP,
pacotes perdidos, retransmissão de pacotes, pacotes de confirmação ACK duplicados. Imagem na
figura 2.
Figura 2 – DNS Query.

Experiência

já tinha trabalhado com Ethereal, versão anterior do Wireshark. Estes dados capturados
podem dizer muito sobre a rede. Neste caso em especifico, até detectei problema no link, como por
exemplo 43 pacotes de ACK duplicados (Figura 3), 7 pacotes retransmitidos (Figura 4) e 25 pacotes
TCP Previous segment lost (Figura 5). Mais tarde reiniciei o servidor e resolveu.

Figura 3 – ACK duplicados Figura 4 – Retransmissão de pacotes


Figura 5 – Seguimento Anterior Perdido

Além disso é possível acompanhar os “bastidores” da abertura da pagina, como a requisição


inicial, a solicitação de DNS, a resposta do DNS, a entrega da pagina.
A utilização dos filtros muito bom para refinar a informação e poder melhorar a análise
desses dados.

Conclusão

O analisador de protocolo é uma ferramenta muito útil para sabermos oque esta trafegando
em nossa rede. E dependendo do caso e da amostragem detectarmos e solucionarmos de maneira
mais efetiva problemas que podem estar ocorrendo.
No caso da captura pelo hub, como não estava visualizando o trafego, se fosse o caso,
poderia colocar o ip do servidor no computador que estava rodando o analisador de protocolo para
capturar as requisições e identificá-las, assim podendo resolver eficientemente qualquer outro
problema que pudesse estar ocorrendo.

Das könnte Ihnen auch gefallen