Mudanças entre as edições de "RED29004-Laboratórios"

Edição atual tal como às 11h39min de 4 de fevereiro de 2021

Esta página é dedicada a descrição de roteiros de experimentos que tem por objetivo o fortalecimento de conceitos relacionados à disciplina de Redes de Computadores I da Engenharia de Telecomunicações do IFSC.

Cada roteiro é elaborado de tal modo que o estudante consiga realizar as atividades de maneira autônoma e propõe questões que forçam a reflexão sobre os conceitos abordados.

Caso deseje realizar em casa, uma boa opção e utilizar o VirtualBox e instalar uma máquina virtual pré-configurada com todo o ferramental necessário que pode se baixada aqui, usuário: aluno, senha: aluno2020.

Página principal da disciplina

Ferramentas básicas: Ping e Traceroute

Objetivos

Familiarização com a infraestrutura dos laboratórios de redes
Conhecer aplicativos para verificar os parâmetros do TCP/IP
Diagnosticar o atraso dos pacotes
Traçar rotas em redes TCP/IP

Conceitos introdutórios para uso do laboratório

A rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1.

Figura 1 - Diagrama da rede do laboratório

Roteiro de atividades

ifconfig

O aplicativo ifconfig pode ser utilizado para visualizar a configuração ou configurar uma interface de host em redes TCP/IP. Se nenhum argumento for passado na chamada do ifconfig, o comando mostra a configuração atual de cada interface de rede.

Consultar as páginas man ifconfig do Linux para maiores detalhes sobre o funcionamento deste aplicativo, o qual permite ativar/desativar a interface, configurar o endereço IP, definir o tamanho da MTU, redefinir o endereço de hardware se a interface suporta, redefinir a interrupção utilizada pelo dispositivo, entre outros.

Analisando os dados obtidos do seguinte exemplo

ifconfig 
 enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 191.36.9.46  netmask 255.255.255.0  broadcast 191.36.9.255
        inet6 2804:1454:1004:200:a85a:5102:2b69:f30e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::fe96:6859:7e7b:5a53  prefixlen 64  scopeid 0x20<link>
        inet6 2804:1454:1004:200:77e5:2fd9:4bf6:6544  prefixlen 64  scopeid 0x0<global>
        ether f0:4d:a2:e4:1b:05  txqueuelen 1000  (Ethernet)
        RX packets 124632  bytes 136030754 (136.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 38103  bytes 7323375 (7.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 21  memory 0xf7fe0000-f8000000

 lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Loopback Local)
        RX packets 3921  bytes 385075 (385.0 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3921  bytes 385075 (385.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Conclui-se que:
1. O sistema em questão possui duas interfaces de rede: enp0s25 e lo
2. enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500: A interface está ativa (UP), está com as características BROADCAST,RUNNING,MULTICAST ativas e possui um MTU (Maximum Transmission Unit) de 1500 bytes
3. inet 191.36.9.46 netmask 255.255.255.0 broadcast 191.36.9.255: Endereço IPv4 associado a interface, sua máscara de rede e seu respectivo endereço de broadcast
4. inet6 2804:1454:1004:200:a85a:5102:2b69:f30e prefixlen 64 scopeid 0x0<global> : Endereço IPv6 associado a interface, sua máscara de redes e escopo global (roteável)
5. inet6 fe80::fe96:6859:7e7b:5a53 prefixlen 64 scopeid 0x20<link> : Endereço IPv6 associado a interface, sua máscara de redes e escopo local (não roteável)
6. inet6 2804:1454:1004:200:77e5:2fd9:4bf6:6544 prefixlen 64 scopeid 0x0<global> : Endereço IPv6 associado a interface, sua máscara de redes e escopo global (roteável)
7. ether f0:4d:a2:e4:1b:05 txqueuelen 1000 (Ethernet): Endereço Ethernet (Hardware Address). Ethernet é o padrão da camada 2, nesse caso
8. RX packets 124632 bytes 136030754 (136.0 MB): Quantidade de bytes recebidos, desde o último boot
9. RX errors 0 dropped 0 overruns 0 frame 0: Quantidade de bytes recebidos com erro, desde o último boot
10. TX packets 38103 bytes 7323375 (7.3 MB): Quantidade de bytes transmitidos, desde o último boot
11. TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0: Quantidade de bytes transmitidos com erro, desde o último boot
12. device interrupt 21 memory 0xf7fe0000-f8000000: Parâmetros do sistema operacional
13. A interface lo: Qualquer tráfego que um computador envie em uma rede loopback é endereçada ao mesmo computador. O endereço IP mais usado para tal finalidade é 127.0.0.1 no IPv4 e ::1 no IPv6. O nome de domínio padrão para tal endereço é localhost. Em sistemas Unix, a interface loopback é geralmente chamada de lo ou lo0.
Agora utilize o comando sudo ifconfig para verificar o estado de suas interfaces e responda:
1. Quantas e quais interfaces de rede sua máquina possui? Liste.
2. Qual o significado/utilidade da interface lo?
3. Quais são os endereços da camada 2 atribuído as mesmas? De onde o sistema obteve esses endereços?
4. Quais são os endereços IPv4? De onde o sistema obteve esses endereços?
5. Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo?

ping

Aplicativo ping permite a um usuário verificar se um host remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede. O ping está baseado no envio de mensagens de solicitação de eco (echo request) e de resposta de eco (echo reply). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, a ser estudado mais tarde, componente do protocolo IP.

O ping é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP.

Consultar as páginas man do ping para verificar as possibilidades de uso deste aplicativo.

Exemplo 1:

PING 200.135.37.65 (200.135.37.65) 56(84) bytes of data.
64 bytes from 200.135.37.65: icmp_seq=1 ttl=62 time=0.925 ms
64 bytes from 200.135.37.65: icmp_seq=2 ttl=62 time=0.743 ms
64 bytes from 200.135.37.65: icmp_seq=3 ttl=62 time=0.687 ms
64 bytes from 200.135.37.65: icmp_seq=4 ttl=62 time=0.689 ms

4 packets transmitted, 4 received, 0% packet loss, time 2999ms

rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms

No exemplo foram enviados quatro pacotes ICMP, cada um com um número de seqüência (icmp_seq), os quais foram recebidos com sucesso com o tempo de viagem assinalado (time).
Cada pacote tem ainda um tempo de vida (ttl – time to live), o qual é decrementado em cada roteador, sendo o pacote descartado quando chegar a zero. Isto evita pacotes perdidos na rede.
Quando o ping é interrompido (CRTL-C), uma estatística é apresentada indicando o percentual de pacotes transmitidos, recebidos e perdidos.
O tempo de viagem (rtt – round trip time) mínimo (min), médio (avg) e máximo (max) é calculado, assim como o desvio padrão (mdev)

Exercício:

Envie ping para diferentes hosts e compare os tempos de resposta:
1. No endereço local de loopback;
2. Na máquina de um colega do laboratório;
3. servidor e roteador da rede da escola;
4. servidores externos:
  1. www.ifsc.edu.br
  2. www.uol.com.br
  3. www.aaa.jp
5. Explique as diferenças entre os tempos de resposta dos ping realizados:
  1. Entre ping para diferentes destinos.
  2. Entre respostas recebidas de um mesmo destino.
6. Consulte as páginas man e teste o ping com os parâmetros abaixo e descreva suas funcionalidades:
  -c count
  -i intervalo
  -s packetsize
  -t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens). Com essa estratégia é possível mapear os roteadores no caminho entre a origem e o destino de um pacote.im como o desvio padrão (mdev)

traceroute

O traceroute é capaz de traçar uma rota aproximada entre dois hosts. Este comando usa mensagens ICMP. Para determinar o nome e o endereço dos roteadores entre a fonte e o destino, o traceroute na fonte envia uma série de datagramas IP ordinários ao destino. O primeiro datagrama tem o TTL (time to live – tempo de vida) igual a 1, o segundo 2, o terceiro 3, e assim por diante, e inicia temporizadores para cada datagrama. Quando o enésimo datagrama chega ao enésimo roteador, este verifica que o tempo de sobrevida do datagrama acaba de terminar. Pelas regras do IP, o datagrama é então descartado e uma mensagem ICMP de advertência tempo de vida excedido é enviada a fonte com o nome do roteador e seu endereço IP. Quando a resposta chega de volta a fonte, a mesma calcula o tempo de viagem em função dos temporizadores.

O traceroute envia datagramas IP encapsulados em segmentos UDP a um host destino. Todavia escolhe um número de porta destino com um valor desconhecido (maior que 30000), tornando improvável que o host destino esteja usando esta porta. Quando o datagrama chega ao destino uma mensagem ICMP porta inalcançável é gerada e enviada a origem. O programa traceroute precisa saber diferenciar as mensagens ICMP recebidas – tempo excedido e porta inalcançável – para saber quando a rota foi concluída.

Exemplo:

 sudo traceroute -I 191.36.8.3

 traceroute to 191.36.8.3 (191.36.8.3), 30 hops max, 60 byte packets
  1  _gateway (191.36.9.254)  1.444 ms  1.709 ms  2.097 ms
  2  172.18.255.251 (172.18.255.251)  0.138 ms  0.151 ms  0.152 ms
  3  191.36.8.3 (191.36.8.3)  1.544 ms  1.551 ms  1.550 ms

NOTA: O comando traceroute acima foi executado com o parâmetro -I. Esse comando força o traceroute a utilizar mensagens ICMP. Outra opção é utilizar o comando com o parâmetro -T, forçando o traceroute a utilizar o protocolo TCP para transmissão de seus pacotes. Caso nenhum dos parâmetros (-I ou -T) seja utilizado o traceroute utiliza o protocolo UDP como padrão. Visando barrar o tráfego de torrent na rede do Câmpus, o Firewall bloqueia as mensagens UDP da rede. Deste modo não é possível executar o comando traceroute na rede do Campus sem o uso dos parâmetro (-I ou -T).

O exemplo mostra a rota dos pacotes entre um computador do Lab. Redes (191.36.8.3) e o servidor www do campus (191.36.8.3). Observe que para cada roteador são realizados três amostras de tempo de ida e volta. Veja pelo mapa da rede do Campus São José que entre estes dois computadores, sistemas finais, existem dois roteadores intermediários, máquina do professor e Switch camada 3 (VLANs).

Outro exemplo:

 sudo traceroute -I www.polito.it

 traceroute to www.polito.it (130.192.181.193), 30 hops max, 60 byte packets
   1  _gateway (191.36.9.254)  1.326 ms  1.410 ms  1.620 ms
   2  172.18.255.251 (172.18.255.251)  0.172 ms  0.183 ms  0.184 ms
   3  sw5-pop-wireless-backup-radio.remep.pop-sc.rnp.br (200.237.201.153)  2.574 ms  2.885 ms  3.114 ms
   4  * * *
   5  popsc-rt21-2189.pop-sc.rnp.br (200.237.202.49)  1.743 ms  1.890 ms  1.882 ms
   6  sc-lansc-rt21.bkb.rnp.br (200.143.253.109)  0.698 ms  0.681 ms  0.680 ms
   7  200.143.255.140 (200.143.255.140)  11.554 ms  11.640 ms  11.607 ms
   8  br-rnp.redclara.net (200.0.204.213)  12.710 ms  12.509 ms  12.217 ms
   9  us-br.redclara.net (200.0.204.9)  128.588 ms  128.600 ms  128.723 ms
  10  redclara-gw.par.fr.geant.net (62.40.125.168)  224.711 ms  224.812 ms  224.744 ms
  11  ae5.mx1.gen.ch.geant.net (62.40.98.182)  232.127 ms  232.146 ms  232.059 ms
  12  ae6.mx1.mil2.it.geant.net (62.40.98.81)  238.833 ms  238.855 ms  238.820 ms
  13  garr-gw.mx1.mil2.it.geant.net (62.40.125.181)  237.648 ms  238.871 ms  238.870 ms
  14  rx1-mi2-rx1-to1.to1.garr.net (90.147.80.218)  240.543 ms  240.734 ms  240.797 ms
  15  rx1-to1-ru-polito.to1.garr.net (193.206.132.34)  242.406 ms  242.406 ms  242.771 ms

Exercício:

Traçar a rota dos pacotes entre seu computador e diferentes hosts:
1. máquina de um colega do laboratório.
2. servidor e roteador da rede da escola.
3. servidores americanos.
Explique as diferenças entre os tempos de resposta:
1. Entre traceroutes para diferentes destinos.
2. No caso do traceroute para os EUA, aponte claramente qual foi o salto onde ocorreu a travessia do oceano. Como você chegou a essa conclusão?
3. Entre as três medidas apresentadas para cada salto.
O que justifica um possível tempo de resposta menor para um salto posterior? Por exemplo: pode-se obter no salto 12 um tempo de 238.833 ms e no salto 13 um tempo de 237.648 ms.
Explique as linhas com o caracter *.

Ferramentas básicas: WireShark e tcpdump

Objetivos

Conhecer aplicativos para verificar os parâmetros do TCP/IP
Familiarização com os sniffers de rede WireShark e tcpdump.

Introdução

O entendimento de protocolos de redes pode ser bastante aprofundado através da “observação de protocolos funcionando” e “da manipulação de protocolos” - observando a sequência de mensagens trocadas entre duas entidades, entrando nos detalhes da operação do protocolo, e fazendo com que os protocolos realizem certas ações e então observando estas ações e as consequências.

A ferramenta básica para observar as mensagens trocadas entre as entidades em execução é chamada de sniffer. Como o nome sugere, um sniffer captura mensagens sendo enviadas/recebidas pelo seu computador; ele também tipicamente armazena e/ou apresenta os conteúdos dos vários campos dos protocolos nestas mensagens capturadas. Um sniffer isoladamente é um elemento passivo. Ele observa as mensagens sendo enviadas e recebidas pelas aplicações e protocolos executando no seu computador, mas jamais envia pacotes. Similarmente, os pacotes recebidos nunca são explicitamente endereçados ao sniffer. Ao invés disso, um sniffer recebe uma cópia de pacotes que são enviados/recebidos para/de aplicações e protocolos executando no seu computador.

A Figura 1 mostra a estrutura de um sniffer. À direita da Figura 1 estão os protocolos (neste caso, protocolos da Internet) e aplicações (tais como navegador web ou cliente FTP) que normalmente executam no seu computador. O sniffer, exibido dentro do retângulo tracejado na Figura 1 é uma adição aos softwares usuais no seu computador, e consiste de duas partes: a biblioteca de captura de pacotes e o analisador de pacotes. A biblioteca de captura de pacotes recebe uma cópia de cada quadro da camada de enlace que é enviado do ou recebido pelo seu computador. Lembre que mensagens trocadas por protocolos das camadas mais altas tais como HTTP, FTP, TCP, UDP, DNS ou IP, são todos eventualmente encapsulados em quadros que são transmitidos para o meio físico como um cabo Ethernet. Na Figura 1, assume-se que o meio físico é uma Ethernet, e desta forma, os protocolos das camadas superiores são eventualmente encapsulados em um quadro Ethernet. Capturar todos os quadros fornece todas as mensagens enviadas/recebidas de/por todos os protocolos e aplicações executando em seu computador.

Figura 1 - Estrutura de um sniffer

O analisador de pacotes exibe os conteúdos de todos os campos dentro de uma mensagem de protocolo. Para que isso seja feito, o analisador de pacotes deve “entender” a estrutura de todas as mensagens trocadas pelos protocolos. Por exemplo, suponha que estamos interessados em mostrar os vários campos nas mensagens trocadas pelo protocolo HTTP na Figura 5. O analisador de pacotes entende o formato dos quadros Ethernet, e desta forma pode identificar o datagrama IP dentro de um quadro. Ele também entende o formato do datagrama IP, para que ele possa extrair o segmento TCP dentro do datagrama IP. Ele entende a estrutura do segmento TCP, para que possa extrair a mensagem HTTP contida no segmento. Finalmente, ele entende o protocolo HTTP e então, por exemplo, sabe que os primeiros bytes de uma mensagem HTTP contém a cadeia “GET”, “POST” ou “HEAD”. Nós utilizaremos o sniffer Wireshark (http://www.wireshark.org) para estes laboratórios, o que nos permite exibir os conteúdos das mensagens sendo enviadas/recebidas de/por protocolos em diferentes camadas da pilha de protocolos. Tecnicamente falando, Wireshark é um analisador de pacotes que pode ser executado em computadores com Windows, Linux/UNIX e MAC.

É um analisador de pacotes ideal para nossos laboratórios, pois é estável, tem uma grande base de usuários e é bem documentado incluindo um guia de usuário (http://www.wireshark.org/docs/wsug_html/), páginas de manual (http://www.wireshark.org/docs/man-pages/), e uma seção de FAQ detalhada (http://www.wireshark.org/faq.html), funcionalidade rica que inclui a capacidade de analisar mais que 500 protocolos, e uma interface com o usuário bem projetada. Ele funciona em computadores ligados a uma Ethernet para conectar-se à Internet, bem como protocolos ponto a ponto, tal como PPP.

Analisando os campos da interface do Wireshark

Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura 3 aparecerá. Inicialmente, nenhum dado será apresentado nas janelas. A interface do Wireshark tem seis componentes principais:

Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus File e Capture. O menu File permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu Capture permite iniciar uma captura de pacotes;
A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes;
Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos;
A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote;
A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados;
A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal.

Figura 3 - Interface com o usuário do Wireshark

Roteiro de atividades

Inicie o navegador web;
Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso;
Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces.
Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4);

Figura 4 - Interfaces de rede no Wireshark
Basta clicar no botão Start da interface desejada para iniciar a captura de pacotes. Na Figura 4, como o Wireshark está sendo executado no Linux, o botão Start da interface eth0 deve ser selecionado;
Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio;
No navegador, acesse o site http://www.ifsc.edu.br;
Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos na conexão;
Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em Capture e depois em Stop;
Para testar as capacidades de filtragem, vamos inserir a cadeia “http” (sem as aspas e em minúsculo) na especificação do filtro de exibição e depois selecionar Apply (ou Aplicar). Um resultado similar é exibido na figura 5;

Figura 5 - Janela após a aplicação do filtro http
Selecione a primeira mensagem HTTP exibida na janela de listagem de pacotes. Ela deve ser a mensagem HTTP GET que foi enviada do seu computador ao servidor HTTP em www.ifsc.edu.br. Quando você seleciona a mensagem HTTP GET, as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do segmento TCP e da mensagem HTTP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles.
Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre;
Com Wireshark ativo (Abra-o novamente se necessário) acesse um sítio de sua preferência e responda às seguintes questões:
1. Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado host (ip.addr == 191....). Anote o filtro utilizado e salve a janela do mesmo. Exemplo de filtros.
2. Elimine o filtro e anote os diferentes protocolos que aparecem na coluna Protocol na janela de listagem de pacotes;
3. Quanto tempo passa entre o envio de uma mensagem HTTP GET até o recebimento de uma resposta OK? (por padrão, o valor da coluna Time na janela de listagem de pacotes é a quantidade de tempo, em segundos, desde que a captura iniciou). Para exibir o campo Time no formato hora do dia, selecione o menu View, depois Time Display Format, então selecione Time of day.
4. Qual é o endereço IP do sítio navegado? Qual é o endereço IP da interface de rede do seu computador? Qual o endereço MAC de sua máquina?

Tcpdump

Leia atentamente o manual do tcpdump , principalmente os exemplos:
```
 man tcpdump
```
Faça um ping e navegue para algum site de sua preferência e, com o uso de parâmetros apropriados, faça com que o tcpdump armazene os em um arquivo denominado “pacotes_capturadosX.pcap“ (um arquivo para cada item X):
1. Capture todos os pacotes oriundos e destinados à sua máquina.
2. Idem anterior com a flag -vvv ativa e, em seguida, a flag -n.
  - Qual é a função dessas flags?
3. Capture somente os pacotes oriundos de sua máquina.
  - Anote o comando utilizado.
4. Capture somente pacotes destinados à sua máquina.
  - Anote o comando utilizado.
5. Capture pacotes HTTP e DNS (lembre-se da porta de cada serviço).
  - Anote o comando utilizado.
Procure um dos arquivos salvos, com o navegador de arquivos de sua máquina, dê um duplo clique sobre o mesmo.
1. Com qual programa foi aberto o arquivo?
2. Exemplifique um possível uso dessa compatibilidade de arquivos?

Conceituando protocolos

Objetivos

Desenvolver o conceito de protocolo.
Entender o conceito de clientes e servidores de serviço.
Conceber um protocolo/serviço de calculadora pela rede.

Requisitos de um protocolo de camada de aplicação

Os tipos de mensagens trocadas.
A sintaxe dos vários tipos de mensagens, tais como os campos da mensagem e como os campos são delineados.
A semântica dos campos, isto é, o significado da informação nos campos.
Regras para determinar quando e como um processo envia mensagens e responde a mensagens.

Definição do protocolo a ser criado

Vamos criar uma calculadora em rede através de um protocolo bem simples, utilizando como ferramenta de comunicação o ping e o Wireshark.

1. O protocolo tem por objetivo dar suporte a uma calculadora em rede.
2. Um aluno cria uma mensagem e envia, sem aviso prévio, a um colega. Este será o cliente da arquitetura cliente-servidor.
3. O colega, ao receber a mensagem, deverá interpretá-la, elaborar uma resposta à pergunta e retorná-la ao colega. Este será o servidor da arquitetura cliente-servidor.
4. A estrutura básica de um pacote que flui do cliente para o servidor e vice-versa é apresentada na figura abaixo. Essa estrutura deverá ser absolutamente respeitada, caso contrário, o servidor poderá não conseguir interpretá-la e descartará a mensagem.

Onde Dst e Src são utilizados para identificar o nome do emissor e destinatário: as iniciais dos nomes.
O campo dados conterá a pergunta ou a reposta.

Roteiro

Desative todas as atividades de rede de seu computador.
Abra o wireshark e deixe capturando mensagens com o filtro icmp ativo.
Cada estudante vai construir uma mensagem, respeitando o formato estabelecido, de solicitação (lado cliente). Essa mensagem deverá conter uma questão matemática, por exemplo: 2+2.
1. Para construir a mensagem utilize o código ASCII: Tabela ASCII ou Tabela ASCII
Envie essa mensagem a um ou vários colegas, sem aviso prévio, através do comando ping com a flag pattern. Ex:
```
 ping -p FF0200416C6C4F6469362D3103FF 192.168.1.1
```
- No relatório deverá estar contido a mensagem (Hexa) e sua interpretação.
Ao receber uma mensagem no wireshark, interprete-a, (Ferramenta para conversão ASCII ==> Hexadecimal) verificando quem é o emitente e realizando a operação aritmética solicitada.
- No relatório deverá estar contido a mensagem (Hexa) e sua interpretação.
Monte uma resposta e utilize o comando ping para responder ao emitente.
- No relatório deverá estar contido a mensagem (Hexa) e sua interpretação.

Desvendando o HTTP com Wireshark

Fonte base: Wireshark - HTTP

Objetivos

Baseado na pequena introdução ao Wireshark estamos prontos para utilizar o mesmo para investigar protocolos em operação.
Explorar vários aspectos do protocolo HTTP:
1. A interação básica GET/resposta do HTTP.
2. A interação manual GET/resposta do HTTP utilizando o telnet.
3. Diferenciação do comportamento das versões 1.0 e 1.1 do protocolo HTTP.

A Interação Básica GET/Resposta do HTTP

Vamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Faça o seguinte:
1. inicie o navegador;
2. limpe o cache do mesmo (teclas de atalho para o Firefox: Ctrl + Shift + Del);
3. inicie o Wireshark, como descrito no Ferramentas básicas;
4. inicie a captura de pacotes;
5. digite o seguinte URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html;
6. pare a captura de pacotes;
7. digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados).
  
  Fig.1 Requisição e Resposta HTTP
O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas:
1. A mensagem GET (do seu navegador para o servidor web www.sj.ifsc.edu.br) e a mensagem de resposta do servidor para o seu navegador.
2. A janela de conteúdos de pacotes mostra detalhes da mensagem selecionada (neste caso a mensagem HTTP GET /~odilson/RED29004//RED29004.html, que está em destaque na janela de listagem de pacotes).
3. A mensagem HTTP transportada em um segmento TCP, que é carregado em um datagrama IP, que é levado em um quadro Ethernet com 5728 bits no fio. Isso é observado de baixo para cima na janela de detalhes do cabeçalho do pacote selecionado. O Wireshark exibe informações sobre o quadro, IP, TCP e HTTP. Você deve expandir as informações, por exemplo, do HTTP clicando na seta ao lado esquerdo de “Hypertext Transfer Protocol”. Observando as informações das mensagens HTTP GET e de resposta. Você consegue inclusive enxergar a mensagem mostrada no navegador: RED29004! Página de teste.
Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões.
1. O seu navegador executa HTTP 1.0 ou 1.1?
2. Qual a versão de HTTP do servidor?
3. Quais idiomas (se algum) o seu navegador indica ao servidor que pode aceitar?
4. Qual o endereço IP do seu computador?
5. E do servidor tele.sj.ifsc.edu.br?
6. Qual o número da porta utilizada no seu computador?
7. E do servidor tele.sj.ifsc.edu.br?
8. Qual o código de status retornado do servidor para o seu navegador?
9. Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez?
10. Quantos bytes de conteúdo são baixados pelo seu navegador?
11. Encontre a mensagem RED29004! Página de teste. Onde (em qual campo) encontra-se?
12. Qual a diferença entre os endereços IP e porta de origem e destino entre a mensagem GET e a de resposta do HTTP?

Interação Básica GET/Resposta do HTTP usando TELNET e REQUISIÇÃO MANUAL

Vamos repetir o acesso aos links acima, porém sem usar o navegador. A ideia é que nós façamos o papel de navegador. Isso deve ser feito com os seguintes passos:
1. Coloque o Wireshark para capturar pacotes
2. Abra um terminal de texto no Linux (menu Aplicativos->Acessórios->Terminal).
3. Execute este comando:
```
telnet tele.sj.ifsc.edu.br 80
```
4. Após aparecer esta linha:
```
Trying 200.135.37.75...
Connected to integrado.sj.ifsc.edu.br.
Escape character is '^]'.
```
  digite o seguinte:
```
GET /~odilson/RED29004//RED29004.html HTTP/1.0
```
  e em seguida tecle ENTER duas vezes.
5. Identifique a página html que foi enviada como resposta. Respeita o protocolo HTTP?
6. No Wireshark compare o resultado das execuções desses comandos com o que se viu nas capturas Wireshark com acesso pelo navegador. Qual a diferença em cada caso?
7. Quanto tempo levou para fechar a conexão?
8. Refaça um pedido em que o recurso é inexistente no servidor (ex: página html com nome/URL inexistente). Observe a resposta. Qual é o código da mensagem recebida?
Refaça a conexão com o servidor:
```
telnet tele.sj.ifsc.edu.br 80
```
1. Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:
```
GET /~odilson/RED29004//RED29004.html HTTP/1.1
Host: tele.sj.ifsc.edu.br
```
  <Enter>/<Enter>
2. Quanto tempo levou para fechar a conexão?
Refaça a conexão com o servidor:
```
telnet tele.sj.ifsc.edu.br 80
```
1. Refaça o pedido, mas agora utilizando o HTTP/1.1:
```
GET /~odilson/RED29004//RED29004.html HTTP/1.1
Host: tele.sj.ifsc.edu.br
```
  <Enter>/<Enter>
2. Antes do fechamento da conexão, faça um novo pedido na conexão já aberta:
```
GET /~odilson/RED29004//RED29004_arq3.html HTTP/1.1
Host: tele.sj.ifsc.edu.br
```
  <Enter>/<Enter>
O que explica a diferença de tempo para fechamento de conexão entre as versões HTTP 1.0 e 1.1?
Descreva qual seria o procedimento para o download de dois objetos, via telnet, nos protocolos HTTP 1.0 e 1.1?

Desvendando o HTTP com Wireshark, parte 2

Objetivos

Explorar vários aspectos do protocolo HTTP:
1. A requisição condicional.
2. Formatos de mensagens HTTP.
3. Cookies.
4. Os processos e protocolos envolvidos ao baixar arquivos grandes em HTML.
5. Os processos envolvidos ao baixar arquivos em HTML com objetos incluídos.

A Interação HTTP GET Condicional/Resposta

A maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
1. Inicie o navegador web;
2. Limpe o cache do seu navegador (Ctrl + Shift + Del);
3. Inicie o Wireshark;
4. Digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html. Seu navegador deve exibir um arquivo em HTML muito simples com duas linhas;
5. Pressione o botão “refresh” no navegador (ou digite o URL novamente);
6. No Wireshark pare a captura de pacotes e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes.
Responda às seguintes questões:
1. Inspecione o conteúdo da primeira mensagem - HTTP GET - do seu navegador para o servidor tele.sj.ifsc.edu.br. Você vê uma linha “If-Modified-Since”?
2. Inspecione o conteúdo da resposta do servidor, segunda mensagem. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso?
3. Agora inspecione o conteúdo da terceira mensagem - HTTP GET - do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”?
4. Qual é o código de status e a frase retornada do servidor na resposta à segunda mensagem HTTP GET? É diferente do código de retorno da primeira mensagem?
5. Na segudna resposta, o servidor retornou explicitamente o conteúdo do arquivo? Explique.
6. Qual o tamanho da primeira e segunda mensagem de retorno (respostas) do servidor?

Cookies

Inicie o navegador web;
Limpe o cache do seu navegador;
Inicie a captura no Wireshark;
Digite o URL no navegador http://www.dvwa.co.uk/;
Pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
Utilize o recurso de procura do Wireshark, exemplo na figura ao lado, e busque em Packet details pelas strings cookie e set-cookie

Figura 1 - Filtro string cookie
Você deve ter encontrado 1 ocorrência de set-cookie e várias de cookie, sempre com o mesmo número associado, explique o motivo explicando o comportamento do protocolo?
Inicie novamente a captura no Wireshark;
Digite novamente a URL no navegador http://www.dvwa.co.uk/ (NÃO limpe o cache);
Pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro.
Busque novamente as strings cookie e set-cookie. Analise.
Os números são os mesmos do caso anterior? Explique o funcionamento de Cookies através desse experimento.

Baixando Documentos Longos

Antes de qualquer experimento deve-se desabilitar algumas funcionalidades do kernel do LINUX, para que os experimentos reflitam a teoria. Caso sua interface de rede não seja a eth0 adapte o comando substituindo eth0 pelo nome da sua interface de rede. Se, por qualquer motivo, reiniciar a máquina, repita-o:

 sudo ethtool --offload eth0 gso off tso off sg off gro off

Nos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande. Faça o seguinte:
1. Inicie o navegador web;
2. Limpe o cache do seu navegador;
3. Inicie o Wireshark;
4. Digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004_arq2.html. Seu navegador deve exibir um documento bastante longo e criativo :);
5. Faça um atualização da página (F5);
6. Pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
Na janela de listagem de pacotes, clique sobre a resposta do servidor (200 OK (text/html))
Na janela de detalhes do pacote, clique sobre o nono ".... Reassembled TCP Segments"
- Esta resposta, em vários pacotes, merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma série de linhas de cabeçalho, seguida por uma linha em branco, seguida pela carga útil (Content-Length). Nessa resposta, a carga útil do arquivo em HTML é bastante longo, e a informação de 11747 bytes é muito grande para caber em um único segmento TCP. Assim sendo, a resposta HTTP é quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark. Aqui fica evidente a relação entre camadas: Na camada de aplicação uma grande mensagem que é quebrada pela camada de transporte para "dar conta" de fazer o serviço de entrega.
Responda às seguintes questões:
1. Quantas mensagens HTTP GET foram enviadas pelo seu navegador?
2. Quantas respostas HTTP sua máquina recebeu?
3. Quantos segmentos TCP foram necessários para carregar a resposta?
4. Você percebe alguma lógica no sequenciamento desses segmentos TCP? Se sim, explicite. Tema para o próximo capítulo.
5. Qual é o código de status e a frase associada com a resposta à mensagem HTTP GET? Obs.: Observe os campos do cabeçalho de uma resposta HTTP.
6. No segundo GET realizado, quantos segmentos TCP foram necessários para obtenção da resposta do servidor?
7. O que explica a diferença entre a primeira e segunda requisições?

Documentos HTML com Objetos Incluídos

Agora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu navegador baixa um arquivo principal com objetos incluídos. No nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
1. Inicie o navegador web;
2. Limpe o cache do seu navegador;
3. Inicie o Wireshark;
4. Digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html. Seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não são conteúdos do arquivo em HTML e nem estão depositadas no mesmo servidor, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. As imagens estão em docente.ifsc.edu.br;
Digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq4.html. Seu navegador deve exibir um arquivo pequeno em HTML com cinco imagens incluídas. Estas cinco imagens,diferentemente do caso anterior, estão depositadas no próprio sítio navegado;
Pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
Responda às seguintes questões, separando as respostas para o acesso ao RED29004_arq3.html e RED29004_arq4.html (6 respostas):
1. Quantas mensagens HTTP GET foram enviadas pelo seu navegador em cada acesso?
2. Para quais endereços na Internet estas mensagens foram enviadas em cada acesso?
3. Você consegue dizer se o seu navegador baixou imagens com ou sem paralelismo? Explique e diferencie o comportamento em cada um dos casos.

HTTPS

O Hyper Text Transfer Protocol Secure (HTTPS) é uma implementação do protocolo HTTP sobre uma camada adicional de segurança que utiliza o protocolo SSL/TLS e permite a transmissão de dados numa conexão criptografada através de certificados digitais.
Caso tenha interesse em analisar troca de mensagens HTTPS e verificar seus conteúdos siga o roteiro How to Decrypt SSL and TLS Traffic Using Wireshark

Serviço de Nomes (DNS)

Leitura recomendada

Detalhes sobre DNS

Objetivos

O Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto:

o lado cliente do DNS e
uma pequena análise do protocolo

Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor.

PARTE 1: Consulta simples ao DNS gerada a partir de um comando ping

O comando ping pode ser usado tanto com um endereço IP como com um nome de host. Em última instância, ele sempre enviará pacotes para um endereço IP. No caso de ser usado o endereço de host, ele tentará resolver (mapear) este nome em um endereço IP usando um servidor DNS (local). Ele gera uma pergunta para o servidor (ou para os servidores, caso exista mais de um configurado). Esta experiência mostra como verificar os servidores instalados e, através de uma captura de pacote mostra a estrutura dos cabeçalhos DNS.

Inicialmente consulte e anote quem são os servidores DNS instados na sua máquina. É para estes servidores que serão conduzidas as perguntas DNS. Use a ferramenta nm-tool ou acesso ao arquivo de configuração do sistema:
nmcli dev show | grep DNS
Prepare o wireshark para capturar pacotes. Feche o mozilla ou qualquer outro software de rede parar evitar tráfego DNS que possa vir a confundi-lo.
Execute o ping para um endereço de host conhecido
ping www.ifsc.edu.br
Pare a captura de pacotes no Wireshark e coloque um filtro de display para mostrar apenas mensagens DNS e de ICMP
dns || icmp
Observe os pacotes capturados. Em particular foque no pacote de pergunta que deve ser similar ao mostrado abaixo e deve estar direcionado a um dos servidores DNS. Nos flags do header do pacote DNS é possível observar que é um QUERY (pergunta) a ser resolvido de forma recursiva. A pergunta propriamente dita está no campo QUERIES, onde é colocado o nome a ser resolvido e o tipo do registro solicitado (tipo A) que indica resolução de nome.
Foque agora um pacote de resposta do servidor para o cliente. Deve ter uma estrutura similar ao mostrado abaixo. Nos flags do header do pacote DNS é possível observar que é uma resposta. A resposta propriamente dita está no campo ANSWERS (ele também repete a pergunta no campo QUERIES). Note que podem haver vários registros (RR) retornados, cada um com um tipo. No exemplo abaixo também é retornada uma lista de servidores autorizados (RR tipo NS). Também é retornado o endereço IP destes servidores através de RRs adicionais do tipo A (inclusive endereços IPv6).
Perguntas a serem respondidas, baseado nos pacotes "Standard query" e "Standard query response":
1. Quem são os servidores DNS da sua máquina?
2. O ping gerou pergunta para cada um deles?
3. Qual o tipo da RR associada a pergunta (Queries). O que significa?
4. Qual endereço IP retornado para o www.ifsc.edu.br?
5. Qual endereço IP usado no ping (ver pacote REQUEST ICMP)?
6. Qual protocolo de transporte, camada 4, que foi usado para transportar as mensagens de aplicação DNS?
7. No QUERY realizado foi solicitado consulta recursiva. O servidor aceitou esta solicitação? (ver a resposta do servidor)
8. Quais os servidores autorizados (Authoritative nameservers) foram repassados como resultado de sua consulta?
Logo após o primeiro ping existe mais uma consulta DNS. Esta pergunta é realizada através de uma mensagem do tipo PTR. O ping está tentando verificar qual é o nome da máquina que realmente está respondendo. É o DNS reverso, nesse tipo de colsulta se fornece um IP e o servidor devolve o nome da máquina.
Perguntas a serem respondidas:
1. Qual o IP que se pretende resolver?
2. Qual o nome retornado?
3. O nome retornado é www.ifsc.edu.br? Sim ou não? Explique.

Consultas DNS por meio de ferramentas especializadas

Usando o programa host, Nslookup ou dig, que são executados no terminal, descubra e anote no relatório os endereços IP associados aos seguintes nomes de hosts (máquinas):
- mail.ifsc.edu.br
- www.google.com
- www.gmail.com
Agora descubra e anote no relatório quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host ou dig isso pode ser feito assim:
```
host -t ns ifsc.edu.br
dig -t ns ifsc.edu.br
```
O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio e/ou máquina. Por exemplo, como ele pode-se descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA (Mail Transfer Agent) mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX (Mail eXchange) de um domínio. Novamente as ferramentas a ser utilizada nesse caso podem ser host ou dig. Por exemplo:
```
host -t mx ifsc.edu.br
dig -t mx ifsc.edu.br
```
Descubra e anote no relatório quem é o servidor de emails nos seguintes domínios:
- gmail.com
- hotmail.com
- ifsc.edu.br
Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim:
```
dig -x 200.135.37.65
```
... o dig tem um resultado um pouco mais carregado que os outros utilitários (host e nslookup), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha ;; ANSWER SECTION:. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do dig para respostas curtas:
```
dig -x 200.135.37.65 +short
```
Faça uma consulta iterativa com dig e responda:
```
dig +trace @8.8.8.8 mail.ru.
```
1. Qual foi o RLD (Root Level Domain) consultado?
2. Qual o TLD (Top Level Domain) consultado?
3. Qual o SLD (Second Level Domain) consultado?
4. Como você sabe que foram esses os LDs consultados?

Algumas consultas AAAA

Vamos expandir um pouco nossos horizontes e fazer algumas consultas envolvendo IPv6.

No terminal de sua máquina faça uma consulta e responda: qual o endereço IPv6 dos hosts? Por exemplo:
```
dig AAAA google.com
host -t AAAA google.com
```
1. ipv6.br
2. www.microsoft.com
Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo:
```
dig -x 2001:12ff::10
dig -x 2001:12ff::10 +short
host 2001:12ff::10
```
1. 2801:84:0:2::10
2. 2001:12d0:0:126::183:244
3. 2001:12ff::10

Exemplos de arquivos de um Second Level Domain fictício

Exemplo de arquivos de configuração de um servidor BIND

/etc/bind/db.redes

$TTL	86400
@	IN	SOA	ns.redes.edu.br. root (
		     2016090900		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			  86400 )	; Negative Cache TTL
;
@	IN	NS	ns.redes.edu.br.
@	IN	MX	10	mail.redes.edu.br.
$ORIGIN redes.edu.br.
ns	A	192.168.1.101
www	A	192.168.1.102
www	A	192.168.1.103
www	A	192.168.1.104
www	A	192.168.1.105
www	A	192.168.1.106
www	A	192.168.1.107
ftp	A	192.168.1.108
mail	A	192.168.1.109

/etc/bind/db.2.168.192 (Zona reversa)

$TTL	86400
@	IN	SOA	ns.redes.edu.br. root (
		     2016090900		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			  86400 )	; Negative Cache TTL
;
	IN      NS      ns.redes.edu.br.
101       IN      PTR     ns.redes.edu.br.
102       IN      PTR     www.redes.edu.br.
108       IN      PTR     ftp.redes.edu.br.
109       IN      PTR     mail.redes.edu.br.

Comparando sockets UDP e TCP

Objetivos

Entender o conceito de sockets relacionados aos protocolos UDP e TCP.
- Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para sockets. Um processo é semelhante a um prédio e o socket do processo é semelhante a uma porta em seu interior. A aplicação reside dentro do prédioa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior do prédio mas tem pouco (ou nenhum) controle sobre o exterior.
Simultaneamente explora-se os conceitos relativos aos protocolos UDP e TCP, observando-se a quantidade de mensagens necessárias para a troca de uma simples frase textual.
- Observa-se a "agilidade" do UDP e a robustez do TCP.
Por fim, propõe-se um comparativo entre os dois protocolos da camada de transporte: UDP e TCP.

Leia os slides de 1 à 12 e o 58: Capitulo 3 -- Camada de Transporte

Descrição da aplicação a ser desenvolvida em UDP e TCP

Usaremos a aplicação cliente-servidor simples a seguir para demonstrar a programação de socket:

Um cliente lê uma linha de caracteres (dados) do teclado e a envia para o servidor.
O servidor recebe os dados e converte os caracteres para maiúsculas.
O servidor envia os dados modificados ao cliente.
O cliente recebe os dados modificados e apresenta a linha em sua tela.

Programação de sockets com TCP

Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Pode-se dizer que o TCP é realizado em duas etapas:

Primeiramente eles devem se apresentar, o primeiro socket da Figura abaixo. Isto serve somente para abertura de conexão.
Estabelecer uma conexão TCP, o segundo socket da Figura abaixo. Todos os dados trafegarão pelo segundo socket.

O processo TCPServer tem dois sockets:

A aplicação cliente-servidor usando TCP:

Roteiro

Utilizamos a linguagem Python por expor com clareza os principais conceitos de sockets. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de sockets utilizando a API Posix encontra-se aqui.

Escreva (copie) o código do programa servidor e salve como TCPServer.py

from socket import *
serverPort = 33333
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind(('',serverPort))
#Escuta as requisicoes do TCP do cliente. Numero maximo de conexoes em fila = 1
serverSocket.listen(1)
print 'O servidor esta pronto'
while 1:
	#Quando o cliente bate a essa porta, o programa chama o metodo accept() para serverSocket,
        #que cria um novo socket no servidor, chamado connectionSocket, dedicado a esse cliente
        #especifico. Cliente e servidor, entao, completam a apresentacaoo, criando uma conexao TCP
        #entre o clientSocket do cliente e o connectionSocket do servidor.
	connectionSocket, addr = serverSocket.accept()
	message = connectionSocket.recv(1024)
        print message
	messageMaiuscula = message.upper()
	connectionSocket.send(messageMaiuscula)
	connectionSocket.close()

No terminal da máquina execute a aplicação servidor:
```
python TCPServer.py
```
- Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe.
Deixe o programa servidor rodando nesse terminal.
Em um outro terminal, abra um segundo terminal, pode-se verificar se a porta está aberta com a ferramenta Nmap (the Network Mapper):
- Lembre-se de ajustar ip_do_servidor para o número adequado, ou seja, o IP da máquina onde está rodando o TCPServer.py.
```
 nmap -p 33333 ip_do_servidor
```
Qual o estado dessa porta? Cite e justifique o tipo de serviço.

No segundo terminal, escreva (copie) o código do programa cliente e salve como TCPClient.py.

Lembre-se de ajustar ip_do_servidor para o número adequado, ou seja, o IP da máquina onde está rodando o TCPServer.py. Obs.: mantenha as aspas.

Esse experimento pode ser rodado tanto numa única máquina quanto em máquinas distintas para cliente e servidor.

from socket import *
serverName = 'ip_do_servidor'
serverPort = 33333
#SOCK_STREAM habilita uso do TCP
clientSocket = socket(AF_INET, SOCK_STREAM)
#Representa o estabelecimento da conexao. E o "aperto de maos", onde o cliente e servidor trocam
#informacoes da portas que serao utilizadas pela conexao (socket) propriamente dito
clientSocket.connect((serverName,serverPort))
message = raw_input('Entre com a sentanca em minuculas: ')
#Diferentemente do UDP, aqui nao e necessario encaminhar o endereco do servidor, ja que este socket
#eh uma "tubulacao" direta entre ambos, basta empurrar dados
clientSocket.send(message)
modifiedMessage = clientSocket.recv(1024)
print 'Mensagem do servidor: ', modifiedMessage
clientSocket.close()

Rode o WireShark. Configure a captura na interface any, use o filtro do tipo: tcp.port==33333.
No segundo terminal execute a aplicação cliente:
```
python TCPCliente.py
```
Digite a mensagem que deseja e espere a resposta do servidor. Funcionou?
Com o servidor rodando em seu terminal, faça duas conexões simultâneas. Pode ser dois terminais rodando a aplicação cliente em cada um deles.
Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark.
Pare a captura no Wireshark.
Perguntas:
1. As três primeiras mensagens trocadas apresentam a camada de aplicação, sim ou não? Explique. O que elas significam?
2. Em qual mensagem (número) é que a frase é enviada ao servidor?
3. A mensagem seguinte (quinta) apresenta camada de aplicação? Clique na camada TCP no Wireshark e observe o campo Flags: 0x010 (ACK). O que você acha que isso significa?
4. Qual o conteúdo da mensagem seguinte (sexta)? E da sétima? Explique.
5. Explique as três últimas mensagens. Dica: olhe as figuras 3.39 e 3.40 do Kurose versão 6.
6. Qual é o protocolo da camada de transporte nessa troca de mensagens?
7. Quais são os números de porta e os IPs utilizados?
8. Quem definiu o número de porta do cliente?
9. Quais foram os números de sequência utilizados em todas as mensagens?
10. Qual o número identificador de protocolo TCP no pacote IP?
11. Quantos socktes foram abertos no servidor com um cliente "conectado"? E com dois clientes?
12. Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente. O teste também pode ser feito utilizando máquinas virtuais e/ou vários terminais.
13. Capture todos os pacotes trocados, entre você e seu vizinho. Os números de portas e IPs são ou não iguais?

Programação de sockets com UDP

A aplicação cliente-servidor usando UDP tem a estrutura apresentada na Figura baixo. Utilizamos a linguagem Python por expor com clareza os principais conceitos de sockets. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de sockets utilizando a API Posix encontra-se aqui.

Como fica evidente na Figura acima, há dois processos cliente e servidor que podem ou não rodar em máquinas distintas e se comunicam justamente enviando mensagens via sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes.

Roteiro

Observe que uma mesma máquina pode fazer o papel de cliente e servidor simultaneamente.

Escreva (copie) o programa UDPServer.py

#Os comentarios estao propositalmente sem acentuacao, caso contrario, tem-se erro de sintaxe.
#Esta linha define que pode-se utilizar sockets dentro do programa
from socket import *
#Define explicitamente a porta aberta servidor
serverPort = 22222
#Cria o socket do servidor, denominado serverSocket. O primeiro parametro indica a familia do endereco,
#em particular, AF_INET indica que a rede subjacente esta usando IPv4. O segundo parametro indica que
#o socket eh do tipo SOCK_DGRAM, ou seja, eh um socket UDP.
serverSocket = socket(AF_INET, SOCK_DGRAM)
#Vincula o numero da porta, nesse caso 22222, ao socket do servidor e "abre a porta".
serverSocket.bind(('', serverPort))
print "O servidor esta pronto para recepcao"
#Aguarda indefinidamente por contatos (mensagens) de clientes
while 1:
        message, clientAddress = serverSocket.recvfrom(2048)
        print message
        #Ao receber a mensagem do cliente converte todos os caracteres para maiusculas.
	modifiedMessage = message.upper()
	serverSocket.sendto(modifiedMessage, clientAddress)

Num terminal da máquina execute a aplicação servidor:
```
python UDPServer.py
```
- Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal.

Escreva (copie) o programa cliente. UDPClient.py.

Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP da maquina onde está rodando a aplicação servidor. Obs.: mantenha as aspas.

#Esta linha define que pode-se utilizar sockets dentro do programa
from socket import *
#Define o endereco ip do servidor ao qual o cliente contactara.
#Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP de sua maquina ou de seu vizinho.
serverName = 'ip_do_servidor'
#Define a porta de acesso ao servidor
serverPort = 22222
#Cria o socket do cliente, denominado clientSocket. O primeiro parametro indica a familia do endereco,
#em particular, AF_INET indica que a rede subjacente esta usando IPv4. O segundo parametro indica que
#o socket eh do tipo SOCK_DGRAM, o que significa que eh um socket UDP.
clientSocket = socket(AF_INET, SOCK_DGRAM)
#raw_input eh uma funcao interna da linguagem Python que permite a solicitacao de entrada de dados que
#sera armazenada em message.
message = raw_input('Entre com a sentanca em minuculas: ')
#O metodo sendto() acrescenta o endereco (e porta) de destino a mensagem e envia o pacote resultante
#pelo socket aberto.
clientSocket.sendto(message,(serverName, serverPort))
#Apos o envio do pacote, o cliente aguarda a resposta do servidor armazenando esta na variavel
#modifiedMessage e o endereco de origem eh armazenado em serverAddress. 2048 representa o tamanho do buffer.
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
#Imprime a mensagem recebida na tela.
print modifiedMessage
#Fecha o socket.
clientSocket.close()

Rode o WireShark. Configure a captura na interface any, com o filtro: udp.port == 22222.
Num segundo terminal execute o programa:
```
python UDPClient.py
```
- Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe.
No segundo terminal, aplicação cliente, digite a mensagem que desejar, SEM espaços em branco, e espere a resposta do servidor. Funcionou?
Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando a aplicação cliente.
Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark.
Pare a captura de pacotes.
PERGUNTAS baseadas na captura:
1. Em algum momento foi identificado algum procedimento para estabelecimento de conexão?
2. Em algum campo do UDP existe numeração de mensagens?
3. Qual o número identificador de protocolo UDP no pacote IP?
4. Qual é o checksum no pacote (datagrama) UDP?
5. É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor?
6. Se a mensagem digitada for teste, do cliente para o servidor deve aparacer o campo Data:7465737465 e a resposta do servidor deve aparecer Data: 5445535445. O que significa isso? Dica, olhe na internet o código ASCII.
7. Qual foi a sequência numérica do campo Data em seu teste? Qual o significado?
8. Qual é o protocolo da camada de transporte nessa troca de mensagens?
9. Qual são os dois números de porta e os dois IPs utilizados?
10. Quem definiu o número de porta do cliente?
11. Quantos socktes foram abertos no servidor com um cliente "conectado"? E com dois clientes?
12. Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente.
13. Capture todos os pacotes trocados, entre você e seu vizinho. Os números de portas e IPs são ou não iguais? Explique.
Comparativo entre TCP e UDP:
1. Quantas mensagens foram trocadas entre o servidor e o cliente em cada um dos protocolos para atingir o mesmo objetivo?
2. O que justifica a diferença na quantidade de mensagens trocadas?
3. Discuta as vantagens e desvantagens de cada protocolo.

Desafios para casa

Modifique uma das aplicações cliente-servidor, seja UDP ou TCP, para fazer um pingue-pongue com a mensagem, ou seja, o cliente gera e envia a mensagem, o servidor a devolve, o cliente reenvia a mesma mensagem, o servidor a devolve e assim sucessivamente.
Faça a "Tarefa 1: Servidor Web" do livro do Kurose, página 131, 6a ed.

TCP x UDP

Objetivos

O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP.
Ambos protocolos de transporte podem ser usados por aplicações que precisem se comunicar. Porém cada um deles têm certas propriedades, então a escolha precisa ser realizada baseada nas necessidade de comunicação a ser feita pela aplicação.

Roteiro

O que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos?

O roteiro será executado sobre máquinas virtuais, através do uso do Netkit2. É o primeiro contato, por hora não se preocupe muito com ele, somente siga os passos.

Em primeiro lugar vamos corrigir uma falha do Netkit2:

wget -4 http://docente.ifsc.edu.br/odilson/RED29004/vmlinux -O /home/aluno/netkit2/fs/vmlinux

Copie o texto abaixo, abra o editor Gedit/Pluma, cole o texto e salve o arquivo em /home/aluno/TCPxUDP.conf.

Transmissor[type]=generic
Receptor[type]=generic
Sniffer[type]=generic
 
Transmissor[eth0]=lan0:ip=10.0.0.1/24
Receptor[eth0]=lan0:ip=10.0.0.2/24:rate=10000
Sniffer[eth0]=lan0:ip=10.0.0.3/24

Digite netKit2 no terminal para executá-lo (o link por ícone gráfico não está funcionando).
Carregue o arquivo com a configuração já salva:
```
 File >> Load and Run >> TCPxUDP.conf
```
- Perceba que abrirá uma janela com três abas inferiores, representando três máquina virtuais criadas pelo Netkit, denominadas: Transmissor, Receptor e Sniffer. Cada uma dessas abas é o terminal de configuração de uma das três máquinas virtuais atualmente configuradas no Netkit.
No terminal da máquina do VirtualBox (NÃO do Netkit) execute o comando abaixo, para fazer o download do arquivo a ser usado no experimento. Esse arquivo será salvo num diretório compartilhado com as máquinas no Netkit.
```
wget -4 http://docente.ifsc.edu.br/odilson/RED29004/original.txt -O /home/aluno/lab/shared/original.txt
```
Observe o tamanho do arquivo transferido ... ele deve ter exatamente 6816634 bytes (cerca de 6,6 MB). Você pode fazer isso com o comando ls -l /home/aluno/lab/shared/original.txt.

Transferência utilizando o protocolo TCP

Execute o tcpdump na VM Sniffer. Durante o experimento ele ficará capturando pacotes para futura análise com o Wireshark.
```
tcpdump -i eth0 tcp port 5555 -s 1024 -U -w /hostlab/shared/SnifferTCP.cap
```
- Dica: para copiar textos para os terminais do Netkit, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole clicando sobre a rodinha (scroll) do mouse sobre o terminal desejado do Netkit.
Vamos simular uma taxa de perdas para tornar o ambiente de simulação um pouco mais próximo a realidade. Para tal vamos utilizar o comando tc (Traffic Control) na máquina Transmissor executando:
```
tc qdisc add dev eth0 root netem loss 20%
```
Na máquina Receptor execute o netcat (nc) (utilize man nc para saber os detalhes das flags utilizadas) que abrirá um socket TCP que ficará aguardando conexão na porta 5555. Os dados recebidos serão salvos (através do direcionamento feito através do símbolo >) em arquivoTCP:
```
nc -vvnl 5555 > arquivoTCP
```
Na máquina Transmissor também execute o netcat mas com o objetivo de transmitir o arquivo original.txt para a maquina Receptor. O tempo gasto na transmissão será medido pelo comando time:
```
time nc -vvn 10.0.0.2 5555 < /hostlab/shared/original.txt
```
Após aproximadamente 2 minutos a transmissão será finalizada. Vai aparecer a mensagem com o tempo gasto no Transmissor.
- Anote o tempo apresentado.
Pare a captura de pacotes pelo tcpdump, no terminal da VM Sniffer digite <Ctrl> + <C>.
Execute o WireShark no VirtulBox e abra o arquivo salvo no Sniffer:
```
File >> Open >> /home/aluno/lab/shared/SnifferTCP.cap
```
- Como no o comportamento padrão do Wireshark é redefinir o número de sequência para sempre iniciar em 1 e isso pode atrapalhar nossos experimentos, vamos desabilitar essa funcionalidade:
```
Edit >> Preferences >> Protocols >> TCP >> (Desabilite) Relative sequence numbers >> OK
```
Verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
Analisando a captura de pacotes do WireShark responda:
1. Quais as portas origem e destino escolhidas pelo cliente e servidor?
2. Qual é o número de sequência do primeiro e do último pacote?
3. Qual é o número de sequência do primeiro e do último ACK?
4. É possível calcular o tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos ou descreva a maneira de obtenção do valor. Dica: observe e o primeiro e o último número de sequência e faça uma correlação com o tamanho do arquivo.
5. Qual é o tamanho do último segmento de dados recebido?
6. Apresente os segmentos do 3-way handshake e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula?
7. Apresente os segmentos do fechamento de conexão e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula?

Transferência utilizando o protocolo UDP

Execute o tcpdump na VM Sniffer. Durante o experimento ele ficará capturando pacotes para futura análise com o Wireshark.
```
tcpdump -i eth0 udp port 5555 -s 1024 -U -w /hostlab/shared/SnifferUDP.cap
```
No terminal da máquina do VirtualBox execute o comando abaixo, para fazer o download dos arquivos a serem usados no experimento. Esse arquivo será salvo num diretório compartilhado com as máquinas no Netkit.
```
wget -4 http://tele.sj.ifsc.edu.br/~odilson/RED29004/receptor -O /home/aluno/lab/shared/receptor
wget -4 http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor -O /home/aluno/lab/shared/transmissor
```
Na máquina Receptor acrescente permissão de execução e o execute, conforme a sequência de comandos abaixo:
```
chmod +x /hostlab/shared/receptor
/hostlab/shared/receptor 5555 > arquivoUDP
```
Na máquina Transmissor acrescente permissão de execução:
```
chmod +x /hostlab/shared/transmissor
```

Inicie a transferência do arquivo:

/hostlab/shared/transmissor 10.0.0.2 5555 < /hostlab/shared/original.txt

Quando completar a transferência vai aparecer a mensagem no Transmissor: "Levou XXXXX segundos para transmitir XXXXX bytes".
Pare a captura de pacotes pelo tcpdump, no terminal da VM Sniffer dê um <Ctrl> + <C>.

Execute o WireShark e abra o arquivo salvo no Sniffer:

File >> Open >> /home/aluno/lab/shared/SnifferUDP.cap

Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
Analisando a captura de pacotes do WireShark responda:
1. Qual é o identificar do primeiro e do último pacote? Existe?
2. É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP?
Compare as transferências feitas com os protocolos TCP e UDP em relação, principalmente, ao tempo gasto para transmitir o arquivo e a integridade de dados.
1. O que eles têm em comum?
2. Que diferenças lhe pareceram mais pronunciadas?
3. Como isso deve afetar as aplicações que usam esses protocolos?

Desvendando o TCP - Número de Sequência, Controle de Erros, transmissão duplex

Objetivos

Verificar:
- Controle de Erros: Significado de Número de Sequência, ACK
- Controle de Fluxo: Significado do campo Windows Size; Funcionamento do controle de fluxo;
Utilizar o software netkit2.

Configuração do Laboratório

O roteiro será executado sobre máquinas virtuais, através do uso do Netkit2. Copie o texto abaixo, abra o editor de sua preferência, cole o texto e salve o arquivo em /home/aluno/TCP.conf.

PC1[type]=generic
PC2[type]=generic
PC3[type]=generic
 
 
PC1[eth0]=lan0:ip=10.0.0.1/24
PC2[eth0]=lan0:ip=10.0.0.2/24
PC3[eth0]=lan0:ip=10.0.0.3/24

PARTE 1 - Transmissão sem erros: Verificação de Número de Sequência e Reconhecimentos

Executar a configuração do laboratório no Netkit. Abra o NetKit2 e abra o arquivo de configuração:
```
 File >> Load and Run >> /home/aluno/TCP.conf
```
- Perceba que abrirá uma janela com três abas inferiores, representando três máquina virtuais criadas pelo Netkit, denominadas: PC1, PC2 e PC3. Cada uma dessas abas é o terminal de configuração da respectiva máquina virtual.
Utilize o editor de texto da máquina real, inclua o texto abaixo, e salve como /home/aluno/lab/shared/arq.tx
```
ABCDEFGHIJKLMNOPQRSTUVXZW1234
```
Execute o tcpdump no PC3.
- Dica: para copiar textos para o Netkit, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole clicando sobre a rodinha (scroll) do mouse.
```
  tcpdump -i eth0 tcp port 5555 -s 1024 -U -w /hostlab/shared/TCP_sem_erros.cap
```
Execute o processo servidor no PC2 e prepare o mesmo para limitar a sua capacidade de recepção em cerca de 20 bytes (tamanho do buffer). Isto permitirá ver a quebra do arquivo de 30 bytes em alguns segmentos TCP
```
sysctl -w net.ipv4.tcp_rmem='20 20 20'
nc -l 5555 > arq.rx
```

Envie o arquivo arq.tx a partir do PC1

  nc 10.0.0.2 5555 < /hostlab/shared/arq.tx

No PC3 faça CTRL-C, para parar a caprtura de pacotes.
Abra o arquivo TCP_sem_erros.cap (/home/aluno/lab/shared/TCP_sem_erros.cap) com o Wireshark da máquina do VirtualBox. Você terá algo parecido com o apresentado na Figura 1.

Fig.1 -- Protocolo TCP
Analise como os dados foram transmitidos e reconhecidos.
Perguntas
1. Qual o número de sequência (normalizado pelo Wireshark) de cada segmento de dados transmitido (de PC1 para PC2) e qual o significado do número de reconhecimento em cada um deles?
2. Como foi reconhecido cada segmento enviado?
  - Relate esta análise por segmento usando os timestamps como referência.

PARTE 2 - Transmissão com erros: retransmissões

Repetir todo a parte 1 mas substituir o item 3 por:

  tcpdump -i eth0 tcp port 5555 -s 1024 -U -w /hostlab/shared/TCP_com_erros.cap

E o item 4 por:

sysctl -w net.ipv4.tcp_rmem='20 20 20'
tc qdisc add dev eth0 root netem loss 50% 
nc -l 5555 > arq.rx

Perguntas:
1. Qual o número de sequência (normalizado pelo Wireshark) de cada segmento de dados transmitido (de PC1 para PC2) e qual o significado do número de reconhecimento em cada um deles?
2. Como foi reconhecido cada segmento enviado?
3. Houve perda de pacotes? Como você identificou isso?
4. Os pacotes perdidos foram retransmitidos? Justifique.

PARTE 3 - Testando a capacidade do TCP de enviar dados de forma duplex

Agora vamos fazer um pequeno teste de transmissão de arquivos entre dois colegas e observar o comportamento full-duplex.
No experimento, o arquivo de uma máquina será transmitido para outra e vice-versa.

Feche no Netkit2, se estiver aberto. Isso é para limpar as configurações previamente feitas.
Abra novamente o Netkit2 e carregue o aquivo TCP.conf, Parte 1.
Limite o tamanho do buffer do TCP tanto no PC1 quanto PC2:
```
sysctl -w net.ipv4.tcp_rmem='10000 10000 10000'
```

Num terminal da máquina do Virtualbox baixe os arquivos para o experimento e salve-os no diretório compartilhado com o Netkit2:

wget -4 http://docente.ifsc.edu.br/odilson/RED29004/Servidor.tx -O /home/aluno/lab/shared/Servidor.tx
wget -4 http://docente.ifsc.edu.br/odilson/RED29004/Cliente.tx -O /home/aluno/lab/shared/Cliente.tx

No PC3 inicie a captura de pacotes:

tcpdump -i eth0 tcp port 5555 -s 1024 -U -w /hostlab/shared/fullduplex.cap

No PC1, que fará o papel de servidor por aguardar a conexão do cliente, execute o comando abaixo. Perceba que o Servidor vai enviar (o sinal < indica isso) um arquivo e vai receber e salvar (o sinal > indica isso) outro do Cliente.
```
nc -l 5555 < /hostlab/shared/Servidor.tx > Arq_recebido.rx
```
No PC2, que fará o papel de cliente, execute o comando abaixo. Perceba que ele também vai enviar e receber arquivo do servidor.
```
nc 10.0.0.1 5555 < /hostlab/shared/Cliente.tx > Arq_recebido.rx
```
Confira o conteúdo dos arquivos recebidos no PC1 e PC2:
```
cat Arq_recebido.rx
```
Pare a captura de pacotes no PC3 com <Ctrl> + <C>.
Execute o Wireshark e confira a troca de pacotes abrindo o arquivo salvo:
```
File >> Open >> /home/aluno/lab/shared/fullduplex.cap
```

Perguntas:

Onde pode ser observado a comunicação full-duplex?
Qual é a relação entre os comandos no terminal tanto do cliente como do servidor com a comunicação full-duplex?
Como os ACKs são propagados, em pacotes exclusivos ou de carona (piggyback) com os dados?

TCP: Controle de congestionamento e equidade

Objetivos

Visualização, através de gráficos, do controle de congestionamento e a consequente equidade do protocolo TCP.
Visualização, através de gráficos, da disputa por banda entre os protocolos TCP e UDP.
Utilização do software Iperf (iperf –h para help) para gerar tráfego entre duas máquinas - cliente e servidor - e permitir a observação do comportamento da disputa de banda.
Utilização do software netkit2 para simulação de redes "complexas".

Parte 1: Somente fluxos TCP

O roteiro será executado sobre máquinas virtuais, através do uso do Netkit2.
Para realização dos ensaios será montada a rede virtual apresentada na Figura 1.

Figura 1 - Rede para testes

Copie o texto abaixo e crie um arquivo, salve-o como /home/aluno/TCP.conf.

# Definição das máquinas
R1[type]=router
PC1[type]=generic
PC2[type]=generic
PC3[type]=generic

# Definição dos roteadores padrão
PC1[default_gateway]=10.0.0.254
PC2[default_gateway]=10.0.1.254
PC3[default_gateway]=10.0.1.254

# Definição das interfaces do roteador 
R1[eth0]=lan0:ip=10.0.0.254/24:rate=10000
R1[eth1]=lan1:ip=10.0.1.254/24:rate=10000

# Definição das interfaces dos PCs
PC1[eth0]=lan0:ip=10.0.0.1/24:rate=10000
PC2[eth0]=lan1:ip=10.0.1.2/24:rate=10000
PC3[eth0]=lan1:ip=10.0.1.3/24:rate=10000

Execute o NetKit2.
Carregue o arquivo de configuração:
```
 File >> Load and Run >> /home/aluno/TCP.conf
```
- Perceba que abrirá uma janela com quatro abas inferiores, representando um roteador e três máquina virtuais criadas pelo Netkit, denominadas: R1, PC1, PC2 e PC3. Cada uma dessas abas é o terminal de configuração do respectivo equipamento.
- Ao clicar no menu File - Graph, pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
Execute no PC3 o tcpdump para salvar a troca de dados entre o PC1 e o PC2 num arquivo:
```
tcpdump -i eth0 -w /hostlab/shared/FluxosTCP.cap
```
- Para copiar comando para os terminais das máquinas virtuais: copie o texto desejado, no Netkit selecione o terminal da máquina desejada e clique sobre a "rodinha" do mouse que o texto será colado.

No PC1 (servidor) execute:

iperf -s -p 2000 & iperf -s -p 2001 & iperf -s -p 2002 &

No PC2 (cliente) execute (copie a três linhas e cole no terminal adequado e em seguida tecle <Enter>):

iperf -c 10.0.0.1 -f m -i 1 -t 90 -p 2000 -l 1300 & \
(sleep 20; iperf -c 10.0.0.1 -f m -i 1 -t 70 -p 2001 -l 1300) & \
(sleep 30; iperf -c 10.0.0.1 -f m -i 1 -t 60 -p 2002 -l 1300) &

Fique monitorando o PC2 até a tela parar de ser atualizada, aproximadamente 90 s.
Pare os processos nos três PCs utilizando CTRL-C.
Abra o Wireshark.

Abra o arquivo

File >> Open >> /home/aluno/lab/shared/FluxosTCP.cap

No wireshark acesse Statistics >> IO Graph e, na tela que abrir, ajuste TODOS os parâmetros para obter um gráfico similar ao apresentado na Figura 2:

Figura 2 - Captura de 3 fluxos de dados
1. Clique em Add a new graph (sinal de + no canto inferior esquerdo)
  - X Enabled
  - Duplo clique sobre o campo Graph name: Porta 2000
  - Duplo clique sobre o campo Display Filter: tcp.port==2000
  - Duplo clique sobre o campo Color: clique no botão logo a direita e selecione a cor desejada.
2. Para os demais gráficos copie o anterior clicando no ícone com dois retângulos no canto inferior esquerdo
  - Edite nome, porta e cor.
Salve esse gráfico no relatório.
Responda:
1. Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor.
2. Explique os filtros aplicados no gráfico do Wireshark.
  - Quais são os 4 gráficos apresentados?
  - Há uma relação de valor entre as curvas?
  - Qual é esta relação?
3. Por que a curva vermelha se sobrepõe a curva preta nos primeiros 20 segundos? Considere o início do tempo onde há início de tráfego!
4. Qual é a relação entre a curva preta e as curvas vermelha e verde no intervalo entre 20 e 30 segundos?
5. Explique a relação entre as 4 curvas e o comando do cliente no intervalo entre 20 e 40 segundos.
6. Qual é o mecanismo do TCP que explica a grande oscilação das curvas, principalmente percebida no intervalo entre 20 e 30 segundos?

Parte 2: Fluxos TCP mais UDP

Agora vamos dificultar a vida do TCP incluindo um tráfego UDP. O gráfico gerado deverá apresentar a competição pelo meio de transmissão entre os diversos fluxos de dados.

Deslique o NetKit2, para limpar todos os processos e buffers:
```
File >> Quit
```

Copie o texto abaixo e crie um arquivo, salve-o como /home/aluno/TCPxUDP.conf:

# Definição das máquinas
R1[type]=router
PC1[type]=generic
PC2[type]=generic
PC3[type]=generic
PC4[type]=generic
 
# Definição dos roteadores padrão
PC1[default_gateway]=10.0.0.254
PC2[default_gateway]=10.0.1.254
PC3[default_gateway]=10.0.1.254
PC4[default_gateway]=10.0.1.254
 
# Definição das interfaces do roteador 
R1[eth0]=lan0:ip=10.0.0.254/24:rate=10000
R1[eth1]=lan1:ip=10.0.1.254/24:rate=10000
 
# Definição das interfaces dos PCs
PC1[eth0]=lan0:ip=10.0.0.1/24:rate=10000
PC2[eth0]=lan1:ip=10.0.1.2/24:rate=10000
PC3[eth0]=lan1:ip=10.0.1.3/24:rate=10000
PC4[eth0]=lan1:ip=10.0.1.4/24:rate=10000

Execute o NetKit2 e carregue o arquivo de configuração.

No PC4 execute:

tcpdump -i eth0 -w /hostlab/shared/FluxosTCP+UDP.cap

No PC1 execute:

iperf -s -u -p 2000 & iperf -s -p 2001 &

A próxima etapa deve ser executada "simultaneamente" nos PC2 e PC3.
1. Para isso copie o texto abaixo e cole no terminal do PC2, ainda NÃO tecle <Enter>:
```
iperf -u -c 10.0.0.1 -f m -i 1 -t 60 -p 2000 -l 1300 -b 10000000
```
2. Copie o texto abaixo e cole no terminal do PC3, ainda NÃO tecle <Enter>:
```
iperf -c 10.0.0.1 -f m -i 1 -t 90 -p 2001 -l 1300
```
3. Tecle <Enter> no PC3 e PC2, NESSA ORDEM, "simultaneamente".
Fique monitorando o PC3 a tela parar de ser atualizada, aproximadamente 90 s.
Pare os processos nos quatro PCs utilizando CTRL-C.
Execute o Wireshark e abra o arquivo /home/aluno/lab/shared/FluxosTCP+UDP.cap.
Edite as configurações do gráfico e deixe parecido com o da Figura 3.
- No Graph 2 altere o filtro para udp.port==2000.
- No Graph 3 altere o filtro para tcp.port==2001.
  
  Figura 3 - Captura de 2 fluxos de dados: TCP e UDP
Salve o gráfico no relatório.
Responda:
1. Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor.
2. Qual a relação dos filtros aplicados no gráfico e os comandos executados no terminal.
  - Quais são os 4 gráficos apresentados?
  - Há uma relação de valor entre as curvas?
  - Qual é esta relação?
3. Qual é a relação entre a curva preta e as curvas vermelha e verde no intervalo até por volta de 60 segundos?
4. O que ocorreu com o gráfico verde após os 60 segundos. O que explica esse comportamento?
5. Explique o gráfico azul, em barras.
Compare o comportamento dos vários fluxos de dados, nos dois experimentos, com e sem o UDP.

Interligação de duas redes através de um roteador

Objetivos

Introdução ao mundo IP
Verificação das configurações de interfaces de rede
Verificação de tabelas de roteamento nos hospedeiros e no roteador
Verificação de movimentação de pacotes (rotas) em roteadores

Fonte Base

Endereçamento MAC x Endereçamento IP

Procedimento

Construir uma rede no Netkit com quatro PCs e um roteador. Com o editor de texto copie o conteúdo abaixo e salve no arquivo /home/aluno/roteador.conf:

r1[type]=router
 
pc1[type]=generic
pc2[type]=generic 
pc3[type]=generic
pc4[type]=generic
 
r1[eth0]=lan0:ip=192.168.200.254/24
r1[eth1]=lan1:ip=192.168.100.254/24
 
pc1[eth0]=lan0:ip=192.168.200.1/24
pc1[default_gateway]=192.168.200.254
 
pc2[eth0]=lan0:ip=192.168.200.2/24
pc2[default_gateway]=192.168.200.254
 
pc3[eth0]=lan1
 
pc4[eth0]=lan1:ip=192.168.100.2/24
pc4[default_gateway]=192.168.100.254

Rodar o netkit2.
Carregar o arquivo roteador.conf a partir do Netkit2:
```
File >> Load and Run
```
Visualizar a rede a ser implementada:
```
File >> Graph
```
- Observe que a rede é composta de 4 PCs (pc1 - pc4) e 1 roteador (r1). O roteador possui duas interfaces de rede que interliga as duas sub-redes.
Anotar os endereços de hardware (ou MAC) e IP de cada dispositivo na rede. No terminal de cada PC execute:
```
ifconfig
```
Observar, interpretar e anotar a tabela de roteamento nos hospedeiros pc1 e pc4. Identificar os default gateways em cada PC.
```
route -n
```
Observar, interpretar e anotar a tabela de roteamento no roteador (r1)
```
exit
route -n
```
Observar, "provar" e anotar que pacotes indo do pc1 para pc2 na lan0 são enviados diretamente para pc2, ou seja, entrega direta. Explique a entrega direta.
- Use o ping, tcpdump e seu diagrama de rede como apoio.
- Lembre-se que você pode verificar o fluxo de dados individualmente em cada interface de rede e, portanto, se certificar que se há ou não pacotes atravessando o roteador:
  - Deixe o ping entre pc1 e pc2, em pc1 execute:
    ping 192.168.200.2
  - Num primeiro momento em r1:
    exit tcpdump -i eth0 -n -e
  - Em seguida, ainda em r1:
    tcpdump -i eth1 -n -e
  - Ver: manpage do tcpdump
Observar, "provar" e anotar que pacotes indo de pc1 para pc4 são encaminhados ao roteador e, em seguida, entregues ao destino, ou seja, entrega indireta. Explique a entrega indireta.

Configuração básica de interface de rede

No pc3 teste a conectividade com os demais pcs, por exemplo, fazendo pings para o pc1 e pc4:
```
ping 192.168.200.1 
ping 192.168.100.2
```
- Perceba que não há conectividade, não há resposta aos pings, dado que a interface de rede do pc3 não está devidamente configurada.
Assim sendo, configure a interface de rede no pc3.
- Anote todos os comandos executados.
- O mesmo deverá ser capaz de "pingar" para qualquer outro PC ou ser "pingado".
- Dicas:
  1. Observe a configuração de rede do pc4, que está na mesma sub-rede, e tente adaptá-la para o pc3.
  2. Utilize ferramentas de configuração ifconfig e route. Use o man ou procure na web como utilizar esses comandos.
Execute o comando ping do pc3 para o pc4. Obteve sucesso? Se não corrija as configurações.
Execute o comando ping do pc3 para o pc1. Obteve sucesso? Se não corrija as configurações.
Execute o comando ping do pc2 para o pc3. Obteve sucesso? Se não corrija as configurações.

Referências adicionais

[http://linux-ip.net/html Guia de Administração da Camada IP no Linux

Tabelas Estáticas de Roteamento

Objetivos

Analisar o funcionamento de roteadores com tabelas estáticas de roteamento.
Verificar a entrega direta e indireta de pacotes.
Analisar loops em rede.

Para atingir tais objetivos utilizaremos o netkit2. Leia o tutorial de como o netkit2 trabalha com roteadores.

Kurose Cap. 4: slides 1-25, 29-35 e 57-62

Arquitetura de rede

Em todos os experimentos será utilizado como base a seguinte arquitetura de rede:

Tabelas estáticas de roteamento

Crie em seu computador um arquivo com nome /home/aluno/rot1.conf, com o seguinte conteúdo:

# Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
 
# Routers definitions
r1[type]=gateway
r2[type]=gateway
r3[type]=gateway
 
# Hosts' interfaces to local routers
pc1[eth0]=link0:ip=192.168.0.1/24
pc2[eth0]=link1:ip=192.168.1.1/24
pc3[eth0]=link2:ip=192.168.2.1/24
 
# Routers' interfaces to local networks
r1[eth0]=link0:ip=192.168.0.254/24
r2[eth0]=link1:ip=192.168.1.254/24
r3[eth0]=link2:ip=192.168.2.254/24
 
# Network "backbone" links
r1[eth1]=backbone0:ip=10.0.0.1/30
r1[eth2]=backbone1:ip=10.0.1.1/30
 
r2[eth1]=backbone0:ip=10.0.0.2/30
r2[eth2]=backbone2:ip=10.0.2.1/30
 
r3[eth1]=backbone1:ip=10.0.1.2/30
r3[eth2]=backbone2:ip=10.0.2.2/30

Rode o netKit em seu computador. Em um terminal digite:
```
 netkit2 &
```
No menu File - Load and Run, procure o arquivo /home/aluno/rot1.conf e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3.
Ao clicar no menu File - Graph, pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.

Nos três roteadores rode os seguintes comandos para inibir a filtragem de pacotes com rotas incompletas (copie o texto abaixo e cole nos respectivos terminas, com um click sobre a rodinha do mouse):

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter

Testes de conectividade de enlace e configuração do default gateway.
1. Por exemplo, no pc1 execute o comando:
```
 ping 192.168.0.254
```
  Obteve sucesso? Sim ou não e por quê?
2. Teste a conectividade do pc1 executando o comando:
```
 ping 10.0.0.1
```
  Obteve sucesso? Sim ou não e por quê?
3. Por exemplo, no pc1 execute o comando:
```
 ping 10.0.0.2
```
  Obteve sucesso? Sim ou não e por quê?
4. Configure o roteador padrão em todos os PCs, por exemplo no pc1:
```
 route add -net default gw 192.168.0.254
```
5. Teste novamente a conectividade, no pc1 execute o comando:
```
 ping 10.0.0.1
```
  e
```
 ping 10.0.0.2
```
  Obteve sucesso? O comportamento foi o mesmo dos iten 6.2 e 6.3? Sim ou não e por quê?
6. Com os ping do item anterior ativos (um a cada tempo) rode o wireshark no r1 (clique na aba r1 e em seguida no menu wireshark any).
  1. Qual a origem e destino dos pacotes? Por quê?
  2. Qual a diferença no ping entre os dois itens?
Iniciando o roteamento.
1. Deixe o ping do item 6.3 e o wireshark do item 6.6 rodando e estabeleça uma rota no roteador r2 com o comando:
```
 route add -net 192.168.0.0/24 gw 10.0.0.1
```
  O que ocorreu com o ping e o wireshark? Por quê?
  - Interpretando o comando: route add (adiciona rota) -net 192.168.0.0/24 (para a rede 192.168.0.0/24) gw 10.0.0.1 (utilizando a interface 10.0.0.1, enlace direto, do roteador r1).
2. Em todos os roteadores crie rotas para todas as redes. Em cada roteador deve-se criar 3 rotas, para as sub-redes "distantes". Lembre-se que os enlaces diretos já criam automaticamente rotas para as respectivas sub-redes diretamente conectadas ao equipamento, ou seja, entrega direta. Se tudo estiver correto, todos os PCs devem pingar entre si.
3. Trace e anote as rotas entre os hosts através do traceroute.
Testando a queda de enlace.
1. Com todas as rotas em perfeito funcionamento, gere um ping do pc1 para o pc3 e execute wireshark any no r1 , em seguida "derrube" o enlace entre o r1 e r3. Por exemplo, no r3 execute o comando:
```
 ifconfig eth1 down
```
  O que ocorreu com o ping e o wireshark? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede?

Testando campo TTL com loop na rede

No arquivo abaixo as tabelas de roteamento geram um loop. Copie o conteúdo abaixo e crie um arquivo /home/aluno/loop.conf

# Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
 
# Default gateways definitions
pc1[default_gateway]=192.168.0.254
pc2[default_gateway]=192.168.1.254
pc3[default_gateway]=192.168.2.254
 
# Routers definitions
r1[type]=gateway
r2[type]=gateway
r3[type]=gateway
 
# Hosts' interfaces to local routers
pc1[eth0]=link0:ip=192.168.0.1/24
pc2[eth0]=link1:ip=192.168.1.1/24
pc3[eth0]=link2:ip=192.168.2.1/24
 
# Routers' interfaces to local networks
r1[eth0]=link0:ip=192.168.0.254/24
r2[eth0]=link1:ip=192.168.1.254/24
r3[eth0]=link2:ip=192.168.2.254/24
 
# Network "backbone" links
r1[eth1]=backbone0:ip=10.0.0.1/30
r1[eth2]=backbone1:ip=10.0.1.1/30
 
r2[eth1]=backbone0:ip=10.0.0.2/30
r2[eth2]=backbone2:ip=10.0.2.1/30
 
r3[eth1]=backbone1:ip=10.0.1.2/30
r3[eth2]=backbone2:ip=10.0.2.2/30 

# Routes definition
r1[route]=192.168.2.0/24:gateway=10.0.0.2
r2[route]=192.168.2.0/24:gateway=10.0.2.2
r3[route]=192.168.2.0/24:gateway=10.0.1.1

Analisando o arquivo de configuração do Netkit mostre onde é criado o loop.

Lembre-se de rodar os comandos para evitar filtros de pacotes nos três roteadores:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter

Configure os roteadores para salvar os dados coletados, com os seguintes comandos:

No r1:
```
tcpdump -i eth1 -w /hostlab/r1.pcap &
```
No r2:
```
tcpdump -i eth2 -w /hostlab/r2.pcap &
```
No r3:
```
tcpdump -i eth1 -w /hostlab/r3.pcap &
```

Gere um tráfego controlado a partir do pc1:
```
ping -c2 192.168.2.1
```
Pare (Ctrl + C) todas as coletas de dados nos roteadores.
Com o Wireshark abra os três arquivos de pacotes capturados: /home/aluno/lab/r1.pcap...r3.pcap. Deixe as três janelas do Wireshark lado a lado e responda:
1. Em qual roteador os pacotes são descartados? Observe os pacotes de número de sequência 1 e explique sua resposta.
2. Qual o significado da linha com o seguinte conteúdo parcial: 192.168.0.1 ICMP 128 Time-to-live exceeded (Time to live exceeded in transit)?
3. Explique qual o objetivo do campo ttl no cabeçalho IP?

Protocolos de roteamento dinâmicos - RIP

Objetivo

Analisar o funcionamento de protocolo dinâmicos de roteamento RIP.

O Pacote Quagga: breve introdução

O pacote Quagga fornece um conjunto de processos (daemons) com facilidades para a construção da tabela de roteamento de um sistema. O projeto Quagga é derivado do pacote Zebra. O esquema abaixo mostra a estrutura do Quagga.

Acima do kernel se executam processos especializados para a configuração da tabela de roteamento. Note que a tabela de roteamento é mantida pelo kernel do Sistema Operacional Linux/Unix e qualquer modificação será realizada a partir da API (Application Programming Interface) do sistema. O processo Zebra centraliza todo o gerenciamento da tabela recebendo e repassando informações para outros processos que executam um determinado protocolo de roteamento. Por exemplo, no esquema mostrado existem 3 processos responsáveis pela execução dos protocolos BGP, RIP e OSPF. É possível executar vários protocolos de roteamento dinâmico simultaneamente.

Cada processo do Quagga possui o seu próprio arquivo de configuração e um terminal para receber comandos (um processo shell chamado vtysh). Cada terminal se comunica com seu deamon por uma porta específica. No arquivo do Zebra deverão constar as configurações estáticas.

Os deamons do sistema são chamados pelos seguintes nomes:

zebra (acesso pela porta 2601 no vty);
ripd (acesso pela porta 2602 no vty);
ospfd (acesso pela porta 2604 no vty);
bgpd (acesso pela porta 2605 no vty);

Os deamons possuem arquivos de configuração por default localizados normalmente no diretório /etc/quagga e possuindo a terminação conf: por exemplo: zebra.conf para o processo zebra. Entretanto, em nossos laboratórios, fazendo uso do Netkit, será comum usarmos arquivos de configuração fornecidos na linha de comando:

#zebra -d -f /hostlab/r1/zebra.conf.

Nos arquivos de configuração podemos colocar informações tais como senhas para o terminal vty, configurações de depuração, de roteamento e de log. O que segue aos pontos de exclamação (vale também \#) são comentários.

Através do Zebra (e seu arquivo de configuração) é possível ligar/desligar interfaces e atribuir endereços as mesmas. Também pode-se acrescentar rotas.

Roteiro

Baseado no diagrama abaixo, executaremos o protocolo de roteamento RIP a partir do Quagga, de tal modo que o sistema se auto recuperará, por exemplo, da queda de um enlace.

Crie em seu computador um arquivo com nome /home/aluno/RIP.conf. Observe que nessa configuração já está inserida a definição dos default gateway de cada pc. O conteúdo do arquivo é o seguinte:

# Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic

# Default gateways definitions
pc1[default_gateway]=192.168.0.254
pc2[default_gateway]=192.168.1.254
pc3[default_gateway]=192.168.2.254

# Routers definitions
r1[type]=gateway
r2[type]=gateway
r3[type]=gateway
 
# Hosts' interfaces to local routers
pc1[eth0]=link0:ip=192.168.0.1/24
pc2[eth0]=link1:ip=192.168.1.1/24
pc3[eth0]=link2:ip=192.168.2.1/24
 
# Routers' interfaces to local networks
r1[eth0]=link0:ip=192.168.0.254/24
r2[eth0]=link1:ip=192.168.1.254/24
r3[eth0]=link2:ip=192.168.2.254/24
 
# Network "backbone" links
r1[eth1]=backbone0:ip=10.0.0.1/30
r1[eth2]=backbone1:ip=10.0.1.1/30
 
r2[eth1]=backbone0:ip=10.0.0.2/30
r2[eth2]=backbone2:ip=10.0.2.1/30
 
r3[eth1]=backbone1:ip=10.0.1.2/30
r3[eth2]=backbone2:ip=10.0.2.2/30

Em cada roteador, configure o serviço RIP.
1. O Netkit cria no diretório home do usuário (/home/aluno) uma pasta chamada lab.
2. Nesta pasta, há uma pasta exclusiva para cada equipamento da rede em teste.
3. Neste diretório podem ser colocados arquivos de configuração de serviços a serem executados nas máquinas virtuais do Netkit. É por ali que será configurado, primeiramente, o Quagga, software de roteamento que implementa RIP, OSPF e/ou BGP.
4. O arquivo de configuração abaixo mostra a configuração do Quagga para o roteador r1. Salve este arquivo como /home/aluno/lab/r1/zebra.conf.
```
hostname r1

interface eth0
   ip address 192.168.0.254/24
interface eth1
   ip address 10.0.0.1/30
interface eth2
   ip address 10.0.1.1/30

log stdout
```
5. Em seguida, adapte o arquivo para os roteadores r2 e r3 observando a figura:
  - Configure cada interface de cada roteador com seu respectivo IP, baseado na figura.
  - Salve no respectivo diretório de cada roteador.
Para o caso particular de nossa arquitetura de rede, o arquivo de configuração para o RIP pode ser único, assim sendo, vamos criar o arquivo /home/aluno/lab/shared/ripd.conf com o seguinte conteúdo:
```
router rip
  redistribute connected
  redistribute static
  network eth1
  network eth2
```
No r2 deixe o tcpdump capturando pacotes em todas as interfaces
```
 tcpdump -i any -vvv -w /hostlab/r2/r2_RIP.pcap &
```
No pc1 execute:
```
 ping 192.168.2.1
```
O ping está funcionando? Por quê?
Deixe o ping rodando!
Inicie o daemon quagga em todos os roteadores (r1, r2 e r3).
```
 service quagga start
```
Execute o Quagga e o RIP em todos os roteadores (r1, r2 e r3), a partir dos arquivos criados.
1. Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do Netkit, ou seja, "/home/aluno/lab" na máquina real é a mesma pasta que "/hostlab/" nas máquinas virtuais do Netkit.
2. Para iniciar os serviços no r1, faça algo como o que está no exemplo abaixo.
```
zebra -d -f /hostlab/r1/zebra.conf
ripd -d -f /hostlab/shared/ripd.conf
```
3. Repita o procedimento para r2 e r3 utilizando os arquivos corretos, por exemplo, para r2:
```
zebra -d -f /hostlab/r2/zebra.conf
ripd -d -f /hostlab/shared/ripd.conf
```
Olhe o terminal do pc1, o que ocorreu com o ping? Por quê?
Observando o estado do sistema. Vamos usar comandos para verificar o estado dos roteadores.
1. Solicitar uma sessão com o vtysh no zebrad:
```
 vtysh
```
2. Verifique o estado das interfaces usando o comando:
```
 show interface
```
3. Verifique se o roteador está habilitado para roteamento:
```
 show ip forwarding
```
4. Verifique o estado da tabela de roteamento usando o comando:
```
 show ip route
```
  Interprete detalhadamente essa tabela! Você consegue visualizar o mapa da rede a partir dessa tabela?
5. Verifique a configuração atual do roteador:
```
 show run
```
6. Sair do vtysh:
```
exit
```
Teste as demais conectividades entre os PCs com pings mútuos. Tudo funcionando?
A partir de cada PC trace a rota (traceroute) para os demais PC e anote-as.
Com o route -n e/ou netstat -r verifique a anote as rotas de cada roteador.
Desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens.
1. "Derrube" o enlace r1-r3, no r1 execute:
```
vtysh 2061 
conf t
interface eth2 
shutdown
```
  - Significado dos comandos:
    1. Entra no zebrad.
    2. Entra no modo de configuração.
    3. Entra na referida interface a ser operada, no caso eth2.
    4. Desativa a interface. Se desejado pode-se ativá-la novamente com no shutdown.
Monitorando o ping, aguarde até o retorno das repostas ao mesmo. É comum demorar até uns 2-3 minutos.
1. Anote o número de sequência do último ping com sucesso antes da "derrubada" do enlace e o primeiro após a retorno da funcionamento normal do ping.
Pare todos os pings.
Pare o tcpdump no r2:
```
 fg
<Ctrl + c>
```
Teste as conectividades. O que aconteceu?
Retrace e anote as rotas executando nos roteadores
```
 vtysh 2061
show ip route
```
e
```
 traceroute
```
a partir dos PCs.
1. São diferentes do caso original (todos enlaces ativos)? Por quê?
2. Quais os caminhos/rotas que foram reescritos? Por quê? Obs.: estão relacionados com a interface desativada.
Abra com o Wireshark o arquivo /home/aluno/r2/r2_RIP.pcap, filtre por rip. Responda:
- Clique sobre a mensagem e expanda o campo Routing Information Protocol na janela central.
- Os roteadores são identificados por seus IPs.
- O campo Metric indica o número de saltos do roteador em questão até a rede.
- Observe que na formação das rotas surgem métricas iguais a 3, mas são estabilizadas em 2.
- Observe que pode haver métricas com número 16 (~infinito).
1. Tente compreender as mensagens RIPv2 trocadas desde o início explicando-as.
2. Prove que até aproximadamente a mensagem 30 as rotas todas foram formadas.
3. Justifique/explique as métricas iguais a 3.
4. As mensagens são trocadas aproximadamente a cada minuto?
5. Qual o número (No.) da mensagem onde a rede apresentou problemas com rotas (obs: retire o filtro rip e procure no número de sequência dos pings (seq) os números anotados no item 15.1).
6. Quais e quantas mensagens (número) são trocadas entre os roteadores para restabelecer as rotas?
7. Pesquise o significado do endereço 224.0.0.9.

Protocolos de roteamento dinâmicos - OSPF

Objetivo

Analisar o funcionamento de protocolo dinâmicos de roteamento OSPF.

Roteiro

A rede a ser analisada será a mesma que nos casos anteriores.

Crie em seu computador um arquivo com nome /home/aluno/OSPF.conf. O conteúdo do arquivo é o seguinte:

# Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic

# Default gateways definitions
pc1[default_gateway]=192.168.0.254
pc2[default_gateway]=192.168.1.254
pc3[default_gateway]=192.168.2.254

# Routers definitions
r1[type]=gateway
r2[type]=gateway
r3[type]=gateway
 
# Hosts' interfaces to local routers
pc1[eth0]=link0:ip=192.168.0.1/24
pc2[eth0]=link1:ip=192.168.1.1/24
pc3[eth0]=link2:ip=192.168.2.1/24
 
# Routers' interfaces to local networks
r1[eth0]=link0:ip=192.168.0.254/24
r2[eth0]=link1:ip=192.168.1.254/24
r3[eth0]=link2:ip=192.168.2.254/24
 
# Network "backbone" links
r1[eth1]=backbone0:ip=10.0.0.1/30
r1[eth2]=backbone1:ip=10.0.1.1/30
 
r2[eth1]=backbone0:ip=10.0.0.2/30
r2[eth2]=backbone2:ip=10.0.2.1/30
 
r3[eth1]=backbone1:ip=10.0.1.2/30
r3[eth2]=backbone2:ip=10.0.2.2/30

Em cada roteador, configure o serviço Zebra.
1. O Netkit cria no diretório home do usuário (/home/aluno) uma pasta chamada lab.
2. Nesta pasta, há uma pasta exclusiva para cada equipamento da rede em teste.
3. Neste diretório podem ser colocados arquivos de configuração de serviços a serem executados nas máquinas virtuais do Netkit. É por ali que será configurado, primeiramente, o Quagga, software de roteamento que implementa RIP, OSPF e/ou BGP.
4. O arquivo de configuração abaixo mostra a configuração do Quagga para o roteador r1. Salve este arquivo como /home/aluno/lab/r1/zebra.conf.
```
hostname r1

interface eth0
   ip address 192.168.0.254/24
interface eth1
   ip address 10.0.0.1/30
interface eth2
   ip address 10.0.1.1/30

log stdout
```
5. Em seguida, adapte o arquivo para os roteadores r2 e r3 observando a figura:
  - Configure cada interface de cada roteador com seu respectivo IP, baseado na figura.
  - Salve no respectivo diretório de cada roteador.

Crie o arquivo de configuração para o OSPF no roteador r1, /home/aluno/lab/r1/ospfd.conf:

#Router r1
#
hostname r1
password r1
enable password r1
#
interface eth0
interface eth1
interface eth2
!ip ospf network point-to-point
router ospf
passive-interface eth0
network 192.168.0.0/24 area 0
network 10.0.0.0/30 area 0
network 10.0.1.0/30 area 0
#
log stdout

Crie o arquivo ospfd.conf para r2 e r3 adaptando o arquivo acima:
1. - Configure cada interface de cada roteador com seu respectivo IP e endereço de rede, baseado na figura.
  - Salve no respectivo diretório de cada roteador.
No r2 deixe o tcpdump capturando pacotes em todas as interfaces
```
 tcpdump -i any -vvv -w /hostlab/r2/r2_OSPF.pcap &
```
A partir do pc1 deixe rodando o ping
```
 ping 192.168.2.1
```
Inicie o daemon quagga em todos os roteadores (r1, r2 e r3).
```
 service quagga start
```

Execute o Quagga e o OSPF a partir dos arquivos criados. No r1:

zebra -d -f /hostlab/r1/zebra.conf
ospfd -d -f /hostlab/r1/ospfd.conf

No r2:

zebra -d -f /hostlab/r2/zebra.conf
ospfd -d -f /hostlab/r2/ospfd.conf

No r3:

zebra -d -f /hostlab/r3/zebra.conf
ospfd -d -f /hostlab/r3/ospfd.conf

A partir de cada PC trace a rota (traceroute) para os demais PC e anote-as.
Com o route -n e/ou netstat -r verifique a anote as rotas de cada roteador.
Desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens.
1. "Derrube" o enlace r1-r3, no r1 execute:
```
vtysh 2061
conf t
interface eth2
shutdown
```
  - Significado dos comandos:
    1. Entra no zebrad.
    2. Entra no mode de configuração.
    3. Entra na referida interface a ser operada, no caso eth2.
    4. Desativa a interface. Se desejado pode-se reativá-la com no shutdown.
Monitorando o ping, aguarde até o retorno das repostas ao mesmo. A parada é praticamente imperceptível.
1. Anote o número de sequência do último ping com sucesso antes da "derrubada" do enlace e o primeiro após a retorno da funcionamento normal do ping.
Pare todos os pings.
Pare o tcpdump no r2:
```
 fg
<Ctrl + c>
```
Teste as conectividades. O que aconteceu?
Retrace e anote as rotas executando nos roteadores
```
 vtysh 2061
show ip route
```
e
```
 traceroute
```
a partir dos PCs.
1. São diferentes do caso original (todos enlaces ativos)? Por quê?
2. Quais os caminhos/rotas que foram reescritos? Por quê?
Abra o arquivo /home/aluno/r2/r2_OSPF.pcap.
- Perceba que com o protocolo OSPF, diferentemente do RIP, não há trocas periódicas de mensagens do protocolo de roteamento.
- Só haverá trocas quando o protocolo sentir necessidade de alguma mudança de rota, por exemplo, com a queda de um enlace.
Analisando a captura de dados
responda:
1. Quais as mensagens trocadas pelo protocolo OSPF são observadas no WireShark? Observe o trecho de mensagens onde não houve respostas ao ping.
2. Qual o tempo aproximado para a total recuperação das rotas? (Isso é observável pela diferença de tempos (timestamp) na sequência de mensagens observadas no Wireshark).
3. As mensagens trocadas pelos roteadores são distintas quando comparadas ao uso do RIP?
4. Houve diferença no tempo de atualização das rotas quando comparado ao RIP? Por quê?

Neighbor Discovery e roteamento estático no IPv6

Este roteiro foi baseado no material disponível no Livro - Laboratório de IPv6.

Slides de endereçamento IPv6.

Guia didático de endereçamento IPv6 obtido de http://ipv6.br/.

Objetivos do laboratório:

Um primeiro contato com o protocolo IPv6
Compreender o funcionando do Neighbor Discovery, o equivalente ao ARP (Address Resolution Protocol) do IPv4, que em resumo é uma tabela contendo a relação ente IPs e MACs.
Aprender configurações básicas de interfaces IPv6 no Linux
Aprender configurações básicas de rotas IPv6

Introdução teórica

Obs.: texto copiado literalmente de: Laboratório de IPv6.

A descoberta de vizinhança por meio do protocolo Neighbor Discovery no IPv6 é um procedimento realizado pelos nós de uma rede para descobrir endereços físicos dos dispositivos vizinhos presentes no mesmo enlace. A função deste protocolo se assemelha à função do ARP e do RARP no IPv4.

O procedimento é iniciado quando um dispositivo tenta enviar um pacote cujo endereço físico de destino é desconhecido. O nó solicitante envia uma mensagem Neighbor Solicitation (NS) para todos os nós do enlace pertencentes ao grupo multicast solicited-node (ff02::1:ffXX:XXXX), de modo que XX:XXXX são os últimos 24 bits do endereço IPv6 em que está interessado.
É possível notar que, por uma coincidência dos últimos 24 bits, é bastante provável que apenas o nó de destino faça realmente parte deste grupo. Isto é um truque interessante do IPv6 para diminuir o tráfego deste tipo de pacote na rede.
Na mensagem NS, o endereço IPv6 a ser resolvido é informado no campo Target. O campo Source link-layer address informa ao nó de destino o endereço MAC do nó de origem, poupando-o de ter que fazer o mesmo procedimento no sentido inverso.
O nó de destino, dono do IPv6 requisitado, ao receber este pacote, envia uma mensagem Neighbor Advertisement (NA) como resposta diretamente ao nó requisitante. O seu endereço físico será informado no campo Target link-layer address.
A informação de mapeamento entre endereços IP e endereços físicos é armazenada em uma tabela chamada neighbor cache. Nela também fica registrado o status de cada destino, informando se o mesmo é alcançável ou não.

Roteiro de atividades:

A figura abaixo apresenta o diagrama esquemático da rede a ser montada/analisada. Observe que todos os IPv6 Global Unicast já estão definidos na mesma, são esses IPs que utilizaremos em nosso experimento.

Crie em seu computador um arquivo com nome /home/aluno/IPv6.conf, com o seguinte conteúdo:

#Ligacao das maquinas nos dominios de colisao
#Duas pequenas redes interligadas pelo backbone
 
# Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
pc4[type]=generic
 
# Hosts' interfaces to local routers
pc1[eth0]=link0:ipv6=2001:bcc:faca:1::101/64
pc2[eth0]=link1:ipv6=2001:bcc:cafe:1::102/64
pc3[eth0]=HUB1:ipv6=2001:bcc:1f0:1::103/64
pc4[eth0]=HUB1
 
#Default Gateways definitions
pc1[route]=default6:gateway=2001:bcc:faca:1::1
pc2[route]=default6:gateway=2001:bcc:cafe:1::1
pc3[route]=default6:gateway=2001:bcc:1f0:1::1
 
# Routers definitions
r1[type]=gateway
r2[type]=gateway
 
#Routers interfaces definitions
r1[eth0]=backbone0:ipv6=2001:db8:dead:1::1/64
r1[eth1]=link0:ipv6=2001:bcc:faca:1::1/64
r1[eth2]=link1:ipv6=2001:bcc:cafe:1::1/64
 
r2[eth0]=backbone0:ipv6=2001:db8:dead:1::2/64
r2[eth1]=HUB1:ipv6=2001:bcc:1f0:1::1/64

Rode o NetKit em seu computador. Em um terminal digite:
```
netkit2 &
```
No menu File - Load and Run, procure o arquivo /home/aluno/IPv6.conf e clique em OK.
Ao clicar no menu File - Graph, pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.

Deixe capturando pacotes no r1 com o tcpdump:

tcpdump -i any -w /hostlab/r1/r1.pcap &

Vamos testar o Neighbor Discovery, anote a saída do comando. A partir do pc1 execute:
```
ndisc6 -m 2001:bcc:faca:1::1 eth0
```
- Esse comando descobre e retorna o MAC address da interface de rede que possui o endereço IPv6 informado.
Observe que todas as interfaces de rede já estão pré-configuradas, exceto do pc4.
Adapte o comando abaixo, que seria do pc1, para adicionar o endereço IPv6 à interface de rede no pc4:
```
ip addr add 2001:bcc:faca:1::101/64 dev eth0
```
Faça um ping6 entre o pc3 ao pc4.
- Se tudo estiver devidamente configurado, deve-se obter sucesso no ping entre o pc3 e pc4. Explique o por quê?
Faça um ping6 entre o pc1 ao pc4.
- Obteve sucesso? Sim ou não e por quê?
No pc4 use o seguinte comando para verificar como ficou a configuração dos endereços da interface de rede. O resultado é similar ao apresentado pelo comando ifconfig:
```
ip addr show dev eth0
```
No pc4, liste a tabela de roteamento com o comando:
```
ip -6 route show
```
No pc4, acrescente o default gateway com o seguinte comando:
```
ip -6 route add default via 2001:bcc:1f0:1::1 dev eth0
```
- Confira novamente a tabela de roteamento do pc4.
Faça novamente um ping6 entre o pc1 ao pc4.
- Obteve sucesso? Sim ou não e por quê?
No r1, adicione uma rota estática para a rede dos pc3 e pc4 através do seguinte comando:
```
ip -6 route add 2001:bcc:1f0:1::/64 via 2001:db8:dead:1::2 dev eth0
```
No r2, adicione uma rota estática para a rede dos pc1 e pc2 através dos seguintes comandos:
```
ip -6 route add 2001:bcc:faca:1::/64 via 2001:db8:dead:1::1 dev eth0
ip -6 route add 2001:bcc:cafe:1::/64 via 2001:db8:dead:1::1 dev eth0
```
- Pode-se conferir se as rotas foram corretamente configuradas com o comando:
```
ip -6 route show
```
Faça novamente o ping6 entre o pc1 ao pc4.
- Obteve sucesso? Sim ou não e por quê?

A partir do computador pc1 use os comandos e anote as rotas obtidas.

traceroute6 2001:bcc:1f0:1::103
traceroute6 2001:bcc:1f0:1::104

Use o comando abaixo para consultar a tabela de roteamento de cada um dos roteadores.
```
ip -6 route show
```
- São coerentes com os dados das rotas obtidas acima?
Pare o tcpdump em r1.
```
fg
<Ctrl c>
```
Abra o arquivo do tcpdump e explique o processo de descoberta de vizinhança (Neighbor Solicitation - NS e Neighbor Advertisement - NA), citando os endereços de multicast e link local utilizados.
- Alguns exemplos de campos visualizáveis para uma mensagem do tipo Neighbor Advertisement, presentes nas camadas destacadas:
1. Source (camada Ethernet)
  - A origem é o endereço MAC da interface do dispositivo que enviou a resposta.
2. Protocol (camada Ethernet)
  - Indica que a mensagem utiliza IPv6.
3. Next header (camada IPv6)
  - Indica qual é o próximo cabeçalho. Neste caso, o valor 58 (0x3a) refere-se a uma mensagem ICMPv6.
4. Source (camada IPv6)
  - A origem é o endereço IP da interface diretamente ligada ao enlace em que a requisição foi recebida.
5. Destination (camada IPv6)
6. Type (camada ICMPv6)
  - Indica que a mensagem é do tipo 136 (Neighbor Advertisement).
7. Flags (camada ICMPv6)
  - Uma mensagem NA possui três flags:
  1. Indica se quem está enviando é um roteador. Neste caso, o valor marcado é 0, pois não é um roteador.
  2. Indica se a mensagem é uma resposta a um NS. Neste caso, o valor marcado é 1, pois é uma resposta.
  3. Indica se a informação carregada na mensagem é uma atualização de endereço de algum nó da rede. Neste caso, o valor marcado é 1, pois está informando o endereço pela primeira vez.
8. Target Address (camada ICMPv6)
  - Indica o endereço IP associado às informações das flags. Neste caso, é o próprio endereço da interface do dispositivo em questão.
Numa mensagem do tipo Neighbor Solicitation qual é o endereço IPv6 de origem e destino? Explique/defina ambos.
Em todos os hosts rode o comando
```
 ip -6 neighbor show
```
1. Qual é a funcionalidade desse comando?
2. Qual é o significado do conteúdo dessa tabela?
3. A tabela mostrada em cada um dos casos é compatível com o diagrama da rede montado?
4. Por que, por exemplo, na tabela do pc3 não há uma referência explícita ao pc1?
Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6.

@@ Linha 1: / Linha 1: @@
+*<span style="font-size:130%"> Esta página é dedicada a descrição de roteiros de experimentos que tem por objetivo o fortalecimento de conceitos relacionados à disciplina de Redes de Computadores I da Engenharia de Telecomunicações do IFSC.
+*<span style="font-size:130%"> Cada roteiro é elaborado de tal modo que o estudante consiga realizar as atividades de maneira autônoma e propõe questões que forçam a reflexão sobre os conceitos abordados.
+*<span style="font-size:130%"> Caso deseje realizar em casa, uma boa opção e utilizar o VirtualBox e instalar uma máquina virtual pré-configurada com todo o ferramental necessário que pode se baixada [http://docente.ifsc.edu.br/odilson/RED29004/RED29004.ova aqui], usuário: aluno, senha: aluno2020.
+[[RED1-EngTel_(página) | <span style="font-size:200%"> Página principal da disciplina]]
 ==Ferramentas básicas: ''Ping'' e ''Traceroute''==
 ===Objetivos===
@@ Linha 5: / Linha 13: @@
 *Diagnosticar o atraso dos pacotes
 *Traçar rotas em redes  TCP/IP
-*Familiarização com o ''sniffer'' de rede WireShark
 ===Conceitos introdutórios para uso do laboratório===
@@ Linha 11: / Linha 18: @@
 [[Arquivo:Diagrama_rede_IFSC_lab_redes_I.jpeg |thumb | 400px| Figura 1 - Diagrama da rede do laboratório]]
-====Máquinas virtuais====
-Eventualmente serão utilizadas nessa disciplina.
-Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.1.0/24. A máscara de rede '''/24''' indica que o último ''byte'' do endereço é utilizado para identificar cada máquina, por exemplo  192.168.1.1, 192.168.1.2, etc.
-O sistema operacional hospedeiro é o '''Linux Ubuntu'''. Como os laboratórios são utilizados por várias disciplinas/alunos/professores, os usuários não tem acesso a senha de ''root'' (administrador).
-Para possibilitar a execução de comandos exclusivos do administrador (usuário root), cada computador tem instaladas máquinas virtuais, as quais podem ser lançadas a partir do aplicativo '''VirtualBox'''. As máquinas virtuais pertencem a mesma rede local do laboratório e tem endereçamento  192.168.1.x, sendo o ''byte'' que identifica a máquina (x) deverá ser manualmente configurado com a seguinte regra: M1 – 101, M2 – 102,..., M9 – 109, M10 – 110,..., M14 – 114 . Por exemplo:, M1 ficará com o endereço 192.168.1.101.
 ===Roteiro de atividades===
@@ Linha 26: / Linha 26: @@
-#Analisando os dados obtidos do seguinte exemplo <code>ifconfig
+#Analisando os dados obtidos do seguinte exemplo<syntaxhighlight lang=bash>
-eth0      Link encap:Ethernet  Endereço de HW 64:51:06:1a:f3:da
+ifconfig
-          inet end.: 172.18.18.14  Bcast:172.18.63.255  Masc:255.255.192.0
+  enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
-          endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link
+        inet 191.36.9.46  netmask 255.255.255.0  broadcast 191.36.9.255
-          UP BROADCAST RUNNING MULTICAST  MTU:1500  Métrica:1
+        inet6 2804:1454:1004:200:a85a:5102:2b69:f30e  prefixlen 64  scopeid 0x0<global>
-          pacotes RX:415237 erros:0 descartados:0 excesso:0 quadro:0
+        inet6 fe80::fe96:6859:7e7b:5a53  prefixlen 64  scopeid 0x20<link>
-          Pacotes TX:118109 erros:0 descartados:0 excesso:0 portadora:0
+        inet6 2804:1454:1004:200:77e5:2fd9:4bf6:6544  prefixlen 64  scopeid 0x0<global>
-          colisões:0 txqueuelen:1000
+        ether f0:4d:a2:e4:1b:05  txqueuelen 1000  (Ethernet)
-          RX bytes:364658695 (364.6 MB) TX bytes:18315199 (18.3 MB)
+        RX packets 124632  bytes 136030754 (136.0 MB)
-          IRQ:18
+        RX errors 0  dropped 0  overruns 0  frame 0
+        TX packets 38103  bytes 7323375 (7.3 MB)
+        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
+        device interrupt 21  memory 0xf7fe0000-f8000000
-lo        Link encap:Loopback Local
+ lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
-          inet end.: 127.0.0.1  Masc:255.0.0.0
+        inet 127.0.0.1  netmask 255.0.0.0
-          endereço inet6: ::1/128 Escopo:Máquina
+        inet6 ::1  prefixlen 128  scopeid 0x10<host>
-          UP LOOPBACK RUNNING  MTU:65536  Métrica:1
+        loop  txqueuelen 1000  (Loopback Local)
-          pacotes RX:6688 erros:0 descartados:0 excesso:0 quadro:0
+        RX packets 3921  bytes 385075 (385.0 KB)
-          Pacotes TX:6688 erros:0 descartados:0 excesso:0 portadora:0
+        RX errors 0  dropped 0  overruns 0  frame 0
-          colisões:0 txqueuelen:0
+        TX packets 3921  bytes 385075 (385.0 KB)
-          RX bytes:1057934 (1.0 MB) TX bytes:1057934 (1.0 MB) </syntaxhighlight>
+        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 </syntaxhighlight>
-##O sistema em questão possui duas interfaces de rede: '''eth0''' e '''lo'''
+#Conclui-se que:
-##'''Link encap:Ethernet''': Configuração da interface '''Eth'''ernet 0 (primeira)
+##O sistema em questão possui duas interfaces de rede: '''enp0s25''' e '''lo'''
-##'''Endereço de HW 64:51:06:1a:f3:da''': É o endereço da placa de rede, camada 2
+##'''enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500''': A interface está ativa (UP), está com as características BROADCAST,RUNNING,MULTICAST ativas e possui um MTU (''Maximum Transmission Unit'') de 1500 bytes
-##'''inet end.: 172.18.18.14  Bcast:172.18.63.255  Masc:255.255.192.0''': Endereço IPv4 associado a interface, seu respectivo endereço de ''broadcast'' e mascara de rede
+##'''inet 191.36.9.46  netmask 255.255.255.0  broadcast 191.36.9.255''': Endereço IPv4 associado a interface, sua máscara de rede e seu respectivo endereço de ''broadcast''
-##endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link: Endereço IPv6 de escopo local gerado por autoconfiguração
+##'''inet6 2804:1454:1004:200:a85a:5102:2b69:f30e  prefixlen 64  scopeid 0x0<global> ''': Endereço IPv6 associado a interface, sua máscara de redes e escopo global (roteável)
-##'''UP BROADCAST RUNNING MULTICAST''': Significa que a interface está ativa (UP), responde a requisições de broadcast (pode ser desabilitado no kernel) e também pode ser associada a tráfegos ''multicast''
+##'''inet6 fe80::fe96:6859:7e7b:5a53  prefixlen 64  scopeid 0x20<link> ''': Endereço IPv6 associado a interface, sua máscara de redes e escopo local (não roteável)
-##'''MTU: 1500''': ''Maximum Transfer Unit'' – Tamanho máximo do pacote suportado pelo enlace que é do tipo Ethernet
+##'''inet6 2804:1454:1004:200:77e5:2fd9:4bf6:6544  prefixlen 64  scopeid 0x0<global> ''': Endereço IPv6 associado a interface, sua máscara de redes e escopo global (roteável)
-##Os demais parâmetros são estatísticas da respectiva interface, como por exemplo, pacotes transmitidos, recebidos etc
+##'''ether f0:4d:a2:e4:1b:05  txqueuelen 1000  (Ethernet)''': Endereço Ethernet (''Hardware Address''). Ethernet é o padrão da camada 2, nesse caso
+##'''RX packets 124632  bytes 136030754 (136.0 MB)''': Quantidade de bytes recebidos, desde o último ''boot''
+##'''RX errors 0  dropped 0  overruns 0  frame 0''': Quantidade de bytes recebidos com erro, desde o último ''boot''
+##'''TX packets 38103  bytes 7323375 (7.3 MB)''': Quantidade de bytes transmitidos, desde o último ''boot''
+##'''TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0''': Quantidade de bytes transmitidos com erro, desde o último ''boot''
+##'''device interrupt 21  memory 0xf7fe0000-f8000000''': Parâmetros do sistema operacional
 ##A interface '''lo''': Qualquer tráfego que um computador envie em uma rede ''loopback'' é endereçada ao mesmo computador. O endereço IP mais usado para tal finalidade é 127.0.0.1 no IPv4 e ::1 no IPv6. O nome de domínio padrão para tal endereço é ''localhost''. Em sistemas Unix, a interface loopback é geralmente chamada de lo ou lo0.
-#Agora utilize o comando '''ifconfig''' para verificar o estado de suas interfaces e responda:
+#Agora utilize o comando '''sudo ifconfig''' para verificar o estado de suas interfaces e responda:<span style="color: #9966CC;">
 ##Quantas e quais interfaces de rede sua máquina possui? Liste.
+##Qual o significado/utilidade da interface '''lo'''?
 ##Quais são os endereços da camada 2 atribuído as mesmas? De onde o sistema obteve esses endereços?
 ##Quais são os endereços IPv4? De onde o sistema obteve esses endereços?
-##Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo?
+##Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo? </span>
 ====ping====
@@ Linha 68: / Linha 77: @@
 Consultar as páginas ''man'' do ping para verificar as possibilidades de uso deste aplicativo.
-#Exemplo 1: <code>
+# Exemplo 1: <syntaxhighlight lang=bash>
 PING 200.135.37.65 (200.135.37.65) 56(84) bytes of data.
 bytes from 200.135.37.65: icmp_seq=1 ttl=62 time=0.925 ms
@@ Linha 74: / Linha 83: @@
 bytes from 200.135.37.65: icmp_seq=3 ttl=62 time=0.687 ms
 bytes from 200.135.37.65: icmp_seq=4 ttl=62 time=0.689 ms
-^C
---- 200.135.37.65 ping statistics ---
 packets transmitted, 4 received, 0% packet loss, time 2999ms
-rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms </syntaxhighlight>
-##No exemplo foram enviados quatro pacotes ICMP, cada um com um número de seqüência (''icmp_seq''), os quais foram recebidos com sucesso com o tempo de viagem assinalado (''time'')
+rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms</syntaxhighlight>
-##Cada pacote tem ainda um tempo de vida (''ttl'' – ''time to live''), o qual é decrementado em cada roteador, sendo o pacote descartado quando chegar a zero; isto evita pacotes perdidos na rede
+* No exemplo foram enviados quatro pacotes ICMP, cada um com um número de seqüência (''icmp_seq''), os quais foram recebidos com sucesso com o tempo de viagem assinalado (''time'').
-##Quando o ping é interrompido ('''CRTL-C'''), uma estatística é apresentada indicando o percentual de pacotes transmitidos, recebidos e perdidos
+* Cada pacote tem ainda um tempo de vida (''ttl – time to live''), o qual é decrementado em cada roteador, sendo o pacote descartado quando chegar a zero. Isto evita pacotes perdidos na rede.
-##O tempo de viagem (''rtt'' – ''round trip time'') mínimo (''min''), médio (''avg'') e máximo (''max'') é calculado, assim como o desvio padrão (''mdev'')
+* Quando o ping é interrompido (CRTL-C), uma estatística é apresentada indicando o percentual de pacotes transmitidos, recebidos e perdidos.
-#Como exercício envie '''ping''' para diferentes ''hosts'' e compare os tempos de resposta:
+* O tempo de viagem (''rtt – round trip time'') mínimo (''min''), médio (''avg'') e máximo (''max'') é calculado, assim como o desvio padrão (''mdev'')
-##no endereço local de loopback;
+Exercício:</span>
-##máquina de um colega do laboratório;
+# <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">Envie '''ping''' para diferentes ''hosts'' e compare os tempos de resposta:</span>
-##servidor e roteador da rede da escola;
+## <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">No endereço local de ''loopback'';</span>
-##servidores externos: <code>
+## <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">Na máquina de um colega do laboratório;</span>
-www.ifsc.edu.br
+## <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">servidor e roteador da rede da escola;</span>
-www.uol.com.br
+## <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">servidores externos:</span>
-www.nasa.com
+### <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">www.ifsc.edu.br</span>
-www.polito.it </syntaxhighlight>
+### <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">www.uol.com.br</span>
-#Explique as diferenças entre os tempos de resposta dos ping realizados:
+### <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">www.aaa.jp</span>
-##Entre ping para diferentes destinos.
+## <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">Explique as diferenças entre os tempos de resposta dos '''ping''' realizados:</span>
-##Entre respostas recebidas de um mesmo destino.
+### <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">Entre ping para diferentes destinos.</span>
-#Consulte as páginas ''man'' e teste o '''ping''' com os parâmetros abaixo e descreva suas funcionalidades:
+### <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">Entre respostas recebidas de um mesmo destino.</span>
-##-c count
+## <span style="background-color: rgb(248, 249, 250); font-family: monospace, monospace; color: rgb(204, 153, 255);" data-mce-style="background-color: #f8f9fa; font-family: monospace, monospace; color: #cc99ff;">Consulte as páginas '''man''' e teste o ping com os parâmetros abaixo e descreva suas funcionalidades:<br  />-c count<br  />-i intervalo<br  />-s packetsize<br  />-t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens). Com essa estratégia é possível mapear os roteadores no caminho entre a origem e o destino de um pacote.</span>im como o desvio padrão (''mdev'')
-##-i intervalo
-##-s packetsize
-##-t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens)
-##-b (Se desejarmos descobrir o endereço IP de vários ''hosts'' em uma rede local, poderemos utilizar o '''ping''' no endereço de ''broadcast'')
-#*No Ubuntu a resposta a um  ping no endereço de broadcast é desabilitada por padrão e somente o administrador pode habilitar esta funcionalidade. Quem desejar testar esse tipo de ping deverá utilizar uma máquina virtual qualquer (VirtualBox) e habilitar a  resposta a um  '''ping''' no endereço de ''broadcast''. Para tal, primeiro iniciamos uma máquina virtual, logamos como aluno/aluno e depois executamos em um terminal os comandos abaixo<code>
-sudo su
-echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts </syntaxhighlight> em seguida esta máquina responderá a '''ping''' no ''broadcast''.
-##Execute um ping ''broadcast'' e explique porque aparece o termo ''(DUP!)'' após cada resposta. Dica: observe o número de sequência.
 ====traceroute====
@@ Linha 110: / Linha 110: @@
 O '''traceroute''' envia datagramas IP encapsulados em segmentos UDP a um host destino. Todavia escolhe um número de porta destino com um valor desconhecido (maior que 30000), tornando improvável que o host destino esteja usando esta porta. Quando o datagrama chega ao destino uma mensagem ICMP porta inalcançável é gerada e enviada a origem. O programa traceroute precisa saber diferenciar as mensagens ICMP recebidas – tempo excedido e porta inalcançável – para saber quando a rota foi concluída.
-#Exemplo: <code>
+* Exemplo:<syntaxhighlight lang=bash>
-traceroute 200.135.37.65
+ sudo traceroute -I 191.36.8.3
-traceroute to 200.135.37.65 (200.135.37.65), 30 hops max, 60 byte packets
-  192.168.1.1 (192.168.1.1)  0.225 ms  0.216 ms  0.368 ms
+ traceroute to 191.36.8.3 (191.36.8.3), 30 hops max, 60 byte packets
-  172.18.0.254 (172.18.0.254)  1.236 ms  1.235 ms  1.343 ms
+  _gateway (191.36.9.254)  1.444 ms  1.709 ms  2.097 ms
-  hendrix.sj.ifsc.edu.br (200.135.37.65)  1.331 ms  1.313 ms  1.414 ms </syntaxhighlight> O exemplo mostra a rota dos pacotes entre um computador do Lab. Redes (192.168.2.1) e o servidor ''hendrix'' (200.135.37.65). Observe que para cada roteador são realizados três amostras de tempo de ida e volta. Veja pelo mapa da rede do Campus São José que entre estes dois computadores, sistemas finais, existem dois roteadores intermediários, máquina do professor e Switch camada 3 (VLANs).
+  172.18.255.251 (172.18.255.251)  0.138 ms  0.151 ms  0.152 ms
-#Traçar a rota dos pacotes entre seu computador e diferentes hosts:
+  191.36.8.3 (191.36.8.3)  1.544 ms  1.551 ms  1.550 ms </syntaxhighlight>
-##máquina de um colega do laboratório
-##servidor e roteador da rede da escola
+NOTA: O comando '''traceroute''' acima foi executado com o parâmetro -I. Esse comando força o '''traceroute''' a utilizar mensagens ICMP. Outra opção é utilizar o comando com o parâmetro -T, forçando o '''traceroute''' a utilizar o protocolo TCP para transmissão de seus pacotes. Caso nenhum dos parâmetros (-I ou -T) seja utilizado o '''traceroute''' utiliza o protocolo UDP como padrão. Visando barrar
-##servidores externos.
+o tráfego de torrent na rede do Câmpus, o Firewall bloqueia as mensagens UDP da rede. Deste modo não é possível executar o comando traceroute na rede do Campus sem o uso dos parâmetro (-I ou -T).
-#Explique as diferenças entre os tempos de resposta:
-##Entre traceroutes para diferentes destinos.
-##Entre as três medidas apresentadas para cada salto.
-##O que justifica um possível tempo de resposta menor para um salto posterior? Por exemplo: pode-se obter no salto 13 um tempo de 289.207 ms e no salto 14 um tempo de 277.115 ms.
-#Explique as linhas com o caracter *.
-==Ferramentas básicas: WireShark ==
+O exemplo mostra a rota dos pacotes entre um computador do Lab. Redes (191.36.8.3) e o servidor ''www'' do campus (191.36.8.3). Observe que para cada roteador são realizados três amostras de tempo de ida e volta. Veja pelo mapa da rede do Campus São José que entre estes dois computadores, sistemas finais, existem dois roteadores intermediários, máquina do professor e Switch camada 3 (VLANs).
+* Outro exemplo:<syntaxhighlight lang=bash>
+ sudo traceroute -I www.polito.it
+ traceroute to www.polito.it (130.192.181.193), 30 hops max, 60 byte packets
+  _gateway (191.36.9.254)  1.326 ms  1.410 ms  1.620 ms
+  172.18.255.251 (172.18.255.251)  0.172 ms  0.183 ms  0.184 ms
+  sw5-pop-wireless-backup-radio.remep.pop-sc.rnp.br (200.237.201.153)  2.574 ms  2.885 ms  3.114 ms
+  * * *
+  popsc-rt21-2189.pop-sc.rnp.br (200.237.202.49)  1.743 ms  1.890 ms  1.882 ms
+  sc-lansc-rt21.bkb.rnp.br (200.143.253.109)  0.698 ms  0.681 ms  0.680 ms
+  200.143.255.140 (200.143.255.140)  11.554 ms  11.640 ms  11.607 ms
+  br-rnp.redclara.net (200.0.204.213)  12.710 ms  12.509 ms  12.217 ms
+  us-br.redclara.net (200.0.204.9)  128.588 ms  128.600 ms  128.723 ms
+  redclara-gw.par.fr.geant.net (62.40.125.168)  224.711 ms  224.812 ms  224.744 ms
+  ae5.mx1.gen.ch.geant.net (62.40.98.182)  232.127 ms  232.146 ms  232.059 ms
+  ae6.mx1.mil2.it.geant.net (62.40.98.81)  238.833 ms  238.855 ms  238.820 ms
+  garr-gw.mx1.mil2.it.geant.net (62.40.125.181)  237.648 ms  238.871 ms  238.870 ms
+  rx1-mi2-rx1-to1.to1.garr.net (90.147.80.218)  240.543 ms  240.734 ms  240.797 ms
+  rx1-to1-ru-polito.to1.garr.net (193.206.132.34)  242.406 ms  242.406 ms  242.771 ms
+</syntaxhighlight>
+*Exercício:
+# <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">Traçar a rota dos pacotes entre seu computador e diferentes ''hosts'':</span>
+## <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">máquina de um colega do laboratório.</span>
+## <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">servidor e roteador da rede da escola.</span>
+## <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">servidores americanos.</span>
+# <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">Explique as diferenças entre os tempos de resposta:</span>
+## <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">Entre '''traceroutes''' para diferentes destinos.</span>
+## <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">No caso do '''traceroute''' para os EUA, aponte claramente qual foi o salto onde ocorreu a travessia do oceano. Como você chegou a essa conclusão?</span>
+## <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">Entre as três medidas apresentadas para cada salto.</span>
+# <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">O que justifica um possível tempo de resposta menor para um salto posterior? Por exemplo: pode-se obter no salto 12 um tempo de '''238.833 ms''' e no salto 13 um tempo de '''237.648 ms'''.</span>
+# <span style="color: rgb(204, 153, 255);" data-mce-style="color: #cc99ff;">Explique as linhas com o caracter *.</span>
+==Ferramentas básicas: WireShark e tcpdump ==
 KUROSE, J.F & ROSS, K. W. Todos os direitos reservados
+===Objetivos===
+*Conhecer aplicativos para verificar os parâmetros do TCP/IP
+*Familiarização com os ''sniffers'' de rede WireShark e tcpdump.
 ===Introdução===
@@ Linha 135: / Linha 169: @@
 A ferramenta básica para observar as mensagens trocadas entre as entidades em execução é chamada de ''sniffer''. Como o nome sugere, um ''sniffer'' captura mensagens sendo enviadas/recebidas pelo seu computador; ele também tipicamente armazena e/ou apresenta os conteúdos dos vários campos dos protocolos nestas mensagens capturadas. Um ''sniffer'' isoladamente é um elemento passivo. Ele observa as mensagens sendo enviadas e recebidas pelas aplicações e protocolos executando no seu computador, mas jamais envia pacotes. Similarmente, os pacotes recebidos nunca são explicitamente endereçados ao ''sniffer''. Ao invés disso, um ''sniffer'' recebe uma cópia de pacotes que são enviados/recebidos para/de aplicações e protocolos executando no seu computador.
-A Figura 1 mostra a estrutura de um ''sniffer''. À direita da Figura 2 estão os protocolos (neste caso, protocolos da Internet) e aplicações (tais como navegador web ou cliente FTP) que normalmente executam no seu computador. O ''sniffer'', exibido dentro do retângulo tracejado na Figura 2 é uma adição aos softwares usuais no seu computador, e consiste de duas partes: a biblioteca de captura de pacotes e o analisador de pacotes. A biblioteca de captura de pacotes recebe uma cópia de cada quadro da camada de enlace que é enviado do ou recebido pelo seu computador. Lembre que mensagens trocadas por protocolos das camadas mais altas tais como HTTP, FTP, TCP, UDP, DNS ou IP, são todos eventualmente encapsulados em quadros que são transmitidos para o meio físico como um cabo Ethernet. Na Figura 2, assume-se que o meio físico é uma Ethernet, e desta forma, os protocolos das camadas superiores são eventualmente encapsulados em um quadro Ethernet. Capturar todos os quadros fornece todas as mensagens enviadas/recebidas de/por todos os protocolos e aplicações executando em seu computador.
+A Figura 1 mostra a estrutura de um ''sniffer''. À direita da Figura 1 estão os protocolos (neste caso, protocolos da Internet) e aplicações (tais como navegador web ou cliente FTP) que normalmente executam no seu computador. O ''sniffer'', exibido dentro do retângulo tracejado na Figura 1 é uma adição aos softwares usuais no seu computador, e consiste de duas partes: a biblioteca de captura de pacotes e o analisador de pacotes. A biblioteca de captura de pacotes recebe uma cópia de cada quadro da camada de enlace que é enviado do ou recebido pelo seu computador. Lembre que mensagens trocadas por protocolos das camadas mais altas tais como HTTP, FTP, TCP, UDP, DNS ou IP, são todos eventualmente encapsulados em quadros que são transmitidos para o meio físico como um cabo Ethernet. Na Figura 1, assume-se que o meio físico é uma Ethernet, e desta forma, os protocolos das camadas superiores são eventualmente encapsulados em um quadro Ethernet. Capturar todos os quadros fornece todas as mensagens enviadas/recebidas de/por todos os protocolos e aplicações executando em seu computador.
-[[Arquivo:Sniffer_estrutura.png |thumb | 500px| Figura 1 - Estrutura de um ''sniffer'']]
+[[Arquivo:Sniffer_estrutura.png |thumb | 400px| Figura 1 - Estrutura de um <em>sniffer</em>]]
 O analisador de pacotes exibe os conteúdos de todos os campos dentro de uma mensagem de protocolo. Para que isso seja feito, o analisador de pacotes deve “entender” a estrutura de todas as mensagens trocadas pelos protocolos. Por exemplo, suponha que estamos interessados em mostrar os vários campos nas mensagens trocadas pelo protocolo HTTP na Figura 5. O analisador de pacotes entende o formato dos quadros Ethernet, e desta forma pode identificar o datagrama IP dentro de um quadro. Ele também entende o formato do datagrama IP, para que ele possa extrair o segmento TCP dentro do datagrama IP. Ele entende a estrutura do segmento TCP, para que possa extrair a mensagem HTTP contida no segmento. Finalmente, ele entende o protocolo HTTP e então, por exemplo, sabe que os primeiros bytes de uma mensagem HTTP contém a cadeia “GET”, “POST” ou “HEAD”. Nós utilizaremos o ''sniffer'' Wireshark (http://www.wireshark.org) para estes laboratórios, o que nos permite exibir os conteúdos das mensagens sendo enviadas/recebidas de/por protocolos em diferentes camadas da pilha de protocolos. Tecnicamente falando, Wireshark é um analisador de pacotes que pode ser executado em computadores com Windows, Linux/UNIX e MAC.
 É um analisador de pacotes ideal para nossos laboratórios, pois é estável, tem uma grande base de usuários e é bem documentado incluindo um guia de usuário (http://www.wireshark.org/docs/wsug_html/), páginas de manual (http://www.wireshark.org/docs/man-pages/), e uma seção de FAQ detalhada (http://www.wireshark.org/faq.html), funcionalidade rica que inclui a capacidade de analisar mais que 500 protocolos, e uma interface com o usuário bem projetada. Ele funciona em computadores ligados a uma Ethernet para conectar-se à Internet, bem como protocolos ponto a ponto, tal como PPP.
-*Analisando os campos da interface do Wireshark
+* Analisando os campos da interface do Wireshark
 Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura 3 aparecerá. Inicialmente, nenhum dado será apresentado nas janelas. A interface do Wireshark tem seis componentes principais:
-#Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus ''File'' e ''Capture''. O menu ''File'' permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu ''Capture'' permite iniciar uma captura de pacotes;
+# Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus ''File'' e ''Capture''. O menu ''File'' permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu ''Capture'' permite iniciar uma captura de pacotes;
-#A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes;
+# A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes;
-#Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos;
+# Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos;
-#A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote;
+# A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote;
-#A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados;
+# A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados;
-#A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal.
+# A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal.
-[[Arquivo:Wireshark_interface_usuario.png |thumb | 700px| Figura 3 - Interface com o usuário do Wireshark]]
+[[Arquivo:Wireshark_interface_usuario.png |thumb | 500px| Figura 3 - Interface com o usuário do Wireshark]]
-===Roteiro de atividades ===
+===Roteiro de atividades===
-#Inicie o navegador web;
-#Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso;
+# Inicie o navegador web;
-#Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces.
+# Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso;
-#Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4); [[Arquivo:Wireshark_interfaces_rede.png |thumb | 400px| Figura 4 - Interfaces de rede no Wireshark]]
+# Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces.
-#Basta clicar no botão ''Start'' da interface desejada para iniciar a captura de pacotes. Na Figura 4, como o Wireshark está sendo executado no Linux, o botão Start da interface eth0 deve ser selecionado;
+# Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4); [[Arquivo:Wireshark_interfaces_rede.png |thumb | 300px| Figura 4 - Interfaces de rede no Wireshark]]
-#Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio;
+# Basta clicar no botão ''Start'' da interface desejada para iniciar a captura de pacotes. Na Figura 4, como o Wireshark está sendo executado no Linux, o botão Start da interface eth0 deve ser selecionado;
-#No navegador, acesse o site http://www.ifsc.edu.br;
+# Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio;
-#Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos na conexão;
+# No navegador, acesse o site http://www.ifsc.edu.br;
-#Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em ''Capture'' e depois em ''Stop'';
+# Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos na conexão;
-#Para testar as capacidades de filtragem, vamos inserir a cadeia “http” (sem as aspas e em minúsculo) no especificação do filtro de exibição e depois selecionar ''Apply'' (ou Aplicar). Um resultado similar é exibido na figura 5; [[Arquivo:Wireshark_filtro_HTTP.png |thumb | 600px| Figura 5 - Janela após a aplicação do filtro http]]
+# Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em ''Capture'' e depois em ''Stop'';
-#Selecione a primeira mensagem HTTP exibida na janela de listagem de pacotes. Ela deve ser a mensagem HTTP GET que foi enviada do seu computador ao servidor HTTP em www.ifsc.edu.br. Quando você seleciona a mensagem HTTP GET, as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do segmento TCP e da mensagem HTTP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles.
+# Para testar as capacidades de filtragem, vamos inserir a cadeia “http” (sem as aspas e em minúsculo) na especificação do filtro de exibição e depois selecionar ''Apply'' (ou Aplicar). Um resultado similar é exibido na figura 5; [[Arquivo:Wireshark_filtro_HTTP.png |thumb | 400px| Figura 5 - Janela após a aplicação do filtro http]]
-#Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre;
+# Selecione a primeira mensagem HTTP exibida na janela de listagem de pacotes. Ela deve ser a mensagem HTTP GET que foi enviada do seu computador ao servidor HTTP em www.ifsc.edu.br. Quando você seleciona a mensagem HTTP GET, as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do segmento TCP e da mensagem HTTP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles.
-#Saia do Wireshark.
+# Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre;
-#Com Wireshark ativo (Abra-o novamente) acesse um sítio e responda às seguintes questões:
+# <span style="color: #9966CC;">Com Wireshark ativo (Abra-o novamente se necessário) acesse um sítio de sua preferência e responda às seguintes questões:
-##Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado ''host'' ('''ip.addr == 192.168...'''). Anote o filtro utilizado e salve a janela do mesmo.
+## Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado ''host'' ('''ip.addr == 191....'''). Anote o filtro utilizado e salve a janela do mesmo. [https://mundotecnologico.net/2011/11/25/criando-filtros-no-wireshark/ Exemplo de filtros].
-##Elimine o filtro e anote os diferentes protocolos que aparecem na coluna ''Protocol'' na janela de listagem de pacotes;
+## Elimine o filtro e anote os diferentes protocolos que aparecem na coluna ''Protocol'' na janela de listagem de pacotes;
-##Quanto tempo passa entre o envio de uma mensagem HTTP GET até o recebimento de uma resposta OK? (por padrão, o valor da coluna Time na janela de listagem de pacotes é a quantidade de tempo, em segundos, desde que a captura iniciou). Para exibir o campo Time no formato hora do dia, selecione o menu ''View'', depois ''Time Display Format'', então selecione ''Time of day''.
+## Quanto tempo passa entre o envio de uma mensagem HTTP GET até o recebimento de uma resposta OK? (por padrão, o valor da coluna Time na janela de listagem de pacotes é a quantidade de tempo, em segundos, desde que a captura iniciou). Para exibir o campo Time no formato hora do dia, selecione o menu ''View'', depois ''Time Display Format'', então selecione ''Time of day''.
-##Qual é o endereço IP do sítio navegado? Qual é o endereço IP da interface de rede do seu computador? Qual o endereço MAC de sua máquina?
+## Qual é o endereço IP do sítio navegado? Qual é o endereço IP da interface de rede do seu computador? Qual o endereço MAC de sua máquina?</span>
+===Tcpdump===
+#Leia atentamente  o manual do tcpdump , principalmente os exemplos: <syntaxhighlight lang=bash> man tcpdump </syntaxhighlight>
+#<span style="color: #9966CC;">Faça um ping e navegue para algum site de sua preferência e, com o uso de parâmetros apropriados, faça com que o tcpdump armazene os em um arquivo denominado “pacotes_capturados'''X'''.pcap“ (um arquivo para cada item '''X'''):
+##Capture todos os pacotes oriundos e destinados à sua máquina.
+##Idem anterior com a ''flag'' ''-vvv'' ativa e, em seguida, a ''flag'' -n.
+##*Qual é a função dessas ''flags''?
+##Capture somente os pacotes oriundos de sua máquina.
+##*Anote o comando utilizado.
+##Capture somente pacotes destinados à sua máquina.
+##*Anote o comando utilizado.
+##Capture pacotes HTTP e DNS (lembre-se da porta de cada serviço).
+##*Anote o comando utilizado.
+#<span style="color: #9966CC;">Procure um dos arquivos salvos, com o navegador de arquivos de sua máquina, dê um duplo clique sobre o mesmo.
+##Com qual programa foi aberto o arquivo?
+##Exemplifique um possível uso dessa compatibilidade de arquivos?
 ==Conceituando protocolos==
 ===Objetivos===
-*Conceber um protocolo/serviço de calculadora pela rede
+*Desenvolver o conceito de protocolo.
 *Entender o conceito de clientes e servidores de serviço.
+*Conceber um protocolo/serviço de calculadora pela rede.
+===Requisitos de um protocolo de camada de aplicação===
+#Os tipos de mensagens trocadas.
+#A sintaxe dos vários tipos de mensagens, tais como os campos da mensagem e como os campos são delineados.
+#A semântica dos campos, isto é, o significado da informação nos campos.
+#Regras para determinar quando e como um processo envia mensagens e responde a mensagens.
-===Protocolo de rede===
+===Definição do protocolo a ser criado===
-*Protocolo é o conjunto de regras sobre o modo como se dará a comunicação entre as partes envolvidas. Protocolo é a "língua" dos computadores, ou seja, uma espécie de idioma que segue normas e padrões determinados. É através dos protocolos que é possível a comunicação entre um ou mais computadores.
+#Vamos criar uma calculadora em rede através de um protocolo bem simples, utilizando como ferramenta de comunicação o ping e o Wireshark.
+[[Arquivo:AppRCO.png | 500px | Estrutura Applicação'']]
+##O protocolo tem por objetivo dar suporte a uma calculadora em rede.
+##Um aluno cria uma mensagem e envia, sem aviso prévio, a um colega. Este será o cliente da arquitetura cliente-servidor.
+##O colega, ao receber a mensagem, deverá interpretá-la, elaborar uma resposta à pergunta e retorná-la ao colega. Este será o servidor da arquitetura cliente-servidor.
+##A estrutura básica de um pacote que flui do cliente para o servidor e vice-versa é apresentada na figura abaixo. Essa estrutura deverá ser absolutamente respeitada, caso contrário, o servidor poderá não conseguir interpretá-la e descartará a mensagem.
+[[Arquivo:Exemplo_protocolo.svg | 400px | Estrutura do Pacote'']]
+*Onde '''Dst''' e '''Src''' são utilizados para identificar o nome do emissor e destinatário: as iniciais dos nomes.
+*O campo dados conterá a pergunta ou a reposta.
+===Roteiro===
-===Atividades===
+# Desative todas as atividades de rede de seu computador.
-#Desative todas as atividades de rede de seu computador.
+# Abra o wireshark e deixe capturando mensagens com o filtro '''icmp''' ativo.
-#Abra o wireshark e deixe capturando mensagens com o filtro '''icmp''' ativo.
+# Cada estudante vai construir uma mensagem, respeitando o formato estabelecido, de solicitação (lado cliente). Essa mensagem deverá conter uma questão matemática, por exemplo: 2+2.
-#A estrutura básica de um pacote que flui do cliente para o servidor e vice-versa é: [[Arquivo:Exemplo_protocolo.svg | 400px | Estrutura do Pacote'']]
+## Para construir a mensagem utilize o código ASCII: [http://iris.sel.eesc.usp.br/sel433a/ASCII.pdf Tabela ASCII] ou [https://pt.wikipedia.org/wiki/ASCII Tabela ASCII]
-##'''Dst''' e '''Src''' são utilizados para identificar o nome do emissor e destinatário: as iniciais dos nomes.
+# <span style="color: #9966CC;">Envie essa mensagem a um ou vários colegas, sem aviso prévio, através do comando '''ping''' com a ''flag'' ''pattern''. Ex: <syntaxhighlight lang=bash> ping -p FF0200416C6C4F6469362D3103FF 192.168.1.1 </syntaxhighlight>
-#Cada estudante vai construir uma mensagem, respeitando o formato estabelecido, de solicitação (lado cliente). Essa mensagem deverá conter uma questão matemática, por exemplo: 2+2. Para construir a mensagem utilize o código ASCII: [http://www.theasciicode.com.ar/ Tabela ASCII]
+#* No relatório deverá estar contido a mensagem (Hexa) e sua interpretação.</span>
-#Envie essa mensagem através do comando '''ping''' com a ''flag'' ''pattern''. Ex: <code> ping -p FF0200416C6C4F6469362D3103FF 192.168.1.1 </syntaxhighlight>
+# <span style="color: #9966CC;">Ao receber uma mensagem no wireshark, interprete-a, ([http://www.rapidtables.com/convert/number/hex-to-ascii.htm Ferramenta para conversão ASCII ==> Hexadecimal]) verificando quem é o emitente e realizando a operação aritmética solicitada.
-#Ao receber uma mensagem no wireshark, interprete-a, ([http://www.rapidtables.com/convert/number/hex-to-ascii.htm Ferramenta para conversão ASCII ==> Hexadecimal]) verificando quem é o emitente e realizando a operação aritmética solicita. Monte uma resposta e utilize o comando '''ping''' para responder ao emitente.
+#* No relatório deverá estar contido a mensagem (Hexa) e sua interpretação.</span>
+# <span style="color: #9966CC;">Monte uma resposta e utilize o comando '''ping''' para responder ao emitente.
+#* No relatório deverá estar contido a mensagem (Hexa) e sua interpretação.</span>
 ==Desvendando o HTTP com Wireshark==
@@ Linha 196: / Linha 267: @@
 ===Objetivos===
-*Baseado na pequena introdução ao Wireshark apresentada no '''Laboratório 1''', agora estamos prontos para utilizar o Wireshark para investigar protocolos em operação.
+*Baseado na pequena introdução ao Wireshark estamos prontos para utilizar o mesmo para investigar protocolos em operação.
 *Explorar vários aspectos do protocolo HTTP:
-*#a interação básica GET/resposta do HTTP,
+*#A interação básica GET/resposta do HTTP.
-*#formatos de mensagens HTTP,
+*#A interação manual GET/resposta do HTTP utilizando o telnet.
-*#baixando arquivos grandes em HTML,
+*#Diferenciação do comportamento das versões 1.0 e 1.1 do protocolo HTTP.
-*#baixando arquivos em HTML com objetos incluídos, e
-*#segurança HTTP.
 ===A Interação Básica GET/Resposta do HTTP===
-Vamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Faça o seguinte:
+#Vamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Faça o seguinte:
-#inicie o navegador;
+##inicie o navegador;
-#limpe o cache do mesmo (teclas de atalho para o Firefox: '''Ctrl + Shift + Del''');
+##limpe o cache do mesmo (teclas de atalho para o Firefox: '''Ctrl + Shift + Del''');
-#inicie o Wireshark, como descrito no '''Laboratório 1''';
+##inicie o Wireshark, como descrito no '''Ferramentas básicas''';
-#inicie a captura de pacotes;
+##inicie a captura de pacotes;
-#digite o seguinte URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html;
+##digite o seguinte URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html;
-#pare a captura de pacotes;
+##pare a captura de pacotes;
-#digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados).
+##digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados).[[Arquivo:HTTP_Wireshark.png |thumb | 300px| Fig.1 Requisição e Resposta HTTP]]
+#O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas:
-[[Arquivo:HTTP_Wireshark.png |thumb | 300px| Fig.1 Requisição e Resposta HTTP]]
+##A mensagem GET (do seu navegador para o servidor web www.sj.ifsc.edu.br) e a mensagem de resposta do servidor para o seu navegador.
+##A janela de conteúdos de pacotes mostra detalhes da mensagem selecionada (neste caso a mensagem HTTP GET /~odilson/RED29004//RED29004.html, que está em destaque na janela de listagem de pacotes).
-O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas:
+##A mensagem HTTP transportada em um segmento TCP, que é carregado em um datagrama IP, que é levado em um quadro Ethernet com 5728 bits no fio. Isso é observado de baixo para cima na janela de detalhes do cabeçalho do pacote selecionado. O Wireshark exibe informações sobre o quadro, IP, TCP e HTTP. Você deve expandir as informações, por exemplo, do HTTP clicando na seta ao lado esquerdo de “Hypertext Transfer Protocol”. Observando as informações das mensagens HTTP GET e de resposta. Você consegue inclusive enxergar a mensagem mostrada no navegador: '''RED29004! Página de teste.'''
-#A mensagem GET (do seu navegador para o servidor web www.sj.ifsc.edu.br) e a mensagem de resposta do servidor para o seu navegador.
+#<span style="color: #9966CC;">Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões.
-#A janela de conteúdos de pacotes mostra detalhes da mensagem selecionada (neste caso a mensagem HTTP GET /~odilson/RED29004//RED29004.html, que está em destaque na janela de listagem de pacotes).
+##O seu navegador executa HTTP 1.0 ou 1.1?
-#A mensagem HTTP transportada em um segmento TCP, que é carregado em um datagrama IP, que é levado em um quadro Ethernet com 5728 bits no fio. Isso é observado de baixo para cima na janela de detalhes do cabeçalho do pacote selecionado. O Wireshark exibe informações sobre o quadro, IP, TCP e HTTP. Você deve expandir as informações, por exemplo, do HTTP clicando na seta ao lado esquerdo de “Hypertext Transfer Protocol”. Observando as informações das mensagens HTTP GET e de resposta. Você consegue inclusive enxergar a mensagem mostrada no navegador: '''RED29004! Página de teste.'''
+##Qual a versão de HTTP do servidor?
+##Quais idiomas (se algum) o seu navegador indica ao servidor que pode aceitar?
-Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões.
+##Qual o endereço IP do seu computador?
-#O seu navegador executa HTTP 1.0 ou 1.1?
+##E do servidor tele.sj.ifsc.edu.br?
-#Qual a versão de HTTP do servidor?
+##Qual o número da porta utilizada no seu computador?
-#Quais idiomas (se algum) o seu navegador indica ao servidor que pode aceitar?
+##E do servidor tele.sj.ifsc.edu.br?
-#Qual o endereço IP do seu computador?
+##Qual o código de status retornado do servidor para o seu navegador?
-#E do servidor tele.sj.ifsc.edu.br?
+##Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez?
-#Qual o número da porta utilizada no seu computador?
+##Quantos bytes de conteúdo são baixados pelo seu navegador?
-#E do servidor tele.sj.ifsc.edu.br?
+##Encontre a mensagem '''RED29004! Página de teste'''. Onde (em qual campo) encontra-se?
-#Qual o código de status retornado do servidor para o seu navegador?
+##Qual a diferença entre os endereços IP e porta de origem e destino entre a mensagem GET e a de resposta do HTTP?
-#Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez?
-#Quantos bytes de conteúdo são baixados pelo seu navegador?
-#Encontre a mensagem '''RED29004! Página de teste'''. Onde (em qual campo) encontra-se?
-#Qual a diferença entre os endereços IP e porta de origem e destino entre a mensagem GET e a de resposta do HTTP?
 ===Interação Básica GET/Resposta do HTTP usando TELNET e REQUISIÇÃO MANUAL===
@@ Linha 247: / Linha 312: @@
 Trying 200.135.37.75...
 Connected to integrado.sj.ifsc.edu.br.
-Escape character is '^]'.
+Escape character is '^]'.</syntaxhighlight>digite o seguinte:<syntaxhighlight lang=text>
-</syntaxhighlight>digite o seguinte:<syntaxhighlight lang=text>
 GET /~odilson/RED29004//RED29004.html HTTP/1.0
 </syntaxhighlight> e em seguida tecle ENTER duas vezes.
-## Identifique a página html que foi enviada como resposta. Respeita o protocolo HTTP?
+## <span style="color: #9966CC;">Identifique a página html que foi enviada como resposta. Respeita o protocolo HTTP?
-## Compare o resultado das execuções desses comandos com o que se viu no navegador. Qual a diferença em cada caso?
+## <span style="color: #9966CC;">No Wireshark compare o resultado das execuções desses comandos com o que se viu nas capturas Wireshark com acesso pelo navegador. Qual a diferença em cada caso?
-##Quanto tempo levou para fechar a conexão?
+## <span style="color: #9966CC;">Quanto tempo levou para fechar a conexão?
-## Refaça um pedido em que o recurso é inexistente no servidor (ex: página html com nome inexistente). Observe a resposta. Qual é o código da mensagem recebida?
+## <span style="color: #9966CC;">Refaça um pedido em que o recurso é inexistente no servidor (ex: página html com nome/URL inexistente). Observe a resposta. Qual é o código da mensagem recebida?
 # Refaça a conexão com o servidor:<syntaxhighlight lang=bash>
-telnet tele.sj.ifsc.edu.br 80
+telnet tele.sj.ifsc.edu.br 80</syntaxhighlight>
-</syntaxhighlight>
 ## Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:<syntaxhighlight lang=bash>
 GET /~odilson/RED29004//RED29004.html HTTP/1.1
-Host: tele.sj.ifsc.edu.br</syntaxhighlight><code> <Enter>/<Enter></syntaxhighlight>
+Host: tele.sj.ifsc.edu.br</syntaxhighlight> <Enter>/<Enter>
-##Quanto tempo levou para fechar a conexão?
+##<span style="color: #9966CC;">Quanto tempo levou para fechar a conexão?
 # Refaça a conexão com o servidor:<syntaxhighlight lang=bash>
 telnet tele.sj.ifsc.edu.br 80
 </syntaxhighlight>
-## Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:<syntaxhighlight lang=bash>
+## Refaça o pedido, mas agora utilizando o HTTP/1.1:<syntaxhighlight lang=bash>
 GET /~odilson/RED29004//RED29004.html HTTP/1.1
-Host: tele.sj.ifsc.edu.br</syntaxhighlight><code> <Enter>/<Enter></syntaxhighlight>
+Host: tele.sj.ifsc.edu.br</syntaxhighlight> <Enter>/<Enter>
-## Faça um novo pedido na conexão já aberta:<syntaxhighlight lang=bash>
+## Antes do fechamento da conexão, faça um novo pedido na conexão já aberta:<syntaxhighlight lang=bash>
-GET /~odilson/RED29004/RED29004_arq3.html HTTP/1.1
+GET /~odilson/RED29004//RED29004_arq3.html HTTP/1.1
-Host: tele.sj.ifsc.edu.br</syntaxhighlight><code> <Enter>/<Enter></syntaxhighlight>
+Host: tele.sj.ifsc.edu.br</syntaxhighlight> <Enter>/<Enter>
-#O que explica a diferença de tempo para fechamento de conexão entre as versões HTTP 1.0 e 1.1? Descreva o processo de download dos objetos em ambos os casos.
+#<span style="color: #9966CC;">O que explica a diferença de tempo para fechamento de conexão entre as versões HTTP 1.0 e 1.1?
+#<span style="color: #9966CC;">Descreva qual seria o procedimento para o download de dois objetos, via telnet, nos protocolos HTTP 1.0 e 1.1?
 ==Desvendando o HTTP com Wireshark, parte 2==
+===Objetivos===
+*Explorar vários aspectos do protocolo HTTP:
+*#A requisição condicional.
+*#Formatos de mensagens HTTP.
+*#''Cookies''.
+*#Os processos e protocolos envolvidos ao baixar arquivos grandes em HTML.
+*#Os processos envolvidos ao baixar arquivos em HTML com objetos incluídos.
 ===A Interação HTTP GET Condicional/Resposta===
-A maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
+#A maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
-#inicie o navegador web;
+##Inicie o navegador web;
-#limpe o cache do seu navegador('''Ctrl + Shift + Del''');
+##Limpe o cache do seu navegador ('''Ctrl + Shift + Del''');
-#inicie o Wireshark;
+##Inicie o Wireshark;
-#digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html seu navegador deve exibir um arquivo em HTML muito simples com duas linhas;
+##Digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html. Seu navegador deve exibir um arquivo em HTML muito simples com duas linhas;
-#pressione o botão “refresh” no navegador (ou digite o URL novamente);
+##Pressione o botão “refresh” no navegador (ou digite o URL novamente);
-#pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes.
+##No Wireshark pare a captura de pacotes e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes.
+#<span style="color: #9966CC;">Responda às seguintes questões:
+##Inspecione o conteúdo da primeira mensagem - HTTP GET - do seu navegador para o servidor tele.sj.ifsc.edu.br. Você vê uma linha “If-Modified-Since”?
+##Inspecione o conteúdo da resposta do servidor, segunda mensagem. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso?
+##Agora inspecione o conteúdo da terceira mensagem - HTTP GET - do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”?
+##Qual é o código de status e a frase retornada do servidor na resposta à segunda mensagem HTTP GET? É diferente do código de retorno da primeira mensagem?
+##Na segudna resposta, o servidor retornou explicitamente o conteúdo do arquivo? Explique.
+##Qual o tamanho da primeira e segunda mensagem de retorno (respostas) do servidor?
-Responda às seguintes questões:
+===''Cookies''===
-#Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor tele.sj.ifsc.edu.br. Você vê uma linha “If-Modified-Since”?
+#Inicie o navegador web;
-#Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso?
+#Limpe o cache do seu navegador;
-#Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”?
+#Inicie a captura no Wireshark;
-#Qual é o código de status e a frase retornada do servidor na resposta à segunda mensagem HTTP GET? É diferente do código de retorno da primeira mensagem?
+#Digite o URL no navegador http://www.dvwa.co.uk/;
-#O servidor retornou explicitamente o conteúdo do arquivo? Explique.
+#Pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
-#Qual o tamanho da primeira e segunda mensagem de retorno do servidor?
+#Utilize o recurso de procura do Wireshark, exemplo na figura ao lado, e busque em '''''Packet details''''' pelas strings '''cookie''' e '''set-cookie''' [[Arquivo:Cookies.png |thumb | 200px| Figura 1 - Filtro string cookie]]
+#<span style="color: #9966CC;">Você deve ter encontrado 1 ocorrência de ''set-cookie'' e várias de ''cookie'', sempre com o mesmo número associado, explique o motivo explicando o comportamento do protocolo?
+#Inicie novamente a captura no Wireshark;
+#Digite novamente a URL no navegador http://www.dvwa.co.uk/ (NÃO limpe o ''cache'');
+#Pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro.
+#Busque novamente as strings '''cookie''' e '''set-cookie'''. Analise.
+#<span style="color: #9966CC;">Os números são os mesmos do caso anterior? Explique o funcionamento de Cookies através desse experimento.
 ===Baixando Documentos Longos===
-<span style="color: red;">Antes de qualquer experimento deve-se desabilitar algumas funcionalidades do kernel do LINUX, para que os experimentos reflitam a teoria. Caso sua interface de rede não seja a '''eth0''' adapte o comando, caso reiniciar a máquina repita-o:</span>
+<span style="color: red;">Antes de qualquer experimento deve-se desabilitar algumas funcionalidades do kernel do LINUX, para que os experimentos reflitam a teoria. Caso sua interface de rede não seja a '''eth0''' adapte o comando substituindo eth0 pelo nome da sua interface de rede. Se, por qualquer motivo, reiniciar a máquina, repita-o:</span>
-<code>sudo ethtool --offload eth0 gso off tso off sg off gro off </syntaxhighlight>
-Nos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande. Faça o seguinte:
-#inicie o navegador web;
-#limpe o cache do seu navegador;
-#inicie o Wireshark;
-#digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004_arq2.html seu navegador deve exibir um documento bastante longo e criativo :) ;
-#Faça um atualização da página (F5);
-#pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
-Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de '''11747 bytes''' é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o nono "Reassembled TCP Segments" no Wireshark.
+<syntaxhighlight lang=bash> sudo ethtool --offload eth0 gso off tso off sg off gro off </syntaxhighlight>
-Responda às seguintes questões:
+#Nos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande. Faça o seguinte:
-#Quantas mensagens HTTP GET foram enviadas pelo seu navegador?
+##Inicie o navegador web;
-#Quantos segmentos TCP foram necessários para carregar a resposta?
+##Limpe o cache do seu navegador;
-#Qual é o código de status e a frase associada com a resposta à mensagem HTTP GET?
+##Inicie o Wireshark;
-#No segundo GET realizado, quantos segmentos TCP foram necessários para obtenção da resposta do servidor?
+##Digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004_arq2.html. Seu navegador deve exibir um documento bastante longo e criativo :);
-#O que explica a diferença entre a primeira e segunda requisições?
+##Faça um atualização da página (F5);
+##Pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
+#Na janela de listagem de pacotes, clique sobre a resposta do servidor ('''200 OK (text/html)''')
+#Na janela de detalhes do pacote, clique sobre o nono ".... '''Reassembled TCP Segments'''"
+#*Esta resposta, em vários pacotes, merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma série de linhas de cabeçalho, seguida por uma linha em branco, seguida pela carga útil (''Content-Length''). Nessa resposta, a carga útil do arquivo em HTML é bastante longo, e a informação de '''11747 bytes''' é muito grande para caber em um único segmento TCP. Assim sendo, a resposta HTTP é quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark. Aqui fica evidente a relação entre camadas: Na camada de aplicação uma grande mensagem que é quebrada pela camada de transporte para "dar conta" de fazer o serviço de entrega.
+#<span style="color: #9966CC;">Responda às seguintes questões:
+##Quantas mensagens HTTP GET foram enviadas pelo seu navegador?
+##Quantas respostas HTTP sua máquina recebeu?
+##Quantos segmentos TCP foram necessários para carregar a resposta?
+##Você percebe alguma lógica no sequenciamento desses segmentos TCP? Se sim, explicite. Tema para o próximo capítulo.
+##Qual é o código de status e a frase associada com a resposta à mensagem HTTP GET? Obs.: Observe os campos do cabeçalho de uma resposta HTTP.
+##No segundo GET realizado, quantos segmentos TCP foram necessários para obtenção da resposta do servidor?
+##O que explica a diferença entre a primeira e segunda requisições?
 ===Documentos HTML com Objetos Incluídos===
-Agora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
+#Agora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu navegador baixa um arquivo principal com objetos incluídos. No nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
-#inicie o navegador web;
+##Inicie o navegador web;
-#limpe o cache do seu navegador;
+##Limpe o cache do seu navegador;
-#inicie o Wireshark;
+##Inicie o Wireshark;
-#digite o URL no navegador  http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não estão no arquivo em HTML, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. As imagens estão em docente.ifsc.edu.br;
+##Digite o URL no navegador  http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html. Seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não são conteúdos do arquivo em HTML e nem estão depositadas no mesmo servidor, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. As imagens estão em docente.ifsc.edu.br;
-#digite o URL no navegador  http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq4.html seu navegador deve exibir um arquivo pequeno em HTML com cinco imagens incluídas. Estas cinco imagens,diferentemente do caso anterior, estão depositadas no próprio sítio do professor;
+#Digite o URL no navegador  http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq4.html. Seu navegador deve exibir um arquivo pequeno em HTML com cinco imagens incluídas. Estas cinco imagens,diferentemente do caso anterior, estão depositadas no próprio sítio navegado;
-#pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
+#Pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
+#<span style="color: #9966CC;">Responda às seguintes questões, separando as respostas para o acesso ao RED29004_arq3.html e RED29004_arq4.html (6 respostas):
-Responda às seguintes questões:
+##Quantas mensagens HTTP GET foram enviadas pelo seu navegador em cada acesso?
-#Quantas mensagens HTTP GET foram enviadas pelo seu navegador em cada acesso?
+##Para quais endereços na Internet estas mensagens foram enviadas em cada acesso?
-#Para quais endereços na Internet estas mensagens foram enviadas em cada acesso?
+##Você consegue dizer se o seu navegador baixou imagens com ou sem paralelismo? Explique e diferencie o comportamento em cada um dos casos.
-#Você consegue dizer se o seu navegador baixou imagens com ou sem paralelismo? Explique e diferencie o comportamento em cada um dos casos.
 ===HTTPS===
-Para finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
+*O Hyper Text Transfer Protocol Secure (HTTPS) é uma implementação do protocolo HTTP sobre uma camada adicional de segurança que utiliza o protocolo SSL/TLS e permite a transmissão de dados numa conexão criptografada através de certificados digitais.
-#inicie o navegador web;
+*Caso tenha interesse em analisar troca de mensagens HTTPS e verificar seus conteúdos siga o roteiro [https://support.citrix.com/article/CTX116557 ''How to Decrypt SSL and TLS Traffic Using Wireshark'']
-#limpe o cache do seu navegador;
-#inicie o Wireshark;
-#digite o seguinte URL no navegador https://www.ssllabs.com/ssltest/;
-#pare a captura de pacotes e digite "ssl" na caixa de texto de especificação de filtro, para que apenas as mensagens criptografadas sejam exibidas.
-Responda:
+==Serviço de Nomes (DNS)==
-#Compare a sequência de troca de mensagens (GET e resposta) entre o HTTP (das seções anteriores) com o ssl, existe alguma similaridade?
-#Que tipos de campos são mais presentes nesse tipo de mensagens?
-#Você consegue identificar o conteúdo de alguma nas mensagens ssl, como no caso das mensagens http?
-==Serviço de Nomes (DNS)==
+===Leitura recomendada===
+*[[Detalhes sobre DNS]]
 ===Objetivos===
 O Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto:
-#o lado cliente do DNS,
+#o lado cliente do DNS e
-#uma pequena análise do protocolo e
+#uma pequena análise do protocolo
-#consultas AAAA
 Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados  hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor.
-===Consulta simples ao DNS gerada a partir de um comando ping===
+===PARTE 1: Consulta simples ao DNS gerada a partir de um comando ping===
 O comando ping pode ser usado tanto com um endereço IP como com um nome de host. Em última instância, ele sempre enviará pacotes para um endereço IP. No caso de ser usado o endereço de host, ele tentará resolver (mapear) este nome em um endereço IP usando um servidor DNS (local). Ele gera uma pergunta para o servidor (ou para os servidores, caso exista mais de um configurado). Esta experiência mostra como verificar os servidores instalados e, através de uma captura de pacote mostra a estrutura dos cabeçalhos DNS.
-#Inicialmente consulte e anote quem são os servidores DNS instados na sua máquina. É para estes servidores que serão conduzidas as perguntas DNS. Use a ferramenta nm-tool ou acesso ao arquivo de configuração do sistema:<br />
+#Inicialmente consulte e anote quem são os servidores DNS instados na sua máquina. É para estes servidores que serão conduzidas as perguntas DNS. Use a ferramenta nm-tool ou acesso ao arquivo de configuração do sistema:
-#: nm-tool | tail -n 8 <br />
+#: nmcli dev show | grep DNS
-#: cat /etc/resolv.conf
 #Prepare o wireshark para capturar pacotes. Feche o mozilla ou qualquer outro software de rede parar evitar tráfego DNS que possa vir a confundi-lo.
 #Execute o ping para um endereço de host conhecido
 #: ping www.ifsc.edu.br
-#Pare a captura e coloque um filtro de display para mostrar apenas mensagens DNS e de ICMP
+#Pare a captura de pacotes no Wireshark e coloque um filtro de display para mostrar apenas mensagens DNS e de ICMP
 #: dns || icmp
-#Observe os pacotes capturados. Em particular foque no pacote de pergunta que deve ser similar ao mostrado abaixo e deve estar direcionado a um dos servidores DNS. Nos flags do header do pacote DNS é possível observar que é um QUERY (pergunta) a ser resolvido de forma recursiva. A pergunta propriamente dita está no campo QUERIES, onde é colocado o nome a ser resolvido e o tipo do registro solicitado (tipo A) que indica resolução de nome).
+#Observe os pacotes capturados. Em particular foque no pacote de pergunta que deve ser similar ao mostrado abaixo e deve estar direcionado a um dos servidores DNS. Nos ''flags'' do header do pacote DNS é possível observar que é um QUERY (pergunta) a ser resolvido de forma recursiva. A pergunta propriamente dita está no campo QUERIES, onde é colocado o nome a ser resolvido e o tipo do registro solicitado (tipo A) que indica resolução de nome.
 #:
 #:[[Arquivo:DNS-Tela1-Wireshark.jpg | 900px| Estrutura de uma pergunta simples DNS]]
@@ Linha 373: / Linha 452: @@
 #:
 #:[[Arquivo:DNS-Tela2-Wireshark.jpg | 900px| Estrutura de uma resposta simples DNS]]
-#Perguntas a serem respondidas, baseado nos pacotes "''Standard query''" e "''Standard query responde''":
+# <span style="color: #9966CC;">Perguntas a serem respondidas, baseado nos pacotes "''Standard query''" e "''Standard query response''":
 ##Quem são os servidores DNS da sua máquina?
-##O ping gerou uma pergunta para cada um deles?
+##O ping gerou pergunta para cada um deles?
-##Qual o tipo da RR (Registro) associada a pergunta (''Queries''). O que significa?
+##Qual o tipo da RR associada a pergunta (''Queries''). O que significa?
 ##Qual endereço IP retornado para o www.ifsc.edu.br?
 ##Qual endereço IP usado no ping (ver pacote REQUEST ICMP)?
+##Qual protocolo de transporte, camada 4, que foi usado para transportar as mensagens de aplicação DNS?
 ##No QUERY realizado foi solicitado consulta recursiva. O servidor aceitou esta solicitação? (ver a resposta do servidor)
-##Quais os endereços IPv4 dos servidores autorizados repassados?
+##Quais os servidores autorizados (''Authoritative nameservers'') foram repassados como resultado de sua consulta?
-#Logo após o primeiro ping existe mais uma consulta DNS. Esta pergunta é realizada através de uma mensagem do tipo '''PTR'''. O ping está tentando verificar qual é o nome da máquina que realmente está respondendo. É o DNS reverso, onde se fornece um IP e o servidor devolve o nome da máquina.
+#Logo após o primeiro ping existe mais uma consulta DNS. Esta pergunta é realizada através de uma mensagem do tipo PTR. O ping está tentando verificar qual é o nome da máquina que realmente está respondendo. É o DNS reverso, nesse tipo de colsulta se fornece um IP e o servidor devolve o nome da máquina.
-#Perguntas a serem respondidas:
+# <span style="color: #9966CC;">Perguntas a serem respondidas:
 ##Qual o IP que se pretende resolver?
 ##Qual o nome retornado?
+##O nome retornado é www.ifsc.edu.br? Sim ou não? Explique.
 ===Consultas DNS por meio de ferramentas especializadas===
@@ Linha 391: / Linha 472: @@
 #* www.google.com
 #* www.gmail.com
-# Agora descubra e anote no relatório quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa ''host'' ou ''dig'' isso pode ser feito assim: <syntaxhighlight lang=bash>
+# <span style="color: #9966CC;">Agora descubra e anote no relatório quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa ''host'' ou ''dig'' isso pode ser feito assim: <syntaxhighlight lang=bash>
 host -t ns ifsc.edu.br
 dig -t ns ifsc.edu.br
-</syntaxhighlight>
-# Descubra e anote no relatório: qual o servidor DNS usado pelo seu computador? Num terminal digite: <syntaxhighlight lang=bash>
-cat /etc/resolv.conf
-caso a resposta seja "nameserver 127.0.1.1" (endereço de loopback), provavelmente o sistema gráfico está controlando sua interface, nesse caso execute:
-nm-tool | tail -n 8
 </syntaxhighlight>
 # O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio e/ou máquina. Por exemplo, como ele pode-se descobrir que ''host'' recebe emails em um determinado domínio. Isso é utilizado pelos MTA (''Mail Transfer Agent'') mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX (''Mail eXchange'') de um domínio. Novamente as ferramentas a ser utilizada nesse caso podem ser ''host'' ou ''dig''. Por exemplo: <syntaxhighlight lang=bash>
 host -t mx ifsc.edu.br
 dig -t mx ifsc.edu.br
-</syntaxhighlight>Descubra e anote no relatório quem é o servidor de emails nos seguintes domínios:
+</syntaxhighlight>
+#<span style="color: #9966CC;">Descubra e anote no relatório quem é o servidor de emails nos seguintes domínios:
 #* gmail.com
 #* hotmail.com
@@ Linha 409: / Linha 486: @@
 # Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: <syntaxhighlight lang=bash>
 dig -x 200.135.37.65
-</syntaxhighlight> ... o ''dig'' tem um resultado um pouco mais carregado que os outros utilitários (''host'' e ''nslookup''), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha '';; ANSWER SECTION:''. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do ''dig'' para respostas curtas: <code>
+</syntaxhighlight> ... o ''dig'' tem um resultado um pouco mais carregado que os outros utilitários (''host'' e ''nslookup''), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha '';; ANSWER SECTION:''. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do ''dig'' para respostas curtas:  <syntaxhighlight lang=bash>
 dig -x 200.135.37.65 +short
 </syntaxhighlight>
-#Faça uma consulta recursiva com dig e responda:<syntaxhighlight lang=bash>
+#<span style="color: #9966CC;">Faça uma consulta iterativa com ''dig'' e responda:<syntaxhighlight lang=bash>
-dig +trace mail.ru. </syntaxhighlight>
+dig +trace @8.8.8.8 mail.ru. </syntaxhighlight>
 ##Qual foi o RLD (''Root Level Domain'') consultado?
 ##Qual o TLD (''Top Level Domain'') consultado?
 ##Qual o SLD (''Second Level Domain'') consultado?
 ##Como você sabe que foram esses os LDs consultados?
-# Como explicado durante a aula e visto no exercício anterior, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? Posto de outro modo, vamos fazer todo o processo de requisição interativa, do exercício anterior, manualmente, ou seja, descobrir quem é o ''Root Level Domain'', o ''Top Level Domain'' e o ''Second Level Domain''. Anote no relatório.
-## Descubra quem são os servidores raiz (topo de hierarquia DNS): <syntaxhighlight lang=bash>
-host -t ns .
-dig -t ns .
-</syntaxhighlight>
-## Escolha um dos servidores RLD listados, e use-o para fazer as consultas. Por exemplo: <syntaxhighlight lang=bash>
-host -v -t a www.sj.ifsc.edu.br. j.root-servers.net.
-</syntaxhighlight>... e observe a seção '';; AUTHORITY SECTION:''. Ele contém a listagem de servidores DNS que podem atender sua consulta.
-## Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Por exemplo: <code>
-host -v -t a www.sj.ifsc.edu.br. b.dns.br </syntaxhighlight>
-## Quantos servidores DNS foram necessários consultar no total?
-#Consultando um servidor explícito(@)<syntaxhighlight lang=bash>
-dig @j.root-servers.net. +trace www.sj.ifsc.edu.br. </syntaxhighlight>
-##Explique a diferença na consulta realizada por esse comando para o comando ''dig +trace www.sj.ifsc.edu.br''. Em algum caso a consulta poderia ser exatamente a mesma? Qual?
-==Serviço de Nomes (DNS), parte 2==
 ===Algumas consultas AAAA===
 Vamos expandir um pouco nossos horizontes e fazer algumas consultas envolvendo IPv6.
-#No terminal de sua máquina faça uma consulta e responda: qual o endereço IPv6 dos hosts? Por exemplo: <code>
+#<span style="color: #9966CC;">No terminal de sua máquina faça uma consulta e responda: qual o endereço IPv6 dos hosts? Por exemplo: <syntaxhighlight lang=bash>
 dig AAAA google.com
 host -t AAAA google.com </syntaxhighlight>
-##webmail.ufsc.br
-##www.sj.ifsc.edu.br
-##www.nyt.com
 ##ipv6.br
 ##www.microsoft.com
-#Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo: <code>
+#<span style="color: #9966CC;">Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo: <syntaxhighlight lang=bash>
 dig -x 2001:12ff::10
 dig -x 2001:12ff::10 +short
@@ Linha 452: / Linha 510: @@
 ##2001:12d0:0:126::183:244
 ##2001:12ff::10
-##2804:1454:1004:100::2
-===Analisando o protocolo via Wireshark===
-Agora que já está ficando claro como funcionam as consultas DNS, deve-se investigar como se dá a comunicação entre seu computador e seu servidor DNS.
-#abra o navegador web e limpe o cache do mesmo;
-#abra o Wireshark e escolha a interface e inicie a captura de pacotes;
-#inicie a captura de pacotes no Wireshark;
-#no terminal digite '''dig +trace canon.jp''' (isso vai provocar a consulta DNS);
-#pare a captura de pacotes;
-#No Wireshark digite “dns” no filtro (sem as aspas);
-Com base nisso identifique o seguinte:
-#quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta?
-#que protocolo de transporte é usado?
-#que portas de origem e destino são utilizadas?
-#qual o formato das mensagens DNS? Elas são textuais como as mensagens HTTP?
-#qual o tipo de registro DNS acessado em cada consulta?
-#que informações estão contidas nas respostas DNS? Há algo além do que foi pedido?
-#qual o tamanho das mensagens DNS?
-#qual endereço IP a mensagem de consulta DNS é enviada? Foi o mesmo ip obtido na seção anterior: seu servidor DNS?
-#examine a mensagem de consulta DNS. Qual o campo “type” desta mensagem?
-#a mensagem de consulta contém algum campo “answer”?
-#examine a mensagem de resposta DNS. Quantos campos com “answer” existem?
-#quais são os benefícios de usar o UDP ao invés do TCP como protocolo de transporte para o DNS?
 ===Exemplos de arquivos de um ''Second Level Domain'' fictício===
 *Exemplo de arquivos de configuração de um servidor [https://www.isc.org/downloads/bind/ BIND]
-/etc/bind/db.redes <code>
+/etc/bind/db.redes <syntaxhighlight lang=bash>
 $TTL	86400
 @	IN	SOA	ns.redes.edu.br. root (
@@ Linha 500: / Linha 535: @@
 mail	A	192.168.1.109 </syntaxhighlight>
-/etc/bind/db.2.168.192 (Zona reversa) <code>
+/etc/bind/db.2.168.192 (Zona reversa) <syntaxhighlight lang=bash>
 $TTL	86400
 @	IN	SOA	ns.redes.edu.br. root (
@@ Linha 515: / Linha 550: @@
        IN      PTR     mail.redes.edu.br. </syntaxhighlight>
-==Entendendo ''sockets'', UDP e TCP==
+==Comparando ''sockets'' UDP e TCP==
 ===Objetivos===
-Entender o conceito de ''sockets'' relacionados aos protocolos UDP e TCP.
+*Entender o conceito de ''sockets'' relacionados aos protocolos UDP e TCP.
+**Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para ''sockets''. Um processo é semelhante a um prédio e o ''socket'' do processo é semelhante a uma porta em seu interior. A aplicação reside dentro do prédioa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior do prédio mas tem pouco (ou nenhum) controle sobre o exterior.
+*Simultaneamente explora-se os conceitos relativos aos protocolos UDP e TCP, observando-se a quantidade de mensagens necessárias para a troca de uma simples frase textual.
+**'''Observa-se a "agilidade" do UDP e a robustez do TCP'''.
+*Por fim, propõe-se um comparativo entre os dois protocolos da camada de transporte: UDP e TCP.
-Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para ''sockets''. Um processo é semelhante a uma casa e o ''socket'' do processo é semelhante a uma porta. A aplicação reside dentro da casa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior da casa mas tem pouco (ou nenhum) controle sobre o exterior.
-Simultaneamente explora-se os conceitos relativos aos protocolos UDP e TCP, observando-se a quantidade de mensagens necessárias para a troca de uma simples frase textual. Observa-se a "agilidade" do UDP e a robustez do TCP.
+Leia os slides de 1 à 12 e o 58: [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%203%20Camada%20de%20transporte.pdf Capitulo 3 -- Camada de Transporte]
 ===Descrição da aplicação a ser desenvolvida em UDP e TCP===
@@ Linha 531: / Linha 569: @@
 #O servidor envia os dados modificados ao cliente.
 #O cliente recebe os dados modificados e apresenta a linha em sua tela.
+===Programação de ''sockets'' com TCP===
+*Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Pode-se dizer que o TCP é realizado em duas etapas:
+#Primeiramente eles devem se apresentar, o primeiro ''socket'' da Figura abaixo. Isto serve somente para abertura de conexão.
+#Estabelecer uma conexão TCP, o segundo ''socket'' da Figura abaixo. Todos os dados trafegarão pelo segundo ''socket''.
+O processo TCPServer tem dois sockets:
+[[imagem:Programacao_socket_TCP_1.png|400px]]
+A aplicação cliente-servidor usando TCP:
+[[imagem:Programacao_socket_TCP_2.png|500px]]
+=====Roteiro=====
+*Utilizamos a linguagem Python por expor com clareza os principais conceitos de ''sockets''. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de ''sockets'' utilizando a API Posix encontra-se [[RED29004-2014-1#03.2F04.2F14:_Camada_de_Aplica.C3.A7.C3.A3o:_programando_sockets_TCP | aqui]].
+#Escreva (copie) o código do programa '''servidor''' e salve como TCPServer.py <syntaxhighlight lang=bash>
+from socket import *
+serverPort = 33333
+serverSocket = socket(AF_INET, SOCK_STREAM)
+serverSocket.bind(('',serverPort))
+#Escuta as requisicoes do TCP do cliente. Numero maximo de conexoes em fila = 1
+serverSocket.listen(1)
+print 'O servidor esta pronto'
+while 1:
+	#Quando o cliente bate a essa porta, o programa chama o metodo accept() para serverSocket,
+        #que cria um novo socket no servidor, chamado connectionSocket, dedicado a esse cliente
+        #especifico. Cliente e servidor, entao, completam a apresentacaoo, criando uma conexao TCP
+        #entre o clientSocket do cliente e o connectionSocket do servidor.
+	connectionSocket, addr = serverSocket.accept()
+	message = connectionSocket.recv(1024)
+        print message
+	messageMaiuscula = message.upper()
+	connectionSocket.send(messageMaiuscula)
+	connectionSocket.close() </syntaxhighlight>
+#No terminal da máquina execute a aplicação servidor: <syntaxhighlight lang=bash>
+python TCPServer.py </syntaxhighlight>
+#*Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe.
+#Deixe o programa servidor rodando nesse terminal.
+#Em um outro terminal, abra um segundo terminal, pode-se verificar se a porta está aberta com a ferramenta Nmap (''the Network Mapper''):
+#*<span style="color: red;">Lembre-se de ajustar ip_do_servidor para o número adequado, ou seja, o IP da máquina onde está rodando o TCPServer.py. <syntaxhighlight lang=bash>
+ nmap -p 33333 ip_do_servidor </syntaxhighlight>
+#<span style="color: #9966CC;">Qual o estado dessa porta? Cite e justifique o tipo de serviço.
+#No segundo terminal, escreva (copie) o código do programa '''cliente''' e salve como TCPClient.py.
+#*<span style="color: red;">Lembre-se de ajustar ip_do_servidor para o número adequado, ou seja, o IP da máquina onde está rodando o TCPServer.py. Obs.: mantenha as aspas.
+#*Esse experimento pode ser rodado tanto numa única máquina quanto em máquinas distintas para cliente e servidor. <syntaxhighlight lang=bash>
+from socket import *
+serverName = 'ip_do_servidor'
+serverPort = 33333
+#SOCK_STREAM habilita uso do TCP
+clientSocket = socket(AF_INET, SOCK_STREAM)
+#Representa o estabelecimento da conexao. E o "aperto de maos", onde o cliente e servidor trocam
+#informacoes da portas que serao utilizadas pela conexao (socket) propriamente dito
+clientSocket.connect((serverName,serverPort))
+message = raw_input('Entre com a sentanca em minuculas: ')
+#Diferentemente do UDP, aqui nao e necessario encaminhar o endereco do servidor, ja que este socket
+#eh uma "tubulacao" direta entre ambos, basta empurrar dados
+clientSocket.send(message)
+modifiedMessage = clientSocket.recv(1024)
+print 'Mensagem do servidor: ', modifiedMessage
+clientSocket.close() </syntaxhighlight>
+#Rode o WireShark. Configure a captura na interface '''''any''''', use o filtro do tipo: '''tcp.port==33333'''.
+#No segundo terminal execute a aplicação cliente: <syntaxhighlight lang=bash>
+python TCPCliente.py </syntaxhighlight>
+#Digite a mensagem que deseja e espere a resposta do servidor. Funcionou?
+#Com o servidor rodando em seu terminal, faça duas conexões simultâneas. Pode ser dois terminais rodando a aplicação cliente em cada um deles.
+#Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark.
+#Pare a captura no Wireshark.
+#<span style="color: #9966CC;">Perguntas:
+##As três primeiras mensagens trocadas apresentam a camada de aplicação, sim ou não? Explique. O que elas significam?
+##Em qual mensagem (número) é que a frase é enviada ao servidor?
+##A mensagem seguinte (quinta) apresenta camada de aplicação? Clique na camada TCP no Wireshark e observe o campo '''Flags: 0x010 (ACK)'''. O que você acha que isso significa?
+##Qual o conteúdo da mensagem seguinte (sexta)? E da sétima? Explique.
+##Explique as três últimas mensagens. Dica: olhe as figuras 3.39 e 3.40 do Kurose versão 6.
+##Qual é o protocolo da camada de transporte nessa troca de mensagens?
+##Quais são os números de porta e os IPs utilizados?
+##Quem definiu o número de porta do cliente?
+##Quais foram os números de sequência utilizados em todas as mensagens?
+##Qual o número identificador de protocolo TCP no pacote IP?
+##Quantos ''socktes'' foram abertos no servidor com um cliente "conectado"? E com dois clientes?
+##Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente. O teste também pode ser feito utilizando máquinas virtuais e/ou vários terminais.
+##Capture todos os pacotes trocados, entre você e seu vizinho. Os números de portas e IPs são ou não iguais?
 ===Programação de ''sockets'' com UDP===
@@ Linha 538: / Linha 658: @@
 [[imagem:Programacao_socket_UDP.png|500px]]
-Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens via ''sockets'', que abstrai qualquer necessidade de conhecimento das camadas subjacentes.
+Como fica evidente na Figura acima, há dois processos cliente e servidor que podem ou não rodar em máquinas distintas e se comunicam justamente enviando mensagens via ''sockets'', que abstrai qualquer necessidade de conhecimento das camadas subjacentes.
 =====Roteiro=====
-#Observe que uma mesma máquina pode fazer o papel de cliente e servidor simultaneamente.
+*Observe que uma mesma máquina pode fazer o papel de cliente e servidor simultaneamente.
-#Escreva o programa UDPServer.py <code>
+#Escreva (copie) o programa UDPServer.py <syntaxhighlight lang=bash>
+#Os comentarios estao propositalmente sem acentuacao, caso contrario, tem-se erro de sintaxe.
 #Esta linha define que pode-se utilizar sockets dentro do programa
 from socket import *
@@ Linha 556: / Linha 677: @@
 #Aguarda indefinidamente por contatos (mensagens) de clientes
 while 1:
+        message, clientAddress = serverSocket.recvfrom(2048)
-	message, clientAddress = serverSocket.recvfrom(2048)
          print message
          #Ao receber a mensagem do cliente converte todos os caracteres para maiusculas.
 	modifiedMessage = message.upper()
 	serverSocket.sendto(modifiedMessage, clientAddress) </syntaxhighlight>
-#No terminal da máquina execute o programa: <code>
+#Num terminal da máquina execute a aplicação servidor: <syntaxhighlight lang=bash>
-python UDPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza eh sintaxe. Deixe o programa rodando nesse terminal.
+python UDPServer.py </syntaxhighlight>
-#Abra um '''novo terminal''' e escreva o programa cliente. UDPClient.py. Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP de sua maquina ou de seu vizinho. <code>
+#*Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal.
+#Escreva (copie) o programa cliente. UDPClient.py. <span style="color: red;">
+#*Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP da maquina onde está rodando a aplicação servidor. Obs.: mantenha as aspas. <syntaxhighlight lang=bash>
 #Esta linha define que pode-se utilizar sockets dentro do programa
 from socket import *
@@ Linha 589: / Linha 711: @@
 #Fecha o socket.
 clientSocket.close() </syntaxhighlight>
-#No terminal da máquina execute o programa: <code>
-python UDPClient.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe.
-#O cliente pode também ser substituído pelo comando de terminal: <code> netcat -u ip_do_servidor 22222</syntaxhighlight>
 #Rode o WireShark. Configure a captura na interface '''''any''''',  com o filtro: '''udp.port == 22222'''.
-#Digite a mensagem que deseja e espere a resposta do servidor. Funcionou?
+#Num segundo terminal execute o programa: <syntaxhighlight lang=bash>
-#Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando o cliente.
+python UDPClient.py </syntaxhighlight>
-PERGUNTAS baseadas na captura:
+#*Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe.
-#Em algum momento foi identificado algum procedimento para estabelecimento de conexão?
+#No segundo terminal, aplicação cliente, digite a mensagem que desejar, SEM espaços em branco, e espere a resposta do servidor. Funcionou?
-#Em algum campo do UDP existe numeração de mensagens?
+#Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando a aplicação cliente.
-#Qual o número identificador de protocolo UDP no pacote IP?
+#Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark.
-#Qual é o ''checksum'' no pacote (datagrama) UDP?
+#Pare a captura de pacotes.
-#É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor?
+#<span style="color: #9966CC;">PERGUNTAS baseadas na captura:
-#Se a mensagem digitada for '''teste''', do cliente para o servidor deve aparacer o campo '''Data:7465737465''' e a resposta do servidor deve aparecer '''Data: 5445535445'''. O que significa isso? Dica, olhe na internet o código ASCII.
+##Em algum momento foi identificado algum procedimento para estabelecimento de conexão?
-#Qual foi a sequência numérica do campo Data em seu teste? Qual o significado?
+##Em algum campo do UDP existe numeração de mensagens?
-#Qual é o protocolo da camada de transporte nessa troca de mensagens?
+##Qual o número identificador de protocolo UDP no pacote IP?
-#Qual são os dois números de porta e os dois IPs utilizados?
+##Qual é o ''checksum'' no pacote (datagrama) UDP?
-#Quem definiu o número de porta do cliente?
+##É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor?
-#Quantos ''socktes'' foram abertos no servidor com um cliente "conectado"? E com dois clientes?
+##Se a mensagem digitada for '''teste''', do cliente para o servidor deve aparacer o campo '''Data:7465737465''' e a resposta do servidor deve aparecer '''Data: 5445535445'''. O que significa isso? Dica, olhe na internet o código ASCII.
-#Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente.
+##Qual foi a sequência numérica do campo ''Data'' em seu teste? Qual o significado?
-#Capture todos os pacotes trocados, entre você e seu vizinho. Os números de portas e IPs são ou não iguais? Explique.
+##Qual é o protocolo da camada de transporte nessa troca de mensagens?
+##Qual são os dois números de porta e os dois IPs utilizados?
-==Entendendo sockets, UDP e TCP, parte 2==
+##Quem definiu o número de porta do cliente?
+##Quantos ''socktes'' foram abertos no servidor com um cliente "conectado"? E com dois clientes?
-===Programação de ''sockets'' com TCP===
+##Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente.
+##Capture todos os pacotes trocados, entre você e seu vizinho. Os números de portas e IPs são ou não iguais? Explique.
-Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Isso significa que, antes que cliente e servidor possam enviar dados uma ao outro, primeiramente eles devem se apresentar, o primeiro ''socket'' da Figura abaixo, e estabelecer uma conexão TCP, o segundo ''socket'' da Figura abaixo. Todos os dados trafegarão pelo segundo ''socket''.
+#<span style="color: #9966CC;">Comparativo entre TCP e UDP:
+##Quantas mensagens foram trocadas entre o servidor e o cliente em cada um dos protocolos para atingir o mesmo objetivo?
-O processo TCPServer tem dois sockets:
+##O que justifica a diferença na quantidade de mensagens trocadas?
+##Discuta as vantagens e desvantagens de cada protocolo.
-[[imagem:Programacao_socket_TCP_1.png|400px]]
-A aplicação cliente-servidor usando TCP:
-[[imagem:Programacao_socket_TCP_2.png|500px]]
-=====Roteiro=====
-#Escreva o código do programa servidor. TCPServer.py <code>
-from socket import *
-serverPort = 33333
-serverSocket = socket(AF_INET, SOCK_STREAM)
-serverSocket.bind(('',serverPort))
-#Escuta as requisicoes do TCP do cliente. Numero maximo de conexoes em fila = 1
-serverSocket.listen(1)
-print 'O servidor esta pronto'
-while 1:
-	#Quando o cliente bate a essa porta, o programa chama o metodo accept() para serverSocket,
-        #que cria um novo socket no servidor, chamado connectionSocket, dedicado a esse cliente
-        #especifico. Cliente e servidor, entao, completam a apresentacaoo, criando uma conexao TCP
-        #entre o clientSocket do cliente e o connectionSocket do servidor.
-	connectionSocket, addr = serverSocket.accept()
-	message = connectionSocket.recv(1024)
-        print message
-	messageMaiuscula = message.upper()
-	connectionSocket.send(messageMaiuscula)
-	connectionSocket.close() </syntaxhighlight>
-#No terminal da máquina execute o programa: <code>
-python TCPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal.
-#Pode-se testar se a porta está aberta: <code>
- nmap -p33333 ip_do_servidor </syntaxhighlight>
-#Qual o estado dessa porta? Cite e justifique o tipo de serviço.
-#Abra um '''novo terminal''' e escreva o programa cliente. TCPClient.py <code>
-from socket import *
-serverName = 'ip_do_servidor'
-serverPort = 33333
-#SOCK_STREAM habilita uso do TCP
-clientSocket = socket(AF_INET, SOCK_STREAM)
-#Representa o estabelecimento da conexao. E o "aperto de maos", onde o cliente e servidor trocam
-#informacoes da portas que serao utilizadas pela conexao (socket) propriamente dito
-clientSocket.connect((serverName,serverPort))
-message = raw_input('Entre com a sentanca em minuculas: ')
-#Diferentemente do UDP, aqui nao e necessario encaminhar o endereco do servidor, ja que este socket
-#eh uma "tubulacao" direta entre ambos, basta empurrar dados
-clientSocket.send(message)
-modifiedMessage = clientSocket.recv(1024)
-print 'Mensagem do servidor: ', modifiedMessage
-clientSocket.close() </syntaxhighlight>
-#Rode o WireShark. Configure a captura na interface '''''any''''', use o filtro do tipo: '''tcp.port==33333'''.
-#Digite a mensagem que deseja e espere a resposta do servidor. Funcionou?
-#Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando o cliente.
-Perguntas
-#As três primeiras mensagens trocadas apresentam a camada de aplicação, sim ou não? Explique. O que elas significam?
-#Em qual mensagem (número) é que a frase é enviada ao servidor?
-#A mensagem seguinte (quinta) apresenta camada de aplicação? Clique na camada TCP no Wireshark e observe o campo '''Flags: 0x010 (ACK)'''. O que você acha que isso significa?
-#Qual o conteúdo da mensagem seguinte (sexta)? E da sétima? Explique.
-#Explique as três últimas mensagens. Dica: olhe as figuras 3.39 e 3.40 do Kurose versão 6.
-#Qual é o protocolo da camada de transporte nessa troca de mensagens?
-#Qual são os números de porta e os IPs utilizados?
-#Quem definiu o número de porta do cliente?
-#Quais foram os números de sequência utilizados em todas as mensagens?
-#Qual o número identificador de protocolo TCP no pacote IP?
-#Quantos ''socktes'' foram abertos no servidor com um cliente "conectado"? E com dois clientes?
-#Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente.
-#Capture todos os pacotes trocados, entre você e seu vizinho. Os números de portas e IPs são ou não iguais?
-Comparativo.
-#Quantas mensagens foram trocadas entre o servidor e cliente em cada um dos protocolos, UDP e TCP, para atingir o mesmo objetivo?
-#Discuta outras diferenças observadas entre os protocolos UDP e TCP.
 ===Desafios para casa===
@@ Linha 694: / Linha 746: @@
 ===Objetivos===
-O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP.
+*O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP.
+*Ambos protocolos de transporte podem ser usados por aplicações que precisem se comunicar. Porém cada um deles têm certas propriedades, então a escolha precisa ser realizada baseada nas necessidade de comunicação a ser feita pela aplicação.
-Ambos protocolos de transporte podem ser usados por aplicações que precisem se comunicar. Porém cada um deles têm certas propriedades, então a escolha precisa ser realizada baseada no tipo de comunicação a ser feita pela aplicação.
+=== Roteiro ===
-=== Experimento 1 ===
+'''O que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos?'''
-<span style="color: red;">Antes de qualquer experimento deve-se desabilitar algumas funcionalidades do kernel do LINUX, para que os experimentos reflitam a teoria. Caso sua interface de rede não seja a '''eth0''' adapte o comando, caso reiniciar a máquina repita-o:</span>
-<code>sudo ethtool --offload eth0 gso off tso off sg off gro off </syntaxhighlight>
-O que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos?
+O roteiro será executado sobre máquinas virtuais, através do uso do [[Netkit2 | Netkit2]]. É o primeiro contato, por hora não se preocupe muito com ele, somente siga os passos.
-# Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: <syntaxhighlight lang=bash>
+#Em primeiro lugar vamos corrigir uma falha do Netkit2: <syntaxhighlight lang=bash>
-wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/jogo.exe
+wget -4 http://docente.ifsc.edu.br/odilson/RED29004/vmlinux -O /home/aluno/netkit2/fs/vmlinux </syntaxhighlight>
+#Copie o texto abaixo, abra o editor '''Gedit/Pluma''', cole o texto e salve o arquivo em '''/home/aluno/TCPxUDP.conf'''. <syntaxhighlight lang=bash>
+Transmissor[type]=generic
+Receptor[type]=generic
+Sniffer[type]=generic
+Transmissor[eth0]=lan0:ip=10.0.0.1/24
+Receptor[eth0]=lan0:ip=10.0.0.2/24:rate=10000
+Sniffer[eth0]=lan0:ip=10.0.0.3/24 </syntaxhighlight>
+#Digite netKit2 no terminal para executá-lo (o ''link'' por ícone gráfico não está funcionando).
+#Carregue o arquivo com a configuração já salva: <syntaxhighlight lang=bash>
+ File >> Load and Run >> TCPxUDP.conf</syntaxhighlight>
+#*Perceba que abrirá uma janela com três abas inferiores, representando três máquina virtuais criadas pelo Netkit, denominadas: '''Transmissor''', '''Receptor''' e '''Sniffer'''. Cada uma dessas abas é o terminal de configuração de uma das três máquinas virtuais atualmente configuradas no Netkit.
+#No terminal da máquina do VirtualBox ('''NÃO do Netkit''') execute o comando abaixo, para fazer o ''download'' do arquivo a ser usado no experimento. Esse arquivo será salvo num diretório compartilhado com as máquinas no Netkit. <syntaxhighlight lang=bash>
+wget -4 http://docente.ifsc.edu.br/odilson/RED29004/original.txt -O /home/aluno/lab/shared/original.txt </syntaxhighlight>
+#Observe o tamanho do arquivo transferido ... ele deve ter exatamente 6816634 bytes (cerca de 6,6 MB). Você pode fazer isso com o comando '''ls -l /home/aluno/lab/shared/original.txt'''.
+====Transferência utilizando o protocolo '''TCP'''====
+#Execute o tcpdump na '''VM Sniffer'''. Durante o experimento ele ficará capturando pacotes para futura análise com o Wireshark.<syntaxhighlight lang=bash>
+tcpdump -i eth0 tcp port 5555 -s 1024 -U -w /hostlab/shared/SnifferTCP.cap </syntaxhighlight>
+#*<span style="color: blue;">Dica: para copiar textos para os terminais do Netkit, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole clicando sobre a rodinha (''scroll'') do mouse sobre o terminal desejado do Netkit.
+#Vamos simular uma taxa de perdas para tornar o ambiente de simulação um pouco mais próximo a realidade. Para tal vamos utilizar o comando '''tc''' (''Traffic Control'') na máquina '''Transmissor''' executando: <syntaxhighlight lang=bash>
+tc qdisc add dev eth0 root netem loss 20%  </syntaxhighlight>
+#Na máquina '''Receptor''' execute o '''netcat''' ([http://netcat.sourceforge.net/ nc]) (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá um ''socket'' '''TCP''' que ficará aguardando conexão na porta 5555. Os dados recebidos serão salvos (através do direcionamento feito através do símbolo '''>''') em '''arquivoTCP''': <syntaxhighlight lang=bash>
+nc -vvnl 5555 > arquivoTCP </syntaxhighlight>
+#Na máquina '''Transmissor''' também execute o '''netcat''' mas com o objetivo de transmitir o arquivo original.txt para a maquina '''Receptor'''. O tempo gasto na transmissão será medido pelo comando '''time''': <syntaxhighlight lang=bash>
+time nc -vvn 10.0.0.2 5555 < /hostlab/shared/original.txt </syntaxhighlight>
+#Após aproximadamente 2 minutos a transmissão será finalizada. Vai aparecer a mensagem com o tempo gasto no '''Transmissor'''.
+#*Anote o tempo apresentado.
+#Pare a captura de pacotes pelo tcpdump, no terminal da VM '''Sniffer''' digite <Ctrl> + <C>.
+#Execute o WireShark no VirtulBox e abra o arquivo salvo no '''Sniffer''':<syntaxhighlight lang=bash>
+File >> Open >> /home/aluno/lab/shared/SnifferTCP.cap </syntaxhighlight>
+#*Como no o comportamento padrão do Wireshark é redefinir o número de sequência para sempre iniciar em 1 e isso pode atrapalhar nossos experimentos, vamos desabilitar essa funcionalidade: <syntaxhighlight lang=bash>
+Edit >> Preferences >> Protocols >> TCP >> (Desabilite) Relative sequence numbers >> OK </syntaxhighlight>
+#<span style="color: #9966CC;">Verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
+#<span style="color: #9966CC;">Analisando a captura de pacotes do WireShark responda:
+## <span style="color: #9966CC;">Quais as portas origem e destino escolhidas pelo cliente e servidor?
+## <span style="color: #9966CC;">Qual é o número de sequência do primeiro e do último pacote?
+## <span style="color: #9966CC;">Qual é o número de sequência do primeiro e do último ACK?
+## <span style="color: #9966CC;">É possível calcular o tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos ou descreva a maneira de obtenção do valor. Dica: observe e o primeiro e o último número de sequência e faça uma correlação com o tamanho do arquivo.
+## <span style="color: #9966CC;">Qual é o tamanho do último segmento de dados recebido?
+## <span style="color: #9966CC;">Apresente os segmentos do ''3-way handshake'' e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula?
+## <span style="color: #9966CC;">Apresente os segmentos do fechamento de conexão e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula?
+====Transferência utilizando o protocolo '''UDP'''====
+#Execute o tcpdump na '''VM Sniffer'''. Durante o experimento ele ficará capturando pacotes para futura análise com o Wireshark.<syntaxhighlight lang=bash>
+tcpdump -i eth0 udp port 5555 -s 1024 -U -w /hostlab/shared/SnifferUDP.cap </syntaxhighlight>
+#No terminal da máquina do VirtualBox execute o comando abaixo, para fazer o ''download'' dos arquivos a serem usados no experimento. Esse arquivo será salvo num diretório compartilhado com as máquinas no Netkit. <syntaxhighlight lang=bash>
+wget -4 http://tele.sj.ifsc.edu.br/~odilson/RED29004/receptor -O /home/aluno/lab/shared/receptor
+wget -4 http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor -O /home/aluno/lab/shared/transmissor </syntaxhighlight>
+#Na máquina '''Receptor''' acrescente permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash>
+chmod +x /hostlab/shared/receptor
+/hostlab/shared/receptor 5555 > arquivoUDP
 </syntaxhighlight>
-# Observe o tamanho do arquivo transferido ... ele deve ter exatamente 332831416 bytes (cerca de 318 MB). Você pode fazer isso com o comando '''ls -l jogo.exe''', ou executando o gerenciador de arquivos e visualizando as propriedades desse arquivo.
+#Na máquina '''Transmissor''' acrescente permissão de execução:  <syntaxhighlight lang=bash>
-# Escolha um colega para fazer o experimento em que o arquivo será transferido de um computador para o outro. NÃO pode ser na própria máquina. Um será o '''receptor''' e outro o '''transmissor'''.
+chmod +x /hostlab/shared/transmissor </syntaxhighlight>
-# A primeira transferência será feita usando o protocolo TCP da seguinte forma:
+#Inicie a transferência do arquivo: <syntaxhighlight lang=bash>
-#* Execute o WireShark e deixe-o capturando pacotes '''somente''' durante a transferência do arquivo. Como o o comportamento padrão do wireshark é redefinir o número de sequência para sempre iniciar em um e isso pode atrapalhar nossos experimentos, vamos desabilitar essa funcionalidade: <code>
+/hostlab/shared/transmissor 10.0.0.2 5555 < /hostlab/shared/original.txt
-Edit >> Preferences >> Protocols >> TCP >> Desabilite Relative sequence numbers </syntaxhighlight>
-#* No computador '''receptor''' execute o '''netcat''' ('''nc''') (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em '''arquivo''': <syntaxhighlight lang=bash>
-nc -vvnl 5555 > arquivoTCP
 </syntaxhighlight>
-#* No computador '''transmissor''' execute, após o processo do '''receptor''' estar executando: <syntaxhighlight lang=bash>
+#Quando completar a transferência vai aparecer a mensagem no '''Transmissor''': "Levou XXXXX segundos para transmitir XXXXX bytes".
-time nc -vvn ip_do_receptor 5555 < jogo.exe
+#Pare a captura de pacotes pelo tcpdump, no terminal da VM '''Sniffer''' dê um <Ctrl> + <C>.
-</syntaxhighlight>
+#Execute o WireShark e abra o arquivo salvo no '''Sniffer''':<syntaxhighlight lang=bash>
-#* Quando completar a transferência, pare o Wireshark.
+File >> Open >> /home/aluno/lab/shared/SnifferUDP.cap </syntaxhighlight>
-#* Verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
+#<span style="color: #9966CC;">Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
-#* Analisando a captura de pacotes do WireShark responda:
+#<span style="color: #9966CC;">Analisando a captura de pacotes do WireShark responda:
-## Quais as portas origem e destino escolhidas pelo cliente e servidor?
+## <span style="color: #9966CC;">Qual é o identificar do primeiro e do último pacote? Existe?
-## Qual é o identificador do primeiro e do último pacote?
+## <span style="color: #9966CC;">É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP?
-## Qual é o identificador do primeiro e do último ACK?
+# <span style="color: #9966CC;">Compare as transferências feitas com os protocolos TCP e UDP em relação, principalmente, ao tempo gasto para transmitir o arquivo e a integridade de dados.
-## Qual o Tamanho Máximo de Segmento (MSS) escolhidos pelo cliente e servidor na conexão.
-## É possível calcular o tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos ou descreva a maneira de obtenção do valor.
-## Qual é o tamanho do último segmento de dados recebido?
-## Todos os segmentos trocados entre as máquinas contém dados ou alguns são somente de controle? Qual o percentual aproximado de segmentos de controle?
-## Apresente os segmentos do ''3-way handshake'' e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula?
-## Apresente os segmentos do fechamento de conexão e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula?
-# A segunda transferência será feita usando o protocolo UDP:
-#* Execute o WireShark e deixe-o capturando pacotes '''somente''' durante a transferência do arquivo.
-#* No computador '''receptor''' baixe o programa '''receptor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash>
-wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/receptor
-chmod +x receptor
-./receptor 5555 > arquivoUDP
-</syntaxhighlight>
-#* No computador '''transmissor''' baixe o programa '''transmissor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash>
-wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor
-chmod +x transmissor </syntaxhighlight>
-#* Inicie a transferência do arquivo: <code>
-./transmissor ip_do_receptor 5555 < jogo.exe
-</syntaxhighlight>
-#* Quando completar a transferência (vai aparecer a mensagem no '''transmissor''' "Levou XXXXX segundos para transmitir XXXXX bytes), no '''receptor''' digite <CTRL + C>, verifique o tamanho do arquivo recebido.
-#* Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
-#* Analisando a captura de pacotes do WireShark responda:
-## Qual é o identificar do primeiro e do último pacote? Existe?
-## É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP?
-## Há segmentos de controle ou somente segmentos de dados?
-## Qual é o tamanho do último segmento de dados recebido?
-# Compare as transferências feitas com os protocolos TCP e UDP.
 ## O que eles têm em comum?
 ## Que diferenças lhe pareceram mais pronunciadas?
 ## Como isso deve afetar as aplicações que usam esses protocolos?
-==TCP x UDP, parte 2==
+==Desvendando o TCP - Número de Sequência, Controle de Erros, transmissão ''duplex''==
+===Objetivos===
-=== Experimento 2 ===
+*Verificar:
-*Tem como objetivo gerar um gráfico para facilitar a visualização do '''controle de congestionamento''' e a consequente equidade do protocolo TCP.
+**Controle de Erros: Significado de Número de Sequência, ACK
-*Utilizar o software [https://iperf.fr/ Iperf] (iperf –h para help) para gerar tráfego entre duas máquinas, '''cliente''' e '''servidor'''.
+**Controle de Fluxo: Significado do campo Windows Size; Funcionamento do controle de fluxo;
 *Utilizar o software [[netkit2]].
+===Configuração do Laboratório===
+O roteiro será executado sobre máquinas virtuais, através do uso do [[Netkit2 | Netkit2]]. Copie o texto abaixo, abra o editor de sua preferência, cole o texto e salve o arquivo em /home/aluno/TCP.conf.
+<syntaxhighlight lang=bash>
+PC1[type]=generic
+PC2[type]=generic
+PC3[type]=generic
+PC1[eth0]=lan0:ip=10.0.0.1/24
+PC2[eth0]=lan0:ip=10.0.0.2/24
+PC3[eth0]=lan0:ip=10.0.0.3/24
+</syntaxhighlight>
+===PARTE 1 - Transmissão sem erros: Verificação de Número de Sequência e Reconhecimentos===
+#Executar a configuração do laboratório no Netkit. Abra o NetKit2 e abra o arquivo de configuração: <syntaxhighlight lang=bash>
+ File >> Load and Run >> /home/aluno/TCP.conf </syntaxhighlight>
+#*Perceba que abrirá uma janela com três abas inferiores, representando três máquina virtuais criadas pelo Netkit, denominadas: PC1, PC2 e PC3. Cada uma dessas abas é o terminal de configuração da respectiva máquina virtual.
+#Utilize o editor de texto da máquina real, inclua o texto abaixo, e salve como '''/home/aluno/lab/shared/arq.tx''' <syntaxhighlight lang=bash>
+ABCDEFGHIJKLMNOPQRSTUVXZW1234 </syntaxhighlight>
+#Execute o tcpdump no PC3.
+#*<span style="color: blue;">Dica: para copiar textos para o Netkit, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole clicando sobre a rodinha (''scroll'') do mouse. <syntaxhighlight lang=bash>
+  tcpdump -i eth0 tcp port 5555 -s 1024 -U -w /hostlab/shared/TCP_sem_erros.cap </syntaxhighlight>
+#Execute o processo servidor no PC2 e prepare o mesmo para limitar a sua capacidade de recepção em cerca de 20 bytes (tamanho do buffer). Isto permitirá ver a quebra do arquivo de 30 bytes em alguns segmentos TCP<syntaxhighlight lang=bash>
+sysctl -w net.ipv4.tcp_rmem='20 20 20'
+nc -l 5555 > arq.rx </syntaxhighlight>
+#Envie o arquivo arq.tx a partir do PC1 <syntaxhighlight lang=bash>
+  nc 10.0.0.2 5555 < /hostlab/shared/arq.tx </syntaxhighlight>
+#No PC3 faça CTRL-C, para parar a caprtura de pacotes.
+#Abra o arquivo TCP_sem_erros.cap (/home/aluno/lab/shared/TCP_sem_erros.cap) com o Wireshark da máquina do VirtualBox. Você terá algo parecido com o apresentado na Figura 1. [[Arquivo:WiresharkTCPPerdaDePacotes.png |thumb | 600px| Fig.1 -- Protocolo TCP]]
+#Analise como os dados foram transmitidos e reconhecidos.
+#<span style="color: #9966CC;">Perguntas
+##Qual o número de sequência (normalizado pelo Wireshark) de cada segmento de dados transmitido (de PC1 para PC2) e qual o significado do número de reconhecimento em cada um deles?
+##Como foi reconhecido cada segmento enviado?
+##*Relate esta análise por segmento usando os ''timestamps'' como referência.
+===PARTE 2 - Transmissão com erros: retransmissões===
+#Repetir todo a parte 1 mas substituir o item 3 por:<syntaxhighlight lang=bash>
+  tcpdump -i eth0 tcp port 5555 -s 1024 -U -w /hostlab/shared/TCP_com_erros.cap </syntaxhighlight>
+#E o item 4 por: <syntaxhighlight lang=bash>
+sysctl -w net.ipv4.tcp_rmem='20 20 20'
+tc qdisc add dev eth0 root netem loss 50%
+nc -l 5555 > arq.rx </syntaxhighlight>
+#<span style="color: #9966CC;">Perguntas:
+##Qual o número de sequência (normalizado pelo Wireshark) de cada segmento de dados transmitido (de PC1 para PC2) e qual o significado do número de reconhecimento em cada um deles?
+##Como foi reconhecido cada segmento enviado?
+##Houve perda de pacotes? Como você identificou isso?
+##Os pacotes perdidos foram retransmitidos? Justifique.
+===PARTE 3 - Testando a capacidade do TCP de enviar dados de forma duplex===
+*Agora vamos fazer um pequeno teste de transmissão de arquivos entre dois colegas e observar o comportamento ''full-duplex''.
+*No experimento, o arquivo de uma máquina será transmitido para outra e vice-versa.
+#Feche no Netkit2, se estiver aberto. Isso é para limpar as configurações previamente feitas.
+#Abra novamente o Netkit2 e carregue o aquivo TCP.conf, Parte 1.
+#Limite o tamanho do ''buffer'' do TCP tanto no '''PC1''' quanto '''PC2''': <syntaxhighlight lang=bash>
+sysctl -w net.ipv4.tcp_rmem='10000 10000 10000' </syntaxhighlight>
+#Num terminal da máquina do Virtualbox baixe os arquivos para o experimento e salve-os no diretório compartilhado com o Netkit2: <syntaxhighlight lang=bash>
+wget -4 http://docente.ifsc.edu.br/odilson/RED29004/Servidor.tx -O /home/aluno/lab/shared/Servidor.tx
+wget -4 http://docente.ifsc.edu.br/odilson/RED29004/Cliente.tx -O /home/aluno/lab/shared/Cliente.tx </syntaxhighlight>
+#No PC3 inicie a captura de pacotes: <syntaxhighlight lang=bash>
+tcpdump -i eth0 tcp port 5555 -s 1024 -U -w /hostlab/shared/fullduplex.cap </syntaxhighlight>
+#No PC1, que fará o papel de servidor por aguardar a conexão do cliente, execute o comando abaixo. Perceba que o Servidor vai enviar (o sinal '''<''' indica isso) um arquivo e vai receber e salvar (o sinal '''>''' indica isso) outro do Cliente. <syntaxhighlight lang=bash>
+nc -l 5555 < /hostlab/shared/Servidor.tx > Arq_recebido.rx </syntaxhighlight>
+#No PC2, que fará o papel de cliente, execute o comando abaixo. Perceba que ele também vai enviar e receber arquivo do servidor. <syntaxhighlight lang=bash>
+nc 10.0.0.1 5555 < /hostlab/shared/Cliente.tx > Arq_recebido.rx </syntaxhighlight>
+#Confira o conteúdo dos arquivos recebidos no PC1 e PC2: <syntaxhighlight lang=bash>
+cat Arq_recebido.rx </syntaxhighlight>
+#Pare a captura de pacotes no PC3 com <Ctrl> + <C>.
+#Execute o Wireshark e confira a troca de pacotes abrindo o arquivo salvo: <syntaxhighlight lang=bash>
+File >> Open >> /home/aluno/lab/shared/fullduplex.cap </syntaxhighlight>
+<span style="color: #9966CC;">Perguntas:
+#<span style="color: #9966CC;">Onde pode ser observado a comunicação ''full-duplex''?
+#<span style="color: #9966CC;">Qual é a relação entre os comandos no terminal tanto do cliente como do servidor com a comunicação ''full-duplex''?
+#<span style="color: #9966CC;">Como os ACKs são propagados, em pacotes exclusivos ou de carona (''piggyback'') com os dados?
+==TCP: Controle de congestionamento e equidade==
+=== Objetivos ===
+*Visualização, através de gráficos, do '''controle de congestionamento''' e a consequente '''equidade''' do protocolo TCP.
+*Visualização, através de gráficos, da disputa por banda entre os protocolos TCP e UDP.
+*Utilização do software [https://iperf.fr/ Iperf] (iperf –h para help) para gerar tráfego entre duas máquinas - '''cliente''' e '''servidor''' - e permitir a observação do comportamento da disputa de banda.
+*Utilização do software [[netkit2]] para simulação de redes "complexas".
+===Parte 1: Somente fluxos TCP===
 *O roteiro será executado sobre máquinas virtuais, através do uso do [[Netkit2 | Netkit2]].
 *Para realização dos ensaios será montada a rede virtual apresentada na Figura 1.
-[[Arquivo:TCP_Rede_Controle_de_Fluxo.png |thumb | 200px| Figura 1 - Rede ara testes]]
+[[Arquivo:TCP_Rede_Controle_de_Fluxo.png |thumb | 200px| Figura 1 - Rede para testes]]
 #Copie o texto abaixo e crie um arquivo, salve-o como /home/aluno/TCP.conf.
-<code>
+<syntaxhighlight lang=bash>
 # Definição das máquinas
 R1[type]=router
@@ Linha 788: / Linha 948: @@
 PC3[eth0]=lan1:ip=10.0.1.3/24:rate=10000
 </syntaxhighlight>
-#Abra o NetKit2.
+#Execute o NetKit2.
-#Abra o arquivo de configuração: <code>
+#Carregue o arquivo de configuração: <syntaxhighlight lang=bash>
-  File > Load and Run </syntaxhighlight>
+  File >> Load and Run >> /home/aluno/TCP.conf</syntaxhighlight>
 #*Perceba que abrirá uma janela com quatro abas inferiores, representando um roteador e três máquina virtuais criadas pelo Netkit, denominadas: R1, PC1, PC2 e PC3. Cada uma dessas abas é o terminal de configuração do respectivo equipamento.
 #*Ao clicar no menu '''File - Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
-#Execute no PC3 o tcpdump para salvar a troca de dados entre o PC1 e o PC2 num arquivo: <code>
+#Execute no PC3 o tcpdump para salvar a troca de dados entre o PC1 e o PC2 num arquivo: <syntaxhighlight lang=bash>
-tcpdump -i eth0 -w /hostlab/shared/pc3.cap </syntaxhighlight>
+tcpdump -i eth0 -w /hostlab/shared/FluxosTCP.cap </syntaxhighlight>
-#*Copie o texto acima e, no Netkit, selecione o R1 e clique sobre a "rodinha" do mouse que o texto será colado.
+#*Para copiar comando para os terminais das máquinas virtuais: copie o texto desejado, no Netkit selecione o terminal da máquina desejada e clique sobre a "rodinha" do mouse que o texto será colado.
-#No PC1 (servidor) execute: <code>
+#No PC1 (servidor) execute: <syntaxhighlight lang=bash>
 iperf -s -p 2000 & iperf -s -p 2001 & iperf -s -p 2002 & </syntaxhighlight>
-#No PC2 (cliente) execute: <code>
+#No PC2 (cliente) execute (copie a três linhas e cole no terminal adequado e em seguida tecle <Enter>): <syntaxhighlight lang=bash>
-iperf -c 10.0.0.1 -f m -i 1 -t 90 -p 2000 -l 1300 & (sleep 20; iperf -c 10.0.0.1 -f m -i 1 -t 70 -p 2001 -l 1300) & (sleep 30; iperf -c 10.0.0.1 -f m -i 1 -t 60 -p 2002 -l 1300) & </syntaxhighlight>
+iperf -c 10.0.0.1 -f m -i 1 -t 90 -p 2000 -l 1300 & \
-#Fique monitorando o PC2 até a tela parar de ser atualizada, aproximadamente 90 s. Pare os processos nos três PCs utilizando CTRL-C.
+(sleep 20; iperf -c 10.0.0.1 -f m -i 1 -t 70 -p 2001 -l 1300) & \
+(sleep 30; iperf -c 10.0.0.1 -f m -i 1 -t 60 -p 2002 -l 1300) & </syntaxhighlight>
+#Fique monitorando o PC2 até a tela parar de ser atualizada, aproximadamente 90 s.
+#Pare os processos nos três PCs utilizando CTRL-C.
 #Abra o Wireshark.
-#Abra o arquivo <code>
+#Abra o arquivo <syntaxhighlight lang=bash>
-File > Open > /home/aluno/lab/shared/pc3.cap </syntaxhighlight>
+File >> Open >> /home/aluno/lab/shared/FluxosTCP.cap </syntaxhighlight>
-#No wireshark acesse '''Statistics''' >> '''IO Graph''' e, na tela que abrir, ajuste TODOS os parâmetros para obter um gráfico similar ao apresentado na Figura 2.
+#No wireshark acesse '''Statistics''' >> '''IO Graph''' e, na tela que abrir, ajuste TODOS os parâmetros para obter um gráfico similar ao apresentado na Figura 2:  [[Arquivo:TCP_Wireshark.png |thumb | 400px| Figura 2 - Captura de 3 fluxos de dados]]
-#*Perceba que todos os botões '''Graph 1...4''' devem ser clicados,  e os filtros aplicados (tcp.port==2000; tcp.port==2001; tcp.port==2002) isso fará com que o Wireshark mostre as respectivas curvas.
+##Clique em '''Add a new graph''' (sinal de + no canto inferior esquerdo)
+##* X Enabled
+##* Duplo clique sobre o campo '''Graph name''': Porta 2000
+##* Duplo clique sobre o campo '''Display Filter''': tcp.port==2000
+##* Duplo clique sobre o campo '''Color''': clique no botão logo a direita e selecione a cor desejada.
+##Para os demais gráficos copie o anterior clicando no ícone com dois retângulos no canto inferior esquerdo
+##* Edite nome, porta e cor.
+#<span style="color: #9966CC;">Salve esse gráfico no relatório.
+#<span style="color: #9966CC;">Responda:
+##Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor.
+##Explique os filtros aplicados no gráfico do Wireshark.
+##*Quais são os 4 gráficos apresentados?
+##*Há uma relação de valor entre as curvas?
+##*Qual é esta relação?
+##Por que a curva vermelha se sobrepõe a curva preta nos primeiros 20 segundos? Considere o início do tempo onde há início de tráfego!
+##Qual é a relação entre a curva preta e as curvas vermelha e verde no intervalo entre 20 e 30 segundos?
+##Explique a relação entre as 4 curvas e o comando do cliente no intervalo entre 20 e 40 segundos.
+##Qual é o mecanismo do TCP que explica a grande oscilação das curvas, principalmente percebida no intervalo entre 20 e 30 segundos?
+===Parte 2: Fluxos TCP mais UDP===
+Agora vamos dificultar a vida do TCP incluindo um tráfego UDP. O gráfico gerado deverá apresentar a competição pelo meio de transmissão entre os diversos fluxos de dados.
+#Deslique o NetKit2, para limpar todos os processos e ''buffers'': <syntaxhighlight lang=bash>
+File >> Quit </syntaxhighlight>
+#Copie o texto abaixo e crie um arquivo, salve-o como /home/aluno/TCPxUDP.conf: <syntaxhighlight lang=bash>
+# Definição das máquinas
+R1[type]=router
+PC1[type]=generic
+PC2[type]=generic
+PC3[type]=generic
+PC4[type]=generic
+# Definição dos roteadores padrão
+PC1[default_gateway]=10.0.0.254
+PC2[default_gateway]=10.0.1.254
+PC3[default_gateway]=10.0.1.254
+PC4[default_gateway]=10.0.1.254
+# Definição das interfaces do roteador
+R1[eth0]=lan0:ip=10.0.0.254/24:rate=10000
+R1[eth1]=lan1:ip=10.0.1.254/24:rate=10000
+# Definição das interfaces dos PCs
+PC1[eth0]=lan0:ip=10.0.0.1/24:rate=10000
+PC2[eth0]=lan1:ip=10.0.1.2/24:rate=10000
+PC3[eth0]=lan1:ip=10.0.1.3/24:rate=10000
+PC4[eth0]=lan1:ip=10.0.1.4/24:rate=10000 </syntaxhighlight>
+#Execute o NetKit2 e carregue o arquivo de configuração.
+#No PC4 execute: <syntaxhighlight lang=bash>
+tcpdump -i eth0 -w /hostlab/shared/FluxosTCP+UDP.cap </syntaxhighlight>
+#No PC1 execute: <syntaxhighlight lang=bash>
+iperf -s -u -p 2000 & iperf -s -p 2001 & </syntaxhighlight>
+#A próxima etapa deve ser executada "simultaneamente" nos PC2 e PC3.
+##Para isso copie o texto abaixo e cole no terminal do PC2, ainda NÃO tecle <Enter>: <syntaxhighlight lang=bash>
+iperf -u -c 10.0.0.1 -f m -i 1 -t 60 -p 2000 -l 1300 -b 10000000 </syntaxhighlight>
+##Copie o texto abaixo e cole no terminal do PC3, ainda NÃO tecle <Enter>: <syntaxhighlight lang=bash>
+iperf -c 10.0.0.1 -f m -i 1 -t 90 -p 2001 -l 1300 </syntaxhighlight>
+##Tecle <Enter> no PC3 e PC2, NESSA ORDEM, "simultaneamente".
+#Fique monitorando o PC3 a tela parar de ser atualizada, aproximadamente 90 s.
+#Pare os processos nos quatro PCs utilizando CTRL-C.
+#Execute o Wireshark e abra o arquivo /home/aluno/lab/shared/FluxosTCP+UDP.cap.
+#Edite as configurações do gráfico e deixe parecido com o da Figura 3.
+#*No '''Graph 2''' altere o filtro para '''udp.port==2000'''.
+#*No '''Graph 3''' altere o filtro para '''tcp.port==2001'''. [[Arquivo:TCPxUDP_Wireshark.png |thumb | 400px| Figura 3 - Captura de 2 fluxos de dados: TCP e UDP]]
+#<span style="color: #9966CC;">Salve o gráfico no relatório.
+#<span style="color: #9966CC;">Responda:
+##Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor.
+##Qual a relação dos filtros aplicados no gráfico e os comandos executados no terminal.
+##*Quais são os 4 gráficos apresentados?
+##*Há uma relação de valor entre as curvas?
+##*Qual é esta relação?
+##Qual é a relação entre a curva preta e as curvas vermelha e verde no intervalo até por volta de 60 segundos?
+##O que ocorreu com o gráfico verde após os 60 segundos. O que explica esse comportamento?
+##Explique o gráfico azul, em barras.
+#<span style="color: #9966CC;">Compare o comportamento dos vários fluxos de dados, nos dois experimentos, '''com e sem o UDP'''.
-[[Arquivo:TCP_Wireshark.png |thumb | 400px| Figura 2 - Captura de 3 fluxos de dados]]
+==Interligação de duas redes através de um roteador==
+===Objetivos===
-Responda:
+*Introdução ao mundo IP
-#Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor.
+*Verificação das configurações de interfaces de rede
-#Explique os filtros aplicados no gráfico do Wireshark.
+*Verificação de tabelas de roteamento nos hospedeiros e no roteador
-##Quais são os 4 gráficos apresentados?
+*Verificação de movimentação de pacotes (rotas) em roteadores
-##Há uma relação de valor entre as curvas?
-##Qual é esta relação?
-#Por que a curva vermelha se sobrepõe a curva preta nos primeiros 20 segundos? Considere o início do tempo onde há início de tráfego!
-#Qual é a relação entre a curva preta e as curvas vermelha e verde no intervalo entre 20 e 30 segundos?
-#Explique a relação entre as 4 curvas e o comando do cliente no intervalo entre 20 e 40 segundos.
-#Qual é o mecanismo do TCP que explica a grande oscilação das curvas, principalmente percebida no intervalo entre 20 e 30 segundos?
-=====Incluindo UDP=====
+===Fonte Base===
-Agora vamos dificultar a vida do TCP incluindo um tráfego UDP. O gráfico gerado deverá apresentar a competição pelo meio de transmissão entre os diversos fluxos de dados.
+*[http://docente.ifsc.edu.br/odilson/RED29004/MACxIP.pdf Endereçamento MAC x Endereçamento IP]
-#No PC3 execute: <code>
-tcpdump -i eth0 -w /hostlab/shared/pc3.cap </syntaxhighlight>
-#No PC1 execute: <code>
-iperf -s -p 2000 & iperf -s -p 2001 & iperf -s -u -p 2002 & </syntaxhighlight>
-#No PC2 execute: <code>
-iperf -c 10.0.0.1 -f m -i 1 -t 90 -p 2000 -l 1300 & (sleep 20; iperf -c 10.0.0.1 -f m -i 1 -t 70 -p 2001 -l 1300) & (sleep 30; iperf -u -c 10.0.0.1 -f m -i 1 -t 60 -p 2002 -l 1300) & </syntaxhighlight>
-#Fique monitorando o PC2 a tela parar de ser atualizada, aproximadamente 90 s. Pare os processos nos três PCs utilizando CTRL-C.
-#Baseado na Figura 2, no '''Graph 4''' altere o filtro para '''udp.port==2002'''. Salve o gráfico gerado.
-#Responda as mesmas questões do item anterior, '''todas'''.
-#Compare o comportamento dos vários fluxos de dados com e sem o UDP.
-=== Experimento 3 (opcional) ===
+===Procedimento===
-Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste terceiro experimento, serão feitas transferências simultâneas de arquivos a partir de um mesmo servidor, comparando-se o resultado obtido com TCP e UDP. Essas transferência ocorrerão entre os computadores do laboratório e um servidor externo ao laboratório.
+#Construir uma rede no Netkit com quatro PCs e um roteador. Com o editor de texto copie o conteúdo abaixo e salve no arquivo '''/home/aluno/roteador.conf''': <syntaxhighlight lang=text>
+r1[type]=router
+pc1[type]=generic
+pc2[type]=generic
+pc3[type]=generic
+pc4[type]=generic
+r1[eth0]=lan0:ip=192.168.200.254/24
+r1[eth1]=lan1:ip=192.168.100.254/24
+pc1[eth0]=lan0:ip=192.168.200.1/24
+pc1[default_gateway]=192.168.200.254
+pc2[eth0]=lan0:ip=192.168.200.2/24
+pc2[default_gateway]=192.168.200.254
+pc3[eth0]=lan1
+pc4[eth0]=lan1:ip=192.168.100.2/24
+pc4[default_gateway]=192.168.100.254 </syntaxhighlight>
+#Rodar o netkit2.
+#Carregar o arquivo '''roteador.conf''' a partir do Netkit2:<syntaxhighlight lang=bash>
+File >> Load and Run </syntaxhighlight>
+#Visualizar a rede a ser implementada:<syntaxhighlight lang=bash>
+File >> Graph </syntaxhighlight>
+#*Observe que a rede é composta de 4 PCs ('''pc1''' - '''pc4''') e 1 roteador ('''r1'''). O roteador possui duas interfaces de rede que interliga as duas sub-redes.
+#<span style="color: #9966CC;">Anotar os endereços de hardware (ou MAC) e IP de cada dispositivo na rede. No terminal de cada PC execute: <syntaxhighlight lang=bash>
+ifconfig </syntaxhighlight>
+#<span style="color: #9966CC;">Observar, interpretar e anotar a tabela de roteamento nos hospedeiros '''pc1''' e '''pc4'''. Identificar os ''default gateways'' em cada PC.<syntaxhighlight lang=bash>
+route -n </syntaxhighlight>
+#<span style="color: #9966CC;">Observar, interpretar e anotar a tabela de roteamento no roteador ('''r1''')<syntaxhighlight lang=bash>
+exit
+route -n </syntaxhighlight>
+#<span style="color: #9966CC;">Observar, "provar" e anotar que pacotes indo do '''pc1''' para '''pc2''' na '''lan0''' são enviados diretamente para '''pc2''', ou seja, entrega direta. Explique a entrega direta.
+#*Use o '''ping''', '''tcpdump''' e seu diagrama de rede como apoio.
+#*Lembre-se que você pode verificar o fluxo de dados individualmente em cada interface de rede e, portanto, se certificar que se há ou não pacotes atravessando o roteador:
+#**Deixe o ping entre '''pc1''' e '''pc2''', em '''pc1''' execute:<syntaxhighlight lang=bash>
+ping 192.168.200.2</syntaxhighlight>
+#**Num primeiro momento em '''r1''':<syntaxhighlight lang=bash>
+exit
+tcpdump -i eth0 -n -e </syntaxhighlight>
+#**Em seguida, ainda em '''r1''': <syntaxhighlight lang=bash>
+tcpdump -i eth1 -n -e </syntaxhighlight>
+#**Ver: [http://www.tcpdump.org/tcpdump_man.html manpage do tcpdump]
+#<span style="color: #9966CC;">Observar, "provar" e anotar que pacotes indo de '''pc1''' para '''pc4''' são encaminhados ao roteador e, em seguida, entregues ao destino, ou seja, entrega indireta. Explique a entrega indireta.<span style="color: black;">
-# Todos devem executar este procedimento ao mesmo tempo. Abra um terminal em seu computador, e nele execute este comando, '''só tecle <Enter> quando o professor determinar''': <syntaxhighlight lang=bash>
+===Configuração básica de interface de rede===
-wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/arq2.iso
+#No '''pc3''' teste a conectividade com os demais '''pcs''', por exemplo, fazendo ''pings'' para o '''pc1''' e '''pc4''': <syntaxhighlight lang=bash>
-</syntaxhighlight>
+ping 192.168.200.1
-# Observe a taxa de transferência (velocidade do download) obtida. Que valores ela apresenta?  Quanto tempo levou para o arquivo ser transferido?
+ping 192.168.100.2</syntaxhighlight>
-# Após todos terem copiado o arquivo, o professor irá repetir a transferência, porém desta vez ele irá fazê-la sozinho. Que taxas ele obteve, e quanto tempo levou?
+#*Perceba que não há conectividade, não há resposta aos ''pings'', dado que a interface de rede do '''pc3''' não está devidamente configurada.
-# O professor irá repetir a transferência novamente, mas desta vez ele irá pedir que um aluno também a inicie logo em seguida. Qual foi a taxa obtida por ambos?
+#Assim sendo, configure a interface de rede no '''pc3'''.
-# Para poder fazer uma comparação, as transferências serão feitas novamente porém usando UDP como protocolo de transporte. Para isso siga estes passos:
+#*<span style="color: #9966CC;"> Anote todos os comandos executados.
-## Abra dois terminais. No '''terminal 1''' execute este comando: <syntaxhighlight lang=bash>
+#*O mesmo deverá ser capaz de "pingar" para qualquer outro PC ou ser "pingado".
-watch -n 1 ls -l arquivo
+#*Dicas:
-</syntaxhighlight> ... e no '''terminal 2''': <syntaxhighlight lang=bash>
+#*#Observe a configuração de rede do '''pc4''', que está na mesma sub-rede, e tente adaptá-la para o '''pc3'''.
-./receptor 5555 > arquivo
+#*#Utilize ferramentas de configuração '''ifconfig''' e '''route'''. Use o '''man''' ou procure na web como utilizar esses comandos.
-</syntaxhighlight>
+#Execute o comando ping do '''pc3''' para o '''pc4'''. Obteve sucesso? Se não corrija as configurações.
-## Fique observando o '''terminal 1'''.
+#Execute o comando ping do '''pc3''' para o '''pc1'''. Obteve sucesso? Se não corrija as configurações.
-## O professor irá transmitir o arquivo, um processo para cada aluno.
+#Execute o comando ping do '''pc2''' para o '''pc3'''. Obteve sucesso? Se não corrija as configurações.
-##*konsole
-##*abrir várias abas
-##*n vezes ./transmissor ip_do_receptor 5555 < jogo.exe
-## No '''terminal 1''' observe o tamanho do arquivo, que deverá aumentar gradativamente. Monitore manualmente o tempo em segundos até o tamanho do arquivo parar de crescer (relógio, celular ou relógio do computador).
-## Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? O tamanho do arquivo recebido é o mesmo do arquivo original?
-## Faça um comparativo das transferências usando TCP e UDP.
-==== Tarefa extra (pode ser em casa)====
+====Referências adicionais====
-Use o aplicativo '''NetCat''' (nc) para fazer transferências UDP e responda (utilize o '''man''' para os comandos, boa parte da respostas estão lá):
+* [http://linux-ip.net/html Guia de Administração da Camada IP no Linux
-#Qual o procedimento no lado transmissor e receptor?
-#Consegue-se medir o tempo de maneira automática? Por que sim ou por que não?
-#Por que os processos não param ao final da transferência como no '''experimento 1'''?
-==Protocolos de roteamento==
+==Tabelas Estáticas de Roteamento==
 ===Objetivos===
-*Analisar o funcionamento de protocolos de roteamento estático e dinâmico da Internet a partir de uma estrutura física formada por roteadores e redes locais:
+*Analisar o funcionamento de roteadores com tabelas estáticas de roteamento.
-**tabelas estáticas de roteamento
+*Verificar a entrega direta e indireta de pacotes.
-**os protocolo RIP e OSPF.
+*Analisar ''loops'' em rede.
 Para atingir tais objetivos utilizaremos o [[netkit2]]. Leia o [http://wiki.sj.ifsc.edu.br/index.php/Netkit2#Roteadores tutorial] de como o '''netkit2''' trabalha com roteadores.
+[http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%204%20A%20camada%20de%20REDE.pdf Kurose Cap. 4]: slides 1-25, 29-35 e 57-62
+===Arquitetura de rede===
 Em todos os experimentos será utilizado como base a seguinte arquitetura de rede:
 [[Arquivo:DynamicRoutingTriangle.png]]
-===Experimento 1: tabelas estáticas de roteamento===
+===Tabelas estáticas de roteamento===
-#Crie em seu computador um arquivo com nome '''/home/aluno/exp1.conf''', com o seguinte conteúdo: <code> # Hosts definitions
+#Crie em seu computador um arquivo com nome '''/home/aluno/rot1.conf''', com o seguinte conteúdo: <syntaxhighlight lang=bash>
+# Hosts definitions
 pc1[type]=generic
 pc2[type]=generic
@@ Linha 909: / Linha 1 170: @@
 r3[eth1]=backbone1:ip=10.0.1.2/30
 r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
-#Rode o '''netKit''' em seu computador. Em um terminal digite: <code> netkit2 & </syntaxhighlight>
+#Rode o '''netKit''' em seu computador. Em um terminal digite: <syntaxhighlight lang=bash> netkit2 & </syntaxhighlight>
-#No menu '''File - Load and Run''', procure o arquivo '''/home/aluno/exp1.conf''' e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3.
+#No menu '''File - Load and Run''', procure o arquivo '''/home/aluno/rot1.conf''' e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3.
 #Ao clicar no menu '''File - Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
-#Nos três roteadores rode os seguintes comandos para inibir a filtragem de pacotes com rotas incompletas (copie o texto abaixo e cole nos respectivos terminas, com um ''click'' sobre a rodinha do mouse): <code>
+#Nos três roteadores rode os seguintes comandos para inibir a filtragem de pacotes com rotas incompletas (copie o texto abaixo e cole nos respectivos terminas, com um ''click'' sobre a rodinha do mouse): <syntaxhighlight lang=bash>
 echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
 echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
@@ Linha 918: / Linha 1 179: @@
 echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter </syntaxhighlight>
 #Testes de conectividade de enlace e configuração do ''default gateway''.
-##Por exemplo, no '''pc1''' execute o comando: <code> ping 192.168.0.254 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
+##Por exemplo, no '''pc1''' execute o comando: <syntaxhighlight lang=bash> ping 192.168.0.254 </syntaxhighlight> <span style="color: #9966CC;"> Obteve sucesso? Sim ou não e por quê?
-##Teste a conectividade do '''pc1''' executando o comando: <code> ping 10.0.0.1 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
+##Teste a conectividade do '''pc1''' executando o comando: <syntaxhighlight lang=bash> ping 10.0.0.1 </syntaxhighlight> <span style="color: #9966CC;"> Obteve sucesso? Sim ou não e por quê?
-##Por exemplo, no '''pc1''' execute o comando: <code> ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
+##Por exemplo, no '''pc1''' execute o comando: <syntaxhighlight lang=bash> ping 10.0.0.2 </syntaxhighlight> <span style="color: #9966CC;"> Obteve sucesso? Sim ou não e por quê?
-##Configure o roteador padrão em todos os PCs, por exemplo no '''pc1''': <code> route add -net default gw 192.168.0.254 </syntaxhighlight>
+##Configure o roteador padrão em todos os PCs, por exemplo no '''pc1''': <syntaxhighlight lang=bash> route add -net default gw 192.168.0.254 </syntaxhighlight>
-##Teste novamente a conectividade, no '''pc1''' execute o comando: <code> ping 10.0.0.1 </syntaxhighlight> e <code> ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? O comportamento foi o mesmo dos iten 6.2 e 6.3? Sim ou não e por quê?
+##Teste novamente a conectividade, no '''pc1''' execute o comando: <syntaxhighlight lang=bash> ping 10.0.0.1 </syntaxhighlight> e <syntaxhighlight lang=bash> ping 10.0.0.2 </syntaxhighlight> <span style="color: #9966CC;">Obteve sucesso? O comportamento foi o mesmo dos iten 6.2 e 6.3? Sim ou não e por quê?
-##Com os ping do item anterior ativos (um a cada tempo) rode o '''wireshark''' no '''r1''' (clique na aba '''r1''' e em seguida no menu '''wireshark any'''. Observe que ao usar o wireshark com o Netkit, o wireshark não é dinâmico, ou seja, de tempos em tempos deves recarregar (''reload'' <CTRL>+<R>) a captura de pacotes).
+##Com os ping do item anterior ativos (um a cada tempo) rode o '''wireshark''' no '''r1''' (clique na aba '''r1''' e em seguida no menu '''wireshark any''').
-###Qual a origem e destino dos pacotes? Por quê?
+###<span style="color: #9966CC;">Qual a origem e destino dos pacotes? Por quê?
-###Qual a diferença no ping entre os dois itens?
+###<span style="color: #9966CC;">Qual a diferença no ping entre os dois itens?
-##*Obs: Uma opção ao '''wireshark''' é o [http://www.tcpdump.org/ tcpdump] que permite que se grave todo o tráfego de pacotes para posterior análise, sem influenciar no funcionamento dos experimentos. O arquivo gravado é compatível com o '''wireshark''', ou seja, pode-se abrir um arquivo gravado com o '''tcpdump''' no '''wireshark'''. Por exemplo, para iniciar a captura de pacotes em todas as interfaces de '''r1''', utilize o seguinte comando (atenção ao "&" no final que envia o '''tcpdump''' para ''background'', permitindo o uso normal do terminal): <code> tcpdump -i any -w /hostlab/r1.pcap & </syntaxhighlight> '''Ao final do experimento''', antes de fechar o Netkit, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''. Os arquivos '''.pcaps''' gerados ficam na pasta /home/aluno/lab, no exemplo '''r1.pcap'''. Ao clicar sobre o mesmo, automaticamente será aberto o '''wireshark'''.
 #Iniciando o roteamento.
-##Deixe o '''ping''' do item 6.3 e o '''wireshark''' (ou '''tcpdump''') do item 6.6 rodando e estabeleça uma rota no roteador '''r2''' com o comando: <code> route add -net 192.168.0.0/24 gw 10.0.0.1 </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê?
+##Deixe o '''ping''' do item 6.3 e o '''wireshark''' do item 6.6 rodando e estabeleça uma rota no roteador '''r2''' com o comando: <syntaxhighlight lang=bash> route add -net 192.168.0.0/24 gw 10.0.0.1 </syntaxhighlight> <span style="color: #9966CC;"> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê?
 ##* Interpretando o comando: route add (adiciona rota) -net 192.168.0.0/24 (para a rede 192.168.0.0/24) gw 10.0.0.1 (utilizando a interface 10.0.0.1, enlace direto, do roteador r1).
-##Em todos os roteadores crie rotas para todas as redes. Em cada roteador deve-se criar 3 rotas, para as sub-redes "distantes". Lembre-se que os enlaces diretos já criam automaticamente rotas para as respectivas sub-redes, diretamente conectadas ao equipamento. Se tudo estiver correto, '''todos''' os PCs devem pingar entre si. Teste!
+##Em todos os roteadores crie rotas para todas as redes. Em cada roteador deve-se criar 3 rotas, para as sub-redes "distantes". Lembre-se que os enlaces diretos já criam automaticamente rotas para as respectivas sub-redes diretamente conectadas ao equipamento, ou seja, entrega direta. Se tudo estiver correto, '''todos''' os PCs devem pingar entre si.
+##<span style="color: #9966CC;"> Trace e anote as rotas entre os ''hosts'' através do '''traceroute'''.
 #Testando a queda de enlace.
-##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc1''' para o '''pc3''' e execute '''wireshark any''' no '''r1''' , em seguida "derrube" o enlace entre o '''r1''' e '''r3'''. Por exemplo, no '''r3''' execute o comando: <code> ifconfig eth1 down </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede?
+##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc1''' para o '''pc3''' e execute '''wireshark any''' no '''r1''' , em seguida "derrube" o enlace entre o '''r1''' e '''r3'''. Por exemplo, no '''r3''' execute o comando: <syntaxhighlight lang=bash> ifconfig eth1 down </syntaxhighlight> <span style="color: #9966CC;">O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede?
 ===Testando campo TTL com ''loop'' na rede===
-#No arquivo abaixo as tabelas de roteamento geram um ''loop''. Copie o conteúdo abaixo e crie um arquivo loop.conf <code>
+#No arquivo abaixo as tabelas de roteamento geram um ''loop''. Copie o conteúdo abaixo e crie um arquivo '''/home/aluno/loop.conf''' <syntaxhighlight lang=bash>
 # Hosts definitions
 pc1[type]=generic
@@ Linha 975: / Linha 1 236: @@
 r2[route]=192.168.2.0/24:gateway=10.0.2.2
 r3[route]=192.168.2.0/24:gateway=10.0.1.1 </syntaxhighlight>
-#*Lembre-se de rodar os comandos para evitar filtros de pacotes nos três roteadores: <code>
+#<span style="color: #9966CC;"> Analisando o arquivo de configuração do Netkit mostre onde é criado o ''loop''.
+#*Lembre-se de rodar os comandos para evitar filtros de pacotes nos três roteadores: <syntaxhighlight lang=bash>
 echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
 echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
@@ Linha 981: / Linha 1 243: @@
 echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter </syntaxhighlight>
 #Configure os roteadores para salvar os dados coletados, com os seguintes comandos:
-##No r1: <code>
+##No r1: <syntaxhighlight lang=bash>
-tcpdump -i any -w /hostlab/r1.pcap & </syntaxhighlight>
+tcpdump -i eth1 -w /hostlab/r1.pcap & </syntaxhighlight>
-##No r2: <code>
+##No r2: <syntaxhighlight lang=bash>
-tcpdump -i any -w /hostlab/r2.pcap & </syntaxhighlight>
+tcpdump -i eth2 -w /hostlab/r2.pcap & </syntaxhighlight>
-##No r3: <code>
+##No r3: <syntaxhighlight lang=bash>
-tcpdump -i any -w /hostlab/r3.pcap & </syntaxhighlight>
+tcpdump -i eth1 -w /hostlab/r3.pcap & </syntaxhighlight>
-#Gere um tráfego controlado a partir do '''pc1''': <code>
+#Gere um tráfego controlado a partir do '''pc1''': <syntaxhighlight lang=bash>
 ping -c2 192.168.2.1 </syntaxhighlight>
 #Pare (Ctrl + C) todas as coletas de dados nos roteadores.
-#Com o Wireshark abra os três arquivos de pacotes capturados: /home/aluno/lab/r1.pcap...r3.pcap. Deixe as três janelas do Wireshark lado a lado e responda:
+#<span style="color: #9966CC;">Com o Wireshark abra os três arquivos de pacotes capturados: /home/aluno/lab/r1.pcap...r3.pcap. Deixe as três janelas do Wireshark lado a lado e responda:
 ##Em qual roteador os pacotes são descartados? Observe os pacotes de número de sequência 1 e explique sua resposta.
 ##Qual o significado da linha com o seguinte conteúdo parcial: ''192.168.0.1 ICMP	128 Time-to-live exceeded (Time to live exceeded in transit)''?
+##Explique qual o objetivo do campo ttl no cabeçalho IP?
-==Protocolos de roteamento, parte 2==
+==Protocolos de roteamento dinâmicos - RIP==
+===Objetivo===
+*Analisar o funcionamento de protocolo dinâmicos de roteamento RIP.
-===O Pacote Quagga -- Breve introdução ===
+===O Pacote Quagga: breve introdução ===
 O pacote [http://www.nongnu.org/quagga/ Quagga] fornece um conjunto de processos (''daemons'') com
@@ Linha 1 041: / Linha 1 306: @@
 interfaces e atribuir endereços as mesmas. Também pode-se acrescentar rotas.
-==Experimento 3: protocolos e roteamento OSPF==
-Tempo aproximado para execução e conferência: 30 min
+===Roteiro===
+*Baseado no diagrama abaixo, executaremos o protocolo de roteamento RIP a partir do Quagga, de tal modo que o sistema se auto recuperará, por exemplo, da queda de um enlace.
+[[Arquivo:DynamicRoutingTriangle.png]]
+#Crie em seu computador um arquivo com nome '''/home/aluno/RIP.conf'''. Observe que nessa configuração já está inserida a definição dos default gateway de cada pc. O conteúdo do arquivo é o seguinte: <syntaxhighlight lang=bash>
+# Hosts definitions
+pc1[type]=generic
+pc2[type]=generic
+pc3[type]=generic
+# Default gateways definitions
+pc1[default_gateway]=192.168.0.254
+pc2[default_gateway]=192.168.1.254
+pc3[default_gateway]=192.168.2.254
+# Routers definitions
+r1[type]=gateway
+r2[type]=gateway
+r3[type]=gateway
+# Hosts' interfaces to local routers
+pc1[eth0]=link0:ip=192.168.0.1/24
+pc2[eth0]=link1:ip=192.168.1.1/24
+pc3[eth0]=link2:ip=192.168.2.1/24
+# Routers' interfaces to local networks
+r1[eth0]=link0:ip=192.168.0.254/24
+r2[eth0]=link1:ip=192.168.1.254/24
+r3[eth0]=link2:ip=192.168.2.254/24
+# Network "backbone" links
+r1[eth1]=backbone0:ip=10.0.0.1/30
+r1[eth2]=backbone1:ip=10.0.1.1/30
+r2[eth1]=backbone0:ip=10.0.0.2/30
+r2[eth2]=backbone2:ip=10.0.2.1/30
+r3[eth1]=backbone1:ip=10.0.1.2/30
+r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
+#Em cada roteador, configure o serviço RIP.
+##O Netkit cria no diretório '''home''' do usuário (/home/aluno) uma pasta chamada '''lab'''.
+##Nesta pasta, há uma pasta exclusiva para cada equipamento da rede em teste.
+##Neste diretório podem ser colocados arquivos de configuração de serviços a serem executados nas máquinas virtuais do Netkit. É por ali que será configurado, primeiramente, o Quagga, software de roteamento que implementa RIP, OSPF e/ou BGP.
+##O arquivo de configuração abaixo mostra a configuração do Quagga para o roteador '''r1'''. Salve este arquivo como '''/home/aluno/lab/r1/zebra.conf'''.<syntaxhighlight lang=text>
+hostname r1
+interface eth0
+   ip address 192.168.0.254/24
+interface eth1
+   ip address 10.0.0.1/30
+interface eth2
+   ip address 10.0.1.1/30
+log stdout
+</syntaxhighlight>
+##Em seguida, adapte o arquivo para os roteadores '''r2''' e '''r3''' observando a figura:
+##*Configure cada interface de cada roteador com seu respectivo IP, baseado na figura.
+##*Salve no respectivo diretório de cada roteador.
+#Para o caso particular de nossa arquitetura de rede, o arquivo de configuração para o RIP pode ser único, assim sendo, vamos criar o arquivo '''/home/aluno/lab/shared/ripd.conf''' com o seguinte conteúdo: <syntaxhighlight lang=text>
+router rip
+  redistribute connected
+  redistribute static
+  network eth1
+  network eth2
+</syntaxhighlight>
+#No '''r2''' deixe o '''tcpdump''' capturando pacotes em todas as interfaces <syntaxhighlight lang=bash> tcpdump -i any -vvv -w /hostlab/r2/r2_RIP.pcap &</syntaxhighlight>
+#No '''pc1''' execute: <syntaxhighlight lang=bash> ping 192.168.2.1 </syntaxhighlight> <span style="color: #9966CC;">O ping está funcionando? Por quê?
+#Deixe o ping rodando!
+#Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <syntaxhighlight lang=bash> service quagga start </syntaxhighlight>
+#Execute o Quagga e o RIP em todos os roteadores (r1, r2 e r3), a partir dos arquivos criados.
+##Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do Netkit, ou seja, "/home/aluno/lab" na máquina real é a mesma pasta que "/hostlab/" nas máquinas virtuais do Netkit.
+##Para iniciar os serviços no '''r1''', faça algo como o que está no exemplo abaixo. <syntaxhighlight lang=bash>
+zebra -d -f /hostlab/r1/zebra.conf
+ripd -d -f /hostlab/shared/ripd.conf
+</syntaxhighlight>
+##Repita o procedimento para '''r2''' e '''r3''' utilizando os arquivos corretos, por exemplo, para '''r2''':<syntaxhighlight lang=bash>
+zebra -d -f /hostlab/r2/zebra.conf
+ripd -d -f /hostlab/shared/ripd.conf
+</syntaxhighlight>
+#<span style="color: #9966CC;">Olhe o terminal do pc1, o que ocorreu com o ping? Por quê?
+#Observando o estado do sistema. Vamos usar comandos para verificar o estado dos roteadores.
+##Solicitar uma sessão com o vtysh no ''zebrad'': <syntaxhighlight lang=bash> vtysh </syntaxhighlight>
+##Verifique o estado das interfaces usando o comando: <syntaxhighlight lang=bash> show interface </syntaxhighlight>
+##Verifique se o roteador está habilitado para roteamento: <syntaxhighlight lang=bash> show ip forwarding </syntaxhighlight>
+##<span style="color: #9966CC;">Verifique o estado da '''tabela de roteamento''' usando o comando: <syntaxhighlight lang=bash> show ip route </syntaxhighlight> '''Interprete detalhadamente essa tabela'''! Você consegue visualizar o mapa da rede a partir dessa tabela?
+##Verifique a configuração atual do roteador: <syntaxhighlight lang=bash> show run </syntaxhighlight>
+##Sair do vtysh: <syntaxhighlight lang=bash>exit </syntaxhighlight>
+#Teste as demais conectividades entre os PCs com pings mútuos. Tudo funcionando?
+#<span style="color: #9966CC;">A partir de cada PC trace a rota ('''traceroute''') para os demais PC e anote-as.
+#<span style="color: #9966CC;">Com o '''route -n''' e/ou '''netstat -r''' verifique a anote as rotas de cada roteador.
+#Desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens.
+##"Derrube" o enlace '''r1-r3''', no '''r1''' execute: <syntaxhighlight lang=bash>
+vtysh 2061
+conf t
+interface eth2
+shutdown </syntaxhighlight>
+##*Significado dos comandos:
+##*#Entra no ''zebrad''.
+##*#Entra no modo de configuração.
+##*#Entra na referida interface a ser operada, no caso ''eth2''.
+##*#Desativa a interface. Se desejado pode-se ativá-la novamente com ''no shutdown''.
+#Monitorando o ping, aguarde até o retorno das repostas ao mesmo. É comum demorar até uns 2-3 minutos.
+##<span style="color: #9966CC;">Anote o número de sequência do último ping com sucesso antes da "derrubada" do enlace e o primeiro após a retorno da funcionamento normal do ping.
+#Pare todos os pings.
+#Pare o tcpdump no '''r2''':<syntaxhighlight lang=bash> fg
+<Ctrl + c> </syntaxhighlight>
+#<span style="color: #9966CC;">Teste as conectividades. O que aconteceu?
+#<span style="color: #9966CC;">Retrace e anote as rotas executando nos roteadores <syntaxhighlight lang=bash> vtysh 2061
+show ip route </syntaxhighlight> e <syntaxhighlight lang=bash> traceroute </syntaxhighlight> a partir dos PCs.
+##São diferentes do caso original (todos enlaces ativos)? Por quê?
+##Quais os caminhos/rotas que foram reescritos? Por quê? Obs.: estão relacionados com a interface desativada.
+#Abra com o Wireshark o arquivo /home/aluno/r2/r2_RIP.pcap, filtre por '''rip'''. Responda:
+#*Clique sobre a mensagem e expanda o campo ''Routing Information Protocol'' na janela central.
+#*Os roteadores são identificados por seus IPs.
+#*O campo ''Metric'' indica o número de saltos do roteador em questão até a rede.
+#*Observe que na formação das rotas surgem métricas iguais a 3, mas são estabilizadas em 2.
+#*Observe que pode haver métricas com número 16 (~infinito).
+##<span style="color: #9966CC;">Tente compreender as mensagens RIPv2 trocadas desde o início explicando-as.
+##<span style="color: #9966CC;">Prove que até aproximadamente a mensagem 30 as rotas todas foram formadas.
+##<span style="color: #9966CC;">Justifique/explique as métricas iguais a 3.
+##<span style="color: #9966CC;">As mensagens são trocadas aproximadamente a cada minuto?
+##<span style="color: #9966CC;">Qual o número (No.) da mensagem onde a rede apresentou problemas com rotas (obs: retire o filtro rip e procure no número de sequência dos pings (seq) os números anotados no item 15.1).
+##<span style="color: #9966CC;">Quais e quantas mensagens (número) são trocadas entre os roteadores para restabelecer as rotas?
+##<span style="color: #9966CC;">Pesquise o significado do endereço 224.0.0.9.
+==Protocolos de roteamento dinâmicos - OSPF==
+===Objetivo===
+*Analisar o funcionamento de protocolo dinâmicos de roteamento OSPF.
+===Roteiro===
+A rede a ser analisada será a mesma que nos casos anteriores.
-#Reinicie o NetKit2 para limpar todas as configurações.
+[[Arquivo:DynamicRoutingTriangle.png]]
-#Crie em seu computador um arquivo com nome '''/home/aluno/exp2.conf'''. Observe que nessa configuração já está inserida a definição dos default gateway de cada pc. O conteúdo do arquivo é o seguinte: <code>
+#Crie em seu computador um arquivo com nome '''/home/aluno/OSPF.conf'''. O conteúdo do arquivo é o seguinte: <syntaxhighlight lang=bash>
 # Hosts definitions
 pc1[type]=generic
@@ Linha 1 081: / Linha 1 475: @@
 r3[eth1]=backbone1:ip=10.0.1.2/30
 r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
-#Crie os arquivos de configuração para o OSPF em cada roteador, colocando-os dentro dos diretórios dos mesmos (p. ex: /home/aluno/lab/r1). O nome destes arquivos deve ser '''ospfd.conf''' e o conteúdo deve ser conforme o modelo abaixo para o '''r1'''. Para o '''r2''' e '''r3''' faça as adaptações necessárias.<syntaxhighlight lang=text>
+#Em cada roteador, configure o serviço '''Zebra'''.
+##O Netkit cria no diretório '''home''' do usuário (/home/aluno) uma pasta chamada '''lab'''.
+##Nesta pasta, há uma pasta exclusiva para cada equipamento da rede em teste.
+##Neste diretório podem ser colocados arquivos de configuração de serviços a serem executados nas máquinas virtuais do Netkit. É por ali que será configurado, primeiramente, o Quagga, software de roteamento que implementa RIP, OSPF e/ou BGP.
+##O arquivo de configuração abaixo mostra a configuração do Quagga para o roteador '''r1'''. Salve este arquivo como '''/home/aluno/lab/r1/zebra.conf'''.<syntaxhighlight lang=text>
+hostname r1
+interface eth0
+   ip address 192.168.0.254/24
+interface eth1
+   ip address 10.0.0.1/30
+interface eth2
+   ip address 10.0.1.1/30
+log stdout
+</syntaxhighlight>
+##Em seguida, adapte o arquivo para os roteadores '''r2''' e '''r3''' observando a figura:
+##*Configure cada interface de cada roteador com seu respectivo IP, baseado na figura.
+##*Salve no respectivo diretório de cada roteador.
+#Crie o arquivo de configuração para o OSPF no roteador '''r1''', '''/home/aluno/lab/r1/ospfd.conf''': <syntaxhighlight lang=text>
 #Router r1
 #
@@ Linha 1 100: / Linha 1 513: @@
 log stdout
 </syntaxhighlight>
-#Os arquivos '''zebra.conf''' são os mesmos utilizados no experimento 2.
+#Crie o arquivo '''ospfd.conf''' para '''r2''' e '''r3''' adaptando o arquivo acima:
-#Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <code> service quagga start </syntaxhighlight>
+##*Configure cada interface de cada roteador com seu respectivo IP e endereço de rede, baseado na figura.
-#Execute o Quagga e o OSPF a partir dos arquivos criados. Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do NetKit. Para iniciar os serviços no '''r1''', faça algo como o que está no exemplo abaixo. Repita o procedimento para '''r2''' e '''r3''' utilizando os arquivos corretos.<code>
+##*Salve no respectivo diretório de cada roteador.
+#No '''r2''' deixe o '''tcpdump''' capturando pacotes em todas as interfaces <syntaxhighlight lang=bash> tcpdump -i any -vvv -w /hostlab/r2/r2_OSPF.pcap &</syntaxhighlight>
+#A partir do '''pc1''' deixe rodando o ping <syntaxhighlight lang=bash> ping 192.168.2.1</syntaxhighlight>
+#Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <syntaxhighlight lang=bash> service quagga start </syntaxhighlight>
+#Execute o Quagga e o OSPF a partir dos arquivos criados. No '''r1''': <syntaxhighlight lang=bash>
 zebra -d -f /hostlab/r1/zebra.conf
 ospfd -d -f /hostlab/r1/ospfd.conf </syntaxhighlight>
-#Repita, na medida do possível e fazendo os devidos ajustes, as atividades 11 a 21 do experimento anterior e responda, além das respectivas questões desses itens:
+#No '''r2''': <syntaxhighlight lang=bash>
+zebra -d -f /hostlab/r2/zebra.conf
+ospfd -d -f /hostlab/r2/ospfd.conf </syntaxhighlight>
+#No '''r3''': <syntaxhighlight lang=bash>
+zebra -d -f /hostlab/r3/zebra.conf
+ospfd -d -f /hostlab/r3/ospfd.conf </syntaxhighlight>
+#<span style="color: #9966CC;">A partir de cada PC trace a rota ('''traceroute''') para os demais PC e anote-as.
+#<span style="color: #9966CC;">Com o '''route -n''' e/ou '''netstat -r''' verifique a anote as rotas de cada roteador.
+#Desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens.
+##"Derrube" o enlace '''r1-r3''', no '''r1''' execute: <syntaxhighlight lang=bash>
+vtysh 2061
+conf t
+interface eth2
+shutdown</syntaxhighlight>
+##*Significado dos comandos:
+##*#Entra no zebrad.
+##*#Entra no mode de configuração.
+##*#Entra na referida interface a ser operada, no caso eth2.
+##*#Desativa a interface. Se desejado pode-se reativá-la com ''no shutdown''.
+#Monitorando o ping, aguarde até o retorno das repostas ao mesmo. A parada é praticamente imperceptível.
+##<span style="color: #9966CC;">Anote o número de sequência do último ping com sucesso antes da "derrubada" do enlace e o primeiro após a retorno da funcionamento normal do ping.
+#Pare todos os pings.
+#Pare o tcpdump no '''r2''':<syntaxhighlight lang=bash> fg
+<Ctrl + c> </syntaxhighlight>
+#<span style="color: #9966CC;">Teste as conectividades. O que aconteceu?
+#<span style="color: #9966CC;">Retrace e anote as rotas executando nos roteadores <syntaxhighlight lang=bash> vtysh 2061
+show ip route </syntaxhighlight> e <syntaxhighlight lang=bash> traceroute </syntaxhighlight> a partir dos PCs.
+##São diferentes do caso original (todos enlaces ativos)? Por quê?
+##Quais os caminhos/rotas que foram reescritos? Por quê?
+#Abra o arquivo /home/aluno/r2/r2_OSPF.pcap.
+#*Perceba que com o protocolo OSPF, diferentemente do RIP, não há trocas periódicas de mensagens do protocolo de roteamento.
+#* Só haverá trocas quando o protocolo sentir necessidade de alguma mudança de rota, por exemplo, com a queda de um enlace.
+#Analisando a captura de dados <span style="color: #9966CC;">responda:
+##Quais as mensagens trocadas pelo protocolo OSPF são observadas no WireShark? Observe o trecho de mensagens onde não houve respostas ao ping.
+##Qual o tempo aproximado para a total recuperação das rotas? (Isso é observável pela diferença de tempos (''timestamp'') na sequência de mensagens observadas no Wireshark).
 ##As mensagens trocadas pelos roteadores são distintas quando comparadas ao uso do RIP?
 ##Houve diferença no tempo de atualização das rotas quando comparado ao RIP? Por quê?
 ==''Neighbor Discovery'' e roteamento estático no IPv6==
@@ Linha 1 139: / Linha 1 589: @@
 [[Arquivo:Diagrama_rede_IPv6.jpg]]
-#Crie em seu computador um arquivo com nome /home/aluno/IPv6.conf, com o seguinte conteúdo: <code>
+#Crie em seu computador um arquivo com nome '''/home/aluno/IPv6.conf''', com o seguinte conteúdo: <syntaxhighlight lang=bash>
 #Ligacao das maquinas nos dominios de colisao
 #Duas pequenas redes interligadas pelo backbone
 # Hosts definitions
 pc1[type]=generic
@@ Linha 1 148: / Linha 1 598: @@
 pc3[type]=generic
 pc4[type]=generic
+# Hosts' interfaces to local routers
+pc1[eth0]=link0:ipv6=2001:bcc:faca:1::101/64
+pc2[eth0]=link1:ipv6=2001:bcc:cafe:1::102/64
+pc3[eth0]=HUB1:ipv6=2001:bcc:1f0:1::103/64
+pc4[eth0]=HUB1
+#Default Gateways definitions
+pc1[route]=default6:gateway=2001:bcc:faca:1::1
+pc2[route]=default6:gateway=2001:bcc:cafe:1::1
+pc3[route]=default6:gateway=2001:bcc:1f0:1::1
 # Routers definitions
 r1[type]=gateway
 r2[type]=gateway
-# Hosts' interfaces to local routers
+#Routers interfaces definitions
-pc1[eth0]=link0
+r1[eth0]=backbone0:ipv6=2001:db8:dead:1::1/64
-pc2[eth0]=link1
+r1[eth1]=link0:ipv6=2001:bcc:faca:1::1/64
+r1[eth2]=link1:ipv6=2001:bcc:cafe:1::1/64
-r1[eth0]=backbone0
+r2[eth0]=backbone0:ipv6=2001:db8:dead:1::2/64
-r1[eth1]=link0
+r2[eth1]=HUB1:ipv6=2001:bcc:1f0:1::1/64
-r1[eth2]=link1
+ </syntaxhighlight>
+#Rode o NetKit em seu computador. Em um terminal digite: <syntaxhighlight lang=bash>
-r2[eth0]=backbone0
-r2[eth1]=HUB1
-pc3[eth0]=HUB1
-pc4[eth0]=HUB1 </syntaxhighlight>
-#Rode o NetKit em seu computador. Em um terminal digite: <code>
 netkit2 & </syntaxhighlight>
-#No menu '''File''' - '''Load and Run''', procure o arquivo /home/aluno/IPv6.conf e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: '''pc1-4''' ou '''r1-2'''.
+#No menu '''File''' - '''Load and Run''', procure o arquivo '''/home/aluno/IPv6.conf''' e clique em OK.
 #Ao clicar no menu '''File''' - '''Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
-#Em todos os equipamentos, iremos iniciar a captura de pacotes em uma das interfaces que será gravado em um arquivo para estudo posterior. Utilize os seguintes comandos (atenção ao "&" no final que envia o tcpdump para background):
+#Deixe capturando pacotes no '''r1''' com o '''tcpdump''':<syntaxhighlight lang=bash>
-##'''pc1''': tcpdump -i eth0 -w /hostlab/ipv6_pc1.pcap &
+tcpdump -i any -w /hostlab/r1/r1.pcap & </syntaxhighlight>
-##'''pc2''': tcpdump -i eth0 -w /hostlab/ipv6_pc2.pcap &
+#<span style="color: #9966CC;">Vamos testar o ''Neighbor Discovery'', anote a saída do comando. A partir do '''pc1''' execute: <syntaxhighlight lang=bash>
-##'''pc3''': tcpdump -i eth0 -w /hostlab/ipv6_pc3.pcap &
+ndisc6 -m 2001:bcc:faca:1::1 eth0 </syntaxhighlight>
-##'''pc4''': tcpdump -i eth0 -w /hostlab/ipv6_pc4.pcap &
+#*Esse comando descobre e retorna o ''MAC address'' da interface de rede que possui o endereço IPv6 informado.
-##'''r1''': tcpdump -i eth0 -w /hostlab/ipv6_r1.pcap &
+#Observe que todas as interfaces de rede já estão pré-configuradas, exceto do '''pc4'''.
-##'''r2''': tcpdump -i eth0 -w /hostlab/ipv6_r2.pcap &
+#Adapte o comando abaixo, que seria do '''pc1''',  para adicionar o endereço IPv6 à interface de rede no '''pc4''': <syntaxhighlight lang=bash>
-#No '''pc1''' use o seguinte comando para adicionar o endereço IPv6 à interface de rede: <code>
 ip addr add 2001:bcc:faca:1::101/64 dev eth0 </syntaxhighlight>
-#No '''pc1''' use o seguinte comando para verificar como ficou a configuração dos endereços da interface de rede. O resultado é similar ao apresentado pelo comando '''ifconfig''': <code>
+#Faça um '''ping6''' entre o '''pc3''' ao '''pc4'''.
+#*<span style="color: #9966CC;">Se tudo estiver devidamente configurado, deve-se obter sucesso no ping entre o '''pc3''' e '''pc4'''. Explique o por quê?
+#Faça um '''ping6''' entre o '''pc1''' ao '''pc4'''.
+#*<span style="color: #9966CC;">Obteve sucesso? Sim ou não e por quê?
+#No '''pc4''' use o seguinte comando para verificar como ficou a configuração dos endereços da interface de rede. O resultado é similar ao apresentado pelo comando '''ifconfig''': <syntaxhighlight lang=bash>
 ip addr show dev eth0 </syntaxhighlight>
-#Configure os IPv6s de todas as interfaces dos demais equipamentos de acordo com o diagrama da rede (adapte os números de IPs), seguindo o exemplo do item 6.
+#<span style="color: #9966CC;">No '''pc4''', liste a tabela de roteamento com o comando: <syntaxhighlight lang=bash>
-#Faça um '''ping6''' entre o '''pc3''' ao '''pc4'''. Por exemplo do '''pc3''' ao '''pc4''': <code>
+ip -6 route show </syntaxhighlight>
-ping6 -c4 2001:bcc:1f0:1::104 </syntaxhighlight>
+#No '''pc4''', acrescente o ''default gateway'' com o seguinte comando: <syntaxhighlight lang=bash>
-#Se tudo estiver devidamente configurado, deve-se obter sucesso no ping entre o '''pc3''' e '''pc4'''. Explique o por quê?
-#Faça um '''ping6''' entre o '''pc1''' ao '''pc2'''.
-#Não deve ter obtido sucesso, por quê?
-#Nos computadores '''pc3''' e '''pc4''', acrescente o ''default gateway'' com o seguinte comando: <code>
 ip -6 route add default via 2001:bcc:1f0:1::1 dev eth0 </syntaxhighlight>
-#Nos computadores '''pc1''' e '''pc2''', acrescente o ''default gateway'' analisando o diagrama da rede e adaptando o comando acima.
+#*<span style="color: #9966CC;">Confira novamente a tabela de roteamento do '''pc4'''.
-#Faça novamente o '''ping6''' entre o '''pc1''' ao '''pc2'''.
+#Faça novamente um '''ping6''' entre o '''pc1''' ao '''pc4'''.
-#Agora deve ter obtido sucesso, por quê?
+#*<span style="color: #9966CC;">Obteve sucesso? Sim ou não e por quê?
-#Faça um '''ping6''' entre o '''pc1''' ao '''pc4'''.
+#No '''r1''', adicione uma rota estática para a rede dos '''pc3''' e '''pc4''' através do seguinte comando: <syntaxhighlight lang=bash>
-#Obteve sucesso? Sim ou não e por quê?
-#No '''r1''', adicione uma rota estática para a rede dos '''pc3''' e '''pc4''' através do seguinte comando: <code>
 ip -6 route add 2001:bcc:1f0:1::/64 via 2001:db8:dead:1::2 dev eth0 </syntaxhighlight>
-#No '''r2''', adicione uma rota estática para a rede dos '''pc1''' e '''pc2''' através dos seguintes comandos: <code>
+#No '''r2''', adicione uma rota estática para a rede dos '''pc1''' e '''pc2''' através dos seguintes comandos: <syntaxhighlight lang=bash>
 ip -6 route add 2001:bcc:faca:1::/64 via 2001:db8:dead:1::1 dev eth0
 ip -6 route add 2001:bcc:cafe:1::/64 via 2001:db8:dead:1::1 dev eth0 </syntaxhighlight>
-#Pode-se conferir se as rotas foram corretamente configuradas com o comando: <code>
+#*Pode-se conferir se as rotas foram corretamente configuradas com o comando: <syntaxhighlight lang=bash>
 ip -6 route show </syntaxhighlight>
 #Faça novamente o '''ping6''' entre o '''pc1''' ao '''pc4'''.
-#Obteve sucesso? Sim ou não e por quê?
+#*<span style="color: #9966CC;">Obteve sucesso? Sim ou não e por quê?
-#Use os comandos '''traceroute6 2001:bcc:1f0:1::103''' e '''traceroute6 2001:bcc:1f0:1::104''' a partir do computador '''pc1'''.
+#<span style="color: #9966CC;">A partir do computador '''pc1''' use os comandos e anote as rotas obtidas. <syntaxhighlight lang=bash>
-#Anote as rotas.
+traceroute6 2001:bcc:1f0:1::103
-#Use o comando '''ip -6 route show''' para consultar a tabela de roteamento de cada um dos roteadores. São coerentes com os dados das rotas obtidas acima?
+traceroute6 2001:bcc:1f0:1::104 </syntaxhighlight>
-#Em cada uma das máquinas virtuais, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''.
+#Use o comando abaixo para consultar a tabela de roteamento de cada um dos roteadores.<syntaxhighlight lang=bash>
-#Estude os '''.pcaps''' gerados utilizando o '''wireshark''': abra o '''wireshark''', '''File/Open''' e procure os arquivo na pasta /home/aluno/lab. Clique sobre cada um deles e faça a análise.
+ip -6 route show </syntaxhighlight>
-#Explique o processo de descoberta de vizinhança (''neighbor discovery'' / ''Neighbor Solicitation'' - '''NS''' e ''Neighbor Advertisement'' - '''NA'''), citando os endereços de '''multicast''' e '''link local''' utilizados.
+#*<span style="color: #9966CC;">São coerentes com os dados das rotas obtidas acima?
-#Alguns exemplos de campos visualizáveis para uma mensagem do tipo ''Neighbor Advertisement'':
+#Pare o '''tcpdump''' em '''r1'''.<syntaxhighlight lang=bash>
-##Destination (camada Ethernet)
+fg
-##*O endereço MAC do nó requisitante que foi obtido por meio da mensagem NS enviada anteriormente.
+<Ctrl c>  </syntaxhighlight>
-##Source (camada Ethernet)
+#<span style="color: #9966CC;">Abra o arquivo do '''tcpdump''' e explique o processo de descoberta de vizinhança (''Neighbor Solicitation'' - '''NS''' e ''Neighbor Advertisement'' - '''NA'''), citando os endereços de '''multicast''' e '''link local''' utilizados.
+#*Alguns exemplos de campos visualizáveis para uma mensagem do tipo ''Neighbor Advertisement'', presentes nas camadas destacadas:
+##'''Source''' (camada Ethernet)
 ##*A origem é o endereço MAC da interface do dispositivo que enviou a resposta.
-##Type (camada Ethernet)
+##'''Protocol''' (camada Ethernet)
 ##*Indica que a mensagem utiliza IPv6.
-##Next header (camada IPv6)
+##'''Next header''' (camada IPv6)
 ##*Indica qual é o próximo cabeçalho. Neste caso, o valor 58 (0x3a) refere-se a uma mensagem ICMPv6.
-##Source (camada IPv6)
+##'''Source''' (camada IPv6)
 ##*A origem é o endereço IP da interface diretamente ligada ao enlace em que a requisição foi recebida.
-##Destination (camada IPv6)
+##'''Destination''' (camada IPv6)
-##*Diferentemente da mensagem NS, a mensagem NA possui como destino o endereço IPv6 global do nó requisitante.
+##'''Type''' (camada ICMPv6)
-##Type (camada ICMPv6)
 ##*Indica que a mensagem é do tipo 136 (Neighbor Advertisement).
-##Flags (camada ICMPv6)
+##'''Flags''' (camada ICMPv6)
 ##*Uma mensagem NA possui três flags:
 ###Indica se quem está enviando é um roteador. Neste caso, o valor marcado é 0, pois não é um roteador.
 ###Indica se a mensagem é uma resposta a um NS. Neste caso, o valor marcado é 1, pois é uma resposta.
 ###Indica se a informação carregada na mensagem é uma atualização de endereço de algum nó da rede. Neste caso, o valor marcado é 1, pois está informando o endereço pela primeira vez.
-##Target Address (camada ICMPv6)
+##'''Target Address''' (camada ICMPv6)
 ##*Indica o endereço IP associado às informações das flags. Neste caso, é o próprio endereço da interface do dispositivo em questão.
-##ICMPv6 option (camada ICMPv6)
+#<span style="color: #9966CC;">Numa mensagem do tipo ''Neighbor Solicitation'' qual é o endereço IPv6 de origem e destino? Explique/defina ambos.
-##*Indica as opções do pacote ICMPv6:
+#<span style="color: #9966CC;">Em todos os hosts rode o comando <syntaxhighlight lang=bash> ip -6 neighbor show </syntaxhighlight>
-###Target link-layer address
-##Type
-##*Indica o tipo de opção. Neste caso, Target link-layer address.
-##Link-layer address
-##*Indica o endereço MAC da interface do dispositivo em questão.
-#Numa mensagem do tipo ''Neighbor Solicitation'' qual é o endereço IPv6 de origem e destino? Explique/defina ambos.
-#Analisando o tráfego gerado no '''pc1''', identifique aproximadamente quais os números (No.) de troca de pacotes nas ocorrência de '''ping6'''. Quais dais ocorrências obtiveram sucesso e quais não obtiveram? Quando não houve sucesso, qual é a causa listada no WireShark? Relacione esses dados com o itens do roteiro executado.
-#Em todos os hosts rode o comando <code> ip -6 neighbor show </syntaxhighlight>
 ##Qual é a funcionalidade desse comando?
 ##Qual é o significado do conteúdo dessa tabela?
 ##A tabela mostrada em cada um dos casos é compatível com o diagrama da rede montado?
 ##Por que, por exemplo, na tabela do '''pc3''' não há uma referência explícita ao '''pc1'''?
-#Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6.
+#<span style="color: #9966CC;">Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6.