Facultad de Ingenier´ıa - Universidad de la Republica´

Proyecto de grado

Construcci´onde routers inal´ambricos para monitorizar calidad de servicio

Autores: Supervisores: Johnatan Stanley Galli Mat´ıasRichart Guti´errez Nicol´asSantiago Puppo Perna Eduardo Gramp´ın Castro

Instituto de Computaci´on

9 de julio de 2015 “Confine yourself to observing and you always miss the point of your life. The object can be stated this way: Live the best life you can. Life is a game whose rules you learn if you leap into it and play it to the hilt. Otherwise, you are caught off balance, continually surprised by the shifting play. Non-players often whine and complain that luck always passes them by. They refuse to see that they can create some of their own luck. Darwi Odrade - Chapterhouse: Dune”

Frank Herbert

(“Lim´ıtatea observar y siempre perder´asel sentido de tu vida. Se puede poner de esta manera: Vive la mejor vida que puedas. La vida es un juego cuyas reglas aprendes si saltas a ella y la juegas a fondo. De lo contrario, te encontrar´asen una inestabilidad constante, sorprendi´endote continuamente de los cambios del juego. Quienes no juegan, a menudo se quejan de que la suerte les pasa por al lado. Se niegan a ver que pueden crear un poco de su propia suerte. Darwi Odrade - Dune: Casa Capitular”) Resumen

Las redes inal´ambricas 802.11, conocidas com´unmente como redes “Wi-Fi”, se enfrentan a una gran variedad de problemas de se˜naly cobertura. En este proyecto se construye una herramienta que monitorea las redes inal´ambricas, brindando diversa informaci´onde las mismas, teniendo como objetivos centrales entender sus problemas y analizar su funcionamiento, permitiendo lograr una mejor planificaci´on.

A lo largo del proyecto se ha avanzado en la construcci´onde esta herramienta, comenzando con la interiorizaci´onen este tipo de redes y sus problem´aticas,realizando luego diferentes estudios del estado del arte, posibles arquitecturas y par´ametrosde monitorizaci´oninteresantes, para finalmente comenzar con el desarrollo de la herramienta.

El desarrollo se agrupa en diferentes etapas, desde el dise˜noy arquitectura del sistema, hasta su implementaci´oncompleta utilizando C y C++. Luego de completado el desarrollo, se realiz´oco- mo caso de estudio un despliegue en el Instituto de Computaci´oncon el objetivo de tomar mediciones de las redes inal´ambricas dentro de un entorno real. Finalmente se analizaron los re- sultados obtenidos en el despliegue para hallar conclusiones sobre la utilidad de la herramienta, verificando que cumple con los objetivos propuestos. Agradecimientos

A quienes nos acompa˜naron durante esta importante etapa. Se cierra un ciclo del cual nos llevamos much´ısimo.Sigamos disfrutando el camino. Gracias!

A Shawn Patterson, Joshua Bartholomew, Lisa Harriton, The Lonely Island, Tegan y Sara, por alegrar nuestras jornadas de desarrollo. Everything is Awesome!

iii Contenido

Resumen II

Agradecimientos III

Contenido IV

1. Introducci´on 1 1.1. Problem´aticaexistente...... 1 1.2. Objetivos...... 2 1.3. Composici´ondel trabajo presentado...... 2

2. Antecedentes4 2.1. Redes inal´ambricas...... 4 2.2. Familia 802.11...... 6 2.3. Funcionamiento de una red LAN inal´ambrica 802.11...... 7 2.3.1. Asociaci´onde los clientes con los APs...... 8 2.3.2. Utilizaci´ondel canal por diferentes clientes...... 9 2.3.3. Detectando el estado del medio...... 10 2.3.4. Problema del terminal oculto...... 11 2.4. La trama IEEE 802.11...... 12 2.5. Problemas de calidad de la se˜nalen las redes inal´ambricas...... 15

3. Hardware 16 3.1. Hardware utilizado...... 16 3.2. Routerboard 133...... 16 3.3. Routerboard R52...... 18 3.4. OpenWRT...... 20 3.5. TP-LINK...... 20

4. Estado del arte 22 4.1. Estado del arte en hardware de routers inal´ambricos...... 22 4.1.1. Router Inal´ambrico...... 22 4.1.2. Funcionamiento de un router inal´ambrico...... 23 4.1.3. Qualcomm Atheros...... 23 4.1.4. Intel...... 24 4.1.5. Broadcom...... 24 4.1.6. Comparativa...... 24

iv Contenido v

4.2. Estado del arte en firmware de c´odigoabierto...... 25 4.2.1. Introducci´on...... 25 4.2.2. Alchemy y Talisman - SVEASOFT...... 26 4.2.3. HyperWRT y Tomato...... 27 4.2.4. DD-WRT...... 27 4.2.5. OpenWRT...... 28 4.2.6. X-WRT...... 28 4.2.7. Tarifa...... 28 4.2.8. Elecci´ondel firmware...... 29 4.3. Estado del arte en lenguajes de programaci´onpara sistemas embebidos...... 29 4.3.1. Definici´onde sistema embebido...... 29 4.3.2. Evoluci´onde los sistemas embebidos...... 30 4.3.3. Areas´ de aplicaci´ony ejemplos...... 30 4.3.4. Caracter´ısticascomunes...... 31 4.3.5. Componentes de un sistema embebido...... 32 4.3.6. Requerimientos de dise˜no...... 33 4.3.7. Desarrollo de software en sistemas embebidos...... 34 4.3.8. Lenguajes en sistemas embebidos...... 35 4.3.9. Elecci´ondel lenguaje a utilizar...... 40 4.4. Arquitecturas de monitorizaci´on...... 41

5. Monitorizaci´on 43 5.1. Indicadores de calidad...... 43 5.2. Herramientas de an´alisisexistentes...... 47 5.3. Merkai - CISCO...... 50

6. Desarollo 52 6.1. Generalidades...... 52 6.1.1. Acercamiento a OpenWRT y las herramientas disponibles...... 52 6.1.2. Trabajando sobre la Routerboard 133...... 54 6.1.3. Trabajando sobre TP-Link TL-WDR4300...... 57 6.2. Implementaci´on...... 58 6.2.1. Idea general y arquitectura...... 58 6.2.2. Servidor...... 59 6.2.3. Base de datos...... 61 6.2.4. Interfaz con el usuario...... 62 6.2.5. Monitor...... 65 6.2.6. Comparaci´onlibpcap y tcpdump...... 68

7. Evaluaci´on 70 7.1. Caso de estudio...... 70 7.1.1. Escenario de pruebas...... 70 7.1.2. M´etricasde las capturas de datos...... 71 7.2. Procesamiento de los datos capturados...... 71 7.2.1. An´alisis medio ocupado...... 71 7.2.2. Tipos de paquetes...... 74 7.2.3. Clientes que m´aspaquetes y volumen de datos enviaron...... 79 Contenido vi

7.2.4. Cantidad de paquetes y tr´aficodurante una semana...... 81 7.2.5. Comparaci´onde cantidad de paquetes y transferencia semanal...... 85 7.2.6. Medici´onde se˜nal...... 88 7.2.7. Comparaci´onde tipos en cada monitor...... 89 7.2.8. Cantidad de dispositivos registrados...... 93 7.2.9. Tr´aficosin AP origen ni destino...... 94 7.2.10. Comparaci´onentre tr´aficoenviado y recibido por los APs...... 94 7.2.11. Conclusiones de la evaluaci´on...... 96

8. Conclusiones y trabajo a futuro 97 8.1. Conclusiones...... 97 8.1.1. Investigaci´on...... 97 8.1.2. Desarrollo...... 98 8.2. Trabajo a futuro...... 99

Listado de Figuras 100

Listado de Tablas 103

A. Uso de la herramienta 104 A.1. Consideraciones para que la herramienta funcione correctamente...... 104 A.2. Funcionamiento de la herramienta...... 105

B. Base de datos 106 B.1. Pasos para instalar y configurar la base de datos...... 106 B.2. Script para generar las tablas...... 106

C. C´odigo 108 C.1. Script macState.sh...... 108 C.2. Servidor...... 110 C.3. Monitor...... 120

D. Compilaci´onpara OpenWRT 124 D.1. Paso a paso para la compilaci´oncruzada para OpenWRT...... 124 D.2. Makefile com´un...... 125 D.3. Makefile OpenWRT...... 125

Bibliograf´ıa 128 Dedicado a los que sab´ıanque este d´ıaiba a llegar. . .

vii Cap´ıtulo1

Introducci´on

1.1. Problem´atica existente

Es com´unque en sitios p´ublicos(como universidades, centros comerciales, etc.) se cuente con un servicio de red inal´ambrica, el cual debe poseer una amplia cobertura para ser brindado en buenas condiciones a los usuarios dentro de la zona que se quiere alcanzar. En entornos de este tipo es complejo y dif´ıcilplanificar la instalaci´onde puntos de acceso (los cuales brindar´anel acceso a la red) de forma que se disponga de buena cobertura y calidad de servicio.

En particular, en lo que refiere a la calidad, existen diversos problemas para brindar un buen nivel de servicio. Esto ocurre por las particularidades del medio que utilizan las redes inal´ambricas para transportar los datos, es decir, el aire, donde existen diversas fuentes de problemas que pueden mermar la calidad del servicio ofrecido. Esto se debe en parte a la heterogeneidad del medio, en el cual coexisten diferentes tipos de se˜nalesjunto a los datos transportados por la red inal´ambrica, como son aquellas generadas por los tel´efonosinal´ambricos, celulares, radios, hornos microondas, entre otros, y son conocidas como interferencia.

Adem´as,no solo existen estas otras se˜nalesque interfieren con la red inal´ambrica, sino que, a diferencia de una red cableada, donde los datos se transfieren por un medio dedicado, en las redes inal´ambricas los datos se encuentran y colisionan con los objetos f´ısicos que existen en el espacio mientras viajan entre dos puntos, ya sea una pared, un mueble, una persona, etc. Estas interferencias reducen la calidad del servicio que brinda la red, generando problemas para el usuario final al querer utilizar la misma.

M´asadelante, se analizan en profundidad los diferentes tipos de problemas existentes, planteando los escenarios m´ascomunes a los que suelen enfrentarse las redes de este tipo.

1 Cap´ıtulo1. Introducci´on 2

1.2. Objetivos

En este proyecto se propone abordar los problemas existentes en redes inal´ambricas densas desde el punto de vista de su detecci´ony el an´alisisde sus causas. Se plantea implementar un sistema de monitoreo utilizando routers que sean capaces de obtener ciertos indicadores de la red para ayudar en su planificaci´on,con el objetivo de ofrecer un buen nivel de servicio. Se tomar´an mediciones de diversas variables del medio inal´ambrico para obtener m´etricasde la calidad del servicio.

Para realizar dicha tarea se cuenta con placas de routers con capacidad de dos interfaces inal´ambricas (hardware existente en la facultad). De esta forma es posible utilizar una para dar servicio y la otra para monitorizar (monitor fuera de banda). Como se explicar´am´asade- lante, adem´asde estas placas, se disponen de routers TP-LINK que no poseen dos interfaces inal´ambricas, por lo que pueden cumplir una ´unicafunci´ona la vez.

Se realizar´aun estudio del estado del arte de diferentes tem´aticasque ayudar´ana la elecci´onde los distintos componentes del sistema a construir. Para profundizar en los dispositivos y sistemas operativos disponibles para los routers se realizar´ael estado del arte en hardware de routers inal´ambricos y el estado del arte en firmware de c´odigoabierto. Por otro lado se estudiar´ael estado del arte en lenguajes de programaci´onpara sistemas embebidos para la construcci´ondel software que se desarrollar´aen el sistema.

Junto a lo anterior se estudiar´andiferentes arquitecturas de monitorizaci´ondistribuida y se buscar´anlas variables relevantes a ser medidas para tener un buen indicador de la calidad del servicio. Finalmente, se analizar´anlos resultados obtenidos.

En resumen, los objetivos son implementar el sistema de monitoreo mencionado y obtener resultados a trav´esde su utilizaci´on.

1.3. Composici´ondel trabajo presentado

El trabajo desarrollado se presenta de la siguiente forma:

En el cap´ıtulo1 se presenta el problema y los objetivos buscados.

En el cap´ıtulo2 se realiza una introducci´ona la tem´aticaabordada.

En el cap´ıtulo3 se presenta el hardware utilizado.

El cap´ıtulo4 contiene el estudio de los diversos estados del arte mencionados anterior- mente (en hardware de routers inal´ambricos, en firmware de c´odigoabierto y en lenguajes Cap´ıtulo1. Introducci´on 3

de programaci´onpara sistemas embebidos), adem´asdel an´alisisde arquitecturas de mo- nitorizaci´on.

En el cap´ıtulo5 se presenta el estudio y la selecci´onde los indicadores a utilizar para medir la calidad de la se˜nal,los diferentes sistemas de monitorizaci´onexistentes y una plataforma en concreto, propietaria, que coincide en algunos aspectos con lo buscado en este proyecto.

El cap´ıtulo6 presenta el desarrollo realizado sobre la infraestructura.

En el cap´ıtulo7 se muestran los resultados obtenidos.

Finalmente, en el cap´ıtulo8 se presentan las conclusiones y el trabajo a futuro. Cap´ıtulo2

Antecedentes

El presente cap´ıtuloest´abasado en el libro “Redes de Computadores: Un Enfoque Descendente” [1], en los documentos sobre redes inal´ambricas [2], [3], [4] y [5], en la presentaci´on“Wireless Security” [6] y en el art´ıculo“Propagation Measurements and Models for Wireless Communi- cations Channel” [7].

2.1. Redes inal´ambricas

Una red inal´ambrica es un conjunto de hosts, enlaces y estaciones base, mediante la cual los hosts consiguen comunicarse entre s´ıy con otras redes a las que las estaciones base tengan acceso. En una red inal´ambrica tipo es posible identificar ciertos elementos:

Hosts inal´ambricos: los hosts son dispositivos que act´uancomo sistemas terminales. Pue- den ser m´ovileso no, pero su conexi´oncon el resto de la red se realiza a trav´esdel medio inal´ambrico. Una notebook, un celular o una computadora de escritorio son posibles ejem- plos.

Enlaces inal´ambricos: un host se conecta a la estaci´onbase o a otro host por medio de un enlace de comunicaciones inal´ambrico. Dependiendo de qu´etecnolog´ıa se use para este enlace, se tendr´acierta velocidad y distancia m´axima entre equipos. Tambi´enlas estaciones base u otros dispositivos de la red pueden conectarse entre s´ıpor medio de enlaces inal´ambricos.

Estaci´onbase: es una parte clave de la red inal´ambrica. Es responsable de enviar y recibir datos desde y hacia un host inal´ambrico que est´easociado con ella. Generalmente se encar- ga de coordinar la transmisi´onde los m´ultipleshosts inal´ambricos que tenga asociados. El estar asociado quiere decir que ese host se encuentra dentro del alcance de la estaci´onbase

4 Cap´ıtulo2. Antecedentes 5

Figura 2.1: Escenario t´ıpicode una red inal´ambrica.

y utiliza la estaci´onbase para re-enviar datos desde y hacia otra red u otro dispositivo. Particularmente en las redes LAN inal´ambricas a las estaciones base se las conoce como puntos de accesos, AP, del ingl´es “Access Point”.

Dichos elementos formando un escenario t´ıpicode una red inal´ambrica se pueden apreciar en la figura 2.1.

Una estaci´onbase suele encontrarse conectada a otra red de mayor tama˜no(generalmente Internet) y provee a la red inal´ambrica la comunicaci´oncon esa otra red, permitiendo que los hosts inal´ambricos asociados puedan enviar y recibir datos desde y hacia esa red.

Los hosts asociados a una estaci´onbase operan en modo de infraestructura. Lo cual implica que todos los servicios de red com´unmente usados (asignaciones de direcciones y enrutamiento, entre otros) son proporcionados por la propia red con la que el host se conecta por medio de la estaci´onbase. Esto se diferencia de las redes Ad Hoc, donde no existe infraestructura a la cual conectarse y los propios hosts deben realizar todas las funciones que generalmente brinda la red.

Cuando un host se mueve fuera del alcance de la estaci´onbase con la que estaba asociado y entra dentro del ´areade cobertura de otra estaci´onbase, cambia su estaci´onasociada a la nueva. Esto se conoce con el nombre de handoff (transferencia).

De los diferentes elementos mencionados anteriormente se puede definir una clasificaci´onde los diferentes tipos de redes seg´undos par´ametros,si un paquete dentro de la red realiza un Cap´ıtulo2. Antecedentes 6

Con infraestructura Sin infraestructura

Un ´unicosalto Se tiene (al menos) una esta- No existe una estaci´onbase ci´onbase conectada a una red conectada a la red, pero los cableada de mayor tama˜no, nodos pueden alcanzar sus ob- por donde pasa toda la comu- jetivos de un solo salto. Por nicaci´on. Por ejemplo: redes ejemplo: redes Bluetooth y re- 802.11, redes celulares y Wi- des 802.11 en modo ad hoc. MAx. M´ultiplessaltos Existe una estaci´onbase que No existe una estaci´onbase se conecta con la red de ma- y los nodos pueden tener que yor tama˜no, pero algunos no- retransmitir a trav´esde otros dos inal´ambricos pueden tener nodos para alcanzar su objeti- que retransmitir a trav´esde vo. Por ejemplo: redes m´oviles otros para llegar a la estaci´on ad hoc o redes vehiculares ad base. Por ejemplo: algunas re- hoc. des de sensores inal´ambricos y las redes de malla inal´ambri- cas.

Tabla 2.1: Clasificaci´onde los tipos de redes.

´unicosalto o m´ultiplessaltos inal´ambricos y si existe una infraestructura dentro de la red. Esta clasificaci´onse puede apreciar en la tabla 2.1.

Como se puede ver, existen numerosos tipos de redes inal´ambricas. En este proyecto nos enfoca- remos en las redes LAN inal´ambricas, del est´andar802.11, conocidas com´unmente como redes Wi-Fi.

2.2. Familia 802.11

Dentro del est´andar 802.11 existen diversos tipos de especificaciones con diferentes usos. Las que definen tipos de redes LAN inal´ambricas son cuatro: 802.11a, 802.11b, 802.11g y 802.11n.

En la tabla 2.2 se puede ver las caracter´ısticasde las mismas.

La frecuencia de 5 GHz es menos usada, por lo que posiblemente posea menos interferencia que la 2.4 GHz, pero tiene menos alcance.

Como se puede ver en la tabla, los est´andaresmencionados presentan algunas diferencias entre s´ı,pero tambi´enposeen caracter´ısticascomunes en cuanto a su funcionamiento, la estructura de trama para la capa de enlace [8], la capacidad de reducir la velocidad de transmisi´onpara incrementar la distancia y los diferentes modos en los que pueden trabajar, entre otros. En la secci´onsiguiente se detallar´anestos tipos de redes. Cap´ıtulo2. Antecedentes 7

802.11a 802.11b 802.11g 802.11n

A˜node lanzamiento 1999 1999 2003 2009 Frecuencia (GHz) 5 2.4 2.4 2.4 y 5 Area´ de cobertura Buen ´area Buen ´area Buen ´area ´ Area de co- de cobertu- de cobertu- de cobertu- bertura re- ra ra ra ducida Cantidad de canales 8 3 3 - que no se solapan M´axima velocidad 54 11 54 +100 de transferencia por antena (Mbps) Rendimiento real La mejor Buena Mejor que La mejor (basado en el ambiente buena y los usuarios) Compatibilidad 802.11a 802.11b 802.11b/g 802.11b/g/n Penetrabilidad (en Buena Mejor que Mejor que - objetos s´olidos) buena buena

Tabla 2.2: Caracter´ısiticasest´andares 802.11 a/b/g/n.

2.3. Funcionamiento de una red LAN inal´ambrica 802.11

Habiendo visto los diferentes est´andarespara la familia 802.11, se ver´ac´omoes el funcionamiento de este tipo de redes. El conjunto de servicio b´asico,BSS (Basic Service Set) es un componente de arquitectura fundamental en una red de este tipo. Contiene uno o m´ashosts inal´ambricos y una estaci´onbase central llamada AP (como se mencion´oanteriormente). En la figura 2.2 puede verse un escenario t´ıpicode una arquitectura LAN inal´ambrica 802.11.

Los APs se conectan generalmente a un switch o un router, el cual los conecta con Internet. En un hogar, t´ıpicamente se cuenta con un AP y un router, generalmente integrados en un mismo dispositivo que conecta el BSS con Internet. En cambio, la red utilizada en este proyecto estar´aformada por diferentes APs con su BSS, interconectados entre s´ıy/o con Internet por medio de switches o routers, conformando una red inal´ambrica densa.

Como sucede en las redes cableadas, cada host, AP y router tendr´anuna direcci´onMAC por cada tarjeta de red que posean, la cual en teor´ıaes ´unica.Esta direcci´onMAC es muy importante para que exista comunicaci´onen la red, como se ver´amas adelante.

Para que un host pueda enviar o recibir datos de la red, debe primero asociarse con un AP. Asociarse implica crear una conexi´onentre el host y el AP, de forma tal, que solamente el AP sea quien env´ıedatos al host y el host solamente env´ıedatos al AP. Los APs poseen un Identificador Cap´ıtulo2. Antecedentes 8

Figura 2.2: Arquitectura de una red IEEE 802.11.

Figura 2.3: Solapamiento de los 11 canales. de conjunto de servicio, SSID (Service Set Identifier) y un n´umerode canal. El primero es la forma en que los hosts van a reconocer a ese AP, es decir, el nombre con el que ser´aasociado, mientras que la segunda es el canal por el cual transmitir´ay recibir´adatos. En el cap´ıtulo5 se explica en mayor nivel de detalle el uso de los canales. En nuestro pa´ısse utilizan 11 canales parcialmente solapados en frecuencia de 2.4GHz, como se puede ver en la figura 2.3. Tambi´ense aprecia que en dichas condiciones existen hasta 3 canales que no se solapan entre s´ı, el conjunto formado por los canales 1, 6 y 11. Es importante destacar que el solapamiento implica que se genere ruido en los canales solapados, lo que provoca un deterioro en la calidad de la se˜nal.

2.3.1. Asociaci´onde los clientes con los APs

Los APs env´ıanperi´odicamente tramas baliza (beacon frames) hacia la red, las cuales contienen su direcci´onMAC y su identificador SSID. Como los hosts esperan que los APs env´ıenestas tramas, exploran todos los canales en busca de las mismas, generando as´ıun listado para que el Cap´ıtulo2. Antecedentes 9 usuario o el propio host decida con cual AP asociarse. Esta exploraci´onque realizan los hosts se denomina exploraci´onpasiva.

Adem´asde este tipo de exploraci´onexiste otro denominado exploraci´onactiva, en el cual los hosts difunden un paquete de sondeo que ser´arecibido por los diferentes APs a los que llegue la se˜nal.A continuaci´on,los APs env´ıan un paquete de respuesta, de esta forma el host puede identificarlos y elegir con cu´alasociarse.

Cabe aclarar que el est´andarno especifica la forma de seleccionar un AP para asociarse, sino que la selecci´onqueda a cargo del dise˜nadorde software o del firmware del equipo. De todas formas, lo mas frecuente es que el host seleccione el AP cuya trama baliza se reciba con mayor intensidad de se˜nal.Es importante destacar que esta elecci´onno tiene por qu´eser la mejor, ya que no solo es importante la intensidad que presente la se˜nal,sino que tambi´enes importante la cantidad de hosts que ya se encuentren asociados a dicho AP. Cuanto cuanto mayor sea el n´umerode hosts que est´eatendiendo, menos tiempo y recursos podr´adedicarle a cada uno.

Luego de que un host decide con cu´alAP asociarse le env´ıaun paquete de solicitud de asociaci´on al AP, el cual responde con un paquete de respuesta de asociaci´on,quedando as´ı asociado y pasando el host a formar parte de la subred a la que pertenece el AP. Esta asociaci´ones un poco m´ascompleja si el AP implementa un protocolo de seguridad, en cuyo caso el host deber´aautenticarse para poder asociarse con el mismo.

Generalmente, luego de la asociaci´on,el host buscar´aque se le asigne una IP, para lo cual enviar´aun mensaje de descubrimiento DHCP [9] hacia la subred a trav´esdel AP. DHCP es un protocolo mediante el cual se le asigna a un host una direcci´onIP libre perteneciente a la subred. Cuando el host obtiene una direcci´onIP, pasar´aa ser visible para el resto de la red y posiblemente el mundo (en caso de estar conectado a Internet).

2.3.2. Utilizaci´ondel canal por diferentes clientes

En una situaci´on“ideal” el host ser´ıael ´unicoequipo asociado al AP, pero esto no es as´ı,ya que generalmente existen diferentes hosts asociados, por lo que debe existir alguna forma de que los distintos emisores (hosts asociados y el AP) coordinen las transmisiones que realizan. Para esto existen diferentes formas de repartir el uso del canal: particionamiento del canal, acceso aleatorio y toma por turnos. En particular 802.11 utiliza y define un protocolo de acceso aleatorio, denominado CSMA/CA, acceso m´ultiplepor sondeo de portadora con evitaci´onde colisiones, por su sigla en ingl´es.Esto quiere decir que cada emisor sondea el canal antes de transmitir, y en caso de que detecte que el mismo est´aocupado no transmite, y en su lugar espera un tiempo aleatorio para volver a intentarlo. Si detecta que el canal no est´aen uso, entonces comienza a transmitir y no se detiene hasta haber finalizado. Cap´ıtulo2. Antecedentes 10

Este protocolo emplea un reconocimiento (ACK) de la capa de enlace, mediante el cual un emisor recibe una notificaci´onde que su paquete ha llegado a destino. Esto es importante, ya que, como se ver´am´asadelante, los paquetes no siempre logran llegar intactos a su destino. Este reconocimiento funciona de la siguiente manera: cuando el destinatario recibe un paquete, comprueba su estado mediante la comprobaci´onCRC [10], espera un per´ıodo de tiempo llama- do “espacio corto entre tramas” (SIFS por sus siglas en ingl´es)y luego env´ıaun paquete de reconocimiento a quien envi´oel paquete anterior. Si este no recibe la trama de reconocimiento dentro de un per´ıodo de tiempo determinado, supone que no ha llegado correctamente y vuelve a enviarlo (siempre utilizando CSMA/CA para acceder al canal). Si alcanza cierto n´umerode retransmisiones sin recibir el reconocimiento, descarta el paquete.

Es importante destacar que el sondeo de uso del canal solamente tiene lugar cuando se comienza una transmisi´on.Por lo tanto, si dos emisores comienzan a transmitir simult´aneamente, ninguno sabr´aque el canal se encuentra en uso y ambos transmitir´antodo el paquete que pretend´ıan enviar, lo cual puede generar una importante degradaci´ondel servicio, sobre todo ante paquetes largos. Por lo tanto, el protocolo presenta una forma de intentar evitar esta problem´aticay as´ıreducir las colisiones, la cual se puede ver en el funcionamiento del mismo.

2.3.3. Detectando el estado del medio

Cuando una estaci´on(ya sea un host o un AP) debe transmitir, primero comprueba que el canal (o medio) est´einactivo. Esta comprobaci´onse realiza de forma f´ısicay virtual. Se denomina CCA, Clear Channel Assessment, al mecanismo para determinar si el medio est´ainactivo. Posee dos componentes: detecci´onde portador (CS, Carrier Sense) y detecci´onde energ´ıa.La primera de ellas a su vez est´acompuesta por una CS f´ısicay una CS virtual. La f´ısicaes una medici´on directa de la intensidad de la se˜nalrecibida correspondiente al protocolo 802.11. Si se encuentra por encima de cierto nivel (82 dBm) el medio se considera ocupado. Mientras tanto, la virtual refiere al NAV (Network Allocation Vector), que funciona como un indicador de cu´andoel canal estar´ainactivo. El NAV se actualiza cada vez que se recibe un paquete 802.11 v´alidoque no tiene como objetivo la propia estaci´on,de forma que una estaci´onpuede evitar transmitir a´un cuando la CS f´ısicadetecte inactividad. La segunda, detecci´onde energ´ıa,revisa si el medio se encuentra ocupado, midiendo el total de energ´ıarecibida sin importar de d´ondeprovenga. Si el mismo supera cierto nivel (62 dBm), entonces se considera que el medio est´aocupado.

La comprobaci´onde inactividad del canal mencionada es realizada durante un per´ıodo de tiempo denominado DIFS, espacio distribuido entre tramas por sus siglas en ingl´es,para el caso en que no hayan existido errores de env´ıoen la transmisi´onanterior, o uno llamado EIFS, espacio de error entre tramas, en caso de que haya ocurrido un error en una transmisi´on.En caso de que el medio se detecte inactivo durante el tiempo adecuado, se transmite el paquete completamente. Cap´ıtulo2. Antecedentes 11

Figura 2.4: Terminal oculto por desvanecimiento de se˜nal.

Si no fuese as´ı,se selecciona un valor de espera aleatorio llamado backoff, que representa el tiempo que la estaci´ondebe detectar al canal inactivo para poder transmitir. Este backoff se elige dentro de un rango posible, el cual crece al doble cada vez que se realiza una transmisi´on err´oneay retorna a su m´ınimo cuando se realiza una transmisi´onsatisfactoria. Mientras se detecte que el canal se encuentra inactivo durante un cierto per´ıodo de tiempo, denominado “slot time”, se decrementa el valor del backoff. Una vez que el backoff alcance el valor 0, la estaci´ontransmite la trama completa y espera a recibir un reconocimiento. En caso de recibirlo considera que se ha transmitido correctamente y vuelve a ejecutar el algoritmo para el siguiente paquete que posea. En caso de no recibir reconocimiento, el emisor vuelve a entrar en la fase de backoff para retransmitir el paquete.

Cabe aclarar que se espera que el backoff elegido por diferentes emisores sea distinto, lo cual ayuda a evitar las colisiones.

2.3.4. Problema del terminal oculto

De todas formas, existen ciertos problemas que este algoritmo no soluciona, como el problema del terminal oculto a causa del desvanecimiento de la se˜nal.Esto ocurre cuando existen al menos 3 estaciones, dos de las cuales quieren transmitir hacia la tercera, pero est´anubicadas de forma tal que no se encuentran dentro del alcance de la otra, por lo tanto no logran detectar lo que la otra emite. Este escenario se puede apreciar en la figura 2.4.

Otro problema que no contempla el algoritmo es el del terminal oculto a causa de un obst´aculo, en el cual tanto A como C estar´ıandentro del radio de acci´ondel otro, pero la existencia de un obst´aculoentre ellos hace que detecten sus transmisiones, como se puede apreciar en la figura 2.5.

Por lo tanto, cuando A y C intenten transmitir hacia B, ambos ver´anel canal libre, por m´as que uno de los dos ya se encuentre transmitiendo, dado que la se˜nalque env´ıacada uno de ellos no alcanza al otro. En cambio, B recibir´asimult´aneamente ambas transmisiones, y por lo tanto se provocar´auna colisi´on,lo que har´ıaque el canal sea desperdiciado durante todo el tiempo de Cap´ıtulo2. Antecedentes 12

Figura 2.5: Terminal oculto por obst´aculo. transmisi´ondel paquete m´aslargo de los dos. Para solucionar este problema, el est´andarpresenta un esquema de reserva (el cual no es obligatorio implementar ni usar). Este esquema permite a las estaciones utilizar dos paquetes de tama˜nopeque˜nodenominados Solicitud de transmisi´on (RTS, por sus siglas en ingl´es)y Preparado para enviar (CTS, por sus siglas en ingl´es)para reservar el uso del canal. Cuando un emisor pretende comenzar a transmitir, primero env´ıaun RTS al AP, indicando el tiempo necesario para completar la totalidad de la transferencia que desea realizar y para recibir el ACK. Cuando el AP recibe el RTS, responde difundiendo a toda la red un CTS, el cual tiene un doble prop´osito:le informa al emisor que puede transmitir y le avisa al resto de estaciones que no pueden transmitir durante el per´ıodo de tiempo indicado. Este esquema se puede apreciar en la figura 2.6.

De esta forma se mitigar´ıael problema de la terminal oculta. Podr´ıadarse que existan colisio- nes cuando se env´ıanRTS o CTS, pero dado que estos paquetes poseen un tama˜noreducido, la colisi´onno es tan relevante. Como contrapartida, este m´etodo introduce retardos y consume re- cursos del canal, por lo tanto, si se utiliza, se reserva para paquetes de tama˜noconsiderablemente grandes.

2.4. La trama IEEE 802.11

Una trama es la forma de nombrar a un paquete a nivel de capa de enlace. Es una agrupaci´on de bits organizada de una forma espec´ıfica.La trama 802.11 posee similitudes con la trama Cap´ıtulo2. Antecedentes 13

Figura 2.6: Evitaci´onde colisiones usando RTS y CTS.

Ethernet IEEE 802.3 [11], pero a su vez posee ciertos campos que son particulares para el ´ambito inal´ambrico.

A continuaci´onse presentan los diferentes campos, y en la imagen 2.7 puede apreciarse la composici´onde la misma.

Control de trama: este campo incluye varios sub-campos, los cuales se listan a continuaci´on:

Versi´onprotocolo: indica la versi´onusada del protocolo 802.11.

Tipo y subtipo: determinan la funci´onde la trama. Existen 3 tipos diferentes: control, datos y administraci´on.Para cada uno existen numerosos sub-tipos seg´unla operaci´on que se est´erealizando. Cap´ıtulo2. Antecedentes 14

Figura 2.7: Trama 802.11.

Hacia AP y desde AP: definen los significados de las direcciones. Son diferentes para modo ad hoc e infraestructura, y adem´as,para ´este´ultimotambi´encambian dependiendo de si el emisor de la trama es un AP o un host.

M´asfragmentos: indica si existen m´asfragmentos de la trama.

Reintentar: indica si la trama est´asiendo retransmitida.

Gesti´onde potencia: indica cuando la estaci´onemisora est´aen modo activa o en ahorro de energ´ıa.

M´asdatos: indica a un host en modo ahorro de energ´ıaque un AP tiene m´aspaquetes para enviar. Tiene algunos otros usos particulares.

WEP: indica si se est´ausando autenticaci´ony cifrado.

Orden: indica si las tramas recibidas deben ser procesadas en orden.

Campo duraci´on:es utilizado para definir por cu´anto tiempo se pretende reservar el medio. Como se vi´oanteriormente, esto refiere al uso de RTS y CTS.

Campos de direcci´on:la trama posee cuatro campos de este tipo, donde cada uno puede contener una direcci´onMAC de 6 bytes. Las primeras tres de estas direcciones son necesarias para la comunicaci´onen la red. En particular, para mover el paquete desde una estaci´oninal´ambrica hasta una interfaz de router a trav´esde un AP. La primera direcci´oncontiene la MAC de la estaci´oninal´ambrica que tiene que recibir la trama, la segunda direcci´oncontiene la MAC de la estaci´onque transmite la trama, la tercera es un tanto especial, ya que contiene la direcci´on MAC de la interfaz del router a trav´esde la cual el BSS se conecta con otras sub redes. El cuarto campo de direcci´ones usado solamente cuando los APs se re-env´ıantramas entre s´ıen modo ad hoc.

Campo n´umerode secuencia: es utilizado para identificar una trama y poder distinguir tramas entre s´ı. Cap´ıtulo2. Antecedentes 15

Carga ´utily CRC: la carga ´utilgeneralmente estar´acompuesta por un paquete IP o ARP. La longitud m´aximadel campo es de 2312 bytes, pero generalmente no posee m´asde 1500 bytes. Luego de la carga ´utilse incluye el CRC (c´odigode redundancia c´ıclica)de 32 bits, usado por el receptor para detectar errores en la trama recibida.

2.5. Problemas de calidad de la se˜nalen las redes inal´ambricas

Existen 3 factores principales que afectan la calidad de la se˜nalen las redes inal´ambricas:

Intensidad decreciente de la se˜nal:mientras la se˜nalse propaga va perdiendo intensidad, atenu´andosea medida que atraviesa diferentes objetos, incluido el aire. A esta p´erdidase le denomina p´erdidade propagaci´on(path loss). Por lo tanto, cuanto m´asdistanciados se encuentren el emisor y el receptor, y cuanto m´asobjetos existan entre ellos, mayor ser´ala p´erdida.

Interferencia de otros or´ıgenes:los diferentes equipos que transmiten en una misma fre- cuencia generan interferencia entre s´ı, ya sean del mismo tipo (como m´asde una red inal´ambrica en el mismo canal o en canales solapados) o de otros tipos que no tengan que ver con redes inal´ambricas (como un tel´efonoinal´ambrico transmitiendo en la frecuencia de 2.4 GHz con un AP transmitiendo en la misma frecuencia). Adem´asde la interferen- cia entre equipos que son transmisores, existe tambi´eninterferencia causada por ruido electromagn´etico,como el que produce un motor o un microondas.

Propagaci´onmulticamino: este tipo de p´erdidade se˜nalsucede cuando partes de la onda electromagn´eticatoman caminos de diferentes longitudes entre el emisor y el receptor. Esto puede deberse a que la onda se refleja en los objetos existentes y el suelo, por lo que la se˜nalrecibida en el receptor ser´amenos limpia. Incluso si existen objetos que se est´an desplazando que se ubiquen entre el emisor y el receptor, la propagaci´onmulticamino variar´aa lo largo del tiempo.

La p´erdidade se˜nalque provocan estos factores puede comprobarse y medirse de diferentes formas, las cuales ser´anexploradas en el cap´ıtulo5. Cap´ıtulo3

Hardware

3.1. Hardware utilizado

Este cap´ıtulo est´abasado en los sitios de Routerboard [12], [13], [14], “Linux Wireless” [15], [16], [17], TP-Link [18], [19], los manuales Routerboard 133 [20], Routerboard R52 [21], [22] y TP-Link [23] y el cat´alogode Routerboard [24].

El hardware utilizado al comienzo de este proyecto estuvo compuesto por placas Routerboard 133 y tarjetas inal´ambricas Routerboard R52.

Routerboard nace en el 2002, de la mano de la empresa MikroTik, como una gama de productos de hardware de routers. MikroTik fue fundada en 1995 enfocada al desarrollo de sistemas de routers y routers inal´ambricos. Esta empresa apunta a un mercado que va desde el hogar hasta grandes corporaciones.

Se hab´ıaelegido este hardware porque se encontraba disponible en el grupo de investigaci´on “MINA” y ofrece una gran posibilidad de personalizaci´on.

Como se explicar´am´asadelante, avanzado el proyecto se discontinu´oel uso de este hardware y se opt´opor utilizar TP-Link TL-WDR4300 en su lugar.

3.2. Routerboard 133

En las figuras 3.1y 3.2 se presentan la placa utilizada y un diagrama de la misma.

16 Cap´ıtulo3. Hardware 17

Figura 3.1: RouterBoard 133 vista superior e inferior.

Las caracter´ısticasprincipales de este dispositivo se presentan en la tabla 3.1.

Figura 3.2: RouterBoard 133 diagrama. Cap´ıtulo3. Hardware 18

Procesador Procesador embebido MIPS32 4Kc 175MHz (little-endian), incluye TLB (Translation Lookaside Buffer) y no posee uni- dad de punto flotante (est´aoptimizada para trabajar con enteros) Memoria 32MB SDRAM onboard Boot Loader RouterBOOT, 1Mbit Flash chip Almacenamiento 64 MB onboard NAND no vol´atil Ethernet 3 puertos 10/100 Mbit/s Fast Ethernet Slot MiniPCI 3 slots MiniPCI tipo IIIA/IIIB Puerto serial Un puerto serial DB9 RS232C asincr´onico LEDs LED de encendido (indica cuando la placa est´aprendida) y de uso para el desarrollador (se enciende al iniciar y se apaga al levantar el kernel) Parlante Mini PC-Speaker Energ´ıa POE (Power over ethernet) 16 a 28V DC solamente en el puerto LAN1. Power jack: 9 a 28V DC Consumo de 3-4W sin tarjetas conectadas, m´aximo10W energ´ıa Dimensiones y 11.7 cm x 10.5 cm (4.61 in x 4.13 in). 115 gramos peso Temperatura y -20◦C a +65◦C, hasta 70 % de humedad relativa humedad Arquitectura Completamente compatible con el est´andarde arquitectura MIPS32 con bus PCI

Tabla 3.1: Caracter´ısiticasdel RouterBoard 133.

3.3. Routerboard R52

La tarjeta R52 es una tarjeta miniPCI de doble banda. En la tabla 3.2 se presentan sus princi- pales caracter´ısticas,y en la figura 3.3 se puede ver una imagen de la misma. Cap´ıtulo3. Hardware 19

Chipset Atheros AR 5414 Est´andares 802.11 a/b/g Acceso al me- CSMA/CA con ACK dio Seguridad 64/128 bit WEP, Cifrado TKIP y AES-CCM, Autenticaci´on WPA, WPA2, 802.1x Conectores Dos conectores U.fl Certificaciones FCC, EC Energ´ıa 3.3V +/- 10 % DC Temperatura -20◦C a +70◦C, hasta 90 % y humedad soportada Dimensiones y 6.0cm x 4.5cm, 20 gramos peso Potencia y 17dBm / -88dBm - 6Mbps sensibilidad en 13dBm / -71dBm - 54Mbps 802.11 a Potencia y 19dBm / -95dBm - 1Mbps sensibilidad en 19dBm / -90dBm - 11Mbps 802.11 b Potencia y 18dBm / -90dBm - 6Mbps sensibilidad en 15dBm / -73dBm - 54Mbps 802.11 g Velocidades de 802.11b:11,5.5,2,1 Mbps, auto-fallback transferencia 802.11g:54,48,36,24,18,12,9,6 Mbps, auto-fallback 802.11a:54,48,36,24,18,12,9,6 Mbps, auto-fallback En modo turbo: 802.11g:108,96,72,48,36,24,18,12 Mbps, auto-fallback 802.11a:108,96,72,48,36,24,18,12 Mbps, auto-fallback

Tabla 3.2: Caracter´ısiticasdel RouterBoard R52.

Figura 3.3: RouterBoard R52. Cap´ıtulo3. Hardware 20

Driver AP IBSS Mesh MON

ath5k Si Si Si Si

Tabla 3.3: Modos soportado por la tarjeta RouterBoard R52

Se investig´oel chipset utilizado por la tarjeta para analizar los modos soportados por la misma. Dicho chipset es un Atheros AR5414, que a su vez utiliza el driver “ath5k”, por lo que se investig´olos modos soportados por este driver. Estos modos se pueden apreciar en la tabla 3.3.

El modo AP es el modo m´ascom´unen los routers (el cual ha sido descrito en la introducci´on).

El modo MON (monitor) es un modo pasivo, en el que el equipo (generalmente) no transmite datos, pero en cambio obtiene todos los paquetes de la red sin importar su objetivo, sin aplicar ning´unfiltro. Es el modo com´unmente utilizado cuando se pretende analizar el tr´aficode una red.

IBSS (Independent Basic Service Set), conocido tambi´encomo modo Ad-Hoc, es usado para crear una red inal´ambrica sin la necesidad de disponer de un AP en la misma. Es el modo punto a punto.

El modo Mesh, es usado para permitir a m´ultiplesdispositivos comunicarse entre s´ıestableciendo rutas din´amicasentre ellos de modo inteligentes.

3.4. OpenWRT

Sobre el hardware mencionado se instal´oel sistema OpenWRT, cuyo an´alisisse encuentra en el cap´ıtulo3, en la secci´onde estado del arte de firmware de routers.

El trabajo realizado sobre la placa RouterBoard 133 para efectuar la instalaci´onde OpenWRT se detalla en el cap´ıtulo6.

3.5. TP-LINK

Como se detallar´aen el cap´ıtulo5, se utiliz´otambi´enun router TP-Link TL-WDR4300. Su ca- racter´ısticam´asdestacable, que lo hace relevante para este trabajo, es el soporte para OpenWRT en versiones m´asrecientes, espec´ıficamente la versi´onutilizada es 12.09 “Attitude Adjustment”. Cap´ıtulo3. Hardware 21

Chipset Atheros AR 9344 y Atheros AR 9580 Est´andares 802.11 a/b/g/n Antenas 3 antenas de banda dual 2.4GHz y 5GHz Seguridad Encriptaci´onWEP,WPA / WPA2,WPA-PSK/ WPA2-PSK de 64/128-bit Energ´ıa 12 VDC / 1.5A Dimensiones 24.3 cm x 16.06 cm x 3.25 cm Tasas de trans- 5GHz hasta 450 Mbps ferencia 2.4GHz hasta 300 Mbps

Tabla 3.4: Caracter´ısiticasdel TP-Link TL-WDR4300.

Figura 3.4: TP-Link TL-WDR4300.

El resto de las caracter´ısticasdel router, a pesar de ser interesantes, no son relevantes para el desarrollo de este proyecto, por lo que no fueron utilizadas. Cap´ıtulo4

Estado del arte

4.1. Estado del arte en hardware de routers inal´ambricos

Esta secci´onest´abasada en el libro “Redes de Computadores: Un Enfoque Descendente” [1] y en los sitios [25], [26] y [27]. La subsecci´onde cada fabricante y la comparaci´onentre ellos se basa en: Qualcomm [28], [29] y [30], Intel, [31], [32] y [33], y Broadcom [34], [35] y [36].

4.1.1. Router Inal´ambrico

Un router es un dispositivo de interconexi´onpresente en una red, que cuenta con varios enlaces y toma los paquetes que llegan por cualquiera de ellos, reenvi´andolospor el enlace adecuado, de forma de hacer llegar el paquete al destino deseado. Para ello, el dispositivo posee capacidad de almacenamiento y de decisi´onpara saber hacia d´ondedebe enviar el paquete. Este re-env´ıo lo realiza utilizando direcciones de capa 3, capa de red [8]. La capa de red tiene como objetivo lograr que los datos lleguen desde un origen a un destino a´uncuando ambos no se encuentren conectados directamente. En este nivel se realiza el direccionamiento y re-env´ıohasta su destino.

Un punto de acceso inal´ambrico es un dispositivo que integra una red inal´ambrica, al cual los usuarios inal´ambricos de dicha red transmiten paquetes (y reciben) de forma inal´ambrica, utilizando ondas de radio, que generalmente est´aconectado al resto de la red de forma cableada.

Dadas estas dos definiciones, se define un router inal´ambrico como un dispositivo que realiza tanto las funciones de un router como de un punto de acceso inal´ambrico.

Cuando una red posee al menos un router inal´ambrico, se dice que es una “red de infraestruc- tura inal´ambrica”. Los dispositivos inal´ambricos que deseen conectarse a la red (notebooks, celulares, impresoras, etc.) lo har´ana trav´esdel router inal´ambrico, que permite que los dis- positivos conectados interact´uenentre s´ıy con el resto de los dispositivos que sean alcanzables 22 Cap´ıtulo4 Estado del arte 23 desde la red (en el caso de un hogar con conexi´onde datos, ser´ıaa toda la internet). Como se mencion´oanteriormente, estos routers inal´ambricos pueden estar conectados al resto de la red por un cable Ethernet, y a su vez pueden permitir que otros dispositivos se conecten al router de forma cableada, por lo tanto una red de infraestructura inal´ambrica tambi´enpuede poseer conexiones por cable, tanto para dispositivos como para conectarse al resto de la red. Sin importar la forma en que los dispositivos se conecten al router, todos tendr´anacceso a la misma red (o redes) y podr´ancomunicarse entre s´ı(siempre que as´ıse permita).

4.1.2. Funcionamiento de un router inal´ambrico

Como se explic´oen el punto anterior, los routers reenv´ıanla informaci´on(paquetes) que reciben tanto de los dispositivos conectados al mismo como del resto de la red. Cada vez que un router reenv´ıaun paquete verifica que el mismo se haya enviado correctamente. De la misma forma, cada vez que recibe un paquete env´ıauna verificaci´onde recibido al emisor del paquete, sin importar si la transmisi´ondel paquete es a trav´es de un cable o de forma inal´ambrica.

Para que el router pueda efectuar este reenv´ıode paquetes necesita saber hacia d´ondedebe enviar cada paquete, es decir, debe conocer el destinatario del mismo. La forma de identificar al destinatario es mediante la direcci´onIP. Esta direcci´ones asignada por el router a cada dispositivo conectado en el momento en que dicho dispositivo se conecta (pudiendo ser renovada por el router), asignaci´onpara la cual se usa el protocolo DHCP [9]. Cabe aclarar que las IP que tendr´anasignadas los dispositivos conectados al router son IPs de la red local y no de Internet (en el caso que el router posea conexi´ona Internet). Si el router posee conexi´ona Internet, el mismo tendr´aal menos una direcci´onIP ´unicaen Internet, asignada por su ISP [37] y otra local en la red que ´elmismo gestiona.

Cuando el router recibe un paquete que debe reenviar entre Internet y la red local, necesita realizar una conversi´onde direcciones. Para esto posee una tabla NAT [38].

Se ha realizado un estudio de las diferentes piezas de hardware en materia de tarjetas inal´ambri- cas existentes actualmente en el mercado. En las subsecciones siguientes, se presentan los resul- tados obtenidos.

4.1.3. Qualcomm Atheros

Qualcomm Atheros (anteriormente Atheros) es un desarrollador de semiconductores para redes y comunicaciones. Se especializa en chipsets inal´ambricos. Fue fundada en 1998 bajo el nombre de Atheros por expertos en procesamiento de se˜nalesde la Universidad de Stanford, la Universidad de California en Berkeley y la industria privada. Posteriormente, en 2011, fue comprada por Qualcomm pasando a llamarse Qualcomm Atheros. Esta empresa tiene un importante inter´es Cap´ıtulo4 Estado del arte 24 en el estudio, ya que los chipsets Atheros para el est´andarIEEE 802.11 son usados por unos 30 fabricantes de dispositivos inal´ambricos.

4.1.4. Intel

Intel es uno de los mayores fabricantes de circuitos integrados del mundo. Fundada en California el 18 de julio de 1968 como Integrated Electronics Corporation por Robert Noyce y Gordon Moore. A pesar de ser mayormente conocida por la creaci´onde procesadores (fundamentalmente de la serie x86), tambi´endesarrollan chipsets inal´ambricos.

4.1.5. Broadcom

Broadcom Corporation es uno de los principales fabricantes de circuitos integrados para comu- nicaciones de banda ancha inal´ambricas y cableadas a nivel mundial. Fue fundada en 1991 por Henry Samueli y Henry Nicholas. Sus principales clientes son grandes compa˜n´ıas,como Amazon, Dell y Cisco, entre otras, pero tambi´enposee un gran mercado en los hogares.

4.1.6. Comparativa

En las tablas 4.1, 4.2y 4.3 se puede observar una comparativa de las principales caracter´ısticas de los ´ultimos4 modelos lanzados por cada compa˜n´ıa(a Octubre del 2014).

Se apunt´oa relevar ciertas caracter´ısticasde cada uno: modelo, interfaz, MiMo, est´andaresque implementa, fecha de salida, rango de frecuencia, par´ametrosde monitorizaci´on, par´ametros accesibles por hardware y soporte de OpenWRT. Como no ha sido posible encontrar toda la informaci´onnecesaria para todos los modelos, la comparativa no se ha podido realizar com- pletamente. Entendemos que en algunas caracter´ısticasel problema se debe a que son datos reservados de cada fabricante o no son datos que se encuentren p´ublicamente. En particular, el soporte a OpenWRT no depende solo de esta pieza de hardware, sino que depende de todo el router en su conjunto, por lo que no es posible determinar qu´eversi´onde OpenWRT soporta cada tarjeta.

MiMo [39] refiere a “Multiple-input multiple-output”, m´ultiplesantenas usadas de forma si- mult´aneapara transmitir y m´ultiplesantenas utilizadas simult´aneamente para recibir. Se de- nota de la forma ExR, donde E es el n´umerode antenas usadas para emitir y R el n´umerode antenas usadas para recibir. Cap´ıtulo4 Estado del arte 25

QCA9862 QCA9880 QCA9890 QCA6174

Interfaz PCIe PCIe PCIe PCIe USB3 SDIO MiMo 2x2 3x3 3x3 2x2 Est´andares a/b/g/n/ac a/b/g/n/ac a/b/g/n/ac a/b/g/n/ac Fecha de salida 22/07/2013 15/07/2013 12/09/2013 05/06/2014

Tabla 4.1: Caracter´ısticasdiferentes hardware Qualcomm.

AC7260 N 7260 N 7260 Plus N 7260 Plus + BT

Interfaz PCIe PCIe PCIe PCIe MiMo 2x2 2x2 2x2 2x2 Est´andares a/b/g/n/ac a/b/g/n a/b/g/n b/g/n Fecha de salida 17/04/2013 17/04/2013 17/04/2013 17/04/2013

Tabla 4.2: Caracter´ısticasdiferentes hardware Intel.

BCM43162 BCM43602 BCM43241 BCM4339

Interfaz PCIe PCIe SDIO SDIO MiMo 1x1 3x3 2x2 1x1 Est´andares a/b/g/n/ac a/b/g/n/ac a/b/g/n a/b/g/n/ac Fecha de salida 13/02/2014 06/02/2014 05/04/2013 05/09/2013

Tabla 4.3: Caracter´ısticasdiferentes hardware Broadcom.

4.2. Estado del arte en firmware de c´odigoabierto

Esta secci´onse basa en los art´ıculos“Network performance evaluation based on three processes” [40], “Implementaci´onopenwrt del protocolo de comunicaciones w2lan” [41], “Plataforma m´ovil para aula virtual basada en wrt160nl-openwrtusb” [42] y “The openwrt embedded development framework” [43], y en el sitio [44].

Las diferentes secciones de cada firmware se basan en los sitios: Alchemy y Talisman [45], [46], [47] y [48], HyperWRT y Tomato [49], DD-WRT [50], [51], [52] y [53], OpenWRT [54], X-WRT [55], y Tarifa [56].

4.2.1. Introducci´on

Los firmwares libres tienen su origen en la empresa Linksys de Cisco (fabricante de hardware para redes dom´esticasy peque˜nasempresas), particularmente con el modelo WRT54G; ya que Cap´ıtulo4 Estado del arte 26 poco despu´esde su lanzamiento se descubri´oque su firmware se basaba en componentes del kernel de linux, y al regirse ´estepor la GNU GPL la empresa se vio obligada a liberar el c´odigo fuente del firmware. De esta manera, los desarrolladores pudieron aprender con exactitud c´omo comunicarse con el hardware, y as´ınacieron varios proyectos open source como Alchemy, DD- WRT, OpenWRT, X-WRT, HyperWRT, Tomato, etc; orientados no s´oloa arreglar los bugs de WRT54G y optimizar su rendimiento, sino tambi´ena extender sus funcionalidades.

Algunas de las funcionalidades agregadas que se pueden encontrar en estos firmwares son sopor- te para sistemas de distribuci´oninal´ambrica (WDS), puentes inal´ambricos (Wireless Bridge), repetidores (Repeaters), montar un servidor VPN o VoIP, controlar el uso del ancho de banda por protocolo, alterar los tama˜nosdel tr´afico,incrementar la potencia de la antena, acceder a los logs del router de forma remota, ejecutar aplicaciones linux, etc.

Existen firmwares que ofrecen a´unm´asfuncionalidades, mientras otros se centran en las funcio- nalidades espec´ıficasde los routers, y otros buscan proveer una interfaz de usuario m´asamigable; pero un gran atractivo que ofrecen todos, adem´asde las funcionalidades que traen de serie, es la posibilidad de desarrollar nuevas funcionalidades o ajustar las existentes seg´unla necesidad.

4.2.2. Alchemy y Talisman - SVEASOFT

Alchemy es el primer firmware de routers de la empresa Sveasoft (y uno de los primeros firmwares de routers desarrollados por terceros), basado en el c´odigofuente del WRT54G liberado por Linksys. En un principio ofrec´ıanel firmware con algunas funcionalidades nuevas y arreglos de bugs respecto a la versi´onde Linksys, pero luego comenzaron a cobrar una membres´ıa para tener acceso a su comunidad (que ofrec´ıalos binarios de los productos y soporte para los mismos), provocando una batalla con los defensores de la GPL. A partir de ese momento comienzan a circular versiones del firmware en las redes P2P y sitios web, a lo que la empresa Sveasoft comunica que dichas versiones son pirateadas y contienen backdoors, mientras que los responsables de hacer p´ublicoel firmware acusan recibir amenazas por parte del due˜node la empresa.

A ra´ızde esto la empresa discontinu´oel desarrollo de Alchemy, y comenz´oa ofrecer un nuevo firmware, Talisman, el cual agrega m´asde cien funcionalidades nuevas y arregla bugs encontrados com´unmente en las versiones de serie de los firmwares. Sin embargo, no se encontr´oinformaci´on sobre qu´efuncionalidades incorporan tanto Alchemy como Talisman, lo que se presume que se debe a la turbiedad de la historia de la empresa y el secretismo con el que se manej´opor fuera de su comunidad con respecto a sus productos.

Actualmente, la empresa parece haber desaparecido, ya que la ´ultimaactualizaci´onde su p´agina data del a˜no2010, y el ´ultimohilo en su foro (el ´unicocon menos de un a˜node antig¨uedad) Cap´ıtulo4 Estado del arte 27 consta de notificaciones de sus clientes de que los enlaces de descarga no funcionan, para las cuales no tuvieron respuesta.

4.2.3. HyperWRT y Tomato

Al igual que en el caso de Alchemy, HyperWRT se basa en el c´odigofuente del firmware de Lynksys, pero sus desarrolladores centraron su foco en optimizar dicho firmware, y no tanto en extender sus funcionalidades. Por esta raz´ones considerado el firmware desarrollado por terceros m´asrecomendado para principiantes, ya que su conjunto de funcionalidades se encuentra limitado a aquellas m´asb´asicasde los routers, siendo m´asf´acilconfigurarlo y adiminstrarlo que otros firmwares de su clase. Algunas de sus prioridades en cuanto a las funcionalidades a agregar eran incrementar la potencia de la antena, triggers de puertos, conexi´onpor telnet, y scripts de configuraci´on.

Sin embargo, esta versi´onse encuentra discontinuada desde el 2006. Su sucesor directo es Toma- to, en desarrollo desde el 2008 a la fecha, y soporta una variedad mucho m´asamplia de equipos. Entre sus funcionalidades se destacan una interfaz gr´aficamejorada, basada en AJAX y SVG, clasificaci´ondel tr´aficoen 10 tipos, almacenando y mostrando estad´ısticas,y permitiendo con- trolar el ancho de banda de los clientes a partir de estos datos, soporte para m´ultiplesmodos de red inal´ambrica, ajuste de potencia de transmisi´on,selecci´onde antenas y canales, y permite mostrar la intensidad de la se˜nalde los dispositivos inal´ambricos conectados.

4.2.4. DD-WRT

DD-WRT nace como alternativa gratuita a Alchemy, cuando sus desarrolladores deciden cobrar por el producto. Ofrece un conjunto de funcionalidades m´asamplio que HyperWRT/Toma- to, y existe una comunidad dedicada a extenderlo y actualizarlo; pero no es tan flexible como OpenWRT, ya que las modificaciones implican volver a compilar el firmware, por lo que se lo considera un firmware para usuarios de nivel medio para su uso y nivel avanzado para modi- ficarlo. Se basaba en el propio c´odigofuente de Alchemy, tomado del repositorio p´ublicode la ´ultimaversi´ongratuita, pero a partir de la versi´on23 comenz´oa basarse en OpenWRT. Al d´ıa de la fecha se encuentra vigente, y es mantenido por un desarrollador que se denomina Brain Slayer.

Contiene funcionalidades como WDS, controles avanzados de calidad de servicio para la asigna- ci´onde ancho de banda, control de potencia, etc., pero, si bien ofrece soporte para m´asde 200 dispositivos, no se encontr´oque soporte el Mikrotik RouterBoard 133 en su wiki ni en la base de datos de routers de su web. Cap´ıtulo4 Estado del arte 28

4.2.5. OpenWRT

Como en el caso de HyperWRT y Alchemy, OpenWRT nace como un firmware alternativo para el router WRT54G de Linksys, basado en su c´odigofuente, pero que r´apidamente comenz´oa soportar otros dispositivos, y a diferencia del resto de los proyectos, luego se comenz´oa desa- rrollar el producto desde cero, si bien se segu´ıautilizando el c´odigooriginal de Linksys como referencia.

Todos sus componentes fueron optimizados en cuanto a tama˜noy uso de recursos para poder ejecutar en hardware limitado, e incluso varias de sus funcionalidades han sido agregadas a la l´ıneabase del kernel de linux. Dispone de cerca de tres mil quinientos paquetes de instalaci´onde software mediante el manejador de paquetes opkg, y es el que permite mayor nivel de customi- zaci´on,por lo que se lo considera para usuarios con nivel de expertise medio a alto, aunque a la hora de extenderlo puede resultar m´asaccesible que otros de su tipo, ya que no necesariamente requiere compilar el firmware completo para agregar una funcionalidad.

Entre sus funcionalidades destacadas se encuentran el ajuste del tama˜nodel tr´aficopara mejorar la calidad del servicio, configuraci´onextensible de todos los drivers de hardware, un conjunto de scripts para unificar y simplificar la configuraci´ondel sistema, balanceo de carga, AQM (Active Queue Management) a trav´esdel scheduler de red del kernel de linux, monitorizaci´on y estad´ısticas de la red en tiempo real, extensibles a trav´esde herramientas como RRDtool, collectd, nagios, etc., y la implementaci´onde un file system con posibilidad de escritura. Esta ´ultimafuncionalidad sobresale frente a los otros firmwares del mismo tipo, ya que en caso de querer modificar los contenidos de su memoria no ser´anecesario flashear el dispositivo, y a su vez habilita el uso del manejador de paquetes para instalar nuevas herramientas.

Dadas sus caracter´ısticas,OpenWrt resulta la mejor opci´onpara construir una aplicaci´onsobre un router inal´ambrico sin tener que construir un firmware para ello.

4.2.6. X-WRT

El proyecto X-WRT es un conjunto de paquetes y parches para OpenWRT que ofrecen acceso a las herramientas de configuraci´ondel router mediante una interfaz gr´aficaweb, en lugar de la interfaz por consola que tra´ıaOpenWRT originalmente, o la interfaz web actual (LuCi) basada en el lenguaje de programaci´onLua.

4.2.7. Tarifa

Tarifa es un proyecto basado en la versi´onde serie del WRT54GL de Linksys, con un alcance menor en comparaci´oncon los anteriores, ya que se presenta como un reemplazo para el firmware Cap´ıtulo4 Estado del arte 29 de dicho router con mejoras de velocidad, alcance y arreglos de bugs. Permite aumentar el rango de la se˜nal,y agrega otras funcionalidades, como aumentar la cantidad de conexiones simult´aneas soportadas y mejoras de performance en el uso de la NAT-Firewall.

4.2.8. Elecci´ondel firmware

Se eligi´oOpenWRT como firmware a utilizar en el proyecto debido a las siguientes razones:

El gran apoyo que tiene de la comunidad, con una gran cantidad de paquetes de diferen- tes tipos de funcionalidades, informaci´ony gu´ıastanto para la instalaci´oncomo para el desarrollo sobre el mismo.

Posee file system, por lo cual no hay necesidad de trabajar sobre el firmware y re-compilarlo cuando se quieren agregar nuevas funcionalidades, sino que se pueden agregar paquetes directamente como en cualquier distribuci´onde Linux.

Es abierto y gratuito.

Es frecuentemente utilizado en el grupo de investigaci´on“MINA”, lo que simplifica la extensi´onfutura de la herramienta a realizar, y puede ser de ayuda en la elaboraci´onde la misma.

El hardware con el que se cuenta soporta OpenWRT.

4.3. Estado del arte en lenguajes de programaci´onpara sistemas embebidos

La presente secci´onse basa en los libros “Programming Embedded Systems” [57], “Embedded Systems Design” [58], “Programming Embedded Systems in C and C++” [59], “Embedded Sys- tems Specication and Design Languages” [60], en los art´ıculos“Design languages for embedded systems” [61] y “Models of computation and languages for embedded system design” [62], y en los sitios [63], [64], [65], [66] y [67].

4.3.1. Definici´onde sistema embebido

Un sistema embebido es un conjunto de hardware y software dise˜nadopara realizar una funci´on determinada. Este tipo de sistemas se encuentra presente continuamente en nuestras vidas. La mayor´ıade las veces son utilizados sin percatarnos de su existencia, sin saber que algo que se Cap´ıtulo4 Estado del arte 30 utiliza o algo que se realiza sucede gracias a que detr´asexiste un conjunto de piezas de hardware y software que lo hacen posible.

Por la propia definici´on,este tipo de sistemas se distingue de las computadoras (en el t´ermino com´unde la palabra), las cuales no est´andise˜nadaspara realizar una funci´onespec´ıfica,por lo cual es claro que la forma de dise˜narestos sistemas no es igual a la forma de dise˜naruna computadora.

Es com´unque estos sistemas formen parte de un sistema m´asgrande. Un ejemplo claro es un auto moderno, que posee diferentes sistemas embebidos (radio, control de frenos, etc.), pero tambi´eneste sistema mayor, al cual pueden pertenecer, podr´ıaser una computadora, en los cuales tanto un teclado, joystick o mouse son sistemas embebidos (poseen un procesador y un software para realizar ciertas funciones espec´ıficas).

En la mayor´ıade estos sistemas es muy importante el enlace con el mundo f´ısico.Es decir, que toman datos, censan, o interact´uan de alguna forma con el mundo f´ısicoque los rodea.

4.3.2. Evoluci´onde los sistemas embebidos

En 1971 Intel present´oel primer microprocesador de un solo chip (es decir, integrado f´ısicamente en una misma unidad [68]), el 4004, dise˜nadopara ser usado en calculadoras de la empresa Busicom. Intel cre´oeste chip de prop´ositogeneral en lugar de dise˜narun hardware espec´ıfico para cada tipo de calculadora, dise˜nadopara leer y ejecutar una serie de instrucciones, lo que ser´ıael software, guardadas en una unidad de memoria. A partir de ese momento se comenz´oa utilizar cada vez m´aseste tipo de microprocesadores.

En los 80 y 90 los microprocesadores comenzaron a estar presentes cada vez m´asen la vida cotidiana. Actualmente est´anpresentes en todos lados, en los hogares, empresas, centros de estudio, en la calle, etc. Cada a˜nose crean seis mil millones de nuevos microprocesadores, de los cuales menos del 2 % son usados en computadores de prop´ositogeneral. Por lo tanto, es clara la cantidad de sistemas embebidos que van surgiendo a˜notras a˜no.Adem´asde la cantidad que va en aumento, cada vez surgen m´astipos de sistemas embebidos, con nuevos objetivos, como sistemas de dom´otica,monitores m´edicos,etc.

4.3.3. Areas´ de aplicaci´ony ejemplos

Se presenta a continuaci´onun listado de diversas ´areasdonde existen sistemas embebidos y sus aplicaciones. Evidentemente el listado deja afuera muchos de estos sistemas, ya que dada la cantidad que existen ser´ıaimposible incluirlos a todos. Cap´ıtulo4 Estado del arte 31

Medios de transporte: en todos los veh´ıculosmodernos y no tan modernos se encuentra una gran cantidad de sistemas embebidos: control del airbag, control de encendido, ABS (sistema anti-bloqueo de ruedas), ESP (control de estabilidad), aire acondicionado, GPS, entre otros. En los aviones se encuentran en el sistema de control de vuelo, sistema anti- colisi´on,informaci´onal piloto, etc. En el resto de medios de transporte (con componentes el´ectricos)sucede lo mismo.

Telecomunicaciones: en esta ´areaes bien clara la cantidad de sistemas embebidos existen- tes. Por mencionar algunos: tel´efonos,contestadora y dispositivos manos libres.

Medicina: cada vez existen m´asproductos de cuidado de la salud que son sistemas em- bebidos, no solo de monitoreo, sino tambi´ende procesamiento informaci´ony cuidados, entre otros. Ejemplos muy conocidos de este tipo de dispositivos son los marcapasos o los puls´ometros.

Seguridad: por ejemplo control de acceso por huella, alarmas, cierres autom´aticos,etc.

Electr´onicade consumo: equipos de video, audio y entretenimiento.

Equipamiento de f´abricas:un ´areamuy amplia donde se usan todo tipo de sistemas embe- bidos, donde generalmente es prioritario que el sistema cumpla su funci´oncorrectamente frente al consumo de energ´ıa.

Casas inteligentes (dom´otica):usados para incrementar el confort y eficiencia de los ho- gares. Algunos de ellos pueden ser aire acondicionado, iluminaci´onautom´atica,tempori- zadores, etc.

Log´ıstica: como sem´aforos,RFID para control de mercanc´ıas, carga y descarga de las mismas.

Rob´otica:una de las ´areasm´astradicionales donde este tipos de sistemas ha sido usado.

Generaci´onde energ´ıa:las diferentes plantas de generaci´onde energ´ıa,sin importar de que tipo sean, utilizan sistemas embebidos para su funcionamiento.

Con este listado se quiere mostrar la cantidad y variedad existente de tipos de sistemas embe- bidos.

4.3.4. Caracter´ısticascomunes

De todos los ejemplos mencionados anteriormente es claro que gran parte de estos sistemas deben cumplir ciertas caracter´ısticaspara poder funcionar. Cap´ıtulo4 Estado del arte 32

Confiabilidad: hay que tener en cuenta que est´aninteractuando directamente con el ambiente y tienen un impacto sobre el mismos seg´unlas acciones que el sistema realice (un controlador de una planta nuclear no puede fallar). La confiabilidad abarca los siguientes aspectos:

Fiabilidad: la probabilidad de que un sistema no falle.

Mantenibilidad: la facilidad con la que un sistema puede ser reparado dentro de un deter- minado plazo.

Disponibilidad: la probabilidad de que el sistema est´edisponible cuando se desee usarlo.

Protecci´on(“Safety”): la propiedad de que el sistema no causar´ada˜noal ser usado.

Seguridad: la propiedad de que los datos confidenciales sigan siendo confidenciales y que la autenticaci´onest´egarantizada.

Eficiencia: no se puede desperdiciar nada. Para esta caracter´ısticase pueden usar las siguientes m´etricas:

Uso de energ´ıa:es generalmente un caracter´ısticamuy importante en este tipo de sistemas.

Eficiencia en tiempo de ejecuci´on:debe explotar todas las ventajas que el hardware pueda poseer.

Tama˜nodel c´odigo:el c´odigoque ejecutar´aun sistema generalmente debe estar guardado en el mismo, por lo que es importante que ocupe el menor espacio posible.

Trabajo en tiempo real: muchos de estos sistemas deben trabajar (y responder) en tiempo real. El no poder completar determinada acci´onen cierto tiempo muestra una baja calidad del sistema y puede provocar sucesos graves en el entorno con el que interact´ua,dependiendo de la funci´on del mismo.

4.3.5. Componentes de un sistema embebido

Existe un gran variedad de hardware para este tipo de sistemas, por lo cual un software embebido dise˜nadopara cierto sistema dif´ıcilmente funcione en otro sistema sin realizarle cambios. Esta variedad se debe a que se optimizan ampliamente las piezas de hardware utilizado para cada sistema, quitando lo innecesario buscando abaratar costos, y compartiendo todos los recursos de hardware posibles.

De todas formas, existen ciertos componentes que est´anpresentes en todos los sistemas em- bebidos, como son el procesador y el software. Adem´as,las instrucciones que componen este Cap´ıtulo4 Estado del arte 33

Figura 4.1: Sistema embebido gen´erico. software deben almacenarse f´ısicamente para poder ser le´ıdasy procesadas cada vez que se uti- liza el sistema. Existen diferentes tipos de memoria para este fin, de los cuales la mayor´ıade los sistemas utiliza los siguientes dos: la memoria ROM (read-only memory) y la RAM (random access memory).. Como se mencion´oanteriormente, los sistemas embebidos interact´uancon el entorno, para lo cual deben poseer alg´untipo de entrada (botones, sensores, etc.) y/o salida (leds, sonidos, etc.). Estas salidas se activan o no en funci´onde las entradas y el software del sistema. F´ısicamente un sistema embebido se podr´ıarepresentar con el diagrama que se muestra en la figura 4.1.

Dejando de lado los componentes que se han mencionado, el resto del hardware de los sistemas embebidos son particulares para la funci´onque el sistema realiza, lo cual lleva a tener software embebido espec´ıficopara cada sistema. Para facilitar la tarea de interactuar con cada hardware particular existen los drivers, los cuales son m´oduloso piezas de software embebido que se encargan de operar e interactuar con cierta pieza de hardware. A su vez, la aplicaci´on(el software principal) que est´eejecutando en un sistema embebido utiliza este driver para interactuar con una pieza de hardware. De esta forma se evita exigir a cada aplicaci´onque implemente la interacci´oncon cada pieza de hardware que deba utilizar.

4.3.6. Requerimientos de dise˜no

Los sistemas embebidos tienen diferentes requerimientos seg´uncu´alsea la funci´onque vayan a desarrollar, y repercuten directamente en el dise˜nodel mismo. A continuaci´onse presentan algunos de estos requerimientos.

De hardware:

Poder de procesamiento: es decir la carga de procesamiento que podr´amanejar. General- mente es medido en millones de instrucciones por segundos (MIPS).

Memoria: la cantidad de memoria RAM y ROM que tendr´a,lo que repercute directamente en el software que pueda ejecutar. Cap´ıtulo4 Estado del arte 34

Criterio Bajo Medio Alto

Procesador 4 u 8 bits 16 bits 32 o 64 bits Memoria Menor a 64 KB 64 KB a 1 MB Mayor a 1 MB Costo de desarrollo Menor a USD USD 100K a USD Mayor a 1M 100K 1M Costo de producci´on Menor a USD 10 USD 10 a USD Mayor a USD 1K 1K Cantidad de unidades Menor a 100 100 a 10000 Mayor a 10000 Consumo de energ´ıa Mayor a 10 mW/- 10 a 1 mW/MIPS Menor a 1 mW/- MIPS MIPS Tiempo de vida D´ıasa meses A˜nos D´ecadas Reliatibility Puede fallar oca- Debe funcionar de Debe ser a prueba sionalmente forma confiable de fallas

Tabla 4.4: Rangos de valores t´ıpicosde requerimientos de dise˜no.

Consumo de energ´ıa:cu´anta energ´ıaes usada por el sistema. Este requerimiento es de los m´asrelevantes cuando el sistema es alimentado por pilas o bater´ıas.Generalmente se mide en miliwatts por MIPS (mW/MIPS).

De negocio:

Cantidad de unidades: es decir, la producci´onque se espera realizar del mismo.

Costo de desarrollo: el costo tanto del dise˜nodel hardware como del software.

Vida ´util:cu´anto tiempo se espera que el producto se mantenga en uso antes de comenzar a fallar.

Fiabilidad: que tan confiable debe ser el producto.

En la tabla 4.4, basada en una tabla de [57], se pueden ver los rangos de valores t´ıpicos de requerimiento de dise˜nos,las etiquetas bajo, medio o alto son ilustrativas y no debe tomarsen como una medici´onreal.

4.3.7. Desarrollo de software en sistemas embebidos

En la mayor´ıade los desarrollos de software para sistemas embebidos el desarrollador se en- cuentra m´ascerca del hardware que en un desarrollo de software convencional. En el caso de este proyecto no existe la necesidad de un gran contacto con el hardware, ya que se instal´oun sistema operativo en el sistema embebido y se trabaja sobre ´el.De todas formas, tanto en la Cap´ıtulo4 Estado del arte 35 instalaci´onde este sistema operativo como en el desarrollo del software realizado se estuvo en mayor contacto con el hardware que en un desarrollo convencional.

En primer lugar, este tipo de software debe ser confiable, por lo que el dise˜nodel mismo de- be realizarse teniendo en mente la confiabilidad y los diferentes aspectos que esta contiene. Dependiendo de la funci´ondel sistema este punto ser´am´aso menos importante.

En parte porque los sistemas embebidos poseen, generalmente, hardware que cumple con lo justo las necesidades del mismo, toma gran importancia el desarrollo de c´odigoeficiente. Se debe tener especial cuidado en qu´eusar y c´omousarlo. Un ejemplo claro es quedarse sin espacio de memoria al querer asignar nueva memoria din´amicamente, por lo cu´alel sistema dejar´ade funcionar. Para solucionar esto muchos sistemas reservan est´aticamente todo el espacio de memoria que van a necesitar antes de comenzar su ejecuci´on.Se debe minimizar todo lo posible el uso de los recursos del sistema para no enfrentarse a situaciones en las cuales el sistema deje de funcionar, ya que muchos de esos sistemas no est´anpensados para ser reiniciados en caso de tener problemas de software, por lo que el c´odigoadem´asde eficiente debe ser robusto. Tambi´enes importante la eficiencia en cuanto al consumo de energ´ıa.

Otro aspecto importante es la dificultad en el desarrollo de c´odigoreusable. Como ya se men- cion´oanteriormente, dada la variabilidad de estos sistemas no es sencillo desarrollar c´odigoque pueda ser usado en diferente hardware sin recibir modificaciones.

En cuanto a la comunicaci´oncon perif´ericos,puede ser simplificada usando los drivers de los mismos, en caso de que posean. De todas formas es necesario saber c´omocomunicarse con cada dispositivo perif´ericopara lograr un correcto funcionamiento del sistema.

En los sistemas de tiempo real es muy importante tener siempre en mente que se deben cumplir los requerimiento de tiempo para el procesamiento o respuesta del sistema.

Las herramientas a las que se puede estar acostumbrado en el desarrollo de un software en un sistema de prop´ositogeneral no siempre sirven para el desarrollo de sistemas embebidos. Es posible que el debug de un software en un sistema embebido deba realizarse encendiendo leds o activando alg´unotro dispositivos de salida. De todas formas existen herramientas de bajo nivel que pueden ser de ayuda en este contexto.

4.3.8. Lenguajes en sistemas embebidos

Dadas las diferentes tareas que realizan los sistemas embebidos es dif´ıcilpensar en un lenguaje de prop´ositogeneral que sea ´optimopara todos los casos. Existe cierta variedad de lenguajes que han ido evolucionando, con sus ventajas y desventajas, y cada uno se adapta mejor a las diversas situaciones. Elegir el adecuado para el sistema que se vaya a desarrollar es un punto tan importante como complejo. Cap´ıtulo4 Estado del arte 36

Se pueden clasificar seg´unla organizaci´onde componentes:

Von-Neumann: basado en la ejecuci´onsecuencial de instrucciones, las cuales son secuencias de c´alculosm´asb´asicos.

Eventos discretos: en este modelo existen eventos que se van ejecutando en orden. Se basa en la simulaci´onde estos eventos y c´omolos mismos se van procesando en el tiempo.

M´aquinade estados finito: est´abasado en la noci´onde un n´umerofinito de estados, entradas, salidas y transiciones entre estados.

Flujo de datos: se basa en c´omola informaci´onse mueve en el sistema, c´omopasa de componente a componente y la transformaci´onque sufre dentro de cada uno.

Adem´asexisten principalmente dos categor´ıasde tipos de comunicaci´on:

Memoria compartida: los componentes acceden al mismo lugar de memoria para comuni- carse. En este tipo de comunicaci´onse debe tener especial cuidado con las modificaciones que se hagan sobre la memoria compartida cuando se quiere escribir y leer de manera concurrente.

Pasaje de mensajes: la comunicaci´onse realiza mediante el env´ıoy la recepci´onde men- sajes. Este tipo de comunicaci´ones generalmente m´aslento que el anterior. Se pueden distinguir 3 sub-tipos de comunicaci´on:

• Pasaje de mensajes asincr´onico(o no bloqueante): los mensajes son enviados a ciertos buffers y el emisor no necesita esperar a que el receptor reciba el mensaje ni a que est´edisponible para recibirlo, simplemente lo env´ıa.Tiene la problem´aticade que los buffers tienen un tama˜nofinito, por lo cual si los mensajes no se retiran a tiempo de los mismos podr´ıanllenarse. • Pasaje de mensajes sincr´onico(bloqueante o basado en “rendez-vous”): en este tipo de comunicaci´onsincr´onicael emisor debe esperar a que el receptor est´epronto para recibir su mensaje. No existe el problema del desbordamiento del buffer, pero la performance se ve reducida. • Invocaci´onremota (o “rendez-vous” extendido): es similar al tipo anterior, con la diferencia de que el emisor debe esperar por un aviso por parte del receptor de que el mensaje ha sido recibido (o procesado) para poder continuar.

Estas dos formas de categorizar los lenguajes se combinan para generar la clasificaci´onde los lenguajes que se puede apreciar en la tabla 4.5, basada en una tabla de [58] Cap´ıtulo4 Estado del arte 37

Memoria com- Pasaje de men- Pasaje de men- partida sajes asincr´oni- sajes sincr´oni- cos cos

Basados en Von- C, C++, Java, C, C++, Java, C, C++, Java, Neumann Assembler, LUA, LUA CSP, ADA, Pyt- Python hon Eventos discretos VHDL, Verilog, SystemC M´aquinade estados StateCharts SDL finitos Flujo de datos KPN, SDF

Tabla 4.5: Clasificaci´onde los lenguajes.

Existe otro tipo de lenguaje, llamado lenguaje sincr´onico,que combina m´aquina de estados finitos con Von-Neumann, pudiendo as´ıexpresar c´omputoscomplejos pero siguiendo dentro del modelo de m´aquinade estados. Ejemplos de este tipo de lenguaje son Esterel, Lustre y SCADE.

Es importante aclarar que la categorizaci´onse realiza con la base de cada lenguaje y teniendo en cuenta que en muchos de ellos no es clara la categor´ıaadecuada. La transici´onentre categor´ıas a veces es sencilla, lo que genera dificultad al momento de clasificarlos.

A continuaci´onse presentar´auna breve descripci´onde los diferentes lenguajes.

StateCharts es un lenguaje basado en m´aquinasde estados que utiliza memoria compartida y soporta jerarqu´ıay concurrencia, lo cual hace posible definir estados dentro de otros estados y tener diferentes sub-estados activos a la vez.

Esterel es un lenguaje “reactivo”. Es decir, cuando recibe un evento de entrada se activa y genera una salida. Se asume que estas activaciones con su reacci´oncorrespondiente se completan instant´aneamente, lo que evita todas las discusiones sobre solapamiento de tiempos de estas activaciones.

Lustre es similar a Esterel, con la diferencia de que Esterel es m´asorientado a un lenguaje imperativo y Lustre es m´asorientado a uno de tipo flujo de datos.

SCADE es un lenguaje que combina a los dos anteriores junto a una representaci´ongr´afica.

SDL es un lenguaje tambi´enbasado en m´aquinade estados finitos, pero utiliza pasaje de men- sajes para la comunicaci´on,lo que resulta especialmente ´utilen sistemas distribuidos donde la memoria compartida no es una opci´onviable. Se puede trabajar con este lenguaje tanto de forma textual como de forma gr´afica.En versiones posteriores del lenguaje se incluyeron caracter´ısticas de orientaci´ona objetos. Cap´ıtulo4 Estado del arte 38

Kahn Process Networks (KPN) es un tipo especial de lenguaje de flujos, ya que su representaci´on no indica el orden en que se deben realizar los c´alculos.La escritura en las colas de mensajes son no bloqueantes. Tiene como desventaja que estas colas de comunicaci´onpueden llenarse y hacer que el sistema entre en deadlock.

En Synchronous Data Flow (SDF) la planificaci´ones mucho m´assimple y es posible definir restricciones sobre el tama˜node los buffers, podr´ıa verse como una restricci´onsobre KPN. Esto se puede ver en la notaci´ongr´afica,donde se aprecia un grafo dirigido. Adem´as,los nodos producen y consumen un n´umerofijo de elementos por ejecuci´on,permitiendo que sea predecible y se optimice al momento de ser compilado.

VHDL modela la concurrencia a trav´esde procesos. Cada uno de estos procesos modela un componente (pieza de HW) de esta concurrencia. Los procesos se comunican a trav´esde se˜nales, las cuales se corresponden con conexiones f´ısicas.A pesar de modelar componentes de HW, VHDL es un lenguaje textual. Describe sistemas con una estructura jer´arquica.Estos sistemas est´ancompuestos por bloques que contienen primitivas, otros bloques o procesos concurrentes. La ejecuci´onse activa al producirse cierto evento.

Verilog es similar a VHDL con un poco menos de flexibilidad. Est´am´asorientado a la simulaci´on de circuitos integrados digitales, y no tanto a simulaciones de gran tama˜no.Permite al usuario crear nuevas compuertas l´ogicasusando tablas de verdad.

SystemC proporciona un entorno de simulaci´onde eventos discretos que mezcla fuertemente aspectos de la programaci´onsobre hardware y software. Es una biblioteca de C++ creada para resolver los problemas de concurrencia, tiempo, l´ogicade m´ultiplevalor y comportamiento determinado, que en ese momento no ten´ıanlos lenguajes de software.

CSP (communicating sequential processes) fue de los primeros lenguajes en proponer meca- nismos de comunicaci´onentre procesos, los cuales se comunican a trav´esde canales. CSP es determinado, ya que espera por una entrada en un canal para ejecutarse, al igual que en KPN.

ADA es un lenguaje orientado a objetos, en su dise˜noel objetivo era crear un lenguaje orientado a objetos que se pueda usar para desarrollar software militar de nivel cr´ıtico.Una de sus m´as interesantes caracter´ısticases el poder declarar procedimientos anidados. A pesar de que pas´oa ser un lenguaje p´ublico,no ha tenido mucho uso fuera de las industrias militar, aeroespacial y aeron´autica.

En Assembler las instrucciones son directamente las mismas que posee el procesador, pero escritas de una forma f´acilmente legible por un humano. Cada instrucci´onse compone de un operador y algunos operandos. Estas instrucciones son ejecutadas secuencialmente, salvo que se indique lo contrario con ciertas instrucciones condicionales o que generan loops. Cap´ıtulo4 Estado del arte 39

Un c´odigoen C contiene funciones construidas a partir de expresiones aritm´eticas,loops y condiciones. Cuando en una ejecuci´onse invoca una funci´on,el control de la ejecuci´onpasa a esa funci´onhasta que finalice y retorne al punto donde hab´ıasido invocada. C posee tipos predefinidos que est´anderivados de los que el procesador maneja directamente, y es posible construir nuevos tipos a partir de ellos. Un programa en C utiliza 3 tipos de memoria:

Datos globales, asignado cuando se compila el software.

El stack, donde se guardan, borran y modifican autom´aticamente las variables que se est´en usando.

El heap, donde se puede guardar datos de forma din´amica.

C++ es una extensi´onde C orientada o objetos, que tiene mecanismos de estructuras para programas grandes, clases, definici´onde espacios de nombres y manejo de excepciones, entre otros. Adem´asincluye nuevos tipos de datos como arreglos, ´arboles y strings.

Java es, al igual que C++, un lenguaje orientado a objetos con clases y herencia. A diferencia de los anteriores, Java es totalmente independiente de la plataforma en la que se ejecute. Para esto necesita la m´aquinavirtual de java, un int´erpretedel c´odigoque genera un programa en java. Este c´odigoque genera ocupa menos espacio que un c´odigobinario. Tiene como ventajas que fue dise˜nadocomo un lenguaje seguro, tiene manejo de excepciones y un garbage collector autom´atico.Sin embargo no es un buen sistema para aplicaciones que necesiten ejecutar en tiempo real, ya que necesita del int´erpretepara poder ejecutar, lo que puede requerir bastante espacio en memoria, no tiene control directo sobre dispositivos de entrada y salida, el garbage collector introduce un costo computacional que puede afectar la ejecuci´ony no se puede planificar cu´andoser´aejecutado, cuando hay m´asde un hilo ejecutando no se puede asegurar el orden en que ser´anejecutados y t´ıpicamente los programas en Java son menos eficientes que en C.

Existe una versi´onde Java llamada Java Card, que es un versi´onmuy reducida de Java con ´enfasisen la seguridad, pensada para tarjetas inteligentes. Adem´asexiste otra versi´on,Java Mi- cro Edition (Java ME), que est´apensada para sistemas con recursos limitados. Provee interfaces de usuario flexibles, seguridad y manejo nativo de protocolos de red, entre otras caracter´ısticas.

LUA es un lenguaje de scripting ligero, que combina una sintaxis procedural simple con una poderosa construcci´onde descripci´onde datos, es tipado din´amicamente y corre sobre su pro- pio int´erprete.Existen diferentes versiones ´utilespara sistemas embebidos (Lua VM, LuaJIT, LLVM, entre otras).

Python es un lenguaje interpretado, que soporta programaci´onorientada a objetos y programa- ci´onimperativa. Posee un tipado din´amicoy tiene una implementaci´ondel lenguaje escrita en C, CPython, que puede ser usado sobre algunos sistemas embebidos. Cap´ıtulo4 Estado del arte 40

4.3.9. Elecci´ondel lenguaje a utilizar

Dados el hardware disponible y el firmware elegido, las opciones se reducen a un lenguaje que siga el modelo de Von-Neumann.

En estas condiciones procedimos a comparar los diferentes lenguajes para seleccionar el m´as indicado. El lenguaje C es de los m´asusados en los sistemas embebidos. No siempre ha sido as´ı, pero cada vez m´asC se ha ido convirtiendo en lo m´asparecido a un est´andarpara el desarrollo de software embebido. Es interesante saber que C es elegido para desarrollo en sistemas con procesadores que van de 8-bit a 64-bit, sistemas que trabajan con diferentes unidades de memoria (B, KB, MB, etc.) y alcances de proyectos muy diferentes con equipos de una persona a cientos de ellas.

C tiene muchas ventajas, es un lenguaje peque˜noy relativamente simple de aprender, existen compiladores de C para pr´acticamente todo tipo de procesadores y los mismos generan c´odigo bastante eficiente, y al programar en C se tiene independencia del procesador que se vaya a usar. La mayor parte de lenguajes de alto nivel tambi´entienen estas ventajas, pero algo que diferencia a C y sin duda es una de sus grandes fortalezas es que es un lenguaje de “bajo alto nivel”. Es decir, a pesar de ser un lenguaje de alto nivel, provee un alto grado de control directo del hardware sin perder los beneficios de ser de alto nivel.

En un comienzo Assembler era lo que m´asse usaba. Es importante recalcar que las instrucciones que se usan en Assembler dependen del procesador sobre el cual se vaya a ejecutar el software, por lo que se dispone de un gran control sobre lo que el procesador va a ejecutar, pero se renuncia a los beneficios de los lenguajes de alto nivel, ya que el c´odigono es reusable entre diferentes tipos de procesadores y no es sencillo de usar.

En el caso de C++, se dispone de las nuevas funcionalidades que este lenguaje aporta en comparaci´oncon C, pero, a pesar de ser muy ´utiles,reducen la eficiencia del c´odigogenerado. Por lo tanto, C++ es m´asusado cuando esta reducci´onde eficiencia es menos relevante que los beneficios que trae C++.

Ada tiene ciertos beneficios que podr´ıansimplificar el desarrollo de software frente a C o C++, pero a´unas´ı no ha tenido gran aceptaci´onpor los desarrolladores de este tipo de software, sumado a que ser´ıaun nuevo lenguaje a aprender.

La principal desventaja de Java es la necesidad de correr sobre su propio int´erprete,adem´asde la menor eficiencia en comparaci´oncon C.

Lua posee varias ventajas, pero posee cierta complejidad e introduce cierto overhead en la compilaci´ondin´amica(JIT compilation).

CPyhton pese a poder ser usado en sistemas embebidos, no es compatible con la gran mayor´ıa. Cap´ıtulo4 Estado del arte 41

Por los motivos expuestos anteriormente, por el mayor conocimiento que se tiene sobre C/C++, y al correr sobre OpenWRT (que es ampliamente compatible con C/C++), se decidi´outilizar C/C++ para el desarrollo de la herramienta.

4.4. Arquitecturas de monitorizaci´on

A continuaci´onse presentan diferentes arquitecturas para monitorizaci´onde redes.

Distribuida - Cada nodo procesa localmente los datos y se basa en la informaci´onque le env´ıanotros nodos para tomar decisiones. No hay ning´unmaster.

• Ventajas ◦ No es necesario transferir toda la informaci´ona un nodo central para que este ordene al resto qu´edebe hacer. ◦ Los nodos se “conocen” entre s´ıy podr´ıantomar decisiones m´asr´apidamente basadas en informaci´onde sus vecinos que ya posean. ◦ Aunque un nodo falle, el resto sigue procesando. • Desventajas ◦ Debe existir coordinaci´onentre los nodos. ◦ Existe la posibilidad de que un nodo tome una decisi´onincompatible con la decisi´onde otro. ◦ Los nodos usan procesamiento que dejan de aportar a su funci´onprincipal.

Centralizada - Cada nodo simplemente recolecta y env´ıainformaci´ona un master, sin realizar ning´unprocesamiento. El master se encarga de realizar todos los procesamientos y ordena al resto de los nodos qu´ehacer.

• Ventajas ◦ No van a existir decisiones incompatibles al procesarse todo desde un nodo cen- tral. ◦ No se necesita coordinaci´onentre los nodos. ◦ Los routers se dedican totalmente a su funci´onprincipal y no utilizan procesa- miento para otras tareas. • Desventajas ◦ Si falla el master se cae el sistema. ◦ Mayor carga en el master. ◦ Toda la informaci´ondebe viajar al nodo master. Cap´ıtulo4 Estado del arte 42

H´ıbrido- Cada nodo hace un peque˜noprocesamiento y mantiene datos, pero env´ıagran parte de la informaci´ona un master donde se toman decisiones y se comunican al resto de los nodos.

• Ventajas ◦ No hay tanta sobrecarga en el master. ◦ Aunque el master caiga se contin´uarealizando el procesamiento en los nodos. ◦ Las decisiones que involucren vecinos directos se pueden tomar en los nodos. ◦ Los nodos conocen cierta informaci´onsobre sus vecinos. • Desventajas ◦ Los nodos usan cierto procesamiento que dejan de aportar a su funci´onprincipal. ◦ Debe haber coordinaci´onentre los nodos. ◦ Existe cierta carga de informaci´onhacia el master. ◦ Se tiene mayor complejidad al existir decisiones locales y globales.

La carga de mensaje de red entre las 3 formas es similar.

En el caso de un arquitectura distribuida se env´ıanmuchos mensajes para compartir la informaci´oncon el resto de los nodos y comunicar las decisiones tomadas.

En el caso de un arquitectura centralizada hay muchos mensajes para enviar datos propios y recibir ´ordenes del master.

En el caso h´ıbridohay un poco de cada uno de los anteriores.

En este proyecto se opt´opor utilizar una arquitectura totalmente centralizada. Esta decisi´onse tom´opor simplicidad y por adaptarse a la realidad del proyecto, ya que se quiso disponer de la mayor cantidad de datos posible en una misma base de datos, para lo cual el servidor central recibe todos los datos de los monitores, los procesa y los almacena; no siendo relevantes la toma de decisiones ni las consecuentes modificaciones en el comportamiento de los routers.

Siendo conscientes de las desventajas de este tipo de arquitectura, se asume el riesgo de utilizarla. Para evitar un fallo en el master, controlar la carga sobre el mismo o la carga sobre la red ser´ıa recomendable realizar un estudio de carga sobre la infraestructura. Cap´ıtulo5

Monitorizaci´on

5.1. Indicadores de calidad

La presente secci´onse basa en el libro “Redes de Computadores: Un Enfoque Descendente” [1], en los sitios [69], [70], [71] y [72], en los art´ıculos“Montaje de un router wireless en una maquina gnu/linux” [73], “Is rssi a reliable parameter in sensor localization algorithms - an experimental study” [74], “Assessing link quality in ieee 802.11 wireless networks: Which is the right metric?” [75], “Link-level measurements from an 802.11b mesh network” [76], “Long-distance 802.11b links: Performance measurements and experience” [77], “An´alisis de la calidad de se˜nalen una red wifi con la herramienta netstumbler” [78], “Link quality and signal-to-noise ratio in 802.11 wlan with fading: A time-series analysis” [79] y “On the wifi interference analysis based on sensor network measurements” [80], y en la tesis “A measurement-based joint power and rate controller for ieee 802.11 networks” [81].

Uno de los problemas que constantemente afecta la transmisi´onconfiable de las se˜nalesen un sistema de comunicaci´oninal´ambrico es el deterioro que ´estaspresentan por causa de factores como la distancia, la temperatura del ambiente, el ancho de banda utilizado, la interferencia elec- tromagn´etica(producida por rayos, motores, generadores, etc.), obst´aculos(como por ejemplo paredes, ventanas, pisos, ´arboles), entre otros. El deterioro de la se˜nalpuede presentarse como una peque˜naatenuaci´ono p´erdida de potencia debido a la distancia que separa el transmisor de su receptor, o por causa de se˜nalesel´ectricasaleatorias que se encuentran en el ambiente, las cuales se conocen como ruido. Es por ´estoque es muy importante conocer y analizar la cantidad de ruido e interferencia que introduce el medio de transmisi´ona la se˜nal,ya que si el medio presenta demasiado ruido la comunicaci´onno ser´aeficiente ni confiable.

Seg´unel est´andarIEEE 802.11 [82], se define un canal como una instancia de medio de comu- nicaciones para el prop´ositode pasar unidades de datos de protocolo (PDU) entre dos o m´as

43 Cap´ıtulo5. Monitorizaci´on 44 estaciones (STA); y se define la separaci´onentre canales como la diferencia entre las frecuencias centrales de dos canales no solapados y adyacentes del transmisor de radio.

Teniendo en cuenta estos conceptos, es importante remarcar que en el contexto de las comu- nicaciones inal´ambricas las transmisiones realizadas en canales adyacentes se solapan y causan interferencia entre ellas, resultando en un pobre rendimiento de la red. A su vez, las se˜nalesno solo pueden provenir de redes cercanas, sino que tambi´enpueden originarse en fuentes externas tales como monitores para beb´es,tel´efonosinal´ambricos, hornos de microondas, etc.

Para la banda de 2.4 GHz existen 14 canales separados por 5 MHz, para los cuales en cada pa´ıs y zona geogr´aficase aplican sus propias restricciones sobre el n´umerode canales disponibles. Por ejemplo, en Uruguay se utilizan los 11 primeros, as´ıcomo en Norteam´erica,mientras que en Europa se dispone de 13, y en Jap´onse utilizan todos. Esta distribuci´onintroduce un problema, dado que cada canal necesita 22MHz de ancho de banda para operar, y es que se produce un solapamiento de varios canales contiguos.

Al existir gran cantidad de puntos de acceso y clientes utilizando esta banda se produce un fuerte impacto en el rendimiento de la red inal´ambrica producido por la interferencia que generan, que si bien es producida por todos los dispositivos, los que tienen mayor incidencia son los APs, por lo que manejar su solapamiento resulta un desaf´ıofundamental para mejorar la performance de la red. Aqu´ıaparece un concepto importante a tener en cuenta: el solapamiento.

Al distanciarse por 5 MHz los canales contiguos, y al utilizar 22 MHz de ancho de banda cada uno, sucede que cada canal se solapa con los 4 canales sucesivos contiguos a s´ımismo hacia cada lado. Por ejemplo, el canal 1 se superpone con los canales 2, 3, 4 y 5, y el 6 con los canales 2, 3, 4, 5, 7, 8, 9 y 10. Como los dispositivos que emiten en rangos de frecuencias solapados pueden generar interferencias, es importante seleccionar el canal que menos se superponga con los puntos de acceso cercanos, de forma de no deteriorar la calidad de se˜naltanto en nuestro dispositivo como en los que se encuentran dentro de nuestro rango de alcance de se˜nal.

Para poder determinar la calidad de un enlace es necesario definir indicadores que permitan conocer el estado del mismo, para luego tomar las mediciones correspondientes y as´ıobtener el nivel de la se˜nalrecibida entre los nodos que conforman el enlace. Una vez que conocemos estos valores, podremos optar por reaccionar ante la situaci´onque se presenta, como puede ser cambiar el canal en el que se opera, aumentar la potencia del emisor en caso de que la intensidad de la se˜nalque llega al receptor sea muy d´ebil,o reducirla en caso de que la se˜nalque llega al receptor sea buena pero se est´ecausando interferencia en otros dispositivos de la red. A continuaci´onse presentan los indicadores de calidad de se˜nalm´asrelevantes.

En comunicaciones anal´ogicasy digitales la relaci´onse˜nal/ruido,comunmente escrito S/N, o SNR por su sigla en ingl´es,es una medida de la intensidad de la se˜nalcon respecto al ruido de fondo. La relaci´onse mide en decibelios (dB). Si la intensidad de la se˜nalentrante en microvoltios Cap´ıtulo5. Monitorizaci´on 45 es Vs, y el nivel de ruido, tambi´enen microvoltios, es Vn, entonces la relaci´onse˜nal/ruido en decibelios est´adada por la f´ormula S/N = 20 log10 (Vs / Vn). Si Vs = Vn, entonces S/N = 0. En esta situaci´onla se˜nales casi ilegible, debido a que el nivel de ruido compite fuertemente con ella. En las comunicaciones digitales, ´esto probablemente provocar´auna reducci´onen la velocidad transmisi´onde datos debido a errores frecuentes que requieren que el emisor vuelva a enviar algunos paquetes de datos. Idealmente, Vs es mayor que Vn, de modo que S/N sea positivo.

Se puede determinar la calidad de se˜nalde la conexi´onobservando la relaci´onse˜nal-ruido(SNR) de la red inal´ambrica. Esta m´etricacompara la intensidad de la se˜nalcon los niveles de ruido existentes para ofrecer una estimaci´onm´asprecisa de la calidad de la conexi´on. A modo de ejemplo, si consideramos un valor SNR menor a 25 dB y una intensidad de se˜nalmenor al 40 % (-70 dBm) es probable que se trate de un problema de alcance o bloqueo de se˜nal;mientras que si el valor SNR es menor a 25 dB y el nivel de ruido es mayor al 10 % (-90 dBm) es probable que se trate de un problema de interferencia ocasionada por otros dispositivos.

L´ogicamente, esta m´etricaest´amuy relacionada con el Bit Error Rate (y por lo tanto al Packet Error Rate), ya que, al no distinguirse claramente la se˜naldel ruido, se introducen posibles fuentes de error en la lectura de los paquetes, mientras que en el caso opuesto se reducen las probabilidades de que esto suceda. Sin embargo, como se indica en [75], calcularlo genera mucho overhead, por lo que, en caso de no estar disponible de forma nativa por parte de la placa de red, puede generar un impacto muy negativo en la performance del router. A su vez, este indicador var´ıaseg´un la tasa de transmisi´on,lo que sugiere utilizar un algoritmo de adaptaci´onde tasa de transmisi´onen funci´onde los valores de SNR registrados.

Un indicador muy similar al SNR es el SINR, que mide la intensidad de la se˜nalfrente a la suma de interferencia m´asel ruido. En este proyecto, como es demasiado costoso en la pr´actica (cuando no es imposible) identificar la interferencia para separarla del ruido, se considerar´ala interferencia como ruido. De esta forma, SNR y SINR ser´anconsiderados el mismo indicador, al cual nos vamos a referir como SNR.

A su vez, RSSI (Received Signal Strength Indicator) se define como diez veces el logaritmo del cociente de la potencia de se˜nalrecibida y una potencia de referencia. Por lo tanto, el RSSI es directamente proporcional a 10 Log P/Pref, lo que implica que mantiene una relaci´onde proporcionalidad directa con la potencia de la se˜nal. Esto´ lo vuelve un indicador muy relevante a la hora de medir la calidad de se˜nal,pero presenta un par de desventajas: La primera es la forma en que se toma el indicador, que se realiza en el pre´ambulo de la recepci´onde un paquete PLCP (Physical Layer Convergence Protocol, que es un protocolo especificado dentro de la capa de convergencia de transmisi´onque define exactamente c´omose formatean los elementos dentro de un flujo de datos para un tipo particular de instalaci´onde transmisi´on)y en la lectura de sus headers, y no en el per´ıodo de recepci´onde los datos de dicho paquete, por lo que no nos permite Cap´ıtulo5. Monitorizaci´on 46 conocer la potencia de la se˜nalpromedio de la recepci´ondel paquete completo. Y la segunda desventaja es que no es capaz de detectar interferencias destructivas en el medio, lo que puede explicarse por el hecho de que las medidas s´olose toman cuando se recibe con ´exitoel header PLCP; de esta forma, no existen medidas de RSSI para los casos en los que falla la recepci´onde un paquete. Para complementar esta m´etricapuede utilizarse la medici´ondel “silence value”, que refleja la potencia total de la se˜nalobservada antes de que comience un frame.

Otro indicador de la calidad de la se˜nalse puede obtener a partir de los estados de LPI (Low- Power Idle), que indican:

Cuando la radio se encuentra transmitiendo activamente (TX)

Cuando el mecanismo de detecci´onde paquetes/se˜nalprovoca un intento de demodulaci´on (RX)

Cuando hay suficiente energ´ıade la se˜nalen banda en el medio, pero el mecanismo de detecci´onde paquetes no se activa (BUSY). Esto´ puede suceder debido a la interferencia, por ejemplo, puede ser provocada por una actividad fuera de banda, tal como un horno de microondas, una transmisi´onBluetooth o transmisiones de paquetes IEEE 802.11 en los canales adyacentes.

Cuando no aplica ninguno de los estados anteriores (IDLE).

Como el estado LPI s´olopuede encontrarse en uno de ´estos a la vez, es posible diferenciar el tiempo libre del tiempo ocupado, e incluso distinguir el tiempo que se reciben se˜nales“limpias” que activan intentos de demodulaci´ondel tiempo que se reciben se˜nalescon interferencia. Para este trabajo, es interesante distinguir el tiempo que se insume en demodular paquetes (RX), aquel en el que se percibe se˜nalpero no alcanza para activar el mecanismo de detecci´onde paquetes (BUSY), y lo que se conoce como Transmission Opportunity, que es el tiempo en el que efectivamente se est´atransmitiendo m´asaquel en el que se podr´ıaestar transmitiendo (TX + IDLE). De esta forma se pueden obtener estad´ısticasque brindan indicios sobre la saturaci´on del medio, lo cual posibilita tomar decisiones sobre c´omoreaccionar ante la realidad que se presenta.

Siguiendo en esta l´ınea,pero un nivel m´asalto dentro de la capa de enlace, es posible obtener estad´ısticassobre las tramas que llegan al receptor, clasific´andolasen tramas de datos, tramas de gesti´ony tramas de control. Esto es ´util para conocer el nivel de overhead que existe en el medio, el cual disminuye la calidad de la se˜nalrecibida. Para lograrlo es necesario realizar sniffing en la red, configurando el adaptador en modo promiscuo, e inspeccionar sus headers para discernir a qu´ecategor´ıapertenecen. Una vez que se identifica la trama recibida, interesa conservar su tipo (si se trata de una trama de control, o de gesti´onde qu´etipo espec´ıfico es) y un Cap´ıtulo5. Monitorizaci´on 47 timestamp de cuando fue recibida, adem´asde mantener contadores por tipo de trama recibida. Estas estad´ısticas, junto a los tiempos registrados, sirven para conocer el nivel de uso de la red a lo largo de la jornada, lo que permite no s´oloreaccionar frente a la situaci´onactual, sino que adem´as,permite planificar la configuraci´onde los puntos de acceso de la red para brindar una mejor calidad de servicio seg´unlos requerimientos en horarios espec´ıficos.

Por otro lado, pueden utilizarse indicadores de calidad de la conexi´onpara tener una noci´on de la calidad de se˜nalrecibida. Este tipo de m´etricasno brinda informaci´ondirecta sobre la calidad de la se˜nal,pero, al depender tan fuertemente de ella, nos permite conocer su estado desde un punto de vista m´aspr´oximoa la experiencia de los usuarios de la red. Por ejemplo, utilizando la t´ecnicade ping flooding se puede medir la latencia entre el router y los clientes, y obtener el porcentaje de paquetes perdidos, duplicados y desordenados. Si bien para obtener estos indicadores se puede recurrir a m´etodos que generan m´asoverhead en la red, pueden ser ´utilespara casos en los que no es posible obtener indicadores de las formas mencionadas anteriormente.

5.2. Herramientas de an´alisisexistentes

Esta secci´onse basa en los art´ıculos“Herramientas de monitorizaci´ony an´alisisdel tr´aficoen redes de datos” [83] y “A perspective on trafic measurement tools in wireless networks” [84], y en el sitio [85].

Un sniffer o analizador de paquetes es un programa que captura (y opcionalmente analiza) paquetes de red, los cuales no siempre tienen por qu´eestar dirigidos al equipo donde el programa est´aejecutando. Estos analizadores tienen diversos usos, desde simplemente almacenar el tr´afico existente hasta monitorizar redes en tiempo real para detectar fallos o ataques (incluso para poder realizarlos).

Actualmente existen multitud de programas de este tipo. La mayor´ıade ellos tienen en com´un ciertas funcionalidades:

Capturar tr´aficode redes LAN cableadas e inal´ambricas.

Capturar tr´aficoa trav´esde las interfaces de red que el equipo posea (en modo promiscuo permite capturar todo el tr´aficode la red sin importar el destinatario).

Posibilidad de examinar, guardar y cargar capturas de paquetes en diferentes formatos.

Interpretar el funcionamiento de diferentes protocolos utilizados en la red (DHCP, TCP, HTTP, etc.). Cap´ıtulo5. Monitorizaci´on 48

Aplicar filtros sobre los paquetes a capturar o a mostrar.

Calcular estad´ısticasy representar gr´aficossobre diferentes indicadores (velocidades, pa- quetes enviados, recibidos, etc.).

Generar reportes en tiempo real.

Configurar alarmas que notifiquen ante cierto evento.

Obtener informaci´onde los nodos presentes en la red (MAC, IP, sistema operativo, fabri- cante).

Reconstruir sesiones TCP.

A continuaci´onse presenta un breve an´alisisde las diferentes herramientas existentes.

Tcpdump

Es un software libre y de c´odigoabierto que se ejecuta sobre la consola. Permite interceptar y visualizar paquetes TCP/IP (entre otros) que est´enviajando en la red a la cual el equipo est´econectada, ya sea inal´ambrica o cableada. Posee versiones para Linux, Windows y OS X entre otros.

Wireshark

Es uno de los analizadores m´asutilizado, adem´asde ser de los m´ascompletos. Al igual que tcpdump, permite capturar los paquetes de red. Muestra con gran nivel de detalle de cada paquete. Posee interfaz gr´aficay gran posibilidad de aplicar filtros. Puede reconstruir y presentar flujos TCP e interacciones completas. Est´adesarrollado bajo licencia GNU y posee versiones para la mayor´ıade los sistemas operativos actuales.

CommView

A diferencia de las anteriores, esta herramienta es comercial y est´adise˜nadapara obtener una completa imagen del flujo de tr´aficode redes LAN cableadas y para reconstruir las sesiones f´acilmente. Posee un analizador para tr´aficoVoIP. Corre en Windows y su interfaz gr´afica es f´acilmente manipulable. Existe una versi´onpara monitoreo del tr´aficoen un equipo de forma remota.

Kismet

Es usado como sniffer y como IDS (sistema de detecci´onde intrusos) para redes 802.11 a/b/g/n. Trabaja con tarjetas que soportan modo monitor. Es posible agregarle plugins para incrementar sus funcionalidades, permite detectar redes escondidas y soporta la mayor´ıa de los sistemas operativos. Cap´ıtulo5. Monitorizaci´on 49

NetworkMiner

Esta herramienta, ´unicamente para Windows, est´aenfocada en el an´alisisforense, e intenta obtener toda la informaci´onposible sobre los hosts presentes en la red (cableada o inal´ambrica). Su interfaz gr´aficapresenta una sencilla y a la vez completa forma de visualizar la informaci´on obtenida. Puede obtener una gran cantidad de informaci´onsobre cada host, y posee una versi´on gratuita con las funcionalidades mencionadas y una versi´oncomercial que extiende las mismas, permitiendo exportaci´onde resultados a CSV y Excel, coloreo de hosts y geolocalizaci´onIP, entre otras.

OmniPeek

Esta herramienta, comercial, es un analizador de red (cableada e inal´ambrica) con una interfaz gr´aficasencilla e intuitiva. Posee visibilidad en tiempo real, y mediante la interfaz se puede analizar r´apidamente las condiciones de la red para detectar problemas. Puede analizar tr´afico de voz y video IP.

Existen otras herramientas que no son analizadores de paquetes, pero ayudan a conocer el estado de la red o redes existentes.

InSSIDer

Es una herramienta para escanear las redes 802.11 presentes. Es de software libre y tiene ver- siones para Windows, Linux y dispositivos m´oviles.Recoge informaci´onde las redes que detecte como direcciones MAC, SSID, canal, fabricante y tipo de seguridad, entre otros. Puede generar gr´aficospara mostrar la intensidad y la localizaci´onde las diferentes redes y permite filtrar las redes a mostrar.

NetStumbler

Es una herramienta libre, para Windows, que permite la detecci´onde redes LAN inal´ambricas que utilicen los est´andares802.11a/b/g. Permite escanear todo el espectro de forma r´apida, logrando ver las redes cercanas, los niveles de se˜nal,el SNR, velocidad de transferencia y marcas de los equipos. Posee gr´aficoscon cierta informaci´onde las redes, como SNR en tiempo real, y puede detectar la ubicaci´onde antenas inal´ambricas direccionales.

Acrylic

Esta herramienta puede realizar un an´alisisde cobertura y seguridad de redes LAN inal´ambricas. Posee una interfaz sencilla e intuitiva donde visualizar todos los dispositivos de comunicaciones existentes, c´omose comportan y cu´alesson las opciones de seguridad implantadas. Tiene la funcionalidad de generar informes autom´aticamente. Cap´ıtulo5. Monitorizaci´on 50

Figura 5.1: Merkai - Informaci´onpor canales.

5.3. Merkai - CISCO

Esta secci´onest´abasada en los sitios de CISCO Merkai [86], [87], [88], [89] y [90], y en los datasheets [91] y [92].

Merkai es una empresa fundada en 2006 que actualmente forma parte de CISCO, y ofrece pro- ductos que se administran completamente desde la nube, incluyendo LAN inal´ambrica, switches Ethernet y dispositivos de seguridad. Es una empresa a nivel global con m´asde veinte mil im- plementaciones de sus productos en redes de todo el mundo. El objetivo de Merkai es construir redes inteligentes, administrables a trav´esde la nube que simplifiquen las redes empresariales. Se presenta en este proyecto como una alternativa paga similar a lo que se busca comenzar a resolver en este trabajo.

Est´aenfocado en la administraci´oncentralizada de la red, pero tambi´en presenta ´ındices y mediciones. Automatiza, optimiza e incrementa la performance en las redes inal´ambricas de alta densidad a´unsobre condiciones de mucha interferencia. Esto lo realiza utilizando un tercer radio dedicado a esta funci´onque poseen los puntos de acceso de Merkai, con el cual mide la utilizaci´ondel canal, la fuerza de la se˜nal,el throughput, las se˜nalesde los APs que no sean de Merkai y las interferencias que no sean por WiFi. Posee herramientas para analizar en tiempo real el espectro de se˜nalesy la utilizaci´onde los canales en cualquier punto de la red, de forma de detectar interferencias y actuar en consecuencia. Utilizando todos los datos que obtiene en tiempo real y el hist´oricoadapta autom´aticamente el canal a usar, el poder de la se˜nalde los APs y la configuraci´onde las conexiones de los clientes, para optimizar y mejorar la performance de la red.

En las figuras 5.1y 5.2 se pueden apreciar algunas capturas de la informaci´onque brinda. Cap´ıtulo5. Monitorizaci´on 51

Figura 5.2: Merkai - An´alisisde espectro en vivo.

Funciona de forma tal que los datos de gesti´onde la red (configuraci´on,estad´ısticas,etc.) pasan de los dispositivos Merkai a la nube de Merkai y los datos de los usuarios no van a la nube, sino que van directamente a su destino a trav´esde la red (LAN o WAN seg´unel caso).

En la nube de Merkai se analizan todos los datos y se toman decisiones sobre la red, de forma de evitar tener que configurarla manualmente para adaptarla a las condiciones en las que se encuentra y sacarle el mayor provecho.

Tambi´enposee herramientas para monitorizar y resolver los problemas que puedan tener la red, los dispositivos o los clientes en cualquier punto de la misma.

Finalmente posee utilidades para analizar el uso que los clientes le dan a la red. Entre ellos se encuentran el tiempo de uso, an´alisisde permanencia en zonas, ubicar visitantes nuevos y localizaci´onactual, con posibilidad de filtros por sistema operativo y hardware entre otros.

Por ser un sistema totalmente cerrado y propiativo no se explica c´omose logra tomar todas estas decisiones ni exactamente qu´emedidas toman. Cap´ıtulo6

Desarollo

6.1. Generalidades

Luego del planteamiento del problema y el estudio realizado, se continu´ocon la intenci´onde desarrollar una herramienta que ayude a atacar el problema planteado.

Esta secci´onest´abasada en los sitios de OpenWRT [93], [94], [95], [96], [97], [98], [99], [100], [101], [102], [103], [104], [105], [106], [107], [108], [109], [110], [111] y [112], sobre como instalar OpenWRT [113], [114], [115] y [116], sobre dhcp en ubuntu [117], sobre tftp en ubuntu [118], de kernel.org [119] y [120], de Linux Wireless [121], de iwconfig manpage [122], sobre Kismet [123], [124], [125] y [126], de iw github [127], sobre “wireless tool for linux” [128] y sobre “banwidth monitoring tool for linux” [129], y en los documentos “Kismet Readme” [130], “Step By Step Guide for Starting “Hello, World!” on OpenWRT” [131] y “Linux & 802.11 Wireless” [132].

6.1.1. Acercamiento a OpenWRT y las herramientas disponibles

Se investig´oel sistema OpenWRT, las gu´ıasb´asicasde comienzo, la forma de instalar paquetes nuevos y en particular el funcionamiento de las redes inal´ambricas sobre este sistema.

La configuraci´ondefinida para la red inal´ambrica se encuentran en el archivo /etc/config/wire- less. Cuando se inicia el router por primera vez, el sistema detecta qu´etarjeta posee y arma una configuraci´onpor defecto para esa tarjeta. Esta configuraci´onposee dos secciones importantes, una referida a la red f´ısica,“wifi-device”, y otra que refiere a una red virtual que se monta sobre la f´ısica,“wifi-iface”. A continuaci´onse presentan los campos que contiene esta configuraci´on en la placa Routerboard 133 con la versi´onKamikaze del firmware, con un detalle de cada uno (no todos los campos son obligatorios):

52 Cap´ıtulo6. Desarollo 53

config wifi-device Nombre interno del adaptador option type Tipo (broadcom, atheros, mac80211) option country Siglas del pa´ıs option channel Canal option distance Distancia al cliente mas lejano (1-n, si es soportado) option hwmode Modo de HW (11b, 11g, 11a, 11bg, si es soportado) option rxantenna Indica la antena receptora (0,1,2, si es soportado) option txantenna Indica la antena transmisora (0,1,2, si es soportado) option txpower Poder de transmisi´on(en dBm)

config wifi-iface option network La interfaz de red a la cual se va a montar la virtual option device Identificador para el hw de radio option mode Modo de la red (ap, sta, adhoc, monitor o wds) option ssid Nombre de la red option bssid Direcci´onbssid option encryption Cifrado (none, wep, psk, psk2, wpa o wpa2) option key Clave de cifrado option keyX Otra clave option hidden Red oculta o visible (0, 1) option isolate Aisla a los clientes entre si (0,1)

Se continu´oinvestigando en profundidad el funcionamiento de las redes sobre este firmware.

OpenWRT posee una gran cantidad de paquetes. Nos enfocamos en aquellos que puedan resultar provechosos para el objetivo que se persigue. Entre las herramientas evaluadas se encuentran: “iwconfig” (similar a ifconfig aplicado a redes inal´ambricas, mediante el cual se pueden se- tear diferentes par´ametros y sacar datos y estad´ısticas),“iw” (la cual reemplaza al anterior), “tcpdump” (un capturador de tr´afico),entre otras. Una herramienta en particular, “kismet”, result´omuy interesante y m´asadelante se profundiza sobre la misma.

Tambi´ense busc´oinformaci´onde sobre c´omorealizan sus funciones estas herramientas, revisando sus c´odigofuente, para intentar encontrar que “systemcalls” utilizan o de qu´eforma obtienen sus datos y poder replicarlo en nuestra herramienta.

Por otro lado se investig´oc´omocompilar paquetes propios para que ejecuten sobre nuestra placa. Se presentaron diversos problemas a la hora de realizar esta tarea, y no se logr´ogenerar un paquete funcional para la versi´onutilizada de OpenWRT. Cap´ıtulo6. Desarollo 54

6.1.2. Trabajando sobre la Routerboard 133

Se investig´osi era posible trabajar en esta tarjeta en modo monitor, para lo que se busc´oinforma- ci´onsobre el chipset que utiliza, resultando que era posible. Por lo tanto, se comenz´oa trabajar sobre la misma, instalando OpenWRT. A continuaci´onse presentan los pasos realizados:

Flasheo con RouterBOOT 2.7

En primer lugar se instal´ola versi´on2.7 del firmware RouterBOOT (el cual es un gestor de arranque). La versi´oninstalada se descarg´odesde http://www.routerboard.com/files/rb- 2.7/adm5120-2.7.fwf

Se estableci´ouna conexi´onal router utilizando el puerto serial y se cre´ouna configuraci´on para conectarse al mismo. Para esto se ejecut´oel comando “minicom -s”, dentro de la secci´on“Serial port setup”se ubic´oel device en el que se encuentra el router (con dmesg — grep tty) y se lo seleccion´oen “serial device”. Luego se configur´oel “Bps/Par/Bits” en 1152000 y 8N1 y se guard´ola configuraci´on.

A continuaci´onse inici´ocon la configuraci´oncreada: “minicom nombre archivo config”

Se enciende el router y se presiona cualquier tecla r´apidamente para entrar al setup.

Dentro del setup se eligi´ola opci´on“g”, “Upgrade firmware”, luego la “s”, “Over serial port”. Desde este punto el router se queda a la espera del archivo. Presionando Ctrl + a + z se elige la opci´on“s”, transferir archivo, seleccionando “xmodem” se busca el archivo y se lo env´ıa.Luego de finalizada la transferencia hay que reiniciar el router.

Finalmente se formatea la nand, con la opci´on“e” del setup quedando el dispositivo flasheado con RouterBOOT 2.7.

Instalaci´onOpenWRT

Luego se procedi´oa instalar OpenWRT realizando un arranque por red. Para esto fue necesario levantar un servidor DHCP y un TFTP.

Por otro lado se descarg´ola imagen de OpenWRT para arranque por red openwrt- adm5120-2.6-vmlinux.elf.

Como servidor DHCP se utiliz´odhcp3-server, el cual se descarg´oy se modific´osu confi- guraci´on(archivo /etc/dhcp/dhcpd.conf):

subnet 192.168.100.0 netmask 255.255.255.0 { range 192.168.100.2 192.168.100.250; Cap´ıtulo6. Desarollo 55

option routers 192.168.56.1; option broadcast-address 192.168.100.255; default-lease-time 600; max-lease-time 7200; }

Se reinici´ola interfaz /etc/init.d/isc-dhcp-server restart

Se cambi´ola configuraci´onde red del sistema donde estaba ejecutando (Ubuntu) y se deshabilitaron otras interfaces de red existentes.

A continuaci´onse levant´oun servidor TFTP. Para esto se utiliz´oxinetd (sudo apt-get install xinetd tftpd tftp -y), se cre´oel fichero /etc/xinetd.d/tftp, donde se guard´ola configuraci´ondel mismo (fue necesario mantener el nombre “tftp”):

service tftp{ protocol = udp port = 69 socket\_type = dgram wait = yes user = nobody server = /usr/sbin/in.tftpd server*args = var/lib/tftpboot -s disable = no }

Se cre´oel directorio /var/lib/tftpboot y se le asignaron los permisos necesarios (sudo chown -R nobody:nobody /var/lib/tftpboot y sudo chmod -R 777 /var/lib/tftpboot)

Finalmente se reinici´oel servicio para que se apliquen los cambios (sudo service xinetd stop y sudo service xinetd start). Es importante destacar que una vez el archivo a transferir est´een el directorio hay que darle permisos al mismo.

Teniendo ambos servidores levantados se modific´ola configuraci´ondel DHCP para que el router pueda tomar el archivo de imagen del firmware. Para esto se agreg´o:

host router{ hardware ethernet [MAC\_ROUTER]; filename "/openwrt-adm5120-2.6-vmlinux.elf"; // Imagen de OpenWRT fixed-address 192.168.100.3; }

Se modific´ola configuraci´onque ya exist´ıa previamente agregando la direcci´onIP del servidor TFTP Cap´ıtulo6. Desarollo 56

next-server 192.168.100.5;

Se conect´oel router por red cableada y se configur´opara que arranque por red (opci´on “e”), luego se reinici´o(previamente se verific´oque los servidores dhcp y tftp estuvieran levantados y funcionando correctamente) obteniendo as´ıel router ejecutando OpenWRT pero con un inicio por red. A´unno est´ainstalado.

Se configur´ola red desde el router para poder acceder a la pc donde se tiene el OpenWRT completo (openwrt-adm5120-rb1xx-kernel y openwrt-adm5120-router le-rootfs.tar.gz). Pa- ra esto se ejecut´oifconfig eth0 192.168.100.5.

Utilizando scp se obtuvieron ambos archivo y renombr´andosela imagen del firmware a “kernel”.

scp [email protected]:/home/pgmonitoreo/nombre\_archivo .

Finalmente, con los archivos en el router, se realizaron los pasos adecuados para la insta- laci´onde OpenWRT:

mount /dev/mtdblock2 /mnt cd /mnt copiar kernel a /mnt cd / umount /mnt mount /dev/mtdblock3 /mnt cd /mnt copiar openwrt-adm5120-router\_le-rootfs.tar.gz a mnt tar zxvf openwrt-adm5120-router\_le-rootfs.tar.gz rm openwrt-adm5120-router\_le-rootfs.tar.gz cd / umount /mnt sync reboot

Entrando nuevamente al router, se cambi´ola configuraci´onpara que bootee desde nand, se reinici´oy qued´oinstalado y funcionando OpenWRT.

Luego de instalar el firmware, se comenz´oa trabajar sobre ´el,investigando diferentes herra- mientas y capacidades del mismo.

A grandes rasgos no se consigui´oun avance significativo, ya que surgieron varias problem´ati- cas que imposibilitaron el avance. Entre ellas, al no poder instalar una versi´onde OpenWRT Cap´ıtulo6. Desarollo 57 m´asreciente, ya que la placa no lo soporta, muchas herramientas o features no se encontraban disponibles. Tampoco se logr´ocompilar un paquete para instalar nosotros mismos, y lo m´as importante, se hizo muy complicado configurar la red de forma correcta. Al cambiar la con- figuraci´onde las interfaces no era posible quitarle el bridge sin perder la conectividad con el dispositivo por m´asque seg´unla documentaci´onse estaba configurando de forma correcta. Se revis´otambi´enque no se tratara de un problema causado por el de firewall, pero tampoco se tuvo ´exito.Al conectarlo a otra pc se intent´ocambiar el “default gateway” en la tabla de ruteo, pero tampoco se logr´oque la red quedara funcional, ni se consiguieron resultados intentando conectar el router como cliente a otro servidor dhcp (ya sea de un router o de un servidor).

Luego de aproximadamente dos meses de intentos fallidos, se decidi´ohacer un cambio en el hardware utilizado.

6.1.3. Trabajando sobre TP-Link TL-WDR4300

Sobre este hardware se pudo instalar una versi´onde OpenWRT m´asreciente, la versi´on12.09 “Attiude Adjustment”, y se lograron manejar de forma correcta las configuraciones de las redes y dem´as.Como contrapartida, el mismo no cuenta con las diferentes interfaces inal´ambricas que pose´ıael R133, por lo cual no se va a poder utilizar como AP y monitor a la vez.

Luego de sortear los diferentes problemas que surgen al trabajar con un nuevo hardware, nos enfocamos en la herramienta “kismet”. Dicha herramienta es un sniffer, detector de redes y fun- ciona tambi´encomo IDS (sistema de detecci´onde intrusos), mencionado en el cap´ıtuloanterior. Nuestro inter´essobre ella se encuentra en los datos que la misma obtiene de la red. Posee 3 partes bien diferenciadas: un cliente, un servidor y uno o m´asdrones:

Cliente: muestra al usuario la informaci´onque la herramienta posee de forma amigable. Corre sobre linux.

Servidor: es quien recepciona y procesa los datos que env´ıanlos drones. Corre sobre linux.

Dron: se encarga de tomar los datos de las redes y enviarlos al servidor. Corre sobre OpenWRT.

Para hacer funcionar esta herramienta surgieron diferentes obst´aculos,tanto en el router como en la PC que iba a oficiar de cliente y servidor. Por el lado del router, no se lograba ejecutar el “kismet dron” de forma correcta. Se instalaron diferentes versiones del mismo hasta que se logr´oobtener una funcional. En cuanto a la PC, como se estaba trabajando sobre un Ubuntu 11.10 no se logr´oinstalar el servidor sobre esta versi´ondel sistema operativo por problemas de compatibilidad. Se intentaron resolver los errores que presentaba la instalaci´on,pero finalmente Cap´ıtulo6. Desarollo 58 se opt´opor actualizar la versi´onde Ubuntu a la 12.04. En esta versi´onde Ubuntu no se mani- festaron los problemas que se presentaban anteriormente, pero aparecieron otros. Finalmente se agreg´oel repositorio de kismet directamente al listado de Ubuntu y se logr´oinstalar de forma correcta el servidor y el cliente.

Luego de instalar la herramienta se investig´ola configuraci´onnecesaria para hacerla funcionar. Nos encontramos con el problema de que el dron no enviaba los datos al servidor, a pesar de estar todo configurado como indica la documentaci´on.Luego de probar diferentes configuraciones a partir de informaci´onextra´ıdade foros de usuariosse logr´ohacer que se env´ıen.

Se analiz´ola herramienta y se intent´ode alguna forma utilizar los datos que posee para nuestro inter´es,probando con obtener directamente a partir de los datos que env´ıael dron, leyendo los logs que genera el server, realizando plugins sobre la herramienta, utilizando otra herramienta (“kismon”) que lee informaci´ondel servidor (que result´oque no era lo que precis´abamos),pero no se logr´oobtener la informaci´ondeseada.

Tambi´ense investig´osu c´odigofuente para entender su funcionamiento y basarse en el mismo para desarrollar nuestra propia herramienta, pero el resultado no fue satisfactorio.

Finalmente se opt´opor utilizar tcpdump y realizar un parseo sobre su archivo de salida. M´as adelante se profundiza en este tema.

6.2. Implementaci´on

A continuaci´onse presenta el desarrollo realizado. El mismo ha sido construido en C/C++. Para el desarrollo se utiliz´oel libro “802.11ac: A Survival Guide” [133], el documento “Programing with Libpcap - Sniffing the network” [134], el art´ıculo“Plab: a packet capture and analysis architecture” [135] y los sitios sobre tcpdump y libpcap [136], [137], [138], [139], [140], [141], [142], [143], [144], [145], [146] y [147], sobre instalar y programar para OpenWRT [148], [149], [150], [151], [152] y [153], de scp [154], y [155], sobre manejo de se˜nales[156] y [157], de postgre [158], [159] y [160] y sobre 802.11 [161], [162] y [163], [164].

6.2.1. Idea general y arquitectura

La idea es disponer de uno o m´asrouters en modo monitor (los cuales llamaremos “monitores”) capturando todos los paquetes e informaci´ondel uso del aire que puedan obtener del medio. Estos routers cada cierto tiempo env´ıanlos datos al servidor, donde se procesan, se almacenan en una base de datos y se presentan en parte al usuario. En la figura 6.1 se puede apreciar la arquitectura del sistema. Cap´ıtulo6. Desarollo 59

Figura 6.1: Arquitectura del sistema desplegado.

Todos los datos obtenidos por los routers se procesan y se guardan en una base de datos, de forma de poder realizar cualquier consulta sobre la misma, cubriendo los diferentes intereses en cuanto a datos o estad´ısticasque puedan surgir por parte de los usuarios.

Se utiliz´oel lenguaje ingl´esen diferentes partes del c´odigoy en la base de datos para evitar inconvenientes al utilizar tildes o e˜nes.

6.2.2. Servidor

El servidor ejecuta sobre linux, se encarga de procesar los datos que los monitores env´ıan, guardarlos en la base de datos y mostrarlos al usuario. Tambi´eninteract´uacon el usuario para que el mismo pueda configurar diferentes par´ametros,navegar por la informaci´onque se presente y realizar ciertas consultas. En la figura 6.2 se puede ver el men´ude opciones que ofrece la pantalla principal.

Internamente el servidor posee dos hilos, un hilo principal que se encarga de la presentaci´on de la informaci´one interacci´oncon el usuario, y un hilo secundario que procesa la informaci´on recibida por los monitores y la guarda en la base de datos.

La herramienta toma su configuraci´ondesde archivo, y sus par´ametrosde configuraci´onson:

rutaDirCapturas: ruta donde estar´anlos directorios con las capturas. Cap´ıtulo6. Desarollo 60

Figura 6.2: Pantalla principal, selecci´onde acciones.

prefijoInfoDron: prefijo para saber si un archivo contiene la informaci´onde los paquetes que captur´oun monitor.

prefijoInfoScript: prefijo para saber si un archivo contiene la informaci´onque un monitor cens´odel uso del aire.

tiempoEntreLecturas: tiempo en segundos entre lecturas de archivos.

cantidadMaximaPaquetes: cantidad m´aximade paquetes que puede existir en un mismo archivo de captura.

Por el lado del hilo que procesa la informaci´on,el mismo es b´asicamente un parser que procesa los archivos enviados por los monitores y actualiza la base de datos. Para el parser se utiliza la biblioteca libpcap (sobre la cual se entrar´aen mayor detalle en la secci´onsiguiente). Los archivos de datos se organizan dentro del servidor de forma de diferenciar los enviados por cada router, los ya procesados y los que tuvieron alg´unproblema al ser procesados. Esto ´ultimo con la finalidad de disponder de datos con los que debuguear la herramienta, ya sea con el objetivo de arreglarla o de extenderla para que soporte el nuevo caso.

Para obtener mayor informaci´onen cada paquete se utiliza el header “radiotap”. El mismo es un header que se acopla a la trama de enlace y brinda informaci´onespec´ıfica del hardware, obtenida interactuando directamente con el controlador. Por esa raz´onla informaci´ona la que se puede acceder es muy dependiente del fabricante del hardware y del driver.

El servidor utiliza una base de datos relacional para guardar toda la informaci´oncapturada por los monitores. En la secci´onsiguiente se presentan los detalles de la base.

En el ap´endiceC se presenta la parte m´asrelevante del c´odigodel servidor. Cap´ıtulo6. Desarollo 61

Figura 6.3: Dise˜node la base de datos.

6.2.3. Base de datos

Respecto a la base de datos, se utiliz´oel manejador de base de datos “PostgreSQL v9.1” sobre un sistema operativo Ubuntu 12.04. Se cre´ouna base llamada wifi qos cuyo due˜noes un usuario sin privilegios, que es el que se utiliza para conectarse desde el servidor. Los pasos para realizar la instalaci´ony configuraci´onde la base se pueden encontrar en el ap´endiceB.

Se crearon las tablas “ReadingSamples” y “AirUsage” para almacenar la informaci´oncorres- pondiente a la captura de paquetes por parte de la interfaz de red en modo promiscuo y de las estad´ısticasde tiempos de uso del aire respectivamente. Tambi´ense cuenta con dos tablas extra (“ReadingSamples Hist” y “AirUsage Hist”) donde se guarda la informaci´onhist´oricacorres- pondiente a las tablas mencionadas anteriormente. Esto se realiz´oas´ıpara volcar hacia ellas la informaci´onque no sea actual, manteniendo todos los datos recabados en diferentes sesiones sin afectar el rendimiento del motor de la base sobre las tablas con datos actuales, que es donde se realizan las consultas que se muestran en la interfaz gr´afica.En la figura 6.3 se puede ver el dise˜node la base de datos.

La estructura de la tabla “ReadingSamples” es:

MonitorId: char(17) - MAC del nodo monitor. Cap´ıtulo6. Desarollo 62

TimeStamp: bigint - Timestamp con precisi´onen microsegundos de cuando la interfaz de red recibi´oel paquete.

SourceMAC: char(17) - MAC del emisor del mensaje.

DestinationMAC: char(17) - MAC del destinatario del mensaje.

Signal: smallint - Potencia de se˜nalmedida desde el nodo monitor.

Channel: smallint - Canal de la banda de 2.4 Ghz utilizado en el env´ıodel paquete.

PackageType: smallint - Tipo de paquete (puede ser administraci´on,control o datos).

PacketSubtype: smallint - Sub-tipo de paquete (los valores que puede tomar dependen del tipo).

SSID: char(32) - El SSID del AP con el cual se est´ainteractuando.

PacketSize: int - Tama˜nodel paquete en bytes.

La clave primaria de la tabla son los atributos MonitorId y TimeStamp.

La estructura de la tabla “AirUsage” es:

MonitorId: char(17) - MAC del nodo monitor.

TimeStamp: bigint - Tiempo con precisi´onen microsegundos de toma de los datos.

SamplingTime: int - Duraci´ondel muestreo en milisegundos.

BusyTime: int - Tiempo en que el medio estuvo ocupado en milisegundos (tiempo en que no pudo transmitir si hubiera querido).

UsageTime: int - Tiempo en que efectivamente estuvo recibiendo paquetes en milisegundos.

BusyRatio: float - Cociente entre BusyTime y SampleTime.

La clave primaria de la tabla son los atributos MonitorId y TimeStamp.

La biblioteca utilizada en el servidor para conectarse a la base es “libpqxx v4.0”.

6.2.4. Interfaz con el usuario

Mediante la interfaz, el usuario puede acceder a ciertos datos en pantalla, los cuales se calcu- lan en tiempo real y corresponden a los ´ultimossesenta minutos. Los mismos se presentan a continuaci´on.

Informaci´onb´asicade los APs discriminada por el par monitor y AP, la cual contiene: Cap´ıtulo6. Desarollo 63

Figura 6.4: Presentaci´onde datos de APs.

Monitor que capt´ola se˜nal.

SSID AP.

MAC AP.

Canal.

Se˜nalpromedio del AP.

Se˜nalm´aximadel AP.

Se˜nalm´ınimadel AP.

Desde all´ı, es posible entrar en mayor detalle sobre cada AP, donde se puede apreciar, separado por monitor que capt´olos paquetes, la siguiente informaci´on:

MAC Cliente.

Promedio, m´aximoy m´ınimode se˜nalenviado por cliente.

Cantidad de paquetes y cantidad de bytes enviados por cliente.

Promedio, m´aximoy m´ınimode se˜nalrecibido por cliente.

Cantidad de paquetes y cantidad de bytes recibidos por cliente.

Cantidad de clientes.

En las figuras 6.4y 6.5 pueden verse estos datos.

Tambi´enes posible acceder a la informaci´ondel uso del aire, donde se muestra la siguiente informaci´on:

Monitor que realiz´ola medici´on. Cap´ıtulo6. Desarollo 64

Figura 6.5: Informaci´onen profundidad de un AP.

Figura 6.6: Datos de uso del aire.

Duraci´ondel muestreo.

Tiempo ocupado.

Tiempo de uso.

Relaci´onde ocupaci´on.

Dicha informaci´onpuede verse en la figura 6.6.

El usuario puede ver y cambiar los datos de configuraci´ondel servidor en tiempo de ejecuci´on. Tambi´ense puede cambiar la ruta del archivo de configuraci´onde forma de tener diferentes configuraciones ya establecidas y poder cambiar entre ellas f´acilmente.

Adem´asde la informaci´onmencionada que el usuario puede visualizar a trav´esde la interfaz, la herramienta cuenta con un conjunto de consultas pre definidas que posiblemente sean atractivas para el usuario. Como se mencion´oanteriormente, cualquier usuario puede realizar sus propias consultas directamente sobre la base. Las que aqu´ıpresentamos fueron seleccionadas por su relevancia y utilidad. Las misas son:

Informaci´ongeneral de APs. Cap´ıtulo6. Desarollo 65

Figura 6.7: Consultas establecidas a la BD.

Uso de aire general.

Informaci´oncompleta por AP y monitor.

Mayor cantidad de paquetes.

Mayor cantidad de datos.

Uso del aire contra tipos de paquete capturados por minuto.

El detalle de las mismas se encuentra en el ap´endiceA y una captura de ellas puede verse en la figura 6.7.

6.2.5. Monitor

A la herramienta que ejecuta sobre el router la llamamos monitor (internamente tambi´ense le llam´odron). El monitor captura toda la informaci´ondel medio en modo promiscuo, toma ciertos valores internos del router y env´ıaesos datos al servidor.

Internamente el monitor inicia, carga la configuraci´on,invoca el script “macState.sh”, creado por el tutor Mat´ıasRichart, y comienza a capturar paquetes en modo promiscuo utilizando libpcap. Cada cierto tiempo env´ıalos archivos que genera al servidor. El script se puede ver en el ap´endiceC.

El script mencionado lee ciertos valores utilizando la herramienta “iw”, para finalmente escribir cada cierto tiempo en un archivo los valores de tiempo activo, tiempo ocupado, tiempo recibiendo y la relaci´onde ocupado sobre el total de la muestra en el propio nodo monitor (estos valores se corresponden con los mencionados anteriormente de la tabla AirUsage). Dado que el nodo monitor est´aen modo promiscuo, estos valores representan el estado del medio. Cap´ıtulo6. Desarollo 66

Libpcap es una biblioteca de C para captura y an´alisisde tr´afico.En este proyecto se la utiliza para capturar los paquetes y guardarlos a archivo en el monitor. Luego, tambi´ense la utiliza para levantar los archivos transferidos al servidor. Comenzar a utilizar libpcap puede resultar complejo, pero a la larga result´obeneficioso.

Los archivos son enviados al servidor utilizando scp. Se configuraron el servidor y los monitores con “ssh-keys” para que no sea necesario introducir credenciales para enviar los datos. Para esto se realizaron los siguientes pasos (ayudados por la herramienta dropbear):

Se genera una clave en el monitor.

dropbearkey -t rsa -f ~/.ssh/id_rsa

Se cambia el formato de la clave.

dropbearkey -y -f ~/.ssh/id_rsa | grep "^ssh-rsa" >> authorized_keys

Se agrega el “authorized keys” al “ /.ssh” del servidor.

Asegurarse que los permisos del archivo sean 600.

Al igual que el servidor, el monitor posee un archivo de configuraci´on,en el cual se pueden configurar los siguientes par´ametros:

rutaCapturas: ruta donde se dejar´anlos archivos a enviar.

prefijoCapturasPaquetes: prefijo de las capturas de paquetes.

prefijoCapturasMatias: prefijo de las capturas del script MacState.

rutaScript: ruta de ejecuci´ondel script MacState.

ipServidor: ip a donde mandar los archivos.

puertoServidor: puerto por donde mandar los archivos.

rutaServidor: ruta donde dejar los archivos en el servidor.

usuarioServidor: usuario en el servidor.

dispositivoID: identificador del dispositivo. Utilizamos la MAC.

refresco: tiempo m´aximo en segundo de timeout al inicializar la captura.

maxPaquetes: cantidad de paquetes m´aximacapturados por archivo. Cap´ıtulo6. Desarollo 67

Figura 6.8: Ejecuci´ondel monitor, inicio y configuraci´on.

Figura 6.9: Ejecuci´ondel monitor, env´ıode archivos.

maxMacState: cantidad de lecutras macState por archivo.

interfaz: interfaz donde se capturar´anpaquetes.

En las figuras 6.8y 6.9 se pueden ver dos capturas de la ejecuci´ondel monitor.

Existieron dificultades considerables para poder compilar el paquete del monitor para que fun- cione correctamente en el router. Se utiliz´oel SDK de OpenWRT para realizar la compilaci´on Cap´ıtulo6. Desarollo 68

Figura 6.10: Gr´aficade uso de CPU al ejecutar el monitor (libpcap) y tcpdump. cruzada en Ubuntu, dado que no se puede compilar directo en el router. Para realizar esta com- pilaci´onse debe configurar el SDK de forma correcta, ubicar los archivos a compilar en el lugar adecuado y realizar dos makefiles. Uno de ellos es el makefile com´unque se utiliza en cualquier programa de C/C++, y el otro es espec´ıficopara OpenWRT en el que se configuran diferentes par´ametrosdel paquete que se est´acompilando. Adem´as,se deben configurar las diferentes ca- beceras que se incluyan y utilicen en el c´odigo.Es importante tener en cuenta que las bibliotecas t´ıpicasusadas en cualquier programa en C/C++ son sustituidas por otras versiones reducidas de las mismas para que funcionen en OpenWRT. En el ap´endiceD se puede ver el paso a paso realizado en mayor detalle junto a los correspondientes makefiles.

En el ap´endiceC se presenta parte del c´odigodel monitor.

6.2.6. Comparaci´onlibpcap y tcpdump

Dado que en un comienzo se utiliz´otcpdump para obtener los datos y luego se pas´oa utilizar la biblioteca libpcap, se decidi´orealizar una comparaci´onde performance entre ambas soluciones. Para esto se utiliz´o“luci-app-statistics” y “collectd”.

Se realiz´oel mismo tipo de captura en ambas, midiendo uso de CPU y memoria RAM. Entre las 22:09 y 22:12 se ejecut´oel monitor (el cual realiza la captura con libpcap, ejecuta el script de uso del aire y env´ıalas capturas usando scp), y entre las 22:42 y 22:45 se ejecut´oun tcpdump junto al script de uso de aire y el env´ıode datos hacia el servidor. Los resultados obtenidos se presentan en las gr´aficas 6.10y 6.11.

El uso de CPU al utilizar tcpdump es inferior a la mitad que al ejecutar el monitor. En cuanto al uso de memoria RAM, la misma es similar en ambos casos. Hay que resaltar que el monitor obtiene m´asdatos que los que se obtienen con tcpdump, lo que ya de por s´ıjustifica su pre- ferencia, pero si adem´asconsideramos que el nodo monitor se utiliza de forma dedicada para monitorizar (valga la redundancia), resulta innecesario el ahorro de uso de CPU que aporta utilizar tcpdump. Cap´ıtulo6. Desarollo 69

Figura 6.11: Gr´aficade uso de memoria al ejecutar el monitor (libpcap) y tcpdump. Cap´ıtulo7

Evaluaci´on

7.1. Caso de estudio

Se han realizado estudios de diferentes estados del arte y se ha desarrollado una herramienta capaz de monitorizar exitosamente las redes inal´ambricas densas, de forma de brindar datos para comprender su funcionamiento y poder tomar decisiones en su planificaci´on.A continuaci´onse detallan las particularidades del caso de estudio.

7.1.1. Escenario de pruebas

En el Instituto de Computaci´onde la Facultad de Ingenier´ıa,se realiz´oel despliegue de los monitores. Se ubicaron 4 routers distribuidos en dos pisos. En la figura 7.1 se pueden ver los 4 routers. Los mismos monitorizaron todas las redes inal´ambricas existentes en el aire durante una semana.

El primero que se aprecia (de color rojo), en la sala 103, corresponde al monitor “sala de carrera”. A su derecha (de color amarillo), pegado a la sala 140, se encuentra el monitor “impresora planta baja”. En el siguiente piso, comenzando por la izquierda (de color azul), en el espacio libre que se encuentra al centro se ubica el monitor “impresora subsuelo”, y finalmente, a su derecha (de color verde), en la sala 036, se encuentra el monitor “sala grados 1”. De esta forma nos referiremos a los diferentes monitores de aqu´ıen adelante.

La disposici´onde los mismos estuvo condicionada al acceso que se pudo tener a las diferentes oficinas, as´ıcomo el acceso a la red el´ectricay de datos.

70 Cap´ıtulo7. Evaluaci´on 71

Figura 7.1: Plano del InCo con los monitores.

7.1.2. M´etricas de las capturas de datos

Se presentan diferentes m´etricassobre la captura de datos.

Cada monitor envi´oal servidor, en promedio, 4.700 capturas por d´ıa.

El tama˜nopromedio de cada captura fue de 285KB.

La cantidad promedio de paquetes por captura fue de 1.000.

La base de datos creci´o,en promedio, 4.14 GB por d´ıa.

La base de datos aument´o,en promedio, 19 millones de tuplas por d´ıa.

7.2. Procesamiento de los datos capturados

Tomando como conjunto de datos la informaci´oncapturada por los 4 monitores en el plazo de una semana, se realizaron los siguientes an´alisis.

7.2.1. An´alisismedio ocupado

Se presenta el an´alisisrealizado sobre el uso del medio. Se tomaron mediciones de “Busy Time” (tiempo en el cual la interfaz est´aocupada recibiendo cualquier tipo de datos) y “Recieve Time” Cap´ıtulo7. Evaluaci´on 72

Figura 7.2: Porcentaje de medio ocupado de sala de carrera - Lunes 15.

(tiempo en el cual la interfaz est´arecibiendo datos que logra interpretar). Por lo comentado anteriormente, es claro que el “Busy Time” incluye al “Recieve Time”.

Al encontrarse los monitores en modo promiscuo, los valores aqu´ıpresentados corresponden a la utilizaci´ondel medio (aire), por lo cual estos datos proporcionan informaci´onsobre la utilizaci´on del medio en s´ı.Se tom´oun d´ıacon nivel de uso representativo para mostrar la evoluci´ondel uso del aire en el correr del d´ıa.

Esta m´etricaresulta de especial inter´es,dado que refleja la oportunidad de transmitir que poseen los dispositivos. Si el medio se encuentra ocupado la mayor parte del tiempo los dispositivos tendr´anmenos oportunidad de transmitir.

En las figuras 7.2, 7.3, 7.4y 7.5 se pueden ver los porcentajes de “Busy Time” y “Recieve Time” durante todo un d´ıa(h´abil)agrupado cada una hora, de los 4 monitores. En estas gr´aficasse puede apreciar la diferencia de utilizaci´ondel medio en los diferentes monitores. Adem´ases posible observar como var´ıael uso de las redes a lo largo del d´ıa.Otra informaci´onrelevante que brinda este an´alisises la diferencia entre el “Busy Time” y el “Recieve Time” que se aprecia en las gr´aficas,donde la misma corresponde a las interferencias y/o colisiones ocurridas en ese lapso de tiempo.

En la figura 7.6 se presenta, en una misma gr´afica,los diferentes porcentajes de utilizaci´ondel medio, capturado por cada uno de los monitores. Cap´ıtulo7. Evaluaci´on 73

Figura 7.3: Porcentaje de medio ocupado de impresora subsuelo - Lunes 15.

Figura 7.4: Porcentaje de medio ocupado de sala grados 1 - Lunes 15.

Figura 7.5: Porcentaje de medio ocupado de impresora planta baja - Lunes 15. Cap´ıtulo7. Evaluaci´on 74

Figura 7.6: Porcentaje de utilizaci´ondel medio para los 4 monitores - Lunes 15.

7.2.2. Tipos de paquetes

En esta secci´onse presentan diferentes tablas donde se muestra la cantidad de paquetes de cada tipo y subtipo observados por cada uno de los monitores durante un d´ıatipo agrupados por AP (es decir, por cada punto de acceso que est´aprestando servicio). Con esto es posible apreciar los diferentes tipos de paquetes que son intercambiados en cada conjunto de servicio b´asico.

Estos datos se pueden ver en las tablas 7.2, 7.3, 7.4y 7.5. La tabla 7.1 muestra la relaci´onentre la MAC del AP y el identificador utilizado en el resto de las tablas.

A continuaci´onse presenta una breve descripci´onde cada sub-tipo de paquete que se en- contr´odurante la monitorizaci´on:

Association Request: enviado hacia un AP para asociarse al mismo (en caso de existir seguridad en la red, el cliente debe estar previamente autenticado).

Association Response: enviado por un AP en respuesta a un “Association Request”.

Reassociation Request: es similar a un “Association Request”, con la diferencia de que incluye la informaci´onsobre la actual asociaci´onque posea el cliente.

Reassociation Response: enviado por un AP en respuesta a un “Reassociation Request”.

Probe Request: se utiliza para buscar APs disponibles.

Probe Response: enviado por un AP en respuesta a un “Probe Request”.

Beacon: enviado peri´odicamente por un AP para anunciarse.

Disassociation: indica la finalizaci´onde una asociaci´on.

Authentication: se utiliza para la autenticaci´onde un cliente frente a un AP. Cap´ıtulo7. Evaluaci´on 75

MAC AP ID MAC AP ID

00:0f:02:12:58:50 AP 1 c0:4a:00:a4:6b:8d AP 9 90:f6:52:f5:d2:d0 AP 2 c0:4a:00:a4:6b:db AP 10 90:f6:52:f5:d7:1c AP 3 c2:4a:00:a4:57:e1 AP 11 92:f6:52:f5:d2:d0 AP 4 c2:4a:00:a4:6a:b5 AP 12 c0:4a:00:a4:57:e1 AP 5 c2:4a:00:a4:6b:5f AP 13 c0:4a:00:a4:6a:b5 AP 6 c2:4a:00:a4:6b:81 AP 14 c0:4a:00:a4:6b:5f AP 7 c2:4a:00:a4:6b:8d AP 15 c0:4a:00:a4:6b:81 AP 8 c2:4a:00:a4:6b:db AP 16

Tabla 7.1: Relaci´onMAC - Identificador de AP.

Deauthentication: indica que quien la recibe no est´amas autenticado.

PS-Poll: se utiliza en el modo de ahorro de energ´ıa.

RTS: utilizado para la coordinaci´ondel acceso al medio.

CTS: se utiliza en respuesta a un “RTS”.

ACK: utilizado para confirmar una recepci´on.

CF End: indica la finalizaci´onde un per´ıodo “CFP”. Se utiliza cuando el AP se encuentra en modo “PCF”.

Data: contiene datos.

De estos datos llama la atenci´on,dentro de los paquetes de tipo gesti´onla gran cantidad de “Beacons” que se env´ıan.En cuanto a los paquetes de tipo control, se destacan tanto los “RTS” como los “ACK”. En ambos tipos (gesti´ony control) se detectaron paquetes que se reconocen dentro de estas categor´ıas,pero no se logra detectar su subtipo. Espec´ıficamente, el valor del campo del paquete que representa el subtipo no es ninguno de los esperados en el est´andar 802.11.

La comparaci´onentre los diferentes tipos de paquetes (managment, control y data) se realiza m´asadelante. Cap´ıtulo7. Evaluaci´on 76

Tipo de paquete AP 3 AP 5 AP 7 AP 10 AP 11 AP 13 AP 16

Association Request 6 28 4 16 138 2 50 Association Response 0 168 0 57 221 0 21 Reassociation Request 14 0 0 1 53 7 12 Reassociation Response 0 0 0 2 77 0 4 Probe Request 27 0 1 3197 440 69 47 Probe Response 2 18623 0 0 25378 0 2159 Beacon 29 763488 0 88244 751055 5 84534 Disassociation 0 22 0 5 337 8 11 Authentication 64 503 25 119 744 16 94 Deauthentication 11 178 1 82 941 5 57 Managment Desconocido 30 180 9 74 7218 14 181

Desconocido Control 209 150 7 77 55278 20 423 PS-Poll 133 0 1 0 1462 57 656 RTS 146 4136 0 244 63537 120 3149 CTS 737 119 26 38 5996 443 669 ACK 367 3538 217 791 39770 547 1083 CF End 0 0 0 0 6229 0 0

Data 2036 1035 26 299 2208140 849 183398

Tabla 7.2: Cantidad de tipos de paquete de sala carrera. Cap´ıtulo7. Evaluaci´on 77

Tipo de paquete AP 1 AP 7 AP 8 AP 9 AP 10 AP 13 AP 14 AP 15 AP 16

Association Request 0 109 103 88 98 1 6 18 7 Association Response 0 73 151 159 133 14 38 50 99 Reassociation Request 0 0 0 7 2 0 4 11 6 Reassociation Response 0 0 0 7 3 7 10 16 12 Probe Request 4761 0 0 0 0 0 3 38 11 Probe Response 527437 4240 8857 16841 6493 6708 12536 27142 6401 Beacon 0 324445 516248 544314 467671 334583 497816 538824 460166 Disassociation 0 1 21 2 8 19 27 43 19 Authentication 0 322 536 334 310 35 73 255 130 Deauthentication 0 102 136 194 149 55 222 257 120 Managment Desconocido 19 156 341 284 253 3844 5105 3965 982

Desconocido Control 12 152 223 244 212 60 13621 2565 255 PS-Poll 0 0 0 0 0 0 58 1 3802 RTS 0 354 1173 3176 423 4555 19488 4735 19206 CTS 0 233 296 141 186 23 772 250 4076 ACK 1790 1347 3096 5248 3088 1895 12516 31643 1630 CF End 6 0 0 0 0 0 0 30 11

Data 2121 2375 2510 4054 1990 423052 803120 1236543 521654

Tabla 7.3: Cantidad de tipos de paquete de impresora subsuelo. Cap´ıtulo7. Evaluaci´on 78

Tipo de paquete AP 6 AP 7 AP 8 AP 9 AP 12 AP 13 AP 14 AP 15

Association Request 10 54 19 22 3 0 8 4 Association Response 0 0 250 209 0 0 75 61 Reassociation Request 0 0 0 0 0 0 5 3 Reassociation Response 0 0 1 7 0 0 18 28 Probe Request 0 0 0 0 19 2 6 10 Probe Response 11 5 16538 18469 10 3 23771 30727 Beacon 2312 724 663900 584351 2155 649 654269 575506 Disassociation 0 0 17 0 3 1 56 50 Authentication 6 73 582 375 7 0 135 334 Deauthentication 0 0 281 279 0 0 313 336 Managment Desconocido 4 63 376 266 338 3 8287 3088

Desconocido Control 4 54 196 193 7161 2 0 173 PS-Poll 0 0 0 0 0 0 667 0 RTS 0 0 1948 689 2788 9 27674 4564 CTS 49 114 15 14 5137 48 577 128 ACK 598 766 1698 1373 10624 172 18385 916 CF End 0 0 0 0 0 0 0 0

Data 340 498 1201 2692 6278 80 1483315 1485105

Tabla 7.4: Cantidad de tipos de paquete de sala grados 1.

Tipo de paquete AP 2 AP 4 AP 5 AP 6 AP 7 AP 8 AP 11 AP 12 AP 13 AP 14

Association Request 0 0 0 0 4 2 4 7 11 2 Association Response 2 12 0 10 129 198 93 62 22 39 Reassociation Request 0 0 84 0 0 0 7 11 9 3 Reassociation Response 0 9 0 1 0 1 17 33 12 13 Probe Request 0 1 0 0 1 0 10 23 21 1 Probe Response 2061 5548 3892 4837 10610 8065 4912 18795 13189 12515 Beacon 92484 87408 203876 545526 548186 522082 194154 536074 550038 495735 Disassociation 5 19 1 17 71 141 19 33 Authentication 14 19 180 15 390 446 126 248 50 71 Deauthentication 4 42 93 23 191 194 227 431 117 168 Managment Desconocido 4 1023 59 11 106 238 1197 3349 4577 5067

Desconocido Control 31 62 40 10 77 115 282 50513 10544 12550 PS-Poll 0 0 0 0 1 0 86 3283 339 198 RTS 127 12594 1715 400 634 1403 8717 25285 7932 21812 CTS 4 45 1 3 8 10 472 4318 1078 585 ACK 12 82 46 1049 842 533 379 35402 4013 6392 CF End 0 0 0 0 0 0 0 0 0 0

Data 229 143239 110 117 743 172 376271 901458 784917 783961

Tabla 7.5: Cantidad de tipos de paquete de impresora planta baja. Cap´ıtulo7. Evaluaci´on 79

7.2.3. Clientes que m´aspaquetes y volumen de datos enviaron

En la tabla 7.6 se pueden ver las MACs de los 5 clientes que enviaron mayor cantidad de paquetes durante un d´ıa,separado por monitor. Luego se presenta, en la tabla 7.7, informaci´onsimilar, pero esta vez sobre los 5 clientes que enviaron mayor cantidad de tr´aficoese mismo d´ıa.

Sala carrera Cliente Cantidad de paquetes Bytes

Desconocido 91004 3640160 58:94:6b:9c:8c:48 35783 9318451 70:1a:04:a1:82:25 26132 3144990 08:ed:b9:9a:1d:9b 25064 4186225 d3:54:95:07:4a:00 24290 971600 Impresora subsuelo Cliente Cantidad de paquetes Bytes

5f:00:62:30:6b:8d 29912 1196480 Desconocido 23766 950640 18:1e:b0:ab:db:a0 17805 1489025 00:18:e7:02:cb:11 14484 1448801 2b:03:97:3c:cb:11 10365 414600 Sala grados 1 Cliente Cantidad de paquetes Bytes

Desconocido 23126 925142 74:4c:d4:39:4a:00 14455 578200 b8:ee:65:43:7f:db 12763 707870 19:da:cc:0e:6b:81 11565 462600 19:da:cc:0e:6b:8d 11278 451120 Impresora planta baja Cliente Cantidad de paquetes Bytes

Desconocido 43907 1756382 3c:cb:7c:32:67:5b 34633 4423040 80:89:7b:01:6a:b5 17608 704320 b8:ee:65:43:7f:db 10019 841568 19:da:cc:0e:6b:81 7372 294880

Tabla 7.6: Top 5 de clientes que m´aspaquetes enviaron en un d´ıa. Cap´ıtulo7. Evaluaci´on 80

Sala carrera Cliente Cantidad de paquetes Bytes

58:94:6b:9c:8c:48 35783 9318451 08:ed:b9:9a:1d:9b 25064 4186225 Desconocido 91004 3640160 70:1a:04:a1:82:25 26132 3144990 a4:9a:58:12:25:34 22736 1772603 Impresora subsuelo Cliente Cantidad de paquetes Bytes

58:94:6b:9c:8c:48 35783 9318451 08:ed:b9:9a:1d:9b 25064 4186225 Desconocido 91004 3640160 70:1a:04:a1:82:25 26132 3144990 a4:9a:58:12:25:34 22736 1772603 Sala grados 1 Cliente Cantidad de paquetes Bytes

58:94:6b:9c:8c:48 9568 1393258 c0:18:85:7e:94:ad 6849 1128613 Desconocido 23126 925142 24:fd:52:f5:e0:04 5574 894128 b8:ee:65:43:7f:db 12763 707870 Impresora planta baja Cliente Cantidad de paquetes Bytes

3c:cb:7c:32:67:5b 34633 4423040 Desconocido 43907 1756382 b8:ee:65:43:7f:db 10019 841568 80:89:7b:01:6a:b5 17608 704320 6c:b7:f4:9e:c2:ca 4716 351137

Tabla 7.7: Top 5 de clientes que m´asdatos transfirieron en un d´ıa. Cap´ıtulo7. Evaluaci´on 81

Como se puede apreciar, en todas las tablas existe una fila para la cual no se conoce la MAC de origen del paquete, ya que la misma estaba vac´ıa.Este resultado gener´ointer´espor saber de que tipo de tr´aficose trataba, por lo cual se analiz´oel mismo en mayor profundidad. De la especificaci´on,se sabe que los paquetes “Clear To Send” son los ´unicosque no poseen MAC origen. Analizando estos datos en profundidad, efectivamente se comprob´oque los mismos co- rresponden a paquetes CTS, de los cuales alrededor de 23.000 tienen como destino a alg´unAP, y aproximadamente 154.000 poseen como destino a alg´uncliente (se detectaron en total 75 des- tinos diferentes). Esto indica claramente el overhead que este protocolo est´agenerando sobre la red.

7.2.4. Cantidad de paquetes y tr´aficodurante una semana

En esta secci´onse presentan gr´aficascomparativas de los 3 diferentes tipos de paquetes existentes durante toda una semana (desde el Martes 09 hasta el Martes 16), medidos por cada monitor. Se tienen dos gr´aficaspor cada uno, comparando as´ıcantidad de paquetes y tr´aficogenerado.

En las gr´aficas 7.7y 7.8 se ve la informaci´onrelativa a la sala de carrera. Se aprecia claramente la utilizaci´onde la red a lo largo del d´ıa(con gran uso entre las 08 y las 20) y la baja de utilizaci´onel fin de semana. En particular, el d´ıa 11, alrededor de las 19 horas, existi´oun pico de paquetes de control. Se investigaron los subtipos, tama˜nos,or´ıgenesy destinos de estos paquetes en la ventana de tiempo que va desde las 18 hasta las 21. En la tabla 7.8 se presentan los datos relevantes, donde se puede apreciar el alto n´umerode paquetes RTS y CTS, lo cual destaca frente a la cantidad de estos paquetes durante el resto de la semana. Tambi´ense presenta una gran cantidad de paquetes de control con subtipo desconocido. En cuanto a los or´ıgenesy destinos de estos paquetes, no se encontraron datos relevantes.

Subtipo Cantidad de paquetes Cantidad total en KB

Desconocido 218107 12353 RTS 253909 11406 CTS 236663 9244 ACK 252463 9861

Tabla 7.8: An´alisisparticular de subtipos de paquete en sala carrera de las 18 a las 21. Cap´ıtulo7. Evaluaci´on 82

Figura 7.7: Comparaci´onde cantidad de paquetes de cada tipo durante una semana en sala de carrera.

Figura 7.8: Comparaci´onde tr´aficode cada tipo de paquete durante una semana en sala de carrera.

En las gr´aficas 7.9y 7.10 se ve la informaci´onrelativa a la impresora subsuelo. Se aprecian 3 intervalos donde no se tienen datos, que corresponden a un error ocurrido en este monitor. Por razones que se desconocen, la interfaz de red dejaba de funcionar correctamente y no capturaba paquetes. Se investig´oy se busc´oinformaci´onrelacionada al problema pero no se logr´odetectar las causas del mismo, ni se obtuvo informaci´onde un problema similar al que se pudiera vincular. Se opt´opor no repetir la toma de datos, ya que se dispon´ıa de la semana completa en otros monitores, y para las comparaciones utilizando los cuatro monitores se utilizaron muestras diarias completas. Cap´ıtulo7. Evaluaci´on 83

Figura 7.9: Comparaci´onde cantidad de paquetes de cada tipo durante una semana en im- presora subuselo.

Figura 7.10: Comparaci´onde tr´afico de cada tipo de paquete durante una semana en impresora subuselo.

En las gr´aficas 7.11y 7.12 se v´ela informaci´onrelativa a la sala grados 1. La gr´aficaes similar a la de sala de carrera, con una mayor cantidad de paquetes y volumen de tr´afico. Cap´ıtulo7. Evaluaci´on 84

Figura 7.11: Comparaci´onde cantidad de paquetes de cada tipo durante una semana en sala grados 1.

Figura 7.12: Comparaci´onde tr´aficode cada tipo de paquete durante una semana en sala grados 1.

En las gr´aficas 7.13y 7.14 se ve la informaci´onrelativa a la impresora planta baja. De la misma forma que en la impresora subuselo, en este monitor se tienen dos cortes en la toma de datos por la misma raz´on.Se destacan en estas gr´aficasla alta cantidad de paquetes managment en comparaci´oncon los paquetes data. Cap´ıtulo7. Evaluaci´on 85

Figura 7.13: Comparaci´onde cantidad de paquetes de cada tipo durante una semana en impresora planta baja.

Figura 7.14: Comparaci´onde tr´afico de cada tipo de paquete durante una semana en impresora planta baja.

7.2.5. Comparaci´onde cantidad de paquetes y transferencia semanal

En la gr´afica 7.15 se presenta la comparaci´onsemanal de la cantidad de paquetes detectada por cada monitor. En la gr´afica 7.16 se realiza esta misma comparaci´onpor tr´afico.

Se aprecia que en los valles los monitores de las impresoras poseen una actividad mayor que los otros dos, mientras que en las crestas esta diferencia se hace menor, alcanzando la igualdad en algunos momentos. Cap´ıtulo7. Evaluaci´on 86 Comparaci´onde cantidad de paquetes capturada por cada monitor. Figura 7.15: Cap´ıtulo7. Evaluaci´on 87 Comparaci´onde cantidad de tr´aficocapturado por cada monitor. Figura 7.16: Cap´ıtulo7. Evaluaci´on 88

7.2.6. Medici´onde se˜nal

Se analiz´oel comportamiento de la se˜naldurante un d´ıa,tomando las mediciones capturadas por un monitor que se encontraba al lado de un AP, y teniendo en cuenta solo aquellos paquetes dirigidos hacia el AP. En las figuras 7.17y 7.18 se pueden ver los resultados.

El pico que se aprecia en ambas gr´aficaspuede deberse a que al menos un cliente se aproxim´oal AP monitorizado, aumentando la intensidad de la se˜nalregistrada por el monitor. Se entiende que esto es as´ıya que es com´unutilizar WiFi en los celulares, la hora del pico coincide con la hora que arranca la jornada y el AP se encuentra al lado de unas sillas de espera.

Figura 7.17: Comportamiento de la se˜nala lo largo del d´ıaen un AP de la red INCO.

Figura 7.18: Comportamiento de la se˜nala lo largo del d´ıaen un AP de la red Wifing. Cap´ıtulo7. Evaluaci´on 89

7.2.7. Comparaci´onde tipos en cada monitor

En la figura 7.19 se presentan 4 gr´aficasde tipo torta donde se muestra la relaci´onentre la can- tidad de paquetes de los 3 tipos existentes para cada monitor durante la semana. Resalta el bajo porcentaje de paquetes de datos en comparaci´oncon los otros dos. M´asa´un,el alto porcentaje de paquetes managament muestra la burocracia a la que se enfrentan las redes inal´ambricas 802.11 para poder funcionar. Sin embargo, este resultado no es del todo representativo, ya que la muestra tomada incluye las noches y el fin de semana, cuando la cantidad de datos desciende considerablemente. Por lo tanto, se realizaron gr´aficassimilares tomando como muestra una hora (correspondiente al lunes 15 entre las 15:00 y las 16:00). Estos resultados se presentan en la figura 7.20, donde se aprecia el predominio de los paquetes de datos frente al resto.

En la figura 7.21 se presentan 4 gr´aficas similares a las anteriores, comparando por volumen de tr´aficoen lugar de cantidad de paquetes. Destaca el alto tr´aficogenerado por los paquetes de

Figura 7.19: Relaci´onsemanal entre cantidad de paquetes de cada tipo por monitor. Cap´ıtulo7. Evaluaci´on 90

Figura 7.20: Relaci´onen una hora entre cantidad de paquetes de cada tipo por monitor. tipo managment frente a los de tipo data, donde se esperaba que se “emparejaran” un poco las proporciones con respecto a la cantidad de paquetes, dado que los paquetes de tipo management tienen tama˜nofijo y los de tipo data pueden ser m´asgrandes. De forma similar a las gr´aficas del punto anterior, se analiz´oel volumen de tr´aficoen el mismo rango horario. Los resultados se presentan en la figura 7.22.

Este resultado Cap´ıtulo7. Evaluaci´on 91

Figura 7.21: Relaci´onsemanal entre tr´aficode cada tipo de paquetes por monitor. Cap´ıtulo7. Evaluaci´on 92

Figura 7.22: Relaci´onen una hora entre cantidad de paquetes de cada tipo por monitor. Cap´ıtulo7. Evaluaci´on 93

7.2.8. Cantidad de dispositivos registrados

Se presenta en esta secci´onla cantidad de dispositivos registrados por los monitores durante una semana y durante un d´ıa.Se registra cualquier dispositivo que env´ıey/o reciba paquetes hacia o desde un AP. Por ejemplo, si un dispositivo env´ıaun “Probe Request” hacia un AP, entonces es registrado.

En la figura 7.23 se presenta la cantidad semanal, donde se tomaron intervalos de 6 horas para cada valor. Estos datos corresponden a lo registrado por los monitores en todo el InCo y sus alrededores.

En la figura 7.24 se presenta la cantidad diaria, donde se tomaron intervalos de 1 hora para cada valor.

Figura 7.23: Cantidad de dispositivos totales en intervalos de 6 horas durante una semana.

Figura 7.24: Cantidad de dispositivos totales en intervalos de 1 hora durante un d´ıa. Cap´ıtulo7. Evaluaci´on 94

Como era de esperar, en las noches y durante todo el fin de semana, la cantidad de dispositivos se reduce considerablemente.

A ra´ızde los altos valores observados se realiz´oun an´alisis en profundidad para el mayor pico registrado (jueves 11 de 15:00 a 21:00). Se obtuvieron por separado las MACs de los dispositivos que enviaron paquetes al AP de aquellas a las que el AP les envi´opaquetes, resultando en un total de 999 dispositivos que enviaron y 2060 que recibieron. Cruzando estos resultados se desprende que los que mantuvieron una interacci´onbilateral son 85. Por otra parte, del total de dispositivos que enviaron paquetes, 843 transmitieron m´asde 50, mientras que para el caso de los dispositivos que recibieron paquetes este valor fue de 1357. Esto indica que una tercera parte de los dispositivos detectados en el pico no alcanzaron a enviar ni recibir 50 paquetes en un lapso de 6 horas.

7.2.9. Tr´aficosin AP origen ni destino

En esta secci´onse analiza el tr´aficoque no posee como origen ni destino a un AP. Para identificar los APs existentes se buscaron los or´ıgenesde los paquetes de tipo beacons. Por lo tanto, si un AP no env´ıabeacons, no ser´aconsiderado como AP. Ser´ıaposible realizar un an´alisisen mayor profundidad, buscando el origen de otros paquetes que sean enviados espec´ıficamente por los APs para refinar esta lista, pero no se hizo de esa manera porque en la infraestructura de la red del InCo todos los APs env´ıanbeacons.

En un lapso de una semana, se encontraron 3.716.462 paquetes que entran en esta categor´ıa. Dentro de estos, se distinguen 12.813 parejas distintas de origen y destino. En la tabla 7.9 se puede ver c´omofueron variando estos paquetes por d´ıa.Destaca la gran cantidad de paquetes de control.

7.2.10. Comparaci´onentre tr´aficoenviado y recibido por los APs

Se realiz´ouna comparaci´onentre todo el tr´afico enviado y recibido por los APs. En la figura 7.25 se realiza esta comparaci´onpor cantidad de paquetes, mientras que en la figura 7.26 se realiza por tr´afico.

Como era de esperarse, el tr´aficoque se origina en los APs es ampliamente superior al generado desde los clientes. En el caso de los paquetes de control, es pr´acticamente la mitad para los APs y la mitad para los clientes. Cap´ıtulo7. Evaluaci´on 95

09/06 10/06 11/06 12/06 13/06 14/06 15/06

Association Request 13 45 3 3 50 28 0 Reassociation Request 2 1 10 3 0 0 0 Probe Request 19737 70188 80516 5678 28528 167371 0 Probe Response 18463 55 852 286 168 289 161 Disassociation 4 4 25 0 0 0 0 Authentication 85 13 41 18 4 332 74 Deauthentication 30 0 0 0 0 0 0 Desconocido 10 81 72 45 1259 70 0 PS-Poll 72 155 2 0 0 0 0 RTS 351080 55 0 0 0 0 0 CTS 61526 306851 122186 8652 2363 154030 121869 ACK 217473 3305 288094 356886 109150 548148 478334 CF End 142 299 8 83 34 0 0 Data 452 549 1178 421 252 36826 1246

Tabla 7.9: Evoluci´onsemanal de paquetes sin intervenci´onde APs.

Figura 7.25: Comparaci´onde cantidad de paquetes semanales enviados y recibidos por todos los APs. Cap´ıtulo7. Evaluaci´on 96

Figura 7.26: Comparaci´onde tr´aficosemanal enviado y recibido por todos los APs.

7.2.11. Conclusiones de la evaluaci´on

El an´alisisrealizado, si bien abarca diferentes aspectos de la realidad de las redes en el InCo, no es exhaustivo. Podr´ıainvestigarse en mayor profundidad, de forma de ampliar la informaci´on obtenida, pero dicho an´alisisexcede el alcance de este proyecto. Cap´ıtulo8

Conclusiones y trabajo a futuro

En este cap´ıtulose detallan las conclusiones obtenidas como resultado del proyecto, en las que se incluyen los resultados respecto a los objetivos planteados al comienzo y los puntos m´as importantes que surgieron a lo largo del mismo, y el trabajo futuro, en el que se detallan los puntos que por alguna raz´onno se pudo completar y aquellas oportunidades de mejora que se detectaron una vez finalizado el desarrollo.

8.1. Conclusiones

8.1.1. Investigaci´on

Una gran parte del proyecto consisti´oen la investigaci´ondel estado del arte de las ´areasde inter´es realacionadas a la tem´aticadel proyecto, entre las cuales se incluyen los hardware de routers inal´ambricos, los firmware de c´odigoabierto para los mismos, los lenguajes de programaci´on para sistemas embebidos y las arquitecturas de monitorizaci´on.

A su vez, se estudiaron como marco te´oricoel funcionamiento de las redes inal´ambricas en general, la familia de redes 802.11 y su funcionamiento, los problemas caracter´ısticosdel uso de las mismas, los posibles indicadores de calidad a utilizar, los detalles del hardware (tanto para aquellos disponibles como los ´ultimosmodelos de los fabricantes m´asrelevantes) y las herramientas existentes en materia de monitorizaci´onde redes inal´ambricas.

El an´alisisde la informaci´onrecabada permiti´otomar las decisiones pertinentes para comenzar el desarrollo de la herramienta de monitorizaci´on.Si bien en algunos casos las decisiones fueron condicionadas por limitantes existentes, como en los casos del hardware y la disponibilidad del mismo en el grupo de investigaci´onMINA o de los indicadores de calidad a utilizar y la capacidad del hardware y/o el software de obtener esos indicadores, en la amplia mayor´ıade los

97 Cap´ıtulo8. Conclusiones y trabajo a futuro 98 casos las decisiones se desprenden del resultado de la investigaci´onrealizada, como en la elecci´on del firmware, del lenguaje de programaci´ona utilizar o de la arquitectura de monitorizaci´on.

Y aunque de cierta parte de la investigaci´onno se desprenda ninguna decisi´onque defina el desa- rrollo de la herramienta, el estudio realizado result´ofundamental para el desarrollo de la misma. En particular, el conocimiento adquirido de las herramientas existentes permiti´oseleccionar las caracter´ısticasdeseables a implementar en nuestra herramienta, mientras que el dominio del funcionamiento de la familia de redes 802.11 y los detalles de su trama facilitaron enormemente la implementaci´ona bajo nivel del parser de las capturas.

A modo de recapitulaci´on,las decisiones que se desprenden de la investigaci´onrealizada son:

La utilizaci´onde OpenWRT como firmware, dado que es el ´unicoque ofrece un file system, tiene buena documentaci´ony gran apoyo de su comunidad, se utiliza frecuentemente dentro del grupo de investigaci´on,y es abierto, gratuito y compatible con el hardware disponible.

La utilizaci´onde C/C++ como lenguaje de programaci´onpara desarrollar la herramienta de monitorizaci´on,siendo que es un lenguaje con el que se posee experiencia, es compatible con el firmware, permite un alto control del hardware y ofrece independencia frente al procesador sobre el que vaya a ejecutar el programa.

La utilizaci´onde una arquitectura centralizada para implementar la herramienta de mo- nitorizaci´on,ya que se deseaba disponer de toda la informaci´onen una misma base de datos, no era relevante la toma de decisiones sobre acciones a ejecutar por parte de los nodos monitores y era la opci´onm´assencilla que cumpl´ıalos requisitos.

8.1.2. Desarrollo

El desarrollo de la herramienta de monitorizaci´onrepresenta la parte central de los objetivos de este proyecto, y el ´exitode la misma al ser desplegada en el ambiente de producci´ondel InCo, logrando obtener informaci´onrelevante de las redes inal´ambricas monitorizadas, indica que se cumpli´oel objetivo. Con la herramienta desarrollada es posible realizar an´alisisde redes inal´ambricas densas, obtener informaci´onrelevante para la planificaci´onde las mismas, e incluso analizar el comportamiento del protocolo 802.11.

Adicionalmente, el hecho de haber completado el an´alisisde los datos obtenidos durante el despliegue, detectando problemas y particularidades a mejorar de las redes, centrando el foco en la planificaci´ony en la mejora de la calidad del servicio, es una prueba de la utilidad de la herramienta. El ejemplo de uso de la herramienta para conocer y entender el comportamiento de una red inal´ambrica densa y detectar problemas respalda la afirmaci´onde que se cumpli´ocon el objetivo. Cap´ıtulo8. Conclusiones y trabajo a futuro 99

En otro orden, es importante destacar que entre los objetivos iniciales se encontraba el de desa- rrollar metodolog´ıasque permitan evaluar las soluciones propuestas, pero el mismo se cambi´oen el transcurso del proyecto por el caso de estudio consistente en el despliegue de la herramienta desarrollada en la red productiva del InCo, y el posterior an´alisisde los datos obtenidos. Resulta claro por lo descrito en los p´arrafosanteriores que este objetivo tambi´en fue cumplido.

8.2. Trabajo a futuro

Dado que en la base de datos se guarda todo lo capturado, ante una ejecuci´onprolongada, o sucesivas ejecuciones, se puede generar una gran cantidad de tuplas. Por lo tanto, ser´ıaintere- sante poder reducir la misma sin perder informaci´onque pueda resultar ´utilni restar velocidad a las consultas que se ejecuten. El hecho de mantener un volumen de datos acotado se ataca, en parte, con la migraci´ona las tablas hist´oricas,lo cual permite tener valores “en vivo” sobre una tabla acotada haciendo que no se pierda velocidad en el acceso a esos datos. Sin embargo, este enfoque no soluciona el problema de fondo, ya que la tabla hist´oricapasa a ser la que padece el problema, y las consultas que no se ejecuten sobre los “en vivo” mantienen la penalizaci´onde performance de ejecutar en una tabla excesivamente poblada.

Se podr´ıaatacar esta problem´aticade otra forma: en lugar de mover los datos a otras tablas, podr´ıanser compactados de forma que ocupen menos espacio. Este compactamiento se podr´ıa llevar adelante identificando paquetes iguales o muy similares existentes en la base, donde, en lugar de tenerlos duplicados, se los podr´ıajuntar de cierta forma reduciendo la cantidad de paquetes. En la misma l´ınea,podr´ıarealizarse manualmente un hashing de las direcciones MAC registradas, provocando que las tuplas que contienen los datos de las capturas pasen de almacenar tres strings de 17 caracteres a almacenar tres identificadores num´ericos,reduciendo significativamente el espacio requerido para almacenar cada tupla. Este´ enfoque no s´olopresenta una mejora en cuanto al espacio de almacenamiento, sino que adem´asmejora la performance de las consutlas ejecutadas sobre esta tabla, dado que el manejador debe realizar una cantidad significativamente menor de lecturas de bloques de disco para recorrer la tabla, ahorr´andose accesos al componente m´aslento del servidor (ya que se trata del ´unicocomponente mec´anico).

La interfaz desarrollada es sencilla y ´agil,no est´apensada para ser una interfaz de usuario completa. Por lo tanto, el tama˜noque ocupa la misma no est´apensada para resoluciones de pantalla peque˜nas.Esto ocurre por la necesidad de mostrar los diferentes resultados de las consultas en tablas que sean agradables a la vista y permitan una buena lectura de la informaci´on presentada. Podr´ıamejorarse la herramienta con una interfaz que logre adaptarse al tama˜no de la consola donde se est´eejecutando. Tambi´encabe la posibilidad de mantener la interfaz en consola como se encuentra actualmente y realizar una aplicaci´oncliente con su propia interfaz que consuma los datos. No se entr´oen detalle sobre este aspecto, dado que uno de los objetivos Listado de figuras 100 fundamentales del proyecto era la toma de datos y no as´ıla presentaci´onde los mismos. A su vez, la interfaz se desarroll´ocomo un prototipo para visualizar los resultados, por lo que no est´apreparada para desplegar en pantalla ni mantener la capacidad de interacci´oncon la gran cantidad de datos a los que se enfrentar´ıaen una red de gran tama˜noo al uso de m´asnodos monitores. Para ello es necesario cambiar la forma en la que se agrupa la informaci´ona la hora de ser mostrada, y la forma en la que se interact´ua con la aplicaci´on.

Otro posible aspecto a atacar es la performance de las consultas que se realizan sobre la base de datos desde la herramienta. Podr´ıan estudiarse las mismas en profundidad para intentar optimizarlas, reduciendo el tiempo de ejecuci´ony en consecuencia el tiempo de espera del usuario.

Al procesar y manejar una cantidad de informaci´onimportante, ser´ıaposible realizar t´ecnicas de Big Data sobre los datos que se tienen para realizar an´alisism´aspotentes.

Ser´ıainteresante ejecutar el sistema en un ambiente donde se cuente con m´asnodos monitores (que a su vez requerir´ıa un servidor central con m´asrecursos computacionales), recabando as´ımayor informaci´onde la red o redes que se est´enmonitoreando. Tambi´enpodr´ıarealizarse la medici´ondurante un tiempo mayor al realizado, disponiendo de estad´ısticasm´asfieles, se dispondr´ıade un muestreo m´asgrande y en consecuencia m´asrepresentativo de la realidad.

Podr´ıaser de utilidad integrar el sistema con alg´unmecanismo de toma de decisiones sobre la red, utilizando la informaci´onrecabada, proces´andolay decidiendo realizar ciertos cambios sobre la red. De este modo podr´ıalograrse que la red se adapte a los cambios en cuanto al uso a los que se somete a lo largo del tiempo. Listado de figuras

2.1. Escenario t´ıpicode una red inal´ambrica...... 5 2.2. Arquitectura de una red IEEE 802.11...... 8 2.3. Solapamiento de los 11 canales...... 8 2.4. Terminal oculto por desvanecimiento de se˜nal...... 11 2.5. Terminal oculto por obst´aculo...... 12 2.6. Evitaci´onde colisiones usando RTS y CTS...... 13 2.7. Trama 802.11...... 14

3.1. RouterBoard 133 vista superior e inferior...... 17 3.2. RouterBoard 133 diagrama...... 17 3.3. RouterBoard R52...... 19 3.4. TP-Link TL-WDR4300...... 21

4.1. Sistema embebido gen´erico...... 33

5.1. Merkai - Informaci´onpor canales...... 50 5.2. Merkai - An´alisisde espectro en vivo...... 51

6.1. Arquitectura del sistema desplegado...... 59 6.2. Pantalla principal, selecci´onde acciones...... 60 6.3. Dise˜node la base de datos...... 61 6.4. Presentaci´onde datos de APs...... 63 6.5. Informaci´onen profundidad de un AP...... 64 6.6. Datos de uso del aire...... 64 6.7. Consultas establecidas a la BD...... 65 6.8. Ejecuci´ondel monitor, inicio y configuraci´on...... 67 6.9. Ejecuci´ondel monitor, env´ıode archivos...... 67 6.10. Gr´aficade uso de CPU al ejecutar el monitor (libpcap) y tcpdump...... 68 6.11. Gr´aficade uso de memoria al ejecutar el monitor (libpcap) y tcpdump...... 69

7.1. Plano del InCo con los monitores...... 71 7.2. Porcentaje de medio ocupado de sala de carrera - Lunes 15...... 72 7.3. Porcentaje de medio ocupado de impresora subsuelo - Lunes 15...... 73 7.4. Porcentaje de medio ocupado de sala grados 1 - Lunes 15...... 73 7.5. Porcentaje de medio ocupado de impresora planta baja - Lunes 15...... 73 7.6. Porcentaje de utilizaci´ondel medio para los 4 monitores - Lunes 15...... 74 7.7. Comparaci´onde cantidad de paquetes de cada tipo durante una semana en sala de carrera...... 82

101 Listado de figuras 102

7.8. Comparaci´onde tr´aficode cada tipo de paquete durante una semana en sala de carrera...... 82 7.9. Comparaci´onde cantidad de paquetes de cada tipo durante una semana en im- presora subuselo...... 83 7.10. Comparaci´onde tr´aficode cada tipo de paquete durante una semana en impresora subuselo...... 83 7.11. Comparaci´onde cantidad de paquetes de cada tipo durante una semana en sala grados 1...... 84 7.12. Comparaci´onde tr´aficode cada tipo de paquete durante una semana en sala grados 1...... 84 7.13. Comparaci´onde cantidad de paquetes de cada tipo durante una semana en im- presora planta baja...... 85 7.14. Comparaci´onde tr´aficode cada tipo de paquete durante una semana en impresora planta baja...... 85 7.15. Comparaci´onde cantidad de paquetes capturada por cada monitor...... 86 7.16. Comparaci´onde tr´aficocapturado por cada monitor...... 87 7.17. Comportamiento de la se˜nala lo largo del d´ıaen un AP de la red INCO..... 88 7.18. Comportamiento de la se˜nala lo largo del d´ıaen un AP de la red Wifing.... 88 7.19. Relaci´onsemanal entre cantidad de paquetes de cada tipo por monitor...... 89 7.20. Relaci´onen una hora entre cantidad de paquetes de cada tipo por monitor.... 90 7.21. Relaci´onsemanal entre tr´aficode cada tipo de paquetes por monitor...... 91 7.22. Relaci´onen una hora entre cantidad de paquetes de cada tipo por monitor.... 92 7.23. Cantidad de dispositivos totales en intervalos de 6 horas durante una semana.. 93 7.24. Cantidad de dispositivos totales en intervalos de 1 hora durante un d´ıa...... 93 7.25. Comparaci´onde cantidad de paquetes semanales enviados y recibidos por todos los APs...... 95 7.26. Comparaci´onde tr´aficosemanal enviado y recibido por todos los APs...... 96 Listado de tablas

2.1. Clasificaci´onde los tipos de redes...... 6 2.2. Caracter´ısticasest´andares802.11 a/b/g/n...... 7

3.1. Caracter´ısiticasdel RouterBoard 133...... 18 3.2. Caracter´ısiticasdel RouterBoard R52...... 19 3.3. Modos soportado por la tarjeta RouterBoard R52...... 20 3.4. Caracter´ısiticasdel TP-Link TL-WDR4300...... 21

4.1. Caracter´ısticasdiferentes hardware Qualcomm...... 25 4.2. Caracter´ısticasdiferentes hardware Intel...... 25 4.3. Caracter´ısticasdiferentes hardware Broadcom...... 25 4.4. Rangos de valores t´ıpicosde requerimientos de dise˜no...... 34 4.5. Clasificaci´onde los lenguajes...... 37

7.1. Relaci´onMAC - Identificador de AP...... 75 7.2. Cantidad de tipos de paquete de sala carrera...... 76 7.3. Cantidad de tipos de paquete de impresora subsuelo...... 77 7.4. Cantidad de tipos de paquete de sala grados 1...... 78 7.5. Cantidad de tipos de paquete de impresora planta baja...... 78 7.6. Top 5 de clientes que m´aspaquetes enviaron en un d´ıa...... 79 7.7. Top 5 de clientes que m´asdatos transfirieron en un d´ıa...... 80 7.8. An´alisisparticular de subtipos de paquete en sala carrera de las 18 a las 21... 81 7.9. Evoluci´onsemanal de paquetes sin intervenci´onde APs...... 95

103 Ap´endiceA

Uso de la herramienta

A.1. Consideraciones para que la herramienta funcione correc- tamente

Para el monitor se debe tener en cuenta que:

Se prob´oen la versi´on12.09 Attitud Adjustment de OpenWRT.

Opkg debe estar disponible.

El script macState.sh debe encontrarse en la ruta configurada.

El archivo dron.conf debe encontrarse en donde se vaya a ejecutar la herramienta y debe estar configurado correctamente.

El router debe permitir el modo promiscuo y el mismo debe estar habilitado en la interfaz que se vaya a utilizar.

Libpcap debe estar instalado.

Libstdcpp debe estar instalado.

El router debe tener conectividad con el servidor.

La key para ssh debe estar configurada en el servidor.

Antes de comenzar a ejecutar el monitor, dar de baja y volver a levantar la interfaz donde se vaya a capturar (aunque ya estuviese configurada en modo monitor).

Para el servidor se debe tener en cuenta que:

104 Ap´endiceA. Uso de la herramienta 105

La base de datos debe estar instalada y la estructura esperada debe estar armada.

El archivo de configuraci´ondebe estar en el mismo lugar que el servidor y debe estar configurado correctamente.

Debe haber un servidor ssh corriendo.

Se debe tener creada las carpetas donde cada monitor mueva sus archivos (incluyendo la carpeta procesados y errores).

A.2. Funcionamiento de la herramienta

El uso de la herramienta no presenta mucha dificultad, una vez se est´eseguro de que se cumplen los puntos de la secci´onanterior, se debe instalar el dron.opkg en los routers, levantar el servidor, y ejecutar los monitores. La recepci´ony procesamiento de datos comenzar´a.

La ejecuci´ondel monitor es sencilla, ya que simplemente se ejecuta sin tener que hacer nada m´as.En el servidor, en cambio, se tiene un men´ucon diferentes opciones, las cuales son bastante intuitivas, utilizando los n´umerosy letras del teclado se va accediendo a las diferentes opciones.

Las consultas pre-hechas que se encuentran en la herramienta son:

Informaci´ongeneral de APs: retorna, agrupado por AP y monitor, informaci´onde cada AP (SSID, MAC, Canal y se˜nales).

Uso de aire general: retorna, agrupado por monitor, las estad´ısticascompletas de uso del aire.

Informaci´oncompleta por AP y monitor: retorna la cantidad de paquete de cada combi- naci´onde tipo y subtipo que pasan por cada AP (tanto entrantes como salientes) seg´un lo que captur´ocada monitor y el total de bytes que circularon de ese tipo por ese AP.

Mayor cantidad de paquetes: retorna los 10 clientes que m´aspaquetes hayan enviado en la red, indicando tambi´enel tama˜nodel total enviado por cada uno de ellos.

Mayor cantidad de datos: retorna los 10 clientes que hayan enviado mayor cantidad de datos en la red, indicando tambi´enla cantidad de paquetes enviados por cada uno de ellos.

Uso del aire contra tipos de paquete capturados por minuto: retorna las estad´ısticasde uso del aire de cada monitor agrupadas por minuto junto a los tipos de paquetes que se transfirieron en ese mismo intervalo. Ap´endiceB

Base de datos

B.1. Pasos para instalar y configurar la base de datos

Se instal´oel motor.

sudo apt-get install postgresql-9.1

Se cambi´oel password del usuario “postgres” y se cre´oun nuevo usuario “pgmonitoreo”.

Para conectarse a la base mediante psql se utiliz´o.

psql -h localhost -d wifi_qos -U pgmonitoreo

B.2. Script para generar las tablas

El siguiente script genera las tablas necesarias para el funcionamiento de la herramienta:

CREATE TABLE ReadingSamples( MonitorId CHAR(17) NOT NULL, TimeStamp BIGINT NOT NULL, SourceMAC CHAR(17) NOT NULL, DestinationMAC CHAR(17) NOT NULL, Signal SMALLINT NOT NULL, Channel SMALLINT NOT NULL, PacketType SMALLINT NOT NULL, PacketSubtype SMALLINT NOT NULL, SSID CHAR(32),

106 Ap´endiceB. Base de datos 107

PacketSize INT NOT NULL, PRIMARY KEY( MonitorId, TimeStamp ) );

CREATE TABLE AirUsage( MonitorId CHAR(17) NOT NULL, TimeStamp BIGINT NOT NULL, SamplingTime INT NOT NULL, BusyTime INT NOT NULL, RecieveTime INT NOT NULL, BusyRatio FLOAT NOT NULL, PRIMARY KEY( MonitorId, TimeStamp ) );

CREATE TABLE ReadingSamples_Hist( MonitorId CHAR(17) NOT NULL, TimeStamp BIGINT NOT NULL, SourceMAC CHAR(17) NOT NULL, DestinationMAC CHAR(17) NOT NULL, Signal SMALLINT NOT NULL, Channel SMALLINT NOT NULL, PacketType SMALLINT NOT NULL, PacketSubtype SMALLINT NOT NULL, SSID CHAR(32), PacketSize INT NOT NULL, PRIMARY KEY( MonitorId, TimeStamp ) );

CREATE TABLE AirUsage_Hist( MonitorId CHAR(17) NOT NULL, TimeStamp BIGINT NOT NULL, SamplingTime INT NOT NULL, BusyTime INT NOT NULL, RecieveTime INT NOT NULL, BusyRatio FLOAT NOT NULL, PRIMARY KEY( MonitorId, TimeStamp ) ); Ap´endiceC

C´odigo

C.1. Script macState.sh

#!/bin/ash #Recibe como par´ametros #nombre de archivo - ruta donde guardarlo - cantidad de lecturas por paquete iw wlan0 survey dump > /tmp/tmpDump activeOld=‘cat /tmp/tmpDump | awk ’{if ($4 == "[in") {getline;getline; print $4}} ’‘ busyOld=‘cat /tmp/tmpDump | awk ’{if ($4 == "[in") {getline;getline;getline; print $4}} ’‘ rxOld=‘cat /tmp/tmpDump | awk ’{if ($4 == "[in" {getline;getline;getline;getline; print $4}} ’‘ txOld=‘cat /tmp/tmpDump | awk ’{if ($4 == "[in") {getline;getline;getline;getline;getline; print $4}} ’‘ initTime=$activeOld #estas variables son para el tema de escribir un nuevo archivo cada cierto # tiempo nuevo=0 tope=$3 contador=0 archivo="$2/script$1$contador.csv" contador=‘expr $contador + 1‘ temporal="procesando" while true do

108 Ap´endiceC. C´odigo 109

sleep 1 iw wlan0 survey dump > /tmp/tmpDump activeNew=‘cat /tmp/tmpDump | awk ’{if ($4 == "[in") {getline;getline; print $4}}’‘ busyNew=‘cat /tmp/tmpDump | awk ’{if ($4 == "[in" ) {getline;getline;getline; print $4}}’‘ rxNew=‘cat /tmp/tmpDump | awk ’{if ($4 == "[in") {getline;getline;getline;getline; print $4}}’‘ txNew=‘cat /tmp/tmpDump | awk ’{if ($4 == "[in") {getline;getline;getline;getline;getline; print $4}}’‘ active=‘expr $activeNew - $activeOld‘ time=‘date +’%s’‘ tx=‘expr $txNew - $txOld‘ rx=‘expr $rxNew - $rxOld‘ busy=‘expr $busyNew - $busyOld‘ idle=‘expr $active - $busy - $tx‘ busyRatio=‘echo "scale=4; ($busy-$tx)/($active-$tx)" | bc -l‘ # echo $time $active $busy $rx $tx $busyRatio # time = Tiempo con precisi´onen milisegundos de toma de los datos. # active = duraci´onde la muestra # busy = duraci´onocupado en la muestra # (tiempo en que no pudo transmitir si hubiera querido, medio ocupado) # rx = duraci´onque estuvo recibiendo paquetes que fue procesado # tx = 0 # busyRatio = porcentaje de ocupado echo "$time,$active,$busy,$rx,$tx,$busyRatio" >> $temporal activeOld=$activeNew busyOld=$busyNew rxOld=$rxNew txOld=$txNew nuevo=‘expr $nuevo + 1‘ if [ $nuevo == $tope ] then mv "$temporal" "$archivo" nuevo=0 archivo="$2/script$1$contador.csv" contador=‘expr $contador + 1‘ fi done Ap´endiceC. C´odigo 110

C.2. Servidor

Se presentan las principales partes del c´odigoque ejecuta en el servidor.

Guardado de datos en la base.

// Funci´oninvocada por hilo secundario, se encarga de actualizar los datos // en la BD void* FuncionHilo(void*) { try { while(continuar) { sleep(tiempoEntreLecturas); // Se accede a la carpeta rutaDirCapturas vector ficheros = vector(); if (GetDir(rutaDirCapturas,ficheros) != -1) { for (int i = 0;i < ficheros.size();i++) { // Se entra en cada directorio en busca de los archivos vector lecturas = vector(); // Se abre cada una de las carpetas if ((ficheros[i] != ".") && (ficheros[i] != "..") && GetDir(rutaDirCapturas + "/" + ficheros[i],lecturas) != -1) { for (int j = 0;j < lecturas.size();j++) { // se revisa cada uno de los ficheros para ver si son capturas // y si son se procesa if(lecturas[j].find(prefijoInfoDron) == 0) { // Como es dron se abre el archivo y se procesa //ifstream infoDron; string archivoCaptura = rutaDirCapturas + "/" + ficheros[i] + "/" + lecturas[j]; unsigned int size = (97 + sizeof(int)*5 + sizeof(long long int)) * 2 * cantidadMaximaPaquetes; Ap´endiceC. C´odigo 111

char* res = (char*) malloc(size * sizeof(char)); memset(res, ’\0’, size);

if(!parse((char*) archivoCaptura.c_str(), res, 0)) { string captura = res; list > caps; while(!captura.empty()) { string lineaCompleta; // Se obtiene la linea de una captura int inicio = captura.find("#"); captura = captura.substr(inicio+1); int fin = captura.find("#"); // SI fin es -1 es xq no hay mas capturas q la actual if (fin == -1) { fin = captura.length(); lineaCompleta = captura.substr(0, fin); captura = ""; } else { lineaCompleta = captura.substr(0, fin); captura = captura.substr(fin); } // Los valores q se obtiene al separar por coma son los // q se inserta en la BD stringstream linea(lineaCompleta); string aux; string monitor = ficheros[i]; // TS getline(linea, aux, ’,’); string timestamp = aux; // Origen getline(linea, aux, ’,’); string origen = aux; // Destino getline(linea, aux, ’,’); Ap´endiceC. C´odigo 112

string destino = aux; // Se~nal getline(linea, aux, ’,’); string signal = aux; // Canal getline(linea, aux, ’,’); string channel = aux; // Tipo getline(linea, aux, ’,’); string type = aux; // Sub Tipo getline(linea, aux, ’,’); string subtype = aux; // SSID getline(linea, aux, ’,’); string ssid = aux; // PacketSize getline(linea, aux, ’,’); string packetSize = aux; vector capturaIndividual; capturaIndividual.push_back(monitor); capturaIndividual.push_back(timestamp); capturaIndividual.push_back(origen); capturaIndividual.push_back(destino); capturaIndividual.push_back(signal); capturaIndividual.push_back(channel); capturaIndividual.push_back(type); capturaIndividual.push_back(subtype); capturaIndividual.push_back(ssid); capturaIndividual.push_back(packetSize) ; caps.push_back(capturaIndividual); } // Se inserta en la BD la captura entera string res = Insert80211Packets(caps); if(res != "OK") { cout << "No ha sido posible insertar un paquete en la BD: " << res << endl; // Se mueve el archivo procesado a "/errores" Ap´endiceC. C´odigo 113

ifstream src(archivoCaptura.c_str(), std::ios::binary); string destino = rutaDirCapturas + "/" + ficheros[i] + "/errores/" + lecturas[j]; ofstream dst(destino.c_str(), std::ios::binary); dst << src.rdbuf(); } else { // Se mueve el archivo procesado a "/procesados" ifstream src(archivoCaptura.c_str(), std::ios::binary); string destino = rutaDirCapturas + "/" + ficheros[i] + "/procesados/" + lecturas[j]; ofstream dst(destino.c_str(), std::ios::binary); dst << src.rdbuf(); } remove(archivoCaptura.c_str()); } else { // Se mueve el archivo procesado a "/errores" ifstream src(archivoCaptura.c_str(), std::ios::binary); string destino = rutaDirCapturas + "/" + ficheros[i] + "/errores/" + lecturas[j]; ofstream dst(destino.c_str(), std::ios::binary); dst << src.rdbuf(); remove(archivoCaptura.c_str()); cout << "Error al querer leer una captura de un monitor, el archivo " << lecturas[j] << " ha sido movido a /errores" << endl; } // Se libera lo reservado para el res del parser free(res); } else if (lecturas[j].find(prefijoInfoScript) == 0) { // Como es script se abre el archivo y se procesa ifstream infoScript; string archivoCaptura = rutaDirCapturas + "/" + ficheros[i] + "/" + lecturas[j]; Ap´endiceC. C´odigo 114

infoScript.open(archivoCaptura.c_str()); // Si se abre correctamente if (infoScript.is_open()) { string lineaCompleta; list > airLines; // Se procesa el archivo por linea while(getline(infoScript, lineaCompleta)) { stringstream linea(lineaCompleta); if (lineaCompleta.length() != 0) { // Split por comas string aux; // Monitor string monitor = ficheros[i]; // TS //MonitorId,TimeStamp,SamplingTime,BusyTime, //RecieveTime,BusyRatio getline(linea, aux, ’,’); // Se le agrega 3 ceros para matchear la precision de // los paquetes de las capturas string timestamp = aux + "000000"; // SamplingTime getline(linea, aux, ’,’); string samplingTime = aux; // BusyTime getline(linea, aux, ’,’); string busyTime = aux; // RecieveTime getline(linea, aux, ’,’); string recieveTime = aux; // TX NO importa!, es 0 xq esta en modo promiscuo getline(linea, aux, ’,’); // BusyRatio getline(linea, aux, ’,’); string busyRatio = aux;

// Se agrega a las l´ıneasde airusage Ap´endiceC. C´odigo 115

vector airIndividual; airIndividual.push_back(monitor); airIndividual.push_back(timestamp); airIndividual.push_back(samplingTime); airIndividual.push_back(busyTime); airIndividual.push_back(recieveTime); airIndividual.push_back(busyRatio); airLines.push_back(airIndividual); } } // Se inserta en la BD la captura entera string res = InsertAirSamples(airLines); if(res != "OK") { cout << "No ha sido posible insertar un paquete en la BD: " << res << endl; // Se mueve el archivo procesado a "/errores" ifstream src(archivoCaptura.c_str(), std::ios::binary); string destino = rutaDirCapturas + "/" + ficheros[i] + "/errores/" + lecturas[j]; ofstream dst(destino.c_str(), std::ios::binary); dst << src.rdbuf(); } else { // Se mueve el archivo procesado a "/procesados" ifstream src(archivoCaptura.c_str(), std::ios::binary); string destino = rutaDirCapturas + "/" + ficheros[i] + "/procesados/" + lecturas[j]; ofstream dst(destino.c_str(), std::ios::binary); dst << src.rdbuf(); } remove(archivoCaptura.c_str()); } else { // Se mueve el archivo procesado a "/errores" ifstream src(archivoCaptura.c_str(), std::ios::binary); string destino = rutaDirCapturas + "/" + ficheros[i] Ap´endiceC. C´odigo 116

+ "/errores/" + lecturas[j]; ofstream dst(destino.c_str(), std::ios::binary); dst << src.rdbuf(); remove(archivoCaptura.c_str()); cout << "Error al querer leer una captura de un script, el archivo " << lecturas[j] << " ha sido movido a /errores" << endl; } } } } } } else cout << "Error al querer leer la informaci´onde los drones" << endl; } } catch (int e) { cout << textoError << " C´odigoHilo" << e << endl; } }

Parseo de captura “.pcap”.

// Procesamiento de una captura resultado de la extracci´onde datos // Bandera de debug, si est´aen 1 imprime lo q va tomando int parse(char* infile, char* res, int debug) { pcap_t *pcap_handle_in; char pcap_errbuf[PCAP_ERRBUF_SIZE]; const u_char *pcap_packet; struct pcap_pkthdr *pcap_header; struct bpf_program pcap_filter; // open infile pcap_handle_in = pcap_open_offline(infile, pcap_errbuf); if (pcap_handle_in == NULL) { fprintf(stderr, "No ha sido posible abrir el archivo: %s\n", pcap_errbuf); return 2; Ap´endiceC. C´odigo 117

} int fallido = 0; while (pcap_next_ex(pcap_handle_in, &pcap_header, &pcap_packet) > 0) { // se obtiene el timestamp del paquete capturado long long int seconds = pcap_header->ts.tv_sec; long long int microseconds = pcap_header->ts.tv_usec; int packetSize = pcap_header->len; if(debug) printf("\nPaquete capturado a las %lld,%lld.\n", seconds, microseconds); // se referencia el header de radiotap segun el comienzo del cuerpo // del paquete pcap struct ieee80211_radiotap_header *buf = (struct ieee80211_radiotap_header*) pcap_packet; int buflen = buf->it_len; if(debug) printf("Largo del header 802.11_radiotap = %d\n", buflen); // movida de parseo del radiotap header pro int channel = 0; char signal = ’0’; struct ieee80211_radiotap_iterator iterator; // inicializo el iterador int ret = ieee80211_radiotap_iterator_init(&iterator, buf, buflen, NULL); while (ret == 0) { // avanzo al siguiente parametro del header de radiotap ret = ieee80211_radiotap_iterator_next(&iterator); if (ret != 0) continue; //see if this argument is something we can use switch (iterator.this_arg_index) { case IEEE80211_RADIOTAP_DBM_ANTSIGNAL :{ signal = (*iterator.this_arg); if(debug) printf("se~nal= %d\n", signal); break;} case IEEE80211_RADIOTAP_RX_FLAGS: if (*iterator.this_arg & 0x0001) { fallido = 1; if(debug) Ap´endiceC. C´odigo 118

printf("Paquete fallido\n"); } break; case IEEE80211_RADIOTAP_CHANNEL:{ char* frequency = iterator.this_arg; // contine dos valores de 16 bits. en el 1ero esta la // frecuencia, y en el 2do las flags. int fH = frequency[1]*256; // leemos la frecuencia en little endian y armamos el valor int fL = frequency[0]&0xff; channel = GetChannel(fH+fL); if(debug) printf("Canal = %d\n", channel); // convertimos la frecuencia en el canal correspondiente } break; default: break; } } // while mas rt headers if (ret != -ENOENT){ if(debug) printf("-1\n"); } // fin movida pro con radiotap // se controla que el paquete procesado no haya fallado if (fallido){ fallido = 0; continue; } // arrancamos a procesar el paquete 802.11 ninja style char* paquete80211 = (char *) buf; paquete80211 += buflen; // obtenemos el tipo y el subtipo int type = (paquete80211[0] & 0x0f) >> 2; int subtype = ((paquete80211[0] & 0xf0) >> 4); if(debug) printf("Tipo = %d\nSubtipo = %d\n", type, subtype); // variables para obtener source y destination MACs Ap´endiceC. C´odigo 119

char flags = paquete80211[1] & 0x03; unsigned char dest[6]; unsigned char destination[18]; unsigned char src[6]; unsigned char source[18] = "\0"; // se extraen los 6 bytes que contienen la MAC de destino, y se le da // el formato apropiado memcpy(dest, &paquete80211[4], 6); snprintf(destination, 18,"%02x:%02x:%02x:%02x:%02x:%02x", dest[0], dest[1], dest[2], dest[3], dest[4], dest[5]); if(debug) printf("Destination Address: %s\n", destination); // se controla que el paquete no sea CTS, porque en ese caso no // trae MAC de origen if (type != 0x01 || subtype != 0x0c){ // se extraen los 6 bytes que contienen la MAC de origen, y se le da // el formato apropiado memcpy(src, &paquete80211[10], 6); snprintf(source, 18,"%02x:%02x:%02x:%02x:%02x:%02x", src[0], src[1], src[2], src[3], src[4], src[5]); if(debug) printf("Source Address: %s\n", source); } // se captura el SSID del lan management frame unsigned char ssid[33] = "\0"; if (type == 0x00 && subtype == 0x08){ // salto los 24 bytes del header MAC y los 12 de los params fijos del // header char * mngmntHdr = &paquete80211[36]; // copio el SSID a mi variable segun el largo declarado en el header memcpy(ssid, &mngmntHdr[2], mngmntHdr[1]); if(debug) printf("SSID: %s\n", ssid); } // controla que no se cuelen paquetes fallidos if (channel > 0 && signal <= 0){ strcat(res, "#"); char strAux[100]; sprintf(strAux, "%lld", seconds*1000000 + microseconds); Ap´endiceC. C´odigo 120

strcat(res, strAux); strcat(res, ","); strcat(res, source); strcat(res, ","); strcat(res, destination); strcat(res, ","); sprintf(strAux, "%d", signal); strcat(res, strAux); strcat(res, ","); sprintf(strAux, "%d", channel); strcat(res, strAux); strcat(res, ","); sprintf(strAux, "%d", type); strcat(res, strAux); strcat(res, ","); sprintf(strAux, "%d", subtype); strcat(res, strAux); strcat(res, ","); strcat(res, ssid); strcat(res, ","); sprintf(strAux, "%d", packetSize); strcat(res, strAux); } } pcap_close(pcap_handle_in); return 0; }

C.3. Monitor

Se presentan las principales partes del c´odigoque ejecuta en los nodos monitores.

Captura de paquetes: bool inicializarCaptura() { try { Ap´endiceC. C´odigo 121

// Si se quiere tomar una por defecto ser´ıaesto // dev = pcap_lookupdev(lpcapErrbuf); // Se inicia la captura, en la interfaz configurada, modo promiscuo y // con un timeout dado if (!(lpcapCaptura = pcap_open_live(lpcapDevice, BUFSIZ, 1, refresco*1000, lpcapErrbuf))) { return false; } else { pcap_set_datalink(lpcapCaptura, DLT_IEEE802_11_RADIO); // La parte de archivo hay que hacerla cada vez return true; } } catch (int e) { cout << textoError << e << endl; return false; } } bool capturar() { try { // Se arma el nombre del archivo del archivo time_t marcaTiempo = time(0); stringstream temp; temp << marcaTiempo; string nombreTemp = rutaCapturas + "/" + prefijoCapturasPaquetes + "_" + temp.str() + ".pcap"; strcpy(lpcapArchivo, nombreTemp.c_str()); // Se setea el DUMP al archivo indicado if ((lpcapDump = pcap_dump_open(lpcapCaptura, lpcapArchivo)) == NULL) { return false; } Ap´endiceC. C´odigo 122

// Lee HASTA maxPaquetes, pero si hay menos luego del timeout, retorna // con menos pcap_loop(lpcapCaptura, maxPaquetes, pcap_dump, (unsigned char *)lpcapDump); pcap_dump_close(lpcapDump); return true; } catch (int e) { cout << textoError << e << endl; return false; } }

Env´ıode datos al servidor:

// Env´ıalos archivos que haya en la carpeta especificada con las capturas // a enviar bool EnviarDatos() { try { // Cantidad de capturas que se enviaron en este intento de enviar // (NO es global, el global es cantCapturasEnviadas) int cantEnviar = 0; // Se abre la carpeta donde se tienen las capturas vector ficheros = vector(); if (GetDir(rutaCapturas,ficheros) != -1) { // Se recorre lo que haya for (int i = 0;i < ficheros.size();i++) { // Se buscan archivos que cumplan el prefijo if((ficheros[i].find(prefijoCapturasPaquetes) == 0) || (ficheros[i].find(prefijoCapturasMatias) == 0)) { cantEnviar++; // Se obtiene la info del archivo a enviar string rutaArchivo = rutaCapturas + "/" + ficheros[i]; Ap´endiceC. C´odigo 123

// Se env´ıael archivo usando scp y las calls a system string scp = "scp " + rutaArchivo + " " + usuarioServidor + "@" + ipServidor + ":" + rutaServidor + "/" + dispositivoID + " -i ~/.ssh/id_rsa"; system(scp.c_str()); // TIENEN QUE ESTAR LAS CARPETAS REMOTAS ANTES!!! // Se borra el fichero remove(rutaArchivo.c_str()); cantCapturasEnviadas++; } } // Para poner la hora de env´ıo time_t tiempo = time(0); tm * ptm = localtime(&tiempo); char buffer[32]; strftime(buffer, 32, "%m/%d/%Y %H:%M:%S", ptm); if (cantEnviar == 1) cout << "Se envi´oun archivo al servidor - " << buffer << endl; else if (cantEnviar > 1) cout << "Se enviaron " << cantEnviar << " archivos al servidor - " << buffer << endl; else cout << "No se enviaron archivos al servidor - " << buffer<< endl; } return true; } catch (int e) { cout << textoError << e << endl; return false; } } Ap´endiceD

Compilaci´onpara OpenWRT

D.1. Paso a paso para la compilaci´oncruzada para OpenWRT

Teniendo el c´odigofuente del paquete a compilar se deben realizar los siguientes pasos:

Crear un directorio base con el nombre del paquete.

Dentro del directorio se debe crear un subdirectorio “src” donde se colocar´ael c´odigo fuente.

Crear un Makefile com´unpara compilar ese c´odigo(como el de la secci´onsiguiente).

En el Makefile en lugar de utilizar “gcc” o “g++” se debe utilizar una variable que tenga el compilador, “$(CC)” o “$(CXX)”, esto es importante para la compilaci´oncon OpenWRT, ya que no se cuenta con los compiladores est´andares.

Poner el Makefile creado en la carpeta src y compilar para asegurarse de que todo est´ebien.

Descargar (si no se tiene ya) el SDK de OpenWRT, el SDK var´ıaseg´unla arquitectura del equipo que se est´eusando para hacer la compilaci´oncruzada, la arquitectura del router donde se vaya a instalar y ejecutar el paquete y la versi´onde OpenWRT que se est´eusando.

Luego de descargar, extraer lo descargado y mover el directorio que se cre´oen el primer paso hacia la carpeta “package” de OpenWRT.

Se debe crear un nuevo Makefile dentro del directorio movido en el punto anterior. Este Makefile es especial para realizar la compilaci´oncruzada. En la ´ultimasecci´onde este ap´endicese presenta el Makefile de este tipo realizado, el cual se puede tomar como ejemplo para relizar otros Makefiles (se basa en el presentado en el art´ıculo[148]).

Es importante utilizar tabulador y no espacios para formatear este Makefile. 124 Ap´endiceD. Compilaci´onpara OpenWRT 125

Finalmente se debe ir a la carpeta ra´ızdel SDK descargado y ejecutar “make”.

Si todo sali´ocorrectamente, dentro del directorio “bin/packages” se encuentra el paquete compilado.

D.2. Makefile com´un dron: dron.o $(CXX) $(LDFLAGS) dron.o -o dron -lpcap dron.o: dron.cpp $(CXX) $(CXXFLAGS) -c dron.cpp -lpcap

#borrar clear: rm -rf *.o dron

D.3. Makefile OpenWRT

Se recalca nuevamente que para dar el formato al Makefile se debe utilizar tabulador y no espacios. Este Makefile se basa en el Makefile presentado en [148].

############################################## # OpenWrt Makefile para el monitor # # # Most of the variables used here are defined in # the include directives below. We just need to # specify a basic description of the package, # where to build our program, where to find # the source files, and where to install the # compiled program on the router. # # Be very careful of spacing in this file. # Indents should be tabs, not spaces, and # there should be no trailing whitespace in # lines that are not commented. Ap´endiceD. Compilaci´onpara OpenWRT 126

# ############################################## include $(TOPDIR)/rules.mk

# Name and release number of this package PKG_NAME:=dron PKG_RELEASE:=1

# This specifies the directory where we’re going to build the program. # The root build directory, $(BUILD_DIR), is by default the build_mipsel # directory in your OpenWrt SDK directory PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME) include $(INCLUDE_DIR)/package.mk

# Specify package information for this program. # The variables defined here should be self explanatory. define Package/dron SECTION:=utils CATEGORY:=Utilities TITLE:=dron -- Proyecto de Grado - FING - UdelaR DEPENDS:=+libstdcpp +libpcap # DESCRIPTION:=\ # If you can’t figure out what this program does, \\\ # you’re probably brain-dead and need immediate \\\ # medical attention. endef define Package/dron/description endef

# Specify what needs to be done to prepare for building the package. # In our case, we need to copy the source files to the build directory. # This is NOT the default. The default uses the PKG_SOURCE_URL and the # PKG_SOURCE which is not defined here to download the source from the web. # In order to just build a simple program that we have just written, it is # much easier to do it this way. Ap´endiceD. Compilaci´onpara OpenWRT 127 define Build/Prepare mkdir -p $(PKG_BUILD_DIR) $(CP) ./src/* $(PKG_BUILD_DIR)/ endef

# We do not need to define Build/Configure or Build/Compile directives # The defaults are appropriate for compiling a simple program such as this one

# Specify where and how to install the program. Since we only have one file, # the helloworld executable, install it by copying it to the /bin directory on # the router. The $(1) variable represents the root directory on the router running # OpenWrt. The $(INSTALL_DIR) variable contains a command to prepare the install # directory if it does not already exist. Likewise $(INSTALL_BIN) contains the # command to copy the binary file from its current location (in our case the build # directory) to the install directory. define Package/dron/install $(INSTALL_DIR) $(1)/bin $(INSTALL_BIN) $(PKG_BUILD_DIR)/dron $(1)/bin/ endef

# This line executes the necessary commands to compile our program. # The above define directives specify all the information needed, but this # line calls BuildPackage which in turn actually uses this information to # build a package. $(eval $(call BuildPackage,dron)) Bibliograf´ıa

[1] James F. Kurose y Keith W. Ross. Redes de Computadores: Un Enfoque Descendente. Quinta edici´on. Addison Wesley, 2010.

[2] Intel. Wireless ethernet lan (wlan) general 802.11a/802.11b/802.11g faq. Visita- do en Octubre 2014. URL http://download.intel.com/support/wireless/wlan/ wirelesslanfaq.pdf.

[3] Intel. Productos intel R wi-fi. http://www.intel.com/support/sp/wireless/wlan/sb/ cs-025321.htm?wapkw=wlan, online. Visitado en Octubre 2014.

[4] Paul Vrancken Philips Research, CoSiNe. Ieee 802.11 medium access con- trol (mac). http://www.wirelesscommunication.nl/reference/chaptr01/wrlslans/ 80211_page2.htm, online. Visitado en Octubre 2014.

[5] TechNet. How 802.11 wireless works. http://technet.microsoft.com/en-us/library/ cc757419(v=ws.10).aspx, online. Visitado en Octubre 2014.

[6] Michael H. Warfield. Wireless security. 2006. URL http://www.wittsend.com/mhw/ 2006/Wireless-Security-ALE/Wireless-Security-ALE-2006.pdf.

[7] Jargen Bach Andersen, Theodore S. Rappaport, and Susumu Yoshida. Propa- gation measurements and models for wireless communications channels. 1995. URL http://www.cs.bilkent.edu.tr/~korpe/courses/cs515-fall2002/papers/ radio-propogation-rappaport.pdf.

[8] IEEE. Modelo osi. 1994. URL http://standards.iso.org/ittf/ PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip.

[9] R. Droms Network Working Group. Rfc 2131 - dynamic host configuration protocol. 2014. URL http://tools.ietf.org/html/rfc2131.

[10] IEEE. Cyclic codes for error detection. 2007. URL http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?reload=true&arnumber=4066263.

[11] IEEE Ethernet Working Group. Ethernet 802.3. http://www.ieee802.org/3/, online. Visitado en Octubre 2014. 128 Bibliography 129

[12] Routerboard. About routerboard. http://routerboard.com/about, online. Visitado en Octubre 2014.

[13] MikroTik. R52. http://routerboard.com/R52, online. Visitado en Octubre 2014.

[14] MS Distribution. Mikrotik r52 802.11a/b/g mini-pci wireless. http://www.msdist.co. uk/product_MikroTik_R52_mini-PCI_wireless.php, online. Visitado en Octubre 2014.

[15] Linux Wireless. About ath5k. http://wireless.kernel.org/en/users/Drivers/ ath5k, online. Visitado en Octubre 2014.

[16] Linux Wireless. Existing linux wireless drivers. http://wireless.kernel.org/en/ users/Drivers, online. Visitado en Octubre 2014.

[17] Linux Wireless. Wireless operating modes. http://wireless.kernel.org/en/users/ Documentation/modes, online. Visitado en Octubre 2014.

[18] TP-LINK. Router gigabit inal´ambrico de banda dual n750 - tl-wdr4300. http://www. tp-link.es/products/details/?model=TL-WDR4300, online. Visitado en Abril 2015.

[19] OpenWRT. Tp-link tl-wdr4300. http://wiki.openwrt.org/toh/tp-link/tl-wdr4300, online. Visitado en Abril 2015.

[20] MikroTik. Routerboard 133 series - user’s manual. 2006. URL http://routerboard. com/pdf/rb133ugA.pdf.

[21] MikroTik. Routerboard r52. http://i.mt.lv/routerboard/files/R52.pdf, online. Vi- sitado en Octubre 2014.

[22] MikroTik. 2.4/5ghz 802.11a+b+g wireless mini-pci card (r52). http://www.mikrotik. com/pdf/R52.pdf, online. Visitado en Octubre 2014.

[23] TP-LINK. Tl-wdr4300 - user guide. http://www.tp-link.com/resources/document/ TL-WDR4300_V1_User_Guide_19100.pdf, online. Visitado en Abril 2015.

[24] MikroTik. Routerboard product catalog q2 2014. 2014. URL http://download2. mikrotik.com/2014-Q2.pdf.

[25] Intel. ¿qu´ees un router inal´ambrico? http://www.hp.com/global/uy/es/wireless/ wireless-network-help4.html, online. Visitado en Octubre 2014.

[26] Intel. Redes inal´ambricas, productos intel wi-fi. http://www.intel.com/support/sp/ wireless/wlan/sb/cs-030505.htm?wapkw=wlan, online. Visitado en Octubre 2014.

[27] Oracle. Java plataform, micro edition (java me). http://www.oracle.com/technetwork/ java/embedded/javame/overview/index.html, online. Visitado en Octubre 2014. Bibliography 130

[28] Qualcomm. Qualcomm atheros. http://www.qca.qualcomm.com/, online. Visitado en Octubre 2014.

[29] Qualcomm. Product collateral. http://www.qca.qualcomm.com/resources/ product-collateral/, online. Visitado en Octubre 2014.

[30] WikiDEV. Atheros. https://wikidevi.com/wiki/Atheros, online. Visitado en Octubre 2014.

[31] Intel. Intel wi-fi products. http://ark.intel.com/es/products/family/59484/ Intel-Wi-Fi-Products], online. Visitado en Octubre 2014.

[32] Intel. Intel. http://www.intel.la/content/www/xl/es/homepage.html, online. Visita- do en Octubre 2014.

[33] Intel. Intel wireless technology and products information. http://www.intel.la/ content/www/xl/es/wireless-products/WirelessTechDocs.html?wapkw=wlan, onli- ne. Visitado en Octubre 2014.

[34] Broadcom. Broadcom company. http://www.broadcom.com/company/, online. Visitado en Octubre 2014.

[35] Broadcom. 802.11 wireless lan solutions. http://www.broadcom.com/products/ Wireless-LAN/802.11-Wireless-LAN-Solutions, online. Visitado en Octubre 2014.

[36] Broadcom. Broadcom corporation quick facts. http://www.broadcom.com/docs/ company/BroadcomQuickFacts.pdf, online. Visitado en Octubre 2014.

[37] Microsoft. ¿qu´ees un proveedor de acceso a internet (isp)? http://windows.microsoft. com/es-es/windows/what-is-internet-service-provider#1TC=windows-7, online. Visitado en Octubre 2014.

[38] Jes´us Moreno Le´on and Ra´ul Ruiz Padilla. Planificaci´on y administraci´on de re- des: Network address traslation. http://www.exa.unicen.edu.ar/catedras/comdat1/ material/NAT.pdf, online. Visitado en Octubre 2014.

[39] Pablo Estrada. Mimo: Why multiple antennas matter. https://meraki.cisco.com/ blog/2011/02/mimo-why-multiple-antennas-matter/, online. Visitado en Octubre 2014.

[40] Karima Vel´asquezand Eric Gamess. Network performance evaluation based on three processes. 2014. URL http://pubs.sciepub.com/jcsa/2/2/1/jcsa-2-2-1.pdf.

[41] Francisco Ortu˜noL´opez. Implementaci´on openwrt del protocolo de comunicaciones w2lan. 2010. URL http://repositorio.bib.upct.es/dspace/bitstream/10317/ 1958/1/pfc3514.pdf. Bibliography 131

[42] D. Grari Hicham. Plataforma m´ovilpara aula virtual basada en wrt160nl-openwrt- usb. 2012. URL http://repositorio.bib.upct.es/dspace/bitstream/10317/3083/ 1/pfc4550.pdf.

[43] Florian Fainelli. The openwrt embedded development framework. 2008. URL ftp: //193.206.140.34/pub/1/openwrt/people/florian/fosdem/fosdem.pdf.

[44] Aaron Weiss. The open source wrt54g story. http://www.wi-fiplanet.com/tutorials/ article.php/3562391, online. Visitado en Octubre 2014.

[45] TheIndividual. The individual’s sveasoft wrt54g firmwares. http://wrt54g.thermoman. de/, online. Visitado en Octubre 2014.

[46] Narod. Freww wrt initiative. http://freewrt.narod.ru/, online. Visitado en Octubre 2014.

[47] Sveasoft. Sveasoft. http://www.sveasoft.com/, online. Visitado en Octubre 2014.

[48] Sveasoft forum. None of the downloads are working. http://www.sveasoft.com/index. php?option=com_kunena&view=topic&catid=26&id=126156&Itemid=18, online. Visita- do en Octubre 2014.

[49] Polarcloud. Tomato firmware. http://www.polarcloud.com/tomato, online. Visitado en Octubre 2014.

[50] Dd-wrt. About dd-wrt. http://www.dd-wrt.com/site/content/about, online. Visitado en Octubre 2014.

[51] Dd-wrt. What is dd-wrt? http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT% 3F, online. Visitado en Octubre 2014.

[52] Dd-wrt. Dd-wrt supported devices. http://www.dd-wrt.com/wiki/index.php/ Supported_Devices, online. Visitado en Octubre 2014.

[53] Dd-wrt. Router database. http://www.dd-wrt.com/site/support/router-database, online. Visitado en Octubre 2014.

[54] OpenWRT. Openwrt. https://openwrt.org/, online. Visitado en Octubre 2014.

[55] Jeremy Collake and Kemen. X-wrt. https://code.google.com/p/x-wrt/, online. Visi- tado en Octubre 2014.

[56] Tarifa. The wrt54gl enhanced firmware. http://tarifa.sourceforge.net/, online. Vi- sitado en Octubre 2014.

[57] Michael Barr and Anthony Massa. Programming Embedded Systems, Second Edition with C and GNU Development Tools. O’Reilly, 2006. Bibliography 132

[58] Peter Marwedel. Embedded Systems Design, Second Edition. Springer, 2011.

[59] Michael Barr. Programming Embedded Systems in C and C++. O’Reilly, 1999.

[60] Eugenio Villar (editor). Embedded Systems Specification and Design Languages - Selected contributions from FDL’07. Springer, 2007.

[61] Stephen A. Edwards. Design languages for embedded systems. 2003. URL http://www. cs.columbia.edu/~sedwards/papers/edwards2003design.pdf.

[62] A. Jantsch and I. Sander. Models of computation and languages for embedded system design. 2005. URL http://ieeexplore.ieee.org/xpl/login.jsp?tp= &arnumber=1454195&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F2192% 2F31230%2F01454195.pdf%3Farnumber%3D1454195.

[63] Lua. Lua. http://www.lua.org/about.html, online. Visitado en Octubre 2014.

[64] J. Visca. Introducci´ona lua. https://eva.fing.edu.uy/pluginfile.php/58939/mod_ resource/content/1/introduccionALua-v1.pdf, online. Visitado en Octubre 2014.

[65] Python. Python. https://www.python.org/, online. Visitado en Octubre 2014.

[66] David Boddie. Embedded python. https://wiki.python.org/moin/EmbeddedPython, online. Visitado en Octubre 2014.

[67] Lua Users. Lua multi tasking. http://lua-users.org/wiki/MultiTasking, online. Vi- sitado en Octubre 2014.

[68] Mary Bellis. Inventors of the modern computer. http://inventors.about.com/od/ mstartinventions/a/microprocessor.htm, online. Visitado en Octubre 2014.

[69] Adri´an Granados. Diagnosticando problemas en redes inal´ambricas. http: //www.adriangranados.com/content/help/wifiexplorer/1.5/es.lproj/pgs/ troubleshoot.html, online. Visitado en Octubre 2014.

[70] Alex Gzz. Redes de telecomunicaciones. http://redestele.blogspot.com/2013_02_ 01_archive.html, online. Visitado en Octubre 2014.

[71] Margaret Rouse. signal-to-noise ratio (s/n or snr). http://searchnetworking. techtarget.com/definition/signal-to-noise-ratio, online. Visitado en Octubre 2014.

[72] Xataka. Qu´e son los canales wi-fi y c´omo escoger el mejor pa- ra nuestra red. http://www.xatakaon.com/optimizacion-del-adsl/ que-son-los-canales-wi-fi-y-como-escoger-el-mejor-para-nuestra-red, on- line. Visitado en Octubre 2014. Bibliography 133

[73] Juan V. Puertos. Montaje de un router wireless en una maquina gnu/linux. URL http: //www.uv.es/~montanan/ampliacion/trabajos/nat_802.11_linux.pdf.

[74] Ambili Thottam Parameswaran, Mohammad Iftekhar Husain, and Shambhu Upadhyaya. Is rssi a reliable parameter in sensor localization algorithms – an experimental study. 2009. URL http://www.cse.buffalo.edu/srds2009/F2DA/f2da09_RSSI_Parameswaran.pdf.

[75] Angelos Vlavianos, Lap Kong Law, Ioannis Broustis, Srikanth V. Krishnamurthy, and Michalis Faloutsos. Assessing link quality in ieee 802.11 wireless networks: Which is the right metric? URL http://www2.research.att.com/~broustis/research/link_ pimrc08.pdf.

[76] Daniel Aguayo, John Bicket, Sanjit Biswas, Glenn Judd, and Robert Morris. Link-level measurements from an 802.11b mesh network. URL http://pdos.csail.mit.edu/rtm/ papers/p442-aguayo.pdf.

[77] Kameswari Chebrolu, Bhaskaran Raman, and Sayandeep Sen. Long-distance 802.11b links: Performance measurements and experience. 2006. URL http://pages.cs.wisc. edu/~sdsen/papers/2006dgpmeas.pdf.

[78] Susan Mart´ınezCordero. An´alisisde la calidad de se˜nalen una red wifi con la herramienta netstumbler. 2005. URL http://www.redalyc.org/articulo.oa?id=30400708.

[79] Jian Zhang and Ivan Marsic. Link quality and signal-to-noise ratio in 802.11 wlan with fading: A time-series analysis. 2006. URL http://www.ece.rutgers.edu/~marsic/ Publications/vtc2006.pdf.

[80] T. Balla Z. Gal and A. Sz. Karsai. On the wifi interference analysis based on sensor network measurements. 2013.

[81] Thomas H¨uhn. A measurement-based joint power and rate controller for ieee 802.11 networks, 2013. URL http://d-nb.info/106738460X/34.

[82] IEEE Standard Asociation. Ieee std 802.11TM-2012. 2012.

[83] Talia Odete Ledesma Qui˜nones,Lucy Coya Rey, and Luis Alberto Marichal Alc´antara. Herramientas de monitorizaci´ony an´alisisdel tr´aficoen redes de datos. 2012. URL http: //revistatelematica.cujae.edu.cu/index.php/tele/article/download/62/61.

[84] Ramesh Babu H. Siddamallaiah, Gowrishankar Subramanian, and Piriyapatna S. Satya- narayana. A perspective on traffic measurement tools in wireless networks. 2010. URL http://www.scirp.org/journal/PaperDownload.aspx?paperID=2337.

[85] Acrylic. An´alisisde cobertura wifi y seguridad. https://www.acrylicwifi.com/, online. Visitado en Octubre 2014. Bibliography 134

[86] Cisco. The next generation meraki wifi. https://meraki.cisco.com/, online. Visitado en Octubre 2014.

[87] Orion. Acerca de cisco meraki. http://www.solucionesorion.com/partners/meraki, online. Visitado en Octubre 2014.

[88] Cisco Merkai. Meraki wifi stumbler. https://play.google.com/store/apps/details? id=com.meraki.wifistumbler, online. Visitado en Octubre 2014.

[89] Cisco. Try cisco meraki cloud networking for free. https://meraki.cisco.com/es/form/ trial, online. Visitado en Octubre 2014.

[90] Cisco. Meraki dashboard demo. https://meraki.cisco.com/es/form/demo, online. Vi- sitado en Octubre 2014.

[91] Merkai. Introducci´ona la tecnolog´ıade red en la nube. https://meraki.cisco.com/ lib/pdf/meraki_overview_es.pdf, online. Visitado en Octubre 2014.

[92] Merkai. Merkai. https://meraki.cisco.com/lib/pdf/meraki_datasheet_trust_es. pdf, online. Visitado en Octubre 2014.

[93] OpenWRT. Openwrt howtos. http://wiki.openwrt.org/doc/howto/start, online. Vi- sitado en Enero 2015.

[94] OpenWRT. Wireless utilities. http://wiki.openwrt.org/doc/howto/wireless. utilities, online. Visitado en Enero 2015.

[95] OpenWRT. Wireless overview. http://wiki.openwrt.org/doc/howto/wireless. overview, online. Visitado en Enero 2015.

[96] OpenWRT. Beginners’ guide to openwrt. http://wiki.openwrt.org/doc/howto/user. beginner, online. Visitado en Enero 2015.

[97] OpenWRT. Kamikaze. http://downloads.openwrt.org/kamikaze/docs/openwrt. html, online. Visitado en Enero 2015.

[98] OpenWRT. Advanced user. http://wiki.openwrt.org/doc/howto/user.advanced, on- line. Visitado en Enero 2015.

[99] OpenWRT. Opkg package manager. http://wiki.openwrt.org/doc/techref/opkg, online. Visitado en Enero 2015.

[100] OpenWRT. Openwrt wireless faq. http://wiki.openwrt.org/doc/faq/faq.wireless, online. Visitado en Enero 2015.

[101] OpenWRT. Faq after installation of openwrt. http://wiki.openwrt.org/doc/faq/ after.installation, online. Visitado en Enero 2015. Bibliography 135

[102] OpenWRT. Openwrt buildroot – about. http://wiki.openwrt.org/about/toolchain, online. Visitado en Enero 2015.

[103] OpenWRT. Routed ap. http://wiki.openwrt.org/doc/recipes/routedap, online. Vi- sitado en Enero 2015.

[104] OpenWRT. Linux network interfaces. http://wiki.openwrt.org/doc/networking/ network.interfaces, online. Visitado en Enero 2015.

[105] OpenWRT. Bandwidthd. http://wiki.openwrt.org/doc/howto/bandwidthd, online. Visitado en Enero 2015.

[106] OpenWRT. Bandwidth monitoring. http://wiki.openwrt.org/doc/howto/bwmon, on- line. Visitado en Enero 2015.

[107] OpenWRT. Kismet. http://wiki.openwrt.org/doc/howto/wireless.tool.kismet, online. Visitado en Enero 2015.

[108] OpenWRT. Configure a guest wlan. http://wiki.openwrt.org/doc/recipes/ guest-wlan, online. Visitado en Enero 2015.

[109] OpenWRT. Openwrt sysupgrade. http://wiki.openwrt.org/doc/howto/generic. sysupgrade, online. Visitado en Enero 2015.

[110] OpenWRT. Command-line interpreter. http://wiki.openwrt.org/doc/howto/user. beginner.cli, online. Visitado en Enero 2015.

[111] OpenWRT. Wireless configuration. http://wiki.openwrt.org/doc/uci/wireless, on- line. Visitado en Enero 2015.

[112] OpenWRT. Cross compile. http://wiki.openwrt.org/doc/devel/crosscompile, onli- ne. Visitado en Enero 2015.

[113] Javier Rodriguez. Portando openwrt a un mikrotik router- board rb133c. http://www.javirodriguez.com.es/2011/06/08/ portando-openwrt-a-un-mikrotik-routerboard-rb133c/, online. Visitado en Octubre 2014.

[114] Rb1xx goes openwrt. http://rb1xx.ozo.com/doku.php, online. Visitado en Octubre 2014.

[115] Lachlanmiskin. Using minicom yo interface with serial de- vices on linux. http://lachlanmiskin.com/blog/2012/08/03/ using-minicom-to-interface-with-serial-devices-on-linux/, online. Visita- do en Octubre 2014. Bibliography 136

[116] nixCraft. Linux / unix minicom serial communication program. http://www.cyberciti. biz/tips/connect-soekris-single-board-computer-using-minicom.html, online. Visitado en Octubre 2014.

[117] Kuyn´e. Instalar y configurar servidor dhcp en ubuntu y derivados. http://kuyne. blogspot.com/2013/09/instalar-y-configurar-servidor-dhcp-en.html, online. Vi- sitado en Octubre 2014.

[118] Linux Hispano. Instalar y configurar servidor tftp en ubuntu. http://www.linuxhispano. net/2012/02/09/instalar-y-configurar-servidor-tftp-en-ubuntu/, online. Visi- tado en Octubre 2014.

[119] kernel.org. Replacing iwconfig with iw. https://wireless.wiki.kernel.org/en/users/ Documentation/iw/replace-iwconfig, online. Visitado en Enero 2015.

[120] kernel.org. Iw. https://wireless.wiki.kernel.org/en/users/Documentation/iw, on- line. Visitado en Enero 2015.

[121] kernel.org. Linux wireless. https://wireless.wiki.kernel.org/en/users, online. Vi- sitado en Enero 2015.

[122] man.cx. Iwconfig manpage. http://man.cx/iwconfig, online. Visitado en Enero 2015.

[123] dragorn. Kismet. https://www.kismetwireless.net/, online. Visitado en Enero 2015.

[124] Kismet. Kismet.git. https://www.kismetwireless.net/kismet.git/, online. Visitado en Enero 2015.

[125] Mike Kershaw. Kismet github. https://github.com/ahendrix/kismet, online. Visitado en Enero 2015.

[126] Joe Barr. An introduction to the kismet packet sniffer. 2008. URL http://archive09. linux.com/feature/139754.

[127] Johannes Berg. iw linux github. https://github.com/dickychiang/iw-linux, online. Visitado en Enero 2015.

[128] HP. Wireless tools for linux. http://www.hpl.hp.com/personal/Jean_Tourrilhes/ Linux/Tools.html#latest, online. Visitado en Enero 2015.

[129] Vladimir A. Pshenkin. Bandwidth monitoring tools for linux. http://dynacont.net/ documentation/linux/network_monitoring/, online. Visitado en Enero 2015.

[130] Mike Kershaw. Kismet readme. 2011. URL https://www.kismetwireless.net/ documentation.shtml. Bibliography 137

[131] Componentality Oy. Step by step guide for starting hello, world! on openwrt. 2013. URL https://www.componentality.com/res/ Step-By-Step-Instruction-To-Run-Apps-On-FlexRoad-HW.en.pdf.

[132] Mike Kershaw. Linux and 802.11 wireless. 2004. URL https://www.kismetwireless. net/presentations/mhvlug-wireless.pdf.

[133] Matthew S. Gast. 802.11ac: A Survival Guide. O’Reilly Media, 2013.

[134] Luis Mart´ınGarc´ıa. Programing with libpcap - sniffing the network. 2008. URL http: //recursos.aldabaknocking.com/libpcapHakin9LuisMartinGarcia.pdf.

[135] Alberto Dainotti y Antonio Pescap´e. Plab: a packet capture and analysis architectu- re. 2004. URL http://traffic.comics.unina.it/software/ITG/D-ITGpublications/ TR-DIS-122004.pdf.

[136] Tcpdump. Tcpdump and libpcap. http://www.tcpdump.org/#latest-release, online. Visitado en Abril 2015.

[137] Tim Carstens. Programming with pcap. http://www.tcpdump.org/pcap.html, online. Visitado en Abril 2015.

[138] Tcpdump. Tcpdump and libpcap. http://www.tcpdump.org/#latest-release, online. Visitado en Abril 2015.

[139] Jonathan Huang. How to install libpcap on latest ubuntu. http://xgjonathan. blogspot.com/2011/04/how-to-install-libpcap-on-ubuntu.html, online. Visitado en Abril 2015.

[140] Alejandro L´opez Monge. Aprendiendo a programar con libpcap. 2005. URL http: //www.e-ghost.deusto.es/docs/2005/conferencias/pcap.pdf.

[141] tcpdump. pcap loop. http://www.tcpdump.org/manpages/pcap_loop.3pcap.html, on- line. Visitado en Abril 2015.

[142] cet.nau. Packet capture with libpcap and other low level network tricks. http: //eecs.wsu.edu/~sshaikot/docs/lbpcap/libpcap-tutorial.pdf, online. Visitado en Abril 2015.

[143] University Of California Riverside. Tcpdump filters. http://www.cs.ucr.edu/~marios/ ethereal-tcpdump.pdf, online. Visitado en Abril 2015.

[144] tcpdump.org. pcap(3) - linux man page. http://linux.die.net/man/3/pcap, online. Visitado en Abril 2015. Bibliography 138

[145] GuyHarris. Libpcap file format. https://wiki.wireshark.org/Development/ LibpcapFileFormat, online. Visitado en Abril 2015.

[146] Hani Benhabiles. A look at the pcap file format. http://www.kroosec.com/2012/10/ a-look-at-pcap-file-format.html, online. Visitado en Abril 2015.

[147] WinPcap. Unix-compatible functions. https://www.winpcap.org/docs/docs_40_2/ html/group__wpcapfunc.html, online. Visitado en Abril 2015.

[148] manoftoday. Writing and compiling a simple program for openwrt. https://manoftoday.wordpress.com/2007/10/11/ writing-and-compiling-a-simple-program-for-openwrt/, online. Visitado en Abril 2015.

[149] OpenWRT. Openwrt buildroot – installation. http://wiki.openwrt.org/doc/howto/ buildroot.exigence, online. Visitado en Abril 2015.

[150] OpenWRT. Using the sdk. http://wiki.openwrt.org/doc/howto/obtain.firmware. sdk, online. Visitado en Abril 2015.

[151] nao15irikiin. Cross compiling for openwrt. https://github.com/airplug/airplug/ wiki/Cross-compiling-for-OpenWRT, online. Visitado en Abril 2015.

[152] Advanxer. Openwrt: Monitoring using collectd. https://advanxer.com/blog/2013/02/ openwrt-monitoring-using-collectd/, online. Visitado en Abril 2015.

[153] OpenWRT. Using dependencies. http://wiki.openwrt.org/doc/devel/dependencies, online. Visitado en Abril 2015.

[154] yorkspace.com. Using public keys with dropbear ssh client. https://yorkspace. wordpress.com/2009/04/08/using-public-keys-with-dropbear-ssh-client/, onli- ne. Visitado en Abril 2015.

[155] jkini. How to scp, ssh and rsync without prompting for password. https://blogs. oracle.com/jkini/entry/how_to_scp_scp_and, online. Visitado en Abril 2015.

[156] yolinux. C/c++ signal handling. http://www.yolinux.com/TUTORIALS/C++Signals. html, online. Visitado en Abril 2015.

[157] Alexander Sandler. Signal handling in linux. http://www.alexonlinux.com/ signal-handling-in-linux, online. Visitado en Abril 2015.

[158] tutorialspoint. Postgresql - c/c++ interface. http://www.tutorialspoint.com/ postgresql/postgresql_c_cpp.htm, online. Visitado en Abril 2015. Bibliography 139

[159] Sean Hamlin. Installing and configuring postgresql 9.1 on ubuntu 12.04 for local drupal development. http://www.pixelite.co.nz/article/ installing-and-configuring-postgresql-91-ubuntu-1204-local-drupal-development/, online. Visitado en Abril 2015.

[160] PostgreSQL. Postgresql 9.1.15 documentation. http://www.postgresql.org/docs/9. 1/static/, online. Visitado en Abril 2015.

[161] Linux Wireless. Automatic channel selection. https://wireless.wiki.kernel.org/en/ users/documentation/acs, online. Visitado en Abril 2015.

[162] INC WILDPACKETS. 802.11 wlan packet types. http://www.wildpackets.com/ resources/compendium/wireless_lan/wlan_packet_types, online. Visitado en Abril 2015.

[163] Nicolas Darchis. 802.11 frames : A starter guide to learn wire- less sniffer traces. https://supportforums.cisco.com/document/52391/ 80211-frames-starter-guide-learn-wireless-sniffer-traces, online. Visita- do en Abril 2015.

[164] Shyam Parekh. Ieee 802.11 wireless lans. http://inst.eecs.berkeley.edu/~ee122/ sp07/80211.pdf, online. Visitado en Abril 2015.