Each wireless frame consists of the following basic
MAC header that includes frame control, duration, address, and
sequence control information.
variable length frame body that contains information specific to
the frame type.
frame check sequence (FCS) that contains a 4-byte cyclic redundancy
The last component, FCS, is used to check the integrity of the
packet on the receiving end. The receiving end computes the CRC
value over the received frame and compares the computed value with
the actual four bytes at the end of the packet. If the values
mismatch, the packet is considered damaged.
The way CommView for WiFi handles such corrupted frames depends on
the user-defined settings. By default, such frames are ignored by
the application, with the following exceptions:
increment the overall packet and byte counters.
increment the CRC Error counter on the
are included in the Packet Size chart in the
Damaged frames are not counted in other charts and tables for the
obvious reason: No part of a frame with the wrong CRC value is
credible. It may have a completely wrong IP address, data payload,
etc., although in real life such frames bear a resemblance to the
original. For the same reason CRC Errors cannot be attributed to a
particular wireless AP or station, as it's impossible to determine
the real sender's MAC address.
Nevertheless, the user may want to check the
Capture damaged frames
box in the options, in which case damaged frames will also be shown
in the packet list. By default, such frames are marked with red and
have the "CRC" identifier shown in the
column of the
It is important to understand that a frame received with a CRC
error by CommView for WiFi may have been received by the
destination node without an error. Despite the fact that damaged
frames are supposed to be discarded by the destination node without
further processing, CommView for WiFi will attempt to decode and
even decrypt such frames.
Not all the wireless adapters are capable of passing damaged frames
to the application level. Such functionality is guaranteed only for
the recommended adapters supported by CommView for WiFi.
Integrity Check Value (ICV) is a 4-byte checksum used in WEP- and
WPA-encrypted frames for verifying the result of decryption. The
receiving end computes the ICV value over the data portion of the
received frame and compares the computed value with the actual four
bytes at the end of the packet's data portion. If the values
mismatch, the decryption is considered unsuccessful.
CommView for WiFi is capable of on-the-fly WEP and WPA decryption,
provided the correct
have been entered by the user. The program shows ICV-related
information in three different places: On the
tabs and in the
column of the
tab. The way ICV errors are shown and counted by the program
depends on whether the key has been entered as well as on its
correctness. There different cases are possible:
key has been entered by the user, and it is correct for the given
key has been entered by the user, but it is incorrect for the given
key has been entered.
In the first case, you should see very few ICV errors reported by
the program. In the second case, all of the captured data frames
will be marked with the ICV Error flag because the computed and the
actual ICV values will not match if the wrong key is used for
decryption. In the third case, no frames will have ICV errors
because no decryption attempts will be made.
As explained above, unlike "hard" CRC errors, ICV errors are "soft"
errors that depend on the decryption key. Your WLAN may be
perfectly healthy, but if you entered the wrong WEP key in CommView
for WiFi, you will observer many ICV errors. Because of its
"softness," packets with ICV errors are, by default, shown in the
same color as any other packets. This can be changed using the
If a frame has a CRC error, detecting an ICV error makes no point.
Therefore, CommView for WiFi never sets the ICV error flag for
frames with CRC errors.