svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ieee80211_scan_next(9)
The software layer provides an extensible framework for scanning.
Scanning is the procedure by which a station locates a BSS to
join (in infrastructure and IBSS mode), or a channel to use (when
operating as an AP or an IBSS master). Scans are either or An
active scan causes one or more ProbeRequest frames to be sent on
visiting each channel. A passive request causes each channel in
the scan set to be visited but no frames to be transmitted; the
station only listens for traffic. Note that active scanning may
still need to listen for traffic before sending ProbeRequest
frames depending on regulatory constraints. A scan operation in‐
volves constructing a set of channels to inspect (the scan set),
visiting each channel and collecting information (e.g. what BSS
are present), and then analyzing the results to make decisions
such as which BSS to join. This process needs to be as fast as
possible so does things like intelligently construct scan sets
and dwell on a channel only as long as necessary. Scan results
are cached and the scan cache is used to avoid scanning when pos‐
sible and to enable roaming between access points when operating
in infrastructure mode. Scanning is handled by pluggable modules
that implement per-operating mode. The core scanning support
provides an infrastructure to support these modules and exports a
common API to the rest of the layer. Policy modules decide what
channels to visit, what state to record to make decisions, and
selects the final station/channel to return as the result of a
scan. Scanning is done synchronously when initially bringing a
vap to an operational state and optionally in the background to
maintain the scan cache for doing roaming and rogue AP monitor‐
ing. Scanning is not tied to the state machine that governs vaps
except for linkage to the state. Only one vap at a time may be
scanning; this scheduling policy is handled in and is transparent
to scanning code. Scanning is controlled by a set of parameters
that (potentially) constrains the channel set and any desired
SSID's and BSSID's. comes with a standard scanner module that
works with all available operating modes and supports and opera‐
tion. Scanning modules use a registration mechanism to hook into
the layer. Use to register a scan module for a particular oper‐
ating mode and or to clear entries (typically on module unload).
Only one scanner module can be registered at any time for an op‐
erating mode. Scanning operations are usually managed by the
layer. Drivers must provide and methods that are called at the
start of a scan and when the work is done; these should handle
work such as enabling receive of Beacon and ProbeResponse frames
and disable any BSSID matching. The method is used to change
channels while scanning. will generate ProbeRequest frames and
transmit them using the method. Frames received while scanning
are dispatched to using the normal receive path. Devices that
off-load scan work to firmware most easily mesh with by operating
on a channel-at-a-time basis as this defers control to scan ma‐
chine scheduler. But multi-channel scanning is supported if the
driver manually dispatches results using routine to enter results
into the scan cache. Scan requests occur by way of the ioctl or
through a change in a vap's state machine that requires scanning.
In both cases the scan cache can be checked first and, if it is
deemed suitably then it's contents are used without leaving the
current channel. To start a scan without checking the cache can
be called; otherwise can be used to first check the scan cache,
kicking off a scan if the cache contents are out of date. There
is also which is a shorthand for using previously set scan para‐
meters for checking the scan cache and then scanning. Background
scanning is done using in a co-routine fashion. The first call
to this routine will start a background scan that runs for a lim‐
ited period of time before returning to the BSS channel. Subse‐
quent calls advance through the scan set until all channels are
visited. Typically these later calls are timed to allow receipt
of frames buffered by an access point for the station. A scan
operation can be canceled using if it was initiated by the speci‐
fied vap, or to force termination regardless which vap started
it. These requests are mostly used by in the transmit path to
cancel background scans when frames are to be sent. Drivers
should not need to use these calls (or most of the calls de‐
scribed on this page). The and routines do explicit iteration
through the scan set and should not normally be used by drivers.
handles the work of transmitting ProbeRequest frames when visit‐
ing a channel during an active scan. When the channel attributes
are marked with this function will arrange that before any frame
is transmitted 802.11 traffic is first received (in order to com‐
ply with regulatory constraints). Min/max dwell time parameters
are used to constrain time spent visiting a channel. The maximum
dwell time constrains the time spent listening for traffic. The
minimum dwell time is used to reduce this time--when it is
reached and one or more frames have been received then an immedi‐
ate channel change will be done. Drivers can override this be‐
haviour through the method. The scan cache contents are managed
by the scan policy module and are opaque outside this module.
The scan framework defines API's for interacting. The validity
of the scan cache contents are controlled by which is exported to
user space through the request. The cache contents can be ex‐
plicitly flushed with or by setting the flag when starting a scan
operation. Scan cache entries are created with the routine; usu‐
ally on receipt of Beacon or ProbeResponse frames. Existing en‐
tries are typically updated based on the latest information
though some information such as RSSI and noise floor readings may
be combined to present an average. The cache contents is aged
through calls. Typically these happen together with other sta‐
tion table activity; every seconds (default 15). Individual
cache entries are marked usable with and faulty with with the
latter taking an argument to identify if there was no response to
Authentication/Association requests or if a negative response was
received (which might hasten cache eviction or blacklist the en‐
try). The cache contents can be viewed using the call. Cache
entries are exported in a public format that is exported to user
applications through the request.