Packet Sniffer. Proyecto final Sistemas Embebidos para Tiempo Real. Integrantes: Pedro Moreira Leonardo Pendás

Transcripción

1 Packet Sniffer Proyecto final Sistemas Embebidos para Tiempo Real Integrantes: Pedro Moreira Leonardo Pendás

2 Resumen En el presente trabajo se detallan todos los aspectos teóricos y prácticos usados para la realización del proyecto de fin de curso de la asignatura Sistemas embebidos para tiempo real. El proyecto consiste en el diseño e implementación de un Packet Sniffer, el cual es un software capaz de adquirir en forma promiscua paquetes en una red. En este caso, estos paquetes se corresponden a tramas de capa MAC sujetas a el formato de la norma IEEE [1] (de ahora en más la norma), la cual fue desarrollada para redes de sensores inalámbricos de bajo consumo. En la misma se especifican todas las funcionalidades de las capas físicas y MAC, así como también el formato de las tramas de cada una de ellas. El sistema será montado sobre un TmoteSky, el cual es un dispositivo hardware pensado para trabajar en redes inalámbricas basadas en esta norma. Este dispositivo cuenta, entre otros elementos, con un microcontrolador MSP430/1611 y el integrado CC2420, el cual es un transceiver de radio frecuencia para trabajar especialmente con la mencionada norma. El desarrollo del software se realizara en lenguaje C. Las arquitecturas de software a usar será un símil de Round-Robin con interrupciones y procesamiento en la rutina de atención a la interrupción (ISR).

3 Tabla de Contenido 1. Introducción 2. Objetivos 3. Alcance 4. Diseño de Software 5. Implementación 6. Pruebas 7. Conclusiones

4 1. Introducción Descripción del problema: Un Packet Sniffer es un dispositivo versátil capaz de ser utilizado en diferentes situaciones. La principal funcionalidad es dentro de las redes, para el testeo de la mismas. Este testeo consiste en poder saber que se esta transmitiendo en cada momento por la red, saber quien envió cada trama así como también a quien va dirigido. Esto lo que permite es una depuración de la comunicación en la red, para que la misma se comporte como se desea, permite verificar que los formatos de paquetes enviados por los nodos, así como las transacciones entre los mismos, son según se establece en la norma. Antecedentes: Actualmente existen dispositivos de este tipo, los mismos están pensados para distintos tipos de redes, incluso redes basadas en la norma. La empresa Texas Instruments desarrolló un packet sniffer pensado para una red basada en esta norma. El mismo cuenta con un hardware específico desarrollado por la misma compañía, con un software de adquisición con el cual se puede levantar los datos capturados y ser mostrados indicando el valor de cada uno de los elementos de la trama. 2. Objetivos Objetivos generales Lo que se busca con este proyecto es poder aplicar y profundizar en los conceptos adquiridos en el curso dependiendo de la situación de la que se trate. Por ejemplo para la correcta elección de la arquitectura de software, poder elegir dependiendo de la situación, si usar Round-Robin con o sin interrupciones, entre otras. A su vez adquirir nuevos conocimientos, como la familiarización con el hardware usado para la implementación. Dentro de este hardware mencionado se encuentra el microcontrolador MSP430 y el chip de radio CC2420. Estos elementos serán utilizados en nuestro proyecto de fin de carrera, por lo cual se busca también como objetivo la familiarización con este hardware y la norma propiamente dicha. Por otra parte se busca al terminar el proyecto, tener un sistema embebido funcionando y realizando la función para la cual fue diseñado. Objetivos específicos 1. Comunicación entre la radio y el microcontrolador: La comunicación entre el Controlador y la radio es a través de un puerto SPI, el cual es manejado desde una UART por el procesador, por lo cual se busca como objetivo implementar las funciones que permitan realizar esta comunicación, para la correcta configuración de la radio y para la comunicación de datos entre el procesador y esta.

5 2. Comunicación entre el procesador y el PC Para esta etapa ya contamos con las funciones desarrolladas en el laboratorio que realizan esta comunicación(a través de la otra UART del controlador). Se buscará obtener un mejor comportamiento del sistema frente a la llegada de varios paquetes símultáneamente, aumentando la velocidad de transmisión del puerto. 3. Diagrama de bloques y esbozo del programa principal Se buscará cuales de las opciones de diseño de software tratadas en el curso se adapta mas al sistema y se realizará el diseño de la arquitectura del sistema (bloque principal y las rutinas de atención a interrupciones) 4. Probar y depurar programa principal, usando hyperterminal Para probar el sistema se intentarán ver las tramas (bytes) en el hyperterminal, verificando que las tramas recibidas sean las mismas que las enviadas. Para ello necesitaremos de un programa auxiliar corriendo en otro mote (simulando otro nodo de la red) que envíe las tramas en el mismo canal físico (ya que la norma cuenta con varios en la banda de 2.4G, y el sistema debe funcionar para un canal fijo, parametrizable y modificable en los archivos fuente) 5. Levantar tramas con software de procesamiento. Intentar utilizar programas ya existentes que soporten tramas de este formato y la logren mostrar de manera más legible la información(esto es, no tener que ir mirando la trama entera de ceros y unos, buscando el valor de cada campo, sino que el programa ya genere el listado de cada trama con los campos correspondientes de cada trama) 6. Familiarización con el hardware Este objetivo se desarrollará en paralelo con los otros, ya que es parte de los conocimientos extras al curso que necesitamos adquirir para poder familiarizarnos con la plataforma en donde va a estar corriendo el software. También nos será de gran utilidad para el proyecto de fin de carrera, que consta de un software que se instalará en la misma placa. A continuación se muestra una foto del dispositivo y un diagrama de bloques con sus módulos principales

6

7 3. Alcance: El proyecto abarca como objetivos principales el software diseñado, probado e instalado en el TmoteSky. El dispositivo debe adquirir en forma correcta los paquetes y debe enviarlos a la PC vía USB, donde serán levantados con el Hyperterminal. Debe contemplar el caso de ráfagas de paquetes y poder capturarlos. En segunda instancia en caso de contar con el tiempo suficiente y tener todo lo demás implementado, se intentara codificar los datos enviados por la PC de forma de que puedan ser levantados con el software de análisis de Texas Instrument. 4. Diseño de Software: Descripción general del sistema El sistema fue diseñado para que actúe de forma pasiva, es decir que se necesite de un estímulo (llegada de datos al transmisor) para que se comience a procesar la información. Por eso, el sistema en general lo que hace es inicializarse, es decir preparase para poder identificar esta llegada de datos, y cuando estos lleguen, se carguen en un buffer interno del procesador y luego ser enviados hacia el PC. Descripción del funcionamiento normal En funcionamiento normal, el sistema se inicializa y se queda esperando tramas. Al llegar una trama, esta es transmitida hacia el PC. Para inicializar el sistema, en el bloque principal (mainsniffer.c) se inicializan tanto el puerto SPI para la comunicación con la radio, y la UART para la comunicación con el PC, para ello se llaman a las funciones PORT_INIT( ), SPI_INIT( ); de chipcon, que se pueden ver en el archivo hal_msp430fet.h. Luego se inicializa la UART1 (hacia el PC) a través de la función inituart1(); que se encuenta en el archivo UART1.c. Luego, se inicializa la cola (función QueueInit utilizada en los laboratorios del curso, del archivo queue.c) con el tamaño que por defecto fijamos en 255 bytes ya que su puntero es una variable de tipo char (8bits). Luego se inicializan las constantes de la radio llamando a la función basicrfinit (que también es cortesía de chipcon, que se encuentra en el archivo basic_rf_init) Luego se espera a que se presione un botón en la placa, para prender el receptor de la radio (mediante la función basicrfreceiveon, cortesía de chipcon) y el sistema se queda esperando recibir paquetes y entra en el bloque main. Al llega un paquete, se ejecuta la ISR que se encuentra en el archivo basic_rf_receive, en donde la trama se guarda en la cola y retorna al main. El robin del main pregunta si la cola esta vacía y en caso de no ser así es que hay tramas a mandarse y se llaman las funciones implementadas para la comunicación hacia el PC, sendbyteuart1. El sistema se quedara constantemente mandando bytes hasta vaciarse la trama.

8 En el siguiente esquema se muestra el diagrama de flujo antes descripto, para el funcionamiento normal del sistema. Inicializo: UART s Puertos Radio Preciono Pulsador (Arranque) No Si Habilito Recepcion Hay datos en la Cola Circular No Si Envio Datos a la PC

9 Elección de la arquitectura de software No se utilizo una única arquitectura de software, esto se debe a que el sistema cuenta con diferentes etapas bien diferenciadas (Recepción de la trama por parte de la radio, almacenamiento en memoria, transmisión hacia la PC). Para la recepción de la trama se eligió procesar la misma dentro de la ISR que atiende la interrupción de la radio, fue elegida así debido a la limitante que teníamos en la velocidad de transmisión hacia el PC (9600 bps, esto se debe a que no se pudo configurar en forma correcta un reloj mas grande para el MSP430). El buffer de recepción de la radio tiene un tamaño de 127 Bytes, si este buffer se encuentra lleno, la radio no sigue recibiendo hasta que se vacié, esto lleva a que la lectura de la trama recibida debe ser rápida para que pueda seguir recibiendo tramas continuamente incluso en el caso de ráfagas. Por este motivo y por la limitante de velocidad, fue que se decidió no enviar hacia la PC cada byte a medida que era recibido, sino recibirlo todo almacenarlo en una cola circular y luego enviarlo hacia la PC. También se utilizo una arquitectura similar al round robin con interrupciones para la transmisión de datos hacia la PC. La diferencia con el round robin puro, que en ves de testear una flag seteada en una interrupción, se consulta a una función para saber si la cola donde se almacenan los bytes recibidos esta vacía. Si esta vacía quiere decir que no se recibió nada desde la radio, en caso contrario tiene datos para enviar. Se eligió esta arquitectura debido a que no queremos que el procesador este mucho tiempo seguido ocupado enviando bytes a la PC, permitiendo de esta forma que la radio pueda interrumpir nuevamente al sistema frente a la llegada de una nueva trama.. Todo esto nuevamente se debe a la diferencia de velocidad entre transmisión y recepción, y a que se quiere que la radio no detenga la recepción debido a que su buffer se encuentra lleno. Flujo de datos Interrupcion de la Radio Bytes desde buffer de radio hacia uc via SPI Almacenamiento de la trama en cola circular Bytes desde cola circular hacia PC via UART Datos enviados levantados en la PC con Hyperterminal

10 5. Implementación: El software implementado consta de un bloque principal, mainsniffer.c en donde se llaman a todas las funciones de inicialización del sistema, esto es: Inicialización de registros y puertos para la comunicación SPI y UART Configuración de los parámetros de la radio Inicialización de la cola FIFO. El software que implementa la comunicación con el hardware se encuentra en los archivos: UART1.c : implementa la interfaz entre el procesador y la UART hacia el PC. Allí se encuentran las rutinas de atención a la transmisión y recepción, y las funciones que envían y reciben datos de este puerto. La comunicación con la radio es SPI, y para ello el dispositivo cuenta con las siguientes señales que se aprecian en la figura: Se comenzó a implementar el software que implementaba esta comunicación y permitía diferentes funcionalidades para la configuración y lectura de datos del buffer de la radio. Para ello se utilizaron las funciones que se describen a continuación; halspi.c : Tiene la función void halspiinit(void), que inicializa los registros de la USART0 que es la que maneja el puerto SPI para la comunicación con la radio. Allí se configura el modo de funcionamiento (sincrónico, a diferencia de la otra que era asíncrona), el BoudRate, índice de modulación y los puertos que se utilizan como entrada-salida del procesador.

11 hal_rf_wait_for_crystal_oscillator.c : esta función la utiliza para configurar la radio, ya que para realizar cualquier escritura o lectura de registro, es necesario que su oscilador este estable, por lo que se queda leyendo el statusbyte de la Radio hasta que esta setee el bit que le indica al procesador que su oscilador ya está estable. hal_rf_set_channel.c : esta función setea el registro de la radio correspondiente al canal en el cual se establece la comunicación inalámbrico. Recibe como parámetro el canal lógico (preestablecido en la norma) y se carga el canal físico en la norma como se especifica en su hoja de datos. hal.h : implementan la interfaz de comunicación a mas bajo nivel con la radio. Estas funcionalidades las comenzamos a implementar, pero debido a errores que desconocemos, las funciones implementadas por nosotros (empleando el mismo código que el fabricante) no permitían escribir los registros necesarios para el correcto funcionamiento del sistema. Las funcionalidades que se encuentran presentes en este archivo son las de enviar y recibir un Byte a la radio por la USART, escribir y leer registros y el acceso a la RAM y colas FIFO de la radio. La interfaz con la cola FIFO del procesador se encuentra en los archivos queue.c y queue.h en donde se encuentran implementadas (de las clases de laboratorio) las funciones que escriben en la cola, que leen el primer dato, que inicializa la cola, y que permite saber si existe algún dato en la cola. Otros archivos necesarios para el funcionamiento: basic_rf_receive.c : es en donde se encuentran las funciones de chipcon que encienden y apagan la radio(basicrfreceiveon, basicrfreceiveoff), la rutina de atención a interrupciones que utiliza la señal FIFOP, que es la que señala la radio cuando tiene una trama completa en su buffer de recepción (ISR Radio), la cual tuvimos que modificar para poder realizar parte del procesamiento (escribir en la cola del controlador). basic_rf_init.c : es en donde se encuentra la mayor parte de la configuración de la radio, a saber, dirección MAC en la red, registro de configuración que hacen referencia a configuraciones del tipo si se deben de descartar los paquetes que llegan (que por defecto los rechaza, esto lo cambiamos), la cantidad de tramas que deben de llegar para que sea interrumpido el procesador, el canal de comunicación físico que va a usar, etc. hal_cc2420: declaración de constantes de la radio Rutinas de atención a interrupciones: -ISR Radio(basic_rf_receive.c) Esta ISR actúa una vez que la radio recibe una trama completa, es decir cuando el micro es interrumpido en el puerto1. En la misma se realiza la lectura de toda la trama y se deja almacenada en una cola circular. -ISR Uart1(COM serie con PC): Esta ISR lo único que hace ya sea para recepción o transmisión (en Uart1 se implementa las ISR para tanto para recepción como para transmisión a través de la UART 1), es respectivamente cargar y leer los datos de los buffers y setear banderas para avisar la recepción o transmisión de estos últimos.

12 6. Pruebas: Esta etapa del proyecto fue dividida en diferentes periodos de tiempo, dado que se realizaron varias pruebas, tanto del sistema completo como de pequeñas partes por separado. Para estas pruebas se realizaron pequeños programas en C que configuraban los modos de funcionamiento, enviaban y recibían datos ya sea a través del Hyperteminal para la comunicación con la PC, y escribiendo y leyendo los registros de la radio para testear la otra interfase. La primera etapa de prueba se correspondió en la comunicación entre el micro y la radio y luego se probó la interfaz entre el micro y la PC. Efectuadas las pruebas se obtuvieron resultados no esperados ya que existió una limitante que fue la velocidad de transmisión hacia el PC, la cual no pudo ser configurada a más de 9600 bps, la cual es la velocidad máxima que se puede alcanzar con el reloj de 32 KHz del hardware, externo al procesador. Este problema surgió debido a que no se pudo elegir otro reloj más veloz. La comunicación con la radio no fue del todo exitosa tampoco, ya que si bien se lograron implementar funciones de comando (como prender oscilador interno de la radio, vaciar el buffer de recepción etc) y lectura de registros de configuración (registros con información respecto al canal usado, etc.), no se tuvo éxito en la prueba de la función que escribía en estos registros de configuración de la radio, los cuales son de gran importancia a la hora de configurar la radio en modo promiscuo. Por estos motivos se recurrió a un librería de protocolos brindados por el fabricante de la radio (Chipcon) que implementaban estas funciones. La segunda etapa de las pruebas fue la de la recepción de paquetes por parte de la radio, para lo cual se utilizó además del mote receptor, otro mote que enviara paquetes en un canal preestablecido por nosotros. Se configuraron tanto receptor como transmisor con sus respectivas direcciones (de Red y de PAN*). Una vez transmitiendo se pudo comprobar que lo que se enviaba era recibido de forma correcta por el receptor, observando los campos del paquete con la herramienta JTAG, la cual nos permite depurar el sistema en tiempo real, y paso a paso. Por ultimo se procedió a probar el sistema completo, para esta prueba nuevamente se uso un mote transmisor. Esta etapa fue similar a la etapa de la prueba de la recepción. Para probar que el packet sniffer funcionaba como tal, se fue cambiando la dirección a la que enviaba el transmisor y se fue comprobando que efectivamente los paquetes eran desplegados en la PC, sin importar la dirección a la cual fueran enviados. La prueba final fue simular una ráfaga de paquetes y ver si la cola FIFO implementada funcionaba correctamente. Para ello se generó un retardo en el main que no permitía al sistema enviar los bytes de corrido hacia el PC, sino que esperaba aprox. 2seg. entre byte simulando así una ráfaga(esto fue enlentecer el receptor en vez de agilizar el transmisor). while(true){ if(!queueisempty(punterocola)){ sendbyteuart1(queuegetdata(punterocola)); halwait(600); halwait(600); //estos tres hal wait generan el retardo de apros. 2 seg.

13 halwait(600); } } Cuando se recibía un paquete se escribía una trama entera en la cola, y entre cada byte que se enviaba al PC se esperaba un tiempo suficiente para que llegara otra trama a la FIFO de la radio, interrumpiendo así al procesador justo en la etapa ñeque se estaban enviando los datos hacia el PC(lo que se hace en bloque main). Corroboramos que se recibían correctamente los paquetes, ya que al transmisor terminar de mandar, los datos(paquetes) que estaban almacenados en la cola era transmitidos uno por uno funcionando así el sistema buffer de almacenamiento de los datos de la ráfaga. Estas pruebas fueron exitosas, cumpliéndose así los requerimientos exigidos para nuestro sistema. El problema principal se puede ver como cualquier problema de congestión de una red de datos, con una velocidad máxima de recepción de datos soportada por la radio y establecida por la norma de 250 kbps. Vel Rafaga Max. 250kbps ( Si ) Tamaño del buffer de la cola ( Buff ) Vel. Salida fija. En el programa 9600bps (So) Así se podría estimar el máximo tiempo que se podría estar recibiendo una ráfaga de datos, es decir Si = So + Buff/delta, para la tasa máxima de datos, el tiempo es delta t = 8.33ms ya que usamos un buffer de 256bytes que se podría aumentar, aumentando así el tamaño de las ráfagas soportadas. Al igual que si aumentáramos la velocidad de transmisión, en donde el hyperterminal y la UART soportan hasta el standard de bps (lo cual fue probado, observando mayoría de errores en los datos). En este caso se podría estar recibiendo durante 14.8ms. *PAN: Personal Area Network, ver norma.

14 7. Conclusiones: Una vez completado este proyecto se puede concluir que se dio cumplimiento a los objetivos fijados para el curso. Se pudo profundizar en el desarrollo de software embebido, aplicar las arquitecturas de software más convenientes dependiendo de la situación y los requerimientos del sistema. Se adquirió un mayor conocimiento en el manejo del hardware usado, como el microcontrolador MSP430, el chip CC2420 al igual que el resto de los elementos que componen el TmoteSky. Por otra parte nos permitió ver los problemas inesperados que pueden surgir al realizar un proyecto. En esto se engloban las pequeñas partes del sistema que son el cimiento del proyecto, que si no pueden ser implementadas, atrasan el resto de las etapas, como por ejemplo la programación de las rutinas de comunicación con la radio, la cual nos trajo sus problemas al igual que la configuración del reloj de la UART. Otro problema inesperado con el cual tuvimos que lidiar fue el de la pérdida de un integrante del grupo, lo cual llevo a tener que redoblar esfuerzos, Por ultimo, se puede decir que se pudo cumplir con los requerimientos detallados en el alcance que debía cumplir el sistema. Cabe mencionar que por razones de tiempo no se pudo realizar la segunda etapa del alcance la cual abarcaba el poder mostrar con el software del packet sniffer de Texas, el paquete capturado. Esto quedo para una prolongación del proyecto por fuera del curso.

15 Anexo: Especificación entregada al comienzo del proyecto: Integrantes Pedro Moreira Leonardo Pendás Andrés Renaud Que se busca hacer? Proyecto Packet-Sniffer El proyecto, como lo dice su nombre, trata de un packet-sniffer, lo que se busca realizar es un sistema que adquiera paquetes en forma promiscua, es decir adquiere todos los paquetes que se modulan a una determinada frecuencia en una determinada red, y los muestre en una PC utilizando algún programa adecuado. Esto se llevara a cabo utilizando un TmoteSky, el cual es un dispositivo que consta entre otros elementos, con un microprocesador MPS430 un chip de radio CC2420 y una antena, estos serán los elementos principales que se utilizaran para el diseño. Antecedentes En la actualidad existen diferentes implementaciones de este tipo, incluso para el tipo de microprocesador que estamos usando. Se encuentra implementado un packet sniffer por Texas, también hay otra implementación en nesc con interfase entre PC y Tmote mediante wireshark, por tal motivo se cuenta con el suficiente apoyo teórico como para poder encarar en forma correcta el problema, y tener funciones ya implementadas de forma que puedan ser utilizadas de ser necesario. Objetivos Lo que se entregara como resultado final será el código C que implemente lo deseado, el mote programado y funcionando y usando programas existentes se buscara poder configurar alguno de forma de que pueda mostrar en pantalla lo obtenido en la captura de paquetes (Wireshark u otro) por medio del sistema implementado. Planificación Primeramente para poder realizar este proyecto se procederá a familiarizarse con el sistema de transmisión y adquisición del mote a través de la antena. Esto será seguido de un estudio de las implementaciones existentes y estimar posibles soluciones. Por ultimo se escribirá el código C necesario y la forma de poder visualizar en la PC lo adquirido, configurando el programa que se utilizara para realizar dicha tarea.

16 Cronograma Tarea Fecha Descripción Subtareas 1 05/05-10/05 Terminar y probar laboratorios y ejercicios Modulo UART y Ej 3 y /05-23/05 Definir y probar comunicación entre radio y micro Estudiar conexiones en TmoteSky Configuración de la radio Configurar SPI Programar prueba: Escribir y leer registros de la radio Configurar frec. reloj adecuadas > 250kb/s Escribir modulo SPI: radio_config(), radio_read() /05-31/05 Definir configuración y programar configuración serie con PC Configurar UART 1, frec. de reloj adecuada. 4 02/06-07/06 Diagrama de bloques y esbozo del programa principal Verificar modulo FIFO: fifo_write, fifo_read, empty_fifo... Definir arquitectura y escribir interrupción que atiende a la radio Prever función que arma la trama q levanta el soft en PC 5 09/06-14/06 Probar y depurar programa principal, usando hyperterminal,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 6 23/06-28/06 Levantar tramas con software de procesamiento. Decidir si usar Texas o WireShrak Configurar y levantar tramas existentes desde un txt Definir si va hacer en tiempo real o no Medificar programa principal 7 30/06-5/07 Depurar, probar y terminar,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,