Rede de Computadores
Relatório Final
Mestrado em Engenharia Informática e Computação
EIC0032 – Redes de Computadores
Grupo:
Antonieta Oliveira – ei07157
Ricardo Amorim – ei08103
Introdução
Numa fase inicial, desenvolveu-se um cliente FTP simples cujo objetivo seria
implementar as diversas fases de negociação bem como a transferência de um
arquivo alojado no servidor. Esta aplicação, desenvolvida na linguagem C, faz uso das
diversas potencialidades do protocolo referido e do conceito de sockets no ambiente
UNIX.
Já numa segunda fase foi feita a configuração de uma rede local de
computadores e o respetivo estudo e interpretação dos conceitos envolvidos.
No final foi utilizada a aplicação desenvolvida na primeira fase para transferir
um arquivo que se encontrava num servidor FTP através da rede configurada na
segunda fase.
Sumário
O relatório constitui uma análise detalhada da implementação feita, bem como
dos resultados obtidos ao longo das experiências feitas. Inicialmente será feita uma
descrição da fase de desenvolvimento da aplicação de download, posteriormente
abordar-se-ão as várias experiências da segunda fase do projeto e a respetiva análise
dos resultados obtidos, incluindo a parte respeitante à utilização da aplicação na rede
configurada e no final concluir-se-á acerca dos conceitos envolvidos em todo o projeto
bem como a sua importância.
Ao longo da análise serão apresentados os comandos mais importantes
utilizados na configuração da rede.
2
Parte 1 – Aplicação de download
A aplicação foi desenvolvida em linguagem C e num único ficheiro, download.c,
destinando-se a implementar uma versão simplificada do protocolo FTP. Esta
implementação inclui as fases de negociação com o servidor, como por exemplo a
autenticação opcional, a criação dos sockets de controlo e de dados e posterior
transferência do ficheiro especificado.
A sintaxe de chamada da aplicação segue o especificado na norma RFC1738:

ftp://<username>:<password>@<host>/<url-path>
Um exemplo da utilização desta sintaxe, que foi utilizado nos testes durante o
desenvolvimento é “ftp://ftp.up.pt/pub/robots.txt” .
Após a verificação do número de argumentos recebidos, é feita a separação do
URL recebido nos diferentes componentes: nome de utilizador, respetiva password,
host, e caminho para o ficheiro. Esta separação foi feita com recurso à função sscanf
da linguagem C juntamente com uma expressão regular, o que permite a rejeição em
caso de falta de argumentos ou da sua especificação estar errada.
Depois da operação do parser, a fase de ligação ao servidor faz uso de um
socket, representando o canal de controlo, que é aberto através da porta do servidor
destinada ao protocolo FTP (porta 21). Para esta ligação são utilizadas as
funcionalidades do serviço DNS, para converter o nome do servidor para o seu
endereço IP.
Após a abertura do canal de controlo, é feita a autenticação com os dados
obtidos a partir do URL. Esta autenticação tem em conta a resposta do servidor,
nomeadamente a aceitação ou rejeição do nome de utilizador ou da password
fornecidos sendo que no caso de rejeição a aplicação termina.
Depois da autenticação estar garantida é feito um pedido ao servidor para a
transferência de um arquivo no modo passivo. Este modo aplica-se para situações em
que, por exemplo o cliente se encontra protegido por uma firewall e portanto incapaz
de aceitar ligações TCP (o que acontece no modo ativo). Desta forma o cliente fica
responsável por abrir o canal de dados para a ligação TCP com o mesmo IP utilizado
para o canal de controlo, mas com a porta calculada com base na resposta do servidor
ao comando “pasv”. O número da porta é obtido com 256*MSB+LSB e é então aberto
o socket para a transferência de dados.
3
Por fim, é enviado o pedido para transferência do ficheiro através do comando
“retr” ao que o servidor responde com o início da transmissão sobre o canal de dados.
Após esta transferência são fechados os dois canais (sockets) bem como o ficheiro
aberto e a aplicação termina a execução.
Na figura 1 apresenta-se o exemplo de uma transferência do ficheiro
“japanese.xml” alojado num servidor ftp com nome de utilizador e password “test”,
juntamente com as respetivas respostas do servidor no decorrer do processo.
O código fonte desenvolvido pode ser consultado em “código fonte do cliente
FTP”.
Parte 2 – Configuração e análise da rede no laboratório
2.1 – Configurar rede IP
Inicialmente foi desligado o cabo que liga o switch ao router laboratorial
(resultando na perda do acesso à internet dos terminais). De seguida, configuraram-se
o tux1 e tux4 com os endereços necessários para garantir a comunicação entre eles.
Depois da eliminação da tabela ARP, que constitui um meio de facilitar o
reconhecimento dos endereços mac associados aos endereços IP, utilizou-se o
comando ping para testar a conectividade. O não reconhecimento do endereço
fornecido faz com que sejam enviados pacotes ARP para obter o endereço físico do
recetor. O cliente envia um pacote ARP para o endereço de broadcast que
reencaminha o pacote para todos os terminais. Posteriormente, o terminal que tiver o
endereço IP contido no pacote enviado irá responder com o seu endereço físico.
Para uma melhor eficiência, este endereço é temporariamente guardado na
tabela ARP, que armazena correspondências do tipo ARP-IP, evitando assim novos
pedidos posteriores durante esse tempo.
O registo 2.a evidencia o comportamento do protocolo.
O comando “ping” gera pacotes ICMP com mensagens de pedido e resposta –
echo request e echo reply - que contêm os endereços de origem e destino.
Cada pacote ethernet transmitido é diferenciado com base no seu cabeçalho:
no caso de ser um pacote IP, o seu cabeçalho terá o valor 0x0800; por outro lado se
se tratar de um pacote ARP, o cabeçalho será igual a 0x0806.
4
2.2 – Virtual LAN
Na segunda parte configuraram-se duas Virtual Lans e atribuíram-se as
respetivas interfaces, garantido a conformidade com o especificado – tux 1 e 4
pertencentes à primeira, e tux 2 pertencente à segunda.
Em primeiro lugar foram criadas as duas vlans no switch e adicionados os tuxs,
sendo que para isso foi necessário configurar o tux2. Os comandos apresentam-se
nas tabelas 3.b.i e 3.b.ii.
Após nova utilização do comando ping verificou-se que existia conectividade
entre os TUXs 1 e 4, mas nenhum destes podia comunicar com o tux2. Isto acontece
devido ao facto de estarem em redes distintas (e como tal o resultado de um pacote
enviado será “Destination Unreachable”). Por outro lado fez-se também o teste em
relação aos endereços de broadcast (ping –b [...]) e constatou-se que também se
encontram em broadcasts distintos, pelo que se conclui que há um endereço de
broadcast para cada vlan.
2.3 – Configuração de um router em Linux
Neste passo, transformámos o tux4 num router, de forma a permitir a
comunicação entre o tux1 e o tux2. Para isso foram utilizados os comandos conforme
as tabelas 3.c.i e 3.c.ii.
Esta configuração faz com que cada interface do tux4 esteja ligada a uma vlan,
e que este possa funcionar como router, reencaminhando os pacotes recebidos. De
seguida foi necessário reconfigurar os tuxs 1 e 2 com os comandos da tabela 3.c.iii, de
modo a garantir a sua comunicação. Por fim, a comunicação entre os dois TUXs, 1 e 2,
já é possível.
As rotas disponíveis em cada tux garantem que os pacotes transitam entre as
duas sub-redes, passando pelo tux4. Observou-se também a troca de pacotes ARP
para o reconhecimento do tux2, uma vez que a tabela ARP dos tuxs 1 e 4 ainda não
tinha uma entrada com o seu endereço.
2.4 – Configurar Router commercial e implementar NAT
Nesta parte, foi adicionado à rede um router comercial com o intuito de fornecer
acesso a uma rede externa aos tuxs anteriormente configurados.
5
A configuração do router passa por atribuir as interfaces para a rede
configurada respeitando as ligações feitas entre o router e o switch, e adicionar as
rotas para garantir a comunicação de todos os TUXs. A configuração utilizada pode
ser consultada na 3.d.i. Como se pode observar nesta tabela, as rotas estáticas são
adicionadas segundo o comando “ip route <ip_destino> <máscara> <gateway>”.
De seguida, o router foi definido como default gateway do quer do tux4
(interface eth1) quer do tux2. Para mostrar a existência de comunicação foi feito ping a
partir do tux1 para as interfaces do tux4 e do router.
Com esta configuração, os pacotes transitam do tux1 para o tux4 e to tux4 para
o router ou para o tux2, conforme o seu endereço de destino.
Neste ponto da experiência as tentativas de contacto com a rede exterior não
recebem resposta. Esta situação deve-se ao facto de os terminais exteriores não
terem forma de saber qual o endereço para onde devem responder dado que todos os
TUXs são vistos como tendo o mesmo endereço. Esta situação resolve-se recorrendo
à funcionalidade NAT do router comercial da bancada. Com esta funcionalidade, os
endereços da rede são mapeados para endereços públicos, e a resposta já é
concretizável. Mais uma vez, a configuração feita pode ser consultada na tabela 3.d.ii.
Nesta configuração optou-se por incluir o tux4 no conjunto de endereços a
mapear, garantindo assim a sua comunicação com o exterior.
A configuração feitaa até agora é apresentada na imagem seguinte:
2.5 – DNS
Com o objetivo de se poder utilizar diretamente o hostname em vez do seu
endereço IP, foi implementada a funcionalidade DNS. Desta vez, a configuração
passou por editar o ficheiro resolv.conf de cada TUX (localizado em /etc/resolv.conf) e
mudar o seu conteúdo para:
6
Search netlab.fe.up.pt
Nameserver 172.16.1.2
Com esta configuração foi então possível fazer, por exemplo, “ping
www.sapo.pt” e obter resposta do servidor. Este pedido subdivide-se em duas fases:
inicialmente, o tux pergunta ao servidor DNS (172.16.1.2) qual o IP que corresponde
ao endereço fornecido. O servidor responde com vários endereços IP, dos quais é
escolhido o primeiro para o envio dos pacotes ICMP.
2.6 – Protocolo FTP
No teste da aplicação desenvolvida anteriormente foi feita uma transferência de
um ficheiro com um cerca de 600MB a partir do servidor ftp da Universidade do Porto.
Uma vez que a rede da universidade é bastante complexa, o comportamento
observado afastou-se ligeiramente da situação ideal, em que haveria um pico de
velocidade inicial, vindo a estabilizar posteriormente.
Na situação real, o gráfico apresenta uma forma mais irregular, evidenciando
os diversos fatores que influenciam a velocidade de transferência de um ficheiro:
Fig. 1 Transferência de um único TUX
Na situação seguinte, o cliente ftp foi executado em dois dos Tuxs (1 e 2), de
modo a observar a gestão de tráfego feita. Nesta situação é possível observar um
decréscimo da velocidade no tux1 quando o tux2 inicia a transferência. De igual modo,
o pico de velocidade atingido no tux2 é menor do que aquele atingido inicialmente no
tux1. Estes factos demonstram a execução da política de gestão de congestionamento
de tráfego que é feita pelos intervenientes no processo.
A figura seguinte evidencia o decréscimo da velocidade de transferência no
tux1, quando o tux2 inicia outra transferência mostrando um equilíbrio de pacotes que
transitam na rede para cada tux:
7
Fig. 2 Transferência do TUX1, em simultâneo com o TUX2
A comunicação com o servidor é feita através de dois canais: o canal de
controlo onde transitam todos os comandos para a obtenção do ficheiro, e o canal de
dados, por onde são enviados todos os dados deste. É feito um pedido inicial ao
servidor de DNS pelo endereço IP do servidor FTP sendo seguido pelo processo de
transferência sobre o protocolo TCP.
Conclusão
Terminado o projeto foram consolidados os conhecimentos acerca das redes
de computadores, bem como a sua importância para a atualidade. Por outro lado, os
conceitos relacionados com os diversos protocolos envolvidos (TCP, ARP, entre
outros) foram mais facilmente interiorizados graças à sua divisão em experiências
laboratoriais.
Foi também evidente a importância da organização das redes de computadores
em sub-redes e a razão pela qual se tem dado cada vez mais importância a
mecanismos de controlo de tráfego e de resolução de congestionamentos.
8
ANEXOS
1. Imagens de execução
2. LOGS parciais
a. Protocolo ARP
Source
Destination
Protocol
Info
Kye_08:d5:b3
Broadcast
ARP
Who
has
172.16.40.254?
Tell
172.16.40.1
Hewlett-
Kye_08:d5:b
_c7:64:8e
3
172.16.40.1
172.16.40.25
ARP
172.16.40.254 is at 00:21:5a:c7:64:8e
ICMP
Echo (ping) request
ICMP
Echo (ping) reply
4
172.16.40.254
172.16.40.1
Log 1 – funcionamento do protocolo ARP
b. Comunicação do tux1 com as restantes interfaces
tux1 >> ping 172.16.40.254
(TUX4.eth0)
64 bytes from 172.16.40.254: icmp_seq=1 ttl=64 time=0.199ms
tux1>> ping 172.16.41.253
(TUX4.eth1)
64 bytes from 172.16.41.253: icmp_seq=1 ttl=64 time=0.190ms
9
tux1>> ping 172.16.41.254
(Router)
64 bytes from 172.16.41.254: icmp_seq=1 ttl=254 time=0.563ms
Log 2 – Comunicação do tux1 com as interfaces na rede
3. CONFIGURAÇÕES
a. Exp1
i. Configurar interfaces tux1 e 4
tux1 >> ifconfig eth0
//ativar interface eth0
tux1>> ifconfig eth0 172.16.Y01/24
//atribuir endereço IP
tux4>> ifconfig eth0 up
tux4>> ifconfig eth0 172.16.Y0.254/24
Configuração 1 – interfaces dos tuxs 1 e 4
b. Exp2
i. Interface do Tux2
tux2 >> ifconfig etho up
//ativar interface eth0
tux2>> ifconfig eth0 172.16.Y1./24
//endereço pertence a vlan1
Configuração 2 – interface do tux2
ii. Configuração do Switch
>>vlan Y0
//criar virtual lan 0
>>vlan Y1
//criar virtual lan 1
>>interface fastethernet 0/1
//interface do TUX1
>>switchport access vlan Y0
//atribuir interface à vlan0
>>interface fastethernet 0/4
//interface do TUX4
>>switchport access vlan Y0
//atribuir interface à vlan0
>>interface fasethernet 0/2
//interface do TUX2
>>switchport access vlan Y1
//atribuir interface à vlan1
Configuração 3 – configuração do switch
10
c. Exp3
i. Interface tux4.eth1
tux4 >> ifconfig eth1 up
//ativar interface eth1
tux4>> ifconfig eth1 172.16.Y1.253
//atribuir endereço IP
tux4>> echo 1 > /[...]/IP_FORWARD
//ativar reencaminhamento
tux4>> echo 0 > /[...]/ICMP_ECHO_IGNORE_BROADCASTS
Configuração 4 – interface eth1 do tux4
ii. Adicionar interface à vlan1
>>interface fasethernet 0/5
//interface eth1 do TUX4
>>switchport access vlan Y1
//atribuir interface à vlan1
Configuração 5 - Adicionar interface eth1 à vlan1
iii. Reconfiguração das interfaces
tux1>> route add default gw 172.16.Y0.254
//interface eth0 do TUX4
tux2>>route add default gw 172.16.Y1.253
// interface eth1 do TUX4
Configuração 6 – reconfigurar interfaces
d. Exp4
i. Configurar router comercial
>>interface gigabitethernet 0/0
//interface 0
>>ip address 172.16.Y1.254 255.255.255.0
>>interface gigabitethernet 0/1
//interface 1
>>ip address 172.16.1.Y9 255.255.255.0
>>ip route 0.0.0.0 0.0.0.0 172.16.1.254
//rede exterior
>>ip route 172.16.Y0.0 255.255.255.0
//vlanY0
Configuração 7 – comandos para a configuração do router
11
ii. Configurar NAT
>> interface gigabitethernet 0/0
>>no shutdown
>>ip nat inside
>> interface gigabitethernet 0/1
>>no shutdown
>>ip nat outside
>>ip nat pool ovrld 172.16.1.49 172.16.1.49 prefix 24
>>ip nat inside source list 1 pool ovrld overload
>>access-list 1 permit 172.16.40.0 0.0.0.255
>> access-list 1 permit 172.16.41.0 0.0.0.255
Configuração 8 – configuração do serviço NAT no router
12
4. código fonte do cliente FTP
5. #include <stdio.h>
6. #include <sys/types.h>
7. #include <sys/socket.h>
8. #include <netinet/in.h>
9. #include <arpa/inet.h>
10.
#include <stdlib.h>
11.
#include <unistd.h>
12.
#include <signal.h>
13.
#include <netdb.h>
14.
#include <strings.h>
15.
#include <string.h>
16.
#include <errno.h>
17.
#include <netdb.h>
18.
19.
#define TRUE 1
20.
#define FALSE 0
21.
#define SIZE 256
22.
23.
//TAMANHO MAXIMO DA RESPOSTA DO SERV
24.
#define MSG_LEN 1024
25.
26.
//PORTA TCP DO SERVIDOR
27.
#define SERVER_PORT 21
28.
29.
char SERVER_ADDR[SIZE];
30.
31.
32.
//RECEBER buff DO SERVIDOR
33.
int receive_cmd(int fd, char* buffer) {
34.
//sleep(1);
35.
memset(buffer, (char) '\0', strlen(buffer));
36.
return read(fd, buffer, MSG_LEN);
37.
}
38.
39.
40.
//ENVIAR COMANDO PARA O SERVIDOR
41.
void send_cmd(int fd, char* buffer) {
42.
char tmp_cmd[SIZE];
43.
memcpy(tmp_cmd, buffer, sizeof(char)*SIZE);
44.
printf("\n>> %s", tmp_cmd);
45.
strcat(tmp_cmd, "\r\n");
46.
write(fd, tmp_cmd, sizeof(char) * strlen(tmp_cmd));
47.
}
48.
49.
50.
int main(int argc, char** argv){
51.
52.
53.
if(argc < 2)
54.
{
55.
printf("USAGE: %s
ftp://<username>:<password>@<host>/<url_path>\n", argv[0]);
56.
exit(1);
57.
}
58.
59.
struct hostent *h;
60.
61.
//LIG. CONTROLO
62.
int sockfd = (int) NULL;
13
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
struct sockaddr_in server_addr;
//LIG. DADOS
int sockfd2 = (int) NULL;
struct sockaddr_in server_addr2;
char host[SIZE];
//PATH DO FICHEIRO
char file_path[SIZE];
//USER
char user_name[SIZE];
//PASSWORD
char pw[SIZE];
//BUFFER PARA AS RESPOSTAS DO SERV.
char buff[MSG_LEN];
//FICHEIRO DESTINO
FILE* f=NULL;
//USER E PASS ESPECIFICADOS
if(strchr(argv[1], '@') != NULL)
{
sscanf(argv[1],
"ftp://%[^:]:%[^@]@%[^/]/%[^\n]",user_name, pw, host, file_path);
85.
}
86.
87.
//USER E PASS PRE' DEFINIDOS
88.
else {
89.
sscanf(argv[1], "ftp://%[^/]/%[^\n]", host,
file_path);
90.
memcpy(user_name, "anonymous", sizeof(char) * SIZE);
91.
memcpy(pw, "[email protected]", sizeof(char) *
SIZE);
92.
}
93.
94.
printf("\nLIGAR A: %s\nUTILIZADOR: %s\nPASSWORD: %s", host,
user_name, pw);
95.
96.
if ((h=gethostbyname(host)) == NULL) {
97.
herror("gethostbyname");
98.
exit(1);
99.
}
100.
101.
memcpy(SERVER_ADDR, inet_ntoa(*((struct in_addr *)h>h_addr)), sizeof(char)*SIZE);
102.
103.
//SOCKET PARA LIG DE CONTROLO
104.
/*server address handling*/
105.
bzero((char*)&server_addr,sizeof(server_addr));
106.
server_addr.sin_family = AF_INET;
107.
server_addr.sin_addr.s_addr = inet_addr(SERVER_ADDR); /*32
bit Internet address network byte ordered*/
108.
server_addr.sin_port = htons(SERVER_PORT);
109.
/*server TCP port must be network byte ordered */
110.
/*open an TCP socket*/
111.
if ((sockfd = socket(AF_INET,SOCK_STREAM,0)) < 0) {
112.
perror("socket()");
113.
exit(0);
114.
}
115.
116.
/*connect to the server*/
117.
if(connect(sockfd,
14
118.
(struct sockaddr *)&server_addr,
119.
sizeof(server_addr)) < 0){
120.
perror("connect()");
121.
exit(0);
122.
}
123.
124.
printf("\nABERTO SOCKET [CONTROLO] EM [ %s:%d ]\n",
SERVER_ADDR, SERVER_PORT);
125.
while(TRUE)
126.
{
127.
receive_cmd(sockfd, buff);
128.
if(strncmp(buff, "220", 3) != 0)
129.
{
130.
131.
printf("\nERRO: ESPERAVA CODIGO 220 [%s]...",
buff);
132.
break;
133.
}
134.
135.
//USER + PASS = 230
136.
char user[SIZE];
137.
sprintf(user, "user %s", user_name);
138.
//ENVIAR USER
139.
send_cmd(sockfd, user);
140.
//ESPERAR RESPOSTA
141.
receive_cmd(sockfd, buff);
142.
printf("\n<< %s", buff);
143.
144.
char pass[SIZE];
145.
sprintf(pass, "pass %s", pw);
146.
//ENVIAR PASS
147.
send_cmd(sockfd, pass);
148.
//ESPERAR RESPOSTA
149.
receive_cmd(sockfd, buff);
150.
printf("\n<< %s", buff);
151.
152.
if(strncmp(buff, "230", 3) != 0)
153.
{
154.
printf("\nERRO: LOGIN INCORRETO");
155.
break;
156.
}
157.
158.
//ENVIAR COMANDO SERVIDOR -> MODO PASSIVO
159.
send_cmd(sockfd, "pasv");
160.
receive_cmd(sockfd, buff);
161.
printf("\n<< %s", buff);
162.
if(strncmp(buff, "227", 3) != 0) {
163.
printf("\nERRO: MODO PASSIVO [ %s ]", buff);
164.
break;
165.
}
166.
167.
//CALCULAR PORTA DA LIG DADOS
168.
int msB, lsB;
169.
sscanf(buff, "%*[^(](%*d,%*d,%*d,%*d,%d,%d)\n", &msB,
&lsB);
170.
int dest_port = msB*SIZE + lsB;
171.
172.
//ABRIR SOCKET LIG DADOS
173.
/*server address handling*/
174.
bzero((char*)&server_addr2,sizeof(server_addr2));
175.
server_addr2.sin_family = AF_INET;
15
176.
server_addr2.sin_addr.s_addr =
inet_addr(SERVER_ADDR);
177.
/*32 bit Internet address network byte ordered*/
178.
server_addr2.sin_port = htons(dest_port);
179.
/*server TCP port must be network byte ordered */
180.
/*open an TCP socket*/
181.
if ((sockfd2 = socket(AF_INET,SOCK_STREAM,0)) < 0) {
182.
perror("socket()");
183.
exit(0);
184.
}
185.
/*connect to the server*/
186.
if(connect(sockfd2,
187.
(struct sockaddr *)&server_addr2,
188.
sizeof(server_addr2)) < 0){
189.
perror("connect()");
190.
exit(0);
191.
}
192.
printf("\nABERTO SOCKET [DADOS] EM [ %s:%d ]",
SERVER_ADDR, dest_port);
193.
//ENVIAR PEDIDO RETR
194.
195.
char retr_cmd[SIZE];
196.
sprintf(retr_cmd, "retr %s", file_path);
197.
send_cmd(sockfd, retr_cmd);
198.
char* fileName;
199.
fileName = strrchr(file_path,'/');
200.
if(fileName != NULL) {
201.
fileName++;
202.
}
203.
else{
204.
fileName = file_path;
205.
}
206.
receive_cmd(sockfd, buff);
207.
printf("\n<< %s", buff);
208.
if(strncmp(buff, "550", 3) == 0) {
209.
printf("\nERRO: ACESSO AO FICHEIRO [ %s",
buff);
210.
exit(-1);
211.
}
212.
//ABRIR FICHEIRO PARA ESCRITA
213.
f = fopen((const char *) fileName, "wb");
214.
float n_bytes = 1.0;
215.
float total_bytes = 0.0;
216.
while(n_bytes != 0) {
217.
int bytes = receive_cmd(sockfd2, buff);
218.
n_bytes = fwrite(buff, sizeof(char), bytes, f);
219.
if(total_bytes < 1024)
220.
{
221.
printf("\n[ %f B GRAVADOS ]",
total_bytes+=n_bytes);
222.
}
223.
else if(total_bytes >= 1024 && total_bytes <
1048576)
224.
{
225.
printf("\n[ %.02f kB GRAVADOS ]",
(total_bytes+=n_bytes)/1024);
226.
}
227.
else
228.
{
229.
printf("\n[ %.02f MB GRAVADOS ]",
(total_bytes+=n_bytes)/1048576);
16
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
}
}
printf("\nTransferencia Concluida!");
break;
}
printf("\nENCERRAR SOCKETS\n");
if(f != NULL)
fclose(f);
if(sockfd2 != (int) NULL)
close(sockfd2);
if(sockfd != (int) NULL)
close(sockfd);
exit(0);
}
5. Makefile
all: download
client: download
./download
ftp://ftp.up.pt/pub/openoffice/packages/10/OOo_3.3.0_Win_x86_langpack_gu.exe
small: download
./download ftp://ftp.up.pt/pub/robots.txt
clienttcp: download.c
gcc -Wall -o download.o -c download.c
gcc -Wall -o app download.o
6. Logs capturados
a) Preenchimento da tabela ARP (exp1)
No.
Time
1 0.000000
60
Source
Destination
Cisco_d4:1c:03
Protocol Length Info
Spanning-tree-(for-bridges)_00 STP
Conf. Root = 32768/30/30:37:a6:d4:1c:00 Cost = 0 Port = 0x8003
Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
IEEE 802.3 Ethernet
Logical-Link Control
Spanning Tree Protocol
17
No.
Time
2 1.188901
Source
Destination
Kye_08:d5:b3
Protocol Length Info
Broadcast
ARP
42
Who has
172.16.40.254? Tell 172.16.40.1
Frame 2: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)
No.
Time
Source
3 1.189019
Destination
Hewlett-_c7:64:8e
Protocol Length Info
Kye_08:d5:b3
ARP
60
172.16.40.254 is at 00:21:5a:c7:64:8e
Frame 3: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Address Resolution Protocol (reply)
No.
Time
4 1.189034
Source
Destination
172.16.40.1
Protocol Length Info
172.16.40.254
ICMP
98
Echo
(ping) request id=0xe857, seq=1/256, ttl=64
Frame 4: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
b)Virtual Lans (exp2) – Não há conetividade com o TUX2
No.
Time
4 1.582047
Source
172.16.40.1
Destination
172.16.40.254
Protocol Length Info
ICMP
98
Echo (ping)
request id=0x4160, seq=1/256, ttl=64
Frame 4: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
18
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 172.16.40.254
(172.16.40.254)
Internet Control Message Protocol
No.
Time
5 1.582183
reply
Source
Destination
172.16.40.254
172.16.40.1
Protocol Length Info
ICMP
98
Echo (ping)
id=0x4160, seq=1/256, ttl=64
Frame 5: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 172.16.40.254 (172.16.40.254), Dst: 172.16.40.1
(172.16.40.1)
Internet Control Message Protocol
No.
Time
6 2.004679
Source
Cisco_d4:1c:03
Destination
Protocol Length Info
Spanning-tree-(for-bridges)_00 STP
60
Conf. Root = 32768/40/30:37:a6:d4:1c:00 Cost = 0 Port = 0x8003
Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
IEEE 802.3 Ethernet
Logical-Link Control
Spanning Tree Protocol
No.
Time
Source
Destination
Protocol Length Info
19
7 2.585934
172.16.40.1
172.16.40.254
ICMP
98
Echo (ping)
request id=0x4160, seq=2/512, ttl=64
Frame 7: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 172.16.40.254
(172.16.40.254)
Internet Control Message Protocol
No.
Time
8 2.586057
reply
Source
Destination
172.16.40.254
172.16.40.1
Protocol Length Info
ICMP
98
Echo (ping)
id=0x4160, seq=2/512, ttl=64
Frame 8: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 172.16.40.254 (172.16.40.254), Dst: 172.16.40.1
(172.16.40.1)
Internet Control Message Protocol
c)TUX4 como router – evidenciar conetividade entre TUX2 e TUX1
No.
Time
7 3.499337
Source
172.16.40.1
Destination
172.16.40.254
Protocol Length Info
ICMP
98
Echo (ping)
request id=0x0f19, seq=2/512, ttl=64
20
Frame 7: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 172.16.40.254
(172.16.40.254)
Internet Control Message Protocol
No.
Time
8 3.499462
reply
Source
Destination
172.16.40.254
172.16.40.1
Protocol Length Info
ICMP
98
Echo (ping)
id=0x0f19, seq=2/512, ttl=64
Frame 8: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 172.16.40.254 (172.16.40.254), Dst: 172.16.40.1
(172.16.40.1)
Internet Control Message Protocol
No.
Time
9 3.901278
Source
172.16.40.1
Destination
172.16.41.253
Protocol Length Info
ICMP
98
Echo (ping)
request id=0x1019, seq=1/256, ttl=64
Frame 9: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 172.16.41.253
(172.16.41.253)
21
Internet Control Message Protocol
No.
Time
10 3.901407
reply
Source
Destination
172.16.41.253
172.16.40.1
Protocol Length Info
ICMP
98
Echo (ping)
id=0x1019, seq=1/256, ttl=64
Frame 10: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 172.16.41.253 (172.16.41.253), Dst: 172.16.40.1
(172.16.40.1)
Internet Control Message Protocol
No.
Time
11 4.007141
Source
Destination
Cisco_d4:1c:03
Protocol Length Info
Spanning-tree-(for-bridges)_00 STP
60
Conf. Root = 32768/40/30:37:a6:d4:1c:00 Cost = 0 Port = 0x8003
Frame 11: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
IEEE 802.3 Ethernet
Logical-Link Control
Spanning Tree Protocol
No.
Time
12 4.503331
Source
172.16.40.1
Destination
172.16.40.254
Protocol Length Info
ICMP
98
Echo (ping)
request id=0x0f19, seq=3/768, ttl=64
22
Frame 12: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 172.16.40.254
(172.16.40.254)
Internet Control Message Protocol
No.
Time
13 4.503473
reply
Source
Destination
172.16.40.254
172.16.40.1
Protocol Length Info
ICMP
98
Echo (ping)
id=0x0f19, seq=3/768, ttl=64
Frame 13: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 172.16.40.254 (172.16.40.254), Dst: 172.16.40.1
(172.16.40.1)
Internet Control Message Protocol
No.
Time
14 4.907332
Source
172.16.40.1
Destination
172.16.41.253
Protocol Length Info
ICMP
98
Echo (ping)
request id=0x1019, seq=2/512, ttl=64
Frame 14: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 172.16.41.253
(172.16.41.253)
23
Internet Control Message Protocol
No.
Time
15 4.907471
reply
Source
Destination
172.16.41.253
172.16.40.1
Protocol Length Info
ICMP
98
Echo (ping)
id=0x1019, seq=2/512, ttl=64
Frame 15: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 172.16.41.253 (172.16.41.253), Dst: 172.16.40.1
(172.16.40.1)
Internet Control Message Protocol
d)Transferência do ficheiro
No.
Time
Source
4 3.587566
172.16.40.1
Destination
172.16.1.2
Protocol Length Info
DNS
69
Standard
query A ftp.up.pt
Frame 4: 69 bytes on wire (552 bits), 69 bytes captured (552 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 172.16.1.2
(172.16.1.2)
User Datagram Protocol, Src Port: 59492 (59492), Dst Port: domain (53)
24
Domain Name System (query)
No.
Time
Source
5 3.588737
Destination
172.16.1.2
172.16.40.1
Protocol Length Info
DNS
337
Standard
query response A 193.136.37.8
Frame 5: 337 bytes on wire (2696 bits), 337 bytes captured (2696 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 172.16.1.2 (172.16.1.2), Dst: 172.16.40.1
(172.16.40.1)
User Datagram Protocol, Src Port: domain (53), Dst Port: 59492 (59492)
Domain Name System (response)
No.
Time
Source
6 3.589074
172.16.40.1
Destination
193.136.37.8
Protocol Length Info
TCP
74
48687 > ftp
[SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=2196501
TSecr=0 WS=32
Frame 6: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 193.136.37.8
(193.136.37.8)
Transmission Control Protocol, Src Port: 48687 (48687), Dst Port: ftp (21), Seq: 0,
Len: 0
25
No.
Time
7 3.590019
Source
Destination
193.136.37.8
172.16.40.1
Protocol Length Info
TCP
74
ftp > 48687
[SYN, ACK] Seq=0 Ack=1 Win=65228 Len=0 MSS=1460 WS=16 SACK_PERM=1
TSval=1943451950 TSecr=2196501
Frame 7: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 193.136.37.8 (193.136.37.8), Dst: 172.16.40.1
(172.16.40.1)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 48687 (48687), Seq: 0,
Ack: 1, Len: 0
No.
Time
8 3.590075
Source
172.16.40.1
Destination
193.136.37.8
Protocol Length Info
TCP
66
48687 > ftp
[ACK] Seq=1 Ack=1 Win=5856 Len=0 TSval=2196502 TSecr=1943451950
Frame 8: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 193.136.37.8
(193.136.37.8)
Transmission Control Protocol, Src Port: 48687 (48687), Dst Port: ftp (21), Seq: 1,
Ack: 1, Len: 0
No.
Time
9 3.597304
Source
193.136.37.8
Destination
172.16.40.1
Protocol Length Info
FTP
106
Response:
220 Bem-vindo à Universidade do Porto
26
Frame 9: 106 bytes on wire (848 bits), 106 bytes captured (848 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 193.136.37.8 (193.136.37.8), Dst: 172.16.40.1
(172.16.40.1)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 48687 (48687), Seq: 1,
Ack: 1, Len: 40
File Transfer Protocol (FTP)
No.
Time
Source
10 3.597436
172.16.40.1
Destination
193.136.37.8
Protocol Length Info
TCP
66
48687 > ftp
[ACK] Seq=1 Ack=41 Win=5856 Len=0 TSval=2196504 TSecr=1943451951
Frame 10: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 193.136.37.8
(193.136.37.8)
Transmission Control Protocol, Src Port: 48687 (48687), Dst Port: ftp (21), Seq: 1,
Ack: 41, Len: 0
No.
Time
Source
11 3.597545
172.16.40.1
Destination
193.136.37.8
Protocol Length Info
FTP
82
Request:
user anonymous
Frame 11: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
27
Ethernet II, Src: Kye_08:d5:b3 (00:c0:df:08:d5:b3), Dst: Hewlett-_c7:64:8e
(00:21:5a:c7:64:8e)
Internet Protocol Version 4, Src: 172.16.40.1 (172.16.40.1), Dst: 193.136.37.8
(193.136.37.8)
Transmission Control Protocol, Src Port: 48687 (48687), Dst Port: ftp (21), Seq: 1,
Ack: 41, Len: 16
File Transfer Protocol (FTP)
No.
Time
12 3.598240
Source
193.136.37.8
Destination
172.16.40.1
Protocol Length Info
TCP
66
ftp > 48687
[ACK] Seq=41 Ack=17 Win=66592 Len=0 TSval=1943451951 TSecr=2196504
Frame 12: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Hewlett-_c7:64:8e (00:21:5a:c7:64:8e), Dst: Kye_08:d5:b3
(00:c0:df:08:d5:b3)
Internet Protocol Version 4, Src: 193.136.37.8 (193.136.37.8), Dst: 172.16.40.1
(172.16.40.1)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 48687 (48687), Seq: 41,
Ack: 17, Len: 0
28