Wifi Frame Format - Learning Module

Loading content...

0/228

Fragmentation

Dividing to Conquer: The Fragmentation Trade-off

In an ideal wireless environment, we would transmit the largest possible frames to maximize efficiency—every byte of header overhead amortized across more payload bytes. But wireless networks are far from ideal. Radio interference, multipath fading, and competing transmissions can corrupt frames in transit. When a large frame is corrupted, the entire frame must be retransmitted, wasting all the airtime spent on the initial transmission.

Fragmentation offers a strategic middle ground. By splitting large frames into smaller fragments, we limit the retransmission cost when errors occur—only the corrupted fragment needs to be resent, not the entire frame. However, this protection comes at a cost: each fragment carries its own MAC header, requires its own acknowledgment, and consumes additional SIFS intervals.

Understanding when and how to use fragmentation is essential for optimizing WiFi performance in challenging RF environments. In this final section of our frame format module, we'll explore the fragmentation mechanism in complete detail.

What You Will Learn

By the end of this page, you will understand the fragmentation mechanism and its triggers, fragment numbering and the role of sequence control, how receivers reassemble fragments, the fragmentation threshold and its configuration, performance trade-offs and when to use fragmentation, and the difference between 802.11 fragmentation and IP fragmentation.

Why Fragment?

Fragmentation addresses the fundamental trade-off between efficiency and reliability in wireless transmission:

The Large Frame Problem:

Large Frame Vulnerability
Large Frame Transmission Without Fragmentation:
 
Frame: 2000 bytes payload + header = ~2040 bytes total
Transmission time at 54 Mbps: ~300 μs
 
Error probability increases with frame length.
If BER (Bit Error Rate) = 10⁻⁵ (1 error per 100,000 bits):
 
Frame bits = 2040 × 8 = 16,320 bits
P(frame error) = 1 - (1 - BER)^bits
               = 1 - (1 - 10⁻⁵)^16320
               ≈ 15% chance of at least one bit error
 
If frame is corrupted:
  - Entire 300 μs of airtime WASTED
  - Must wait for timeout (no ACK)
  - Must retransmit entire 2040-byte frame
  - Adds ~600+ μs delay (original transmission + retry)

The Fragmentation Solution:

Fragmented Frame Transmission
Same 2000 bytes fragmented into 4 × 512-byte fragments:
 
Fragment 0: 512 bytes + ~30 byte header = ~542 bytes, ~80 μs
Fragment 1: 512 bytes + ~30 byte header = ~542 bytes, ~80 μs
Fragment 2: 512 bytes + ~30 byte header = ~542 bytes, ~80 μs
Fragment 3: 464 bytes + ~30 byte header = ~494 bytes, ~73 μs
 
Per-fragment error probability:
P(fragment error) = 1 - (1 - 10⁻⁵)^4336 ≈ 4.2%
 
If Fragment 2 is corrupted:
  - Only 80 μs wasted (not 300 μs)
  - Fragment 2 retransmitted (~80 μs + SIFS + ACK)
  - Other fragments already successfully received
  - Total extra time: ~100 μs (vs ~600 μs for full retransmit)
 
Trade-off: Added overhead
  - 4 ACKs instead of 1 (4 × ~10 μs)
  - 3 extra headers (~90 bytes)
  - 3 extra SIFS intervals (~30 μs)
  - Total overhead: ~130 μs additional for normal case

Fragmentation Benefits

•Reduced retransmission cost
•Lower latency for partial delivery
•Better performance in noisy environments
•Smaller collision windows

Fragmentation Costs

•Increased header overhead
•More ACKs required
•Additional SIFS intervals
•Receiver buffer requirements

When Fragmentation Helps

Fragmentation is most beneficial when the Bit Error Rate is high (noisy environment), hidden terminals cause frequent collisions, and the fragmentation threshold is set appropriately for the error rate. In clean RF environments with low BER, fragmentation overhead exceeds its benefits.

Fragmentation Threshold

The fragmentation threshold is the maximum MSDU size that will be transmitted without fragmentation. Any MSDU (MAC Service Data Unit—the payload from upper layers) exceeding this threshold is fragmented.

Threshold Configuration:

Fragmentation Threshold Values
Threshold Value	Effect	Use Case
2346 bytes (default)	No fragmentation (max MSDU)	Normal operation, clean RF
1500 bytes	Only large frames fragmented	Moderate interference
1024 bytes	Most data frames fragmented	High interference
512 bytes	Aggressive fragmentation	Very noisy environment
256 bytes (minimum)	Maximum fragmentation	Extreme conditions only

Linux Fragmentation Configuration
# Check current fragmentation threshold
iwconfig wlan0
  ...
  Fragment thr=2346 B    # Default: no fragmentation
 
# Set fragmentation threshold to 1024 bytes
sudo iwconfig wlan0 frag 1024
  Fragment thr=1024 B    # Frames > 1024 will be fragmented
 
# Disable fragmentation (use maximum)
sudo iwconfig wlan0 frag off
  Fragment thr=2346 B    # Back to default
 
# Using iw (modern utility)
sudo iw dev wlan0 set frag 1024
 
# View current setting
iw dev wlan0 info

How Fragmentation Decision Works:

When upper layer delivers MSDU to MAC layer:

IF MSDU_size > Fragmentation_Threshold:
    fragments = ceil(MSDU_size / Fragmentation_Threshold)
    Split MSDU into 'fragments' pieces
    Each piece gets own MAC header
    Fragment Number: 0, 1, 2, ... (n-1)
    More Fragments bit: 1 for all except last fragment
    Same Sequence Number for all fragments
ELSE:
    Transmit as single frame
    Fragment Number = 0
    More Fragments bit = 0

Important Distinction:

The threshold applies to the MSDU (payload before MAC header)
Each fragment's total frame size = fragment payload + MAC header + FCS
Fragments are not required to be equal size; the last fragment may be smaller

Threshold vs. RTS Threshold

Don't confuse fragmentation threshold with RTS threshold! RTS threshold triggers RTS/CTS exchange for frames above a size. Fragmentation threshold triggers frame splitting. Both are independent: a fragmented frame may or may not use RTS/CTS depending on fragment size vs. RTS threshold.

Fragment Structure and Control Fields

Each fragment is a complete 802.11 frame with its own header. The Sequence Control field and Frame Control flags coordinate fragment identification and reassembly.

Sequence Control Field in Fragments:

Sequence Control in Fragments
Sequence Control Field (16 bits):
 
┌──────────────────────────────────────────────────────────────────┐
│ Bits 0-3: Fragment Number │ Bits 4-15: Sequence Number          │
│ (4 bits = 0-15)           │ (12 bits = 0-4095)                   │
└──────────────────────────────────────────────────────────────────┘
 
For a fragmented MSDU with Sequence Number 1234:
 
Fragment 0: Sequence Control = 0x1234 >> Not quite...
            Actually: SeqNum in bits 4-15, FragNum in bits 0-3
            Hex representation: 0xD20 | 0x0 = sequence 3296 >> example issue
            
Let's use decimal for clarity:
Fragment 0: SeqNum=1234, FragNum=0  → SeqCtrl = (1234 << 4) | 0 = 19744
Fragment 1: SeqNum=1234, FragNum=1  → SeqCtrl = (1234 << 4) | 1 = 19745
Fragment 2: SeqNum=1234, FragNum=2  → SeqCtrl = (1234 << 4) | 2 = 19746
Fragment 3: SeqNum=1234, FragNum=3  → SeqCtrl = (1234 << 4) | 3 = 19747
 
Key Point: ALL fragments share the SAME Sequence Number.
The Fragment Number distinguishes fragments within the same MSDU.

Frame Control Flags for Fragmentation:

Flag	Location	Role in Fragmentation
More Fragments	Bit 10	Set to 1 if more fragments follow; 0 for last fragment
Retry	Bit 11	Set to 1 if this is a retransmission of a fragment
Protected Frame	Bit 14	Each fragment encrypted individually

Fragment Frame Structure:

Individual Fragment Structure
Original MSDU: 2000 bytes payload
Fragmentation threshold: 512 bytes
Result: 4 fragments
 
Fragment 0 (first):
┌────────────────────────────────────────────────────────────────────────────┐
│ Frame Control │ Dur │ Addr1 │ Addr2 │ Addr3 │ SeqCtrl   │ Fragment    │FCS│
│ Type=Data     │     │       │       │       │ Seq=1234  │ Payload     │   │
│ MoreFrag=1    │     │       │       │       │ Frag=0    │ (512 bytes) │   │
└────────────────────────────────────────────────────────────────────────────┘
 
Fragment 1 (middle):
┌────────────────────────────────────────────────────────────────────────────┐
│ Frame Control │ Dur │ Addr1 │ Addr2 │ Addr3 │ SeqCtrl   │ Fragment    │FCS│
│ Type=Data     │     │       │       │       │ Seq=1234  │ Payload     │   │
│ MoreFrag=1    │     │       │       │       │ Frag=1    │ (512 bytes) │   │
└────────────────────────────────────────────────────────────────────────────┘
 
Fragment 2 (middle):
┌────────────────────────────────────────────────────────────────────────────┐
│ Frame Control │ Dur │ Addr1 │ Addr2 │ Addr3 │ SeqCtrl   │ Fragment    │FCS│
│ Type=Data     │     │       │       │       │ Seq=1234  │ Payload     │   │
│ MoreFrag=1    │     │       │       │       │ Frag=2    │ (512 bytes) │   │
└────────────────────────────────────────────────────────────────────────────┘
 
Fragment 3 (last):
┌────────────────────────────────────────────────────────────────────────────┐
│ Frame Control │ Dur │ Addr1 │ Addr2 │ Addr3 │ SeqCtrl   │ Fragment    │FCS│
│ Type=Data     │     │       │       │       │ Seq=1234  │ Payload     │   │
│ MoreFrag=0    │     │       │       │       │ Frag=3    │ (464 bytes) │   │
└────────────────────────────────────────────────────────────────────────────┘
 
Each fragment is acknowledged individually!

Maximum Fragment Count

The Fragment Number field is 4 bits, limiting fragments to 0-15 (16 fragments maximum). With a minimum fragment size of 256 bytes, this limits the maximum fragmentable MSDU to 16 × 256 = 4096 bytes—well above the typical MTU.

Fragment Transmission Process

Fragment transmission follows a strict sequence with individual acknowledgments. The sender must receive an ACK for each fragment before transmitting the next.

Fragment Transmission Timeline:

Fragment Transmission Sequence
Fragment Burst Transmission (3 fragments):
 
┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│ Sender:     ┌──Frag0──┐ SIFS ┌──Frag1──┐ SIFS ┌──Frag2──┐                   │
│             │ MF=1    │      │ MF=1    │      │ MF=0    │                   │
│             │ FN=0    │      │ FN=1    │      │ FN=2    │                   │
│             └─────────┘      └─────────┘      └─────────┘                   │
│                    ↓              ↓              ↓                          │
│ Receiver:         ┌─ACK─┐       ┌─ACK─┐       ┌─ACK─┐                       │
│                   └─────┘       └─────┘       └─────┘                       │
│                                                                              │
│ Timeline:                                                                    │
│ t0    t1  t2    t3  t4    t5  t6    t7  t8  t9                             │
│ ├──frag0──┤SIFS├ACK─┤SIFS├─frag1──┤SIFS├ACK─┤SIFS├─frag2──┤SIFS├ACK─┤     │
│                                                                              │
│ Note: SIFS (Short Interframe Space) used between ALL these exchanges        │
│       because fragments constitute a single TXOP                             │
└─────────────────────────────────────────────────────────────────────────────┘
 
Duration Field in Each Fragment:
  Fragment 0: Duration = SIFS + ACK + SIFS + Frag1 + SIFS + ACK + SIFS + Frag2 + SIFS + ACK
  Fragment 1: Duration = SIFS + ACK + SIFS + Frag2 + SIFS + ACK
  Fragment 2: Duration = SIFS + ACK

RTS/CTS with Fragmentation:

If the first fragment exceeds the RTS threshold, RTS/CTS is used only for the first fragment. Subsequent fragments are protected by the NAV set by the initial RTS.

With RTS/CTS for fragment burst:

RTS → CTS → Frag0 → ACK → Frag1 → ACK → Frag2 → ACK

RTS Duration covers the ENTIRE fragment burst.
CTS Duration = RTS Duration - SIFS - CTS_time

Fragment Failure Handling:

If an ACK is not received for a fragment:

Sender waits for ACK timeout
Sender enters backoff procedure
Sender retransmits the failed fragment with Retry bit = 1
If eventually successful, continue with next fragment
If retry limit exceeded, entire MSDU is discarded

Retry Limit per Fragment

The short retry limit (typically 7) applies to each fragment, not the entire MSDU. If any fragment fails after maximum retries, the entire MSDU is discarded—even fragments already acknowledged. This is a key performance consideration; high error rates can cause total MSDU loss.

Fragment Reassembly

The receiver must reassemble fragments before delivering the complete MSDU to upper layers. This process requires buffering, ordering, and timeout management.

Reassembly Algorithm:

Fragment Reassembly Process
Fragment Reassembly State Machine:
 
On receiving a frame with (SA, SeqNum, FragNum):
 
1. LOOKUP existing reassembly context for (SA, SeqNum):
   - If none exists and FragNum ≠ 0:
       DISCARD fragment (missed first fragment)
   - If none exists and FragNum = 0:
       CREATE new reassembly context
       START reassembly timer
 
2. VALIDATE fragment:
   - Fragment must have expected FragNum (next in sequence)
   - If FragNum is duplicate (already received):
       DISCARD duplicate, but still send ACK
   - If FragNum is out of order:
       DISCARD (802.11 does NOT reorder fragments)
 
3. APPEND fragment payload to reassembly buffer
 
4. CHECK More Fragments bit:
   - If MoreFrag = 1:
       WAIT for next fragment
   - If MoreFrag = 0:
       REASSEMBLY COMPLETE
       Deliver MSDU to upper layer
       Delete reassembly context
 
5. TIMEOUT handling:
   - If reassembly timer expires before completion:
       DISCARD all received fragments
       Delete reassembly context

Reassembly Buffer Management:

Receivers must maintain buffers for in-progress reassembly. Resource constraints require careful management:

Parameter	Typical Value	Purpose
Max concurrent reassemblies	3-10	Limit memory usage
Reassembly timeout	1-3 seconds	Prevent stale buffer accumulation
Buffer size per reassembly	Up to 2346 bytes	Maximum MSDU size

Fragment Caching Attack

A malicious sender could exhaust receiver reassembly buffers by starting many incomplete fragment sequences. Modern implementations limit concurrent reassemblies per source address and implement aggressive timeouts to mitigate this attack.

Encryption and Fragmentation

When encryption is enabled, each fragment is encrypted independently. This has important security and implementation implications.

Per-Fragment Encryption:

Fragment Encryption Order
Encryption/Decryption with Fragmentation:
 
TRANSMISSION (Encryption):
1. Upper layer delivers MSDU (plaintext payload)
2. MAC layer fragments MSDU into multiple pieces
3. Each fragment is encrypted SEPARATELY:
   - Fragment 0: Encrypt(plaintext_0) + MIC_0
   - Fragment 1: Encrypt(plaintext_1) + MIC_1
   - Fragment 2: Encrypt(plaintext_2) + MIC_2
4. Add unencrypted 802.11 header to each fragment
5. Transmit fragments
 
RECEPTION (Decryption):
1. Receive and ACK each fragment
2. Decrypt each fragment as it arrives
3. Buffer decrypted fragment payloads
4. When MoreFrag=0:
   - Concatenate fragment payloads
   - Deliver reassembled MSDU to upper layer
 
Key Security Point:
  Each fragment has its OWN IV (Initialization Vector) or PN (Packet Number)
  This prevents attacks that rely on IV reuse across fragments

TKIP and Fragment Attacks:

The deprecated TKIP (Temporal Key Integrity Protocol) had a vulnerability related to fragmentation:

TKIP's MIC (Message Integrity Code) was calculated over the complete MSDU
But the MIC was only transmitted with the last fragment
Attackers could replay old fragments with new IVs in some scenarios

CCMP (WPA2/WPA3) Improvements:

Each fragment has its own MIC/authentication tag
Packet Number (PN) prevents replay of individual fragments
No fragment-related cryptographic vulnerabilities known

FragAttacks Vulnerability (2021)

In 2021, researcher Mathy Vanhoef disclosed 'FragAttacks'—vulnerabilities in how many WiFi implementations handle fragments. Bugs included accepting non-consecutive fragments, mixing fragments from different connections, and reassembling plaintext and encrypted fragments. These were implementation bugs, not protocol flaws. Ensure your WiFi drivers are patched.

Fragmentation vs. Aggregation

Modern 802.11n/ac/ax networks emphasize aggregation (combining multiple frames) rather than fragmentation (splitting single frames). Understanding both mechanisms clarifies when each is appropriate.

Aggregation Types:

Aggregation vs. Fragmentation
Mechanism	Direction	Purpose	Introduced
Fragmentation	Split 1 → N	Improve reliability in noisy RF	802.11 original
A-MSDU	Combine N → 1	Reduce per-frame overhead	802.11n
A-MPDU	Combine N → 1	Combine MPDUs for efficiency	802.11n

A-MSDU vs. A-MPDU
A-MSDU (Aggregate MSDU):
┌────────────────────────────────────────────────────────────────────────────┐
│ MAC Header │ MSDU1 │ MSDU2 │ MSDU3 │ ... │ MSDU_n │ FCS                    │
│ (single)   │ (DA,SA,Len,Payload) × n                    │                    │
└────────────────────────────────────────────────────────────────────────────┘
  - Multiple MSDUs share ONE MAC header
  - Max A-MSDU: 7935 bytes (802.11n), 11454 bytes (802.11ac)
  - All MSDUs must have same TID and destination
  - If A-MSDU corrupted, ALL MSDUs lost
 
A-MPDU (Aggregate MPDU):
┌────────────────────────────────────────────────────────────────────────────┐
│ Delimiter│ MPDU1 │ Delimiter│ MPDU2 │ Delimiter│ MPDU3 │ ...               │
└────────────────────────────────────────────────────────────────────────────┘
  - Each MPDU has its OWN header and FCS
  - Delimiters mark MPDU boundaries
  - Up to 64 MPDUs in 802.11n, 256 in 802.11ac
  - If one MPDU corrupted, others still valid
  - Block ACK indicates which MPDUs need retry

Modern Preference:

In contemporary networks, A-MPDU + Block ACK is strongly preferred:

Comparison	Fragmentation	A-MPDU
Error recovery	Per-fragment retry	Block ACK bitmap retry
Overhead	High (per-fragment headers)	Medium (delimiters + bitmap)
Throughput	Reduced	Near-optimal
Typical use	Legacy/noisy environments	All modern deployments

When Fragmentation Still Matters:

Legacy devices (802.11a/b/g)
Extremely noisy RF environments
Specific regulatory or industrial requirements

802.11ax Fragmentation

802.11ax introduces dynamic fragmentation based on channel conditions. The AP can adjust fragment sizes in real-time based on observed error rates. However, most 802.11ax deployments still favor A-MPDU aggregation unless conditions are particularly challenging.

802.11 vs. IP Fragmentation

Fragmentation can occur at multiple layers of the network stack. Understanding the differences between 802.11 (Layer 2) and IP (Layer 3) fragmentation clarifies their respective roles.

Layer Comparison:

802.11 vs. IP Fragmentation
Aspect	802.11 Fragmentation	IP Fragmentation
Layer	Data Link (Layer 2)	Network (Layer 3)
Triggered by	Fragmentation threshold at transmitter	MTU smaller than packet
Reassembly point	Immediate receiver	Final destination
Individual ACKs	Yes (per fragment)	No (IP is connectionless)
Lost fragment handling	MAC layer retry	Entire IP packet lost
Overhead added	MAC header per fragment	IP header per fragment
Fragment numbering	4 bits (0-15)	13 bits (offset × 8 bytes)

Layer Interaction
Packet Flow with Both Fragmentations (Unusual Case):
 
Upper Layer:  ┌─────────────────────────────────────┐
              │        3500-byte UDP datagram       │
              └─────────────────────────────────────┘
                               │
IP Layer:     ┌────────────┐ ┌────────────┐ ┌──────────┐
              │ IP Frag 0  │ │ IP Frag 1  │ │ IP Frag 2│
              │ 1500 bytes │ │ 1500 bytes │ │ 500 bytes│
              └────────────┘ └────────────┘ └──────────┘
                    │              │              │
802.11 Layer:       │              │              │
              Each IP fragment potentially fragmented further
              if > 802.11 fragmentation threshold:
 
              ┌──────┐┌──────┐  ┌──────┐┌──────┐  ┌──────┐
              │F0.0  ││F0.1  │  │F1.0  ││F1.1  │  │F2.0  │
              │750B  ││750B  │  │750B  ││750B  │  │500B  │
              └──────┘└──────┘  └──────┘└──────┘  └──────┘
 
Reassembly:
- Receiver reassembles 802.11 fragments immediately
- IP fragments travel to final destination
- Final destination reassembles IP fragments
- Application receives original 3500-byte datagram

Path MTU Discovery

Modern networks use Path MTU Discovery to avoid IP fragmentation by adjusting packet sizes. With PMTUD, packets are sized to fit the smallest MTU along the path. This makes 802.11 fragmentation the only fragmentation that typically occurs—and even that is uncommon with the default threshold of 2346 bytes.

Performance Considerations

Setting the fragmentation threshold requires balancing reliability against overhead. Here's a practical framework for decision-making.

Performance Impact Analysis:

Throughput Comparison
Throughput with Different Fragmentation Thresholds:
 
Assumptions:
- 1500-byte IP packets (typical)
- 54 Mbps data rate
- SIFS = 10 μs, ACK = 14 μs at basic rate
- MAC overhead: 34 bytes header + 4 bytes FCS = 38 bytes
 
No Fragmentation (threshold = 2346):
  Frame = 1500 + 38 = 1538 bytes → 228 μs at 54 Mbps
  Exchange = Frame + SIFS + ACK = 228 + 10 + 14 = 252 μs
  Throughput = 1500 bytes / 252 μs = 47.6 Mbps effective
 
Threshold = 750 bytes (2 fragments):
  Fragment 0 = 750 + 38 = 788 bytes → 117 μs
  Fragment 1 = 750 + 38 = 788 bytes → 117 μs
  Exchange = Frag0 + SIFS + ACK + SIFS + Frag1 + SIFS + ACK
           = 117 + 10 + 14 + 10 + 117 + 10 + 14 = 292 μs
  Throughput = 1500 bytes / 292 μs = 41.1 Mbps effective
  
  COST: 14% throughput reduction in clean RF
 
But with 10% frame error rate:
  No frag: 10% of 1500B frames lost → retry overhead
           Effective ≈ 43 Mbps after retries
  
  With frag: 10% of 750B fragments lost → partial retries
             Effective ≈ 40 Mbps after retries
             BUT: lower latency variance, more consistent delivery

Practical Guidelines:

Fragmentation Threshold Recommendations
Environment	Recommended Threshold	Rationale
Clean RF, modern devices	2346 (disabled)	Maximum throughput
Light interference	2346 (disabled)	Aggregation handles errors better
Heavy interference, legacy	1024-1500	Balance overhead vs. retry cost
VoIP/real-time critical	Consider lower	Reduce per-packet latency variance
Industrial/high-noise	512-1024	Prioritize delivery over throughput

Monitor Before Changing

Before adjusting the fragmentation threshold, capture baseline metrics: retry rates, throughput, and latency. Enable fragmentation incrementally and measure impact. In most modern networks, the default (disabled) is optimal. Only enable if you observe specific issues that fragmentation can address.

Summary: Mastering 802.11 Fragmentation

We've explored every aspect of 802.11 fragmentation. Here are the essential takeaways:

Key Takeaways

•Fragmentation splits large MSDUs into smaller fragments, each with its own MAC header and FCS, reducing retransmission cost when errors occur.
•The fragmentation threshold determines when fragmentation occurs; default 2346 bytes effectively disables it in most deployments.
•All fragments share the same Sequence Number; the Fragment Number (0-15) distinguishes fragments within an MSDU.
•Each fragment is acknowledged individually using SIFS timing between fragment and ACK.
•Fragment reassembly occurs at the immediate receiver with timeout-based buffer management.
•Per-fragment encryption ensures each fragment has independent cryptographic protection.
•Modern networks prefer A-MPDU aggregation over fragmentation due to superior efficiency and Block ACK retry handling.
•802.11 fragmentation differs from IP fragmentation in layer, reassembly point, and acknowledgment semantics.

Module Complete:

This concludes our comprehensive exploration of WiFi Frame Format. You've mastered:

Frame Types — Management, Control, and Data frames and their subtypes
Frame Structure — Every field of the 802.11 MAC header
Address Fields — All four addressing scenarios and their interpretation
Duration Field — Virtual carrier sensing and NAV operation
Fragmentation — When and how frames are split for transmission

This knowledge forms the foundation for advanced topics including wireless security analysis, protocol debugging, and performance optimization.

Module Complete

Congratulations! You now have comprehensive knowledge of IEEE 802.11 WiFi frame formats. This understanding enables you to analyze packet captures at the frame level, troubleshoot wireless connectivity issues, and understand the fundamental mechanisms that make WiFi work.