On Nov 24, 2003, at 3:01 PM, Martin Regner wrote:
I made some own investigations based on his observations and I think
that
the frame data means something like below.
However this is just very preliminar information based on a few sample
captures, some experiments and some guessing.
...
0x03 0x00 (Tag: Flags and Status - Not sure about exactly what the
bit
mask means completely)
2 bytes for Flags and 2 bytes for Status
0x02 0x00
(FLAGS 0x02=>CRC Error, 0x04=>Frame Eror, 0x40=>Trigger,
0x06=0x04
OR 0x02=>CRC Error+Frame Error, ...)
0x02 0x00
(STATUS 0x02=>Truncated, 0x04=>Encrypted,
0x08=>
Decryption error, 0x40=> Short preamble)
Note: the value shown for FLAGS and STATUS shown in Airopeek doesn't
always
correspond to the values stored in the file.
What are some of the differences?
(In Martijn's original capture - the 11g-bug-gw-smc.apc one - there
were packets with CRC errors according to Ethereal - it turns out that
a media subtype value of 1 appears to mean "802.11 with 4 bytes of 0 at
the end" and 3 appears to mean "802.11 with 4 bytes of FCS at the end"
- that didn't have the "CRC Error" flag set. They appeared to be
largely duplicates of other packets; in at least two of the cases, at
least one of the other packets had a valid CRC, and the duplicates with
the bad CRC appeared to have bad data in them, e.g. the SSID appeared
to be corrupt. Could these be duplicates caused by multipath problems,
so that multiple copies of the packet arrived by different paths? In
those two cases, the bad copies showed up after the good copies;
perhaps the NIC keeps track of received packets, e.g. remembering
sequence numbers and perhaps addresses and, if it sees a duplicate
packet, supplies it to the host, at least in monitor mode, but doesn't
bother to checksum it - and doesn't supply any "probably multipath"
indicator?)
0x07 0x00 (Tag: Signal level dBm)
0x01 0x80 0xff 0xff
That's -32767; did it display that value? (You said it didn't show
that value for "Noise level dBm".)