bcm-specs

[Specification

When sending data (see DMA/PIO) it has to be sent not just with the PLCP header (always padded to 6 bytes) in front of it, but also a transmission header in front of that. So the structure is like this:

transmission header

PLCP header

PDU

76 bytes

6 bytes (including padding)

variable

This page serves as a starting point to document the first transmission header.

The transmission header has the following fields, all 2 or 4 byte fields here are in little endian.

offset (decimal)

name

size/type

explanation

0

flags

2 bytes

2

WSEC/RATE

2 bytes

see below

4

frame control

2 bytes

copied from packet

6

2 bytes

probably has some meaning, explicitly set to 0

8

control

2 bytes

bitfield of some things, see below

10

WEP IV/TKIP (phase 1) info

10 bytes

not necessarily all needed, though

20-22

3 bytes

copied out of the packet from some place (variable) when wsec is enabled and tkip is used. maybe the IV in that case?

26

address1 from the 802.11 header

6 bytes

Probably the address from which an ACK should come when it is expected (see flags below)

32

2 bytes

probably has some meaning, explicitly set to 0

34

another 4-byte PLCP header

4 bytes

RTS/CTS plcp fallback

38

2 bytes

RTS/CTS duration fallback

40

fallback PLCP header

4 bytes (the last 2 are cut off, but are always 0 anyway)

44

fallback duration/id field

2 bytes

48

internal ID

2 bytes

Internal ID, see below

50

2 bytes

something. scb stuff. disregard for now.

52

another 6-byte PLCP header

6 bytes

RTS/CTS plcp

58

2 bytes

RTS/CTS frame frame type

60

2 bytes

RTS/CTS duration

62-67

MAC address

6 bytes

RTS/CTS MAC address 1

68-73

MAC address

6 bytes

RTS/CTS MAC address 2

The fallback duration/id field is the same as the duration/id field in the 802.11 header, but as well as the fallback PLCP header adjusted for a lower transmit rate (if necessary).

The data starting at 52 is a RTS or CTS packet including 6-byte padded PLCP, which has it's own fallback PLCP and fallback duration at 34 and 38. Those MAC addresses are part of it, but you can read about that in the specification. I think the CTS packet here is for the CTS-to-self mechanism 802.11g introduced.

Fields not mentioned are 0.

flags

The flags field has the following bits:

Bit

Meaning

0x1

set this bit if expecting an ACK for this packet (not for multicast or broadcast etc. for example). If set, the chip will also retry the packet unless it gets an ACK up to "short retry limit" times (guess from observing the hardware). If retrying, the chip also sets the retry flag in the 802.11 header.

0x2

RTS/CTS present?

0x4

RTS present?

0x8

set for the first fragment of this packet

0x10

set, unless the packet to send is a PS poll (or another thing for APs, FIXME)

0x20

receiving station is in powersave mode (only relevant for APs)

0x80

RTS/CTS rate is a Clause 17 rate?

0x100

fallback rate is a Clause 17 rate (cf. 802.11 as amended by a and g)?

0x200

fallback RTS/CTS rate is a Clause 17 rate?

0x400

CTS present?

0x800

allow frameburst (cf. http://www.oreilly.com/catalog/802dot112/chapter/ch15.pdf page 7 of the PDF)?

I think the other bits are not used.

Control

The control field at offset 8 consists of the following

Bits

15-10

9-8

7-5

4

3-1

0

Meaning

unknown, there's code to set it but that can never trigger

AntennaDiversity

unused

short preamble control bit (not sure which way around, please test)

unused

on if the transmit rate is a clause 17 rate, i.e. the plcp header is clause 17

WSEC/RATE

Consists of the following

Bits

15-8

7-4

3

2-0

Meaning

unused

wsec key index

unused?

wsec algorithm (cf. Security)

Internal ID

This shows up in the TransmitStatus once status is given for this packet. Of course the hardware treats it as little endian. Can be used for packet identification.

Bits

15 - 8

7 - 4

3 - 2

1 - 0

Meaning

Sequence Number & 0xFF

Fragment #

Something to do with rates?

Queue


Exported/Archived from the wiki to HTML on 2016-10-27