USBPcap vs usbmon：フィールド診断のUSBキャプチャ経路を選ぶ

USB診断は、まずプラットフォームの問いから始まることが多いです。Linuxでキャプチャしているのか、Windowsでキャプチャしているのか。答えは重要です。キャプチャ経路が異なるからです。Linuxは一般に usbmon を使い、Windowsは一般にUSBPcapを使います。どちらも有用なフィールド診断を支えますが、セットアップの前提、権限、ドライバ挙動、失敗モードが異なります。

クイックアンサー：バグがWindowsホスト／ドライバスタック／顧客マシンでしか再現しないなら USBPcap を使う。Linuxラボマシンを管理下にあり、セットアップの摩擦を低く保ちたい、あるいはCIベンチや組み込み検証システムからの反復可能なキャプチャが必要なら usbmon を使う。WindowsとLinuxで挙動が食い違うときは両方を使う——その食い違い自体が証拠になる。

最初に何をキャプチャするか

最初から強くフィルタリングしないでください。USBファームウェアの場合、最初のキャプチャには「列挙」と「コンフィギュレーション後の最初のアプリレベル転送」を含めるべきです。デバイスコンフィギュレーション後にキャプチャを開始すると、障害を説明するディスクリプタ／クラスリクエストそのものを取り逃します。

最低限の証拠：

• 接続／リセット／再アタッチのタイミング
• デバイス／コンフィギュレーション／インターフェース／エンドポイント／BOS／HID／CDC／MSC／ベンダーディスクリプタ
• コントロール転送のSetupパケットフィールド
• エンドポイントアドレス、方向、転送種別
• ステータス／STALL／タイムアウト／ショートパケットマーカー
• 失敗した転送の生ペイロードバイト
• ホストプラットフォームとドライババインドのコンテキスト

重要なのは「どちらのプラットフォームが優れているか」ではなく、「デバイスの挙動を説明できるだけの証拠をキャプチャが保全しているか」です。

USBキャプチャに残すべきもの

ファームウェア／ハードウェアデバッグ向けには、有用なキャプチャは次を残します。

• バスとデバイスのコンテキスト
• エンドポイントアドレスと方向
• 転送種別
• Setupパケットフィールド
• ディスクリプタ応答
• ステータス／エラー表示
• 生ペイロードバイト
• タイミング順
• パケットをデバイスに紐付けるための十分なメタデータ

この構造がなければ、キャプチャはサポート事例で防御しにくいバイナリダンプになります。

Linux usbmon

Linuxでは usbmon がカーネルからUSBトラフィックを露出します。Linuxはラボ／CIベンチ／組み込み検証環境で手に入りやすいので、ファームウェアチームに有用です。列挙と転送を観察したい場合、Windowsのドライババインド複雑性を避けられます。

典型的なセットアップ確認：

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

キャプチャツールがusbmonを見られない場合、debugfsがマウントされているか、ユーザーがモニタエンドポイントを読む権限を持っているかを確認してください。パーミッション失敗を「USBトラフィックなし」として扱わないでください。それは単に、ホストがキャプチャソースを露出していないだけです。

Linuxで典型的な問い：

• キャプチャの権限を持っているか？
• デバイスはどのバス上にあるか？
• 列挙はコンフィギュレーション前で止まったか？
• クラス固有リクエストが届いているか？
• コンフィギュレーション後にエンドポイントがデータを運んでいるか？

Linuxで列挙・転送がクリーンでもWindowsで失敗するなら、次の容疑はWindowsのドライババインド／INFセットアップ／USBPcapインストール／クラス互換性です。

Windows USBPcap

Windowsでは、USBPcapがUSBトラフィックの一般的なキャプチャドライバ経路です。顧客の多くがこのWindowsホストでしかデバイス問題を再現しないため、価値があります。ファームウェア製品の場合、Windowsの証拠を無視すると実際の現場失敗を取り逃します。

Windows固有のリスクはキャプチャスコープです。USBPcapは選択したルートハブからのみキャプチャします。デバイスが別コントローラ／ハブ上にあると、デバイスが別の場所で動いているのにキャプチャは完全に空になることがあります。ファームウェアが無音だと結論する前に、ルートハブを確認してください。

Windowsで典型的な問い：

• USBPcapはインストールされ有効か？
• どのルートハブをキャプチャすべきか？
• デバイスは期待ドライバにバインドされたか？
• アプリがデバイスを開く前に列挙が完了したか？
• バインド後にクラスリクエストやバルク／インタラプト転送があるか？

Windowsキャプチャは、特定のドライバスタックやアプリ環境で問題が出る場合に特に有用です。

キャプチャを「潰す」のではなく「比較」する

同じUSBデバイスがLinuxとWindowsで違う振る舞いをするとき、その違い自体が証拠です。「USBが不安定だ」と一くくりにせず、次を比較します。

• ディスクリプタリクエスト
• 選択されたコンフィギュレーション
• クラス固有リクエスト
• セットアップ後のエンドポイントトラフィック
• エラーステータス
• リセット／再アタッチ周辺のタイミング

比較によって、ファームウェアがプラットフォーム依存であること、片方のホストが許容するディスクリプタをもう片方が拒否すること、USBセットアップ成功後にアプリ層が落ちていること——が見えてきます。

Bus Scopeが活きる場面

Bus Scopeは「証拠」を中心としたUSBキャプチャ・検査の作業台です。汎用ネットワークアナライザではなく、あらゆるプロトコル領域を吸収しようとしているわけでもありません。役目は、USBキャプチャの検査・フィルタ・保存・説明をより簡単にすることです。

usbmon／USBPcapワークフロー向けに、Bus Scopeは次を支援します。

• キャプチャアダプタとデバイスコンテキストの特定
• Setupパケットとディスクリプタの確認
• サポートされる範囲でのクラス関連証拠のデコード
• 生バイトと解釈フィールドの紐付け保持
• リプレイと引き継ぎのための .bscope セッション保存

フィールドレポートが「Windowsで失敗するがLinuxでは動く」となったら、次の手は推測ではなく「キャプチャ証拠の比較」であるべきです。