This page describes the transmit frames that various hardware needs to get a frame on the air. It should allow us to get an overview what formats the stack needs to support and to help on the decision whether we will use 802.11 frames or 802.3 emulation when communicating to upper layers.

• 14 bytes control fields
• 30 bytes 802.11 4addr header
• 2 bytes length of data
• 14 bytes 802.3 daddr, saddr, type/length
• data, including IV, MIC, … if host encryption is selected

(to be completed after some sleep)

Srompf 16:19, 17 January 2006 (PST)

• 76 bytes hardware specific control fields
• 6 bytes PLCP information
• followed by the actual 802.11 information

If card should do encryption, then the IV must be given in the header as well as the 802.11 packet but the data not encrypted (obviously). ICV and FCS are appended by hardware, but must be accounted for in the PLCP header length.

Note that the data length isn't explicitly given except that it is encoded in the PLCP header.

For more details please see http://bcm-specs.sipsolutions.net/Sending

The prism2 header looks good, BTW. Note that AFAIK there's only one chipset that requires the use of 802.3 headers, and that is the prism54 (FullMAC) chipsets. The stack should use 802.11 representation internally, period. Actual frame representation of chipsets is all over the map, especially when encryption is involved, so let me propose this strawman format:

On a per-frame basis, you have the following logical chunks:

- 802.11 header (variable length)
- Encryption header (variable length)
- LLC SNAP header on payload (which we may need to add)
  - actual payload
- Encryption footer (variable length)

wiphy_frame_xmit (struct wiphy_dev *dev, struct sk_buff *skb);

skb→data points to the raw payload, with LLC SNAP header. skb→cb points to a structure that has, among other things:

 - 802.11 header   length
 - encryption header   length
 - encryption footer   length
 - desired data rate(s), antenna, rts/cts, and other tx params.
 - hw/sw encryption flag, and the key needed to encrypt.

Each driver would be responsible for rearranging these chunks as appropriate, ideally using scatter-gather DMA. That's why the chunks are all specified as chunk len; the driver can blindly copy the chunks without worrying about their contents.

Chipsets that require payload padding when using crypto can tell the 802.11 stack of this requirement, and the stack will pass the appropriate pads in via the crypt_header and crypt_footer.

Pizza 11:20, 18 January 2006 (PST)