1# 802.11 protocol overview 2 3This is a quick overview of the 802.11 protocol and where it intersects with 4net80211. It is not intended as a comprehensive deep dive into all of 802.11. 5 6TODO: link to appropriate sections in 802.11-2016 / 802.11-2020 depending upon 7which PDF is freely available. 8 9## 802.11 overview 10 11The 802.11 protocol / specification is a very large document which covers 12everything from the raw signals going out over the air up to how devices 13need to behave in different operating modes. 14 15The IEEE specification documents and amendments describe what devices should 16and must do in order to interoperate. It's important to note that the 17intersection of "what the standard says" and "what devices do" is not always 18fully aligned. The 802.11 specification has evolved over twenty-five years 19and for the most part this allows interoperability between the original 802.11b 20hardware and modern multi-band 802.11ax devices. 21 22It's also important to note that 802.11 is not just limited to the IEEE 23specifications. 802.11 devices are almost exclusively RF devices (if you 24read the specification you may find the old infrared / IR protocol definition!) 25and so need to operate inside of the radio regulatory rules defined by each 26country. These define a wide variety of RF environmental behaviours 27including frequencies can be used, when devices can transmit, what transmit 28power is allowed, interoperability with other devices (802.11 and non-802.11) 29and radar interoperability. For the purposes of this document these will 30be called "regulatory concerns" and will be covered elsewhere. 31 32The 802.11 specification breaks things up into a handful of top level areas: 33 34 * the PHY layer - how the device interfaces with the RF environment and 35 encodes/decodes RF transmissions into data streams. 36 * the MAC layer - defines how data is packetized into individual data frames, 37 exchanged with the upper layer (ethernet/bridge), deciding when and what 38 to transmit via the PHY layer. 39 * MLME - (MAC layer management entities) - defines all of the state methods 40 and transitions that underpin the 802.11 MAC state machine. 41 * Security - the cipher and key management components. 42 * PHY specifications - the specific implementations of PHYs - 2GHz DSSS 43 (spread spectrum), 2GHZ CCK, OFDM, ERP, 802.11n / HT, 802.11ac / VHT, etc. 44 45Most 802.11 implementations do not implement a 1:1 definition of each of these 46layers - notably implementing every single MLME state would be a huge amount 47of work. 48 49## 802.11 revisions 50 51There have been many revisions of the 802.11 specification. The specifications 52can be found online at https://www.ieee802.org/11/. 53 54The latest specification being implemented in net80211 is 802.11-2020, however 55net80211 is far from completely compliant. Generally new code which implements 56802.11 features / protocol handling should identify the specification and 57section which it is referencing. 58 59## 802.11 protocol and frame definitions 60 61net80211 keeps most 802.11 frame and protocol definitions in a single location 62(ieee80211.h). 63This contains descriptions of the 802.11 frame and field definitions, ranging 64from the lowest definition of the frame itself up through frame types/subtypes, 65individual field definitions, information elements, action frames, and 66anything else that can be found in the 802.11 specifications. 67 68The PHY definitions can be found in (ieee80211_phy.c) and (ieee80211_phy.h). 69Notably those include the frame timing information useful for rate control 70and frame duration calculations. 71 72## 802.11 Revisions 73 74(TBD) 75 76### Legacy 802.11 77 78The earliest 802.11 devices implement 1Mbit/s and 2Mbit/s direct spread spectrum 79frames. These include the earliest Wavelan devices. These are grandfathered 80into 802.11b. The PHY specification can be found in 802.11-2020 Section 15.) 81 82### 802.11b 83 84802.11b devices implement Section 15 (1Mbit/2Mbit) PHYs as well as the high 85rate DSSS specification (802.11-2020 Section 16) to provide 5.5Mbit and 11Mbit 86CCK rates. They interoperate with legacy 802.11 devices by using compatible 87PHY encodings and will limit their performance if said legacy devices are 88detected. 89 90### 802.11a 91 92802.11a devices implement OFDM rates from 6Mbit/s to 54Mbit/s on the 5GHz 93band. Among other features, it also defines 5MHz and 10MHz wide channel 94behaviour. This is covered in the OFDM PHY specification (802.11-2020 95Section 17.) 96 97### 802.11g 98 99802.11g devices implement OFDM rates from 802.11a, the CCK rates from 802.11b 100and the DSSS rates from legacy 802.11. These are covered in the ERP 101specification (802.11-2020 Section 18.) There are some MAC extensions for 102negotiating 802.11b / 802.11g interoperability and these are documented 103throughout the MAC specification. This also specifies support for 5MHz and 10410MHz wide channels. 105 106### 802.11n (HT) 107 108802.11n introduced a variety of high throughput rates and feature support 109(hence why it's called HT - high throughput). It introduces higher density 110OFDM rate encodings, 20 and 40MHz wide channels with interoperability for 111earlier devices, packet aggregation via A-MPDU and A-MSDU, MIMO (multiple input, 112multiple output spatial streams), some initial beamforming support, power 113saving extensions and more. 114 115The physical layer support is covered in the HT PHY specification (802.11-2020 116Section 19.) The rest of the MAC extensions are documented throughout the 117rest of the specification. 118 119### 802.11ac (VHT) 120 121802.11ac extends the 802.11n specification (hence why it's VHT - Very 122High Throughput) and boosts performance by adding higher density OFDM QAM 123encoding (256-QAM), wider channels (80MHz, 160MHz), split 80+80MHz channel 124support, much larger A-MSDU / A-MPDU frame sizes, support for MU-MIMO 125(multi-user MIMO) allowing APs to transmit to multiple STAs at the same time 126and various other extensions. 127 128It builds on top of the 802.11n MAC and PHY specification, so a lot of 129802.11n feature and MAC negotiation happens as part of 802.11ac negotiation. 130 131The PHY layer is covered in the VHT PHY Specification (802.11-2020 Section 13221.) Again, the rest of the MAC extensions are documented throughout the 133rest of the specification. 134 135### Greenfield versus backwards compatibility 136 137The various protocols supported by 802.11 build on top of earlier protocols. 138So typically you're not building a single implementation for each protocol - 139for example, you can't handle 802.11ac support without implementing a large 140amount of 802.11n support. 141 142(As a side note, the 802.11 frame has a protocol version field, and 143that actually changed in 802.11ah (900MHz and longer distance bands) - 144which changes a lot of what the fields do. No, net80211 currently does not 145support 802.11ah and will drop frames whose 802.11 protocol ID is not 146supported.) 147 148At the PHY layer, later model hardware can transmit data encodings which 149earlier model hardware just won't recognise. All they'll see is an increase 150in RF power on the channel at best and signals that will confuse the 151RX decoder / cause hardware issues at worst.) 152 153So each of the PHY specifications will lay out a few things: 154 155 * How frames should be encoded in the air in a way that earlier 156 hardware can decode them enough to know it's not for them; 157 * How devices can identify that earlier protocol devices are around and 158 change the configuration (eg STA changing its own configuration, 159 AP changing the configuration of the network it controls, etc) 160 to provide backwards compatibility. 161 162These come at a performance cost. For example, an 802.11g AP which 163supports 802.11b and 802.11 devices needs to notice that an 802.11b 164device wishes to associate, and when it sees this, change some of 165its configuration (notably "long preamble" so 802.11b devices can 166decode frames that are being transmitted, whether destined to it or not.) 167 168Various devices allow backwards compatbility to be configured. 169For example, an 802.11n AP may be configured to deny non-802.11n clients. 170This may improve performance but then earlier clients can't connect. 171 172In 802.11n deployments this was known as a "greenfield deployment". 173This typically disables any and all pre-11n interoperability at both 174a MAC and PHY layer. net80211 has some flags for this to specifically 175inform devices that they can configure the hardware for such a setup. 176Not all drivers implement it however, and in a lot of cases they will 177still handle pre-11n framing, even if the net80211 code will deny 178association. 179 180There are other components to backwards compatibility which are worth 181keeping in mind when reading through the 802.11 specification and 182net80211 stack / driver code. These include: 183 184 * short/long preamble - (vap_update_preamble) 185 * short/long slot time configuration - (vap_update_slot) 186 * 802.11g protection mode (vap_update_erp_protmode) - 187 whether to use CTS-to-self around each transmission 188 * 802.11n protection mode (vap_update_ht_protmode) - 189 whether to use RTS/CTS around each transmission 190 * 802.11n 20/40MHz BSS operation (whether an 802.11n AP sees other APs that 191 overlap its frequency range and need to reconfigure how to protect 192 transmissions) 193 194## How 802.11 (very briefly) works over the air 195 196This is a very brief and not at all comprehensive overview of how 802.11 197works over the air. The goal of this section is to provide enough background 198information to help de-mystify reading the net80211 stack and wireless 199driver source. 200 201### Why there's timing requirements in the first place 202 203Each of the PHY sections in the 802.11 specification describe what 204the PHY needs to do in order to transmit and receive data. It's not 205anywhere as easy as "toggle some bits on a wire". 206 207An important thing to understand is that hardware isn't immediate. 208All the state machines in your 802.11 devices take non-zero time 209to make decisions about when to transmit, when to receive, locking 210onto a signal, deciding it can be decoded, getting reset for the next 211frame, etc. 212 213So a lot of what you'll see in 802.11 negotiation and feature support 214is linked to the underlying hardware implementations and limitations 215of the time. For example the 802.11b specification defines the slot time 216as 20uS, but the 802.11g specification lowers it to 9uS. The "slot time" 217value defines the unit of time used for contention management / backoff, and 218it's defined partly by what the speed of light dictates (ie how big 219of a physical area you want to be able to "hear" in determining if the 220area is busy) and how quickly the hardware can guarantee to respond. 221It dropped to 9uS because hardware got better, but to interoperate 222with older devices without starting to transmit before they're 223ready to react, 802.11g devices will fall back to 20uS slot time when 224they detect an 802.11b device. 225 226This carries through everywhere in odd places that you're not necessarily 227aware of. For example, the 802.11n A-MPDU definition includes negotiated 228padding between frames and limits encryption ciphers (typically CCMP or 229GCMP.) This is due to hardware support - the MAC may be able to support 230much less padding when no encryption is used, but setting up / resetting 231the encryption / decryption blocks may take more time and thus larger 232A-MPDU padding values are negotiated. 233 234### Wait, the speed of light? 235 236Yes. The speed of light is roughly 300 metres for each microsecond of 237travel time. 238 239### Preambles, SIGs, PLCP, sending actual data and waiting / slot times 240 241There are a few things that are worth understanding at a high level. 242 243 * The first thing that a device needs to do is determine 244 whether the air is busy or free. There'll be some hardware 245 to determine the signal level versus noise floor and provide 246 a signal to the transmit hardware that the air is free, 247 and to the receiver that it may want to try start decoding 248 something. 249 250 * The receiver needs to get in synchronisation with the transmitter. 251 This is a one way operation - the transmitter needs to transmit 252 enough of a signal that the receiver can "lock onto" and get itself 253 ready for further data. This is called the "preamble" - it's 254 typically a low bitrate repeating pattern of data that gives 255 the receiver hardware time to lock onto, figure out the signal 256 level and be ready for the next phase. 257 258 * Note that the receiver may pick up the preamble at any point in its 259 transmission so it can't guarantee it will see exactly "x" bits of some 260 repeating pattern. 261 262 * Then there's other bits and pieces - eg look for L-SIG, HT-SIG 263 in the PHY documentation - which is used to further synchronise 264 what's about to happen. 265 266 * Finally it will start transmitting the PHY framing bits needed to 267 identify what the upcoming transmit rate and configuration is 268 (all the stuff leading up to the PLCP header, then the PLCP header.) 269 270Things get more complicated with MIMO, MU-MIMO, 802.11ax OFDM-A, etc but 271don't worry about those for now - they build on top of all of these 272ideas. 273 274Once the data is transmitted, there's some quiet time between frames 275before the receiver can ACK (and then a period of time where an ACK 276is expected.) The transmitter needs to finish transmitting, then 277reset its internal state back to idle to be ready to receive - and 278there's the pesky speed of light speed of 300m per microsecond - 279so there's some MAC (interframe spacing) and PHY (slot time) enforcing 280quiet so everyone has a chance to receive the frame and the reciver 281gets ready to receive. Then if there's an ACK, the ACK happens. 282 283### PLCP header 284 285Once all of the preamble, SIG/training stuff is done, the transmitter 286will send a PLCP header with information about the transmitter 287type and rate (and that's very handwaving it.) net80211 has definitions 288for the plcp header (ieee80211_plcp_hdr) but it's highly unlikely it will 289be relevant or available in modern devices. 290 291### How data is encoded - encoding rates, symbols, guard intervals 292 293Now, once the transmitter has sent all of that, it will start to send 294actual data encoded at the desired transmit rate. The data bits 295that you're transmitting go through a variety of encoding schemes 296before they're turned into bits that are clocked out at the 802.11 297physical layer (think "forward error correction" as an example), 298but they're turned into what are known as "symbols". 299 300A symbol can be thought of as a group of bits encoded in one specific 301RF representation. Explaining all the details isn't in scope of this 302document (and I encourage interested parties to do a quick dive 303into information theory!) but there are a couple of important higher 304level concepts to understand here that influence what happens 305later on in packet delivery. 306 307For OFDM encoding: 308 309 * Each symbol is preceded by a quiet time called a guard interval, to make 310 sure any reflections don't interfere with the upcoming symbol; 311 * Each symbol is then transmitted for a specific length of time to make sure 312 it's received by everyone inside the desired area (again light = 300m/sec 313 per microsecond); 314 * All symbols for a given 802.11 MPDU are sent at the exact same rate; 315 * This is repeated until all the symbols are transmitted. 316 317The higher the data rate used, the higher the signal level needs to be 318and lower the tolerance it has to interference. Forward error correction 319can only do so much, and the higher throughput rate encodings sacrifice 320FEC for throughput. 321 322Once an uncorrectable error occurs and the frame fails CRC, the whole MPDU is 323dropped by the receiver. 324 325Part of why A-MPDU is so important for high throughput is that the 326errors are limited to a single MPDU in the burst of MPDUs. Ie, if 327the transmitter sends ten MPDUs in a single A-MPDU, and five of them 328have uncorrectable errors, then five .. well, didn't. This means 329the receiver can ACK some but not all of the MPDUs, and the transmitter 330can re-send those with new MPDUs. 331 332The default guard interval is 800ns. 802.11n allows for negotiating 333shorter guard interval (400ns) which can be done per device in a BSS. 334An 800ns guard interval is a little short of 300 metres, and 400ns is 335a little short of 150 metres - so using short guard interval means 336you trade increased performance for potential decreased performance 337if you have reflections or stations more than 150 metres away. 338 339802.11ax adds support for 1.6us and 3.2us guard intervals for physically 340larger deployments. 341 342### MAC layer framing 343 344The MAC layer handles data that is encapsulated in the given transmit 345rate that was established in the PHY (PLCP) header. This includes 346the 802.11 MAC header, CRC trailer, any of the cipher processing that 347happens in between. In the case of 802.11n, it can encapsulate 348multiple frames being sent back to back in a single transmission. 349 350Devices which do partial / no offload will typically produce and 351consume 802.11 MAC layer frames to the driver and net80211. 352It's thus important to understand MAC framing and frame types. 353 354### MPDU versus MSDU 355 356An MSDU (MAC service data unit) is an individual frame (think "802.2/802.3 357ethernet") passed from the network stack into net80211. 358 359An MPDU (MAC protocol data unit) is one or more MSDU frames wrapped by an 360(ieee80211_frame) header and CRC trailer. It is what is eventually 361encapsulated inside the PHY framing (preambles, training symbols, PLCP 362header, etc) and sent over the air. 363 364Notably an 802.11 MPDU isn't just an IPv4/IPv6 frame with an 802.11 365header/trailer - it is a full ethernet frame that is being wrapped 366by 802.11 framing. 367 368### Tracking airtime with NAV 369 370802.11 devices have to interoperate in a shared medium. Earlier protocol 371definitions require one transmitter at a time. Later specification 372devices (MU-MIMO with 802.11ac, OFDM-A with 802.11ax, etc) introduce the 373ability for devices to transmit and receive simultaneously. 374 375The simplest way to track this is with NAV (network access vector.) 376The NAV implementation in pre-11ax devices is a single counter which 377counts down to zero. Once it is zero, the air is considered "available" 378to attempt to check to transmit on. The transmitter will also check 379whether the air is busy (ie can it detect any signals present) before 380it transmits - this is called CCA (clear channel access) and is 381typically implemented in hardware. 382 383The duration field in (ieee80211_frame) is a microsecond field which 384covers the whole duration of the frame being transmitted. Receivers 385that decode the frame - even if it's not destined to them! - will listen 386to the NAV and add it to their own NAV. 387 388All 802.11 frames have a duration field. 389 390### Fragmented frames 391 392(TBD) 393 394### Sequence counters and duplication detection 395 396(TBD) 397 398### EDCA and QoS 399 400(TBD) 401 402### Inter-frame spacing (IFS) 403 404(TBD) 405 406## 802.11 frame layout 407 408An individual 802.11 frame contains frame control (version, type, subtype), 409duration, addressing, sequence number and optional QoS information. 410The basic definition is available at (ieee80211_frame) but other definitions 411are also possible - (ieee80211_qosframe), (ieee80211_frame_addr4), 412(ieee80211_qosframe_addr4). 413 414It then has a 4 byte CRC32 trailer appended at the end. 415 416### Addressing types and traffic direction 417 418(TBD - 3addr, 4addr, each of the fields, etc) 419 420### QoS versus non-QoS frames 421 422(TBD) 423 424### RTS/CTS exchange and airtime 425 426(TBD) 427 428### CTS-to-self / OFDM protection 429 430CTS to self is a concept introduced in 802.11g. The general idea is that a 431transmitter can send a CTS to its own MAC address for the duration that it 432wishes to transmit for. Since the CTS frame is transmitted at a slower 433legacy rate, it both reserves airtime in any receiver in earshot, and 434it is understood by older 11b only devices which do not understand 11g. 435 436This ends up also being useful for 11n, 11ac etc to interoperate with 437earlier devices, but they typically rely on a normal RTS exchange. 438 439### Data frames 440 441(TBD) 442 443### Management frames 444 445(TBD) 446 447### Control frames 448 449(TBD) 450 451Notably, control frames do not have a sequence number and so can't be 452de-duplicated. 453 454### Action frames 455 456(TBD) 457 458## Frame combinations 459 460There are various ways that 802.11 frames are combined together to improve 461performance. 462 463### ACK, Delayed Block-ACK, Immediate Block-ACK 464 465(TBD) 466 467### Atheros Fast Frames 468 469(TBD) 470 471### A-MSDU 472 473(TBD) 474 475### A-MPDU 476 477(TBD) 478 479## Security / Encryption 480 481This is a much larger topic, however it's worth touching on the basics here to 482understand how frames are redirected into the security/encryption paths in 483net80211 and what devices may do with said frames. 484 485### WEP, IV header and keys 486 487WEP is an obsolete encryption method dating back to the earliest 802.11b 488specifications. It involves a 4 byte header which includes 489 490 * a 24 bit IV (initialisation vector); 491 * a 2 bit field indication which of four keys to use; 492 * A CRC at the end. 493 494It's relevant today because later cipher frame formats still use the IV 495header - they're just extended to include more information. Notably, the 496four key indexes are typically implemented and used in hardware, and have 497different meanings depending upon the kind of traffic being handled. 498 499### WPA/WPA2 management 500 501This is handled in userland. The 802.11 specification covers everything 502involved in key exchange and management but it's out of scope for this 802.11 503overview documentation. 504 505### CCMP, GCMP, TKIP frames 506 507These later ciphers still use the WEP header, but they then add extra bytes 508to it to include the larger sequence number space, other options needed 509for said ciphers, and a larger trailer for CRC and TKIP MIC. 510 511### IV duplication / tracking 512 513net80211 tracks the received IV / sequence number for each station indexed 514by QoS TID. Anything with an earlier IV is discarded as a stale packet or 515potential replay attack. See the ni_txseqs[] and ni_rxseqs[] field in 516(ieee80211_node). 517 518Note that the 802.11 layer sequence number field will apply /first/. Traffic 519which the 802.11 input layer thinks is old or retransmits will be discarded 520before handed to the net80211 crypto routines. 521 522### Unicast vs Group Keys 523 524WEP has four global keys which are shared between all devices wishing to 525communicate. The keys are provided in the WEP header. 526 527However for later ciphers the four key indexes start taking on new meanings. 528Notably key index 0 is the "unicast key" which handles traffic for a given 529station and is unique for that station, and keys 2 and 3 are used for 530group keys - shared keys for broadcast traffic that all stations need to be 531able to decrypt. 532 533(key 1 is also used for unicast station traffic for seamless station key 534updating, but net80211 currently doesn't support this extension/feature.) 535 536There's also upcoming work for encrypted management traffic and encrypted 537beacons which reuse the key indexes for their traffic, but then don't treat 538them as "global keys" - they start being treated as "global keys but only 539for this traffic type." 540 541It's important to understand the difference between global keys (WEP) versus 542group and unicast keys (everything else) when looking through the net80211 543data and encryption handling paths. 544 545## 802.11 Operating Modes 546 547(TBD) 548 549### Station 550 551(TBD) 552 553### Access Point 554 555(TBD) 556 557### IBSS / Ad-Hoc 558 559(TBD) 560 561### Mesh / 802.11s 562 563(TBD) 564