ANÁLISIS DE REDES MESH CON WIRESHARK

Transcripción

1 Universidad de Valladolid ETS de Ingenieros de Telecomunicación Máster Universitario de Investigación en Tecnologías de la Información y las Telecomunicaciones Asignatura Servicios Avanzados de Apoyo a Aplicaciones Telemáticas (SAA) ANÁLISIS DE REDES MESH CON WIRESHARK Jorge Diez, Pablo López, Juan Alberto Muñoz 22/12/2009 Resumen: El presente informe es un trabajo de la asignatura Servicios Avanzados de Apoyo a Aplicaciones Telemáticas, dentro del Máster Universitario de Investigación en Tecnologías de la Información y las Telecomunicaciones de la Universidad de Valladolid. En él se analiza mediante wireshark el funcionamiento de una red mesh s formada por cuatro ordenadores portátiles con una versión de GNU/linux en la que está implementado el software open80211s.org. 1 Introducción Este informe se engloba en la asignatura Servicios Avanzados de Apoyo a Aplicaciones Telemáticas, dentro del Máster de investigación en TIC de la Universidad de Valladolid. En esta asignatura se estudian las redes s, redes wifi mesh, y se ha conseguido implementar en portátiles un sistema operativo GNU/linux con funcionalidad s. Se han montado varios escenarios y realizado diferentes prácticas en ellos, presentando en el presente informe un análisis básico del funcionamiento de una red s, con trazas capturadas con el analizador de protocolos wireshark [2]. En las siguientes secciones se presenta primero la topología del escenario analizado, para en la siguiente sección analizar una secuencia completa de diálogo HWMP, y por último presentar unas pequeñas conclusiones de lo estudiado. 2 Topología El escenario con el que se ha realizado el estudio han sido cuatro ordenadores portátiles con GNU/linux instalado, estando en el kernel activos los parámetros correspondientes a s de open80211s.org [1], y la funcionalidad de s (wifi mesh) funcionando. De esta forma, se crea una red mesh s entre los portátiles, según la topología de la figura 1. El PC 16 de la misma, además de estar conectado a la red mesh mediante su interfaz wifi, también 1

2 tiene una conexión cableada al router Aula Móvil GSIC, el cual tiene salida a internet. El PC 16, hace routing y NAT entre la red mesh y la red local GSIC Aula móvil. Figura 1 Nodos de la red Mesh: MPP-Asensio (portátil de la sala), MAC: 75:ff MP-Juan, MAC: 7a:65 Las capturas mostradas pertenecen a este MP, debido a que en él se ven todos los mensajes. MP-Jorge, MAC: 76:2a MP-Pablo, MAC: 79:88 3 Análisis de trazas En el tiempo 16:51:17 todos los ordenadores están conectados a la red mesh. Cada 5 segundos se produce la actualización de tablas por lo que cada usuario lanza un broadcast preguntando por aquellos MP que necesita conocer (por ejemplo el ping que lanzaba Pablo sobre la máquina de la sala) y que no tiene visibilidad directa. El temporizador de 5 segundos se observa en las trazas, donde los mensajes se agrupan en ráfagas, con una separación aproximada entre las ráfagas de 5 segundos. Investigando sobre esos 5 segundos, observamos cómo el expiration timeout tiene un valor de 5000 unidades, que va decreciendo durando aproximadamente esos 5 segundos: 2

3 Figura 2 La columna señalada en la figura 2 corresponde al Expiration Time, tiempo en que el path expira, tal y como puede observarse en la documentación de open80211s (figura 3). Figura 3 El expiration time se mide en jiffies, que como puede verse en la figura 4, es un parámetro de configuración del kernel de linux. Figura 4 Analizando los parámetros configurables de mesh en iw, suponemos que el parámetro mediante el que se configura el expiration time es el mesh_hwmp_active_path_timeout, que tiene un valor de 5000 TUs (posiblemente 5000 unidades de tiempo, o 5000 jiffies). 3

4 iw dev mesh0 get mesh_param mesh_hwmp_active_path_timeout 5000 TUs A continuación analizamos una secuencia completa, en la que se ve perfectamente el funcionamiento del protocolo de encaminamiento de s, HWMP. La secuencia comienza por un PATH REQUEST (PREQ) con destino broadcast que envía Asensio preguntando por Pablo. Puede verse en la Figura 5. Se observa que el flag TO está a 0, que es lo que en los distintos documentos analizados en la asignatura corresponde con el DO=1. De esta forma, lo nodos intermedios no deberían responder con un PATH RESPONSE (PREP) aunque tengan al destino en su path table. Todo esto puede verse en la figura 5. Figura 5 Efectivamente, en las figuras 6 y 7 se observa, respectivamente, cómo Jorge y Juan reenvían el PREQ con destino broadcast, sin responder al origen con PREP. Puede verse también como el PREQ ID es el mismo (407), y cómo se decrementa en uno el TTL y se incrementa en uno el hop count. La métrica también se incrementa, en el valor que corresponda al tramo. 4

5 Figura 6 Figura 7 A continuación, Pablo responde a ambos PREQ (al que ha recibido de Jorge y al que ha recibido 5

6 de Juan) con un PREP con target Asensio. Lo interesante es que responde con unicast a Jorge y a Juan. Esto puede observarse en las figuras 8 y 9 (PREPs enviados a Jorge y a Juan respectivamente). En uno de ellos, el target sequence number se conserva (242) y en el otro se incrementa en uno (243). Figura 8 6

7 Figura 9 Jorge y Juan reenvían el PREP a Asensio, como puede verse en las figuras 10 y 11 respectivamente. El mensaje es también unicast. De manera análoga al PREQ, se observa cómo se el TTL se decrementa en uno, el hop count se incrementa en uno, y la métrica se incrementa el valor que corresponda. Figura 10 7

8 Figura 11 A los cinco segundos, una vez expirado el timeout del path, Pablo, envía un PREQ broadcast preguntando por Asensio. Se observa que el originator sequence number (el de Pablo) se incrementa en uno (244) con respecto al mayor de los recibidos antes, y el target secuence number (el de Asensio) es el mismo que el que venía en el PREQ (844), que no ha variado desde el principio de la secuencia. 8

9 Figura 12 Desconexión de Jorge. A continuación, Jorge se desconectó de la red mesh (desactivando la interfaz mesh), pero en las trazas no se observa nada significativo, salvo la ausencia de mensajes de Jorge. El funcionamiento es similar a lo descrito. 4 Conclusiones En el escenario analizado hemos visto cómo funciona el encaminamiento HWMP en una red mesh s. Con el parámetro Destination Only (DO) a 1, los nodos intermedios no responden ante un PREQ con un PREP, aunque tengan un path hacia el destino, y reenvían el PREQ con destino broadcast. Un destino B, que recibe un PREQ de un nodo A, responde con PREP unicast hacia los nodos intermedios, que propagan el PREP hasta el origen. 5 Referencias [1] Open80211s. Web: (Última visita 22/12/2009). [2] Wireshark. Web: (Última visita 22/12/2009). 9