Ethereal-dev: RE: [Ethereal-dev] Ethereal 0.9.16 doesn't read AiroPeek 2.0 files

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Martijn Schipper" <mschipper@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 9 Feb 2004 10:52:02 +0100
Martin Regner wrote:

> Guy Harris wrote:
> > (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?)
> 
> I have no idea about why some packets seems to be corrupt.
> My experience with 802.11 is very limited so far.
> Maybe Martijn knowns more about under what circumstances the capture
was
> done.

I didn't do the capture myself otherwise I would have used Ethereal :-)
We receive a lot of AiroPeek files from costumers, so that's why I
wanted the option to read AiroPeek V9 files with Ethereal.
Guy says he sees a lot of duplicate packets in the sniff. That is
because these packets are retransmitted by the MAC. You can see this by
inspecting the wlan.fc.retry flag. And in most cases the sniffer is a
different machine than the receiving station. That can explains why a
frame that is marked with a FCS error (by the sniffer) is not
retransmitted (because the receiving station did receive this frame
without an FCS error).
The sniff file it self doesn't contain a very common 802.11 scenario. I
can send another one if that will help?

Martijn.


******************Legal Disclaimer**************************
"This email may contain confidential and privileged material for the sole use of the intended recipient.  Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the message in error, please advise the sender by reply email @globespanvirata.com, and delete the message. Thank you."
************************************************************