What Is RTS/CTS in WiFi?
Table of Contents
The Hidden Node Problem
WiFi's CSMA/CA protocol depends on carrier sense - listening to the channel before transmitting. This works when all devices can hear each other. It fails when they cannot.
Consider three devices: Station A on one side of a building, Station C on the other side, and an access point (B) in the middle. A and C can both communicate with B, but they cannot hear each other directly. When A starts transmitting to B, C does not detect the transmission (it is out of range). C performs carrier sense, finds the channel idle, and starts transmitting at the same time. Both signals arrive at B simultaneously and collide. Neither A nor C understands why its transmission failed.
This is the hidden node problem. It is common in any WiFi deployment where the coverage area is large enough that clients at opposite edges cannot hear each other. Hotels, conference centers, warehouses, and multi-floor offices all have hidden node issues.
How RTS/CTS Works
RTS/CTS (Request to Send / Clear to Send) is a channel reservation mechanism defined in 802.11. Instead of transmitting data immediately, the sender first asks for permission:
- Station A sends a short RTS (Request to Send) frame to the access point B. The RTS includes a Duration field specifying how long the entire exchange (RTS + CTS + Data + ACK) will take.
- If the channel is clear, B responds with a CTS (Clear to Send) frame, also including the Duration field.
- A transmits its data frame.
- B sends an ACK confirming receipt.
The key insight is that Station C cannot hear A's RTS, but it can hear B's CTS (because C is within range of B). When C receives the CTS, it reads the Duration field and sets its NAV (Network Allocation Vector) timer to that value. C will not transmit until the NAV timer expires, even if carrier sense shows the channel as idle.
The NAV Timer
The NAV is a virtual carrier sense mechanism. It supplements the physical carrier sense (measuring energy on the channel) with information from the Duration field in received frames.
When a device receives any frame with a Duration value (not just CTS - all 802.11 frames have a Duration field), it updates its NAV if the received Duration is longer than the time remaining on its current NAV. The device treats the channel as busy until the NAV expires, regardless of what physical carrier sense detects.
This is what makes RTS/CTS effective against hidden nodes. The CTS broadcast from the access point sets the NAV on every device within range of the AP, including devices that are hidden from the original sender. All of them defer their transmissions until the reserved period ends.
sequenceDiagram
participant A as Station A
participant AP as Access Point
participant C as Station C (hidden)
A->>AP: RTS (request channel)
AP->>A: CTS (channel reserved)
AP->>C: CTS (channel reserved)
Note over C: Sets NAV timer, defers
A->>AP: Data frame
AP->>A: ACK
Note over C: NAV expires, can transmit
The RTS Threshold
RTS/CTS is not used for every frame. The overhead of two extra frames (RTS + CTS) per data frame would reduce throughput significantly, especially for small frames where the RTS/CTS exchange takes longer than the data frame itself.
The RTS threshold setting determines the minimum frame size that triggers RTS/CTS. Frames smaller than the threshold are sent directly using normal CSMA/CA. Frames larger than the threshold use RTS/CTS first.
The default RTS threshold on most access points is 2347 bytes (effectively disabled, since the maximum 802.11 frame is 2346 bytes). Lowering the threshold to, say, 500 bytes means any frame larger than 500 bytes will use RTS/CTS. Setting it to 0 means every frame uses RTS/CTS (maximum collision protection but highest overhead).
The right threshold depends on the environment. In a small room with few clients and no hidden nodes, RTS/CTS adds unnecessary overhead. In a large venue with many clients and known hidden node issues, a lower threshold improves reliability at the cost of some throughput.
The Overhead Cost
RTS/CTS adds two frames to every protected exchange. On a quiet network, this roughly doubles the airtime for small data frames. On a congested network with hidden nodes, the reduction in collisions more than compensates for the overhead - retransmitting a collided 1500-byte frame wastes far more airtime than the RTS/CTS handshake consumes.
The RTS and CTS frames are small (20 bytes each) and transmitted at the lowest mandatory data rate, ensuring they are received reliably by all devices. This means they occupy the channel for a relatively short time compared to the data frame they protect.
802.11ac and 802.11ax introduced variations on the RTS/CTS concept for multi-user MIMO and OFDMA, where the AP uses a trigger frame to coordinate simultaneous transmissions from multiple clients. The principle is the same: reserve the channel before transmitting to prevent collisions.
RTS/CTS and Security Testing
RTS/CTS frames are management frames transmitted in the clear (unencrypted, even on WPA2/WPA3 networks). This means they are visible to any monitoring device on the channel.
An attacker can forge CTS frames to silence other devices on the channel. By continuously sending CTS frames with large Duration values, the attacker forces all devices within range to set their NAV timers and defer transmission indefinitely. This is a CTS flood denial-of-service attack - the attacker does not need to send deauth frames or overpower the legitimate signal. The victim devices voluntarily stop transmitting because they believe the channel is reserved.
The BLEShark Nano captures all management frames on the monitored channel, including RTS and CTS. Abnormal CTS patterns (CTS frames with no preceding RTS, or continuous CTS with unusually large Duration values) can indicate a CTS flood attack. Monitoring for these patterns is part of comprehensive wireless security assessment.