USBPcap против usbmon: выбор пути USB-захвата для полевой диагностики

USB-диагностика часто начинается с платформенного вопроса: "захватываем на Linux или Windows? Ответ важен, потому что путь захвата разный. Linux обычно использует usbmon. Windows обычно использует USBPcap. Оба могут поддержать полезную полевую диагностику, но у них разные предположения по настройке, права, поведение драйверов и режимы сбоев." Быстрый ответ: "используйте USBPcap, когда баг воспроизводится только на Windows-хосте, стеке драйверов или клиентской машине. Используйте usbmon, когда вы контролируете Linux-машину в лаборатории, хотите меньше трения в настройке, или нужны повторяемые захваты с CI-стендов и систем встроенной валидации. Используйте оба, когда Windows и Linux расходятся — это расхождение часто и есть доказательство."

Что захватывать сначала

Не начинайте с слишком агрессивной фильтрации. Для USB-прошивок первый захват должен включать перечисление и первую application-level передачу после конфигурации. Если вы начали после того, как устройство уже сконфигурировано, вы можете пропустить тот самый дескриптор или класс-запрос, который объясняет сбой.

Минимальные доказательства:

• тайминги подключения/reset/reattach
• device, configuration, interface, endpoint, BOS, HID, CDC, MSC или вендорные дескрипторы
• поля setup-пакета для управляющих передач
• адрес конечной точки, направление и тип передачи
• маркеры status/stall/timeout/short packet
• сырые байты полезной нагрузки для сбойной передачи
• контекст хоста и привязки драйвера

Важно не то, какая платформа «лучше». Важно то, сохранил ли захват достаточно доказательств, чтобы объяснить поведение устройства.

Что должен сохранять USB-захват

Для отладки прошивок и аппаратуры полезный захват хранит:

• контекст шины и устройства
• адрес конечной точки и направление
• тип передачи
• поля setup-пакета
• ответы дескрипторов
• статусы и индикации ошибок
• сырые байты полезной нагрузки
• порядок тайминга
• достаточно метаданных, чтобы связать пакеты с устройством

Без этой структуры захват становится дампом байт, который сложно защитить в кейсе поддержки.

Linux usbmon

В Linux usbmon выставляет USB-трафик ядра. Полезен командам прошивок, потому что Linux часто доступен в лабораториях, на CI-стендах и в embedded-валидации. Также устраняет часть сложности привязки драйверов Windows, когда цель — наблюдать перечисление и передачи.

Типичная проверка настройки:

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

Если инструмент захвата не видит usbmon, проверьте, что debugfs смонтирован и у пользователя есть право на чтение monitor-конечных точек. Не трактуйте сбой прав как «нет USB-трафика» — это значит лишь, что хост не выставил источник захвата.

Типичные Linux-вопросы:

• есть ли у пользователя право на захват?
• на какой шине устройство?
• остановилось ли перечисление до конфигурации?
• приходят ли класс-управляющие запросы?
• идут ли данные по конечным точкам после конфигурации?

Если в Linux перечисление и передачи чистые, а Windows падает — следующий подозреваемый может быть привязкой драйвера Windows, INF-настройкой, инсталляцией USBPcap или класс-совместимостью.

Windows USBPcap

В Windows USBPcap — частый путь capture-драйвера для USB-трафика. Ценен, потому что многие клиенты воспроизводят проблемы устройств только на Windows-хостах. Если продукт — USB-устройство, игнорирование Windows-доказательств может пропустить реальный полевой сбой.

Windows-специфичный риск — область захвата. USBPcap захватывает с выбранного корневого концентратора. Если устройство на другом контроллере или концентраторе, захват может быть совершенно пустым, пока устройство активно где-то ещё. Подтвердите выбор корневого концентратора до вывода, что прошивка молчит.

Типичные Windows-вопросы:

• USBPcap установлен и активен?
• какой корневой концентратор нужно захватывать?
• привязалось ли устройство к ожидаемому драйверу?
• завершилось ли перечисление до открытия устройства приложением?
• идут ли класс-запросы или bulk/interrupt-передачи после привязки?

Windows-захваты особенно полезны, когда проблема появляется только с конкретным стеком драйверов или средой приложения.

Сравнивайте захваты, а не сваливайте вместе

Если одно и то же USB-устройство ведёт себя иначе на Linux и Windows, это различие и есть доказательство. Не сваливайте это в «USB ненадёжен». Сравните:

• запросы дескрипторов
• выбранную конфигурацию
• класс-управляющие запросы
• трафик по конечным точкам после настройки
• статусы ошибок
• тайминг вокруг reset и reattach

Сравнение может показать, что прошивка чувствительна к платформе, что один хост отвергает дескриптор, который другой терпит, или что слой приложения ломается после того, как USB-установка уже прошла.

Место Bus Scope

Bus Scope — рабочее место для USB-захвата и проверки, построенное вокруг доказательств. Это не универсальный сетевой анализатор и не пытается поглотить каждую область протоколов. Его задача — сделать USB-захваты проще для проверки, фильтрации, сохранения и объяснения.

Для воркфлоу usbmon и USBPcap Bus Scope должен помогать командам:

• опознать адаптер захвата и контекст устройства
• проверить setup-пакеты и дескрипторы
• декодировать класс-релевантные данные, где поддерживается
• держать сырые байты привязанными к интерпретированным полям
• сохранять .bscope-сеансы для воспроизведения и передачи

Когда в полевом отчёте написано «устройство падает на Windows, но работает на Linux», следующий шаг — не догадки. Это сравнение захватов.