Warum erscheinen meine von ath9k erzeugten RadioTap-Header fehlerhaft?

Ich sammle 802.11 Pakete mit Scapy auf Ubuntu 16.04 (4.4 Kernel). Die RadioTap Header für meine Pakete haben folgende vorhanden Fahnen:Warum erscheinen meine von ath9k erzeugten RadioTap-Header fehlerhaft?

present=TSFT+Flags+Rate+Channel+dBm_AntSignal+b14+b29+Ext

die Beschreibung des RadioTap gegeben, würde ich Kanal erwarten am 10. Byte nach dem Header und der vorhergehenden Felder (8 für TSFT + 1 jeweils für Flags beginnen und Rate). Kanal hat eine Ausrichtung von 2, so dass kein Padding erforderlich ist. Doch das ist, was in der nicht decodierten Abschnitt des Pakets ist:

notdecoded=' \x08\x00\x00\x00\x00\x00\x00f\xc0 \x02\x00\x00\x00\x00\x10\x02l\t\xa0\x00\xa9\x00\x00\x00\xa9\x00'

In diesem Fall wird die Kanalnummer tatsächlich in den Bytes 18-19 (‚l \ t‘ = 2412), und im nicht genau sicher, was für Byte erscheint enthält die dBm-Signalstärke.

Hat jemand eine Idee, was ich vermisse?

Quelle

2016-02-26 Rich Henry

Das 'notdecoded' Attribut für ein Paket, das ich gerade geschnüffelt habe, ist '' \ xd5q \ x01 \ x00 \ x00 \ x00 \ x00 \ x00 \ x10 \ x02l \ t \ xa0 \ x00 \ xfa \ x01 \ x00 \ x00 ' ', was sinnvoll ist seit' notdecoded [10:12] = 'l \ t''. Können Sie bitte die Frage so bearbeiten, dass sie das vollständige Paket enthält und nicht nur den "nichtdekodierten" Teil? Was zeigt der wireshark, wenn er mit diesem Paket gefüttert wird? – Yoel

Ich bekomme die gleichen Ergebnisse mit meinen Intel Wireless-Karten, alles ist am richtigen Ort. tcpdump ist in der Lage, das Paket zu dekodieren, was ich für eine Antwort brauche, ist jemand, der versteht, was diese zusätzlichen 8 Bytes sind. Ich werde versuchen, in das System zu kommen und ein Paket in ein bisschen zu greifen und werde meine Frage aktualisieren. –

die Antwort gefunden etwas in die Spezifikation nach Graben tiefer:

scapy nicht erweiterten Header nicht analysieren, wie bezeichnet durch Bit-32 (obwohl hat es mir von ihnen sagen, durch die Angabe + Ext oben). Diese zusätzlichen Header werden auf der Vorderseite des "nicht decodierten" Abschnitts des Pakets eingefügt. Ich denke, dass scapy diese erweiterten Header zumindest von nicht decodiert entfernen sollte, um zukünftige Verwirrung zu vermeiden.

In diesem speziellen Fall gibt es zwei zusätzliche 32 Bit erweiterte Bitmap-Header, die für die zusätzlichen 8 Bytes verantwortlich sind.

Wenn jemand eine Antwort mit mehr Details schreiben möchte, akzeptiere ich es, sonst werde ich diese Antwort säubern und für immer akzeptieren.

Quelle

2016-03-02 14:07:43

Warum erscheinen meine von ath9k erzeugten RadioTap-Header fehlerhaft?

Antwort

Verwandte Themen