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