tcpdump zeigt RSSI nicht an

Question

[Aktualisiert mit allen Erkenntnissen aus unserer Fehlerbehebung.
Vielen Dank an den außergewöhnlichen tcpdump/libpcap/Wireshark-Betreuer Guy Harris.]

tcpdumpversteht nur den Datenverbindungstyp „Radiotap“ (auch bekannt als LINKTYPE_IEEE802_11_RADIOTAP, auch bekannt als ) im Radio-Metadaten-Header-Format für den 802.11-Monitormodus.DLT_IEEE802_11_RADIO

Das IEEE802_11_RADIODLT weist die Karte/den Treiber an, jedem empfangenen Frame einen zusätzlichen „falschen“ Header voller Radio-Metadaten voranzustellen. Dabei handelt es sich um Dinge, die nicht als Bits über die Luft übertragen wurden, sondern aus dem Zustand des Radios zum Zeitpunkt des Empfangs des Frames gelesen wurden. Zu diesen Informationen gehören der RSSI, der Kanal, auf den das Radio eingestellt war, die Datenrate/MCS des Pakets und möglicherweise noch viel mehr.

Wenn Ihre Karte und Ihr Treiber Radiotap unterstützen, können Sie angeben, dass Sie in diesem Modus erfassen möchten, indem Sie -y IEEE802_11_RADIOIhren tcpdumpArgumenten hinzufügen. Sie können eine Liste der unterstützten Datenverbindungstypen für Ihre ra0Schnittstelle mit tcpdump -i ra0 -ILoder möglicherweise mit abrufen tcpdump -i ra0 -D. Beachten Sie, dass die DLTs im Monitormodus möglicherweise nicht angezeigt werden, wenn Sie nicht die angeben, -Ium den Monitormodus anzugeben. Beachten Sie auch, dass das Hinzufügen, -Ium die Schnittstelle in den Monitormodus zu versetzen, möglicherweise nicht auf allen Systemen funktioniert. Sie müssen daher möglicherweise das airmon-ngSkript im aircrack-ngOpen-Source-Softwarepaket verwenden, um den Monitormodus einzuschalten.

Es sieht so aus, als ob der Ralink-Treiber/Chipsatz auf der nicht funktionierenden Maschine keine Radiotap-Header unterstützt. Er unterstützt anscheinend nur das veraltete Prism-Headerformat und eine weniger bekannte Variante von Prism-Headern.

Sie können diese Theorie bestätigen, indem Sie das DLT der Schnittstelle auf dem Arbeitscomputer (im Monitormodus) mit den obigen Befehlen überprüfen und bestätigen, dass es sich um … handelt IEEE802_11_RADIO.

Wenn dies bestätigt wird, haben Sie folgende Optionen:

Aktualisieren Sie den Treiber auf Ihrem nicht funktionierenden Computer, damit er mit dem Treiber auf Ihrem funktionierenden Computer übereinstimmt. Anscheinend unterstützt der Treiber auf dem funktionierenden Computer Radiotap-Header. Da Sie sagen, dass beide Computer dasselbe Modell eines USB-WLAN-Adapters haben, ist hoffentlich in beiden Adaptern tatsächlich der gleiche WLAN-Chipsatz verbaut, sodass der bessere Treiber funktioniert.
Verwenden Sie Wireshark (oder das mitgelieferte Befehlszeilentool tshark), um Ihre Paketerfassungen im Monitormodus auf dem Computer mit dem Problem durchzuführen. Wireshark und Tshark sollten wissen, wie die unterschiedlichen Prism-Header analysiert werden, die der „schlechte“ Treiber unterstützt.
Erfassen Sie die Link-Layer-Header mit tcpdumpund analysieren Sie den RSSI des Prism-Headers selbst. Es wird höchstwahrscheinlich der Little-Endian-SInt32 bei Offset 0x44 (Dezimalzahl 68) sein. Es wäre zuverlässiger, nach der Sequenz zu suchen 4400 0400 0000 0400und dann die nächsten 4 Bytes zu nehmen und sie als SInt32 zu betrachten. In Ihrem Beispiel des erfassten Headers sieht der RSSI-Wert folgendermaßen aus: b1ff ffff. Das wäre 0xffffffb1, die 32-Bit-Zweierkomplement-Ganzzahldarstellung mit Vorzeichen von -79, was ein gültiger RSSI für eine schwache, aber immer noch brauchbare Signalstärke ist.
Verwenden Sie es tcpdumpzum Erfassen in einer Datei auf dem Problemcomputer, analysieren Sie sie jedoch anschließend mit Wireshark oder tsharkauf einem anderen Computer.
usw.

Answer 1

[Aktualisiert mit allen Erkenntnissen aus unserer Fehlerbehebung.
Vielen Dank an den außergewöhnlichen tcpdump/libpcap/Wireshark-Betreuer Guy Harris.]

tcpdumpversteht nur den Datenverbindungstyp „Radiotap“ (auch bekannt als LINKTYPE_IEEE802_11_RADIOTAP, auch bekannt als ) im Radio-Metadaten-Header-Format für den 802.11-Monitormodus.DLT_IEEE802_11_RADIO

Das IEEE802_11_RADIODLT weist die Karte/den Treiber an, jedem empfangenen Frame einen zusätzlichen „falschen“ Header voller Radio-Metadaten voranzustellen. Dabei handelt es sich um Dinge, die nicht als Bits über die Luft übertragen wurden, sondern aus dem Zustand des Radios zum Zeitpunkt des Empfangs des Frames gelesen wurden. Zu diesen Informationen gehören der RSSI, der Kanal, auf den das Radio eingestellt war, die Datenrate/MCS des Pakets und möglicherweise noch viel mehr.

Wenn Ihre Karte und Ihr Treiber Radiotap unterstützen, können Sie angeben, dass Sie in diesem Modus erfassen möchten, indem Sie -y IEEE802_11_RADIOIhren tcpdumpArgumenten hinzufügen. Sie können eine Liste der unterstützten Datenverbindungstypen für Ihre ra0Schnittstelle mit tcpdump -i ra0 -ILoder möglicherweise mit abrufen tcpdump -i ra0 -D. Beachten Sie, dass die DLTs im Monitormodus möglicherweise nicht angezeigt werden, wenn Sie nicht die angeben, -Ium den Monitormodus anzugeben. Beachten Sie auch, dass das Hinzufügen, -Ium die Schnittstelle in den Monitormodus zu versetzen, möglicherweise nicht auf allen Systemen funktioniert. Sie müssen daher möglicherweise das airmon-ngSkript im aircrack-ngOpen-Source-Softwarepaket verwenden, um den Monitormodus einzuschalten.

Es sieht so aus, als ob der Ralink-Treiber/Chipsatz auf der nicht funktionierenden Maschine keine Radiotap-Header unterstützt. Er unterstützt anscheinend nur das veraltete Prism-Headerformat und eine weniger bekannte Variante von Prism-Headern.

Sie können diese Theorie bestätigen, indem Sie das DLT der Schnittstelle auf dem Arbeitscomputer (im Monitormodus) mit den obigen Befehlen überprüfen und bestätigen, dass es sich um … handelt IEEE802_11_RADIO.

Wenn dies bestätigt wird, haben Sie folgende Optionen:

Aktualisieren Sie den Treiber auf Ihrem nicht funktionierenden Computer, damit er mit dem Treiber auf Ihrem funktionierenden Computer übereinstimmt. Anscheinend unterstützt der Treiber auf dem funktionierenden Computer Radiotap-Header. Da Sie sagen, dass beide Computer dasselbe Modell eines USB-WLAN-Adapters haben, ist hoffentlich in beiden Adaptern tatsächlich der gleiche WLAN-Chipsatz verbaut, sodass der bessere Treiber funktioniert.
Verwenden Sie Wireshark (oder das mitgelieferte Befehlszeilentool tshark), um Ihre Paketerfassungen im Monitormodus auf dem Computer mit dem Problem durchzuführen. Wireshark und Tshark sollten wissen, wie die unterschiedlichen Prism-Header analysiert werden, die der „schlechte“ Treiber unterstützt.
Erfassen Sie die Link-Layer-Header mit tcpdumpund analysieren Sie den RSSI des Prism-Headers selbst. Es wird höchstwahrscheinlich der Little-Endian-SInt32 bei Offset 0x44 (Dezimalzahl 68) sein. Es wäre zuverlässiger, nach der Sequenz zu suchen 4400 0400 0000 0400und dann die nächsten 4 Bytes zu nehmen und sie als SInt32 zu betrachten. In Ihrem Beispiel des erfassten Headers sieht der RSSI-Wert folgendermaßen aus: b1ff ffff. Das wäre 0xffffffb1, die 32-Bit-Zweierkomplement-Ganzzahldarstellung mit Vorzeichen von -79, was ein gültiger RSSI für eine schwache, aber immer noch brauchbare Signalstärke ist.
Verwenden Sie es tcpdumpzum Erfassen in einer Datei auf dem Problemcomputer, analysieren Sie sie jedoch anschließend mit Wireshark oder tsharkauf einem anderen Computer.
usw.

tcpdump zeigt RSSI nicht an

Antwort1

verwandte Informationen