Understanding Wi-Fi (802.11): Practical Wireless Traffic Analysis with Tshark

At some point you may need to analyze wireless traffic — whether for troubleshooting connectivity issues, validating security controls, or simply understanding how Wi-Fi works internally.

Wi-Fi (IEEE 802.11) is one of the most widely used networking technologies today, and understanding how it behaves at the frame level is a foundational skill for networking and security professionals.

In this article we will capture real 802.11 traffic using monitor mode and analyze it to understand:

• How Wi-Fi communication works at the frame level
  • What normal wireless traffic looks like in a packet capture
  • How suspicious or malicious activity may appear in wireless traffic

TShark is the command-line version of Wireshark, the widely used graphical packet analyzer. While Wireshark provides an interactive GUI for inspecting packets, TShark allows engineers to automate analysis, filter traffic quickly, and extract structured data directly from packet captures.

Lab Setup

To capture raw 802.11 frames, we need a wireless adapter that supports monitor mode.

For this lab, I am using:

TP-Link TL-WN721N (Qualcomm Atheros AR9271 chipset)

This adapter is widely used in wireless security labs and penetration testing environments. AR9271 chipset fully supports monitor mode under Linux.

You can verify that your adapter is detected using:

lsusb

Identifying the Interface

Next, we need to identify the name of our wireless interface.

Running the following command displays all network interfaces on the system:

ip link

In my case the adapter corresponds to:

wlxf8d11162b94a

Now that we have identified our interface, it can be configured for monitor mode.

Enabling Monitor Mode

Monitor mode allows a wireless interface to capture all nearby wireless frames, even if the device is not connected to a specific network.

First, disable the interface:

sudo ip link set wlxf8d11162b94a down

Then enable monitor mode:

sudo iw dev wlxf8d11162b94a set type monitor

Finally bring the interface up:

sudo ip link set wlxf8d11162b94a up

At this point, the adapter can capture raw 802.11 traffic including:

• beacon frames
• probe requests
• authentication attempts
• encrypted data frames

To confirm that the interface is running in monitor mode, the following commands can be used:

ip link show

In monitor mode, captured frames typically include a Radiotap header, which provides metadata such as signal strength, channel, and data rate.

Another useful command is:

iw dev <interface name> info

With the interface configured in monitor mode, we are now ready to capture some wireless traffic.

Capturing Traffic

To collect sample data, we will perform a 15-minute capture using tcpdump. A longer capture helps ensure we observe normal network behavior such as beacon intervals, probe activity, and client associations.

Using timeout ensures the capture automatically stops after 900 seconds:

sudo timeout 900 tcpdump -i wlxf8d11162b94a -w 80211_capture.pcap

Analyzing the Traffic: How WiFi Connections Actually Work

Frames

Wireless communication in 802.11 networks is organized into frames.
Each frame contains information required for communication between wireless devices.

802.11 frames fall into three main categories:

• Management Frames
  Used for network discovery and connection management.
  Examples include Beacon, Probe Request, Authentication, and Association frames.
• Control Frames
  Used to coordinate access to the wireless medium and maintain reliable communication.
  Examples include RTS, CTS, and ACK frames.
• Data Frames
  Carry the actual user traffic such as IP packets.

Frames Subtypes

There are many frame subtypes, but for the purpose of this article we will focus primarily on beacon frames and deauthentication frames. Here is a mapping of the subtypes and mappings that will come in handy in understanding our filters later on.

We can generate a frame distribution statistic by running:

tshark -r 80211_capture.pcap -q -z io,phs

The io,phs statistic groups packets by protocol hierarchy and gives us a high-level view of what types of frames dominate the capture.

Most of the distribution consists of management frames, which is common behavior in Wi-Fi networks.

Beacons

Beacon frames are how Wi-Fi networks advertise their presence.

Get Carlos Minda’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Access points typically transmit beacon frames about 10 times per second (approximately every 100 milliseconds).

Because of this constant broadcast behavior, beacon frames usually make up a large portion of any wireless packet capture.

The number of beacon frames observed in a capture is therefore strongly influenced by how many access points are within range.

To determine a baseline of how many beacon frames are transmitted per second, we first need to count the total number of beacon frames in our capture.

tshark -r 80211_capture.pcap -Y "wlan.fc.type_subtype == 0x08" | wc -l

Notice that we are using the 0x08 subtype to filter for beacon just as we saw on the table before.

For this 900 seconds capture there is 6410 beacon frames, which results in an average of 6410/900 = 7.122 packets/s

Identifying SSID

A Service Set Identifier (SSID) is the name used to identify a wireless network in Wi-Fi environments. It allows devices such as laptops, phones, and IoT devices to discover and connect to a specific network among many available nearby. Access points broadcast the SSID in beacon frames so clients can see and select the network from a list. Some networks choose to disable SSID broadcasting, creating what are commonly called hidden networks, which require users to manually enter the network name to connect. While hiding the SSID may reduce casual visibility, it does not provide strong security on its own.

Let’s determine how many SSIDs appear in our capture:

tshark -r 80211_capture.pcap -Y "wlan.fc.type_subtype == 0x08" -T fields -e wlan.ssid | sort -u

This command displays every unique SSID observed in the capture. TShark may output SSIDs in hexadecimal format depending on how the bytes are represented in the capture. If we were viewing the capture in Wireshark, the SSID would typically appear decoded as ASCII.

In order to get a direct output from our command we can use the following command chain:

tshark -r 80211_capture.pcap -Y "wlan.fc.type_subtype == 0x08 && wlan.ssid" -T fields -e wlan.ssid \
| sort -u \
| while read -r ssid; do echo "$ssid" | xxd -r -p; echo; done

Identifying Access Points (BSSID)

While the SSID represents the name of a wireless network, it does not uniquely identify a specific access point.
The actual identifier used by Wi-Fi devices is the BSSID.

A BSSID (Basic Service Set Identifier) is the MAC address of the wireless interface that is broadcasting the network. Each access point has its own BSSID, even if multiple devices broadcast the same SSID.

This is common in environments where several access points provide coverage for the same network name. For example, in offices, campuses, or apartment buildings, multiple access points may broadcast the same SSID to provide better coverage and roaming between devices.

To extract the BSSID and SSID from beacon frames in our capture we can use:

tshark -r 80211_capture.pcap \
-Y "wlan.fc.type_subtype == 0x08" \
-T fields \
-e wlan.bssid \
-e wlan.ssid

This allows us to see which access points are advertising each wireless network.

If the SSID appears encoded in hexadecimal format, we can decode it by adding the following to our command:

| sort -u \
| grep -v “<” \
| awk ‘{printf “%s “, $1; system(“echo “$2” | xxd -r -p”); printf “\n”}’

Understanding the relationship between SSID and BSSID is important when analyzing wireless captures, because it allows us to distinguish between different physical access points that belong to the same network.

For example, the same SSID may appear multiple times in a capture each associated with a different BSSID for example:

00:11:22:33:44:55 CoffeeShopWiFi
AA:BB:CC:DD:EE:FF CoffeeShopWiFi

In this case, two separate access points are broadcasting the same network name.
From our output this is not the case on our analyzed capture.

The process of connecting to a Wi-Fi network involves several management frame exchanges between the client device and the access point. After discovering available networks, the client begins communication to establish a connection and become part of the wireless network. This process includes network discovery, authentication, and association steps that allow the device to join the access point and begin transmitting data. The diagram below illustrates the sequence of these messages and the direction in which they are exchanged between the client and the access point.

Discovering Client Devices

An essential section of our analysis is to determine what clients are actively attempting to connect to our Wi-Fi network.

Client devices discover networks by sending probe request frames.

These frames are broadcast periodically while a device searches for available Wi-Fi networks.

Historically, probe requests often contained the names of previously connected networks.
This behavior raised privacy concerns because observers could identify networks a device had joined before.

Modern operating systems mitigate this risk by using MAC address randomization and limiting identifying information in probe requests.

To filter probe requests we can use the corresponding subtype value: 0x04

tshark -r 80211_capture.pcap -Y "wlan.fc.type_subtype == 0x04"

You will see on your output the MAC addresses of devices probing for networks:

Nowadays most operating systems and devices randomize your MAC addresses during this process to better protect your privacy but this wasn’t always the case.

Suspicious Wi-Fi Activity

One practical use of wireless traffic analysis is identifying potential denial-of-service attacks.

Two indicators that may suggest suspicious wireless activity are:

• bursts of deauthentication frames, which may indicate a deauthentication attack
• unusually high numbers of probe requests from a single device

We’ve already seen how to get a general statistic of management frames in our capture, and how to filter for probe requests. Let’s dive into filtering for this. For our filter we will use the corresponding 0x0c subtype if we mainly want to see the packets

tshark -r 80211_capture.pcap -Y "wlan.fc.type_subtype == 0x0c"

This will display any deauthentication frames present in the capture.

Since our test setup does not include any malicious activity, it is expected that we do not observe anything unusual during our 15-minute capture.

At last, if we just quickly want to view a quick statistic of management frames subtypes and their count, we can get this with:

tshark -r 80211_capture.pcap \
-Y "wlan.fc.type == 0" \
-T fields -e wlan.fc.type_subtype \
| sort | uniq -c | sort -nr

We will get a quick overview of our different packets and their subtype

So here we can quickly identify, our total 6410 beacon frames, 224 probe request, and the 2 deauth packets. As expected, these values correspond to a normal and healthy Wi-Fi environment.

Conclusion

In this article we explored the fundamentals of Wi-Fi traffic analysis using real packet captures. By examining beacon frames, probe requests, and management frame statistics, we gained insight into how wireless networks behave under normal conditions.

Tools such as tshark allow analysts to extract meaningful insights directly from packet captures and are extremely useful when troubleshooting wireless connectivity or investigating potential security incidents.

Understanding these fundamentals provides a strong foundation for deeper exploration of wireless networking and security analysis.