["Martin Regner" <martin.regner@xxxxxxxxx>]

Guy Harris wrote:
>
> 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?

When I modified the Flags/Status bytes in the capture file I didn't get
exactly the same values when I looked
in Airopeek.  It seemed to make an logical AND with a certain bitmask to
just read some bits from file and
then the result was ORed with some other Flags/Status bits that was
determined by Airopeek when reading the frame.

So if the Flag byte is set to 0x03 in the file, it may appear as "0x02  CRC
Error" in Airopeek.

Not all the Flags/Status shown on Varsanofiev's page
http://www.varsanofiev.com/inside/airopeekv9.htm is stored in the file.
The "Sliced" flag seems to be set when the "slice length" is not the same as
the "frame length".

There seemed also to be some Flags/Status values that was not shown with a
corresponding name.

The Status was shown with numeric value "0x01" for the first frame in all or
most of the captures I tried with, but in the file the Status is 0x00.
There was no corresponding text that showed what the flag meant.

It also seems that Status bit value "0x10" is set when there is a frame note
corresponding to that frame, and that is determined when reading in the
*.ann file that coresponds to the apc-file.
If you open "demo.apc" file (included with Airopeek) there is a
corresponding "demo.ann" file that
will also be read by Airopeek that contains notes for some frames (1, 12,
14, ...).

>
> (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?)

It's just for frame number 3 that I see that Flag is set to "CRC Error"
(0x02 in the file and 0x02 in the GUI) when I read 11g-bug-gw-smc.apc
into Airopeek, but FCS is shown for each packet and there are several frames
where you see "FCS invalid, should be ...".
The FCS seems to be incorrect for e.g. the following frames 1, 3, 7, 20, 21,
22, 23 ...

>
> > 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".)
>

Value 0x01 0x80 0xff 0xff means that the value is not shown both for "Signal
level dBm" and "Noise level dBm".

However I don't think that I have seen any real capture where the value 0x01
0x80 0xff 0xff is used for Signal level dBm,
but several where "Noise level dBm" is set to that value.

Actually I made a mistake when I put together the mail. I was going to put
e.g. 0xDD 0xFF 0xFF 0xFF for "Signal level dBm".