WiresharkでUSBフィルタ:USBPcap、usbmon、Bus Scopeで対象デバイスを特定する
USBPcapやusbmonのキャプチャ量が膨大になったとき、デバイス・エンドポイント・転送種別・Setupパケット・インターフェース・タイミングでUSBキャプチャを絞り込む方法を解説します。
USBキャプチャはすぐに肥大化します。1台のマシンに、キーボード/マウス/Webカメラ/Bluetoothアダプタ/ストレージ/シリアルアダプタ/セキュリティキー/内部ハブが同時に動いていることも珍しくありません。「Wireshark USB filter」「USBPcap filter device」「usbmon filter endpoint」「how to find my USB device in capture」で検索する人たちの問題はほぼ同じ。キャプチャには多すぎるトラフィックと少なすぎる構造が入っています。
Bus ScopeはUSB検査をより直接にするために作られていますが、フィルタリング問題自体を理解しておくのは依然として有用です。キャプチャ元がUSBPcap(Windows)であれusbmon(Linux)であれ、あるいは別のUSBキャプチャ元であれ、鍵は「デバイスを特定してから、転送種別・エンドポイント・コントロールリクエストで絞り込む」ことです。
列挙から始める
USBデバイスを識別する最も簡単な方法は、接続時からキャプチャすることです。列挙にはデバイスを名指しするディスクリプタが入っています。VID、PID、コンフィギュレーション、インターフェース、エンドポイント、クラス固有詳細など。
確認ポイント:
- Vendor ID
- Product ID
- デバイスディスクリプタ
- コンフィギュレーションディスクリプタ
- インターフェースディスクリプタ
- エンドポイントディスクリプタ
- 文字列ディスクリプタ
SET_ADDRESSSET_CONFIGURATION
デバイスの動作開始後にキャプチャを始めると、ディスクリプタの文脈なしにエンドポイントトラフィックしか見えないことがあります。エンドポイント番号だけでは絞り込みが難しくなります。
デバイスアドレスは変わり得る
USBデバイスアドレスは列挙中にホストが割り当てます。切断・再接続するとアドレスは変わるかもしれません。1回目の接続で動いたフィルタが2回目を見落とすことがあります。
リセットループのデバッグでこれは重要です。デバイスが繰り返し再列挙するなら、1つのキャプチャ内で複数アドレスを追う必要があります。Product/Vendorディスクリプタを見れば、それらが同じ物理デバイスだと分かります。
Bus Scopeは、この関係を見える形で保つ助けをします。アドレス変更を頭の中で縫い合わせる必要はありません。
エンドポイントでフィルタする
コンフィギュレーション後、ほとんどのデータトラフィックはエンドポイントを使います。エンドポイントゼロはコントロール用。ほかのエンドポイントはバルク/インタラプト/アイソクロナスになり得ます。
よくあるエンドポイントの読み方:
0x00:エンドポイントゼロのコントロールOUT0x80:エンドポイントゼロのコントロールIN0x81:エンドポイント1 IN0x01:エンドポイント1 OUT0x82:エンドポイント2 IN0x02:エンドポイント2 OUT
方向ビットが大事です。0x81 と 0x01 は方向が違う別物です。たとえばシリアルアダプタは、ホスト→デバイス用にバルクOUTを、デバイス→ホスト用にバルクINを使うことがあります。
エンドポイントフィルタは、対象トラフィックがどのエンドポイントを運ぶかを既に知っているときに有用です。
転送種別でフィルタする
USB問題は転送種別ごとに棲み分けます。
- コントロール転送:ディスクリプタ、コンフィギュレーション、クラスリクエスト、ベンダーコマンド
- バルク転送:ストレージ、シリアルデータ、ベンダーデータ、多くのキャプチャデバイス
- インタラプト転送:HID入力、ステータス通知、低遅延レポート
- アイソクロナス転送:オーディオ、ビデオ、時間に敏感なストリーミング
USBシリアルデバイスがポートを開いてもデータを送らないなら、ラインコーディング/コントロールライン状態向けにコントロール転送を、その後バルクエンドポイントのペイロードを観察。Webcamの映像が壊れるなら、アイソクロナス転送とAlternate Settingを観察。HIDデバイスが変なら、インタラプト転送とレポートディスクリプタを観察。
転送種別でフィルタすれば、ノイズを減らしながら必要なクラスの証拠を保てます。
Setupパケットでフィルタする
コントロール転送にはSetupパケットが含まれます。Setupパケットはリクエスト方向、種別、受信者、リクエストコード、Value、Index、Lengthを識別するので極めて有用です。
重要な例:
GET_DESCRIPTORSET_ADDRESSSET_CONFIGURATIONSET_INTERFACECLEAR_FEATURE- HID
GET_REPORT - HID
SET_REPORT - CDC
SET_LINE_CODING - CDC
SET_CONTROL_LINE_STATE - ベンダー固有コマンド
セットアップ中にデバイスが落ちるなら、Setupパケットを見ればどのリクエストが問題を起こしたかが正確に分かります。
WindowsのUSBPcapキャプチャ選択
Windowsでは、USBPcapはUSBホストコントローラからキャプチャします。マシンに複数のコントローラがある場合、誤ったものを選ぶと、対象デバイスのトラフィックが含まれない空のキャプチャになります。
実用的なワークフロー:
- 対象デバイスを抜く
- 想定されるコントローラでキャプチャ開始
- デバイスを挿す
- 列挙ディスクリプタを探す
- 何も出ない場合、別コントローラのキャプチャを試す
- デバイスが見つかったら、そのキャプチャを参照用に残す
Bus Scopeの価値は、このワークフローを不透明でなくする点にあります。ターゲットは「巨大なパケットリスト」ではなく「USBデバイスとの会話」です。
Linuxのusbmonキャプチャ
Linuxでは usbmon がUSBバストラフィックを露出します。バス番号が大事です。Bus 003 Device 012 としてリストされるデバイスは、その瞬間バス3に属します。再接続後はデバイス番号が変わるかもしれません。
最も有用なキャプチャは接続前から始まるもので、列挙がデバイス識別子を明らかにします。権限でキャプチャがブロックされるなら、まずそれを解決してください。そうでないと、アプリ層の失敗しか見えず、USBの証拠にはたどり着けません。
よくあるフィルタリングミス
次のミスを避けてください。
- 失敗後だけフィルタして列挙を取り逃す
- デバイスアドレスが再接続をまたいで一定だと思い込む
- エンドポイント方向を取り違える
- エンドポイントゼロのコントロールトラフィックを無視する
- ペイロードパケットだけ見てクラスリクエストを取り逃す
- ベンダー固有リクエストをすべてノイズ扱いする
- リセットやエラーを早期にフィルタアウトする
- ハブ/ポートのコンテキストを無視する
クリーンなフィルタは、失敗を保全してこそ意味があります。
調査用キャプチャに残すべきもの
ファームウェア/ドライバ/QAチームと共有するレポートには、次を残してください。
- 初期列挙
- 対象デバイスのディスクリプタ
- ホストが選択したコンフィギュレーションとインターフェース
- 失敗前のクラス/ベンダー固有リクエスト
- 失敗が起きたエンドポイントトラフィック
- リセット/ストール/タイムアウト/切断イベント
- 失敗が即時か、アイドル起因か、負荷起因かを示すタイミングコンテキスト
この証拠は「デバイス認識されません」のスクリーンショットよりずっと強力です。
最終的な診断
USBフィルタリングはノイズを隠す作業ではなく、「失敗を説明するパケットシーケンスを保全する」作業です。列挙から始めて、デバイスを識別し、アドレス変化を追跡し、エンドポイントと転送種別で絞り込み、コントロールリクエストを見えるまま保つ。
Bus Scopeはそのワークフローを支えるためにあります。実際のUSBの会話を素早く見つけ、なぜデバイスが動く/ストールする/リセットする/消えるのかをバスレベルの証拠で説明する。
<!-- bus-scope-localized-transaction-foundation-v1:start -->「WiresharkでUSBフィルタ:USBPcap、usbmon、Bus Scopeで対象デバイスを特定する」の USB 契約試験
結論から言うと、STALL、timeout、reset だけでは原因を説明できません。最初に capture provider が正しい device を見ていることを証明し、次に transfer の契約を読みます。種類、方向、recipient、wValue、wIndex、宣言長、実転送長、status、前後の状態を確認し、known-good と最初に異なる transaction に結論を結び付けます。
| 境界 | 比較する証拠 | 判断 |
|---|---|---|
| platform | provider、権限、Root Hub、usbmon/XHC20 | 正しい接続の record か |
| setup | bmRequestType、bRequest、wValue、wIndex、wLength | host は意図した要求を送ったか |
| data | 方向、長さ、保存 bytes | payload は契約と一致するか |
| status | ACK、STALL、timeout、cancellation | transaction はどこで終わったか |
| state | configuration、interface、alternate setting、halt | device は要求を受けられる状態か |
reset と enumeration より前から capture し、descriptor、SET_CONFIGURATION、SET_INTERFACE、失敗直前の command を残します。狭い endpoint filter は重要な control transfer を隠します。一回の試験では USB 操作を一つだけ行い、firmware、driver、port、cable、host command、timing の一項だけを変えます。
引用できる回答
観測した request、setup field、応答、直前状態を書き、一変数の次試験を示します。retention で保存されなかった bytes は packet loss の証明ではありません。command と reset の時間的近さは相関であり、状態変化または再現なしに原因とは言えません。
VID/PID、firmware、speed、topology、provider、filter、trigger を固定し、usbmon と USBPcap の frame number ではなく USB の意味的段階を比較します。開始・終了、版、OS、接続位置、checksum を残し、Bus Scope トラブルシューティングで確認します。
Semrush の owner は分けます。free USB analyzer は製品ページ、best USB protocol analyzer は比較ページ、USB descriptor viewer はdescriptor ガイドです。この技術ページに未確認の検索量や KD は付けません。
<!-- bus-scope-localized-transaction-foundation-v1:end --><!-- multilingual-blog-closeout:start -->直接回答と受け入れ境界
「WiresharkでUSBフィルタ:USBPcap、usbmon、Bus Scopeで対象デバイスを特定する」への短い答えは次のとおりです。USBPcapやusbmonのキャプチャ量が膨大になったとき、デバイス・エンドポイント・転送種別・Setupパケット・インターフェース・タイミングでUSBキャプチャを絞り込む方法を解説します。 この文は、すべての入力、デバイス、プロジェクト、環境に対する保証ではなく、検証すべき結果として扱います。完了した結果には、開始状態、正確な操作、目に見える出力、Bus Scope で作業が終わったと判断する条件が記録されています。
証拠を起点にした操作手順
プロジェクト全体を変更する前に、小さく再現可能なケースから始めます。アプリのバージョン、OS、入力またはデバイスの識別情報、重要な設定、期待結果を記録します。一つの操作だけを実行し、最初の予期しない変化を保存し、可能なら既知の正常ケースと比較します。複数の設定を同時に変えると、問題を作った条件や直した条件が分からなくなります。
確認点 1:WiresharkでUSBフィルタ:USBPcap、usbmon、Bus Scopeで対象デバイスを特定する
「WiresharkでUSBフィルタ:USBPcap、usbmon、Bus Scopeで対象デバイスを特定する」が曖昧な場合、条件をそろえた正常ケースと失敗ケースを比較します。後から現れた症状をすべて並べるのではなく、最初の意味のある差を示します。その境界が、明確な問い合わせと安全な次の実験につながります。
確認点 2:USBPcapやusbmonのキャプチャ量が膨大になったとき、デバイス・エンドポイント・転送種別・Setupパケット・インターフェース・タイミングでUSBキャプチャを絞り込む方法を
「USBPcapやusbmonのキャプチャ量が膨大になったとき、デバイス・エンドポイント・転送種別・Setupパケット・インターフェース・タイミングでUSBキャプチャを絞り込む方法を解説します。」は、最小で代表的な入力を使って確認します。関係のない設定は固定し、同じ操作を繰り返し、再度開いた後または再接続後も結果が保たれるか調べます。画像一枚より、入力、設定、操作、出力、時刻がそろった記録の方が強い証拠です。
確認点 3:列挙から始める
「列挙から始める」が曖昧な場合、条件をそろえた正常ケースと失敗ケースを比較します。後から現れた症状をすべて並べるのではなく、最初の意味のある差を示します。その境界が、明確な問い合わせと安全な次の実験につながります。
確認点 4:デバイスアドレスは変わり得る
「デバイスアドレスは変わり得る」は、最小で代表的な入力を使って確認します。関係のない設定は固定し、同じ操作を繰り返し、再度開いた後または再接続後も結果が保たれるか調べます。画像一枚より、入力、設定、操作、出力、時刻がそろった記録の方が強い証拠です。
確認点 5:エンドポイントでフィルタする
「エンドポイントでフィルタする」が曖昧な場合、条件をそろえた正常ケースと失敗ケースを比較します。後から現れた症状をすべて並べるのではなく、最初の意味のある差を示します。その境界が、明確な問い合わせと安全な次の実験につながります。
確認点 6:転送種別でフィルタする
「転送種別でフィルタする」は、最小で代表的な入力を使って確認します。関係のない設定は固定し、同じ操作を繰り返し、再度開いた後または再接続後も結果が保たれるか調べます。画像一枚より、入力、設定、操作、出力、時刻がそろった記録の方が強い証拠です。
確認点 7:Setupパケットでフィルタする
「Setupパケットでフィルタする」が曖昧な場合、条件をそろえた正常ケースと失敗ケースを比較します。後から現れた症状をすべて並べるのではなく、最初の意味のある差を示します。その境界が、明確な問い合わせと安全な次の実験につながります。
確認点 8:WindowsのUSBPcapキャプチャ選択
「WindowsのUSBPcapキャプチャ選択」は、最小で代表的な入力を使って確認します。関係のない設定は固定し、同じ操作を繰り返し、再度開いた後または再接続後も結果が保たれるか調べます。画像一枚より、入力、設定、操作、出力、時刻がそろった記録の方が強い証拠です。
確認点 9:Linuxのusbmonキャプチャ
「Linuxのusbmonキャプチャ」が曖昧な場合、条件をそろえた正常ケースと失敗ケースを比較します。後から現れた症状をすべて並べるのではなく、最初の意味のある差を示します。その境界が、明確な問い合わせと安全な次の実験につながります。
確認点 10:よくあるフィルタリングミス
「よくあるフィルタリングミス」は、最小で代表的な入力を使って確認します。関係のない設定は固定し、同じ操作を繰り返し、再度開いた後または再接続後も結果が保たれるか調べます。画像一枚より、入力、設定、操作、出力、時刻がそろった記録の方が強い証拠です。
受け入れマトリクス
| 確認点 | 残す証拠 | 合格条件 |
|---|---|---|
| WiresharkでUSBフィルタ:USBPcap、usbmon、Bus Scopeで対象デバイスを特定する | 開始状態、一つの操作、結果状態 | 別の担当者が同じ結果を再現できる |
| USBPcapやusbmonのキャプチャ量が膨大になったとき、デバイス・エンドポイント・転送種別・Setupパケット・インターフェース・タイミングでUSBキャプチャを絞り込む方法を解説します。 | 開始状態、一つの操作、結果状態 | 別の担当者が同じ結果を再現できる |
| 列挙から始める | 開始状態、一つの操作、結果状態 | 別の担当者が同じ結果を再現できる |
| デバイスアドレスは変わり得る | 開始状態、一つの操作、結果状態 | 別の担当者が同じ結果を再現できる |
| エンドポイントでフィルタする | 開始状態、一つの操作、結果状態 | 別の担当者が同じ結果を再現できる |
| 転送種別でフィルタする | 開始状態、一つの操作、結果状態 | 別の担当者が同じ結果を再現できる |
失敗の分離、復旧、引き継ぎ
最初に失敗した境界で停止します。元データ、プロジェクト、セッション、キャプチャを保存し、破壊的な編集前に複製し、一回の実験では一つの変数だけを変えます。複数変更後に全手順をやり直して結果が変わっても、理由は説明できません。
証拠がないことと、存在しない証拠を分けます。空の画面は、入力、範囲、フィルター、権限、デバイス、時間帯、プロジェクト状態の誤りでも起こります。decoder、編集、レポート、書き出しを解釈する前に、取得または読み込み経路を証明します。
引き継ぎ前に成果物を再度開き、先頭、判断点、末尾を確認します。バージョン、環境、設定、期待、観察、最小再現手順を記録します。機密情報を削除またはマスクし、受取人に権限があることも確認します。
質問と回答
最も速く信頼できる開始方法は何ですか?
最小で代表的なケースを使い、期待結果を書き、一つの変数だけを変えます。フィルター、エフェクト、編集、自動化、大きな入力を加える前に、基本経路を確認します。
どの証拠を保存すべきですか?
入力の識別情報、バージョン、環境、設定、正確な操作、最初の異常な変化、最終出力を残します。プロジェクト、セッション、レポート、書き出しは閉じて開き直します。
いつ手順を繰り返しますか?
アプリ、OS、driver、firmware、モデル、入力、手順の変更が結果に影響し得る場合です。以前に合格したケースを変更せず、比較基準として残します。
いつ引き継ぎ可能になりますか?
権限のある別の人が入力を特定し、操作を繰り返し、同じ結果を確認し、残る制限を理解し、未記録のローカル状態なしで成果物を開ける時です。
関連ガイド
次の同一言語ページは、このトピックの正規所有者を変えずに隣接する工程を説明します。
<!-- multilingual-blog-closeout:end -->