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