Wireshark · Ethereal-dev: Re: [Ethereal-dev] Problem detecting 802.11b frames with CRC errors

[Guy Harris <gharris@xxxxxxxxx>]

Jim Young wrote:

> The primary trace file, frame01-99.cap, contains data sent by a 
> Cisco Access Point.   The Sniffer reports that frames 32, 49, 50, 
> 51 and 52 as having "Bad CRC", but when this trace is opened in 
> Ethereal only frames 49 and 50 are flagged with "[Malformed Packet]".

In Ethereal, "Malformed Packet" isn't used to mark arbitrary errors; 
it's generated whenever a dissector believes that there should be data 
in a packet at a particular point, but that data isn't present.  This 
could be the result of a packet that's malformed, i.e. there's supposed 
to be data there, according to the protocol, but whatever generated the 
packet didn't put any data there, or it could be the result of a problem 
in the dissector, i.e. the protocol specification allows there to be no 
data there but the dissector doesn't know that or doesn't know how to 
detect a packet where there isn't data there.

There are at least two ways for a network analyzer to determine whether 
a packet in a capture file has a bad CRC:

	if the CRC is present in the packet data, and the analyzer knows the 
algorithm used to compute or check the CRC, the analyzer can compute the 
CRC and see whether it matches the CRC in the packet data or check 
whether that CRC is valid;

	if the software that captured the packet wrote a flag with each packet 
indicating whether its CRC was correct or not, and if the analyzer knows 
where that flag is, it can report the value of that flag.

For 802.11 packets in Windows Sniffer, the CRC data doesn't appear to be 
in any captures I've seen, so, even though Ethereal does know how to 
check 802.11 CRCs, it can't do so in those captures.

For Ethernet packets in Windows Sniffer, it appears that there is a bit 
in the per-packet header before the packet data that indicates whether 
the CRC is correct; Ethereal doesn't currently use that bit - at some 
point we'll probably change the API exported by the capture-file-reading 
library in Ethereal to let Ethereal get that information, and have 
Ethereal display it.  The significance of that bit was determined by 
seeing which packets contained a CRC that wasn't valid; not having seen 
any 802.11 captures with a CRC, a similar check couldn't be done.  Now 
that you've supplied a capture with frames known to have bad CRCs (and 
with the other frames assumed to have good CRCs), we can test whether 
the same bit, or perhaps a different bit, indicates whether the CRC of 
an 802.11 frame is good or bad, so that, when we change the API in 
question, we might be able to supply that flag for 802.11 Windows 
Sniffer captures as well.

If there was an error receiving the frame, some of the frame data might 
not have been received, so that data that should be present in a frame 
isn't present, causing the frame to be reported as malformed.  That 
doesn't mean that the frame was reported as a malformed frame *because* 
Ethereal saw that it had a bad CRC, however.