2 .\" Copyright (c) 2004 Bruce M. Simpson <bms@spc.org>,
3 .\" Darron Broad <darron@kewl.org>,
4 .\" David Young <dyoung@pobox.com>.
5 .\" All rights reserved.
7 .\" Redistribution and use in source and binary forms, with or without
8 .\" modification, are permitted provided that the following conditions
10 .\" 1. Redistributions of source code must retain the above copyright
11 .\" notice, this list of conditions and the following disclaimer.
12 .\" 2. Redistributions in binary form must reproduce the above copyright
13 .\" notice, this list of conditions and the following disclaimer in the
14 .\" documentation and/or other materials provided with the distribution.
16 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
19 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28 .\" $FreeBSD: src/share/man/man9/ieee80211_radiotap.9,v 1.3 2004/07/07 12:59:39 ru Exp $
29 .\" $NetBSD: ieee80211_radiotap.9,v 1.9 2006/03/12 03:22:02 dyoung Exp $
30 .\" $DragonFly: src/share/man/man9/ieee80211_radiotap.9,v 1.7 2007/11/23 23:03:57 swildner Exp $
33 .Dt IEEE80211_RADIOTAP 9
36 .Nm ieee80211_radiotap
37 .Nd software 802.11 stack packet capture definitions
40 .In netproto/802_11/ieee80211_var.h
41 .In netproto/802_11/ieee80211_ioctl.h
42 .In netproto/802_11/ieee80211_radiotap.h
47 definitions provide a device-independent
50 capture of information about 802.11 traffic which is not part of
51 the 802.11 frame structure.
53 Radiotap was designed to balance the desire for a capture format
54 that conserved CPU and memory bandwidth on embedded systems,
55 with the desire for a hardware-independent, extensible format
56 that would support the diverse capabilities of virtually all
59 These considerations led radiotap to settle on a format consisting of
60 a standard preamble followed by an extensible bitmap indicating the
61 presence of optional capture fields.
63 The capture fields were packed into the header as compactly as possible,
64 modulo the requirements that they had to be packed swiftly,
65 with their natural alignment,
66 in the same order as the bits indicating their presence.
68 This typically includes information such as signal quality and
70 This information may be used by a variety of user agents, including
72 It is requested by using the
75 .Dv DLT_IEEE802_11_RADIO .
78 Each frame using this attachment has the following header prepended to it:
79 .Bd -literal -offset indent
80 struct ieee80211_radiotap_header {
81 uint8_t it_version; /* set to 0 */
83 uint16_t it_len; /* entire length */
84 uint32_t it_present; /* fields present */
89 A device driver implementing
91 typically defines a structure embedding an instance of
92 .Vt "struct ieee80211_radiotap_header"
94 with subsequent fields naturally aligned,
95 and in the appropriate order. Also, a driver defines
96 a macro to set the bits of the
98 bitmap to indicate which fields exist and are filled in by the driver.
101 Radiotap capture fields are in little-endian byte order.
103 Radiotap capture fields
104 .Em must be naturally aligned .
105 That is, 16-, 32-, and 64-bit fields must begin on 16-, 32-, and
106 64-bit boundaries, respectively.
107 In this way, drivers can avoid unaligned accesses to radiotap
109 radiotap-compliant drivers must insert padding before a capture
110 field to ensure its natural alignment.
111 radiotap-compliant packet dissectors, such as
115 Developers beware: all compilers may not pack structs alike.
116 If a driver developer constructs their radiotap header with a packed
117 structure, in order to ensure natural alignment, then it is important
118 that they insert padding bytes by themselves.
120 Radiotap headers are copied to the userland via a separate bpf attachment.
121 It is necessary for the driver to create this attachment after calling
122 .Xr ieee80211_ifattach 9
125 with the data-link type set to
126 .Dv DLT_IEEE802_11_RADIO .
129 When the information is available,
130 usually immediately before a link-layer transmission or after a receive,
131 the driver copies it to the bpf layer using the
136 The following extension fields are defined for
138 in the order in which they should appear in the buffer copied to userland:
139 .Bl -tag -width indent
140 .It Dv IEEE80211_RADIOTAP_TSFT
141 This field contains the unsigned 64-bit value, in microseconds,
142 of the MAC's 802.11 Time Synchronization Function timer,
143 when the first bit of the MPDU arrived at the MAC.
144 This field should be present for received frames only.
145 .It Dv IEEE80211_RADIOTAP_FLAGS
146 This field contains a single unsigned 8-bit value, containing a bitmap
147 of flags specifying properties of the frame being transmitted or received.
148 .It Dv IEEE80211_RADIOTAP_RATE
149 This field contains a single unsigned 8-bit value, which is the data rate in
150 use in units of 500Kbps.
151 .It Dv IEEE80211_RADIOTAP_CHANNEL
152 This field contains two unsigned 16-bit values.
153 The first value is the frequency upon which this PDU was transmitted
155 The second value is a bitmap containing flags which specify properties of
157 These are documented within the header file,
158 .In netproto/802_11/ieee80211_radiotap.h .
159 .It Dv IEEE80211_RADIOTAP_FHSS
160 This field contains two 8-bit values.
161 This field should be present for frequency-hopping radios only.
162 The first byte is the hop set.
163 The second byte is the pattern in use.
164 .It Dv IEEE80211_RADIOTAP_DBM_ANTSIGNAL
165 This field contains a single signed 8-bit value, which indicates the
166 RF signal power at the antenna, in decibels difference from 1mW.
167 .It Dv IEEE80211_RADIOTAP_DBM_ANTNOISE
168 This field contains a single signed 8-bit value, which indicates the
169 RF noise power at the antenna, in decibels difference from 1mW.
170 .It Dv IEEE80211_RADIOTAP_LOCK_QUALITY
171 This field contains a single unsigned 16-bit value, indicating the
172 quality of the Barker Code lock.
173 No unit is specified for this field.
174 There does not appear to be a standard way of measuring this at this time;
175 this quantity is often referred to as
178 .It Dv IEEE80211_RADIOTAP_TX_ATTENUATION
179 This field contains a single unsigned 16-bit value, expressing transmit
180 power as unitless distance from maximum power set at factory calibration.
181 0 indicates maximum transmit power.
182 Monotonically nondecreasing with lower power levels.
183 .It Dv IEEE80211_RADIOTAP_DB_TX_ATTENUATION
184 This field contains a single unsigned 16-bit value, expressing transmit
185 power as decibel distance from maximum power set at factory calibration.
186 0 indicates maximum transmit power.
187 Monotonically nondecreasing with lower power levels.
188 .It Dv IEEE80211_RADIOTAP_DBM_TX_POWER
189 Transmit power expressed as decibels from a 1mW reference.
190 This field is a single signed 8-bit value.
191 This is the absolute power level measured at the antenna port.
192 .It Dv IEEE80211_RADIOTAP_ANTENNA
193 For radios which support antenna diversity, this field contains a single
194 unsigned 8-bit value specifying which antenna is being used to transmit
195 or receive this frame.
196 The first antenna is antenna 0.
197 .It Dv IEEE80211_RADIOTAP_DB_ANTSIGNAL
198 This field contains a single unsigned 8-bit value, which indicates the
199 RF signal power at the antenna, in decibels difference from an
200 arbitrary, fixed reference.
201 .It Dv IEEE80211_RADIOTAP_DB_ANTNOISE
202 This field contains a single unsigned 8-bit value, which indicates the
203 RF noise power at the antenna, in decibels difference from an
204 arbitrary, fixed reference.
205 .It Dv IEEE80211_RADIOTAP_EXT
206 This bit is reserved for any future extensions to the
210 .Dv IEEE80211_RADIOTAP_EXT
211 to extend the it_present bitmap
213 The bitmap can be extended by multiples of 32 bits to 96, 128, 160
214 bits or longer, by setting
215 .Dv IEEE80211_RADIOTAP_EXT
217 The bitmap ends at the first extension field where
218 .Dv IEEE80211_RADIOTAP_EXT
222 Radiotap header for the Intel(R) PRO/Wireless 2200BG/2225BG/2915ABG driver
223 .Bd -literal -offset indent
224 struct iwi_rx_radiotap_header {
225 struct ieee80211_radiotap_header wr_ihdr;
228 uint16_t wr_chan_freq;
229 uint16_t wr_chan_flags;
230 uint8_t wr_antsignal;
235 Bitmap indicating which fields are present in the above structure:
236 .Bd -literal -offset indent
237 #define IWI_RX_RADIOTAP_PRESENT \\
238 ((1 << IEEE80211_RADIOTAP_FLAGS) | \\
239 (1 << IEEE80211_RADIOTAP_RATE) | \\
240 (1 << IEEE80211_RADIOTAP_CHANNEL) | \\
241 (1 << IEEE80211_RADIOTAP_DB_ANTSIGNAL) | \\
242 (1 << IEEE80211_RADIOTAP_ANTENNA))
250 definitions first appeared in
252 and were later ported to
259 interface was designed and implemented by
260 .An David Young Aq dyoung@pobox.com .
262 is the maintainer of the radiotap capture format.
263 Contact him to add new capture fields.
265 This manual page was written by
266 .An Bruce M. Simpson Aq bms@FreeBSD.org
268 .An Darron Broad Aq darron@kewl.org .