Filtros USB en Wireshark: encontrar el dispositivo adecuado con USBPcap, usbmon y Bus Scope

Las capturas USB pueden volverse abrumadoras rápido. Una máquina puede tener a la vez un teclado, un ratón, una webcam, un adaptador Bluetooth, un dispositivo de almacenamiento, un adaptador serie, un security key y un hub interno activos. Cuando los usuarios buscan "Wireshark USB filter", "USBPcap filter device", "usbmon filter endpoint" o "how to find my USB device in capture", suelen tener el mismo problema: "la captura trae demasiado tráfico y poca estructura." Bus Scope está construido para hacer más directa la inspección USB, pero entender el problema del filtrado sigue siendo útil. Da igual que la captura venga de USBPcap en Windows, usbmon en Linux u otra fuente USB, la clave está en identificar el dispositivo y luego estrechar la traza por dirección, endpoint, tipo de transferencia y petición de control.

Empieza por la enumeración

La forma más fácil de identificar un dispositivo USB es capturar desde el plug-in. La enumeración contiene descriptores que dan nombre al dispositivo, vendor ID, product ID, configuraciones, interfaces, endpoints y detalles class-specific.

Busca:

• Vendor ID.
• Product ID.
• Device descriptor.
• Configuration descriptor.
• Interface descriptors.
• Endpoint descriptors.
• String descriptors.
• SET_ADDRESS.
• SET_CONFIGURATION.

Si empiezas la captura cuando el dispositivo ya está corriendo, puede que solo veas tráfico de endpoint sin el contexto de los descriptores. Eso dificulta el filtrado porque solo con los números de endpoint no basta.

La dirección del dispositivo puede cambiar

Las direcciones de dispositivo USB las asigna el host durante la enumeración. Si el dispositivo se desconecta y se reconecta, la dirección puede cambiar. Un filtro que funcionó en la primera conexión puede fallar en la segunda.

Importa al depurar bucles de reset. Si un dispositivo reenumera una y otra vez, puede que tengas que seguir varias direcciones en una misma captura. Los descriptores de product/vendor revelan que esas direcciones pertenecen al mismo dispositivo físico.

Bus Scope puede ayudar a mantener visible esa relación en lugar de obligarte a emparchar mentalmente los cambios de dirección.

Filtra por endpoint

Tras la configuración, la mayoría del tráfico de datos usa endpoints. El endpoint cero es de control. Otros endpoints pueden ser bulk, interrupt o isochronous.

Significados habituales de endpoint:

• 0x00: control OUT en endpoint zero.
• 0x80: control IN en endpoint zero.
• 0x81: endpoint 1 IN.
• 0x01: endpoint 1 OUT.
• 0x82: endpoint 2 IN.
• 0x02: endpoint 2 OUT.

El bit de dirección importa. 0x81 y 0x01 no son la misma dirección de endpoint. Un adaptador serie, por ejemplo, puede usar un endpoint bulk OUT para datos host-a-dispositivo y un endpoint bulk IN para datos dispositivo-a-host.

Los filtros por endpoint son útiles una vez que ya sabes qué endpoint lleva el tráfico que te interesa.

Filtra por tipo de transferencia

Distintos problemas USB viven en distintos tipos de transferencia:

• Transferencias de control: descriptores, configuración, class requests, comandos vendor.
• Transferencias bulk: almacenamiento, datos serie, datos vendor, muchos dispositivos de captura.
• Transferencias interrupt: input HID, notificaciones de status, reports de baja latencia.
• Transferencias isócronas: audio, vídeo, streaming sensible al tiempo.

Si un dispositivo serie USB se abre pero no manda datos, inspecciona las transferencias de control para line coding y control line state, y luego los endpoints bulk para el payload. Si una webcam arranca pero el vídeo sale corrupto, inspecciona las transferencias isócronas y los alternate settings. Si un HID se porta mal, inspecciona las transferencias interrupt y los report descriptors.

Filtrar por tipo de transferencia reduce ruido y mantiene la evidencia relevante.

Filtra por setup packet

Las transferencias de control incluyen setup packets. Son muy útiles porque identifican la dirección de la petición, el tipo, el recipient, el código de petición, el value, el index y la longitud.

Ejemplos importantes:

• GET_DESCRIPTOR.
• SET_ADDRESS.
• SET_CONFIGURATION.
• SET_INTERFACE.
• CLEAR_FEATURE.
• HID GET_REPORT.
• HID SET_REPORT.
• CDC SET_LINE_CODING.
• CDC SET_CONTROL_LINE_STATE.
• Comandos vendor-specific.

Cuando un dispositivo falla durante el setup, el setup packet suele decirte exactamente qué petición disparó el problema.

Selección de captura de USBPcap en Windows

En Windows, USBPcap captura desde los USB host controllers. Si una máquina tiene varios controllers, elegir el equivocado puede dar una captura sin tráfico del dispositivo objetivo.

Un flujo práctico:

1. Desenchufa el dispositivo objetivo.
2. Arranca la captura en el controller probable.
3. Enchufa el dispositivo.
4. Busca los descriptores de enumeración.
5. Si no aparece nada, prueba la captura en otro controller.
6. Una vez encontrado el dispositivo, mantén la captura cerca como referencia.

El valor de Bus Scope está en hacer este flujo menos opaco: el objetivo es la conversación del dispositivo USB, no una lista enorme de paquetes.

Captura con usbmon en Linux

En Linux, usbmon expone el tráfico del bus USB. El número de bus importa. Un dispositivo listado como Bus 003 Device 012 pertenece al bus 3 en ese momento. Tras una reconexión, el device number puede cambiar.

La captura más útil empieza antes del plug-in, porque la enumeración revela la identidad del dispositivo. Si el permiso bloquea la captura, resuélvelo primero; si no, puede que solo veas fallo a nivel de aplicación y nunca la evidencia USB.

Errores habituales al filtrar

Evita estos errores:

• Filtrar solo tras el fallo, perdiendo la enumeración.
• Asumir que la dirección del dispositivo es estable entre reconexiones.
• Confundir la dirección del endpoint.
• Ignorar el tráfico de control del endpoint zero.
• Mirar solo los paquetes de payload y perderte las class requests.
• Tratar todas las vendor-specific requests como ruido.
• Filtrar resets y errores demasiado pronto.
• Ignorar el contexto del hub y del puerto.

Un filtro limpio solo sirve si conserva el fallo.

Qué mantener en una captura de investigación

Para un informe que puedas compartir con un equipo de firmware, driver o QA, mantén:

• La enumeración inicial.
• Los descriptores del dispositivo objetivo.
• La configuración e interfaz elegidas por el host.
• Las class o vendor-specific requests previas al fallo.
• El tráfico del endpoint implicado en el fallo.
• El evento de reset, stall, timeout o desconexión.
• Bastante contexto de timing para mostrar si el fallo es inmediato, relacionado con idle o con carga.

Esa evidencia es más sólida que una captura de pantalla de "device not recognized".

Diagnóstico final

Filtrar USB no va solo de esconder ruido. Va de conservar la secuencia de paquetes que explica el fallo. Empieza por la enumeración, identifica el dispositivo, sigue los cambios de dirección, acota por endpoint y tipo de transferencia, y mantén visibles las peticiones de control.

Bus Scope está pensado para soportar ese flujo: encontrar rápido la conversación USB real y luego inspeccionar la evidencia a nivel de bus que explica por qué el dispositivo va, se stall, se resetea o desaparece.