Linuxのusbmonパーミッションエラー：パケットが1つも出ない前にUSBキャプチャが失敗する理由

LinuxでUSBキャプチャが失敗するとき、原因はファームウェアとは限りません。キャプチャツールがそもそもusbmonを読む権限を持っていなかった、ということも多いです。デバイスは存在しているのに、ユーザーにアクセス権がない。別のバスを選んでいた……そんなケースで「no packets」が出てしまうと、本当にトラフィックがないのか、それともキャプチャ権限がないだけなのか、区別がつきません。

この区別はファームウェアチームにとって重要です。Linuxユーザーがキャプチャ元をオープンできなかっただけで、ディスクリプタを書き直してはいけません。

usbmonはキャプチャインタフェースであって、デバイス本体ではない

Linuxの usbmon はUSBバスのトラフィックを露出させる仕組みです。キャプチャ操作は、USBデバイスノードをアプリケーションとして開く操作とは別物です。あるプログラムはデバイスと通信できているのに、別のツールがキャプチャできない、あるいは、キャプチャツールはトラフィックを見ているのに、アプリケーション側がデバイス権限を持っていない——そんなことが普通に起きます。

サポートレポートでは、以下をきちんと分けて書くべきです。

• デバイス列挙
• デバイスノードへのアプリケーションアクセス
• usbmonキャプチャへのアクセス
• 選択中のバス
• カーネルサポート
• ユーザー／グループの権限

この切り分けなしに「USBキャプチャ失敗」と書くと、抽象的すぎて何も始まりません。

よくあるパーミッション由来の症状

典型的な症状を並べてみます。

• キャプチャアダプタは一覧に出るが起動できない
• デバイスは動いているはずなのにキャプチャが空
• usbmonを開こうとして permission denied
• root だけがキャプチャできる
• lsusb にはデバイスが出ているのにトラフィックが記録されない
• ユーザーグループやudevルールを変えたらキャプチャできるようになった

まず最初に確認すべきは、「キャプチャセッションが、そのバスへの権限を持って実際にスタートできたか」です。

正しいバスを選ぶ

USBデバイスは特定のバス上に存在します。別のバスをキャプチャしていると、きれいだが空のトレースになります。デバイスがハブの向こう側にある、あるいは再列挙したような場合は、バス番号やデバイスアドレスが変わっていることもあります。

確認しておきたいポイント：

• lsusb でデバイスを特定する
• バス番号を usbmon のソースと突き合わせる
• デバイスを抜き差しして列挙を観察する
• 自信がないときは全バスを短時間キャプチャする
• 接続（attach）時にトラフィックが出ているか確認する

再接続時の attach トラフィックが見えないなら、おそらくキャプチャ箇所が間違っているか、アクセス権がないかのどちらかです。

パーミッションは「運用上の証拠」

デスクトップツールにとって、パーミッション診断は明示的であるべきです。ホストがキャプチャできないのに「ファームウェアのせい」と誤認させるUIでは困ります。本来は次のことをきちんと伝えてほしいはずです。

• どのアダプタが失敗したか
• パーミッションが不足しているか
• Linux側のアクセス設定が必要か
• グループ／udev変更後にリトライが必要か

こうしておくと、原因の切り分けが早くなります。ファームウェアエンジニアが必要としているのはパケットの証拠であって、キャプチャすら始まらなかった状態から「ディスクリプタが足りない」と診断できるわけがないのです。

Bus Scopeが活きる場面

Bus Scopeは「USBの証拠」を中心に据えて設計されています。その中にはアダプタの状態確認とアクセス診断も含まれます。Linuxでは、パケットタイムラインを表示する前にキャプチャソースの状態を表示できるワークフローが理想です。

「usbmon permission denied」「Linux USB capture no packets」「USB device visible but capture empty」といった検索に対する答えは、ファームウェアの話ではありません。キャプチャアクセス・バスの選択・アダプタの状態の話から始めるべきです。