1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
|
AVS Capture Frame Format
Version 2.1.1
1. Introduction
The original header format for "monitor mode" or capturing frames was
a considerable hack. The document covers a redesign of that format.
Any questions, corrections, or proposed changes go to info@linux-wlan.com
2. Frame Format
All sniff frames follow the same format:
Offset Name Size Description
--------------------------------------------------------------------
0 CaptureHeader AVS capture metadata header
64 802.11Header [10-30] 802.11 frame header
?? 802.11Payload [0-2312] 802.11 frame payload
?? 802.11FCS 4 802.11 frame check sequence
Note that the header and payload are variable length and the payload
may be empty.
If the hardware does not supply the FCS to the driver, then the frame shall
have a FCS of 0xFFFFFFFF.
3. Byte Order
All multibyte fields of the capture header are in "network" byte
order. The "host to network" and "network to host" functions should
work just fine. All the remaining multibyte fields are ordered
according to their respective standards.
4. Capture Header Format
The following fields make up the AVS capture header:
Offset Name Type
------------------------------
0 version uint32
4 length uint32
8 mactime uint64
16 hosttime uint64
24 phytype uint32
28 frequency uint32
32 datarate uint32
36 antenna uint32
40 priority uint32
44 ssi_type uint32
48 ssi_signal int32
52 ssi_noise int32
56 preamble uint32
60 encoding uint32
64 sequence uint32
68 drops uint32
72 receiver_addr uint8[6]
78 padding uint8[2]
------------------------------
80
The following subsections detail the fields of the capture header.
4.1 version
The version field identifies this type of frame as a subtype of
ETH_P_802111_CAPTURE as received by an ARPHRD_IEEE80211_PRISM or
an ARPHRD_IEEE80211_CAPTURE device. The value of this field shall be
0x80211002. As new revisions of this header are necessary, we can
increment the version appropriately.
4.2 length
The length field contains the length of the entire AVS capture header,
in bytes.
4.3 mactime
Many WLAN devices supply a relatively high resolution frame reception
time value. This field contains the value supplied by the device. If
the device does not supply a receive time value, this field shall be
set to zero. The units for this field are microseconds.
If possible, this time value should be absolute, representing the number
of microseconds elapsed since the UNIX epoch.
4.4 hosttime
The hosttime field is set to the current value of the host maintained
clock variable when the frame is received by the host.
If possible, this time value should be absolute, representing the number
of microseconds elapsed since the UNIX epoch.
4.5 phytype
The phytype field identifies what type of PHY is employed by the WLAN
device used to capture this frame. The valid values are:
PhyType Value
-------------------------------------
phytype_fhss_dot11_97 1
phytype_dsss_dot11_97 2
phytype_irbaseband 3
phytype_dsss_dot11_b 4
phytype_pbcc_dot11_b 5
phytype_ofdm_dot11_g 6
phytype_pbcc_dot11_g 7
phytype_ofdm_dot11_a 8
phytype_dss_ofdm_dot11_g 9
4.6 frequency
This represents the frequency or channel number of the receiver at the
time the frame was received. It is interpreted as follows:
For frequency hopping radios, this field is broken in to the
following subfields:
Byte Subfield
------------------------
Byte0 Hop Set
Byte1 Hop Pattern
Byte2 Hop Index
Byte3 reserved
For non-hopping radios, the frequency is interpreted as follows:
Value Meaning
-----------------------------------------
< 256 Channel number (using externally-defined
channelization)
< 10000 Center frequency, in MHz
>= 10000 Center frequency, in KHz
4.7 datarate
The data rate field contains the rate at which the frame was received
in units of 100kbps.
4.8 antenna
For WLAN devices that indicate the receive antenna for each frame, the
antenna field shall contain an index value into the dot11AntennaList.
If the device does not indicate a receive antenna value, this field
shall be set to zero.
4.9 priority
The priority field indicates the receive priority of the frame. The
value is in the range [0-15] with the value 0 reserved to indicate
contention period and the value 6 reserved to indicate contention free
period.
4.10 ssi_type
The ssi_type field is used to indicate what type of signal strength
information is present: "None", "Normalized RSSI" or "dBm". "None"
indicates that the underlying WLAN device does not supply any signal
strength at all and the ssi_* values are unset. "Normalized RSSI"
values are integers in the range [0-1000] where higher numbers
indicate stronger signal. "dBm" values indicate an actual signal
strength measurement quantity and are usually in the range [-108 - 10].
The following values indicate the three types:
Value Description
---------------------------------------------
0 None
1 Normalized RSSI
2 dBm
3 Raw RSSI
4.11 ssi_signal
The ssi_signal field contains the signal strength value reported by
the WLAN device for this frame. Note that this is a signed quantity
and if the ssi_type value is "dBm" that the value may be negative.
4.12 ssi_noise
The ssi_noise field contains the noise or "silence" value reported by
the WLAN device. This value is commonly defined to be the "signal
strength reported immediately prior to the baseband processor lock on
the frame preamble". If the hardware does not provide noise data, this
shall equal 0xffffffff.
4.12 preamble
For PHYs that support variable preamble lengths, the preamble field
indicates the preamble type used for this frame. The values are:
Value Description
---------------------------------------------
0 Undefined
1 Short Preamble
2 Long Preamble
4.13 encoding
This specifies the encoding of the received packet. For PHYs that support
multiple encoding types, this will tell us which one was used.
Value Description
---------------------------------------------
0 Unknown
1 CCK
2 PBCC
3 OFDM
4 DSSS-OFDM
5 BPSK
6 QPSK
7 16QAM
8 64QAM
4.14 sequence
This is a receive frame sequence counter. The sniff host shall
increment this by one for every valid frame received off the medium.
By watching for gaps in the sequence numbers we can determine when
packets are lost due to unreliable transport, rather than a frame never
being received to begin with.
4.15 drops
This is a counter of the number of known frame drops that occured. This
is particularly useful when the system or hardware cannot keep up with
the sniffer load.
4.16 receiver_addr
This specifies the MAC address of the receiver of this frame.
It is six octets in length. This field is followed by two octets of
padding to keep the structure 32-bit word aligned.
================================
Changes: v2->v2.1
* Added contact e-mail address to introduction
* Added sniffer_addr, drop count, and sequence fields, bringing total
length to 80 bytes
* Bumped version to 0x80211002
* Mactime is specified in microseconds, not nanoseconds
* Added 64QAM, 16QAM, BPSK, QPSK encodings
================================
Changes: v2.1->v2.1.1
* Renamed 'channel' to 'frequency'
* Clarified the interpretation of the frequency/channel field.
* Renamed 'sniffer address' to 'receiver address'
* Clarified timestamp fields.
|
