USBPcap vs usbmon: eligiendo el camino de captura USB para diagnóstico en campo

El diagnóstico USB suele empezar con una pregunta de plataforma: "¿capturamos en Linux o en Windows? La respuesta importa porque el camino de captura es distinto. Linux suele usar usbmon. Windows suele usar USBPcap. Las dos soportan diagnóstico útil en campo, pero vienen con suposiciones de setup, permisos, comportamiento del driver y modos de fallo diferentes." Respuesta rápida: "usa USBPcap cuando el bug solo se reproduce en un host Windows, un stack de drivers o una máquina de cliente. Usa usbmon cuando controlas una máquina Linux de laboratorio, necesitas menos fricción de setup, o quieres captura repetible desde bancos de CI y sistemas de validación embebida. Usa las dos cuando Windows y Linux discrepan: esa discrepancia suele ser la evidencia."

Qué capturar primero

No empieces filtrando de forma agresiva. Para trabajo de firmware USB, la primera captura debería incluir la enumeración y la primera transferencia a nivel de aplicación tras la configuración. Si empiezas cuando el dispositivo ya está configurado, puedes perderte el descriptor exacto o la class request que explica el fallo.

Evidencia mínima:

• Timing de connect, reset y reattach.
• Descriptores device, configuration, interface, endpoint, BOS, HID, CDC, MSC o vendor.
• Campos del setup packet para transferencias de control.
• Endpoint address, dirección y tipo de transferencia.
• Marcadores de status, stall, timeout y short packet.
• Bytes en crudo del payload para la transferencia que falla.
• Contexto de plataforma del host y binding de driver.

El punto importante no es qué plataforma es "mejor". El punto importante es si la captura conserva suficiente evidencia para explicar el comportamiento del dispositivo.

Qué debe preservar una captura USB

Para depuración de firmware y hardware, una captura útil conserva:

• Contexto de bus y dispositivo.
• Endpoint address y dirección.
• Tipo de transferencia.
• Campos del setup packet.
• Respuestas de descriptor.
• Indicaciones de status y error.
• Bytes en crudo del payload.
• Orden temporal.
• Suficiente metadata para relacionar paquetes con un dispositivo.

Sin esa estructura, una captura se vuelve un volcado de bytes difícil de defender en un caso de soporte.

usbmon en Linux

En Linux, usbmon expone tráfico USB desde el kernel. Es útil para los equipos de firmware porque Linux suele estar disponible en laboratorios, bancos de CI y entornos de validación embebida. También evita parte de la complejidad de binding de drivers en Windows cuando el objetivo es observar enumeración y transferencias.

Comprobación de setup típica:

sudo modprobe usbmon
ls /sys/kernel/debug/usb/usbmon

Si la herramienta de captura no ve usbmon, comprueba que debugfs está montado y que el usuario tiene permiso para leer los endpoints del monitor. No trates un fallo de permiso como "no hay tráfico USB"; solo significa que el host no expuso la fuente de captura.

Preguntas Linux habituales:

• ¿El usuario tiene permiso para capturar?
• ¿En qué bus está el dispositivo?
• ¿La enumeración se paró antes de la configuración?
• ¿Las class-specific requests llegan?
• ¿Los endpoints mueven datos tras la configuración?

Si Linux enseña enumeración y transferencias limpias, pero Windows falla, el siguiente sospechoso puede ser el binding de driver en Windows, la configuración INF, la instalación de USBPcap o la compatibilidad de clase.

USBPcap en Windows

En Windows, USBPcap es una ruta habitual de driver de captura para tráfico USB. Es valioso porque muchos clientes reproducen los problemas del dispositivo solo en hosts Windows. Si el producto es un dispositivo de firmware, ignorar la evidencia Windows puede hacer que se te escape el fallo real en campo.

El riesgo específico de Windows es el alcance de la captura. USBPcap captura desde un concentrador raíz seleccionado. Si el dispositivo está en otro controller u otro hub, la captura puede salir perfectamente vacía mientras el dispositivo está ocupado en otra parte. Confirma el concentrador raíz antes de concluir que el firmware está callado.

Preguntas Windows habituales:

• ¿USBPcap está instalado y activo?
• ¿Qué concentrador raíz debería capturar?
• ¿El dispositivo se enlazó al driver esperado?
• ¿La enumeración terminó antes de que la aplicación abriera el dispositivo?
• ¿Hay class requests o transferencias bulk/interrupt tras el binding?

Las capturas en Windows son especialmente útiles cuando el problema aparece solo con un stack de drivers o un entorno de aplicación concreto.

Compara capturas, no las aplanes

Si el mismo dispositivo USB se comporta distinto en Linux y Windows, esa diferencia es evidencia. No la aplanes como "USB es flaky". Compara:

• Peticiones de descriptor.
• Configuración seleccionada.
• Class-specific requests.
• Tráfico de endpoints tras el setup.
• Estados de error.
• Timing alrededor de reset y reattach.

La comparación puede enseñar que el firmware es sensible a la plataforma, que un host rechaza un descriptor que el otro tolera, o que la capa de aplicación falla después de que el setup USB ya fue bien.

Dónde encaja Bus Scope

Bus Scope es un banco de trabajo de captura e inspección USB construido alrededor de evidencia. No es un analizador de red genérico ni intenta abarcar todo dominio de protocolo. Su trabajo es hacer que las capturas USB sean más fáciles de inspeccionar, filtrar, guardar y explicar.

Para flujos con usbmon y USBPcap, Bus Scope debería ayudar a los equipos a:

• Identificar el adaptador de captura y el contexto del dispositivo.
• Inspeccionar setup packets y descriptores.
• Decodificar evidencia relevante de clase donde se soporte.
• Mantener los bytes en crudo vinculados a los campos interpretados.
• Guardar sesiones .bscope para reproducción y entrega.

Cuando el informe de campo dice "el dispositivo falla en Windows pero va en Linux", el siguiente paso no debería ser adivinar. Debería ser comparar la evidencia de captura.