Introduction
When capturing packets in WLAN wireless networks, regardless of whether you use Wireshark, tcpdump, or Scapy, you will encounter the Radiotap, LLC, and SNAP protocol layers.
As shown in the image:
/>
The LLC (Logical Link Control) sublayer (including SNAP) and the MAC (Media Access Control) sublayer together form the data link layer.
LLC primarily provides services to upper-level protocols, while the MAC layer primarily handles local network addressing and avoiding contention for services below. To gain a deeper understanding, you can look it up.
Below is an explanation of the structure and information contained in Radiotap.
Radiotap
Overview
Radiotap is a de facto standard for 802.11 frame injection and reception.
This sentence is excerpted from the official Radiotap documentation. Radiotap is the de facto standard for 802.11 frame injection and reception (translated from Google).
Many operating systems support Radiotap, including Linux, Windows…
Radiotap is generally added when a network card receives a wireless frame if the kernel allows it. Both driver to userspace and userspace to driver are possible.
This is why we see the Radiotap protocol layer at the very front in the summary when capturing packets in monitor mode (kernel allows).
It provides information related to wireless protocol frames, such as signal strength, noise strength, channel, timestamp, etc.
Finally, the information added in Radiotap is related to the network card. For example, the present field for a WN722N card has the 32nd bit as 1, whereas a counterfeit 8187 card would have it as 0…
The detailed explanation is as follows:
Protocol Header Structure
In general, the entire header is 8 bytes, 32 bits: 8 (version) + 8 (pad) + 16 (len) = 32 (present)
1. The current version field is always 0.2. The pad field is zeroed out to align to four bytes, so the beginning of Radiotap is always \x00\x00.3. Len is the length of the entire Radiotap data layer, which is convenient to skip when not needing parsing.4. Present is the bitmask of the Radiotap protocol data, with a bit set to 1 indicating that the corresponding data exists, located after the header.For example, bit 5 (index) indicates that signal strength data exists behind, bit 31 indicates another present field exists.Due to the bitmask, the Radiotap protocol data length is variable, making Radiotap very flexible. When new fields appear, they do not break existing parsers.When encountering Radiotap data that cannot be understood, the len can be used to skip directly to continue parsing upper-layer data.5. The header length may extend as multiple present fields could exist, but it should be aligned to 8 bytes with 0 padding, such as what is captured by WN722N.
Protocol Data Content
The protocol contains defined, suggested, and rejected fields.
Most of the time, we are concerned with a few defined fields rich in information, detailed on the official website.
Name |
Bits |
Length |
Unit |
Description |
---|---|---|---|---|
TSFT |
0 |
u64 |
Microseconds |
Time when the first bit of the data frame arrives |
Rate |
2 |
u8 |
500Kbps |
Transmission or reception rate |
Channel |
3 |
u16 frequency, +u16 flags |
MHz + bitmap |
Channel frequency and flags |
Antenna signal |
5 |
s8 |
dBm |
Signal strength at the antenna when received |
Antenna noise |
6 |
s8 |
dBm |
Noise strength at the antenna when received |
dBm TX power |
10 |
s8 |
dBm |
Transmit power (signed) |
Due to Radiotap’s flexibility, there are often vendor-customized fields.
Note that when extracting signal strength, the data is in signed integers and the strengths are all negative. You need to subtract 1 before inverting to get the correct absolute value. Refer to the negative number’s complement representation for details.
Additionally, to obtain the above fields, it also depends on whether your network card supports it. Hopefully, it does.
Moreover, each field name in Wireshark has slight differences, as illustrated in the image showing two presents in Wireshark.
How to Filter
Proto is one of ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp, ip6 or radio, and indicates the protocol layer for the index operation. (ether, fddi, wlan, tr, ppp, slip and link all refer to the link layer. radio refers to the “radio header” added to some 802.11 captures.)
Excerpt from the BPF documentation. BPF syntax offers the ability to filter Radiotap protocol, indicated as ‘radio’.
It can be used in the filter parameter of Scapy’s sniff function or in filters using BPF syntax, such as tcpdump.
For example, to filter data packets with a present field of 0x0024, use filter=’radio[2:2]==0x2400’ (Scapy).
Additionally, to filter certain bits, you can use the ‘AND’ operation (&) to achieve filter=’radio[2]&7==7’.
Furthermore, it is vital to note that the Radiotap protocol uses little-endian byte order, meaning that in multi-byte fields, the lower byte is sent first.
For example, the present field 0x12 23 34 45 is received in the order of 0x45 34 23 12 in a wireless network. This can be observed in both Scapy’s str(packet) and the packet bytes section in Wireshark.
Hence, when using filtering syntax, be sure to consider the byte order issue, with lower bytes in front.
How to Parse
Using Scapy
Summary:
Show:
You can see Scapy parses the fields except for version, pad, len, and the first present but Ext in present indicates another present field exists.
Thus, Scapy does not fully support Radiotap well, as the unparsed data is placed in notdecode (little-endian byte order). Scapy directly skips Radiotap parsing through the len field and proceeds to upper-layer data.
Using radiotap-library
This library is also introduced on the official website, and its simple usage is in the C language library applied in the Linux kernel.
Since I prefer programming in Python, I once wanted to modify functions to generate a dynamic link library for Python call but later came across the library below by chance.
Using itamae
When pip searches for Radiotap, another library appears
itamae (0.1.1) – Python 802.11 MPDU and Radiotap parsing
After installation, the introduction of the Radiotap submodule in itamae writes
Provides Radiotap parsing (radiotap.org defined fields) only.NOTE:o Will not parse correctly if extended fields are present before defined fields.o It is recommended not to import * as it may cause conflicts with other modules
It demonstrates support for Radiotap protocol parsing and notes that it only successfully parses packets with one present.
Usage only requires passing the packet string into and returns the parsed dictionary.
What Interesting Uses Are There?
Since we have received signal strength, measuring the relationship between your network card’s signal attenuation and distance multiple times can roughly locate a signal source.
There are many RSSI (Received Signal Strength Indication) indoor positioning algorithms available online for reference.
Imagine you’re sniffing the open WiFi in a shopping mall outside a coffee shop, and suddenly you see the direction and go find a magnesium-aluminum selfie – isn’t it much more convenient?
Or perhaps enterprises can locate the source of many deauth DoS attack packets in the wireless environment more easily through rough positioning.