USBPcap versus usbmon: como escolher o caminho de captura USB para diagnóstico em campo

O diagnóstico USB geralmente começa com uma pergunta de plataforma: "vamos capturar no Linux ou no Windows? A resposta importa porque o caminho de captura é diferente. No Linux, o caminho comum é o usbmon. No Windows, o caminho comum é o USBPcap. Os dois servem para diagnóstico em campo, mas trazem premissas de configuração, permissões, comportamento de driver e modos de falha diferentes." Resposta curta: "use USBPcap quando o bug só se reproduz em um host Windows, em uma pilha de driver ou na máquina do cliente. Use usbmon quando você controla uma máquina Linux de laboratório, quer menos atrito de configuração, ou quer captura repetível em bancadas de CI e em validação embarcada. Use os dois quando Windows e Linux discordam — essa divergência geralmente é a evidência."

O que capturar primeiro

Não comece filtrando agressivamente. Para trabalho de firmware USB, a primeira captura precisa incluir a enumeração e a primeira transferência em nível de aplicação depois da configuração. Se você começa depois do dispositivo já estar configurado, pode perder o descritor exato ou a requisição de classe que explica a falha.

Evidência mínima:

• timing de conexão, reset e reattach
• descritores de device, configuration, interface, endpoint, BOS, HID, CDC, MSC ou vendor
• campos do pacote de setup para transferências de controle
• endereço, direção e tipo de transferência do endpoint
• marcadores de status, stall, timeout e short packet
• bytes brutos do payload para a transferência que falhou
• plataforma de host e contexto de vínculo de driver

O ponto importante não é qual plataforma é "melhor". O ponto importante é se a captura preserva evidência suficiente para explicar o comportamento do dispositivo.

O que uma captura USB precisa preservar

Para depuração de firmware e hardware, uma captura útil mantém:

• contexto de barramento e dispositivo
• endereço e direção do endpoint
• tipo de transferência
• campos do pacote de setup
• respostas de descritor
• indicações de status e erro
• bytes brutos do payload
• ordem temporal
• metadados suficientes para relacionar pacotes a um dispositivo

Sem essa estrutura, a captura vira um despejo de bytes difícil de defender em um caso de suporte.

Linux usbmon

No Linux, o usbmon expõe o tráfego USB a partir do kernel. É útil para equipes de firmware porque o Linux costuma estar disponível em laboratórios, bancadas de CI e ambientes de validação embarcada. Ele também evita parte da complexidade de vínculo de driver do Windows quando o objetivo é observar enumeração e transferências.

Checagem típica de configuração:

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

Se a ferramenta de captura não enxergar o usbmon, confira se o debugfs está montado e se o usuário tem permissão de leitura nos endpoints do monitor. Não trate uma falha de permissão como "não há tráfego USB"; isso só significa que o host não expôs a fonte de captura.

Perguntas típicas em Linux:

• o usuário tem permissão para capturar?
• em qual barramento o dispositivo está?
• a enumeração parou antes da configuração?
• as requisições de classe estão chegando?
• os endpoints estão movimentando dados depois da configuração?

Se o Linux mostra enumeração e transferências limpas, mas o Windows falha, o próximo suspeito pode ser vínculo de driver no Windows, configuração de INF, instalação do USBPcap ou compatibilidade de classe.

Windows USBPcap

No Windows, o USBPcap é um caminho comum de driver de captura para tráfego USB. Ele é valioso porque muitos clientes só reproduzem o problema do dispositivo em hosts Windows. Se o seu produto é um dispositivo de firmware, ignorar a evidência do Windows pode fazer você perder a falha real em campo.

O risco específico do Windows é o escopo da captura. O USBPcap captura a partir de um root hub selecionado. Se o dispositivo estiver em outro controller ou hub, a captura pode estar perfeitamente vazia enquanto o dispositivo está ocupado em outro lugar. Confirme o root hub antes de concluir que o firmware está mudo.

Perguntas típicas em Windows:

• o USBPcap está instalado e ativo?
• qual root hub deve ser capturado?
• o dispositivo vinculou ao driver esperado?
• a enumeração terminou antes da aplicação abrir o dispositivo?
• há requisições de classe ou transferências bulk/interrupt depois do vínculo?

Capturas no Windows são especialmente úteis quando o problema aparece só com uma pilha de driver ou ambiente de aplicação específico.

Compare capturas, não as condense

Se o mesmo dispositivo USB se comporta diferente em Linux e Windows, essa diferença é evidência. Não condense em "USB está instável". Compare:

• requisições de descritor
• configuração selecionada
• requisições específicas de classe
• tráfego de endpoint depois do setup
• status de erro
• temporização em torno de reset e reattach

A comparação pode mostrar que o firmware é sensível à plataforma, que um host rejeita um descritor que o outro tolera, ou que a camada de aplicação está falhando depois que o setup USB já passou.

Onde o Bus Scope entra

O Bus Scope é uma bancada de captura e inspeção USB construída em torno de evidência. Ele não é um analisador de rede genérico e não tenta abraçar todo domínio de protocolo. O trabalho dele é tornar capturas USB mais fáceis de inspecionar, filtrar, salvar e explicar.

Para fluxos com usbmon e USBPcap, o Bus Scope deve ajudar a equipe a:

• identificar o adaptador de captura e o contexto do dispositivo
• inspecionar pacotes de setup e descritores
• decodificar evidência relevante de classe quando suportado
• manter os bytes brutos amarrados aos campos interpretados
• salvar sessões .bscope para replay e handoff

Quando o relatório de campo diz "o dispositivo falha no Windows mas funciona no Linux", o próximo passo não é adivinhar. É comparar evidência de captura.