Cuestión 6

Cambiamos la ruta por la cual nos conectamos a la maquina Linux 1. Para ello hacemos lo siguente:
1)Cambiar la ruta para ir a Linux 1
Route delete 172.20.41.241
Route ad 172.20.41 172.20.43.231

2)C.\ftp 172.20.41.241
Usuario: alumnos
Pass: alumnos
bin
put p3.txt
quit

Primero manda un par de paquetes de 460 bytes de tamaño. Al recibir un mensaje de error indicando que el tamaño es demasiado grande y el nuevo tamaño de MTU se mandan de nuevo un par de paquetes teniendo en cuenta el nuevo tamaño de MTU para calcular el tamaño del MSS. Al comprobar que llegan bien los paquetes con ese tamaño cada vez se van mandando mas paquetes de golpe.

Cuestión 5

Realiza un conexción FTP a la máquina de un compañero de clase. ¿Qué obtienes en el monitor de red al intentar realizar la conexión?

Al intentar hacer una conexión FTP a otro ordenador, vemos como se han realizado 3 intentos pero ninguno de ellos ha establecido conexión con el otro ordenador.

Cuestión 4

Utiliza el programa rexec para ejecutar el comando 'cat 1720intf.txt' en el servidor 10.3.7.0. ¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto el caso anterior?

Se negocia un tamaño de MSS de 460 bytes (primero 1460 y luego 460).
El tamaño de los segmentos TCP es de 480 bytes (460 de datos y 20 de cabecera).
La diferencia es que ahora hay segmentos de menor tamaño que contienen menos datos.

Cuestión 3

Utilza el programa rexec para ejecutar el comando 'cat 1720intf.txt' en el servidor 172.20.43.232 (Linux2). La información recibida es de varios miles de bytes y se recibirá en segmentos TCP de gran tamaño.

¿IP ha fragmentado estos segmentos? ¿Por qué ocurre esto? ¿Cuál es el tamaño de los segmentos TCP?

TCP no fragmenta los segmentos. No los fragmenta porque TCP ya crea los segmentos respetando el tamaño de su MSS (tamaño máximo de segmentos TCP).
El tamaño máximo de los segmentos TCP es de 1460 una vez que se le han restado los bytes de las cabeceras de IP y TCP de 20 bytes cada una.

Cuestión 2

Rexec.exe Remote Shell es un servicio presente en un S.O.Unix con TCP/IP que atiende al puerto TCP 512 en espera de peticiones de ejecución de comandos desde procesos remotos clientes. Utilza TCP, por lo que trabaja con conexión. Para las prácticas se dispondrá de un proframa para MS Windows (rexec.exe) que actúa como cliente. En una sesión de rexec.exe se pide inicialmenteun nombre de ususario y password en la máquina servidora, y tras introducir estos, se pueden ejecutar comandos UNIX en dicha máquina. Nos servira para estudiar una conexión TCP. Dentro de una máquina UNIX, el cliente es un programa en la línea de comandos con esta sintaxis básica:
rsh
Emplear el programa rexec para ejecutar el comando 'ls -1' en la máquina 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 estableciamiento de la conexión entre la máquina del alumno y la 172.20.43.232. Utilzar para ello el filtro adecuado (direcciones y protocolos).

1. Comprueba las secuencias de conexíon-desconexión TCP. ¿Son similares a las que se detallan en la figura 6? (Puede que observes que el cliente contesta a una solicitud de SYN del servidor con un RST. Esto ocurre porque el servidor trata de autentificar al cliente, algo que no permite el PC).
   
   La estructura de envío de datos - confirmación de datos es similar a la detallada en el guión de prácticas.
   Aquí podemos ver la captura de tramas realizada por el Monitor de Red con la que hemos comprobado esto y la figura 6 de la practica donde se detalla esto.
   
   
   
   
2. Comprueba el valor de los puertos utilizados. Indica su valor.
   
   Puertos:
   
   • PC = 2677
     
   • Servidor = 512
   
   Durante la autentificación, los puertos cambian:
   
   • PC = 3512
     
   • Servidor = 113
   
   Esto último ocurre porque, para realizar la operación comentada, se requieren una serie de puertos que aseguren mayor seguridad que los anteriores.
   
   
3. Analizar los valores de la ventana del receptor. ¿Cuál es más grande?
   
   Las ventanas tienes únicamente dos tamaños: 65535 bytes y 5840 bytes.
   La de mayor tamaño es la 65535 bytes y que además coincide con el máximo posible ya que este campo tiene reservados 2 bytes de tamaño, lo que establece 65536 valores posibles que se mueven en el rango de [0,65535].
   

Cuestión 1

Udp.exe. Este sencillo programa para MS Windows nos permitira enviar y recibir paquetes UDP, especificando tambien su contenido, a un nçumero de puerto y una IP destinos especificados para comprobar el funcionamiento de este protocolo.

1. Utilizar el programa udp.exe para realizar un envío de datos al puerto 7 (echo) o al puerto 13 (hora y dia) del servidor Linux 1 del laboratorio (10.3.7.0). PAra ello basta especificar la dirección IP y el puerto del servidor, colocar algún texto en la ventana y pulsar el botón "Envía UDP". Con el monitor de red, analiza la secuencia de paquetes UDP que se desencadenan cuando se envía como datos una palabra, por ejemplo "hola". Utiliza el filtro adecuado en el monitor de Red (direcciones y protocolos).
   
   Hemos mandado el paquete UDP al puerto 7 del servidor Linux 1. Y para ver las tramas en el monitor de red hemos puesto como filtro "ip.addr==10.3.7.0". Una vez puesto el filtro se ve las tramas de petición y respuesta que hemos realizado.
   
   
   
   • Nuestra máquina: puerto 2310
     
   • Servidor: puerto 7
   
   
   
2. Prueba de nuevo Udp.exe, pero enviando un texto mucho mas grande (sobre 2k bytes). Esto se puede hacer copiando parte de algun fichero de texto en la ventana del udp.exe. ¿Se produce fragmentación IP de los paquetes UDP? Estudia las longitudes del paquete UDP y las de los paquetes IP que aparecen. Detalla los paquetes (fragmentados o no) que observas en el Monitor (indica el valor del identificador, flags, tamaño, etc...)
   
   
   En la imagen podemos ver como el paquete se ha fragmentado en 2 datagramas para la petición y en 6 datagramas para la respuesta.
   
   T1) Flags: 0x01, offset: 0, tamaño 1514
   T2) Flags: 0x00, offset: 1480, tamaño: 987
   T3) Flags: 0x01, offset: 0, tamaño: 514
   T4) Flags: 0x01, offset: 480, tamaño: 514
   T5) Flags: 0x01, offset: 960, tamaño: 514
   T6) Flags: 0x01, offset: 1440, tamaño: 514
   T7) Flags: 0x01, offset: 1920, tamaño: 514
   T8) Flags: 0x00, offset: 2400, tamaño: 67
   

Práctica 3

En esta tercera práctica de la asignatura se va a estudiar con profundidad el nivel de transporte del protocolo TCP/IP, siendo nuestro principal objetivo el comprender la diferencia entre los dos protocolos principales de este nivel de red: el TCP, cuyas siglas significan Transmission Control Protocol (en castellano, Protocolo de Control de Transmisión), y el UDP, que es el acrónimo de User Datagram Protocol (cuya traducción es Protocolo de Datagramas de Usuario.