Linux Edu Handbook

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
**Introduction**

While the net is filled with technical descriptions of 802.1 Ethernet packet headers and all of it's varients, there is an unfortunate silence on the subject of 802.11 (wireless) frames.

While current drivers are quite limited in their ability to hand over raw 802.11 for examination and none allow raw 802.11 to be submitted for unaltered transmission (for good reasons!), it **IS** possible to capture such packets and they should be documented in some manner other than in the form of (often) convoluted source code.

This document is to be a work in progress beginning with an overview, then delving into the specifics of each packet type. This will be of interest to writers of 802.11 MAC firmware, wireless scanners, and perhaps others interested in network discovery.

**Overview:**

Because 802.11 is itself more complex in it's options than 802.1 (Ethernet), it's frame format is likewise more complex. Since not all features of 802.11 are necessary for all packets, the 802.11 frame is variable in length. Fields that are not required for a particular frame type are simply omitted. The order of the fields is such that the leading fields are those that are always required and ending with the least commonly required such that fields are **ALWAYS** omitted by truncating the header, never by changing the starting octet of a field within the packet.

^ ^Frame control ^Duration ID ^Address 1 ^Address 2 ^Address3 ^Seq ctl ^Address 4 ^data ^Frame CRC ^ 
^Size (bytes)|2         | 2          |6         | 6        | 6        | 2     | 6        | 0-2,312 | 4 |

^           ^Sub-type ^Type ^protocol ^In Order^WEP^More data^Power Management^retry^more frag^From DS^To DS^
^Size (bits)|4        |2    |2        |1       |1  |1        |1               |1    |1        |1      |1    |
^           ^ MSB     ||^ -----------------------------------------------> ||||||^LSB|

Currently, the protocol version is always 00. If and when the spec evolves in a way that would confuse current devices which correctly implement version 0, the protocol version will be bumped to 01. Wireless devices must silently ignore packets with a version number greater than the one they implement.

Type is one of Management, control, or data. Broadly, Management frames are concerned with the administration of a domain (network discovery, joining, authenticating, leaving, de-authenticating, etc).

Control frames deal primarily with traffic control, that is, who can transmit how much and when. 

Data frames are the real point of the network. These carry data payloads which are generally packets of a higher level protocol such as IP.

^Type        ^Subtype ^Name ^
^Management  |||
^00          |0000    |Association request |
^            |0001    |Association response|
^            |0010    |Reassociation request |
^            |0011    |Reassociation response|
^            |0100    |Probe request |
^            |0101    |Probe response|
^            |1000    |Beacon|
^            |1001    |Announcement traffic indication message (ATIM)|
^            |1010    |Dis-association|
^            |1011    |Authentication|
^            |1100    |De-authentication|
^Control     |||
^01          |1010    |Power save Poll|
^            |1011    |RTS|
^            |1100    |CTS|
^            |1101    |ACK|
^            |1110    |Contention Free period end CF-end|
^            |1111    |CF-end + CF-ACK|
^Data        |||
^10          |0000    |data|
^            |0001    |data+CF-ACK|
^            |0010    |data+CF-poll|
^            |0011    |data+CF-ack+CF-poll|
^            |0100    |NULL data (no payload, used for power management)|
^            |0101    |NULL data+CF-ACK|
^            |0110    |NULL data+CF-poll|
^            |0111    |NULL data+CF-ack+CF-poll|


Note that while the data subtype is "officially" defined as above, it can as easily be seen as simple 1 bit fields as in:

^Data frame sub-type||||
|reserved (must be 0)| NULL data| CF-poll| CF-ACK|


**To DS and From DS**

These bits take together determine where the packet is going.

^To DS^ From DS^ ^
|1    |0       |Packet from station (client device) to AP|
|0    |1       |Packet from AP to station|
|1    |1       |WDS packet from AP to another AP|
|0    |0       |Station to Station packet in an ad-hoc (unmanaged) network|

**Address fields**
Unlike Ethernet (802.1), 802.11 frames have 4 address fields, but may use as few as one of them with the rest omitted. A receiving device can always know how many to expect based on the frame control field.

Address 1 is always present and defines which device(s) should accept the packet (in all cases) Thus, RX filtering in a device always looks at Address1.

The type, subtype, ToDS and FromDS fields determine the actual meaning (and presence) of the address fields.

^To DS^From DS^ Type^ Sub-type^ Purpose                             ^ Address 1^ Address 2^ Address 3^ Address 4^
|1    |0      | data| any     | packet transmitted from a node      | BSSID    | SA       | DA       | none|
|0    |1      | data| any     | packet recieved by a station from AP| DA       | BSSID    | SA       | none|
|1    |1      | data| any     | WDS packet                          | RA       | TA       | DA       | SA  |
|0    |0      | data| any     | packet in ad-hoc (unmanaged) network| DA       | SA       | IBSS     | none|
|0    |0      | ctrl| RTS     | request silence to send a large packet| DA     | SA       | none     | none|
|0    |0      | ctrl| CTS     | grant silence                       | DA (1)   | none     | none     | none|
|0    |0      | ctrl| ACK     | indicate reciept of a frame         | DA (2)   | none     | none     | none|
|0    |0      | ctrl| PS poll | Request any packets saved while sleeping| BSSID| SA       | none     | none|
|0    |0      | mgmt| any     |                                     | DA       | SA       | BSSID    | none|

BSSID = BSS ID of managed network = MAC address of AP.\\
DA = intended final recipiant (station)\\
SA = original sending Station\\
RA = recieving AP of a WDS pframe.\\
TA = transmitting AP of a WDS frame.\\

//DA(1) In this case, the destination is the SA of a preceeding RTS frame//\\
//DA(2) destination is the SA (sender) of a previous frme//\\