UNIVERSIDAD DE EL SALVADOR

FACULTAD DE INGENIERIA Y
ARQUITECTURA
ESCUELA DE INGENIERIA ELECTRICA
REDES DE COMPUTADORA I

CATEDRÁTICO:

ING. HUGO COLATO

LABORATORIO:
“GUIAS SOBRE PROTOCOLOS ARP, ICMP-IP y TCP”

ESTUDIANTES:
BR. FRANCISCO JAVIER CRUZ CAMPOS CC12020
BR. RONNY EDGARDO MATA ESCOBAR
ESCOBA ME13001
BR. OSCAR AMILCAR VIZCARRA DURAN VD14004

Ciudad Universitaria, 11 Abril de 2019

 INTRODUCCION
ARP son las siglas en inglés de Address Resolution Protocol (Protocolo de resolución de
direcciones). ARP es un protocolo del nivel de enlace de datos responsable de encontrar la dirección
hardware que corresponde a una determinada dirección IP, para ello se envía un paquete (ARP
request) a la dirección de multidifusión de la red (broadcast) , que contiene la dirección IP por la
que se pregunta, y se espera a que esa máquina (u otra) responda (ARP reply) con la dirección física
que le corresponde.
Para el desarrollo de estas guías de laboratorio nos dividiremos en 3 partes, que se encuentran
siempre dentro del mismo protocolo ARP, las cuales son: protocolo ARP, ARP + ICMP y TCP,
dentro de las cuales se nos da una introducción general del protocolo, arquitectura del modelo de
red TCP/IP, descripción del protocolo y su funcionamiento, para posteriormente llevar a cabo el
desarrollo de las asignaciones de cada guía de laboratorio.

Debemos recordar al momento de trabajar con este protocolo que cada nodo de una red IP tiene
tanto una dirección MAC como una dirección IP. Para enviar datos, el nodo debe utilizar ambas
direcciones. El nodo debe utilizar sus propias direcciones MAC e IP en los campos de origen y debe
proporcionar una dirección MAC y una dirección IP para el destino. Mientras que una capa OSI
superior proporciona la dirección IP del destino, pero el nodo de envío necesita encontrar la
dirección MAC del destino para un enlace de Ethernet determinado. Ese es el propósito del
protocolo ARP.

El protocolo ARP se basa en determinados tipos de mensajes Ethernet de broadcast y unicast,

denominados “solicitudes ARP” y “respuestas ARP”.

El protocolo ARP ofrece dos funciones básicas:

 Resolución de direcciones IPv4 a direcciones MAC

 Mantenimiento de una tabla de las asignaciones

El modelo OSI describe las comunicaciones de red ideales con una familia de protocolos. TCP/IP
no se corresponde directamente con este modelo. TCP/IP combina varias capas OSI en una única
capa, o no utiliza determinadas capas. El protocolo IP y sus protocolos de enrutamiento asociados
son posiblemente la parte más significativa del conjunto TCP/IP. El protocolo IP se encarga de:
Direcciones IP, Comunicaciones de host a host, Formato de paquetes, Fragmentación.
El protocolo de resolución de direcciones (ARP) se encuentra conceptualmente entre el vínculo de
datos y las capas de Internet. ARP ayuda al protocolo IP a dirigir los datagramas al sistema receptor
adecuado asignando direcciones Ethernet (de 48 bits de longitud) a direcciones IP conocidas (de 32
bits de longitud). Todos estos importantes protocolos necesarios para establecer las conexiones
entre los equipos informáticos se estudiaran de manera practica en los laboratorios a realizar y de
los cuales el presente informe recoge nuestras experiencias con estos protocolos obtenidas mediante
las herramientas informáticas mencionadas previamente.
 DESARROLLO DE LAS GUIAS
GUIA PROTOCOLO ARP
1) Obtén las direcciones MAC y las direcciones IP de todos los adaptadores de red
que tiene tu ordenador. Indica como lo has obtenido y cuáles son.

Mediante el uso del comando ipconfig/all se obtuvieron los siguientes resultados

Fig. 1

Podemos ver en la Fig. 1 la información que se solicitó con el uso del comando indicado
anteriormente. Así mismo se puede apreciar que el único que presenta IP es el adaptador de
Ethernet, siendo el que se utilizó en el momento de la prueba, habiendo sido asignada por DHCP y
observamos las direcciones físicas, siendo distintas una de la otra.
2) Con la información obtenida en el apartado anterior, contesta a las siguientes preguntas
justificando la respuesta.
 ¿A qué tipo de red pertenece tu host?
Pertenece a una red LAN
 ¿Cuál es la IP de dicha red?
La IP de la Red es la 192.168.1.7 como se muestra en la figura 1.

3) Obtén la dirección IP de la puerta de enlace (router) de la red del laboratorio. Indica como
la has obtenido y cuál es.

Fig. 2
Esta dirección IP del Gateway es la que le pertenece al router usado en la práctica, y se
obtuvo mediante el comando ipconfig.

4) ¿Cuál es la dirección MAC del router (puerta de enlace) que te conecta con el resto de la
FIA?

Para encontrar la dirección MAC del Gateway es necesario hacer un ping al Gateway, el cual
envía paquetes de solicitud para la IP de esta y obtiene paquetes respuesta provenientes de la
misma, por lo cual con el uso del comando arp –a en la terminal se puede observar a
continuación como se lleno la tabla con la dirección IP y la dirección MAC del Gateway.

Fig. 3

Gracias a este comando, la dirección MAC del router es: 32-91-8f-29-37-a0

 5) Capturar mediante el analizador de protocolos wireshark un paquete procedente de
una conexión desde tu PC a otra máquina de tu misma aula. Pon el programa
wireshark en modo captura y después puedes en otra ventana hacer un ping otra máquina de
tu aula, por ejemplo: ping 192.168.169.X, donde X identifica el host de destino. Detén la
captura y analiza los paquetes capturados. El programa wireshark visualiza en la
ventana superior información general sobre los paquetes capturados. En la ventana
central hay información sobre los protocolos usados. Si pinchas en Address
Resolution Protocol se muestra la información relativa a la cabecera de la trama del
protocolo ARP. Comprueba que dicha información se corresponde con la estudiada en
teoría. Indica el contenido de dichos campos para los paquetes de petición y respuesta.

Fig. 4

Se envió un ping de la computadora WistronI a la HewlettP, ya que estas se encontraban dentro de

la misma Red y se conocían sus IP’s

Fig. 5. Se visualiza el paquete arp request en Wireshark

En la Fig. 5 se puede observar que la WistronI genera un broadcast (ARP REQUEST) al resto de
computadoras que se encontrasen dentro de la red, luego la maquina HewlettP le responde con un
REPLY (ARP). Con el uso de un filtro ARP se puede observar en la Fig. 5 el contenido del paquete
en donde indica que es REQUEST, y contiene la dirección IP y dirección MAC de la fuente, así
mismo se puede observar que contiene la dirección IP destino mas no la dirección MAC destino

Fig. 6 Se visualiza el paquete arp reply en Wireshark

En la Fig. 6 se puede apreciar que se trata del paquete REPLY, a diferencia de la Fig. 5, en esta se
observa que la fuente es la maquina HewlettP y el destino es la maquina WistronI. En esta ocasión
se puede apreciar que el paquete contiene la dirección IP fuente y lo más importante, la dirección
MAC fuente, es decir, la maquina HewlettP ya conoce la dirección IP y dirección MAC de la
maquina WistronI, indicando que el protocolo ARP ha tenido éxito.

6) Con los resultados del apartado 5 contesta

 ¿Qué dirección MAC de destino llevan los mensajes?
En lo que respecta a los paquetes REQUEST, no se conoce la dirección MAC destino.
En cambio los paquetes REPLY, si se conoce la dirección MAC destino, siento en este
caso la dirección MAC de WistronI (20:6a:8a:aa:ad:97)

 ¿Qué direcciones IP llevan los mensajes request y reply?

En este caso, las direcciones IP de los mensajes REQUEST y REPLY pertenecen a las
maquinas utilizadas, las cuales son: WistronI (192.168.1.7) y HewlettP (192.168.1.47)
  Consulta la tabla ARP del PC para comprobar si tiene la dirección MAC de destino.
En la imagen siguiente, se observara que ya se posee la dirección física de la PC
destino: [192.168.1.47 -----------> f4-30-b9-57-fb-70]

Fig. 7

7) Trascurrido un tiempo vuelve a repetir la captura del apartado 5. Pulsa Stop tras unos 20
segundos

Fig. 8

En este caso se puede observar en la Fig. 8, la captura #9, que este hace un REQUEST al Gateway y
este le responde inmediatamente en la siguiente captura, dejando un total de capturas ARP de 6 y no
de 4 como en las preguntas anteriores.
 Fig. 9

8) Repite de forma inmediata la captura. Pulsa stop tras unos 20 segundos. Examina y explica
qué ocurre en esta última captura.

Fig. 10
Esta captura no varía mucho con las anteriores, ya que se puede observar que al momento de
comprobar de nuevo la memoria caché de ARP, esta ya contiene la dirección MAC, es decir, al
volver a ejecutar el comando ping a la misma máquina las tramas ARP ya no aparecen debido a que
ya se conoce la dirección física de la otra.

9) Captura con el programa wireshark los paquetes ARP y TCP procedentes de una
conexión telnet desde tu PC a la máquina www.ues.edu.sv.
  ¿Qué dirección MAC de destino llevan los mensajes ARP?

Se puede observar que ARP REQUEST no posee la dirección MAC destino, en lugar de la dirección
MAC de ARP REPLY que es: 00:10:18:de:ad:05
 ¿Qué dirección IP llevan los mensajes ARP? ¿Por qué?

La dirección IP que llevan los mensajes ARP son de la PC de la UES, este sería: 192.168.0.18
Esto debido a que el HOST de www.ues.edu.sv no se encuentra en la misma red LAN, es decir, el
encargado de obtener la IP y MAC del HOST es el router, el cual hace peticiones usando recursos
disponibles como los DNS entre otros.
 GUIA DE PROTOCOLOS ARP, ICMP, TCP, IP

PROTOCOLO ARP
Como primer paso del procedimiento utilizaremos el comando ipconfig en nuestro caso para
terminal de Windows, tomando en cuenta que debemos capturar los datos del ordenador monitor,
dirección MAC, IP, red, puerta de enlace o Gateway. Mediante el programa WIRESHARK
utilizamos como filtro: ARP, y de esta manera capturamos los paquetes de tipo ARP.

De la figura anterior, obtenemos los datos requeridos para la práctica, los cuales son:
 Dirección MAC AC-B5-7D-48-4B-F4
 Dirección IP 192.168.1.26(Preferido)
 Mascara de Red 255.255.255.0
 Puesta de enlace 192.168.1.1

Mediante el uso del comando arp –a, obtenemos una tabla en el terminal con los datos siguientes:

Como siguiente paso del proceso utilizaremos el PING a la IP 192.168.1.26, que en esta practica
seria el otro equipo que esta disponible.

Luego en el programa wireshrak le colocamos el filtro ARP y realizamos las correspondientes

capturas sobre los paquetes de tipo ARP.
Como podemos observar ya con el filtro ARP aplicado podemos apreciar todos los protocolos ARP
realizados unicamente por los dispositivos conectados a nuestra red.Vemos que el broadcast
realizado mediante la PC con IP 192.168.1.26 realizamos la pregunta de quien tiene la IP
192.168.1.24 y en la siguiente captura observamos los resultados obtnidos mediante el request.
 1. ¿Cuántas tramas intervienen en la resolución ARP?

Las tramas que podemos observar son las tramas del reply el request, un total de 2 tramas.
2. Escriba la secuencia de las tramas involucradas justificando todas las direcciones
MAC e IP que aparecen

La representación gráfica puede verse en la figura anterior, la cual la secuencia en la trama es:
 Tipo de hardware
 Tipo de protocolo
 Tamaño de hardware
 Tamaño de protocolo
 Opcode (request)
 Dirección MAC de la PC a la que se le realiza el request.
 La IP de la PC a la que se realiza el request
 La dirección MAC del que envía el request.
 La dirección IP del que envía el request.

3. ¿Cuál es el estado de la memoria cache de ARP después del ping? Y ¿cuál es el estado
actual?
 Cuando realizamos el Ping, en el cache de ARP podemos observar las direcciones MAC en
una tabla generada mediante el ping y también podemos ver el IP de las maquinas a las que
se envió el ping.
 Cuando utilizamos el comando arp –a se genera una tabla en el cmd en el sistema
Windows, el cual nos dice el estado antes de realizar un ping, pudiendo obtener mediante
esta tabla las direcciones MAC y las IP de todos los dispositivos conectados a la red.
 En la primera tabla mostrada podemos ver que no contiene la información de las PC de
interés, debido a que aun no se ha solicitado el request siendo las diferencias.

4. ¿Existe información adicional en las tramas? ¿Cuál es la causa?

Debido al protocolo ARP podemos ver información adicional ya que el mismo protocolo requiere
de ella.
PROTOCOLO ICMP/PING
Usando el WIRESHARK filtramos IP e ICMP haciendo ping al otro equipo para poder observar los
paquetes:

Ahora podemos ver la información del reply y el request de los paquetes.

A. Request:
 B. Replay:

1. ¿Qué tipo de mensajes ICMP aparecen?

REQUEST y REPLY
2. Justificar la procedencia de cada dirección MAC e IP

Mediante el comando ping realizado mediante un ARP nos dan las MAC y las IP que
pertenecen a las terminales usadas.
3. Justificar la longitud de los paquetes de acuerdo a los formatos de trama de cada
protocolo involucrado. Estudiar los campos de la cabecera IP e ICMP. ¿Cuál es el
contenido del campo extra?

En la imagen anterior podemos observar que el tamaño de los paquetes es de 74 bytes

equivalentes a 592 bits.
Y en el campo extra tenemos el identificador, cabecera ICMP y el número de secuencia.
FRAGMENTACION IP
Realizamos un ping -n 1 -l 2000 192.168.1.24 como se muestra en la siguiente figura:

Acá vemos la información que el request nos proporciona.

La información que obtenemos del reply.

1. Describa el número de fragmentos correspondientes a cada datagrama.

Según la imagen anterior, el número de fragmentos 12

2. Describa y justifique la información en los campos flags, identificador y flag off de la
cabecera IP en cada datagrama.

Flag: 0x00b9
Identificador: 0x5e64 (24164)
Fragment offset: 128
ICMP TTL_exceeded
Con los mismos filtros usados anteriormente ejecutamos el comando siguiente:
ping -i 1 -n 1 192.168.200.5
La IP cambia por ser otro equipo:

La información proporcionada es para el request:

La información para el reply es la siguiente:

1. ¿Quién envía el mensaje ICMP_TLLexceeded?

El encargado es el equipo destino.

2. ¿Qué paquete causó el error?

No encontramos el paquete error.

3. ¿Cuál fue la causa del error?

En el supuesto caso que hubo un error en el envió de paquetes, la causa seria cuando el TTL no
llega a su destino. Jugando con el parámetro TTL del paquete, calcular el número de saltos
(routers) por los que debe pasar el datagrama hasta llegar a su destino.
 4. Estando en modo de captura realizar un ping a la dirección del otro equipo, evaluando
la ruta obtenida. Estudiar el campo adicional de la cabecera IP.

Los datos para el request son:

Para el reply son:

Ejecutando el comando tracert.

Tomando los datos de WIRESHARK

Visualización del request:

Visualización del reply.
 5. Comparar la salida del comando con los datos obtenidos en el apartado anterior y
estudiar los mensajes enviados por el comando tracert para evaluar la ruta

Los resultados que se obtuvieron tienen similitud con respecto a los anteriores

6. Jugando con el parámetro TTL del paquete, calcular el número de saltos (routers) por
los que debe pasar el datagrama hasta llegar a su destino.

Se calculó a prueba y error, teniendo como resultado 1 salto.

 GUIA PROTOCOLO TCP

En la máquina monitor se debe borrar los filtros previos y activos los filtros siguientes: ip and tcp
and host ip_pc_prueba.

Procedimiento:
Abrimos el programa wireshark desde el servidor y luego ponemos en la línea de comando ip del
cliente, en la siguiente figura se muestra la terminal que actuará como cliente:

IP terminal cliente
Obteniendo la dirección MC de esta IP.

Obteniendo MAC terminal del cliente

Ahora vamos a empezar a capturar datos del terminal.
 Activar el modo captura.

Mac terminal cliente

Ya que el programa wireshark está abierto, este está capturando los paquetes TCP/IP de el cliente
que falta por ser configurada.

Desde el PC de prueba ejecutar el programa Socket Workbench en modo cliente.

Opciones:
Servidor: <IP Servidor Linux>
- Puerto 9
Presionamos el botón Connect, esta establece una conexión con la máquina.
Luego el botón Disconnect.
Así es como hacemos una conexión y una desconexión TCP sin transferencia de datos.

Procedimiento:
Ahora configuramos un servidor en linux, por medio de XAMMP configurado para tener habilitado
el puerto 9, la siguiente figura muestra la IP del servidor con la ejecución de XAMMP ejecutándose

Parametros servidor Linux

Ingresamos los datos del servidor en socket workbench, este se conecta/desconecta y se capturamos
los datos con la herramienta wireshark como se muestra en la siguiente figura:

Conexión/Desconexión

 En el programa WireShark suspender la captura y estudiar las tramas involucradas.

Procedimiento:
Wireshark muestra los datos en la siguiente figura, podemos ver que son 9 frames

Captura de paquetes
Discusión:

a) ¿Qué tipos de segmentos TCP aparecen?

La figura superior muestra las tramas enumeradas, encontramos 9 y contienen segmentos del
protocolo TCP.

b) Justificar los segmentos aparecidos en función de la descripción previa del

protocolo, analizando el mecanismo de conexión y la doble desconexión.
En la siguiente figura podemos observar la solicitud de conexión previo al envió de datos, esto se
logra a partir de 3 tramas que es la información que nos presenta wireshark donde

Los 3 primeros marcos establecen una conexión debida a banderas activas, los marcos 4 y 5 son el
envío de datos y los marcos 6 y 9 son de solicitud, confirmación y aprobación de desconexión, en
los demás marcos encontramos las banderas ACK en marco 7; bandera FIN, ACK en marco 8 y
bandera ACK en marco 9.
 c) Justificar el contenido de los diferentes campos de la cabecera TCP en función
del tipo de segmento. Hacer hincapié especialmente en los campos Número de
secuencia y flags.
Aquí el dato que corresponde al Máximo Tamaño de Segmento se difunde en el campo de opciones
de segmentos que tienen la bandera SYN y SYN/ACK activado, estas son las tramas 1,2 y 4, para
todo el valor máximo de tamaño en segmento es el mismo igual como se presenta continuación.

Las banderas las encontramos en la sección de flags y está acorde a la teoría presentada: ACK: Si
vale 1 indica que el no del ACK es válido. Si vale 0 se ignora el campo ACK. SYN: Para establecer
conexiones. (Connection request SYN=1 y ACK=0) (Connection accepted: SYN=1 y ACK=1).

FIN: Libera la conexión. Especifica que el emisor ya no posee más datos para transmitir, pero el
receptor puede seguir recibiendo.

La siguiente figura muestra la localización de los Flags con su respectivo valor, según la imagen
Flags= 12HEXA=000000010010BIN

d) Discutir el contenido del campo opciones: tipos de opciones, rellenos, etc.

Las tramas con banderas SYN y SYN/ACK activas son las que están en la parte de opciones,
contienen valores de MSS y SACK; la versión TCP Sack se encarga de realizar constantemente una
estimación del tráfico pendiente en la red y sólo envía o retransmite segmentos si el volumen de
datos o tráfico estimado es menor que el de la ventana de congestión CWND.
 e) Utilizando la información de la cabecera de la primera trama de conexión
averiguar el puerto del cliente.
En la siguiente figura se presenta que el primer segmento está hecho por una solicitud que fue
realizada por el cliente, esto indica que ahora el cliente será la fuente, ahora el protocolo IPV4 pone
una cabecera de fuente/destino en wireshark.

Localización de IP cliente

Servicios TCP
Ahora comprobaremos la funcionalidad de otros puertos: echo, daytime, quote.
Realizaremos las siguientes tareas:

1. Mantener los mismos filtros.

2. Activar el modo captura.
3. Desde Windows ejecutar el programa Socket Workbench en modo cliente
Opciones:
- Servidor: <IP Servidor
Linux> - Puerto daytime(13)
Con el botón Connect se establece una conexión con la máquina remota.

A continuación, se presenta la configuración modo cliente en socket workbench

Conexión workbench puerto 13

 En el programa WireShark suspenda la captura y estudie las tramas involucradas.

A continuación, se muestra la captura de datos en wireshark

Captura de paquetes con wireshark

Discusión:
a) Analizar el mensaje enviado.
Estos paquetes son similares al ejercicio anterior ya que se recibieron 9 tramas y los segmentos TCP
tienen activadas las banderas SYN, SYN/ACK, ACK y FIN/ACK

b) Estudiar las diferencias en el mecanismo de desconexión. ¿Qué proceso inicia

la primera desconexión?
Una petición de parte del servidor con la bandera FIN activada es lo que lo inicia.
 Desconexion con bandera

c) Repetimos los pasos anteriores con el puerto de echo 7. De esta manera la

conexión queda abierta hasta que realicemos la desconexión. Utilizando el
botón Send para transmitir una trama al otro extremo de la conexión,
emergerá una ventana donde escribiremos el texto para el campo de datos y
hacer su envío y se muestra en el programa cliente mandando un mensaje de
prueba

Envió de datos al servidor

En la siguiente figura se puede ver que el puerto 7 escucha la solicitud ECHO, analizando en
wireshark la trama 4 contiene este paquete.

Puerto 7 escuchando la solicitud ECHO

 d) Analizar las tramas en el proceso de desconexión.
Se procede a iniciar una petición de parte del servidor con la bandera FIN activada y vemos que el
proceso es el mismo que el anterior:

Desconexion con bandera, puerto 7

e) Comprobar el puerto quote 17 utilizando como servidor remoto.

Se muestra la conexión al sitio indicado, se presentó una desconexión automática y de esta manera
es posible que el sitio web este fuera de servicio como se presenta en la siguiente figura:

Conexión con workbench

A continuación se presenta viendo en wireshark y analizando que solo se capturaron 3 tramas con
las bandera SYN, la IP del servidor es: 96.31.35.198, MAC del servidor: fa:39:09:8e:a1:83 y el
campo GeoIP del protocolo IPV4 indica que el servidor esta Estados Unidos.

Captura de datos
Timeout para el establecimiento de una conexión
Filtro para la máquina monitor: ip and tcp and ether host <mac_pc_prueba_cliente> en esta tarea
utilizaremos dos PCs de ensayos conectados al mismo concentrador:
1 PC de ensayos con el programa Socket WorkBench en modo servidor

1 PC de ensayos con el programa Socket WorkBench en modo cliente

Tareas a realizar
 Veremos la dirección IP del PC que actúe como servidor. A este equipo le ejecutaremos el
programa socket Workbench en modo servidor.

Dirección IP servidor
Opciones:
 Puerto: 6666
Al presionar el botón Listen. Se queda a la espera de una conexión

Dirección IP servidor

 Desde la PC que esta de cliente, se ejecuta el programa Socket Workbench en modo cliente
Opciones:
 Servidor: <dir. IP del PC servidor>
 Puerto: 6666
Con el botón Connect, se establece una conexión con la máquina remota. Así comprobamos que
está bien hecha la conexión y luego desconectamos con el botón Disconnect.
 Configurando como cliente
 Activamos la captura en el monitor.

 Desconectando el cable podemos simular como un fallo en la red

 De nuevo probamos la conexión desde el cliente como en los puntos anteriores.

Cable desconectado

 En el programa WireShark suspender la captura y estudiar las tramas involucradas.

La figura muestra las tramas capturadas en wireshark, produciendo 6 tramas y en el programa
cliente se desconecta marcando error

Captura tramas con fallos en la red

Discusión:

 Estudiar las tramas de conexión que envía el cliente y no son respondidas desde el servidor.
La trama 6 es la que envió el cliente y no se recibió ninguna respuesta, esta trama tiene los
segmentos TCP y ACK duplicado dando a entender cuáles son los segmentos que llegaron y cuales
no para que puedan ser reenviados.

 Analizar los tiempos de espera entre intentos de conexión (timeout).

En la figura se detalla la información cuando un usuario es desconectado automáticamente de

Internet por haber alcanzado el límite de tiempo establecido. Este dato se obtiene en la trama 5
opciones SEQ/ACK analysis, iRTT: 0.000380000 seconds.
 Valor de Timeout

 Reconectar el cable del servidor y comprobar la conexión.

Se observó un cambio en el puerto de conexión en el programa cliente donde las primeras 6 tramas
del programa cliente se conecta a través del puerto 1031 y en las tramas de reconexión lo hacen a
través del puerto 1032 que son las tramas 7,8 y 9

Reconexión en wireskark

Timeout en la retransmisión de tramas

Vamos a ver el mecanismo de recuperación de tramas perdidas en la transmisión de datos TC. Para
esta práctica utilizaremos dos PCs para pruebas conectados al mismo concentrador como en el tema
anterior: Tareas a realizar

 Activar el modo de captura en el equipo monitor

 Consultaremos la dirección IP del PC que actúe como servidor. En este equipo

ejecutaremos la aplicación socket Workbench en modo servidor
Opciones:

 Puerto: 6666
Presionamos el botón Listen. Se queda a la espera de una conexión

 Desde el PC de prueba del cliente, ejecutar el programa Socket Workbench en modo cliente
Opciones:

 Servidor: <dir. IP del PC servidor>

 Puerto: 6666
Presionamos el botón Connect. Se establece una conexión con la máquina remota. Enviaremos
desde el cliente una trama de datos (texto) a través de la conexión (ver tema Servicios TCP para los
detalles).
 Configurando programa cliente

 Desconectaremos el cable de red del PC que actúa como servidor para simular un fallo en la red.
 Enviaremos desde el cliente otra trama de datos (texto) a través de la conexión.

Mensaje de cable desconectado

 Esperaremos sin reconectar el cable hasta que se aborte la conexión.

 En el programa WireShark salir de modo captura y estudiar las tramas involucradas.
Discusión:

 Analizar los tiempos de espera entre intentos de retransmisión. (timeout ).

El resultado obtenido no difería al realizar diferentes pruebas, los paquetes capturados nos dicen
que no hubo ningún proceso de desconexión y que los paquetes fueron enviados con éxito, en la
trama 6 se ve la reconexión esto debido a que hubo un cambio de puerto en el enlace de conexión.

Tramas wireshark
  Analizar el proceso de aborto de la conexión.

No se aprecia un aborto, pero se espera que en el siguiente literal se capture una trama que indique
aborto, En la figura se muestra el valor de timeout que fue alrededor de 0.052754000 segundos en
comparativa con la tarea anterior que se obtuvo un valor de 0.000380000 segundos.

Comparación de timeout

 Activando el programa WireShark en modo captura realizar una conexión desde el cliente
a la dirección: <dir. IP del PC servidor> (Puerto 6666). Analizar la trama de respuesta (uso de
trama de Reset).
Aquí se invierte las terminales para rastrear paquetes del servidor desde el cliente.

En la figura se muestra el mismo procedimiento desconectando el cable del servidor y se espera

mandar otros datos.

La siguiente figura muestra la trama 21, este es un segmento TCP con bandera ACK/RST
Abortar una conexión con la trama de Reset

Vamos a estudiar el mecanismo que permite abortar una conexión de un modo drástico utilizando
las tramas de Reset (flag RST). Este tipo de terminación supone que:
Cualquier dato en espera es eliminado, enviando el Reset inmediatamente
El receptor del Reset sabe que el otro extremo abortó la comunicación pudiendo la aplicación actuar
en consecuencia.
Para esta práctica utilizaremos dos PCs de pruebas conectados al mismo concentrador como en el
tema anterior:
Tareas a realizar:

 Activar el modo captura en el equipo monitor.

 Ejecutaremos los pasos 2 y 3 del tema anterior estableciendo una conexión entre un
PC cliente y un PC servidor utilizando el puerto 6666

 Desconectaremos el cable de red del PC que actúa como servidor.

 Cerraremos el programa Socket WorkBench y lo volveremos a ejecutar, volviendo a

activarlo en modo servidor en el mismo puerto. El servidor queda de este modo, a la
escucha del mismo puerto aunque no reconoce la conexión previa que había realizado el
cliente cuyo extremo permanece abierto (conexión cerrada en un solo sentido)

 Reconectaremos el cable de red del servidor.

 Enviaremos desde el cliente una trama de datos (texto) a través de la conexión.

 El servidor no reconocerá la conexión abierta en el cliente y responderá con una trama de reset
para forzar al cliente a reiniciarla.

En el programa WireShark detener la captura y estudiar las tramas involucradas. Se captura una
nueva trama previa al envio de datos con una nueva conexión, los puertos han cambiado también

Discusión:

 Analizar el tipo de tramas involucradas.

 Discutir el proceso de cierre parcial de conexiones.

En la conexión se capturan los paquetes 16, 17 y 18 con retransmisión, no se ve una bandera de FIN
activa, la bandera de RST es la que solicita una nueva conexión como un cierre parcial
 En el botón Common Protocols tenemos acceso a los mensajes utilizados en diferentes
protocolos pudiendo comprobar su funcionamiento
No se observan registros de protocolos a pesar que los datos fueron enviados con éxito

Protocolo HTTP

Aquí utilizaremos el programa socket WorkBench para ver el funcionamiento de un protocolo de

nivel de aplicación HTTP. En este caso no será necesario el uso del PC monitor ya que utilizaremos
la ventana de mensajes disponible en el propio programa. Tareas a realizar:

1. Desde el PC de ensayos (Windows) ejecutar el programa Socket Workbench en modo cliente.

Opciones:

 Servidor: 193.147.136.16
 Puerto : 80 (http)
Presionamos el botón Connect . Se establece una conexión con la máquina remota

 Utilizaremos el botón Send para transmitir una trama al otro extremo de la conexión.
Escribiremos la siguiente petición del protocolo HTTP (nota debemos incluir dos retornos
de línea al final para señalizar el final de petición). El servidor nos devolverá la página web
principal en formato HTML.
Discusión:

 Analizar el mensaje enviado. Resaltar las marcas de fin de mensaje

 Analizar las tramas recibidas

No existe ninguna respuesta y se prueba con Linux

Ahora la respuesta que tenemos es de la página de inicio, en las capturas de wireshark se obtiene
segmentos que tienen datos http y los datos son textos y etiquetas html.
 CONCLUSIONES

 Debemos recordar que el protocolo ARP es el mismo aunque haya subredes ya que
cada datagrama IP pasa primero por el algoritmo de encaminamiento IP. Este
algoritmo selecciona el manejador de dispositivo que debería enviar el paquete y
sólo entonces se consulta al módulo ARP asociado con ese manejador.

 Luego del desarrollo de estas guías sobre el protocolo ARP, supimos que es tan útil
como necesario para una comunicación más rápida y directa entre hosts de la misma
red. A pesar de sus desventajas, tales como que si la red cambia se tienen que
configurar de nuevo las tablas ARP y que, si se cae un enlace, las tablas ARP no se
actualizan automáticamente, sigue siendo una gran herramienta y el análisis de
tráfico de los paquetes ARP es de importancia tanto para el diagnóstico de la red,
como para fines académicos.

 Cabe destacar que, para la realización del laboratorio fue de gran ayuda la
utilización del programa Wireshark, pues es de excelente aplicación didáctica para
el estudio de las comunicaciones y para la resolución de problemas de red.

 ARP se emplea en redes IEEE 802 además de en las viejas redes DIX Ethernet para mapear
direcciones IP a dirección hardware. Para hacer esto, ha de estar estrechamente relacionado
con el manejador de dispositivo de red. De hecho, las especificaciones de ARP en RFC 826
sólo describen su funcionalidad, no su implementación, que depende en gran medida del
manejador de dispositivo para el tipo de red correspondiente, que suele estar codificado en
el micro código del adaptador.

 Por último a modo general podemos decir que las medidas de seguridad del tráfico de la
información que circula por la red son muy importantes debido a la facilidad con la que esta
puede ser interceptada y modificada.