Obtencion de Checksum en ubuntu

Con husmeador de paquetes (Wireshark)

Elaborado por Fausto Len Amador Maira. Puedes Contactarme a: fausto1mayo@gmail.com

1. Comunicacin UDP
En la captura udp.cap se muestra una comunicacin UDP. Contesta a las siguientes preguntas: 1. Cules son las direcciones IP y puertos involucrados en la comunicacin? Origen: 10.0.0.2, con puerto 32768. Destino: 11.0.0.2, con puerto 33000.

2. En qu red se ha realizado la captura? En la red 10.0.0.0 Lo comprobamos por la presencia de ARP, en la imagen superior se puede apreciar 3. Cul es el nmero de paquetes UDP y numero de bytes de datos intercambiados? El nmero de paquetes UDP son 5 en el primer paquete, y 6 en el segundo dando un total de 11 bytes de datos intercambiados

4. Dibuja un escenario en NetGUI con 2 subredes conectadas a travs de r1: Subred 11.0.0.0 mascara 255.255.255.0 Subred 12.0.0.0 mascara 255.255.255.0

2. Comunicacin TCP
Servidor no disponible

Utilizamos ahora nc para generar trfico TCP y hacemos las capturas que consideramos conveniente para explicar razonadamente que trfico se genera en las siguientes situaciones cuando se intenta establecer una conexin TCP desde pc1, puerto 10000, con la maquina 12.0.0.10, puerto 11111:

1. Existe la maquina 12.0.0.10 pero no hay una aplicacin escuchando en el puerto 11111. La conexin no puede establecerse. El cliente, tras enviar el SYN, recibe un segmento TCP desde 12.0.0.10 con el flag RST (RESET) activado, lo que hace que se cierre abruptamente la conexin.

2. Existe la red 12.0.0.0 y hay ruta para llegar hasta ella, pero no existe la maquina 12.0.0.10. (Para realizar este apartado apaga la maquina 12.0.0.10). No se realiz la conexin puesto que no existe la maquina 12.0.0.10, tras enviar el SYN, recibe un mensaje ICMP de tipo 3 y cdigo 1. Este mensaje lo enva el router r1 al no recibir respuesta a la solicitud de ARP preguntando por la 12.0.0.10 que l hace en la red 12.0.0.0.

Como observamos en la imagenen apagamos pc2(12.0.0.10), por lo tanto como no esta activada nunca habr comunicacin con pc1.

En esta imagen apreciamos el mensaje ICMP as mismo el mensaje que enva el router r1 al no recibir respuesta a la solicitud de ARP preguntando por la 12.0.0.10.

2.2. Cliente y servidor

En la captura tcp.cap se muestra una comunicacin TCP entre dos aplicaciones. Contesta a las siguientes preguntas: 1. Cul es la direccin IP y el puerto del cliente TCP y la direccin IP y el puerto del servidor TCP?En una conexin TCP el cliente es el proceso que primero enva el SYN. As que, en este caso: Cliente: 10.0.0.2, puerto 60709. Servidor: 11.0.0.2, puerto 34000.

2. Cuantos segmentos TCP se han enviado desde el cliente al servidor? 6 segmentos: SYN, ACK, DATA, DATA, FIN, ACK

3. Cuantos segmentos TCP se han enviado desde el servidor al cliente? 4 segmentos: SYN+ACK, ACK, ACK, FIN+ACK, tambin se puede utilizar la imagen anterior para comprobarlo 4. Indica que extremo cierra antes la conexin. El cliente es el que enva el fin primero, tambin se puede utilizar la imagen anterior para comprobarlo

2.3. Nmeros de secuencia

1. Cuantos bytes de datos enva el servidor al cliente? Razona la respuesta. Indica cuales son los nmeros de secuencia del SYN y del FIN que enva el servidor, y que relacin tienen con la cantidad de datos enviada por el servidor al cliente. La ms sencilla de calcular en nmero de bytes de datos enviados es fijarse en los nmeros de secuencia del paquete SYN y del paquete FIN de ese sentido de la comunicacin. Asi:Bytes de datos transmitidos = No sec FIN - No sec SYN 1 (1363273424-1363273423)-1=0 datos transmitidos En este caso sera cero por que el servidor no enva datos solo el cliente. 2. Cuantos bytes de datos enva el cliente al servidor? Razona la respuesta. Indica cuales son los nmeros de secuencia del SYN y del FIN que enva el cliente, y que relacin tienen con la cantidad de datos enviada por el cliente al servidor. datos transmitidos = No sec FIN - No sec SYN 1 (1367801710-1367801698)-1=11 datos transmitidos

2.4. RTT
1. Para cada uno de los segmentos de datos que enva el cliente al servidor, indica cual es el RTT. Observa para ello los tiempos de envi de los segmentos y los de recepcin de sus correspondientes asentimientos.

2.5. Factor de escala sobre la ventana anunciada

1. Indica cual es el valor del campo de ventana anunciada (Window size) en los segmentos SYN en cada uno de los dos sentidos. 10.0.0.2 -> 11.0.0.2: Ventana anunciada = 5840 bytes 11.0.0.2 ->10.0.0.2: Ventana anunciada = 5792 bytes 2. Indica cual es el valor del campo de ventana anunciada (Window size) en los segmentos que no tienen el flag SYN activado en cada uno de los dos sentidos 10.0.0.2 ->11.0.0.2: Ventana anunciada = 2920 bytes 11.0.0.2 -> 10.0.0.2: Ventana anunciada = 2896 bytes Indica cual es el valor real de ventana anunciada teniendo en cuenta el factor de escala que se incluye en las opciones de los segmentos SYN y SYN+ACK. 10.0.0.2 ->11.0.0.2: El campo de ventana anunciada tiene un valor de 2920 bytes, y en el paquete SYN su factor de escala es 1 (lo que indica que hay que multiplicar por 21 el campo de ventana). Por lo tanto la ventana real es 5840 bytes. 11.0.0.2 -> 10.0.0.2: El campo de ventana anunciada tiene un valor de 2896 bytes, y en el paquete SYN+ACK su factor de escala es 1 (lo que indica que hay que multiplicar por 21 el campo de ventana). Por lo tanto la ventana real es 5792 bytes.

2.6. MSS
En la captura tcp-mss-pmtu.cap se muestra el principio de una comunicacin TCP. Ordena en Wireshark los paquetes por la columna Time. Contesta a las siguientes preguntas: 1. Indica cual es el valor anunciado de MSS en las cabeceras opcionales de los paquetes SYN de los dos sentidos de la conexin. Dados estos dos valores, indica que tamao de datos crees usaran ambos sentidos de la conexin si tienen que enviar datos. 11.0.0.11 -> 12.0.0.12: MSS = 660 bytes. 12.0.0.12 -> 11.0.0.11: MSS = 560 bytes. Los dos sentidos de la comunicacin usaran como tamao mximo de datos el menor de estos dos valores, es decir, 560 bytes.

2. Mira los tamaos de las cabeceras de los distintos segmentos, medidos en palabras de 4 bytes y razona porque no todos los segmentos tienen el mismo tamao. Crees que el tamao de la cabecera puede influir en el tamano maximo de datos que posteriormente utilizara TCP para enviar segmentos? En ambos sentidos, el SYN tiene tamao de cabecera 10 palabras de 4 bytes (40 bytes): 5 palabras (20 bytes) de la parte fija de la cabecera, y 5 palabras (20 bytes) de opciones.

En el resto de segmentos, el tamao de cabecera es 8 palabras de 4 bytes (32 bytes): 5 palabras (20 bytes) de la parte fija de la cabecera, y 3 palabras (12 bytes) de opciones.

Los tamaos de las cabeceras de los distintos segmentos son diferentes porque hay opciones que solo viajan en los paquetes SYN, concretamente las opciones MSS y Window Scale. Por eso los paquetes SYN y SYN+ACK tienen mayor tamao de cabecera. El tamao de la cabecera se incluye en el tamao de datos de los segmentos: el valor de MSS est calculado para el supuesto de que los paquetes no lleven opciones ni en la cabecera IP ni en la cabecera TCP. Cuando se envi un segmento concreto al MSS habr que restarle lo que ocupen las cabeceras opcionales que lleve dicho segmento, y el resultado ser la mayor cantidad de bytes de datos que pueden viajar en ese segmento 3. Teniendo en cuenta que en el instante en el que se enva el segmento nmero 4, la maquina 11.0.0.11 tena mas de 2.000 bytes de datos que enviar a la maquina 12.0.0.12, por qu enva menos? Cuantos bytes enva en ese segmento 4? Cmo se justifica cada el nmero de bytes de datos que contiene el segmento 4 dados los valores de MSS anunciados en los segmentos SYN? En el segmento 4 el cliente enva menos de los 2000 bytes para intentar evitar la fragmentacin IP. Para ello tiene en cuenta el menor de los dos valores de MSS anunciados al establecerse la conexin, es decir, 560 bytes. Este tamao de datos se utilizara en paquetes sin opciones en la cabera de IP y sin opciones en la cabecera de TCP. Como el segmento 4 tiene 12 bytes de opciones en la cabera TCP (y 0 bytes de opciones en la cabecera IP), dicho segmento puede llevar un mximo de 560 - 12 = 548 bytes de datos.

4. Explica que tipo de paquete son los paquetes 5 y 7 de la captura. Qu significan y cul puede ser la razn de que se hayan enviado? Qu campo de la cabecera IP de los paquetes 4 y 6 ha provocado que se enven los paquetes 5 y 7? Los paquetes 5 y 7 son mensajes de ICMP de destino inalcanzable porque se necesitaba fragmentacin. Los enva un router del camino entre el cliente y el servidor. El que existan estos paquetes en la captura indica que un router del camino est conectado a un nivel de enlace que requiere un tamao mximo permitido para los datos aun menor que el que se est usando en la conexin 1.

Los paquetes 4 y 6 llevan activado en la cabecera IP el flag DF (No Fragmentar). Eso hace que cuando lleguen a un router que necesite fragmentar esos datagramas (en este caso el router 11.0.0.1) no pueda hacerlo por estar activado dicho flag, y no le quede otro remedio que descartarlos, y enviar un mensaje ICMP al origen por cada datagrama que descarta.

5. Mira el paquete 8 de la captura. Por qu se retransmite este segmento? Comprueba el tamao de su campo de datos. Explica la relacin de este valor con la informacin contenida en los paquetes 5 y 7. El cliente de la conexin TCP, al recibir los ICMP, ve en su contenido (campo MTU of next hop) el tamao mximo de datos que puede poner en sus segmentos: 500 bytes. Y como sabe que los segmentos 4 y 6 han sido descartados, debe reenviarlos con el tamao adecuado. Asi, los 548 bytes de datos del segmento 4 se retransmiten repartidos en el segmento 8 (500 bytes de datos) y segmento 9 (48 bytes de datos). Y anlogamente ocurre con los datos del segmento 6, que se retransmiten en los segmentos 12 y 13.