66.66 Seminario de Electrónica II

Transcripción

1 Trabajo Práctico N 3: Grupo: Kroned Cátedra: Ing. Utard, Marcelo Alumnos: Fernández, Javier Darío N de padrón: Mail: jdfernan@fi.uba.ar Fernández, José Antonio N de padrón: Mail: jafernan@fi.uba.ar Sánchez Pinzón, Federico N de padrón: Mail: fsanchez@fi.uba.ar Teléfonos: Fernández, Javier Darío Tel: Fernández, José Antonio Tel: Sánchez Pinzón, Federico Tel: Docente Asignado 2 do Cuatrimestre de 2003

2 Planificación Introducción Las aplicaciones que utilizamos en el presente trabajo sobre los protocolos UDP y TCP son TFTP y RTP sobre UDP y HTTP y FTP sobre TCP. A continuación se irán presentando acompañada por una breve introducción teórica. TFTP (Trivial File Transfer Protocol) Maqueta Intento de lectura de archivo inexistente Se intentará hacer un GET de un archivo que no existe en el servidor, con el objeto de observar el error que resulta de este intento. [ ] server# tftp [ ] tftp> connect localhost [ ] tftp> get NOFILE [ ] server# Resultados esperados Se espera observar un RRQ enviado del cliente al servidor, y una respuesta de error de parte del servidor. Se podrán apreciar las 2 tramas (RRQ y ERROR) y el error que esperamos encontrar es el de File not found. Lectura de un archivo Se hará un GET de un archivo que esté en condiciones de ser leído, para ver como se transfieren los datos. Página 1 de 13

3 [ ] server# tftp [ ] tftp> get file Received 832 bytes in 0.2 seconds tftp> Resultados esperados Se espera ver un RRQ, seguido de un ACK que contendrá la primera porción de datos, luego un ACK de la porción de datos recibida, y luego una sucesión de paquetes hasta un paquete vacío que indica fin de la transferencia. Escritura de un archivo Se enviará un archivo en una sesión TFTP. [ ] server# tftp localhost [ ] tftp> put passwd Sent 1379 bytes in 0.2 seconds tftp> Resultados esperados Se espera observar la transferencia del archivo, observar como el archivo viaja plano y ver los ACK y el fin de la transmisión. Errores de escritura Se mostrará el resultado de dos errores en el envío de un archivo: el primero es el caso del servidor caído, para mostrar el sistema de timeout y el segundo es el caso de no tener permisos de escritura adecuados en el servidor, lo que impide escribir el archivo. [ ] server# tftp localhost [ ] tftp> put nohup.out Transfer timed out. [ ] tftp> put file Error code 0: Permission denied Página 2 de 13

4 Resultados esperados Se espera ver en el primer caso una serie de intentos de enviar archivos, es decir paquetes WRQ que no serán atendidos, y habrá respuestas de ICMP indicando que no se esta escuchando en ese puerto (conf. TP1). Para el segundo caso se espera ver un paquete con código de operación 5 indicando el error de permisos. Archivo con número entero de bloques Como se explicó en la prueba Lectura de un archivo la forma de detectar el fin de archivo es que el tamaño del paquete recibido sea menor a 512, y si el archivo ocupa un número entero de paquetes UDP, se envía un paquete vacío. En esta prueba se muestra exactamente este último caso, ya que resulta interesante por ser un caso un poco particular. En definitiva no es tan así, ya que no deja de ser un paquete con tamaño menor a 512 bytes. [ ] server# tftp localhost [ ] tftp> put file Resultados esperados Ya que se creo especialmente un archivo de 511 bytes que ocupa exactamente un bloque de datos, se espera ver el envío del primer bloque (que lleva el archivo entero) y luego un bloque adicional de tamaño cero para indicar el fin de la transmisión. FTP (File Transfer Protocol) Maqueta Página 3 de 13

5 Conexión al servidor FTP y log in con password no válido. El objetivo de esta prueba es analizar el tráfico de paquetes TCP necesarios para la conexión al servidor FTP aleph.fi.uba.ar por parte del cliente jdfernan. También se espera visualizar los puertos TCP utilizados por el protocolo en cuestión y el contenido detallado de los mensajes involucrados. Por otro lado, se analiza el formato de salida de cada comando ejecutado. En la computadora host se ejecutan estos comandos: [ ] ftp aleph.fi.uba.ar [ ] ftp> bye Luego del primer comando, se ingresa el nombre de usuario jdfernan y un password no válido, con el fin de registrar los mensajes de error enviados por el servidor. Resultados Esperados Se espera ser rechazado por el servidor FTP aleph.fi.uba.ar y poder reconocer los mensajes involucrados en el inicio de conexión nombrados en la introducción. También se esperan verificar los puertos TCP que utiliza FTP. Conexión al servidor FTP y log in exitoso El objetivo de esta prueba es analizar el tráfico de paquetes TCP necesarios para la conexión al servidor FTP aleph.fi.uba.ar por parte del cliente jdfernan. También se espera visualizar los puertos TCP utilizados por el protocolo en cuestión y el contenido detallado de los mensajes involucrados. Por otro lado, se analiza el formato de salida de cada comando ejecutado. En la computadora host se ejecuta este comando: [ ] ftp aleph.fi.uba.ar Luego se ingresa el nombre de usuario jdfernan y el password correspondiente, con el fin de completar el log in. Página 4 de 13

6 Resultados Esperados Se espera iniciar una sesión contra el servidor FTP aleph.fi.uba.ar y poder reconocer los mensajes involucrados en el inicio de conexión nombrados en la introducción. También se esperan verificar los puertos TCP que utiliza FTP. Listado de comandos FTP El fin de esta prueba es ver que tipo de respuesta se obtiene del comando FTP help, una vez iniciada la conexión FTP detallada en el escenario anterior. Se analiza el formato de salida del comando FTP. En la computadora host se ejecuta este comando: [ ] ftp> help Resultados Esperados Se espera recibir un listado con todos los comandos FTP que acepta el servidor aleph.fi.uba.ar. La lista de comandos debe contener, mínimamente, los analizados en la introducción a FTP. Se analiza el formato de salida del comando. Nombre del directorio home El fin de esta prueba es ver que tipo de respuesta se obtiene del comando FTP pwd, una vez iniciada la conexión FTP detallada en la prueba Conexión al servidor FTP y log in exitoso. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. En la computadora host se ejecuta este comando: [ ] ftp> pwd Resultados Esperados Se espera recibir el nombre del directorio home del usuario jdfernan, administrado por el servidor aleph.fi.uba.ar. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. Página 5 de 13

7 Listado de archivos en el directorio home del cliente El fin de esta prueba es visualizar los archivos y directorios que se encuentran en el directorio /home/jdfernan/, mediante el comando FTP ls. Luego se procede a analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. En la computadora host se ejecuta este comando: [ ] ftp> ls Resultados Esperados Se espera recibir un listado con todos los archivos y directorios del usuario jdfernan, con el objeto de utilizarlos en escenarios futuros. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. Transferencia de un archivo del servidor al cliente El fin de esta prueba es transferir un archivo al cliente, utilizando el comando FTP get. Este comando se ejecuta una vez iniciada la conexión FTP detallada en la prueba Conexión al servidor FTP y log in exitoso. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. En la computadora host se ejecuta este comando: [ ] ftp> get manual.txt /tp3/tmpc.txt Resultados Esperados Se espera recibir el archivo manual.txt del servidor aleph.fi.uba.ar y almacenarlo en el disco rígido del cliente con el path y nombre /tp3/tmpc.txt. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. Página 6 de 13

8 Creación de un directorio El fin de esta prueba es crear un subdirectorio en el directorio /home/jdfernan/, utilizando el comando FTP mkdir. Este comando se ejecuta una vez iniciada la conexión FTP detallada en la prueba Conexión al servidor FTP y log in exitoso. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. En la computadora host se ejecutan estos comandos: [ ] ftp> mkdir recive [ ] ftp> cd recive Resultados Esperados Se espera crear el directorio /home/jdfernan/recive/ exitosamente en el servidor aleph.fi.uba.ar. Para verificar esto último se ejecuta el comando FTP cd (change directory). Se analiza el formato de salida de los comandos y el intercambio de mensajes entre el servidor y el cliente FTP. Transferencia de un archivo del cliente al servidor El fin de esta prueba es transferir un archivo al servidor, utilizando el comando FTP put. Este comando se ejecuta una vez iniciada la conexión FTP detallada en la prueba Conexión al servidor FTP y log in exitoso. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. En la computadora host se ejecutan estos comandos: [ ] ftp> put /tp3/tmpc.txt tmps.txt Resultados Esperados Se espera enviar el archivo /tp3/tmpc.txt del cliente al servidor aleph.fi.uba.ar y almacenarlo en el directorio home con el path y nombre /home/jdfernan/recive/tmps.txt. Vale aclarar que el archivo se copia al directorio /home/jdfernan/recive/, debido a que el último comando ejecutado fue cd recive (prueba Creación de un directorio). Página 7 de 13

9 Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. Eliminar el archivo copiado y el directorio creado en el servidor El fin de esta prueba es eliminar los cambios hechos en el servidor en los últimos dos escenarios, mediante los comandos FTP delete y rmdir. Estos comandos se ejecutan una vez iniciada la conexión FTP detallada en la prueba Conexión al servidor FTP y log in exitoso. Se analiza el formato de salida de los comandos y el intercambio de mensajes entre el servidor y el cliente FTP. En la computadora host se ejecutan estos comandos: [ ] ftp> pwd [ ] ftp> ls [ ] ftp> delete tmps.txt [ ] ftp> cd.. [ ] ftp> rmdir recive [ ] ftp> ls Resultados Esperados Se espera eliminar el archivo /home/jdfernan/recive/tmps.txt del servidor aleph.fi.uba.ar y el directorio /home/jdfernan/recive/, almacenarlos en el directorio home del cliente jdfernan. Para verificar que el directorio /home/jdfernan/ se encuentra en las condiciones originales, se ejecuta el comando ls. Se analiza el formato de salida de los comandos y el intercambio de mensajes entre el servidor y el cliente FTP. Finalizar la sesión FTP El fin de esta prueba es finalizar la conexión con el servidor, ejecutando el comando FTP bye. Este comando se ejecuta una vez iniciada la sesión FTP detallada en la prueba Conexión al servidor FTP y log in exitoso. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. En la computadora host se ejecuta este comando: [ ] ftp> bye Página 8 de 13

10 Resultados Esperados Se espera terminar con las conexiones TCP que sostiene el protocolo FTP. Se analiza el formato de salida del comando y el intercambio de mensajes entre el servidor y el cliente FTP. HTTP (Hypertext Transfer Protocol) Maqueta HTTP Get a una página existente usando HTTP/1.0 El objetivo de esta prueba es observar el intercambio de paquetes que se genera entre el cliente HTTP y el servidor Web cuando se realiza un HTTP get de la versión 1.0 del protocolo. En la computadora host se buscará la página Web de la Facultad de Ingeniería ( utilizando como browser el Microsoft Internet Explorer. La opción de HTTP/1.1 se encuentra deshabilitada en la configuración del navegador. Al mismo tiempo se observará el intercambio de paquetes con el sniffer Ethereal. Resultados esperados En primer lugar se espera observar el código HTML de la página que devuelve el servidor Web. Además, se espera observar como se abren conexiones TCP para la transmisión de los diferentes elementos que conforman la página Web. Página 9 de 13

11 HTTP Get a una página existente usando HTTP/1.1 El objetivo de esta prueba es observar el intercambio de paquetes que se genera entre el cliente y el servidor Web luego de realizar un HTTP get de la versión 1.1 del protocolo. Se espera establecer una comparativa sobre las diferencias entre las versiones 1.0 y 1.1 del protocolo. En la computadora host se buscará la página Web de la Facultad de Ingeniería ( utilizando como browser el Microsoft Internet Explorer. La opción de HTTP/1.1 se encuentra habilitada en el navegador, en esta oportunidad. Al mismo tiempo se observará el intercambio de paquetes con el sniffer Ethereal. Resultados esperados Al igual que en la prueba anterior se espera observar, en primer lugar, el código fuente de la página HTML. Se espera observar como se realiza una reutilización de las conexiones TCP para transferir los diferentes objetos que conforman la página Web. HTTP Get a una página no existente El objetivo de esta prueba es observar cual es el resultado de realizar un HTTP get de una página Web que no se encuentra en el servidor En la computadora host se buscará en la página Web de la Facultad de Ingeniería un documento que no existe ( utilizando como browser el Microsoft Internet Explorer. La opción de HTTP/1.1 se encuentra deshabilitada en el navegador. Al mismo tiempo se observará el intercambio de paquetes con el sniffer Ethereal. Resultados esperados Se espera obtener en el cliente el código HTML de una página Web que posee el error 404 Not found. Página 10 de 13

12 Utilización del pug-in Live HTTP headers para Mozilla Firebird El objetivo de esta prueba es observar los headers que intercambian el cliente y el servidor Web. Para esto se utilizará el plug-in Live HTTP headers para el navegador Mozilla Firebird. En la computadora host se ejecutará el navegador Mozilla Firebird, al cual se le pedirá que vaya a la página de la facultad de ingeniería y se activará el plug-in Live HTTP headers. Resultados esperados Se espera observar la información que poseen los headers que intercambian el navegador y el servidor Web. RTP (Real Time Transport Protocol) Maqueta Análisis del protocolo Q.931 El objetivo de esta prueba es analizar el tráfico de los mensajes en el inicio de sesión. Se espera visualizar los mensajes involucrados (Setup y Alerting Connecting) y los puertos TCP utilizados por este protocolo. Los pasos a seguir son los siguientes: El host2 inicia el sniffer Ethereal en la interfaz Ambas computadoras inician la aplicación NetMeeting El host1 llama al host2, inciando la sesión NetMeeting Página 11 de 13

13 Resultados Esperados Se espera visualizar la transmisión de los mensajes Setup y Alerting Connecting por ambas terminales y que ambas inicien la sesión. También se esperan visualizar los puertos TCP que utiliza el protocolo. Análisis del protocolo H.245 El objetivo de esta prueba es analizar el tráfico de los Exchange Capabilities y la apertura de los canales lógicos, destinados al tráfico bajo RTP. Se espera visualizar los mensajes involucrados y los puertos TCP utilizados por este protocolo. Una vez efectuada la prueba anterior, los pasos a seguir son: El host2 continua el sniffing con la aplicación Ethereal en la interfaz Ambas computadoras mantienen las sesiones NetMeeting iniciadas anteriormente Resultados Esperados Se espera visualizar la transmisión de los Exchange Capabilities y que ambas terminales puedan hacer la apertura de los canales lógicos, destinados al tráfico RTP. También se esperan visualizar los puertos TCP que utiliza el protocolo, que corresponden a los negociados en la prueba Análisis del protocolo Q.931. Análisis del protocolo RTP El objetivo de esta prueba es analizar el tráfico de paquetes RTP/UDP involucrados en una transmisión de audio de tiempo real. Se espera visualizar los puertos UDP utilizados por el protocolo en cuestión y el contenido detallado de los headers de los mensajes RTP. Página 12 de 13

14 Una vez efectuada la prueba anterior, los pasos a seguir son: El host2 continua el sniffing con la aplicación Ethereal en la interfaz Ambas computadoras mantienen las sesiones NetMeeting iniciadas anteriormente El host2 selecciona el codec G.723 para la compresión de audio El host2 envía un mensaje de audio al host1 Resultados Esperados Se espera visualizar la transmisión de paquetes RTP en ráfaga con destino host1. También se esperan verificar los puertos UDP que utiliza el protocolo y el codec seleccionado (especificado en el header de RTP). Análisis del protocolo RTCP El objetivo de esta prueba es analizar el tráfico de paquetes RTCP/UDP, necesarios para el control de una transmisión de audio en curso. Se espera visualizar los puertos UDP utilizados por RTCP y el contenido detallado de los headers de los mensajes involucrados. Se espera conocer los tipos de mensajes RTCP. Una vez efectuada la prueba anterior, los pasos a seguir son: El host2 continua el sniffing con la aplicación Ethereal en la interfaz Ambas computadoras mantienen las sesiones NetMeeting iniciadas anteriormente El host2 continúa enviando el mensaje de audio del escenario anterior al host1 Resultados Esperados Se espera poder reconocer los mensajes involucrados en el control de una transmisión de tiempo real. También se esperan visualizar los puertos UDP que utiliza RTCP. Página 13 de 13

15 Desarrollo del trabajo práctico Introducción Las aplicaciones que utilizamos en el presente trabajo sobre los protocolos UDP y TCP son TFTP y RTP sobre UDP y HTTP y FTP sobre TCP. A continuación se irán presentando acompañada por una breve introducción teórica. TFTP (Trivial File Transfer Protocol) Introducción Teórica TFTP es un protocolo muy simple para transferencia de archivos. De ahí su nombre, Trivial File Transfer Protocol o TFTP. El protocolo se implementó sobre UDP, y es usado para transferir archivos entre distintas máquinas que implementen UDP. Está diseñado para que sea chico y fácil de implementar. Lo único que puede hacer es leer o escribir archivos desde servidores remotos. No puede listar directorios y actualmente no hay forma de autenticar usuarios. Como otros protocolos de Internet usa palabras de 8 bits para transportar la información. Existen tres modos de transferencia: 1. netascii (definido en "USA Standard Code for Information Interchange" con las modificaciones especificadas en "Telnet Protocol Specification"). 2. octet es el modo que reemplaza al antiguo modo binario. 3. mail donde los caracteres se envían al usuario y no al archivo. Este último modo no debe ser usado ni implementado, ya que es obsoleto. En el protocolo existen 5 tipos de paquetes: Read request (RRQ) Write request (WRQ) Data (DATA) Acknowledgement (ACK) Error (ERROR) Las transmisiones se inician con un RRQ o un WRQ, y se recibe a cambio un ACK para comenzar la escritura o un ACK con el primer bloque de datos. Cada bloque de datos lleva un número, comenzando desde el uno. A la recepción de cada bloque de datos se enviará un ACK para el mismo indicando el número de paquete. El protocolo trabaja en la modalidad STOP & WAIT. Para crear una conexión ambos puntos de la comunicación eligen un número al azar, que llamamos TID. En el caso particular de trabajar con UDP, ese TID será el número de puerto. Así, para iniciar una conexión, A envía un RRQ a B Página 1 de 61

16 saliendo por el TID-A y con destina 69 en B (el puerto de TFTP). Entonces B envía un ACK a A, con puerto origen igual a TID-B y destino TID-A. Las pruebas se concentrarán en mostrar los 5 tipos de paquetes y el funcionamiento del protocolo. Intento de lectura de archivo inexistente Se intentará hacer un GET de un archivo que no existe en el servidor, con el objeto de observar el error que resulta de este intento. [ ] server# tftp [ ] tftp> connect localhost [ ] tftp> get NOFILE [ ] server# Resultados obtenidos En el cliente TFTP se observó el siguiente error al hacer el GET: Error code 1: File not found La salida del dump: server# tcpdump -vvv -x -X -s 0 -i lo0 tcpdump: listening on lo0 08:58: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.tftp: [udp sum ok] 18 RRQ "NOFILE" (ttl 64, id 7139, len 46) 0x e 1be da 7f E...@.`... 0x0010 7f f1bd a 9b e4f...E...NO 0x c45 006e FILE.netascii. 08:58: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.61885: [udp sum ok] udp 19 (ttl 64, id 7141, len 47) 0x f 1be d7 7f E../...@.`... 0x0010 7f f1c0 f1bd 001b dd3f ?... 0x c65 206e 6f f75 6e64 00 File.not.found. 08:58: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.61888: [udp sum ok] udp 4 (ttl 64, id 7142, len 32) 0x be e5 7f E...@.`... 0x0010 7f f1bd f1c0 000c 1e P... ^C 8 packets received by filter 0 packets dropped by kernel server# Página 2 de 61

17 Conclusiones Se puede ver el primer paquete UDP, que es un RRQ: OP. CODE FILE NAME NULL MODE NULL e4f46494c e NOFILE 00 netascii \0 En este esquema se muestran claramente todos los campos del paquete. En el dump, se marco en turquesa el encabezado IP, en gris UDP y en amarillo TFTP. Se puede ver a continuación la respuesta con el mensaje de error: OP. CODE ERROR ERROR MESSAGE NULL c65206e6f f756e FNF File not found \0 A continuación se detallan los códigos de error posibles, con sus respectivos textos: 1. Not defined, see error message (if any). 2. File not found. 3. Access violation. 4. Disk full or allocation exceeded. 5. Illegal TFTP operation. 6. Unknown transfer ID. 7. File already exists. 8. No such user. Finalmente observamos el ACK que cierra la transmisión: OP. CODE BLOCK # Haciendo un reconocimiento del bloque recibido que indicaba el error. Lectura de un archivo Se hará un GET de un archivo que esté en condiciones de ser leído, para ver como se transfieren los datos. Página 3 de 61

18 [ ] server# tftp [ ] tftp> get file Received 832 bytes in 0.2 seconds tftp> Resultados obtenidos server# tcpdump -vvv -x -X -s 0 -i lo0 tcpdump: listening on lo0 08:58: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.tftp: [udp sum ok] 16 RRQ "file" (ttl 64, id 7157, len 44) 0x c 1bf ca 7f E..,...@.`... 0x0010 7f f1bd a E...)..fi 0x0020 6c65 006e le.netascii. 08:58: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.61885: [udp sum ok] udp 516 (ttl 64, id 7159, len 544) 0x bf ed4 7f E...@.^... 0x0010 7f f1c1 f1bd 020c 158a x a f #.$FreeBSD:.src/ 0x f 726f 6f74 2f64 6f74 2e etc/root/dot.csh 0x c e f30 rc,v /0 0x f a a /10.02:37:16.ar 0x d0a 230d 0a23 chie.exp.$..#..# 0x e d cshrc.-.csh.re 0x f c 2072 source.script,.r 0x e 6e69 6e67 ead.at.beginning 0x00a0 206f f 6e of.execution.by 0x00b c 6c0d 0a23 0d0a.each.shell..#.. 0x00c c 736f #.see.also.csh(1 0x00d0 292c e f6e e 0d0a ),.environ(7)... 0x00e0 230d 0a0d 0a61 6c #...alias.h..hi 0x00f f d0a 616c story.25..alias. 0x0100 6a09 096a 6f d6c 0d0a 616c 6961 j..jobs.-l..alia 0x c61 096c d61 0d0a 616c 6961 s.la.ls.-a..alia 0x c66 096c d46 410d 0a61 6c69 s.lf.ls.-fa..ali 0x c 6c09 6c73 202d 6c41 0d0a 0d0a as.ll.ls.-la... 0x f d #.A.righteous.um 0x b0d 0a75 6d61 736b d 0a0d ask..umask x0160 0a d20 282f 7362.set.path.=.(/sb 0x e 202f e20 2f f in./bin./usr/sbi 0x0180 6e20 2f f62 696e 202f f n./usr/bin./usr/ 0x d f f6c 6f63 616c games./usr/local 0x01a0 2f e20 2f f6c 6f63 616c /sbin./usr/local 0x01b0 2f62 696e 202f f f /bin./usr/x11r6/ 0x01c e f4d 452f e29 0d0a bin.$home/bin).. 0x01d0 0d0a e f setenv.EDITOR. 0x01e d0a e vi..setenv.pager 0x01f0 096d 6f72 650d 0a e c.more..setenv.BL 0x0200 4f43 4b53 495a b0d 0a0d 0a OCKSIZE.K...if. 0x f70 726f 6d e0d ($?prompt).then. 08:58: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.61889: [udp sum ok] udp 4 (ttl 64, id 7160, len 32) Página 4 de 61

19 0x bf d3 7f x0010 7f f1bd f1c1 000c 1e4f O... 08:58: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.61885: [udp sum ok] udp 324 (ttl 64, id 7161, len 352) 0x bf f92 7f x0010 7f f1c1 f1bd 014c 537a LSz... 0x0020 0a e e #.An.interacti 0x c6c 202d 2d ve.shell.--.set. 0x f 6d d 0a09 some.stuff.up... 0x f6d d set.prompt.=."`h 0x0060 6f73 746e 616d d d0a ostname.-s`#.".. 0x c d0a set.filec...set 0x f d d0a.history.= x d20.set.savehist.=. 0x00a d 0a d61 696c 203d set.mail.= 0x00b f f6d c2f (/var/mail/$USE 0x00c d0a f R)...if.(.$?tcsh 0x00d e0d 0a e 646b.).then...bindk 0x00e e b ey."^w".backward 0x00f0 2d64 656c d 776f d0a delete-word... 0x e64 6b d6b bindkey.-k.up.hi 0x f72 792d d story-search-bac 0x0120 6b d 0a e 646b 6579 kward...bindkey 0x d 6b20 646f 776e f k.down.history 0x0140 2d d 666f d -search-forward. 0x0150 0a09 656e d 0a65 6e d0a..endif..endif.. 08:58: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.61889: [udp sum ok] udp 4 (ttl 64, id 7162, len 32) 0x bfa d1 7f E...@.`... 0x0010 7f f1bd f1c1 000c 1e4e N... ^C 8 packets received by filter 0 packets dropped by kernel server# Conclusiones Tal como se esperaba, se ve el primer paquete UDP que es un RRQ, puerto origen 61885, que es el TID elegido al azar, y destino puerto 69, que es el web known de TFTP. Para detalles de este paquete, ver la prueba anterior, ya que solo cambia el nombre del archivo. El siguiente paquete es el primer paquete de datos: OP. CODE BLOCK # DATA (...) 0d0a Contenido del archivo... Luego se ve un ACK, reconociendo el bloque 1, entonces se transmite el bloque 2, y la transmisión finaliza con la recepción del ACK del bloque 2. El receptor reconoce el fin de archivo por el tamaño del paquete UDP, se entiende que se llegó al final del archivo cuando el tamaño es menor a 512, o bien Página 5 de 61

20 es igual a 0. Esta última condición es útil cuando el archivo tiene un tamaño tal que entra en un número entero de paquetes de datos, en ese caso se transmite un paquete vacío indicando el fin de transmisión. Escritura de un archivo Se enviará un archivo en una sesión TFTP. [ ] server# tftp localhost [ ] tftp> put passwd Sent 1379 bytes in 0.2 seconds tftp> Resultados obtenidos tcpdump: listening on lo0 15:44: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.tftp: [udp sum ok] 18 WRQ "passwd" (ttl 64, id 31693, len 46) 0x e 7bcd f0 7f E...{...@... 0x0010 7f fd4c a 152b L.E...+..pa 0x e sswd.netascii. 15:44: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.64844: [udp sum ok] udp 4 (ttl 64, id 31695, len 32) 0x bcf fc 7f E...{...@... 0x0010 7f fd53 fd4c 000c 072f S.L.../... 15:44: localhost.esepecesito.com.ar > localhost.esepecesito.com.ar.64851: [udp sum ok] udp 516 (ttl 64, id 31696, len 544) 0x bd fefa 7f E...{...@... 0x0010 7f fd4c fd53 020c 907d L.S...}... 0x a f #.$FreeBSD:.src/ 0x f 6d e etc/master.passw 0x c e f 3034 d,v /04 0x0050 2f a34 353a d70 /27.05:45:29.imp 0x d0a 230d 0a72 6f6f 743a.Exp.$..#..root: 0x0070 2a3a 303a 303a d69 6e *:0:0:Administra 0x f 723a 2f72 6f6f 743a 2f62 696e 2f63 tor:/root:/bin/c 0x d0a 746f 6f72 3a2a 3a30 3a30 3a42 sh..toor:*:0:0:b 0x00a0 6f75 726e 652d e ourne-again.supe 0x00b a 2f72 6f6f 743a 0d0a 6461 ruser:/root:..da 0x00c0 656d 6f6e 3a2a 3a31 3a31 3a4f 776e 6572 emon:*:1:1:owner 0x00d0 206f d61 6e d20.of.many.system. 0x00e f a 2f72 6f6f 743a processes:/root: 0x00f0 2f e2f 6e6f 6c6f e0d 0a6f /sbin/nologin..o 0x f 723a 2a3a 323a 353a 5379 perator:*:2:5:sy 0x d a2f 3a2f e 2f6e stem.&:/:/sbin/n 0x0120 6f6c 6f67 696e 0d0a e3a 2a3a 333a ologin..bin:*:3: 0x a e f6d 6d61 7:Binaries.Comma 0x0140 6e e f a2f nds.and.source:/ Página 6 de 61