私は Debian で tcpdump を介して Wi-Fi プローブ要求を監視しており、各プローブ要求要素の RSSI (信号強度) をキャプチャしようとしています。現在、各プローブ要求の tcpdump からの出力は次のようになります。
09:13:17.663057 BSSID:Broadcast DA:Broadcast SA:04:fe:31:67:32:a0 (oui Unknown) Probe Request () [1.0 2.0 5.5 11.0 Mbit]
信号強度やその他の要素が欠落しています。
同じバージョンの tcpdump/libpcap と tcpdump への同じ引数を持つ別のマシンを使用すると、出力には信号強度が含まれます (以下を参照)。
09:14:51.673753 6.0 Mb/s 2412 MHz 11g -71dB signal antenna 1 BSSID:Broadcast DA:Broadcast SA:b2:b2:b2:b2:b2:b2 (oui Unknown) Probe Request (11n-AP) [1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 Mbit]
最初のデバイスのデータ ペイロードから RSSI が欠落している理由と、それをキャプチャする方法がある理由を説明できる人はいますか?
@Spiff からのリクエストに応じて、パケット キャプチャの 1 つを 16 進ダンプで示します。
12:44:40.226564 BSSID:Broadcast DA:Broadcast SA:00:1e:8f:93:3f:60 (oui Unknown) Probe Request (pagefarm) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
0x0000: 4400 0000 9000 0000 7261 3000 0000 0000 D.......ra0.....
0x0010: 0000 0000 0000 0000 4400 0100 0000 0400 ........D.......
0x0020: c79d 0300 4400 0200 0000 0000 0000 0000 ....D...........
0x0030: 4400 0300 0000 0400 0300 0000 4400 0400 D...........D...
0x0040: 0000 0400 b1ff ffff 0000 0000 0000 0000 ................
0x0050: 0000 0000 4400 0600 0000 0400 0000 0000 ....D...........
0x0060: 4400 0700 0000 0400 0000 0000 4400 0800 D...........D...
0x0070: 0000 0400 0200 0000 4400 0900 0000 0000 ........D.......
0x0080: 0000 0000 4400 0a00 0000 0400 3500 0000 ....D.......5...
0x0090: 4000 0000 ffff ffff ffff 001e 8f93 3f60 @.............?`
0x00a0: ffff ffff ffff 4022 0008 7061 6765 6661 ......@"..pagefa
0x00b0: 726d 0108 0204 0b16 0c12 1824 0301 0332 rm.........$...2
0x00c0: 0430 4860 6c .0H`l
答え1
[トラブルシューティングからのすべての発見事項を更新しました。tcpdump
/libpcap/Wireshark の優秀なメンテナーである Guy Harris に感謝します。]
tcpdump802.11 モニター モードの「Radiotap」(別名LINKTYPE_IEEE802_11_RADIOTAP、別名DLT_IEEE802_11_RADIO) 無線メタデータ ヘッダー形式のデータ リンク タイプのみを理解します。
DLTIEEE802_11_RADIOは、受信した各フレームの先頭に、無線メタデータが詰まった「偽の」ヘッダーを追加するようカード/ドライバーに指示します。これは、無線でビットとして送信されたものではなく、フレームを受信した時点で無線の状態から読み取られたものです。この情報には、RSSI、無線がチューニングされたチャネル、パケットのデータ レート/MCS、その他多くの情報が含まれます。
カードとドライバが Radiotap をサポートしている場合は、引数-y IEEE802_11_RADIOに を追加することで、このモードでキャプチャすることを指定できます。 、または を使用すると、インターフェイスtcpdumpでサポートされているデータ リンク タイプの一覧を取得できます。 を含めてモニタ モードを指定しないと、モニタ モード DLT が表示されないことに注意してください。 を追加してインターフェイスをモニタ モードにすることは、すべてのシステムで機能するわけではないため、オープン ソース ソフトウェア パッケージのスクリプトを使用してモニタ モードをオンにする必要がある場合があります。ra0tcpdump -i ra0 -ILtcpdump -i ra0 -D-I-Iairmon-ngaircrack-ng
動作しないマシンの Ralink ドライバー/チップセットは Radiotap ヘッダーをサポートしていないようです。どうやら、非推奨の Prism ヘッダー形式と、あまり知られていない Prism ヘッダーのバリアントのみをサポートしているようです。
この理論を確認するには、上記のコマンドを使用して、動作中のマシン (モニター モードの場合) 上のインターフェイスの DLT をチェックし、それが であることを確認しますIEEE802_11_RADIO。
確認された場合、選択肢は以下のようになるでしょう。
- 動作しないマシンのドライバーを更新して、動作するマシンのドライバーと一致するようにします。どうやら、動作するマシンのドライバーは Radiotap ヘッダーをサポートしているようです。両方のマシンに同じモデルの USB Wi-Fi アダプターが搭載されているとおっしゃっているので、両方のアダプターの内部に本当に同じ Wi-Fi チップセットが搭載されていれば、より優れたドライバーが動作するはずです。
- Wireshark (または付属のコマンドライン ツール
tshark) を使用して、問題のあるマシンでモニター モードのパケット キャプチャを実行します。Wireshark と tshark は、「不良」ドライバーがサポートするバリアント Prism ヘッダーを解析する方法を認識している必要があります。 - リンク層ヘッダーを でキャプチャし
tcpdump、バリアント Prism ヘッダーの RSSI を自分で解析します。オフセット 0x44 (10 進数で 68) のリトルエンディアンの SInt32 である可能性が最も高くなります。シーケンスを探して4400 0400 0000 0400次の 4 バイトを取得し、それらを SInt32 と見なす方が信頼性が高くなります。キャプチャしたヘッダーの例では、RSSI 値は次のようになります。b1ff ffffこれは で0xffffffb1、これは -79 の 32 ビットの 2 の補数符号付き整数表現であり、これは弱いがまだ機能する信号強度の有効な RSSI です。 tcpdump問題のあるマシン上のファイルにキャプチャし、後で Wireshark またはtshark別のマシンを使用して分析するために使用します。- 等