xref: /freebsd/share/man/man9/ieee80211.9 (revision 32100375a661c1e16588ddfa7b90ca8d26cb9786)
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