diff options
Diffstat (limited to 'abs/core-testing/wlan-ng26-utils/tmp/trunk/doc/.svn/text-base/capturefrm.txt.svn-base')
| -rw-r--r-- | abs/core-testing/wlan-ng26-utils/tmp/trunk/doc/.svn/text-base/capturefrm.txt.svn-base | 233 |
1 files changed, 233 insertions, 0 deletions
diff --git a/abs/core-testing/wlan-ng26-utils/tmp/trunk/doc/.svn/text-base/capturefrm.txt.svn-base b/abs/core-testing/wlan-ng26-utils/tmp/trunk/doc/.svn/text-base/capturefrm.txt.svn-base new file mode 100644 index 0000000..9ea908d --- /dev/null +++ b/abs/core-testing/wlan-ng26-utils/tmp/trunk/doc/.svn/text-base/capturefrm.txt.svn-base @@ -0,0 +1,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. |