table of contents
|IEEE80211_PROTO(9)||Kernel Developer's Manual||IEEE80211_PROTO(9)|
802.11 state machine support
ieee80211vap *, enum
net80211 layer that supports 802.11
device drivers uses a state machine to control operation of vaps. These
state machines vary according to the vap operating mode. Station mode state
machines follow the 802.11 MLME states in the protocol specification. Other
state machines are simpler and reflect operational work such as scanning for
a BSS or automatically selecting a channel to operate on. When multiple vaps
are operational the state machines are used to coordinate operation such as
choosing a channel. The state machine mechanism also serves to bind the
net80211 layer to a driver; this is described more
The following states are defined for state machines:
- Default/initial state. A vap in this state should not hold any dynamic state (e.g. entries for associated stations in the node table). The driver must quiesce the hardware; e.g. there should be no interrupts firing.
- Scanning for a BSS or choosing a channel to operate on. Note that scanning can also take place in other states (e.g. when background scanning is active); this state is entered when initially bringing a vap to an operational state or after an event such as a beacon miss (in station mode).
- Authenticating to an access point (in station mode). This state is
normally reached from
IEEE80211_S_SCANafter selecting a BSS, but may also be reached from
IEEE80211_S_RUNif the authentication handshake fails.
- Associating to an access point (in station mode). This state is reached
IEEE80211_S_AUTHafter successfully authenticating or from
IEEE80211_S_RUNif a DisAssoc frame is received.
- Doing Channel Availability Check (CAC). This state is entered only when DFS is enabled and the channel selected for operation requires CAC.
- Operational. In this state a vap can transmit data frames, accept requests for stations associating, etc. Beware that data traffic is also gated by whether the associated “port” is authorized. When WPA/802.11i/802.1x is operational authorization may happen separately; e.g. in station mode wpa_supplicant(8) must complete the handshakes and plumb the necessary keys before a port is authorized. In this state a BSS is operational and associated state is valid and may be used; e.g. ic_bss and ic_bsschan are guaranteed to be usable.
- Channel Switch Announcement (CSA) is pending. This state is reached only
IEEE80211_S_RUNwhen either a CSA is received from an access point (in station mode) or the local station is preparing to change channel. In this state traffic may be muted depending on the Mute setting in the CSA.
- Asleep to save power (in station mode). This state is reached only from
IEEE80211_S_RUNwhen power save operation is enabled and the local station is deemed sufficiently idle to enter low power mode.
Note that states are ordered (as shown above); e.g. a vap must be
IEEE80211_S_RUN or “greater”
before it can transmit frames. Certain
are valid only in certain states; e.g. the iv_bsschan
that specifies the channel for the operating BSS should never be used except
IEEE80211_S_RUN or greater.
State machine changes are typically handled internal to the
net80211 layer in response to
ioctl(2) requests, received frames, or external events
such as a beacon miss. The
function is used to initiate a state machine change on a vap. The new state
and an optional argument are supplied. The request is initially processed to
handle coordination of multiple vaps. For example, only one vap at a time
can be scanning, if multiple vaps request a change to
IEEE80211_S_SCAN the first will be permitted to run
and the others will be
until the scan operation completes at which time the selected channel will
be adopted. Similarly
net80211 handles coordination
of combinations of vaps such as an AP and station vap where the station may
need to roam to follow the AP it is associated to (dragging along the AP vap
to the new channel). Another important coordination is the handling of
IEEE80211_S_CSA. No more than one vap can ever be
actively changing state at a time. In fact
single-threads the state machine logic in a dedicated
taskqueue(9) thread that is also used to synchronize work
such as scanning and beacon miss handling.
After multi-vap scheduling/coordination is done the per-vap
iv_newstate method is called to carry out the state
change work. Drivers use this entry to setup private state and then dispatch
the call to the
net80211 layer using the previously
defined method pointer (in OOP-parlance they call the “super
net80211 handles two state changes
specially. On transition to
IFF_DRV_OACTIVE bit on the vap's transmit queue is
cleared so traffic can flow. On transition to
IEEE80211_S_INIT any state in the scan cache
associated with the vap is flushed and any frames pending on the transmit
queue are flushed.
Drivers are expected to override the
iv_newstate method to interpose their own code and
handle setup work required by state changes. Otherwise drivers must call
in response to being marked up through an
SIOCSIFFLAGS ioctl request and they should use
to implement suspend/resume support.
There is also an
call to force all vaps to an
but this should not be needed by a driver; control is usually handled by
net80211 or, in the case of card eject or vap
destroy, work will be initiated outside the driver.
ioctl(2), wpa_supplicant(8), ieee80211(9), ifnet(9), taskqueue(9)
The state machine concept was part of the original
ieee80211 code base that first appeared in
|August 4, 2009||Debian|