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.