xref: /freebsd/share/man/man9/ieee80211.9 (revision 96190b4fef3b4a0cc3ca0606b0c4e3e69a5e6717)
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.Dd April 24, 2024
29.Dt IEEE80211 9
30.Os
31.Sh NAME
32.Nm IEEE80211
33.Nd 802.11 network layer
34.Sh SYNOPSIS
35.In net80211/ieee80211_var.h
36.Ft void
37.Fn ieee80211_ifattach "struct ieee80211com *ic"
38.Ft void
39.Fn ieee80211_ifdetach "struct ieee80211com *ic"
40.Ft int
41.Fn ieee80211_mhz2ieee "u_int freq" "u_int flags"
42.Ft int
43.Fn ieee80211_chan2ieee "struct ieee80211com *ic" "const struct ieee80211_channel *c"
44.Ft u_int
45.Fn ieee80211_ieee2mhz "u_int chan" "u_int flags"
46.Ft int
47.Fn ieee80211_media_change "struct ifnet *ifp"
48.Ft void
49.Fn ieee80211_media_status "struct ifnet *ifp" "struct ifmediareq *imr"
50.Ft int
51.Fn ieee80211_setmode "struct ieee80211com *ic" "enum ieee80211_phymode mode"
52.Ft enum ieee80211_phymode
53.Fo ieee80211_chan2mode
54.Fa "const struct ieee80211_channel *chan"
55.Fc
56.Ft int
57.Fo ieee80211_rate2media
58.Fa "struct ieee80211com *ic" "int rate" "enum ieee80211_phymode mode"
59.Fc
60.Ft int
61.Fn ieee80211_media2rate "int mword"
62.Sh DESCRIPTION
63IEEE 802.11 device drivers are written to use the infrastructure provided
64by the
65.Nm
66software layer.
67This software provides a support framework for drivers that includes
68ifnet cloning, state management, and a user management API by which
69applications interact with 802.11 devices.
70Most drivers depend on the
71.Nm
72layer for protocol services but devices that off-load functionality
73may bypass the layer to connect directly to the device.
74.Pp
75A
76.Nm
77device driver implements a virtual radio API that is exported to
78users through network interfaces (aka vaps) that are cloned from the
79underlying device.
80These interfaces have an operating mode
81(station, adhoc, hostap, wds, monitor, etc.\&)
82that is fixed for the lifetime of the interface.
83Devices that can support multiple concurrent interfaces allow
84multiple vaps to be cloned.
85This enables construction of interesting applications such as
86an AP vap and one or more WDS vaps
87or multiple AP vaps, each with a different security model.
88The
89.Nm
90layer virtualizes most 802.11 state
91and coordinates vap state changes including scheduling multiple vaps.
92State that is not virtualized includes the current channel and
93WME/WMM parameters.
94Protocol processing is typically handled entirely in the
95.Nm
96layer with drivers responsible purely for moving data between the host
97and device.
98Similarly,
99.Nm
100handles most
101.Xr ioctl 2
102requests without entering the driver;
103instead drivers are notified of state changes that
104require their involvement.
105.Pp
106The virtual radio interface defined by the
107.Nm
108layer means that drivers must be structured to follow specific rules.
109Drivers that support only a single interface at any time must still
110follow these rules.
111.Pp
112Most of these functions require that attachment to the stack is performed
113before calling.
114.Pp
115.\"
116The
117.Fn ieee80211_ifattach
118function attaches the wireless network interface
119.Fa ic
120to the 802.11 network stack layer.
121This function must be called before using any of the
122.Nm
123functions which need to store driver state across invocations.
124.Pp
125.\"
126The
127.Fn ieee80211_ifdetach
128function frees any
129.Nm
130structures associated with the driver, and performs Ethernet and BPF
131detachment on behalf of the caller.
132.Pp
133.\"
134The
135.Fn ieee80211_mhz2ieee
136utility function converts the frequency
137.Fa freq
138(specified in MHz) to an IEEE 802.11 channel number.
139The
140.Fa flags
141argument is a hint which specifies whether the frequency is in
142the 2GHz ISM band
143.Pq Vt IEEE80211_CHAN_2GHZ
144or the 5GHz band
145.Pq Vt IEEE80211_CHAN_5GHZ ;
146appropriate clipping of the result is then performed.
147.Pp
148.\"
149The
150.Fn ieee80211_chan2ieee
151function converts the channel specified in
152.Fa *c
153to an IEEE channel number for the driver
154.Fa ic .
155If the conversion would be invalid, an error message is printed to the
156system console.
157This function REQUIRES that the driver is hooked up to the
158.Nm
159subsystem.
160.Pp
161.\"
162The
163.Fn ieee80211_ieee2mhz
164utility function converts the IEEE channel number
165.Ft chan
166to a frequency (in MHz).
167The
168.Fa flags
169argument is a hint which specifies whether the frequency is in
170the 2GHz ISM band
171.Pq Vt IEEE80211_CHAN_2GHZ
172or the 5GHz band
173.Pq Vt IEEE80211_CHAN_5GHZ ;
174appropriate clipping of the result is then performed.
175.Pp
176.\"
177The
178.Fn ieee80211_media_status
179and
180.Fn ieee80211_media_change
181functions are device-independent handlers for
182.Vt ifmedia
183commands and are not intended to be called directly.
184.Pp
185.\"
186The
187.Fn ieee80211_setmode
188function is called from within the 802.11 stack to change the mode
189of the driver's PHY; it is not intended to be called directly.
190.Pp
191.\"
192The
193.Fn ieee80211_chan2mode
194function returns the PHY mode required for use with the channel
195.Fa chan .
196This is typically used when selecting a rate set, to be advertised in
197beacons, for example.
198.Pp
199.\"
200The
201.Fn ieee80211_rate2media
202function converts the bit rate
203.Fa rate
204(measured in units of 0.5Mbps) to an
205.Vt ifmedia
206sub-type, for the device
207.Fa ic
208running in PHY mode
209.Fa mode .
210The
211.Fn ieee80211_media2rate
212performs the reverse of this conversion, returning the bit rate (in 0.5Mbps
213units) corresponding to an
214.Vt ifmedia
215sub-type.
216.
217.Sh DATA STRUCTURES
218The virtual radio architecture splits state between a single per-device
219.Vt ieee80211com
220structure and one or more
221.Vt ieee80211vap
222structures.
223Drivers are expected to setup various shared state in these structures
224at device attach and during vap creation but otherwise should treat them
225as read-only.
226The
227.Vt ieee80211com
228structure is allocated by the
229.Nm
230layer as adjunct data to a device's
231.Vt ifnet ;
232it is accessed through the
233.Vt if_l2com
234structure member.
235The
236.Vt ieee80211vap
237structure is allocated by the driver in the
238.Dq vap create
239method
240and should be extended with any driver-private state.
241This technique of giving the driver control to allocate data structures
242is used for other
243.Nm
244data structures and should be exploited to maintain driver-private state
245together with public
246.Nm
247state.
248.Pp
249The other main data structures are the station, or node, table
250that tracks peers in the local BSS, and the channel table that defines
251the current set of available radio channels.
252Both tables are bound to the
253.Vt ieee80211com
254structure and shared by all vaps.
255Long-lasting references to a node are counted to guard against
256premature reclamation.
257In particular every packet sent/received holds a node reference
258(either explicitly for transmit or implicitly on receive).
259.Pp
260The
261.Vt ieee80211com
262and
263.Vt ieee80211vap
264structures also hold a collection of method pointers that drivers
265fill-in and/or override to take control of certain operations.
266These methods are the primary way drivers are bound to the
267.Nm
268layer and are described below.
269.Sh DRIVER ATTACH/DETACH
270Drivers attach to the
271.Nm
272layer with the
273.Fn ieee80211_ifattach
274function.
275The driver is expected to allocate and setup any device-private
276data structures before passing control.
277The
278.Vt ieee80211com
279structure must be pre-initialized with state required to setup the
280.Nm
281layer:
282.Bl -tag -width ic_channels
283.It Dv ic_ifp
284Backpointer to the physical device's ifnet.
285.It Dv ic_caps
286Device/driver capabilities; see below for a complete description.
287.It Dv ic_channels
288Table of channels the device is capable of operating on.
289This is initially provided by the driver but may be changed
290through calls that change the regulatory state.
291.It Dv ic_nchan
292Number of entries in
293.Dv ic_channels .
294.El
295.Pp
296On return from
297.Fn ieee80211_ifattach
298the driver is expected to override default callback functions in the
299.Vt ieee80211com
300structure to register it's private routines.
301Methods marked with a
302.Dq *
303must be provided by the driver.
304.Bl -tag -width ic_channels
305.It Dv ic_vap_create*
306Create a vap instance of the specified type (operating mode).
307Any fixed BSSID and/or MAC address is provided.
308Drivers that support multi-bssid operation may honor the requested BSSID
309or assign their own.
310.It Dv ic_vap_delete*
311Destroy a vap instance created with
312.Dv ic_vap_create .
313.It Dv ic_getradiocaps
314Return the list of calibrated channels for the radio.
315The default method returns the current list of channels
316(space permitting).
317.It Dv ic_setregdomain
318Process a request to change regulatory state.
319The routine may reject a request or constrain changes (e.g. reduce
320transmit power caps).
321The default method accepts all proposed changes.
322.It Dv ic_send_mgmt
323Send an 802.11 management frame.
324The default method fabricates the frame using
325.Nm
326state and passes it to the driver through the
327.Dv ic_raw_xmit
328method.
329.It Dv ic_raw_xmit
330Transmit a raw 802.11 frame.
331The default method drops the frame and generates a message on the console.
332.It Dv ic_updateslot
333Update hardware state after an 802.11 IFS slot time change.
334There is no default method; the pointer may be NULL in which case
335it will not be used.
336.It Dv ic_update_mcast
337Update hardware for a change in the multicast packet filter.
338The default method prints a console message.
339.It Dv ic_update_promisc
340Update hardware for a change in the promiscuous mode setting.
341The default method prints a console message.
342.It Dv ic_newassoc
343Update driver/device state for association to a new AP (in station mode)
344or when a new station associates (e.g. in AP mode).
345There is no default method; the pointer may be NULL in which case
346it will not be used.
347.It Dv ic_node_alloc
348Allocate and initialize a
349.Vt ieee80211_node
350structure.
351This method cannot sleep.
352The default method allocates zero'd memory using
353.Xr malloc 9 .
354Drivers should override this method to allocate extended storage
355for their own needs.
356Memory allocated by the driver must be tagged with
357.Dv M_80211_NODE
358to balance the memory allocation statistics.
359.It Dv ic_node_free
360Reclaim storage of a node allocated by
361.Dv ic_node_alloc  .
362Drivers are expected to
363.Em interpose
364their own method to cleanup private state but must call through
365this method to allow
366.Nm
367to reclaim it's private state.
368.It Dv ic_node_cleanup
369Cleanup state in a
370.Vt ieee80211_node
371created by
372.Dv ic_node_alloc .
373This operation is distinguished from
374.Dv ic_node_free
375in that it may be called long before the node is actually reclaimed
376to cleanup adjunct state.
377This can happen, for example, when a node must not be reclaimed
378due to references held by packets in the transmit queue.
379Drivers typically interpose
380.Dv ic_node_cleanup
381instead of
382.Dv ic_node_free .
383.It Dv ic_node_age
384Age, and potentially reclaim, resources associated with a node.
385The default method ages frames on the power-save queue (in AP mode)
386and pending frames in the receive reorder queues (for stations using A-MPDU).
387.It Dv ic_node_drain
388Reclaim all optional resources associated with a node.
389This call is used to free up resources when they are in short supply.
390.It Dv ic_node_getrssi
391Return the Receive Signal Strength Indication (RSSI) in .5 dBm units for
392the specified node.
393This interface returns a subset of the information
394returned by
395.Dv ic_node_getsignal .
396The default method calculates a filtered average over the last ten
397samples passed in to
398.Xr ieee80211_input 9
399or
400.Xr ieee80211_input_all 9 .
401.It Dv ic_node_getsignal
402Return the RSSI and noise floor (in .5 dBm units) for a station.
403The default method calculates RSSI as described above;
404the noise floor returned is the last value supplied to
405.Xr ieee80211_input 9
406or
407.Xr ieee80211_input_all 9 .
408.It Dv ic_node_getmimoinfo
409Return MIMO radio state for a station in support of the
410.Dv IEEE80211_IOC_STA_INFO
411ioctl request.
412The default method returns nothing.
413.It Dv ic_scan_start*
414Prepare driver/hardware state for scanning.
415This callback is done in a sleepable context.
416.It Dv ic_scan_end*
417Restore driver/hardware state after scanning completes.
418This callback is done in a sleepable context.
419.It Dv ic_set_channel*
420Set the current radio channel using
421.Vt ic_curchan .
422This callback is done in a sleepable context.
423.It Dv ic_scan_curchan
424Start scanning on a channel.
425This method is called immediately after each channel change
426and must initiate the work to scan a channel and schedule a timer
427to advance to the next channel in the scan list.
428This callback is done in a sleepable context.
429The default method handles active scan work (e.g. sending ProbeRequest
430frames), and schedules a call to
431.Xr ieee80211_scan_next 9
432according to the maximum dwell time for the channel.
433Drivers that off-load scan work to firmware typically use this method
434to trigger per-channel scan activity.
435.It Dv ic_scan_mindwell
436Handle reaching the minimum dwell time on a channel when scanning.
437This event is triggered when one or more stations have been found on
438a channel and the minimum dwell time has been reached.
439This callback is done in a sleepable context.
440The default method signals the scan machinery to advance
441to the next channel as soon as possible.
442Drivers can use this method to preempt further work (e.g. if scanning
443is handled by firmware) or ignore the request to force maximum dwell time
444on a channel.
445.It Dv ic_recv_action
446Process a received Action frame.
447The default method points to
448.Xr ieee80211_recv_action 9
449which provides a mechanism for setting up handlers for each Action frame class.
450.It Dv ic_send_action
451Transmit an Action frame.
452The default method points to
453.Xr ieee80211_send_action 9
454which provides a mechanism for setting up handlers for each Action frame class.
455.It Dv ic_ampdu_enable
456Check if transmit A-MPDU should be enabled for the specified station and AC.
457The default method checks a per-AC traffic rate against a per-vap
458threshold to decide if A-MPDU should be enabled.
459This method also rate-limits ADDBA requests so that requests are not
460made too frequently when a receiver has limited resources.
461.It Dv ic_addba_request
462Request A-MPDU transmit aggregation.
463The default method sets up local state and issues an
464ADDBA Request Action frame.
465Drivers may interpose this method if they need to setup private state
466for handling transmit A-MPDU.
467.It Dv ic_addb_response
468Process a received ADDBA Response Action frame and setup resources as
469needed for doing transmit A-MPDU.
470.It Dv ic_addb_stop
471Shutdown an A-MPDU transmit stream for the specified station and AC.
472The default method reclaims local state after sending a DelBA Action frame.
473.It Dv ic_bar_response
474Process a response to a transmitted BAR control frame.
475.It Dv ic_ampdu_rx_start
476Prepare to receive A-MPDU data from the specified station for the TID.
477.It Dv ic_ampdu_rx_stop
478Terminate receipt of A-MPDU data from the specified station for the TID.
479.El
480.Pp
481Once the
482.Nm
483layer is attached to a driver there are two more steps typically done
484to complete the work:
485.Bl -enum
486.It
487Setup
488.Dq radiotap support
489for capturing raw 802.11 packets that pass through the device.
490This is done with a call to
491.Xr ieee80211_radiotap_attach 9 .
492.It
493Do any final device setup like enabling interrupts.
494.El
495.Pp
496State is torn down and reclaimed with a call to
497.Fn ieee80211_ifdetach .
498Note this call may result in multiple callbacks into the driver
499so it should be done before any critical driver state is reclaimed.
500On return from
501.Fn ieee80211_ifdetach
502all associated vaps and ifnet structures are reclaimed or inaccessible
503to user applications so it is safe to teardown driver state without
504worry about being re-entered.
505The driver is responsible for calling
506.Xr if_free 9
507on the ifnet it allocated for the physical device.
508.Sh DRIVER CAPABILITIES
509Driver/device capabilities are specified using several sets of flags
510in the
511.Vt ieee80211com
512structure.
513General capabilities are specified by
514.Vt ic_caps .
515Hardware cryptographic capabilities are specified by
516.Vt ic_cryptocaps .
517Software cryptographic capabilities are specified by
518.Vt ic_sw_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