Product Support
Product Activation FAQs
Downloads
Maintenance Programs
White Papers
WildPackets Forums
Technical Compendium
Additional Resources
Tip of the Month
Wireless Tips
Plugin Tips
Product Versions
Networking Books
Networking Glossary
Networking Links
Tech Support Requests
Home > Support > Additional Resources > Tip of the Month

Tip of the Month

May 2004

Corrupted and Retransmitted Packets

Corrupted packets and retransmitted packets are two of the fundamental metrics of an 802.11 WLAN. Analysis of corrupted and retransmitted packets in 802.11 differs from analysis in a wired LAN for three reasons. First, 802.11 WLANs typically have many more corrupted packets than wired LANs do, so the importance of corrupted frames in an 802.11 WLAN is enhanced. Second, 802.11 defines a reliable data link layer, meaning that every corrupted packet should result in a retransmission. Wired LANs typically do not define a reliable data link layer, so a retransmission will only occur if a reliable upper layer protocol is in use. Finally, upper-layer reliability is typically end-to-end, meaning that a corrupted packet anywhere between the source and destination will cause a retransmission. But 802.11 retransmission, since it occurs at layer 2, is implemented between wireless interfaces, so an 802.11 retransmission can only be caused by corruption on the local "segment". This makes it much easier to identify the location of corruption in an 802.11 WLAN than in a traditional wired LAN. Let's explore the implications of these differences.

One of the challenges of working in a wireless environment is that it is difficult to determine whether the analyzer is seeing the same things as the clients. Differences between the analyzer and the client--different radios, different antennae, different physical locations--can cause the analyzer to see different things than the client. As an obvious example, if the analyzer is far from the AP but the wireless client is close to the AP, the analyzer might see a corrupted frame while the station sees an uncorrupted frame. Since we know that every corrupted frame should result in a retransmission, we can use the relative numbers of retransmissions and corrupted frames to evaluate the degree to which the analyzer is seeing what the station(s) on the network are seeing.

For example, consider the case mentioned above, where the client is close to the AP and AiroPeek is far from the AP. In this case, AiroPeek will see a large number of corrupted frames (because it is so far from both the AP and the client that their signals will be weak by the time AiroPeek hears them), but AiroPeek will not see very many retransmissions (because the client, being close to the AP, hears the frames just fine, and therefore doesn't need to send any retransmissions).

Now, consider the opposite case, where AiroPeek is close to the AP and the client is far from the AP. In this case, AiroPeek will see very few corrupted frames (because it is close to the AP, and therefore sees high signal strength from the AP) and will see a larger number of retransmissions (because the station, being far from the AP, will see weak signal strength, resulting in more corruption, and causing it to retransmit). This scenario contains an important assumption: that AiroPeek is able to hear the client's retransmissions even though in this scenario AiroPeek is relatively far from the client. If AiroPeek is far enough from the client, then it won't hear the client's retransmissions at all, or the retransmissions will be received simply as corrupted packets.

In a third case, imagine that AiroPeek, the AP, and the wireless client are all relatively close to each other. In this case, each corrupted packet will result in a retransmission, and the number of corrupted packets will be relatively equal to the number of retransmissions.

In summary,

  • If AiroPeek sees many corrupted frames with few retransmissions, then AiroPeek is probably relatively far from the clients of the BSS.
  • If AiroPeek sees many retransmissions with few corrupted frames, then AiroPeek is probably roughly halfway between the AP and the clients of the BSS.
  • If AiroPeek sees roughly the same number of retransmissions and corrupted frames, then AiroPeek is probably seeing roughly the same thing as the clients of the BSS. This is the ideal scenario.

Download a demo of OmniPeek
Custom Integration & Engineering
WildPackets understands that one size does not fit all. Moreover, we all face new challenges every day. WildPackets Custom Engineering performs software development and systems integration, complementing WildPackets products and enhancing the capabilities of Network Operations Centers.
Learn more...

Network Analysis & Consulting
WildPackets offers a full spectrum of professional services, available remote and on-site. Our network engineers provide expertise for your network troubleshooting, capacity planning, or baseline performance analysis needs.
Learn more...

Tip of the Month
Don’t Lose The Tags
WildPackets’ Technical Support Team regularly receives questions about capturing VLAN (Virtual LAN) tags in packets. Some customers report that they cannot see VLAN tags when capturing packets from their switches. The tags are usually missing because the capture configuration or the location of OmniPeek (or Omni Engine) is incorrect. So, this tip is aimed at understanding VLAN tags and how they can be captured using OmniPeek Product Family.