1.\" 2.\" Copyright (c) 2009 Sam Leffler, Errno Consulting 3.\" All rights reserved. 4.\" 5.\" Redistribution and use in source and binary forms, with or without 6.\" modification, are permitted provided that the following conditions 7.\" are met: 8.\" 1. Redistributions of source code must retain the above copyright 9.\" notice, this list of conditions and the following disclaimer. 10.\" 2. Redistributions in binary form must reproduce the above copyright 11.\" notice, this list of conditions and the following disclaimer in the 12.\" documentation and/or other materials provided with the distribution. 13.\" 14.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 15.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 16.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 17.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 18.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 19.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 20.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 21.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 22.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 23.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 24.\" SUCH DAMAGE. 25.\" 26.\" $FreeBSD: head/share/man/man9/ieee80211.9 233648 2012-03-29 05:02:12Z eadler $ 27.\" 28.Dd May 26, 2016 29.Dt IEEE80211 9 30.Os 31.Sh NAME 32.Nm ieee80211 33.Nd 802.11 network layer 34.Sh SYNOPSIS 35.In net/if.h 36.In net/if_media.h 37.In netproto/802_11/ieee80211_var.h 38.Ft void 39.Fn ieee80211_ifattach "struct ieee80211com *ic" 40.Ft void 41.Fn ieee80211_ifdetach "struct ieee80211com *ic" 42.Sh DESCRIPTION 43IEEE 802.11 device drivers are written to use the infrastructure provided 44by the 45.Nm 46software layer. 47This software provides a support framework for drivers that includes 48ifnet cloning, state management, and a user management API by which 49applications interact with 802.11 devices. 50Most drivers depend on the 51.Nm 52layer for protocol services but devices that off-load functionality 53may bypass the layer to connect directly to the device 54(e.g. the 55.Xr ndis 4 56emulation support does this). 57.Pp 58A 59.Nm 60device driver implements a virtual radio API that is exported to 61users through network interfaces (aka vaps) that are cloned from the 62underlying device. 63These interfaces have an operating mode 64(station, adhoc, hostap, wds, monitor, etc.) 65that is fixed for the lifetime of the interface. 66Devices that can support multiple concurrent interfaces allow 67multiple vaps to be cloned. 68This enables construction of interesting applications such as 69an AP vap and one or more WDS vaps 70or multiple AP vaps, each with a different security model. 71The 72.Nm 73layer virtualizes most 802.11 state 74and coordinates vap state changes including scheduling multiple vaps. 75State that is not virtualized includes the current channel and 76WME/WMM parameters. 77Protocol processing is typically handled entirely in the 78.Nm 79layer with drivers responsible purely for moving data between the host 80and device. 81Similarly, 82.Nm 83handles most 84.Xr ioctl 2 85requests without entering the driver; 86instead drivers are notified of state changes that 87require their involvement. 88.Pp 89The virtual radio interface defined by the 90.Nm 91layer means that drivers must be structured to follow specific rules. 92Drivers that support only a single interface at any time must still 93follow these rules. 94.Sh DATA STRUCTURES 95The virtual radio architecture splits state between a single per-device 96.Vt ieee80211com 97structure and one or more 98.Vt ieee80211vap 99structures. 100Drivers are expected to setup various shared state in these structures 101at device attach and during vap creation but otherwise should treat them 102as read-only. 103The 104.Vt ieee80211com 105structure is allocated by the 106.Nm 107layer as adjunct data to a device's 108.Vt ifnet ; 109it is accessed through the 110.Vt if_l2com 111structure member. 112The 113.Vt ieee80211vap 114structure is allocated by the driver in the 115.Dq vap create 116method 117and should be extended with any driver-private state. 118This technique of giving the driver control to allocate data structures 119is used for other 120.Nm 121data structures and should be exploited to maintain driver-private state 122together with public 123.Nm 124state. 125.Pp 126The other main data structures are the station, or node, table 127that tracks peers in the local BSS, and the channel table that defines 128the current set of available radio channels. 129Both tables are bound to the 130.Vt ieee80211com 131structure and shared by all vaps. 132Long-lasting references to a node are counted to guard against 133premature reclamation. 134In particular every packet sent/received holds a node reference 135(either explicitly for transmit or implicitly on receive). 136.Pp 137The 138.Vt ieee80211com 139and 140.Vt ieee80211vap 141structures also hold a collection of method pointers that drivers 142fill-in and/or override to take control of certain operations. 143These methods are the primary way drivers are bound to the 144.Nm 145layer and are described below. 146.Sh DRIVER ATTACH/DETACH 147Drivers attach to the 148.Nm 149layer with the 150.Fn ieee80211_ifattach 151function. 152The driver is expected to allocate and setup any device-private 153data structures before passing control. 154The 155.Vt ieee80211com 156structure must be pre-initialized with state required to setup the 157.Nm 158layer: 159.Bl -tag -width ic_channels 160.It Dv ic_ifp 161Backpointer to the physical device's ifnet. 162.It Dv ic_caps 163Device/driver capabilities; see below for a complete description. 164.It Dv ic_channels 165Table of channels the device is capable of operating on. 166This is initially provided by the driver but may be changed 167through calls that change the regulatory state. 168.It Dv ic_nchan 169Number of entries in 170.Dv ic_channels . 171.El 172.Pp 173On return from 174.Fn ieee80211_ifattach 175the driver is expected to override default callback functions in the 176.Vt ieee80211com 177structure to register its private routines. 178Methods marked with a 179.Dq * 180must be provided by the driver. 181.Bl -tag -width ic_channels 182.It Dv ic_vap_create* 183Create a vap instance of the specified type (operating mode). 184Any fixed BSSID and/or MAC address is provided. 185Drivers that support multi-bssid operation may honor the requested BSSID 186or assign their own. 187.It Dv ic_vap_delete* 188Destroy a vap instance created with 189.Dv ic_vap_create . 190.It Dv ic_getradiocaps 191Return the list of calibrated channels for the radio. 192The default method returns the current list of channels 193(space permitting). 194.It Dv ic_setregdomain 195Process a request to change regulatory state. 196The routine may reject a request or constrain changes (e.g. reduce 197transmit power caps). 198The default method accepts all proposed changes. 199.It Dv ic_send_mgmt 200Send an 802.11 management frame. 201The default method fabricates the frame using 202.Nm 203state and passes it to the driver through the 204.Dv ic_raw_xmit 205method. 206.It Dv ic_raw_xmit 207Transmit a raw 802.11 frame. 208The default method drops the frame and generates a message on the console. 209.It Dv ic_updateslot 210Update hardware state after an 802.11 IFS slot time change. 211There is no default method; the pointer may be NULL in which case 212it will not be used. 213.It Dv ic_update_mcast 214Update hardware for a change in the multicast packet filter. 215The default method prints a console message. 216.It Dv ic_update_promisc 217Update hardware for a change in the promiscuous mode setting. 218The default method prints a console message. 219.It Dv ic_newassoc 220Update driver/device state for association to a new AP (in station mode) 221or when a new station associates (e.g. in AP mode). 222There is no default method; the pointer may be NULL in which case 223it will not be used. 224.It Dv ic_node_alloc 225Allocate and initialize a 226.Vt ieee80211_node 227structure. 228This method cannot sleep. 229The default method allocates zero'd memory using 230.Xr kmalloc 9 . 231Drivers should override this method to allocate extended storage 232for their own needs. 233Memory allocated by the driver must be tagged with 234.Dv M_80211_NODE 235to balance the memory allocation statistics. 236.It Dv ic_node_free 237Reclaim storage of a node allocated by 238.Dv ic_node_alloc . 239Drivers are expected to 240.Em interpose 241their own method to cleanup private state but must call through 242this method to allow 243.Nm 244to reclaim its private state. 245.It Dv ic_node_cleanup 246Cleanup state in a 247.Vt ieee80211_node 248created by 249.Dv ic_node_alloc . 250This operation is distinguished from 251.Dv ic_node_free 252in that it may be called long before the node is actually reclaimed 253to cleanup adjunct state. 254This can happen, for example, when a node must not be reclaimed 255due to references held by packets in the transmit queue. 256Drivers typically interpose 257.Dv ic_node_cleanup 258instead of 259.Dv ic_node_free . 260.It Dv ic_node_age 261Age, and potentially reclaim, resources associated with a node. 262The default method ages frames on the power-save queue (in AP mode) 263and pending frames in the receive reorder queues (for stations using A-MPDU). 264.It Dv ic_node_drain 265Reclaim all optional resources associated with a node. 266This call is used to free up resources when they are in short supply. 267.It Dv ic_node_getrssi 268Return the Receive Signal Strength Indication (RSSI) in .5 dBm units for 269the specified node. 270This interface returns a subset of the information 271returned by 272.Dv ic_node_getsignal . 273The default method calculates a filtered average over the last ten 274samples passed in to 275.Xr ieee80211_input 9 276or 277.Xr ieee80211_input_all 9 . 278.It Dv ic_node_getsignal 279Return the RSSI and noise floor (in .5 dBm units) for a station. 280The default method calculates RSSI as described above; 281the noise floor returned is the last value supplied to 282.Xr ieee80211_input 9 283or 284.Xr ieee80211_input_all 9 . 285.It Dv ic_node_getmimoinfo 286Return MIMO radio state for a station in support of the 287.Dv IEEE80211_IOC_STA_INFO 288ioctl request. 289The default method returns nothing. 290.It Dv ic_scan_start* 291Prepare driver/hardware state for scanning. 292This callback is done in a sleepable context. 293.It Dv ic_scan_end* 294Restore driver/hardware state after scanning completes. 295This callback is done in a sleepable context. 296.It Dv ic_set_channel* 297Set the current radio channel using 298.Vt ic_curchan . 299This callback is done in a sleepable context. 300.It Dv ic_scan_curchan 301Start scanning on a channel. 302This method is called immediately after each channel change 303and must initiate the work to scan a channel and schedule a timer 304to advance to the next channel in the scan list. 305This callback is done in a sleepable context. 306The default method handles active scan work (e.g. sending ProbeRequest 307frames), and schedules a call to 308.Xr ieee80211_scan_next 9 309according to the maximum dwell time for the channel. 310Drivers that off-load scan work to firmware typically use this method 311to trigger per-channel scan activity. 312.It Dv ic_scan_mindwell 313Handle reaching the minimum dwell time on a channel when scanning. 314This event is triggered when one or more stations have been found on 315a channel and the minimum dwell time has been reached. 316This callback is done in a sleepable context. 317The default method signals the scan machinery to advance 318to the next channel as soon as possible. 319Drivers can use this method to preempt further work (e.g. if scanning 320is handled by firmware) or ignore the request to force maximum dwell time 321on a channel. 322.It Dv ic_recv_action 323Process a received Action frame. 324The default method points to 325.Fn ieee80211_recv_action 326which provides a mechanism for setting up handlers for each Action frame class. 327.It Dv ic_send_action 328Transmit an Action frame. 329The default method points to 330.Fn ieee80211_send_action 331which provides a mechanism for setting up handlers for each Action frame class. 332.It Dv ic_ampdu_enable 333Check if transmit A-MPDU should be enabled for the specified station and AC. 334The default method checks a per-AC traffic rate against a per-vap 335threshold to decide if A-MPDU should be enabled. 336This method also rate-limits ADDBA requests so that requests are not 337made too frequently when a receiver has limited resources. 338.It Dv ic_addba_request 339Request A-MPDU transmit aggregation. 340The default method sets up local state and issues an 341ADDBA Request Action frame. 342Drivers may interpose this method if they need to setup private state 343for handling transmit A-MPDU. 344.It Dv ic_addb_response 345Process a received ADDBA Response Action frame and setup resources as 346needed for doing transmit A-MPDU. 347.It Dv ic_addb_stop 348Shutdown an A-MPDU transmit stream for the specified station and AC. 349The default method reclaims local state after sending a DelBA Action frame. 350.It Dv ic_bar_response 351Process a response to a transmitted BAR control frame. 352.It Dv ic_ampdu_rx_start 353Prepare to receive A-MPDU data from the specified station for the TID. 354.It Dv ic_ampdu_rx_stop 355Terminate receipt of A-MPDU data from the specified station for the TID. 356.El 357.Pp 358Once the 359.Nm 360layer is attached to a driver there are two more steps typically done 361to complete the work: 362.Bl -enum 363.It 364Setup 365.Dq radiotap support 366for capturing raw 802.11 packets that pass through the device. 367This is done with a call to 368.Xr ieee80211_radiotap_attach 9 . 369.It 370Do any final device setup like enabling interrupts. 371.El 372.Pp 373State is torn down and reclaimed with a call to 374.Fn ieee80211_ifdetach . 375Note this call may result in multiple callbacks into the driver 376so it should be done before any critical driver state is reclaimed. 377On return from 378.Fn ieee80211_ifdetach 379all associated vaps and ifnet structures are reclaimed or inaccessible 380to user applications so it is safe to teardown driver state without 381worry about being re-entered. 382The driver is responsible for calling 383.Fn if_free 384on the ifnet it allocated for the physical device. 385.Sh DRIVER CAPABILITIES 386Driver/device capabilities are specified using several sets of flags 387in the 388.Vt ieee80211com 389structure. 390General capabilities are specified by 391.Vt ic_caps . 392Hardware cryptographic capabilities are specified by 393.Vt ic_cryptocaps . 394802.11n capabilities, if any, are specified by 395.Vt ic_htcaps . 396The 397.Nm 398layer propagates a subset of these capabilities to each vap through 399the equivalent fields: 400.Vt iv_caps , 401.Vt iv_cryptocaps , 402and 403.Vt iv_htcaps . 404The following general capabilities are defined: 405.Bl -tag -width IEEE80211_C_8023ENCAP 406.It Dv IEEE80211_C_STA 407Device is capable of operating in station (aka Infrastructure) mode. 408.It Dv IEEE80211_C_8023ENCAP 409Device requires 802.3-encapsulated frames be passed for transmit. 410By default 411.Nm 412will encapsulate all outbound frames as 802.11 frames (without a PLCP header). 413.It Dv IEEE80211_C_FF 414Device supports Atheros Fast-Frames. 415.It Dv IEEE80211_C_TURBOP 416Device supports Atheros Dynamic Turbo mode. 417.It Dv IEEE80211_C_IBSS 418Device is capable of operating in adhoc/IBSS mode. 419.It Dv IEEE80211_C_PMGT 420Device supports dynamic power-management (aka power save) in station mode. 421.It Dv IEEE80211_C_HOSTAP 422Device is capable of operating as an Access Point in Infrastructure mode. 423.It Dv IEEE80211_C_AHDEMO 424Device is capable of operating in Adhoc Demo mode. 425In this mode the device is used purely to send/receive raw 802.11 frames. 426.It Dv IEEE80211_C_SWRETRY 427Device supports software retry of transmitted frames. 428.It Dv IEEE80211_C_TXPMGT 429Device support dynamic transmit power changes on transmitted frames; 430also known as Transmit Power Control (TPC). 431.It Dv IEEE80211_C_SHSLOT 432Device supports short slot time operation (for 802.11g). 433.It Dv IEEE80211_C_SHPREAMBLE 434Device supports short preamble operation (for 802.11g). 435.It Dv IEEE80211_C_MONITOR 436Device is capable of operating in monitor mode. 437.It Dv IEEE80211_C_DFS 438Device supports radar detection and/or DFS. 439DFS protocol support can be handled by 440.Nm 441but the device must be capable of detecting radar events. 442.It Dv IEEE80211_C_MBSS 443Device is capable of operating in MeshBSS (MBSS) mode 444(as defined by 802.11s Draft 3.0). 445.It Dv IEEE80211_C_WPA1 446Device supports WPA1 operation. 447.It Dv IEEE80211_C_WPA2 448Device supports WPA2/802.11i operation. 449.It Dv IEEE80211_C_BURST 450Device supports frame bursting. 451.It Dv IEEE80211_C_WME 452Device supports WME/WMM operation 453(at the moment this is mostly support for sending and receiving 454QoS frames with EDCF). 455.It Dv IEEE80211_C_WDS 456Device supports transmit/receive of 4-address frames. 457.It Dv IEEE80211_C_BGSCAN 458Device supports background scanning. 459.It Dv IEEE80211_C_TXFRAG 460Device supports transmit of fragmented 802.11 frames. 461.It Dv IEEE80211_C_TDMA 462Device is capable of operating in TDMA mode. 463.El 464.Pp 465The follow general crypto capabilities are defined. 466In general 467.Nm 468will fall-back to software support when a device is not capable 469of hardware acceleration of a cipher. 470This can be done on a per-key basis. 471.Nm 472can also handle software 473.Dv Michael 474calculation combined with hardware 475.Dv AES 476acceleration. 477.Bl -tag -width IEEE80211_C_8023ENCAP 478.It Dv IEEE80211_CRYPTO_WEP 479Device supports hardware WEP cipher. 480.It Dv IEEE80211_CRYPTO_TKIP 481Device supports hardware TKIP cipher. 482.It Dv IEEE80211_CRYPTO_AES_OCB 483Device supports hardware AES-OCB cipher. 484.It Dv IEEE80211_CRYPTO_AES_CCM 485Device supports hardware AES-CCM cipher. 486.It Dv IEEE80211_CRYPTO_TKIPMIC 487Device supports hardware Michael for use with TKIP. 488.It Dv IEEE80211_CRYPTO_CKIP 489Devices supports hardware CKIP cipher. 490.El 491.Pp 492The follow general 802.11n capabilities are defined. 493The first capabilities are defined exactly as they appear in the 494802.11n specification. 495Capabilities beginning with IEEE80211_HTC_AMPDU are used solely by the 496.Nm 497layer. 498.Bl -tag -width IEEE80211_C_8023ENCAP 499.It Dv IEEE80211_HTCAP_CHWIDTH40 500Device supports 20/40 channel width operation. 501.It Dv IEEE80211_HTCAP_SMPS_DYNAMIC 502Device supports dynamic SM power save operation. 503.It Dv IEEE80211_HTCAP_SMPS_ENA 504Device supports static SM power save operation. 505.It Dv IEEE80211_HTCAP_GREENFIELD 506Device supports Greenfield preamble. 507.It Dv IEEE80211_HTCAP_SHORTGI20 508Device supports Short Guard Interval on 20MHz channels. 509.It Dv IEEE80211_HTCAP_SHORTGI40 510Device supports Short Guard Interval on 40MHz channels. 511.It Dv IEEE80211_HTCAP_TXSTBC 512Device supports Space Time Block Convolution (STBC) for transmit. 513.It Dv IEEE80211_HTCAP_RXSTBC_1STREAM 514Device supports 1 spatial stream for STBC receive. 515.It Dv IEEE80211_HTCAP_RXSTBC_2STREAM 516Device supports 1-2 spatial streams for STBC receive. 517.It Dv IEEE80211_HTCAP_RXSTBC_3STREAM 518Device supports 1-3 spatial streams for STBC receive. 519.It Dv IEEE80211_HTCAP_MAXAMSDU_7935 520Device supports A-MSDU frames up to 7935 octets. 521.It Dv IEEE80211_HTCAP_MAXAMSDU_3839 522Device supports A-MSDU frames up to 3839 octets. 523.It Dv IEEE80211_HTCAP_DSSSCCK40 524Device supports use of DSSS/CCK on 40MHz channels. 525.It Dv IEEE80211_HTCAP_PSMP 526Device supports PSMP. 527.It Dv IEEE80211_HTCAP_40INTOLERANT 528Device is intolerant of 40MHz wide channel use. 529.It Dv IEEE80211_HTCAP_LSIGTXOPPROT 530Device supports L-SIG TXOP protection. 531.It Dv IEEE80211_HTC_AMPDU 532Device supports A-MPDU aggregation. 533Note that any 802.11n compliant device must support A-MPDU receive 534so this implicitly means support for 535.Em transmit 536of A-MPDU frames. 537.It Dv IEEE80211_HTC_AMSDU 538Device supports A-MSDU aggregation. 539Note that any 802.11n compliant device must support A-MSDU receive 540so this implicitly means support for 541.Em transmit 542of A-MSDU frames. 543.It Dv IEEE80211_HTC_HT 544Device supports High Throughput (HT) operation. 545This capability must be set to enable 802.11n functionality 546in 547.Nm . 548.It Dv IEEE80211_HTC_SMPS 549Device supports MIMO Power Save operation. 550.It Dv IEEE80211_HTC_RIFS 551Device supports Reduced Inter Frame Spacing (RIFS). 552.El 553.Sh SEE ALSO 554.Xr ioctl 2 , 555.Xr ndis 4 , 556.\".Xr ieee80211_amrr 9 , 557.Xr ieee80211_beacon 9 , 558.Xr ieee80211_bmiss 9 , 559.Xr ieee80211_crypto 9 , 560.Xr ieee80211_ddb 9 , 561.Xr ieee80211_input 9 , 562.Xr ieee80211_node 9 , 563.Xr ieee80211_output 9 , 564.Xr ieee80211_proto 9 , 565.Xr ieee80211_radiotap 9 , 566.Xr ieee80211_regdomain 9 , 567.Xr ieee80211_scan 9 , 568.Xr ieee80211_vap 9 , 569.Xr ifnet 9 , 570.Xr kmalloc 9 571