Understanding CRC and ICV Errors

CRC Errors

Each wireless frame consists of the following basic components:

·A MAC header that includes frame control, duration, address, and sequence control information.

·A variable length frame body that contains information specific to the frame type.

·A frame check sequence (FCS) that contains a 4-byte cyclic redundancy code (CRC).

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:

·They increment the overall packet and byte counters.

·They increment the CRC Error counter on the Channels tab.

·They are included in the Packet Size chart in the Statistics window.

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 Errors column of the Packets tab:

It's 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 new 802.11b/g, 802.11a/b/g, and 802.11b/g/n adapters supported by CommView for WiFi.

ICV Errors

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 WEP/WPA key(s) have been entered by the user. The program shows ICV-related information in three different places: On the Nodes and Channels tabs and in the Errors column of the Packets 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:

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 program's Options dialog.

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.