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