BIT-Reihenfolge von WLAN-Daten

[Herakles]

Moin!

Schaut man sich mit wireshark bzw. ethereal WLAN-Pakete an, so fällt etwas auf:

Kommt Beispielsweise ein Beacon-Frame auf der WLAN-Karte herein, so muss dieses im ersten Byte des Paketes gekennzeichnet werden, in diesem Falle mit einer 8. (Beacon-Frame ist Sybtype 8 von WLAN-Management Frames).

Das komische ist aber, dass hinter der 8 in diesem ersten Byte noch eine 0 zu finden ist. Hexadezimal 80 = Binär 10000000, was dezimal eine 128 ist.

Warum aber wird aus dem Sybtype 8 eine 80 gemacht? Wieso ist das erste Byte nicht eine binäre 00001000, dann hätten wir Hexadezimal eine 08 was gleich einer 8 ist und dezimal eine 8.

Interessant wird es außerdem, wenn man sich ein "Clear_to_send"-Paket anschaut. Clear_to_send ist Subtype 12, also ein Hexadezimales C oder eine biäre 1100. Der Rest des Bytes wird jetzt aber nicht wie erwartet mit Nullen aufgefüllt, sondern mit einer hexadezimalen 4, also einer binären 100. Insgesamt hat das erste Byte dann die Wertigkeit hexadezimal C4, deziaml 196 und binär 11000100.

Schaut man nun in wireshark nach, so scheint diese 4 gar nicht interpretiert zu werden, zumindest erscheint keine Information die 4 betreffend, sondern lediglich das C betreffend(es ist eben ein Clea_to_send).

Wieso wird also aus einer hexadezimalen 8 eine hexadezimale 80 gemacht? Network-to-Host Umwandlungen können eigentlich nicht schuld sein, denn diese drehen lediglich die Reihenfolge der Bytes um, nicht aber die Reichenfolge der Bits INNERHALB eines Bytes.

Danke für jeden Gedanken zum Thema, Herakles

 

[andICode]

Guten Abend,

Wahrscheinlich liegen die Daten in "network byteorder" (Big endian) vor....

Ich schlage meine Eier auch immer mit der runden Seite nach oben auf...

 

[Vincent Vega]

Byte Order ist nur interessant, wenn Daten mehr als ein Byte lang sind, also z.B. bei 32-Bit Integern. So wie ich das lese, wundert Herakles sich über den Inhalt eines einzelnen Bytes.

 

[andICode]

Byte Order ist nur interessant, wenn Daten mehr als ein Byte lang sind, also z.B. bei 32-Bit Integern. So wie ich das lese, wundert Herakles sich über den Inhalt eines einzelnen Bytes.

Da hast du recht...
Ich kenne das IEEE 802.11 Protokoll nicht im Detail, aber vielleicht befindet sich das
betreffende Byte in einem 24- oder 32bit Feld...


Sollte ja auch nur ein Denkanstoss sein.

 

[Herakles]

Moin!

Wie man an meinem letzten Absatz sieht, geht es nicht um Network- und Host-Byteorder. Die Daten sind innerhalb der Bytes verdreht. Zumindest erscheinen sie als verdreht...

hmm....

Herakles

Könnte vielleicht ein Bedienungsfehler meinerseits vorliegen? Ich meine mich sogar entsinnen zu können, dass ich heute einmal ein Beacon Frame gesehen habe, dass bei dem Byte, welches den Subtype abbildet, eine hexadezimale 80 war (es ist Subtyp 8) und ein anderes Mal habe ich in diesem Byte eine 08 gesehen und beides wurde von wireshark als Beaconframe erkannt...

Alles sehr fadenscheinig!

 

[Vincent Vega]

Ich habe keine Ahnung von WLAN, aber mir ist beim Lesen diverser Standards und Dokumentationen schon öfters aufgefallen (meist zu spät), dass die Bits nicht immer konsistent nummeriert sind.

So findet sich im PCI Standard z.B. eine Illustration des Default Config Space, bei dem sind die Bits der einzelnen Wörter von links nach rechts von Null bis 31 nummeriert. Erstmal verwirrend, denn in anderen Dokumenten (z.B. in der Doku von x86 Opcodes) wird das niederwertigste Bit oft mit Null bezeichnet und rechts platziert, das höchstwertige links. Nochmal verrückter ist die POWER Instruction Set Architecture, dort wird das höchstwertige Bit einer Instruktion mit 0 bezeichnet und links im Diagramm eingezeichnet, das niederwertigste mit 31 und rechts eingezeichnet.

Vielleicht liegt da der "Bedienungsfehler"?

 

[dettus]

Byte Order ist nur interessant, wenn Daten mehr als ein Byte lang sind, also z.B. bei 32-Bit Integern. So wie ich das lese, wundert Herakles sich über den Inhalt eines einzelnen Bytes.

jupp. hier isses aber bitorder. und die kann auch big- oder little endian sein.


wlan ist scheinbar ein serielles protokoll.
von irgendwoher muessen die daten also in ein byte verpackt werden. und nachrichtentechniker moegen big endian. (ich sprech da aus erfahrung )

jedes angekommene bit wird mit dem buffer verodert, welcher anschliessend nach links geshiftet wird. so wie hier:

p=0;
for (i=0;i<8;i++)
{
  s=gets();
  printf("bit%i:%i\n",i,s);
  p<<=1;
  p|=s;
}
printf("parallel ist es:%08x\n",p);

ist das erste bit 1, so ist das ergbnis 80.

natuerlich koennte man das ganze auch so coden:

p=0;
for (i=0;i<8;i++)
{
  s=gets();
  printf("bit%i:%i\n",i,s);
  p>>=1;
  p|=(s<<7);
}
printf("parallel ist es:%08x\n",p);

oder so

p=0;
for (i=0;i<8;i++)
{
  s=gets();
  printf("bit%i:%i\n",i,s);
  p|=(s<<i);
}
printf("parallel ist es:%08x\n",p);

damit waere das ergebnis 01 statt 80.
allerdings sind die unteren beiden codebeispiele aufwaendiger.



zu der frage warum 80 und nicht 84: ich kenne den wlan-standard nicht. aber ich vermute mal dass (weil das erste bit=1 sein muss und der rest egal ist) hier eine protokollluecke ausgenutzt wird.


und nochmal ein trace zum mitschreiben:

bitnummer   bit    buffer(bin)   buffer(hex)
1            1     00000001         01
2            0     00000010         02
3            0     00000100         04
4            0     00001000         08
5            0     00010000         10
6            0     00100000         20
7            0     01000000         40
8            0     10000000         80

 

[Herakles]

Des Problems Lösung war in der Tat die Reihenfolge der Bits.

Hätte ich den Standard RICHTIG gelesen und nicht nur überflughaft, hätte ich es sehen MÜSSEN. Naja, also es ist foglendermaßen:

Bit0-Bit1: Protocol version => 0 Binär: 0, Hex: 0
Bit2-Bit3: Type => 0, Binär: 0, Hex: 0
Bit4-Bit7: Subtype =>8, Binär: 1000, Hex: 8

ALLERDINGS: Beim Subtype ist das siebte Bit die eins, die anderen Bits sind Null. Also sähe nun das komplette Byte so aus:

00000001

Da jetzt aber laut Konvention immer das höchsterwigste Bite als erstes gesendet wird, wird aus dieser 00000001 eine 10000000, was hexadezimal eine 80 ist.

Das erklärt die 80 im ersten Byte. Noch Fragen? Dann posten!

Herakles