SNIFFER USB 2.0 (FULL SPEED) Julián S. Bruno, Jerónimo F. Atencio, Pablo H. Gómez Martino

Transcripción

1 SNIFFER USB 2.0 (FULL SPEED) Julián S. Bruno, Jerónimo F. Atencio, Pablo H. Gómez Martino Departamento de Ingeniería Electrónica Universidad Tecnológica Nacional FRBA Av. Medrano 951, Buenos Aires, Argentina RESUMEN El presente trabajo describe el diseño e implementación de un sniffer USB desarrollado sobre FPGA. El cual permite capturar toda la información que es transmitida a través del bus, filtrarla y enviarla a un ordenador para ser analizada, permitiendo incluso la detección de errores en la trama. Detecta los distintos estadios del bus diferencial sin interferir con él. Este tipo de sniffer presenta varias ventajas frente a sus más tradicionales competidores, los sniffers USB de software, que no son más que una pieza de software que captura los paquetes a nivel del driver del Host USB, perdiendo totalmente de vista otros problemas que podrían aparecer en la capa de hardware del bus. Por otro lado, no siempre es posible disponer de un sniffer de software en el sistema donde se encuentra el Host controller. La implementación fue realizada en VHDL sobre una FPGA Xilinx XC3S200-FT INTRODUCCION En una transmisión de datos por USB pueden intervenir tres tipos de dispositivos: el Host controller, los Devices y los Hubs conectados físicamente en una topología tipo estrella. En un sistema USB solo existe un Host controller, el cual tiene integrado un Root Hub que le provee más puntos de conexión. Un Device puede estar formado por una o más Interfaces, que se comunican independientemente con las aplicaciones en el ordenador. Estas, a nivel de hardware, pueden contener varios Endpoints. Una Function se presenta al sistema como una colección de Interfaces. La comunicación entre los extremos se realiza entre los buffers del lado Host controller y los Endponits del lado Device, denominándose a este canal de comunicación Pipe. A nivel lógico, USB se comporta como un bus bidireccional, transportando datos de un Device determinado hacia el Host controller y viceversa. La especificación USB 2.0 [1] establece tres velocidades de tasa de transferencia con sus respectivas denominaciones: 480 Mb/s (High speed), 12 Mb/s (Full speed) y 1,5 Mb/s (Low speed). El sistema USB transmite la información a nivel físico usando un par diferencial (D+ y D-), en el cual se encuentra embebido el reloj del sistema. Para realizar esto, se utiliza el código de no retorno a cero invertido (NRZI) y la inserción de un bit (bit stuffing) para garantizar una adecuada transición del bus. La especificación USB 2.0 define los tipos de transferencia de información con sus características particulares, ver Tabla 1. Cada transferencia de datos se divide en una o varias transacciones, las cuales están formadas por paquetes de datos [2]. A su vez, el bus USB trabaja con multiplexación por división de tiempo (TDM), definiendo de esta manera una trama temporal (frame) en la cual serán enviadas las distintas transacciones. Estas ocupan una porción de tiempo determinada, dependiendo del tipo de transferencia a la cual pertenecen. Los conceptos de transferencia, transacciones, paquetes y tramas se pueden observar en la Fig. 1. El Host controller es el encargado de velar para que todas las transacciones se lleven a cabo en el menor tiempo posible y es el responsable de particionar el tiempo del bus en tramas. Estas comienzan con un paquete de inicio de trama (SOF) y terminan con una señalización en el bus que indica el fin de trama (EOF). El Host Controller trabajando con dispositivos Full speed, genera paquetes SOF en intervalos de un milisegundo periódicamente. Dentro de cada trama, se transmiten una o varias transacciones, que a su vez están formadas por paquetes de cuatro tipos diferentes: Token, Data, Handshake y Special. Todos estos paquetes comienzan con un campo de sincronismo (SYNC), de 8 bits de longitud, usado para sincronizar el reloj local del Device con el reloj del Host controller, seguido de un campo identificador del paquete (PID) de la misma longitud. A continuación y dependiendo del PID, podrán venir distintos. Todos los paquetes terminan con una señalización de fin (EOP), cuya longitud es de 3 tiempos de bits. Estos cuatro tipos de paquetes tienen diferentes subtipos, como se puede observar en la Tabla 2, según lo estipula la norma USB 2.0 (Full speed). Para controlar errores en la información, cada paquete incluye un campo que contiene un código de redundancia cíclica (CRC) [3]. El protocolo usa dos polinomios distintos para el cálculo del CRC: CRC5 y CRC16 (según sea un paquete de control o de datos respectivamente).

2 Tabla 1. Clasificación de transferencias Tabla 2. Tipos de paquetes Transferencia Característica Uso típico Control No periódica, ráfagas. Configuración Isócronas Periódicas. Webcam, Teléfono Interrupt Pocos datos, baja frecuencia. Mouse, Teclado Bulk No periódicas, muchos datos, usan el ancho de banda excedente. Impresora, Scanner y Disco Rígido PID Type PID Name Descripción OUT Transacción desde Host a la Function IN Transacción desde Function al Host Token SOF Indica el comienzo de la trama y el número de trama. SETUP Transacción de control, para el Endpoint cero. Data DATA0 Paquete de datos par. DATA1 Paquete de datos impar. ACK El paquete recibido no tiene errores. Handshake El receptor no puede recibir el dato, o NAK no tiene dato para transmitir. El Endpoint esta detinido o esa STALL transferencia de control no esta soportada. Special PRE Habilita las transferencias low-speed desde el Host controller hacia el Device 2. EL SNIFFER Fig. 1. Esquema de una transferencia. El paquete TOKEN encabeza todas las transacciones de información entre el Host controller y el Device. Hay cuatro subtipos: IN, OUT, SOF y SETUP. En la Fig. 2 se aprecia el paquete SOF, él cual contiene el campo Frame number que se ve incrementando en cada trama y finaliza con el campo CRC5. Este paquete es enviado únicamente por el Host controller indicando el inicio de la trama. Los paquetes tipo IN y OUT son utilizados para indicarle al Endpoint de un determinado Device, que a continuación recibirá un paquete de datos o que deberá transmitir uno. El Device es indicado con el campo Addr y el Endpoint con el campo Endp. El paquete SETUP es utilizado para el inicio de las transferencias de control. El campo CRC5 es el control de error de los dos campos antes mencionados. El formato de estos tres tipos de paquetes se puede observar en la Fig. 3. El paquete DATA, que se aprecia en la Fig. 4, es transmitido a continuación de un paquete IN, OUT o SETUP desde o hacia un Device. Los paquetes de datos pueden tener un tamaño máximo de 1024 bytes, según lo estipula la especificación USB 2.0 para dispositivos Full speed. Si se deben transmitir más datos de información, se tendrán que realizar varias transacciones. A estos datos se les calcula el código de redundancia cíclica, el cual es enviado en el campo CRC16. Los paquetes de HANDSHAKE, indican el estado de una transacción de datos y su formato es el indicado en la Fig. 5. El sniffer está compuesto por dos partes: hardware y software. En este trabajo se desarrolla la implementación del sniffer en hardware. El software es el encargado de seleccionar qué paquetes de datos se desean capturar del sistema USB bajo análisis. Dicho software recibe la información permitiendo visualizarla y almacenarla en el ordenador. La implementación en hardware consta de tres bloques: Capa física, Núcleo de procesamiento e Interfaz con el ordenador (I/O), tal como se observa en la Fig. 6. La capa física transforma las señales del par diferencial D+ y D- en señales lógicas adecuadas para la FPGA. El segundo bloque, que reside en la FPGA; recibe las señales lógicas de la capa física, se sincroniza con ellas, analiza las tramas, detecta errores y envía la información al bloque I/O. Este último bloque es el encargado de filtrar la información capturada del bus bajo análisis, para luego transmitir al ordenador la información que será visualizada y almacenada vía una interfaz paralela a USB. Las capturas se realizan colocando el sniffer entre el Host controller y el Device bajo estudio. Los datos transmitidos por el sniffer pueden ser muy variados, como por ejemplo: el número de trama, la información de los descriptores y hasta los datos de un Endpoint byte por byte Capa Física La capa física es la encargada de transformar el par diferencial D+ y D- del bus USB bajo análisis, en las siguientes señales: RCV, VP, VM. Las cuales poseen los niveles eléctricos adecuados para conectarse a la FPGA. RCV es la señal diferencia entre D+ y D-. VP y VM corresponden a las señales del par diferencial. Este bloque no debe cargar ni alterar al bus bajo estudio y además debe responder a la velocidad de transmisión del mismo (Full speed).

3 Fig. 2. Paquete SOF Fig. 3 Paquete IN/OUT/SETUP Fig. 4 Paquete DATA Fig. 5 Paquete HANDSHAKE Fig. 6. Esquema básico 2.2. Núcleo de procesamiento El módulo de procesamiento está compuesto por una gran cantidad de bloques independientes que trabajan en forma sincronizada o en paralelo y están controlados por un bloque central (Control). La mayoría de estos bloques son máquinas de estado sincrónicas que trabajan a la velocidad de transmisión. Un diagrama de estos bloques, se ilustra en la Fig. 7. Este diseño posee un reloj interno (clkext), cuatro veces más rápido que el del Host controller, que se sincroniza con el reloj embebido en la señal RCV. Recupera el reloj del Host y con este hace funcionar todas las máquinas de estado que realizan la descodificación de la trama; identificando los campos PID, SYNC, DATA, etc. y realizando la detección de código de error. La trama es analizada bit a bit, eliminando el bitstuffing si lo tuviera y decodificando el NRZI, hasta obtener la información que fue transmitida. Luego, la información es transferida al bloque I/O para que se le apliquen los filtros correspondientes. En el caso de que ocurra algún error durante el proceso de descodificación, el control será informado para que descarte la trama entera y no sean enviados más datos al bloque I/O Control El bloque de Control es el encargado de habilitar o de deshabilitar las distintas máquinas de estados que integran el núcleo de procesamiento. Esta etapa busca la aparición del campo SYNC y cada vez que aparece un EOP o, se produce un reset o una desconexión del dispositivo; se redispara la búsqueda. Luego, el bloque Control, habilita al bloque BitUnstuffer y al almacenamiento de los próximos 8 bits en un registro de desplazamiento. Este byte corresponde al PID y el bloque DataType determina si el PID es válido. Una vez detectado el PID, se procede al almacenamiento de los restantes bits hasta que el bloque de Status detecte algunos de los tres estadios PLL Esta máquina de estados es la encargada de recuperar el reloj a partir de la señal obtenida desde la capa física (aun codificada en NRZI y con el bitstuffing). Utiliza como referencia un reloj local de 48MHz (clkext) para obtener un reloj de 12 MHz (spllclk) sincronizado con los datos (RCV). El proceso PLL trabaja buscando los flancos de la señal RCV y al encontrarlos, genera una transición en la salida spllclk. Si luego de 2 ciclos de clkext no se encuentra un flanco, se genera una transición en spllclk; en este caso los datos recibidos no cambian. En la Fig. 8 se puede observar el diagrama de estados del proceso antes descripto Data_Recovery Para no provocar la aparición de estados metaestables [4] [5], las señales VM, VP y RCV pasan a través de dos flip flop D (filtros de metaestabilidad) que tiene como señal de reloj spllclk. Las señales libres de metaestabilidad son VM1, VP1 y sdatain Status Este bloque interpreta los estados del par diferencial, analizando los estados lógicos de las señales provenientes del Data_Recovery (VP1 y VM1). Estos estadios están tipificados en la especificación USB 2.0, algunos de ellos son: E0P, Reset y Disconnect. El estado EOP se produce cuando VP1 y VM1 se encuentran en el nivel lógico 0 por un tiempo igual al de dos bits de información y luego VP1 pasa a un nivel lógico 1. Esto se produce al final de cada paquete USB. Si VP1 y VM1 se encuentran en el nivel lógico 0 por un tiempo de 10mseg, este estadio se denomina Reset. El Host controller coloca al bus en este estado para reiniciar a los Devices. El estado en el cual VP1 y VM1 se encuentran en el nivel lógico 0 por un tiempo de 2.5useg, se denomina Disconnect. El bus pasa a este estado cuando el Host controller detecta que un Device se desconectó del bus.

4 Fig. 7. Diagrama interno de la implementación sobre la FPGA NRZI y BitUnstuffer Sync La información que se transmite o recibe entre el Host controller y los Devices, esta codificada en NRZI. Esta codificación consiste en representar al cero con una transición (de 1 a 0 ó de 0 a 1 ) y al uno con una no transición. Por ejemplo la siguiente secuencia de bits Este bloque busca la secuencia de bits que forma el encabezado de todos los paquetes. Cuando la habilitación senablesync se encuentra en 1 lógico, el bloque Sync comienza la búsqueda de dicha secuencia y le informa al Control cuando detecta dicha secuencia se codifica en NRZI como , que no es más ni menos que el campo SYNC DataReady8 y ShiftRegister El bitstuffing consiste en insertar un cero después de 6 unos consecutivos, antes de que los datos sean codificados en NRZI, forzando la transición de los datos cuando están codificados en NRZI. El bloque BitUnstuffer busca 6 unos consecutivos y le informa al bloque Control, que el próximo bit debe ser ignorado. Este último bloque genera una señal que deshabilita al ShiftRegister y DataReady8, para que el próximo bit sea extraído de la secuencia ingresada. En caso de que el próximo bit no sea un cero, se generará una señal de error (bitunstuffererr) que obliga al control a descartar la trama actual y comenzar la búsqueda del paquete SOF. El bloque DataReady8 es un contador de 8 bits que indica al registro de desplazamiento, que debe asignar al bus pdata los bits de información que tiene almacenados. El registro de desplazamiento se encuentra implementado en el bloque ShiftRegister DataType y CRCs El PID es un campo de 8 bits, en el cual el nibble bajo corresponde al tipo de paquete y el nibble alto es dicho valor complementado a uno. Por ejemplo, un paquete de datos puede tener un PID como el siguiente: b.

5 Fig. 8. Máquina de estados PLL El bloque DataType analiza y verifica la consistencia del campo PID, permitiendo filtrar por tipo de paquete e informando errores en dicho campo a través de la señal piderr. El PID es utilizado para determinar qué tipo de CRC (CRC5 o CRC16) debe ser utilizado para comprobar los errores y sobre qué campos debe calcularse. Una vez calculado, se lo compara con el transmitido en el paquete. Los polinomios usados en CRC5 y CRC16 son X 5 +X 2 +1 y X 16 +X 15 +X 2 +1 respectivamente. Luego de haber recibido una señal de PID válido, los datos ingresan al bloque CRC en forma serial para el cálculo del código de verificación de error. Al detectar el EOP los últimos 5 ó 16 bits anteriores son comparados con el CRC calculado. La señal CRC_OK le indicará al bloque TXFrame si ha ocurrido un error, para que este lo transmita al ordenador Interfaz con el ordenador Este bloque establece un vínculo bidireccional entre el Núcleo de procesamiento y el ordenador. Dicha interfaz recibe los filtros desde el ordenador, para luego aplicarlos durante la captura de datos. Los filtros disponibles son: tipo de PID, número de Endpoint y número de Device. Además, se puede habilitar la transmisión del número de trama e informar errores de CRC, en el caso de que ocurran. Esta interfaz está compuesta por tres bloques y posee dos colas, una de transmisión y otra de recepción. La información filtrada es escrita en la cola de transmisión por el bloque TxFrame. Una vez terminada la trama actual se inicia la transmisión de estos datos junto con un encabezado. La máquina de estados USB245 es la encargada de extraer los datos de cola de salida y escribirlos en la interfaz paralela-usb. En el caso de que la cola se encuentre vacía, detendrá la transmisión de datos hasta que la misma llegue a un umbral determinado. Por otra parte, también se encarga de leer dicha interfaz, colocando los datos recibidos en la cola correspondiente. En la cola de recepción se encuentran los filtros de datos. La interfaz paralela-usb está configurada en tipo de transferencia isócrona. Fig. 9. Captura del SOF con osciloscopio TDS2014B 3. IMPLEMENTACIÓN Y VERIFICACIÓN El proyecto fue implementado en un kit de la compañía Digilent (Nexys) que cuenta con una FPGA Xilinx XC3S200-FT256. A este kit, se le conectaron dos circuitos integrados: USB1T11A y FT245BM. El USB1T11A es la capa física, que como mencionamos anteriormente, nos permite obtener las señales del bus sin cargarlo. El FT245BM fue utilizado para proveer una interfaz paralela- USB y subir los datos obtenidos desde la FPGA hacia el ordenador. Este dispositivo posee una transferencia máxima de 1Mbyte/seg. Las primeras versiones de la implementación obtenían como único parámetro del bus, el número de trama que es transmitido por el Host controller y generaban una señal de detección del paquete SOF, que debía activarse cada un milisegundo. Con esta primera etapa estabilizada y sin aun tener la capacidad de bajar y configurar un filtro, se fijó uno en el bloque TXFrame, para que enviase al ordenador el número de trama y los campos PID de esa trama. Hasta ese momento estos datos eran transmitidos al ordenador por una interfaz RS232, la que luego sería reemplazada por la comunicación USB que fue explicada con anterioridad. En las etapas iniciales del desarrollo se realizaron simulaciones del funcionamiento de cada uno de los bloques, utilizando la herramienta ModelSim XE III 6.2c. Se generaron dos tramas modelo para verificar el funcionamiento global del sistema. Se probó el funcionamiento del sniffer conectando varios mouses, teclados y pendrives, de diversos fabricantes, obteniendo resultados satisfactorios en la captura de las transacciones. En la Fig. 9, se puede observar la captura de las señales más relevantes del sniffer, al tener conectado un pendrive Kingston al ordenador. La captura fue realizada con un osciloscopio Tektronix modelo TDS2014B. La señal del canal 1 corresponde a la detección del SOF (type_sof), la del

6 ISE_USB Project Status Project File: ise_usb.ise Current State: Placed and Routed Module Name: USB Errors: No Errors Target Device: xc3s200-5ft256 Warnings: 2268 Warnings Product Version: ISE i Updated: Vie 4. Ene 18:13: Device Utilization Summary Logic Utilization Used Available Utilization Note(s) Number of Slice Flip Flops 189 3,840 4% Number of 4 input LUTs 329 3,840 8% Logic Distribution Number of occupied Slices 198 1,920 10% Number of Slices containing only related logic % Number of Slices containing unrelated logic % Total Number of 4 input LUTs 332 3,840 8% Number used as logic 329 Number used as a route-thru 1 Number used as Shift registers 2 Number of bonded IOBs % IOB Flip Flops 35 Number of GCLKs % Total equivalent gate count for design 4,140 Additional JTAG gate count for IOBs 3,072 Fig. 10. Resultado de la síntesis canal 2 nos muestra los datos transmitidos en el bus USB (sdatain) y la del canal 3 corresponde a la señal anterior decodificada en NRZI y con el bitstuffing eliminado (sdata). En el primer flanco descendente del canal 3 comienza el campo SYNC ( b), finalizando en el lugar indicado por el primer cursor. Los cursores encierran los 8 bits correspondientes al campo PID del SOF. La secuencia de bit que corresponden a dicho PID es la siguiente: b, que puede ser observada en el canal 3. La misma secuencia codificada en NRZI puede ser observada en el canal 2. A continuación de esta podemos ver el número de trama. El tiempo de bit en la transmisión es de 83,33ns y los cursores indican 670ns, que corresponde aproximadamente al tiempo de un byte. En la Fig. 10 se puede apreciar los resultados de la síntesis realizada con la herramienta Xilinx ISE i. El proyecto se realizó íntegramente en VHDL. 4. CONCLUSIONES Y TRABAJO A FUTURO Tal vez, a primera vista parezca excesivo el uso de una herramienta como esta en el desarrollo de alguna aplicación USB. De todos modos, resulta muy útil cuando no es posible correr un sniffer de software (por ejemplo, un pequeño sistema embebido en el cual no se puede ejecutar un sniffer de software) o cuando el problema este en el lado del hardware (por ejemplo, si se está desarrollando sobre un FPGA a nivel lógico un Host o Device USB). Este sniffer no analiza el protocolo de comunicación entre el Host controller y los Hubs, así como tampoco puede analizar el protocolo de dispositivos Low Speed y High Speed. La captura de los datos de un Device nos permite conocer la forma en la que el mismo le responde al Host controller, con lo cual, usando los datos capturados e implementando algunas máquinas de estado podríamos simular el funcionamiento del mismo Device. Como trabajos a futuro queda por implementar la verificación de ciertas condiciones de error en el bus, la mejora en la transmisión de los datos capturados, el envió de informes de error ocurridos en el bus y la incorporación de una entrada de disparo externa para iniciar la captura de datos. Los errores del bus que esta versión del desarrollo aun no verifica son: el caso en que el SOF no respete la cadencia de un milisegundo, que los números de trama no sean consecutivos y errores en el campo SYNC. Cuando se esté analizando un bus con la totalidad del ancho de banda ocupado, será necesaria la implementación de otra interfaz para enviar la totalidad de los datos al ordenador; debido a la capacidad limitada del ancho de banda de la utilizada actualmente. Una solución a esto seria cambiar la interfaz paralela-usb por una Ethernet. La entrada de disparo externa resultaría muy útil para poder determinar la latencia entre la transmisión de los datos por parte del software y la transmisión en el bus. La arquitectura modular del diseño permite la incorporación de mejoras sin tener que incurrir en grandes cambios de los bloques estables. Además, el bajo porcentaje de ocupación de los recursos en la FPGA hace posible la implementación de estas y otras mejoras. 5. REFERENCIAS [1] Compaq Intel Microsoft NEC Hewlett-Packard Lucent Philips, Universal serial bus specification, Revision2.0 Apri. l27, [2] John Gamey, An analysis of throughput characteristic of universal serial bus, Intel Architecture Labs, Jun. 12, [3] Braun, F.; Waldvogel, M., "Fast incremental CRC updates for IP over ATM networks," High Performance Switching and Routing, 2001 IEEE Workshop on, vol., no., pp.48-52, [4] Foley, C., "Characterizing metastability," Advanced Research in Asynchronous Circuits and Systems, Proceedings., Second International Symposium on, vol., no., pp , Mar [5] Wagener, P., "Metastability-a designer's viewpoint," ASIC Seminar and Exhibit, Proceedings., Third Annual IEEE, vol., no., pp.p14/7.1-p14/7.5, Sep 1990.