The Official Home of the AVS header spec appears to bhe the
linux-wlan-ng source tree; just insert it verbatim into a big honking comment, rather than trying to play Find The URL with it. svn path=/trunk/; revision=26239
This commit is contained in:
parent
e3844580e9
commit
dbf7b99e97
|
@ -52,28 +52,6 @@
|
|||
* Arada Systems <http://www.aradasystems.com>
|
||||
*/
|
||||
|
||||
/*
|
||||
* Prism II-based wlan devices have a monitoring mode that sticks
|
||||
* a proprietary header on each packet with lots of good
|
||||
* information. This file is responsible for decoding that
|
||||
* data.
|
||||
*
|
||||
* Support by Tim Newsham
|
||||
*/
|
||||
|
||||
/*
|
||||
* AVS linux-wlan-based products use a new sniff header to replace the
|
||||
* old Prism header. This one has additional fields, is designed to be
|
||||
* non-hardware-specific, and more importantly, version and length fields
|
||||
* so it can be extended later without breaking anything.
|
||||
*
|
||||
* See
|
||||
*
|
||||
* https://mail.shaftnet.org/chora/browse.php?rt=wlanng&f=trunk%2Fdoc%2Fcapturefrm.txt
|
||||
*
|
||||
* Support by Solomon Peachy
|
||||
*/
|
||||
|
||||
#ifdef HAVE_CONFIG_H
|
||||
# include "config.h"
|
||||
#endif
|
||||
|
@ -2044,6 +2022,13 @@ capture_ieee80211_ht (const guchar * pd, int offset, int len, packet_counts * ld
|
|||
#define WLANCAP_MAGIC_COOKIE_V2 0x80211002
|
||||
|
||||
/*
|
||||
* Prism II-based wlan devices have a monitoring mode that sticks
|
||||
* a proprietary header on each packet with lots of good
|
||||
* information. This file is responsible for decoding that
|
||||
* data.
|
||||
*
|
||||
* Support by Tim Newsham
|
||||
*
|
||||
* A value from the header.
|
||||
*
|
||||
* It appears from looking at the linux-wlan-ng and Prism II HostAP
|
||||
|
@ -7739,6 +7724,252 @@ dissect_prism(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
|
|||
call_dissector(ieee80211_handle, next_tvb, pinfo, tree);
|
||||
}
|
||||
|
||||
/*
|
||||
* AVS linux-wlan-based products use a new sniff header to replace the
|
||||
* old Prism header. This one has additional fields, is designed to be
|
||||
* non-hardware-specific, and more importantly, version and length fields
|
||||
* so it can be extended later without breaking anything.
|
||||
*
|
||||
* Support by Solomon Peachy
|
||||
*
|
||||
* Description, from the capturefrm.txt file in the linux-wlan-ng 0.2.9
|
||||
* release (linux-wlan-ng-0.2.9/doc/capturefrm.txt):
|
||||
*
|
||||
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.
|
||||
*/
|
||||
|
||||
/*
|
||||
* Signal/noise strength type values.
|
||||
*/
|
||||
|
|
Loading…
Reference in New Issue