IEEE80211_OUTPUT(9) BSD Kernel Developer's Manual IEEE80211_OUTPUT(9)NAMEieee80211_output — software 802.11 stack output functions
M_WME_GETAC(struct mbuf *);
M_SEQNO_GET(struct mbuf *);
struct ieee80211_key *
ieee80211_crypto_encap(struct ieee80211_node *, struct mbuf *);
ieee80211_process_callback(struct ieee80211_node *, struct mbuf *, int);
The net80211 layer that supports 802.11 device drivers handles most of
the work required to transmit frames. Drivers usually receive fully-
encapsulated 802.11 frames that have been classified and assigned a
transmit priority; all that is left is to do crypto encapsulation, pre‐
pare any hardware-specific state, and push the packet out to the device.
Outbound frames are either generated by the net80211 layer (e.g. manage‐
ment frames) or are passed down from upper layers through the ifnet(9)
transmit queue. Data frames passed down for transmit flow through
net80211 which handles aggregation, 802.11 encapsulation, and then dis‐
patches the frames to the driver through it's transmit queue.
There are two control paths by which frames reach a driver for transmit.
Data packets are queued to the device's if_snd queue and the driver's
if_start method is called. Other frames are passed down using the
ic_raw_xmit method without queueing (unless done by the driver). The raw
transmit path may include data frames from user applications that inject
them through bpf(4) and NullData frames generated by net80211 to probe
for idle stations (when operating as an access point).
net80211 handles all state-related bookkeeping and management for the
handling of data frames. Data frames are only transmit for a vap in the
IEEE80211_S_RUN state; there is no need, for example, to check for frames
sent down when CAC or CSA is active. Similarly, net80211 handles activi‐
ties such as background scanning and power save mode, frames will not be
sent to a driver unless it is operating on the BSS channel with “full
All frames passed to a driver for transmit hold a reference to a node ta‐
ble entry in the m_pkthdr.rcvif field. The node is associated with the
frame destination. Typically it is the receiver's entry but in some sit‐
uations it may be a placeholder entry or the “next hop station” (such as
in a mesh network). In all cases the reference must be reclaimed with
ieee80211_free_node() when the transmit work is completed. The rule to
remember is: net80211 passes responsibility for the mbuf and “node
reference” to the driver with each frame it hands off for transmit.
All frames passed by net80211 for transmit are assigned a priority based
on any vlan tag assigned to the receiving station and/or any Diffserv
setting in an IP or IPv6 header. If both vlan and Diffserv priority are
present the higher of the two is used. If WME/WMM is being used then any
ACM policy (in station mode) is also enforced. The resulting AC is
attached to the mbuf and may be read back using the M_WME_GETAC() macro.
PAE/EAPOL frames are tagged with an M_EAPOL mbuf flag; drivers should
transmit them with care, usually by using the transmit rate for manage‐
ment frames. Multicast/broadcast frames are marked with the M_MCAST mbuf
flag. Frames coming out of a station's power save queue and that have
more frames immediately following are marked with the M_MORE_DATA mbuf
flag. Such frames will be queued consecutively in the driver's if_snd
queue and drivers should preserve the ordering when passing them to the
The net80211 layer will fragment data frames according to the setting of
iv_fragthreshold if a driver marks the IEEE80211_C_TXFRAG capability.
Fragmented frames are placed in the devices transmit queue with the frag‐
ments chained together with m_nextpkt. Each frame is marked with the
M_FRAG mbuf flag, and the first and last are marked with M_FIRSTFRAG and
M_LASTFRAG, respectively. Drivers are expected to process all fragments
Frames sent by net80211 may be tagged with the M_TXCB mbuf flag to indi‐
cate a callback should be done when their transmission completes. The
callback is done using ieee80211_process_callback() with the last parame‐
ter set to a non-zero value if an error occurred and zero otherwise.
Note net80211 understands that drivers may be incapable of determining
status; a device may not report if an ACK frame is received and/or a
device may queue transmit requests in its hardware and only report status
on whether the frame was successfully queued.
SEE ALSObpf(4), ieee80211(9), ifnet(9)BSD March 29, 2010 BSD