ieee80211_input.9 (571dba6ec9f25ecf7582dc2192daf1ceea70065f) ieee80211_input.9 (692eebe092e81927e190dd5eeb4f65d2324ea3fa)
1.\"
2.\" Copyright (c) 2004 Bruce M. Simpson <bms@spc.org>
3.\" Copyright (c) 2004 Darron Broad <darron@kewl.org>
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:

--- 11 unchanged lines hidden (view full) ---

20.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
21.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
22.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
23.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
24.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
25.\" SUCH DAMAGE.
26.\"
27.\" $FreeBSD$
1.\"
2.\" Copyright (c) 2004 Bruce M. Simpson <bms@spc.org>
3.\" Copyright (c) 2004 Darron Broad <darron@kewl.org>
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:

--- 11 unchanged lines hidden (view full) ---

20.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
21.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
22.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
23.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
24.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
25.\" SUCH DAMAGE.
26.\"
27.\" $FreeBSD$
28.\" $Id: ieee80211_input.9,v 1.6 2004/03/04 12:33:27 bruce Exp $
29.\"
28.\"
30.Dd March 2, 2004
29.Dd August 4, 2009
31.Dt IEEE80211_INPUT 9
32.Os
33.Sh NAME
30.Dt IEEE80211_INPUT 9
31.Os
32.Sh NAME
34.Nm ieee80211_input , ieee80211_decap , ieee80211_recv_mgmt
33.Nm ieee80211_input
35.Nd software 802.11 stack input functions
36.Sh SYNOPSIS
37.In net80211/ieee80211_var.h
34.Nd software 802.11 stack input functions
35.Sh SYNOPSIS
36.In net80211/ieee80211_var.h
38.In net80211/ieee80211_proto.h
39.Ft void
40.Fo ieee80211_input
37.Ft void
38.Fo ieee80211_input
41.Fa "struct ifnet *ifp" "struct mbuf *m" "struct ieee80211_node *ni"
42.Fa "int rssi" "u_int32_t rstamp"
39.Fa "struct ieee80211_node *"
40.Fa "struct mbuf *"
41.Fa "int rssi"
42.Fa "int noise"
43.Fc
43.Fc
44.Ft struct mbuf *
45.Fn ieee80211_decap "struct ifnet *ifp" "struct mbuf *m"
46.Ft void
44.Ft void
47.Fo ieee80211_recv_mgmt
48.Fa "struct ieee80211com *ic" "struct mbuf *m0" "struct ieee80211_node *ni"
49.Fa "int subtype" "int rssi" "u_int32_t rstamp"
45.Fo ieee80211_input_all
46.Fa "struct ieee80211com *"
47.Fa "struct mbuf *"
48.Fa "int rssi"
49.Fa "int noise"
50.Fc
51.Sh DESCRIPTION
50.Fc
51.Sh DESCRIPTION
52These
53functions process received 802.11 frames.
54.Pp
55.\"
56The
52The
53.Nm net80211
54layer that supports 802.11 device drivers requires that
55receive processing be single-threaded.
56Typically this is done using a dedicated driver
57.Xr taskqueue 9
58thread.
57.Fn ieee80211_input
59.Fn ieee80211_input
58function takes an mbuf chain
59.Fa m
60containing a complete 802.11 frame from the driver
61.Fa ifp
62and passes it to the software 802.11 stack for input processing.
63The
64.Fa ni
65argument specifies an instance of
66.Vt struct ieee80211_node
67(which may be driver-specific) representing the node from which the
68frame was received.
69The arguments
70.Fa rssi
71and
60and
72.Fa stamp
73are typically derived from on-card data structures; they are used for
74recording the signal strength and time received of the frame respectively.
61.Fn ieee80211_input_all
62process received 802.11 frames and are designed
63for use in that context; e.g. no driver locks may be held.
75.Pp
64.Pp
76.\"
77The
78.Fn ieee80211_decap
79function performs decapsulation of the 802.11 frame in the mbuf chain
80.Fa m
81received by the device
82.Fa ifp ,
83taking the form of the 802.11 address fields into account;
84the structure of 802.11 addresses vary according to the intended
85source and destination of the frame.
86It is typically called from within
87.Fn ieee80211_input .
65The frame passed up in the
66.Vt mbuf
67must have the 802.11 protocol header at the front; all device-specific
68information and/or PLCP must be removed.
69Any CRC must be stripped from the end of the frame.
70The 802.11 protocol header should be 32-bit aligned for
71optimal performance but receive processing does not require it.
72If the frame holds a payload and that is not aligned to a 32-bit
73boundary then the payload will be re-aligned so that it is suitable
74for processing by protocols such as
75.Xr ip 4 .
88.Pp
76.Pp
89.\"
77If a device (such as
78.Xr ath 4 )
79inserts padding after the 802.11 header to align
80the payload to a 32-bit boundary the
81.Dv IEEE80211_C_DATAPAD
82capability must be set.
83Otherwise header and payload are assumed contiguous in the mbuf chain.
84.Pp
85If a received frame must pass
86through the A-MPDU receive reorder buffer then the mbuf
87must be marked with the
88.Dv M_AMPDU
89flag.
90Note that for the moment this is required of all frames received from
91a station and TID where a Block ACK stream is active, not just A-MPDU
92aggregates.
93It is sufficient to check for
94.Dv IEEE80211_NODE_HT
95in the
96.Vt ni_flags
97of the station's node table entry, any frames that do not require reorder
98processing will be dispatched with only minimal overhead.
99.Pp
90The
100The
91.Fn ieee80211_recv_mgmt
92performs input processing for 802.11 management frames.
93It is typically called from within
94.Fn ieee80211_input .
95.\"
96.Sh SEE ALSO
97.Xr ieee80211 9 ,
98.Xr ifnet 9
99.Sh HISTORY
101.Vt rssi
102parameter is the Receive Signal Strength Indication of the frame
103measured in 0.5dBm units relative to the noise floor.
100The
104The
101.Nm ieee80211
102series of functions first appeared in
103.Nx 1.5 ,
104and were later ported to
105.Fx 4.6 .
106.Sh AUTHORS
107.An -nosplit
108This manual page was written by
109.An Bruce M. Simpson Aq bms@FreeBSD.org
110and
111.An Darron Broad Aq darron@kewl.org .
112.Sh BUGS
113There is no netisr queue specifically for the software 802.11 stack yet.
105.Vt noise
106parameter is the best approximation of the noise floor in
107dBm units at the time the frame was received.
108RSSI and noise are used by the
109.Nm net80211
110layer to make scanning and roaming decisions in station mode
111and to do auto channel selection for hostap and similar modes.
112Otherwise the values are made available to user applications
113(with the rssi presented as a filtered average over the last ten values
114and the noise floor the last reported value).
115.Sh SEE ALSO
116.Xr ieee80211 9 .