Desarrollo de un monitor de redes wifi con capacidades avanzadas de medición

Título: Desarrollo de un monitor de redes wifi con capacidades avanzadas de medición Autor: David Garcia Villalba Fecha: 29/06/2012 Director: Albert Cabellos Aparicio Departamento del director: Arquitectura de Computadors Codirector: Marc Portolés Comeras Institución del codirector: Centre Tecnològic de Telecomunicacions de Catalunya Centro: Facultat d'Informàtica de Barcelona (FIB) Universidad: Universitat Politècnica de Catalunya (UPC) BarcelonaTech WIRELESS NETWORK MONITOR Desarrollo de un monitor de redes wifi con capacidades avanzadas de medición Memoria del Proyecto Final de Carrera en Ingeniería Informática. Por David Garcia Villalba. Con la dirección de Albert Cabellos Aparicio y Marc Portolés Comeras. Wireless Network Monitor - David Garcia Villalba 2 La herramienta desarrollada en este trabajo se encuentra dentro del marco del proyecto DISTORSION del Centre Tecnològic de Telecomunicacions de Catalunya y ha estado parcialmente financiado por el Ministerio de Ciencia e Innovación (DISTORSION, TEC2010-10440-E). Wireless Network Monitor - David Garcia Villalba 3 Agradecer a Marc Portolés Comeras y a Albert Cabellos Aparicio el darme la posibilidad de realizar este proyecto, así como el apoyo y soporte recibido durante su desarrollo. Agradecer a Jordi Martínez Llamas sus comentarios y opiniones sobre el proyecto, así como las partidas al Tetris, Parchís o Pintamonas con las que desconectábamos del trabajo. Agradecer a Isaac Bernat Casi el soporte dado, tanto técnico como moral, durante toda la carrera, aun estando, en muchas ocasiones, bajo el efecto de las señales de los puntos de acceso Cisco que habían distribuidos por el campus. Agradecer a Marcos Puerto García y a Noelia Arroitajauregui Avilés el seguir aguantándome después de tantos años, con una mención especial a Noelia por preocuparse por mi salud fuera de su horario laboral. Wireless Network Monitor - David Garcia Villalba 4 Wireless Network Monitor Índice David Garcia Villalba 5 ÍNDICE 1 Introducción .......................................................................................................................... 9 1.1 Motivación .................................................................................................................... 9 1.2 Objetivos ..................................................................................................................... 10 1.3 Resultados ................................................................................................................... 10 1.4 Estado del arte ............................................................................................................ 11 1.4.1 Modo monitor ..................................................................................................... 11 1.4.2 Monitores de redes 802.11 ................................................................................. 11 1.4.2.1 Gestores de redes de los sistemas operativos ................................................ 11 1.4.2.2 inSSIDer ........................................................................................................... 12 1.4.3 Captura de paquetes ........................................................................................... 12 1.4.3.1 Tcpdump .......................................................................................................... 12 1.4.3.2 libpcap ............................................................................................................. 12 1.4.3.3 Kismet .............................................................................................................. 13 1.4.3.4 Wireshark ........................................................................................................ 13 1.4.4 PFC anterior ......................................................................................................... 13 2 Descripción de las métricas y del algoritmo........................................................................ 14 2.1 Métricas ....................................................................................................................... 14 2.2 Background tecnológico .............................................................................................. 14 2.2.1 Redes IEEE 802.11 ............................................................................................... 14 2.2.2 Medio de transmisión ......................................................................................... 15 2.2.3 Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) .................. 17 2.2.3.1 El problema del nodo oculto ........................................................................... 19 2.2.4 Los paquetes Beacon ........................................................................................... 20 2.3 Algoritmo ..................................................................................................................... 20 2.3.1 Eliminación de beacons antiguas ........................................................................ 21 2.3.2 Elección del pivote .............................................................................................. 22 2.3.3 Cálculo de las métricas ........................................................................................ 23 2.3.3.1 Cálculo de la pérdida de beacons en un intervalo de tiempo ......................... 23 2.3.3.2 Cálculo de los paquetes perdidos ................................................................... 24 2.3.3.3 Cálculo de la utilización ................................................................................... 25 2.3.4 Confianza en los valores ...................................................................................... 27 Wireless Network Monitor Índice David Garcia Villalba 6 3 Especificación del programa ............................................................................................... 28 3.1 Especificación de requisitos ........................................................................................ 28 3.1.1 Las partes interesadas (Stakeholders)................................................................. 28 3.1.1.1 El promotor del proyecto ................................................................................ 28 3.1.1.2 El cliente .......................................................................................................... 28 3.1.1.3 Los usuarios finales ......................................................................................... 28 3.1.2 Casos de uso ........................................................................................................ 29 3.1.3 Requisitos de calidad ........................................................................................... 36 3.2 Esquema conceptual ................................................................................................... 38 3.2.1 Atributos derivados ............................................................................................. 38 3.2.2 Descripción del esquema .................................................................................... 38 3.3 Diseño e implementación del programa ..................................................................... 39 3.3.1 Interfaz monitor .................................................................................................. 39 3.3.2 Captura de las beacons ....................................................................................... 40 3.3.3 Almacenamiento de las beacons ......................................................................... 41 3.3.4 Análisis de los datos ............................................................................................ 44 3.3.4.1 Eliminar las beacons antiguas ......................................................................... 46 3.3.4.2 Seleccionar la beacon pivote ........................................................................... 47 3.3.4.3 Calcular las métricas ........................................................................................ 48 3.3.5 El sistema de eventos .......................................................................................... 51 3.3.6 Cambio de canal .................................................................................................. 52 3.3.7 Implementación de las interfaces ....................................................................... 53 3.3.7.1 Interfaz de consola .......................................................................................... 53 3.3.7.2 Interfaz gráfica ................................................................................................ 54 3.3.7.3 Salida a fichero ................................................................................................ 54 3.3.8 Otros detalles ...................................................................................................... 55 3.3.8.1 Mejora de la precisión del algoritmo .............................................................. 55 3.3.8.2 Pruebas de la implementación ........................................................................ 56 4 El programa ......................................................................................................................... 57 4.1 Distribución ................................................................................................................. 57 4.2 Visión general de la herramienta ................................................................................ 58 4.2.1 Elementos comunes ............................................................................................ 58 4.2.2 Interfaz de consola .............................................................................................. 60 4.2.3 Interfaz gráfica .................................................................................................... 62 Wireless Network Monitor Índice David Garcia Villalba 7 4.2.4 Exportado a archivo CSV ..................................................................................... 65 4.2.5 Alteración de resultados ..................................................................................... 66 5 Análisis realizados con wmon ............................................................................................. 67 5.1 Entorno ........................................................................................................................ 67 5.2 Pruebas ........................................................................................................................ 67 5.2.1 Red a 6.5 Mbps .................................................................................................... 67 5.2.2 Red a 26 Mbps ..................................................................................................... 68 5.2.3 Red a 65 Mbps (821.11n) .................................................................................... 68 5.2.4 Descarga de un fichero con velocidad de red automática .................................. 69 5.2.5 Descarga de dos ficheros con velocidad de red automática ............................... 70 5.2.6 Monitorización nocturna sin generar tráfico ...................................................... 70 6 Gestión del proyecto ........................................................................................................... 72 6.1 Planificación ................................................................................................................ 72 6.2 Costes .......................................................................................................................... 75 7 Dificultades encontradas ..................................................................................................... 76 7.1 Programa para Android ............................................................................................... 76 7.2 Métricas uplink y downlink con pings ......................................................................... 77 8 Trabajo futuro ..................................................................................................................... 78 9 Conclusiones........................................................................................................................ 79 10 Glosario ........................................................................................................................... 80 11 Enlaces ............................................................................................................................. 83 12 Bibliografía ...................................................................................................................... 85 13 Anexo: Script - Gráficas de los CSV .................................................................................. 86 Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Métricas 14 2 DESCRIPCIÓN DE LAS MÉTRICAS Y DEL ALGORITMO La principal motivación para el desarrollo del programa es la generación de las métricas atípicas solicitadas, derivadas de cálculos que son función de los tiempos de envío de las beacons por parte de los puntos de acceso. En esta sección se hace una descripción de las métricas, se presentan los fundamentos en los que se basa su cálculo, y se finaliza con una descripción del algoritmo utilizado para calcularlas. 2.1 Métricas El programa a desarrollar debe de proporcionar información de las redes que detecte. Entre esta información se deberán mostrar dos métricas que serán calculadas a partir de las beacons enviadas por los puntos de acceso de las diferentes redes. Por un lado se generará una métrica que llamaremos utilización de la red (en adelante utilización). Esta métrica mostrará la saturación de una red, que puede verse afectada por diversos factores como que la red disponga de clientes transmitiendo y recibiendo datos, así como que se generen interferencias con otros elementos externos, por ejemplo, otras redes. Por otro lado, y con un nombre más descriptivo, se computará una métrica de paquetes perdidos en la red. 2.2 Background tecnológico 2.2.1 Redes IEEE 802.11 El estándar IEEE 802.11 define el uso de los dos niveles inferiores de la pila OSI, capa física y de enlace, especificando su funcionamiento en una red inalámbrica (Wireless LAN o WLAN). Los dispositivos que prueban y certifican que cumplen los estándares de transmisión inalámbrica definidas en los estándares 802.11 pueden denominarse con el nombre comercial Wi-Fi1. Actualmente multitud de dispositivos utilizan esta tecnología, desde ordenadores, siendo los portátiles los pioneros en su implantación masiva, hasta teléfonos, smartphones, televisores o impresoras. La cantidad de productos que disponen de conectividad Wi-Fi no hace más que crecer a lo largo de los años, implantándose en un abanico de productos cada vez más amplio. Los estándares más comunes en la actualidad son el 802.11b, 802.11g y 802.11n. Este último en proceso de expansión, siendo implementado cada vez en más dispositivos. En la actualidad se está desarrollando el estándar 802.11ac, pero ya se pueden encontrar noticias sobre los primeros dispositivos que implementan el actual borrador del estándar. 1 También se puede encontrar como: wifi Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Background tecnológico 15 2.2.2 Medio de transmisión Las redes 802.11 son inalámbricas, utilizando como medio de transmisión la radiofrecuencia o los infrarrojos. En los estándares 802.11 b y g se utiliza la banda de frecuencias de los 2.4 MHz. Esta se divide en canales con un ancho de banda de 22 MHz. Los canales se sitúan en rangos de frecuencias que difieren en 5 MHz, provocando un solapamiento entre canales adyacentes. Este solapamiento puede provocar que el canal 6 se vea afectado por interferencias de los canales 3, 4, 5, 7, 8 y 9. Por ello es habitual del uso de los canales 1, 6 y 11, que no tienen solapamiento entre ellos, si bien existen otras combinaciones que cumplen con esta característica: los pares de canales que estén a cinco canales de distancia o más no tienen interferencias entre ellos. El estándar 802.11n puede trabajar tanto en la banda de los 2.4 GHz como en la de los 5 GHz, con canales de 20 y 40 MHz. En la siguiente tabla se concentran algunos datos de los principales estándares 802.11: Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Background tecnológico 16 Modulación DSSS, FHSS OFDM DSSS OFDM, DSSS OFDM Flujos MIMO 1 1 1 1 4 8 Velocidad de datos por flujo (MB/s) 1, 2 6, 9, 12, 18, 24, 36, 48, 54 1, 2, 5.5, 11 6, 9, 12, 18, 24, 36, 48, 54 7.2, 14.4, 21.7, 28.9, 43.3, 57.8, 65, 72.2 15, 30, 45, 60, 90, 120, 135, 150 Hasta 87.6 Hasta 200 Hasta 433.3 Hasta 866.7 Ancho de banda (MHz) 20 20 20 20 20 40 20 40 80 160 Frecuencia (GHz) 2.4 5 3.7 2.4 2.4 2.4 / 5 5 Lanzamiento Junio 1997 Septiembre 1999 Septiembre 1999 Junio 2003 Octubre 2009 Noviembre 2001 Protocolo 802.11 Original a b g n ac (borrador) Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Background tecnológico 17 2.2.3 Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) La esencia del cálculo de la métrica utilización se basa en el funcionamiento del mecanismo de control de acceso al medio utilizado en las redes 802.11: CSMA/CA. Los mecanismos de control de acceso al medio se encargan de regular el acceso de las estaciones a un medio compartido. Estos mecanismos tienen como objetivo, además, minimizar las colisiones entre estaciones y definir el procedimiento a seguir de producirse alguna. El caso concreto de CSMA/CA es el de un mecanismo distribuido2 en el que una estación no puede detectar la colisión de una trama mientras la transmite, por ello implementa un sistema ARQ de tipo Stop and Wait para la transmisión de tramas unicast. En el caso de las tramas broadcast, si se produce una colisión, esta se pierde. El mecanismo llevado a cabo al enviar una trama se resume en los siguientes pasos: 1. La estación emisora escucha el medio. Si el medio está libre se espera un DIFS, y si mientras está esperando el medio sigue libre, se transmite la trama y se va al punto 3. En cualquier otro caso, donde el medio se ha visto ocupado, se continúa con el punto 2. 2. El emisor se espera para realizar la trasmisión. Para llevar esto a cabo se inicializa una cuenta regresiva, un backoff, que va decreciendo en intervalos fijos de tiempo llamados slots. El backoff solo se activa cuando el emisor observa el medio libre durante un DIFS, deteniéndose en el momento en el que el medio se ve ocupado. El valor del backoff se escoge uniformemente en el intervalo [0..CW], donde CW significa Contention Window y tiene como valor CW = 2n – 1. El valor de la n para el cálculo de la CW se suele iniciar en 5, obteniendo un CW de 31. Cuando el backoff llegue a cero, el emisor trasmitirá la trama inmediatamente. 3. El receptor, tras recibir la trama, espera un SIFS y envía la confirmación, el ACK. 4. Si el emisor recibe la confirmación antes de un DIFS desde que envió la trama, y tiene más que enviar, vuelve al paso 2 para enviar la siguiente. En caso de que no reciba el ACK antes del DIFS volverá también al paso 2 para retrasmitir la trama pero incrementando en uno el valor de la n utilizado en el cálculo de la Contention Window. El siguiente diagrama muestra, de forma visual, el mecanismo llevado a cabo cuando una estación envía una trama unicast, con su correspondiente ACK. 2 No hay un elemento que se encargue de arbitrar el acceso al medio. Son las propias estaciones las que llevan a cabo este trabajo. Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Background tecnológico 18 El host desea enviar una trama, pero observa que el medio está ocupado, por lo que debe esperarse y, además, hará uso del tiempo de backoff. En este ejemplo el host esperará 4 intervalos de tiempo, cada uno representado por un cuadrado naranja. Cuando el medio se libera el host espera un DIFS, mostrado en el diagrama como una llave de color gris en la parte del host, y, como el medio sigue libre, empieza a descontar el tiempo de backoff. Durante este tiempo el medio se ha vuelto a ocupar, por lo que el host detiene la cuenta regresiva hasta que detecta que se vuelve a liberar durante un DIFS, momento en el que continúa con la cuenta regresiva del tiempo de backoff que le tocaba esperar, en este caso le faltaban 3 intervalos de tiempo. Una vez agota el tiempo de backoff procede a enviar la trama, mostrado de color verde. Al llegar al destinatario, este espera un SIFS, representado como una llave de color gris en la parte del destinatario, y envía el ACK al host, mostrado de color azul. Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Background tecnológico 19 2.2.3.1 El problema del nodo oculto Para que el mecanismo de control de acceso al medio fuera efectivo, los hosts deberían poder escucharlo para comprobar si disponen del medio libre, varios puntos del mecanismo CSMA/CA dependen de este factor. Sin embargo nos encontramos con que en las redes inalámbricas esto no ocurre siempre. Un host no tiene la misma cobertura que otro, por lo que el medio se puede observar de manera diferente. Este fenómeno se conoce como el problema del nodo oculto, y se esquematiza en la siguiente ilustración: Sea A un nodo que quiere transmitir datos al nodo B, si A escucha el medio no podrá observar el posible tráfico que esté generando C, por lo que ambos podrían enviar sus tramas al mismo tiempo, colisionando en B y haciendo que este las descarte. Para evitar este problema se introdujo el mecanismo RTS/CTS (Request to Send / Clear to Send) en el que los nodos (A o C en el ejemplo descrito en el párrafo anterior) indican que desean enviar datos, siguiendo con el ejemplo, el nodo A envía una señal RTS. El nodo destinatario recibe la petición y le concede la posibilidad de enviar los datos, enviando un CTS, paquete en el que se indica que nodo es el que tiene el permiso de envío. Tanto A como C reciben el CTS. A procede con el envío de su trama, pero C, que también tiene datos para enviar, se espera, puesto que sabe que ya hay un nodo ocupando el medio. Este mecanismo es de implementación opcional, haciendo que muchos sistemas no lo implementen o lo tengan desactivado de serie. También añade un nuevo comportamiento no deseado, el conocido como el problema del nodo expuesto, en el que los hosts, sin que exista un problema de solapamiento real de coberturas, esperan para trasmitir datos debido a que reciben un paquete CTS. Para más información consultar [11]. Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Algoritmo 20 2.2.4 Los paquetes Beacon Los puntos de acceso en modo infraestructura, para anunciar su presencia a otros sistemas, envían un paquete con información identificativa de las redes que emiten, como por ejemplo el nombre de la red o el cifrado de esta. Estos paquetes se envían de forma periódica. Los momentos en los que un punto de acceso debería enviar una beacon se denominan Target Beacon Transmission Time Time (TBTT). La diferencia entre dos TBTT consecutivos es el intervalo entre beacons. El intervalo entre beacons es anunciado dentro de las propias beacons y se proporciona en unidades de tiempo3. Una unidad de tiempo equivale a 1024 microsegundos. Un intervalo entre beacons típico corresponde a 100 unidades de tiempo, lo que equivale a 102.4 milisegundos. Con este valor se deberían recibir entre 9 y 10 beacons cada segundo del punto de acceso que ha anunciado ese intervalo de tiempo. 2.3 Algoritmo Las beacons, aunque sean paquetes de gestión de la red, también se ven afectadas por el mecanismo de control de acceso al medio. Un punto de acceso no puede enviar una beacon si el medio está ocupado, teniendo que esperar a que este se libere para poder transmitirlo. Podemos aprovechar este comportamiento, junto con el hecho de que las beacons se envían de forma periódica, con un intervalo conocido, para derivar las métricas de utilización y pérdida de paquetes. En un medio ideal, suponiendo también un funcionamiento ideal de los elementos que pudieran afectar al envío, como podría ser un mal funcionamiento del punto de acceso, las beacons, tal y como se ha descrito en la sección 2.2.4 Los paquetes Beacon, deberían enviarse en momentos previsibles en función del intervalo de tiempo anunciado: en cada TBTT. 3 En la literatura se suele encontrar en su versión inglesa: Time Units (TU) Intervalo entre beacons TBTT Intervalo entre beacons TBTT Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Algoritmo 21 Las beacons, como cualquier otro paquete, pueden perderse. Conociendo en qué momentos deberían llegar las beacons, los TBTT, podemos calcular el número de beacons perdidas, lo que nos generará la métrica de paquetes perdidos. Por otro lado, si el punto de acceso encuentra el medio ocupado retrasará el envío de la beacon. Si caracterizamos las beacons como enviadas a tiempo o con retraso podemos derivar la utilización de la red como el porcentaje de beacons que se han enviado con retraso. Vistos los fundamentos en los que nos basaremos, a continuación se describe en detalle el algoritmo y los cálculos que se llevan a cabo para derivar estas métricas. A grandes rasgos, se realizarán las siguientes acciones:  Eliminación de beacons antiguas  Elección de la beacon pivote  Cálculo de las métricas 2.3.1 Eliminación de beacons antiguas Las métricas se derivan de un conjunto de beacons de la red que se está analizando. Este conjunto de beacons contendrá las últimas beacons llegadas en un intervalo de tiempo determinado. Esta etapa se encarga de eliminar, del conjunto de beacons guardas para la red que se está analizando, todas aquellas que tienen una antigüedad mayor al tiempo indicado. Últimos T segundos Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Algoritmo 22 2.3.2 Elección del pivote Uno de los problemas que nos encontramos a la hora de procesar las beacons es que no conocemos los TBTT y, por lo tanto, no disponemos de la referencia para poder decidir que beacons se envían con retraso. Una forma de derivarlos sería, a partir de una beacon que se ha enviado sin retraso, calcular los TBTT, puesto que conocemos los intervalos entre beacons. Sin embargo tampoco podemos conocer que beacon se ha enviado sin retraso, de hecho esto es lo que intentaremos calcular, así que tendremos que escoger una beacon pivote que haga de tiempo base y que supondremos sin retraso. Una vez escogida, podemos derivar los TBTT y hacer suposiciones de retrasos. Como beacon pivote escogeremos aquella que supongamos que tiene un menor retraso. Las beacons pueden retrasarse, pero no se adelantarán. Con esto, escogiendo una beacon que se haya enviado sin retraso, la diferencia entre el tiempo de llegada de una beacon y su TBTT será siempre mayor o igual a 0. 0 2 4 6 8 10 Beacons Retrasos Si se escogiera una beacon retrasada, o más concretamente, no se escogiera la beacon con menor retraso, los cálculos se verían afectados restándole a cada cómputo el retraso de la beacon pivote. Esto hará que las beacons con un retraso menor a la beacon pivote tengan un valor negativo de retraso respecto a ella: llegan antes del momento que se las espera. En la siguiente gráfica se muestran los retrasos si, en la gráfica anterior, se hubiera escogido la primera beacon como pivote. Wireless Network Monitor Descripción de las métricas y del algoritmo David Garcia Villalba Algoritmo 23 -4 -2 0 2 4 6 Beacons Retrasos Con todos estos elementos ya podemos realizar un algoritmo voraz de coste lineal que para la elección del pivote: Se escoge una beacon cualquiera como pivote, por ejemplo la primera beacon que se tenga en el conjunto de beacons, y se calculan los retrasos respecto a este pivote. La beacon pivote será aquella que tenga un menor valor de retraso, valor que será negativo. De haber empate entre varias beacons se podría escoger cualquiera de ellas. Si todos los retrasos son mayores o iguales a 0 significa que la beacon que hemos escogido ya es una beacon candidata a ser usada como pivote. 2.3.3 Cálculo de las métricas En este punto disponemos de las beacons que abarcan el periodo de tiempo sobre el que deseamos calcular las métricas y, de este conjunto, hemos establecido una beacon como tiempo base o pivote, beacon que consideraremos que se ha enviado a tiempo y que usaremos para predecir en que momentos tendrían que enviarse las demás beacons, esto es, predecir los TBTT. 2.3.3.1 Cálculo de la pérdida de beacons en un intervalo de tiempo Dado el intervalo entre beacons consideraremos que hay pérdida de paquetes si una beacon tarda más de en llegar respecto a la beacon anterior que tenemos almacenada. Siendo ∆t la diferencia de tiempo entre dos beacons consecutivas, siempre un número positivo, podemos calcular las beacons perdidas en este intervalo de tiempo con la fórmula: Wireless Network Monitor Especificación del programa David Garcia Villalba Especificación de requisitos 30 Caso de uso: Calcular estadísticas UC002 Descripción: El sistema procesa, de forma periódica, la información almacenada de las beacons, para generar unas estadísticas de las redes detectadas en el canal en el que está trabajando el programa en esos momentos. Actor principal: Sistema Precondición: --- Trigger: El reloj del sistema notifica que se han de calcular las estadísticas. Escenario principal: 1. El sistema calcula las estadísticas de las redes detectadas en el canal en el que está operando el programa en esos instantes. Para una descripción detallada del cálculo ver el apartado 2.3 Algoritmo. 2. El sistema notifica de la disponibilidad de unas estadísticas actualizadas. Extensiones: --- Caso de uso: Obtener listado de interfaces 802.11 UC003 Descripción: Se obtiene un listado con los nombres de las interfaces 802.11 disponibles en el sistema. Actor principal: Usuario Precondición: --- Trigger: Se solicita el listado de interfaces 802.11 del sistema. Escenario principal: 1. El actor principal solicita el listado de las interfaces 802.11 disponibles en el sistema. 2. El sistema muestra un listado con los nombres de las interfaces 802.11. Extensiones: --- Caso de uso: Seleccionar interfaz UC004 Descripción: El usuario indica al sistema la interfaz con la que debe de trabajar. Actor principal: Usuario Precondición: --- Trigger: Se indica al sistema la interfaz 802.11 a utilizar. Escenario principal: 1. El actor indica al sistema la interfaz 802.11 a utilizar. 2. El sistema crea una interfaz monitor sobre la interfaz 802.11 indicada por el usuario. 3. El sistema continúa trabajando con la nueva interfaz monitor creada. Extensiones: 2.a. El sistema ya estaba trabajando sobre una interfaz 2.a.1. El sistema elimina la interfaz monitor sobre la que estaba trabajando. 2.a.2. Se continúa con el paso 2 del escenario principal. Wireless Network Monitor Especificación del programa David Garcia Villalba Especificación de requisitos 31 Caso de uso: Cambio automático de canal UC005 Descripción: El sistema va cambiando de canal cada cierto tiempo. Actor principal: Sistema Precondición: --- Trigger: Se agota el tiempo que se debe de estar en el canal. Escenario principal: 1. Cuando se agota el tiempo que se ha de estar en el canal, ya sea por agotarse el tiempo en canal o por estar el canal vacío y realizar un cambio anticipado, el sistema intenta cambiar el canal de la interfaz sobre la que se está trabajando a otro canal de la lista de canales que se han de escanear. 2. Una vez seleccionado el canal, el sistema borra las beacons almacenadas de las redes del canal anterior. Extensiones: 1.a. No se puede realizar el cambio de canal 1.a.1. Se mantiene el canal actual. 1.a.2. Finaliza el caso de uso. 2.a. El nuevo canal seleccionado es el mismo que el anterior 2.a.1. No se realiza ninguna acción de limpieza. 2.a.2. Finaliza el caso de uso. Caso de uso: Establecer tiempo en canal UC006 Descripción: Se establece el tiempo que el programa estará analizando un canal antes de intentar cambiar a otro de la lista de canales a analizar. Actor principal: Usuario Precondición: --- Trigger: El actor desea establecer el tiempo que estará el programa analizando un canal. Escenario principal: 1. El actor indica cuantos segundos debe de estar el programa analizando un canal. 2. El sistema almacena el nuevo valor y continúa trabajando con el nuevo valor. Extensiones: 2.a. El valor introducido es menor a 5 2.a.1. Finaliza el caso de uso. Wireless Network Monitor Especificación del programa David Garcia Villalba Especificación de requisitos 32 Caso de uso: Establecer tiempo en canal vacío UC007 Descripción: Se establece el tiempo que el programa estará analizando un canal en el que no se captura ninguna beacon antes de intentar cambiar a otro de la lista de canales a analizar. Actor principal: Usuario Precondición: --- Trigger: El actor desea establecer el tiempo que estará el programa analizando un canal vacío. Escenario principal: 1. El actor indica cuantos segundos debe de estar el programa analizando un canal vacío. 2. El sistema almacena el nuevo valor y continúa trabajando con el nuevo valor. Extensiones: 2.a. El valor introducido es menor a 0 o mayor que el tiempo en el canal. 2.a.1. Finaliza el caso de uso. Caso de uso: Establecer canales a escanear UC008 Descripción: Se indican los canales que debe de escanear el programa. Actor principal: Usuario Precondición: Los canales a añadir han de ser números naturales. Trigger: El actor desea indicar los canales a ser escaneados por el programa. Escenario principal: 1. El actor indica al sistema los canales que desea que sean escaneados. 2. El sistema guarda los canales indicados como la lista de canales a escanear. Extensiones: 2.a. Alguno de los canales introducidos están repetidos 2.a.1. El sistema ignora los canales repetidos, añadiéndolos solo una vez, la primera que aparecen, a la lista de canales a escanear. Wireless Network Monitor Especificación del programa David Garcia Villalba Especificación de requisitos 33 Caso de uso: Añadir canal a escanear UC009 Descripción: Se desea añadir al sistema un nuevo canal para que sea escaneado. El mecanismo de cambio automático de canal pasará, eventualmente, por el canal añadido. Actor principal: Usuario Precondición: El canal a añadir ha de ser un número natural. Trigger: Se solicita añadir un canal a la lista de canales a escanear. Escenario principal: 1. El actor principal indica al sistema que quiere añadir un canal a la lista de canales a escanear. 2. El sistema añade el canal indicado por el actor principal a la lista de canales a escanear. Extensiones: 2.a. El canal indicado ya estaba en la lista de canales a escanear 2.a.1. El sistema ignora la petición. 2.a.2. Finaliza el caso de uso. 2.b. Se añade el segundo canal (la lista de canales a escanear pasa a tener dos canales) 2.b.1. El sistema activa, si no estaba desactivado por otros motivos, el cambio automático de canal. 2.b.2. Se continúa con el paso 2 del escenario principal. Caso de uso: Borrar canal a escanear UC010 Descripción: Se desea borrar del sistema uno de los canales de la lista de canales a ser escaneados. Actor principal: Usuario Precondición: El canal a borrar ha de ser uno de los canales de la lista de canales a escanear. Trigger: Se solicita borrar un canal de la lista de canales a escanear. Escenario principal: 1. El actor principal indica al sistema que quiere borrar un canal de la lista de canales a escanear. 2. El sistema borra el canal indicado por el actor principal de la lista de canales a escanear. Extensiones: 2.a. Se borra el canal que actualmente se está analizando 2.a.1. El sistema intenta cambiar al siguiente canal disponible. 2.a.2. Se continúa con el paso 2 del escenario principal. 2.b. Se deja un único canal en el sistema (la lista de canales a escanear pasa a tener un único canal) 2.b.1. El sistema desactiva, si no estaba desactivado por otros motivos, el cambio automático de canal. 2.b.2. Se continúa con el paso 2 del escenario principal. Wireless Network Monitor Especificación del programa David Garcia Villalba Especificación de requisitos 34 Caso de uso: Bloquear canal UC011 Descripción: Se desea que el programa detenga su mecanismo de cambio de canal automático y analice únicamente un canal. Actor principal: Usuario Precondición: El canal a bloquear ha de ser uno de los canales de la lista de canales a escanear. Trigger: Se solicita bloquear un canal de la lista de canales a escanear. Escenario principal: 1. El actor principal indica al sistema que quiere bloquear un canal de la lista de canales a escanear. 2. El sistema cambia al canal indicado, de ser necesario, y detiene el cambio de canal automático. Extensiones: 2.a. El sistema ya estaba bloqueado en el canal indicado 2.a.1. Se reanuda el cambio de canal automático. 2.a.2. Finaliza el caso de uso. 2.b. El sistema no puede cambiar al canal indicado 2.b.1. Finaliza el caso de uso. Caso de uso: Mostrar resultados UC012 Descripción: El sistema debe mostrar las métricas calculadas para las redes detectadas. Actor principal: Sistema Precondición: --- Trigger: Hay nuevos resultados para ser mostrados. Escenario principal: 1. El sistema mostrará las redes y métricas calculadas por pantalla, ordenadas por algún criterio indicado por el usuario. Como mínimo se mostrarán los siguientes datos: a. Datos de la red a la que pertenecen los cálculos: BSSID, SSID, canal, cifrado b. Métricas calculadas de la red: Utilización, pérdidas y RSSI Extensiones: -- Wireless Network Monitor Especificación del programa David Garcia Villalba Especificación de requisitos 35 Caso de uso: Exportar a archivo de texto UC013 Descripción: El sistema debe exportar las métricas calculadas para las redes detectadas a un archivo de texto en formato CSV. Actor principal: Usuario Precondición: --- Trigger: El usuario indica que desea exportar los resultados a un archivo de texto y hay nuevos resultados para ser mostrados. Escenario principal: 1. El usuario indica su deseo de exportar los datos que se van calculando a un archivo CSV, indicando la ruta donde se escribirá el archivo. 2. El sistema escribe los resultados en el archivo CSV cada vez que dispone nuevos datos. Cada línea del archivo CSV debe contener, como mínimo: a. Marca temporal de cuando se ha realizado el cálculo b. Datos de la red a la que pertenecen los cálculos: BSSID, SSID, canal, cifrado c. Métricas calculadas de la red: Utilización, pérdidas y RSSI Extensiones: 2.a. No se puede escribir en el archivo indicado 2.a.1. Finaliza el caso de uso. Wireless Network Monitor Especificación del programa David Garcia Villalba Especificación de requisitos 36 3.1.3 Requisitos de calidad Requisito: Implementado en lenguaje C/C++ RC001 Descripción: El programa debe de ser implementado en lenguaje C/C++. Justificación: A petición de los stakeholders, este debe de ser el lenguaje de programación utilizado para la implementación del proyecto. Criterio de satisfacción: El proyecto es implementado en C/C++. Requisito: Ejecución en entornos Linux RC002 Descripción: El programa debe de ejecutarse en entornos Linux. Justificación: A petición de los stakeholders, el programa debe de ser implementado para ser ejecutado en Linux. Criterio de satisfacción: El programa se ejecuta en entornos Linux en los que se disponga de las librerías de las que depende su ejecución. Requisito: Facilidad de instalación RC003 Descripción: Se debe facilitar la instalación del programa haciéndola lo más simple posible. Justificación: Facilitar el uso del programa por parte de usuarios con bajos conocimientos de uso de entornos Linux, eliminando la barrera de entrada que supone una complicada instalación. Criterio de satisfacción: Se crearán paquetes DEB que realizarán la instalación del programa en distribuciones compatibles con este sistema. Como distribución simple de referencia, los paquetes DEB deben de poder instalarse en Ubuntu (versiones 11.x y 12.x) utilizando este mecanismo. Requisito: Facilidad de uso RC004 Descripción: Se debe de facilitar el uso del programa, simplificando las opciones y dando valores por defecto a todos los elementos configurables. Justificación: Para que los usuarios no se vean abrumados o perdidos al ejecutar el programa, su ejecución debe de ser lo más simple posible. Criterio de satisfacción: El programa debe de poder ejecutarse sin introducir ningún tipo de configuración. Los stakeholders deben de dar su aprobación a las interfaces creadas, aceptando que se cumple este requisito. Wireless Network Monitor Especificación del programa David Garcia Villalba Especificación de requisitos 37 Requisito: Código abierto RC005 Descripción: El código del proyecto será liberado y puesto a disposición de otros usuarios. Justificación: Permite a otros usuarios nutrirse del conocimiento de este proyecto, así como mejorarlo y aportar ideas. Criterio de satisfacción: El código es liberado, está disponible para su descarga y se distribuye bajo una licencia compatible con este requisito. Requisito: Inglés como idioma RC006 Descripción: El programa y su manual deben de estar en inglés. Justificación: Como idioma utilizado internacionalmente, el programa debe de estar en inglés, así como el manual que se distribuye con el programa. Criterio de satisfacción: La interfaz y manual del programa están en inglés. Requisito: Manual del programa RC007 Descripción: Se incluirá una man page de Linux describiendo los argumentos del programa. Justificación: Para que los usuarios puedan conocer con que parámetros pueden llamar al programa, especialmente en la interfaz de consola, se incluirá una man page que los describa. Criterio de satisfacción: Se distribuye una man page explicando los argumentos del programa. Wireless Network Monitor Especificación del programa David Garcia Villalba Esquema conceptual 38 3.2 Esquema conceptual El siguiente esquema conceptual representa el conocimiento que debe ser manejado por el sistema a desarrollar: 3.2.1 Atributos derivados Estadísticas::potencia: Se deriva de la media de la potencia de las beacons de la red a la que pertenecen las estadísticas. Estadísticas::pérdidas: Se calcula tal y como se describió en la sección 2.3.3.2 Cálculo de los paquetes perdidos. Estadísticas::utilización: Se calcula tal y como se describió en la sección 2.3.3.3 Cálculo de la utilización. Canal::paquetes: Se calcula como la cantidad de beacons que hay en las redes del canal. 3.2.2 Descripción del esquema Los cálculos del sistema se basan en los paquetes beacons que vamos capturando, estos deben estar relacionados a las redes que anuncian. Las redes se emiten por un canal, y el sistema va analizando diversos canales configurados en la lista de canales. En un momento puntual solo está analizando un canal. El propósito del sistema es generar unas métricas de las redes, estas métricas están representadas en el esquema dentro de la clase Estadísticas. La información deberá mostrarse en ciertas interfaces. Una de ella, que nos interesa por el propósito de un esquema conceptual, es el exportador a un archivo de texto (CSV), que deberá conocer la ruta del archivo en el que escribirá los resultados. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 39 3.3 Diseño e implementación del programa En esta sección se va a realizar una descripción del diseño y la implementación del programa. Aprovecharemos la propia implementación para ir mostrando como ha sido diseñada para cumplir con la especificación de requisitos. El apartado se estructura recorriendo las diferentes funciones que debe realizar el programa para llevar a cabo su labor. 3.3.1 Interfaz monitor Toda la información que necesitamos en el programa sobre las redes 802.11 se obtiene a partir de las capturas de las beacons que envían los puntos de acceso. Para capturar estos paquetes necesitaremos poner una interfaz 802.11 en modo monitor. Este modo hace que la tarjeta de red capture todos los paquetes que recibe de las redes inalámbricas, sin necesidad de estar asociado a ningún punto de acceso. Haremos uso del script airmon-ng [4] que crea una interfaz 802.11 virtual en modo monitor basada en una interfaz física indicada. Haciendo uso de los derechos que nos otorga la licencia del script, lo añadiremos al código del proyecto para evitar que los usuarios tengan que buscarlo, aunque se encuentra disponible en los repositorios de las principales distribuciones Linux como parte del paquete de software aircrack-ng [5]. Por solicitud de uno de los stakeholders, el código del script será incrustado dentro del propio ejecutable con el objetivo de tener todo el programa en un único archivo. Cada vez que se necesite crear la interfaz monitor, por ejemplo al inicio de la ejecución del programa o cuando un usuario desee cambiar la interfaz con la que se trabaja haciendo uso de la interfaz gráfica, el programa creará la nueva interfaz llamando al script y trabajará sobre la nueva interfaz virtual. La llamada al script tiene la siguiente sintaxis: airmon-ng start wlan0 Si deseamos crear una interfaz monitor que trabaje sobre la interfaz física wlan0. El script también nos permite eliminar las interfaces monitor creadas llamándolo de la siguiente forma: airmon-ng stop mon0 En este caso debemos llamar al script indicándole una de las interfaces virtuales que ha creado. Una vez tenemos la interfaz monitor creada podemos proceder a la captura de las beacons que lleguen por la interfaz. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 46 Dejando para más adelante el trozo marcado como Código para comprobar la confianza del cálculo, en el código se pueden ver claramente los puntos enumerados en la descripción del algoritmo: 3.3.4.1 Eliminar las beacons antiguas Las beacons son guardadas en la lista en el mismo orden de llegada, siguiendo una estructura FIFO. Usando el tiempo actual, los segundos de beacons que deseamos almacenar, y los tiempos guardados de las beacons, podemos empezar por el principio de la lista, que serán los paquetes más antiguos, e ir eliminando hasta que entremos en el rango de tiempo que deseamos almacenar. Algo que se implementa con el siguiente código: void NetInfo::removeOldBeacons(unsigned int sec) { std::list<BeaconInfo>::const_reverse_iterator lastPacket = beacons.rbegin(); time_t actualSec = time(NULL); time_t minTime = actualSec - sec; while (not beacons.empty() and beacons.front().sec < minTime) beacons.pop_front(); if (not beacons.empty() and lastPacket->sec == actualSec) { while (not beacons.empty() and beacons.front().sec == minTime and beacons.front().usec <= lastPacket->usec) beacons.pop_front(); } } En la primera parte obtenemos una referencia al último paquete capturado y calculamos los timestamps validos, restando la cantidad de segundos que deseamos guardar al tiempo actual. Una vez disponemos del mínimo timestamp que aceptaremos, procedemos a borrar los paquetes de la lista hasta que hayan llegado con anterioridad a ese momento de tiempo. Para finalizar el borrado de beacons, y debido a que estas llegan en órdenes de magnitud de milisegundos, realizamos un último pequeño filtrado teniendo en cuenta esta pequeña fracción de tiempo. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 47 3.3.4.2 Seleccionar la beacon pivote Tras el filtrado de beacons procedemos a buscar la beacon pivote. El siguiente código se encarga de ello: void NetInfo::selectBest() { bestIndex = 0; int dnBest = 0; unsigned int loss = 0; std::list<BeaconInfo>::const_iterator bestPacket = beacons.begin(); std::list<BeaconInfo>::const_iterator packet = beacons.begin(); std::list<BeaconInfo>::const_iterator lastPacket = packet++; long long t0 = bestPacket->timestamp; for (unsigned int i = 1; i < numPackets; ++i, ++packet, ++lastPacket) { long int thi = packet->sec - lastPacket->sec; long int tlo = thi*SECtoMICROSEC + packet->usec - lastPacket->usec; loss += lossPackets(tlo, packet->interval); int dn = packet->timestamp - t0 - packet->interval*(i + loss); if (dn < dnBest) { bestIndex = i; dnBest = dn; bestPacket = packet; } } best = bestPacket; } El código, implementando lo descrito en la sección 2.3.2 Elección del pivote, va calculando los retrasos suponiendo como beacon pivote la primera beacon de la lista, seleccionando finalmente la que minimice este valor, que dejará en el atributo best. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 48 El retraso se mide comprobando la diferencia de tiempo entre el envío del paquete que estamos comprobando y cuando debería haber llegado, que se calcula en función del tiempo de envío de la beacon pivote, el intervalo entre beacons y la posición del paquete, teniendo en cuenta los paquetes perdidos. 3.3.4.3 Calcular las métricas Finalmente debemos realizar el cálculo de las métricas. bool NetInfo::calculateStats(bool stats) { bool error = false; int delayed = 0; int sumRSSI = 0; unsigned int packetsWithRSSI = 0; if (best->hasRSSI) { ++packetsWithRSSI; sumRSSI = best->rssi; } unsigned int lossLeft = 0; std::list<BeaconInfo>::const_iterator packet = best; std::list<BeaconInfo>::const_iterator lastPacket = packet--; // (1) for (int i = bestIndex - 1; not error and i >= 0; --i, --packet, --lastPacket) { long int thi = lastPacket->sec - packet->sec; long int tlo = thi*SECtoMICROSEC + lastPacket->usec - packet->usec; lossLeft += lossPackets(tlo, packet->interval); int dn = packet->timestamp - best->timestamp – packet->interval*(i - bestIndex - lossLeft); Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 49 if (packet->hasRSSI) { ++packetsWithRSSI; sumRSSI += packet->rssi; } if (dn > DELAY) ++delayed; else if (dn < -DELAY) error = true; } unsigned int lossRight = 0; packet = best; lastPacket = packet++; // (2) for (int i = bestIndex + 1; not error and i < numPackets; ++i, ++packet, ++lastPacket) { long int thi = packet->sec - lastPacket->sec; long int tlo = thi*SECtoMICROSEC + packet->usec - lastPacket->usec; lossRight += lossPackets(tlo, packet->interval); int dn = packet->timestamp - best->timestamp – packet->interval*(i - bestIndex + lossRight); if (packet->hasRSSI) { ++packetsWithRSSI; sumRSSI += packet->rssi; } if (dn > DELAY) ++delayed; else if (dn < -DELAY) error = true; } Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 50 if (stats) { // (3) unsigned int lossPackets = lossLeft + lossRight; unsigned int totalPackets = numPackets + lossPackets; double max = double(maxPackets); if (max < totalPackets) max = totalPackets; double tDelayedMin = delayed/max; double tDelayedMax = (delayed + max - numPackets)/max; double tDelayedCalculated = double(delayed)/numPackets; weightedDelay = tDelayedCalculated*tDelayedMax + (1 - tDelayedCalculated)*tDelayedMin; lost = (max - numPackets)/max; if (packetsWithRSSI > 0) rssi = sumRSSI/int(packetsWithRSSI); } return not error; } El código es casi una implementación directa del algoritmo descrito en la sección 2.3.3.3 Cálculo de la utilización. Primero, en (1), se calculan los paquetes retrasados desde la beacon pivote hasta el inicio de la lista. Seguidamente, en (2), se calculan desde la beacon pivote hasta el final de la lista. Durante los bucles vamos guardando también el acumulado de paquetes perdidos. Finalmente, si el valor del parámetro stats se evalúa a cierto, se calculan todas las métricas y se almacenan para su consulta. Durante los cálculos de los retrasos, en (1) y (2), se va comprobando que estos sean siempre números positivos. En caso de detectar alguno negativo, bajo un cierto margen de tolerancia, se pararán los cálculos y se retornará de la función indicando el error. Esto nos servirá para poder generar el valor de confianza de los resultados, explicado en el apartado 2.3.4 Confianza en los valores. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 51 Al inicio del método NetInfo::calculateStats(unsigned int, unsigned int), marcado en el pseudocódigo mostrado en este documento con un comentario, se realizará el cálculo de las métricas, sin guardar el resultado, para comprobar si la función retorna un error, es decir, ha encontrado retrasos negativos no tolerados. En la implementación usaremos un valor entero que cuenta las iteraciones que se han calculado las métricas sin detectar valores extraños. Como el cálculo se realiza cada segundo podemos usarlo también como contador de tiempo. El contador se pone a cero al añadir la red a la que pertenece o al detectar retrasos negativos. En otro caso el contador se va incrementando. Cuando el contador supere la cantidad de tiempo de almacenamiento de beacons indicaremos que confiamos en los cálculos, poniendo el atributo OK a cierto. Cada vez que dispongamos de nuevos datos calculados el sistema se lo notificará a las interfaces. 3.3.5 El sistema de eventos Para crear un sistema que separe lo máximo posible la lógica del programa de los elementos que utilizarán los datos calculados, como son la interfaz de consola o la interfaz gráfica, se ha optado por crear un sistema de eventos inspirado en el patrón observador [13]. La estructura seguida es la siguiente: La clase GUIEventDispatcher contiene el registro de interfaces, instancias de la clase GUI, y la cola de eventos que se producen, GUIEvents. Un thread independiente será el encargado de ir tratando los diferentes eventos que se produzcan. Cuando un elemento del sistema deba de notificar algo instanciará el objeto adecuado de GUIEvent y se lo pasará al gestor de eventos, que será el encargado de, eventualmente, realizar la acción adecuada para el evento sobre una interfaz, pasándole las diferentes instancias de GUI al evento. El objeto que genera el evento, una vez ha pasado la instancia de GUIEvent al gestor de eventos, continúa su ejecución sin esperar a que el evento sea tratado, lo que desacopla por completo la ejecución de la lógica del programa con la ejecución de la lógica llevada a cabo por las interfaces y su coste computacional. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 52 3.3.6 Cambio de canal Se creará un thread dedicado al control del cambio de canal automático del programa. Este thread ejecutará el siguiente código: void NetManager::controllerThread_func() { while (runController and channels.size() > 1) { if (setNextChannel()) { packets = 0; notifyChangeScanChannel(getChannel()); for (int i = emptyChannelTime; runController and i > 0; --i) { GUIEventDispatcher::registerEvent( new RemainingChannelTimeEvent(channelTime - emptyChannelTime + i)); sleep(1); } if (packets > 0) { for (int i = channelTime - emptyChannelTime; runController and i > 0; --i) { GUIEventDispatcher::registerEvent( new RemainingChannelTimeEvent(i)); sleep(1); } } } } El thread solo se ejecutará cuando haya más de un canal a analizar. Si durante la ejecución del programa se eliminan canales a analizar, llegando a dejar solo un canal, el thread se detendrá. De manera opuesta, si solo había un canal a analizar y se añade alguno nuevo el thread se volverá a ejecutar. El código simplemente notifica cada segundo del tiempo restante en el canal. El primer bucle se encarga de esperar la cantidad de tiempo que estaremos analizando un canal vacío. Si se ha capturado algún paquete, un segundo bucle esperará el tiempo restante hasta igualar el tiempo de análisis de un canal. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 53 El cambio de canal se delega a la función setNextChannel() que se encarga de cambiar a otro canal, de los que se encuentran en la lista de canales a analizar, haciendo uso del comando de Linux iwconfig. 3.3.7 Implementación de las interfaces Al programa se le pueden crear nuevas interfaces que serán notificadas de los diferentes eventos que genere el programa con el mecanismo de gestión de eventos. El único requisito para crear una interfaz es implementar la clase abstracta GUI: class GUI { public: virtual ~GUI(); virtual void updateChannel(unsigned short channel, const std::list<NetStats>& stats) = 0; virtual void updateScanChannel(unsigned short channel); virtual void updateRemainingChannelTime(int seconds); }; Las clases implementarán los métodos que sean de utilidad para la interfaz que estamos creando, a excepción del método updateChannel() que es una función virtual pura y se ha de implementar obligatoriamente. Una vez disponemos de una instancia de un objeto GUI deberemos registrarla como observador en el gestor de eventos. Con el programa se ofrecen tres interfaces, de las que procedemos a comentar las características más relevantes de su implementación. 3.3.7.1 Interfaz de consola Haciendo uso de la librería ncurses [14] construimos una interfaz de consola interactiva: la interfaz se va refrescando, mostrando la información actualizada, y reacciona a las pulsaciones de ciertas teclas, cambiando su comportamiento. La interfaz mantiene una lista con la información de las redes. Esta lista se mantiene ordenada por el criterio de ordenación que esté vigente en ese momento. Dado que la información que se espera mantener en el programa es relativamente poca para la potencia de los ordenadores, la ordenación de la información guardada de las redes se realiza llamando a la función std::list::sort() cada vez que se reciben nuevos datos, previa actualización o inserción de estos, y cada vez que se solicita el cambio de criterio de ordenación. El código se encarga de escribir por pantalla un número de redes que vendrá delimitado por el tamaño de la pantalla. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 54 Las redes que se muestren, cuando hayan más de las que quepan en la pantalla, dependerán de la posición solicitada por el usuario en el sistema de scroll implementado. Utilizando una variable que indique la posición en la lista de la primera red a mostrar, empezando en 0, podemos incrementarlo y decrementarlo en función de los eventos de teclado que capturemos. El sistema mostrará por consola todas las redes que quepan en función del tamaño de la pantalla, empezando por la red que ocupe la posición indicada en la variable, creando el efecto de scroll. 3.3.7.2 Interfaz gráfica La interfaz gráfica ha sido implementada con Qt [15] haciendo uso de Qt4 Designer, que permite realizar parte de la interfaz con un editor visual. Para completar la interfaz se han creado diversos plugins que intentan encapsular ciertas partes de la interfaz, como la lista de canales. En este caso el plugin se encarga de generar signals cada vez que se añade o se borra algún canal de la lista o se hace doble click sobre alguno. Para hacer el mejor uso posible de las funcionalidades que nos aporta la librería Qt utilizaremos el patrón Modelo-Vista propuesto por los desarrolladores de Qt [16]. Para ello simplemente crearemos una clase que heredará de una de las clases que hacen la función de modelo e implementaremos los métodos adecuados, haciendo que pueda guardar y retornar la información de que necesite la interfaz gráfica. Gracias a las funcionalidades ya implementadas en la librería Qt, y a hacer uso de este patrón, dispondremos automáticamente, previa una pequeña configuración, de la funcionalidad de ordenado de la información. 3.3.7.3 Salida a fichero Esta es una interfaz muy simple que únicamente necesita capturar las actualizaciones de la información de las redes. Cada vez que recibe este evento se encarga de escribir a un archivo, mediante un objeto std::ofstream, los datos con el formato adecuado. Como mejora, esta interfaz intenta filtrar ciertos resultados que le pueden llegar guardándose el timestamp de la última información que escribe, y solo escribiendo cosas que tengan un timestamp igual o superior al que tiene guardado. Wireless Network Monitor Especificación del programa David Garcia Villalba Diseño e implementación del programa 55 3.3.8 Otros detalles 3.3.8.1 Mejora de la precisión del algoritmo La implementación realizada en este proyecto del cálculo de las métricas genera unos resultados más estables y adecuados que el programa realizado en el PFC del cual se deriva este proyecto. Aunque los cálculos son los mismos, un mal tratamiento de la eliminación de las beacons antiguas y una mala decisión de cómo conocer el número de paquetes que se esperaban hacía que los resultados se fueran degradando con el paso del tiempo. En el implementado en el PFC anterior, para la eliminación de beacons antiguas solo se tenían en cuenta los segundos respecto al tiempo en el que se inicia el borrado, elementos también en segundos. Concretamente se utiliza la siguiente línea de código dentro de un bucle que itera por los paquetes: if((aux!=NULL ) && aux->sec < (actualtime - timeToDiscard)) Este es el único código que se encarga de decidir si una beacon ha de ser borrada o no, haciendo uso únicamente del campo donde guarda el momento de envío de una beacon en segundos. Esto implica que tenemos una pérdida de precisión del orden de 1 segundo en el programa. Por ejemplo, en los segundos 10.0 y 10.9, con este código, se borrarían las mismas beacons. Si timeToDiscard es 5 segundos, en ambos casos se borrarían las beacons que hayan sido enviadas en el segundo 4 o anteriores, sin embargo en el segundo tiempo se guardarían 0.9 segundos más de beacons. En un entorno habitual donde las beacons se envíen a 100 u.t. (una beacon cada 102.4 ms) implicaría una diferencia de entre 8 y 9 beacons. Para intentar solventar esta falta de precisión se tomó una segunda decisión errónea: el número de paquetes que se esperaban recibir se calculaba inicialmente de forma teórica haciendo uso del intervalo entre beacons, pero, una vez en ejecución, se iba actualizando con el valor máximo de paquetes que se habían capturado. Como se ha visto en el párrafo anterior, este valor es muy impreciso, donde se debería guardar timeToDiscard segundos de paquetes se podían llegar a tener casi timeToDiscard + 1 segundos. Esto hacía que, con la ejecución continuada del programa, la evolución de los paquetes esperados fuera incrementándose y, cuando se guardaban menos, por la falta de imprecisión, se contaran como beacons perdidas. En este proyecto, tal y como se ha mostrado en la sección 3.3.4.1 Eliminar las beacons antiguas, el borrado de beacons antiguas se hace en el orden de microsegundos, lo cual arregla este problema. Wireless Network Monitor El programa David Garcia Villalba Visión general de la herramienta 62 4.2.3 Interfaz gráfica En la segunda parte del proyecto se implementó la interfaz gráfica del programa haciendo uso de las librerías Qt. Esta interfaz proporciona, además de todas las funcionalidades del programa, la posibilidad de realizar cambios en la configuración durante la ejecución del programa. En la parte superior encontramos los elementos configurables. De izquierda a derecha son los siguientes: Permite seleccionar la interfaz con la que trabajará el programa. Es el equivalente al argumento --interface. Establece el tiempo que el programa pasa en un canal. Es el equivalente al argumento --ctime. Establece el tiempo que el programa pasa en un canal en el que no captura ningún paquete. Es el equivalente al argumento --ectime. Wireless Network Monitor El programa David Garcia Villalba Visión general de la herramienta 63 En la parte derecha del programa encontramos la lista de canales que el programa analizará. Esta lista puede ser modificada, además de por el uso del argumento --channel al ejecutar el programa, haciendo uso de los botones Add, para añadir, y Del, para borrar. Para añadir un canal a la lista se seleccionará en el cuadro que aparece a la izquierda del botón Add, que se deberá presionar una vez se haya indicado el canal que se desea añadir. Para eliminar un canal de la lista simplemente debe de seleccionarse el canal a eliminar de la lista de canales y pulsar el botón Del. Para darle mayor potencial a la lista de canales se le ha otorgado una funcionalidad extra no disponible en la interfaz de consola: bloquear el programa en un canal. El programa, en su ejecución normal, irá cambiando por los canales indicados en la lista de canales. Si deseáramos parar este comportamiento y que el programa se centre en un solo canal, con las herramientas que se han explicado hasta este momento, se deberían eliminar todos los canales, menos el deseado, de la lista de canales. Otra posibilidad sería cerrar el programa y volverlo a ejecutar haciendo uso del argumento --channel e indicando el único canal a analizar. Estas dos cosas tendrían el mismo resultado: El programa analizaría un solo canal. Para facilitar el análisis de un canal cuando el programa ya está en ejecución, sin tener que modificar la lista de canales, se ha implementado el bloqueo de canal. Cuando se hace doble click sobre uno de los canales de la lista el programa intentará cambiar al canal indicado y se quedará en el hasta que se vuelva a realizar un doble click en el mismo canal. Si se realiza un doble click en otro canal se considerará que se desea bloquear el análisis en el nuevo canal seleccionado, esto es, el programa intentará cambiar al canal seleccionado y se quedará bloqueado en el. En la parte central se muestra el listado de redes detectadas y las métricas calculadas por cada red. Esta lista puede ordenarse en base a cualquiera de los campos mostrados. Para ello solo hace falta hacer click en la cabecera de la tabla para solicitar al programa que realice la ordenación. En caso de igualdad se siguen los mismos criterios de ordenación que los explicados en la interfaz de consola. Debajo de la tabla podemos encontrar dos elementos con los que podemos interactuar. Por un lado encontramos el checkbox para llevar al final de la lista las redes que tengan un 100% de pérdidas. Wireless Network Monitor El programa David Garcia Villalba Visión general de la herramienta 64 Estas redes se muestran de la siguiente forma en la lista de redes: A su derecha encontramos la posibilidad de activar la exportación de datos a un archivo CSV. Para hacer uso de esto se ha de escribir la ruta en la que se escribirá el archivo, pudiendo hacer uso del botón Explore… para abrir un explorador de archivos. Seguidamente se podrá marcar o desmarcar la casilla Write to file, que iniciará o detendrá la escritura en el archivo. Finalmente, en la parte inferior encontramos información sobre el estado del programa. A la izquierda se muestra el canal que se está analizando. A la derecha se muestra el tiempo restante en el canal, sin tener en cuenta que la configuración de Empty channel time haga cambiar de canal con antelación. Wireless Network Monitor El programa David Garcia Villalba Visión general de la herramienta 65 4.2.4 Exportado a archivo CSV El archivo generado por la exportación de los datos a un archivo CSV contiene todos los resultados que el programa va generando. El programa calcula cada segundo las métricas de las redes del canal en el que se encuentra. Esta información es escrita en el archivo que se indique, ya sea por el uso de los argumentos -f o --file al ejecutar el programa o activando la casilla Write to file en la interfaz gráfica. En cada actualización de los datos calculados se escribe la información de cada red en líneas separadas. La siguiente actualización de los datos se escribirá a continuación, concatenando los diferentes resultados que se vayan calculando durante la exportación de los datos. Una línea del archivo tiene el siguiente aspecto: 1336600154,2012-05-09T23:49:14+0200,38:72:c0:d0:e2:3d,1,0.02,0.00,-47,y,Skynet En primer lugar encontramos marcas de tiempo, que tienen como finalidad proporcionar al analista de los datos información temporal sobre cuando se obtuvieron las muestras. Estas marcas se proporcionan en dos formatos:  En primer lugar se encuentra un Unix timestamp, que muestra, en segundos, el tiempo transcurrido desde el 1 de enero de 1970. Un problema de esta representación es que no tiene en cuenta las zonas horarias, por lo que dificultaría el tratamiento de datos obtenidos en sistemas con diferentes husos horarios.  En segundo lugar se proporciona el momento de captura en un formato que sigue la norma ISO 8601, y que proporciona toda la información necesaria para saber con exactitud en qué momento fue tomada la muestra: el año, mes, día, hora, minuto y segundos de captura, así como el desplazamiento horario desde UTC. Seguidamente se presenta la información calculada u obtenida por el programa y que pertenecen a las diferentes redes que se están escribiendo:  BSSID  Canal  Porcentaje de utilización: Valor que va entre 0 y 1.  Porcentaje de pérdidas: Valor que va entre 0 y 1.  RSSI: Potencia de la señal recibida en dBm.  Confianza de los datos: Es el homólogo al Valid en las interfaces de consola y gráfica. Muestra y cuando el programa confía en los datos, en otro caso muestra n.  SSID Wireless Network Monitor El programa David Garcia Villalba Visión general de la herramienta 66 4.2.5 Alteración de resultados Los resultados del programa se ven muy afectados por estar, o no, asociado a un punto de acceso. Para mostrar este comportamiento realizaremos una medición con un equipo, primero sin estar asociado ningún punto de acceso y, seguidamente, asociándonos a uno. Tras esto, podremos observar cómo se modifican los resultados por habernos asociado a un punto de acceso. En la siguiente captura se muestran unos resultados obtenidos sin estar asociado a ningún punto de acceso: Acto seguido nos conectamos a la red Skynet y seguimos observando los resultados: Como se puede ver la mayoría de redes han desaparecido, y las pocas que quedan, a excepción de la que estamos conectados, tienen una pérdida de paquetes muy elevada. Estos resultados son provocados por la característica de que la tarjeta de red se centra en el punto de acceso al que estamos conectados, obviando otras señales, lo que hace que, para el programa, las otras redes desaparezcan, puesto que no se reciben beacons. Wireless Network Monitor Análisis realizados con wmon David Garcia Villalba Entorno 67 5 ANÁLISIS REALIZADOS CON WMON 5.1 Entorno Estas pruebas han sido realizadas utilizando:  Ordenador de sobremesa con tarjeta wireless 802.11 b/g D-Link DWL-G520 [20] con chipset Atheros.  Ordenador portátil Dell Latitude E6520 [21] con tarjeta wireless 802.11 b/g/n Intel Centrino Advanced-N 6205 [22].  Modem-router con soporte wireless 802.11 g/n Comtrend VR-3025-u.  Conexión de salida a internet de 30 Mbps. Con el router, crearemos una red en la banda de frecuencias 2.4 GHz. La red será desplegada sobre el canal 1, el que se encuentra menos saturado por redes vecinales. El ordenador portátil se asociará a la red y generará el tráfico. El ordenador de sobremesa permanecerá sin asociarse a ninguna red y será el encargado de ejecutar el programa y realizar las mediciones. Para ir validando los resultados, también se tiene en ejecución el programa generado en el PFC anterior. 5.2 Pruebas Iremos configurando la red creada modificando la velocidad máxima a la pueden trasmitirse los datos. Con ello haremos diferentes pruebas intentando descargar un archivo de internet. 5.2.1 Red a 6.5 Mbps 0 0,2 0,4 0,6 0,8 1 Utilization Loss Con esta configuración la red Wi-Fi se convierte en un cuello de botella, puesto que tanto la conexión a Internet como el servidor que proporciona el archivo permiten velocidades superiores. Se puede observar claramente tanto el inicio como la detención de la descarga: en ambos extremos de la gráfica observamos una baja utilización de la red, mientras que cuando se está descargando la utilización sube a un valor que ronda el 90%. Esto concuerda con los resultados esperados, en los que la red está siendo muy utilizada. Wireless Network Monitor Análisis realizados con wmon David Garcia Villalba Pruebas 68 No hay muchas pérdidas de paquetes, exceptuando al inicio de la descarga, que observamos un incremento temporal de las pérdidas. 5.2.2 Red a 26 Mbps 0 0,2 0,4 0,6 0,8 1 Utilization Loss De nuevo tenemos una situación en la que la red Wi-Fi se convierte en un cuello de botella, sin embargo está vez la velocidad de la red se equipara bastante a la de la conexión a Internet. De nuevo podemos observar bastante bien el inicio y parada de la descarga. La gráfica comienza mostrando una red sin utilización y acaba en las mismas condiciones, pero por medio se puede ver con claridad el intervalo en el que se lleva a cabo la descarga, mostrándose una utilización de la red cercana al 80%. En esta gráfica observamos como las pérdidas de paquetes se incrementan respecto a la anterior prueba. Mientras que antes se asemejaba más a una línea recta cercana al 0, ahora se pueden observar más montículos, así como dos picos de pérdidas más importantes. Los resultados también concuerdan con lo esperado. Podemos observar claramente los momentos en la que la red está siendo usada y su carga es bastante elevada. 5.2.3 Red a 65 Mbps (821.11n) 0 0,2 0,4 0,6 0,8 1 Utilization Loss En esta nueva situación nos encontramos con que la salida a Internet se convierte en el cuello de botella. En la gráfica observamos los resultados más dispares hasta este momento. Se pueden ver los momentos de inicio y finalización de la descarga. Durante ella, la utilización no llega al 40%, excepto en un pico al final. Wireless Network Monitor Análisis realizados con wmon David Garcia Villalba Pruebas 69 De nuevo observamos que, junto con el incremento de velocidad de transferencia, las pérdidas parecen incrementarse. Los montículos que forma la gráfica de pérdidas son mayores, rondando el 10% de pérdidas. Los resultados pueden adecuarse a lo esperado, al estar trabajando sobre una red que permite más velocidad de la utilizada (como máximo 30 Mbps), siguiendo con la tendencia que hemos observado en pruebas anteriores. 5.2.4 Descarga de un fichero con velocidad de red automática 0 0,2 0,4 0,6 0,8 1 Utilization Loss Muchos routers domésticos vienen configurados para que sean ellos los que elijan la velocidad a la que trabaja la red inalámbrica, permitiendo, entre otras cosas, ahorrar energía. Las siguientes pruebas, comenzando por esta, tendrán el router configurado en modo de selección de velocidad automática. En esta primera prueba realizaremos la descarga de un fichero, muy similar a las pruebas que hemos realizado anteriormente. Podemos identificar tanto el inicio como el final de la descarga. La utilización es mucho más variable que lo que hemos ido observando hasta estos momentos y es, de media, bastante elevada. Las pérdidas no suelen pasar del 20%, excepto en varios picos que parecen tener una periodicidad. De hecho se observa como esos picos de pérdidas se producen incluso antes de que comencemos la descarga, además de producirse durante y después de ella. Podrían deberse a factores externos (interferencias con otras redes u otros elementos, así como un funcionamiento anómalo del router). También podemos ver como al finalizar la descarga, aunque las pérdidas bajan a 0, la utilización se queda rondando el 20%, pero con una tendencia a disminuir. Este es un comportamiento que he observado en diversas situaciones y que varias veces he podido comprobar que era culpa del router utilizado: con un simple reinicio la utilización tendía a 0. El inicio de la muestra es el esperado, una utilización cercana a 0. Los datos que se observan durante la descarga son muy variables, mostrando, en general, una utilización bastante alta. Lo menos esperado, tal y como se ha indicado, es la utilización que se muestra al final. Wireless Network Monitor Análisis realizados con wmon David Garcia Villalba Pruebas 70 5.2.5 Descarga de dos ficheros con velocidad de red automática 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 Utilization Loss Volvemos a realizar una prueba similar a la anterior, pero en este caso generaremos tráfico, lo detendremos, y volveremos a generarlo, para, finalmente, detenerlo de nuevo. En la gráfica podemos identificar fácilmente el inicio, parada y reanudación de la descarga, así como la detención final. Los datos mostrados son muy similares a los del apartado anterior: de nuevo la utilización es muy variable y bastante elevada, sobretodo en la segunda descarga. Las pérdidas de paquetes parece que se reducen de la prueba anterior, donde estaban más elevadas, aquí, sobretodo en la segunda descarga, tienden a 0. La gráfica muestra un comportamiento que concuerda con la prueba realizada, así como con las pruebas anteriores. 5.2.6 Monitorización nocturna sin generar tráfico 0 0,2 0,4 0,6 0,8 1 Utilization Loss Finalizamos mostrando los datos obtenidos por la noche durante unos 10 minutos de monitorización sin realizar ningún tipo de tráfico. En la gráfica hay dos elementos que destacan sobre los demás: Primero de todo, y bastante previsible, una baja utilización, cercana a 0, durante la mayoría del tiempo. Por otro lado, unos picos de pérdidas periódicos, similares a los que se han documentado en otras pruebas anteriormente expuestas. Por lo general la gráfica muestra un comportamiento que concuerda con lo esperado, una baja utilización y pocas pérdidas. Observamos que al inicio hay un pico de utilización, que puede Wireless Network Monitor Análisis realizados con wmon David Garcia Villalba Pruebas 71 deberse a interferencias con otros elementos que hayan ocupado el medio y provocado que las beacons se retrasaran. Lo más curioso son las pérdidas de paquetes periódicas. La explicación que le doy es la misma que en pruebas anteriores: puede deberse a algún factor que altere el funcionamiento del router, tal vez algún proceso interno, lo que explicaría más esa periodicidad, así como a otros elementos externos que interfieran en la señal. Obviamente, también se debería tener en cuenta una mala recepción o un mal funcionamiento del host que usamos para realizar la medición. Wireless Network Monitor Trabajo futuro David Garcia Villalba 78 8 TRABAJO FUTURO Un claro punto de trabajo futuro son los elementos descritos en la sección 7 Dificultades encontradas. Como se indicó en 7.1 Programa para Android se podría generar un proyecto para analizar más a fondo la viabilidad de portar el programa a sistemas Android, estudiando si es posible solventar los problemas detectados en este proyecto. También se podría estudiar con mayor detalle los problemas detectados en 7.2 Métricas uplink y downlink con pings, para comprobar si es posible reducir la variabilidad de los datos o, en su defecto, poder generar las métricas, aun con esta variabilidad. Otras posibilidades de trabajo futuro podrían ser la implementación de nuevas interfaces, siempre que resulten útiles, como por ejemplo el exportado de los resultados a una base de datos remota. Wireless Network Monitor Conclusiones David Garcia Villalba 79 9 CONCLUSIONES Con el desarrollo de este proyecto se ha conseguido crear una herramienta que cumple con los requisitos, establecidos en la etapa de análisis de requisitos, y que cubren los objetivos deseados por los stakeholders, adaptándose a las modificaciones que iban surgiendo a lo largo del tiempo y se iban acordando en diferentes reuniones. Es por ello que podemos considerar el resultado del proyecto como un éxito. Se ha creado una herramienta utilizable por casi cualquier usuario sin conocimientos, con una sencilla interfaz, tanto en el modo consola como con la interfaz gráfica, así como mejorada la precisión del algoritmo respecto a su anterior implementación. Se ha puesto a disposición de todos los que lo deseen el código fuente y los binarios del programa [17]. A nivel más personal, este es mi primer proyecto real para terceras personas, con unos stakeholders que tienen unos objetivos y esperan unos resultados, y en el que he podido hacer uso de diversos conocimientos obtenidos en la carrera. No solo la programación, elemento obvio al tratarse de la implementación de una aplicación, si no también valorar los conocimientos obtenidos en asignaturas como Ingeniería de Requisitos [24], que me ha ayudado a darle valor a esta parte del desarrollo de un proyecto y a definir sus requisitos, siempre encaminados a cumplir los objetivos consensuados con los stakeholders, punto que he visto como otros compañeros han fallado, llegándoles a complicar mucho las cosas al darse cuenta que no saben realmente que es lo que tenían que realizar o desarrollar cosas que no son las que deberían. Sin embargo, este proyecto también me ha valido para comprobar cómo se nos han dado unas herramientas y que no debemos aplicarlas siempre al pie de la letra, si no que debemos adaptarlas a nuestras necesidades, o incluso cuestionarlas. Todo esto no hace más que reforzar, a nivel personal, la idea de que el proyecto ha sido un éxito. Wireless Network Monitor Glosario David Garcia Villalba 80 10 GLOSARIO Ad-Hoc En informática, software que busca resolver un problema puntual. No se busca realizar un buen proceso de ingeniería de software ni una buena usabilidad. ARQ (Automatic Repeat Request) Protocolos utilizados para el control de errores en la transmisión de datos, garantizando la integridad de los mismos. Beacon Ver 2.2.4 Los paquetes Beacon. Broadcast Transmisión de un paquete que será recibido por todos los dispositivos en una red. Compilación Proceso de generación de un archivo ejecutable a partir de un código fuente. CSV (Comma-Separated Values) Archivo de texto plano para representar datos en forma de tablas, donde las columnas se separan por comas. DIFS (Distributed Coordination Function Interframe Space) Unidad de tiempo que el medio debe de detectarse como vacío. En las redes 802.11 se calcula como: SIFS + (2*Slot Time). Drivers Programa que controla el la comunicación con un hardware. Wireless Network Monitor Glosario David Garcia Villalba 81 Estación Ver Host. FIFO (First In, First Out) Indica que se trabaja con una estructura que se comporta como una cola, donde los primeros elementos en llegar son los primeros en salir. Host Usuario o cliente de una red. Interfaz virtual Interfaz que no existe físicamente, únicamente en el sistema operativo. Modo infraestructura Modo en el que todos los clientes de una red 802.11 se asocian a un punto de acceso y se comunican a través de él. Plugin (Qt) Unidad de creación de elementos usables en Qt Designer. Permite crear nuevos elementos o añadir nueva lógica a los ya existentes. Punto de acceso Elemento al que se conectan los clientes de una red inalámbrica en modo infraestructura. Este elemento también es el nexo de unión con la red cableada. Script Programa, habitualmente simple, guardado como un archivo de texto que contiene una serie de órdenes que son ejecutadas por algún tipo de intérprete. Wireless Network Monitor Glosario David Garcia Villalba 82 SIFS (Short Interframe Space) Menor intervalo de tiempo entre el envío de los datos y su confirmación. Signal (Qt) Notificación, por parte de un elemento de la interfaz, de que se ha producido un evento. Sniffer Programa que captura los paquetes de una red. Stop and Wait Al enviar una trama, se espera a recibir su confirmación antes de enviar la siguiente. Thread Hilo de ejecución de un programa. Un programa puede dividirse en diferentes threads que pueden estar siendo ejecutados de forma concurrente. Trama Unidad de envío de datos. Se puede ver como un paquete de datos. Unicast Transmisión de un paquete que será recibido por un único destinatario. Wireless Network Monitor Enlaces David Garcia Villalba 83 11 ENLACES [1] http://hdl.handle.net/2099.1/11488 [2] http://www.cttc.cat [3] http://www.cttc.cat/project/distorsion.jsp [4] http://www.aircrack-ng.org/doku.php?id=airmon-ng [5] http://www.aircrack-ng.org [6] http://www.metageek.net/products/inssider/ [7] http://www.tcpdump.org [8] http://www.winpcap.org [9] http://www.kismetwireless.net [10] http://www.wireshark.org [11] http://en.wikipedia.org/wiki/Exposed_node_problem [12] http://www.wand.net.nz/trac/libtrace [13] http://en.wikipedia.org/wiki/Observer_pattern [14] http://www.gnu.org/software/ncurses/ [15] http://qt.nokia.com [16] http://qt-project.org/doc/qt-4.8/model-view-programming.html [17] http://cba.upc.edu/developed-tools/wireless-network-monitor [18] https://github.com/wmon/wmon/ [19] http://www.github.com [20] http://www.dlink.com/products/?pid=12 [21] http://www.dell.com/us/enterprise/p/latitude-e6520/pd [22] http://www.intel.com/content/www/us/en/wireless-products/centrino-advanced-n6205.html Wireless Network Monitor Enlaces David Garcia Villalba 84 [23] http://forum.xda-developers.com/showthread.php?t=1317406 [24] http://www.fib.upc.edu/fib/estudiar-enginyeria-informatica/enginyeries-pla2003/assignatures/ER.html Wireless Network Monitor Bibliografía David Garcia Villalba 85 12 BIBLIOGRAFÍA  López Rovira, Daniel – Viabilitat de mesures d'eficiència de xarxes sense fils [1]  Marc Portoles Comeras, Marc Solé, José Núñez Martínez, Albert Cabellos Aparicio, Josep Mangues Bafalluy, Jordi Domingo Pascual – Packet level measurement of hidden traffic interference in WLAN networks.  Llorenç Cerdà Alabern – Xarxes de Computadors: Conceptes bàsics (ISBN: 9788498803310)  A Technical Tutorial on the IEEE 802.11 Protocol http://www.sss-mag.com/pdf/802_11tut.pdf  IEEE 802.11-2007 - http://standards.ieee.org/getieee802/download/802.11-2007.pdf  Matthew Gast – 802.11 Wireless Networks: The Definitive Guide (ISBN: 9780596100520)  http://linuxwireless.org/en/developers/Documentation/ieee80211/  http://en.wikipedia.org/wiki/802.11  Alejandro López Mongue – Aprendiendo a programar con Libpcap http://www.e-ghost.deusto.es/docs/2005/conferencias/pcap.pdf  Tim Carstens – Programming with pcap - http://www.tcpdump.org/pcap.html  Luis Martin Garcia – Programming with Libpcap - Sniffing the network from our own application - http://recursos.aldabaknocking.com/libpcapHakin9LuisMartinGarcia.pdf  Eric S. Raymond y Zeyd M. Ben-Hamlim – Escribir Programas con NCURSES http://es.tldp.org/Tutoriales/NCURSES/tutorial-ncurses.html  Pradeep Padala – NCURSES Programming HOWTO http://www.linuxdoc.org/HOWTO/NCURSES-Programming-HOWTO/index.html  Norman Matloff – Introduction to the Unix Curses Library http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/Curses.pdf  http://juanfc.lcc.uma.es/EDU/trabajos/curses-time-graf/Curses-UsoBasico.pdf  Carles Pina i Estany – ncurses para remolones http://bulma.net/impresion.phtml?nIdNoticia=2004  http://qt.nokia.com Wireless Network Monitor Anexo: Script - Gráficas de los CSV David Garcia Villalba 86 13 ANEXO: SCRIPT - GRÁFICAS DE LOS CSV Para facilitar la visualización de la utilización y pérdida de paquetes de una red a partir de los archivos CSV, se creó el siguiente script, que hace uso de gnuplot. El script también lista las redes que se encuentran dentro de un archivo CSV generado por wmon. #/bin/bash if [ $# -lt 1 ] || [ $# -gt 3 ] then echo "Ussage: $0 dataFile [bssid [outputFile.png]]" exit 1 fi DATAFILE=$1 if [ ! -f $DATAFILE ] then echo "Error: File \"$DATAFILE\" does not exists." exit 1 fi if [ $# -eq 1 ] then cut -d',' -f3,4,9 $DATAFILE | sort | uniq echo echo "Total: `cut -d',' -f3,4,9 $DATAFILE | sort | uniq | wc -l` networks" exit 0 fi if [ $# -eq 3 ] Wireless Network Monitor Anexo: Script - Gráficas de los CSV David Garcia Villalba 87 then if [ -f $3 ] then echo "Error: Output file \"$3\" already exists." exit 1 fi OPTIONALCMD="set terminal png set output \"$2\"" fi gnuplot -persist <<EOC $OPTIONALCMD set datafile separator "," set style data lines set xlabel "Sample" set ylabel "%" set yrange[0:1] set size 1,0.5 set multiplot set origin 0,0.5 plot "<grep $2 $DATAFILE" using 0:5 title "Utilization" set origin 0,0 plot "<grep $2 $DATAFILE" using 0:6 title "Loss" unset multiplot EOC