Hacia mucho tiempo que no me pasaba por aquí y he visto que hay un monton de gente que ha consultado el blog. Incluso hay seres humanos que nos animan a seguir añadiendo entradas.

Lo siento amigos, pero este blog se realizó para las prácticas de una asignatura muy concreta (Redes). Yo sigo en la universidad y necesito hasta mi último minuto libre para poder ir estudiando (Teleco nada menos).

Pero quien sabe en un futuro que puede pasar?

Gracias a todos los que consultais el blog y realmente, espero que os sirva de ayuda. UN ABRAZO!!!!

RESULTADO TEÓRICO

RESULTADO PRÁCTICO

Como podemos ver en la imagen, el resultado práctico coincide con lo que hemos calculado. Hemos remarcado en la imagen la longitud del último de los tres paquetes, 48 bytes.

• El ordenador se conecta al pc del compañero, pero no recibimos ninguna respuesta TCP del pc conectado. El servicio TCP de los ordenadores están deshabilitados. Nuestra maquina realiza tres intentos de conexión al servicio FTP con el mensaje syn, en las tres ocasiones el pc de destino responde con un mensaje de reset y la conexión se debe volver a realizar

A simple vista no parece haber demasiada diferencia con respecto al caso anterior:

Pero si nos fijamos en los valores remarcados con un recuadro verde podemos ver que el valor del MSS es 460. En este caso sí que se han fragmentado los segmentos, ajustándose al tamaño de la subred que debe atravesar.

• IP no fragmenta los segmentos ya que el protocolo TCP impide la fragmentación como medida de seguridad. Para asegurar el correcto funcionamiento, TCP implementa unos segmentos adecuados a la red donde esté trabajando. Calcula el MSS (máximo tamaño de segmento que corresponde a la MTU-20 bytes – 20 bytes [En nuestro caso MTU=1500----->MSS=1460])

• Win se utiliza para informar del número de bytes que el emisor del paquete es capaz de aceptar al recibir.Este valor depende de la porción que queda libre en su buffer de recepción. Si vale 0 indica que no se van a aceptar datos (aunque si los ACK, RST, FIN…).

win=5840

win=0

El puerto local es variable. Comienza a partir de 1024 y a cada aplicación que utilice una conexión le asigna un número creciente. En este caso el valor es de 1367, pero si lo volvieramos a intentar cambiaría. El puerto de servidor, por el contrario, es fijo para cada función. En este caso el valor obtenido es 512 y siempre tomará este valor si repetimos el proceso.

Figura 6

Estos son los resultados que hemos obtenido:

La parte intermedia no es de fiar y es de esperar que no salga igual que lo que debería salir según la figura 6. Esto es debido a que debido a la aplicación, al navegador o incluso del antivirus o firewall que estemos utilizando, este proceso puede variar en sus pasos intermedios. En este ejemplo podemos ver incluso mensajes [RST] que reinician la conexión.

Sí podemos ver sin embargo que coincide tanto en la parte inicial como en la final. Al inicio nuestra máquina envía un [SYN] y la máquina de destino responde con un [SYN, ACK], respondiendo a su vez nuesttra máquina con un [ACK]. Para acabar la conexión podemos ver que nuestra máquina manda el [FIN] y es respondida por el destino con un [ACK].

Rexec. Remote Shell es un servicio presente en un S.O. UNIX con TCP/IP que atiende el puerto TCP 512 en espera de peticiones de ejecución de comandos desde procesos remotos clientes. Utiliza TCP, por lo que trabaja con conexión. Para las prácticas se dispondrá de un programa para MS Windows (rexec.exe) que actúa como cliente. En una sesión de rexec.exe se pide inicialmente un nombre de usuario y password en la máquina servidora, y tras introducir estos, se pueden ejecutar comandos UNIX en dicha máquina. Nos servirá para estudiar una conexión TCP. Dentro de una máquina UNIX, el cliente es un programa de línea de comandos con esta sintaxis básica: rsh .
Emplear el programa rexec para ejecutar el comando ‘ls –l’ en la maquina con dirección 172.20.43.232 (Linux2). Utiliza para ello el usuario ‘alumnos’ y la clave ‘alumnos’. Con el monitor  de red, analizar y estudiar la secuencia de paquetes TCP intercambiados en el establecimiento de la conexión entre la máquina del alumno y la 172.20.43.232. Utilizar para ello el filtro adecuado (direcciones y protocolos).

En el envio, el mensaje UDP se ha fragmentado en dos mensajes IP FRAGMENT mas un mensaje ECHO REQUEST que contiene la cabecera UDP. Mientras que el mensaje ECHO REPLY, vuelve a nuestra maquina dividida en 6 IP FRAGMENT mas un mensaje ECHO REPLY con cabecera UDP.

• A partir de los datos podemos deducir que la MTU de nuestra subred es de 1500 bytes. Pero el tamaño mínimo de MTU en las subredes que ha atravesado nuestro mensaje es de 500 bytes.