radiotap-rs

no_std compatible radiotap header encoder and decoder for Rust. Supports repeated fields, vendor-specific fields (both vendor-specific namespaces and vendor- specific TLV fields), and most standard radiotap fields.

Examples

See the examples directory for and header_tests.rs for usage examples.

Documentation

Supported Fields

The following fields are currently supported:

Additional, vendor-specific fields are also supported. If you need support for non-vendor-specific fields not listed above, please feel free to submit a pull request.

Gotchas

This section contains some important notes for library consumers and contributors alike.

This Library

As a consequence of some of the quirks of the radiotap specification (See the next subsection for details) and various other factors, you should note the following about this library:

1. Fields are represented as a list (rather than a struct) to support repeated fields.
2. Field order matters. Fields are encoded in the order in which they are stored in the list, however, the radiotap specification mandates non-Type-Length-Value (TLV) fields be ordered in ascending order by their bit index (for fields in the same namespace). Therefore, if you pass out-of-order fields (in the same namespace), the encoder will rectify this by splitting the fields across multiple namespaces, potentially resulting in a larger-than-necessary header. Unless you have a specific reason not to do so, you are encouraged to define fields in ascending order by their bit index.
3. Fields with a bit index < 28 in the first radiotap namespace are encoded using the older implicit-length encoding for backwards compatibility.
4. Vendor-specific fields are always encoded using TLV encoding. However, vendor-specific fields can be decoded from either implicit-length encoding (in vendor-specific namespaces) or TLV encoding (in the radiotap namespace).

Radiotap Specification

If you aren't familiar with the radiotap specification, it is suggested to read about Type Length Value (TLV) fields, the Radiotap Namespace pseudo-field, and the Vendor Namespace field in particular. Some important observations about the radiotap specification itself are:

• Radiotap headers start with a subheader containing the header version, padding, and a sequence of bitmasks defining which fields are present immediately following the subheader.
• Every individual presence bitmask contains 3 special bit indices:
  • $n \cdot 32 - 3$: set to switch to the radiotap namespace (starting with the presence bitmask immediately following this one). This is a pseudo-field (i.e., it only exists within the bitmask and takes up no additional room).
  • $n \cdot 32 - 2$: set to switch to a vendor namespace (starting with the presence bitmask immediately following this one). This is a full field, containing the vendor Organizationally Unique Identifier (OUI), vendor-specific sub-namespace, and the length of the namespace.
  • $n \cdot 32 - 1$: set if another bitmask immediately follows this one. This is a pseudo-field (i.e., it only exists within the bitmask and takes up no additional room).
• Fields can be repeated by repeating their respective namespaces. For example, the presence bitmasks [0xA0000001, 0x00000001] define 2 TSFT fields back-to-back in 2 separate radiotap namespaces.
• Fields with a bit index < 28 can either use the older implicit-length encoding or the newer Type-Length-Value (TLV) encoding. Additionally, fields with a bit index >= 32 must use TLV encoding. TLV encoded fields are nested under the TLV field, which itself uses the older encoding.
• Vendor-specific fields can either use the older implicit-length encoding in vendor-specific namespaces or TLV encoding in the radiotap namespace.
• Not all field members are nicely aligned (e.g., the HE field's data4 station ID member).
• Refer to the IEEE 802.11 specification anywhere the radiotap specification lacks details.

Prior Art

• Rust
  • radiotap
  • rtap
• C/C++
  • kismet
  • libpcap
  • libtins
  • libwifi
  • linux
  • radiotap-library
  • wireshark
• Go
  • go.pkt
  • gopacket-80211
  • gopacket
  • wanonpcap
• JavaScript
  • node_pcap
  • radioparse
  • wiregasm
• Python
  • dpkt
  • itamae
  • python-radiotap
  • scapy
  • wltrace