svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ieee80211_node(9)
The layer that supports 802.11 device drivers maintains a data‐
base of peer stations called the in the entry of the structure.
Station mode vaps create an entry for the access point the sta‐
tion is associated to. AP mode vaps create entries for associ‐
ated stations. Adhoc and mesh mode vaps create entries for
neighbor stations. WDS mode vaps create an entry for the peer
station. Stations for all vaps reside in the same table; each
node entry has a field that identifies the vap that created it.
In some instances an entry is used by multiple vaps (e.g. for dy‐
namic WDS a station associated to an ap vap may also be the peer
of a WDS vap). Node table entries are reference counted. That
is, there is a count of all long term references that determines
when an entry may be reclaimed. References are held by every in-
flight frame sent to a station to ensure the entry is not re‐
claimed while the frame is queued or otherwise held by a driver.
Routines that lookup a table entry return a (i.e. a pointer to a
table entry with the reference count incremented). The and calls
explicitly increment/decrement the reference count of a node, but
are rarely used. Instead most callers use to release a reference
and, if the count goes to zero, reclaim the table entry. The
station table and its entries are exposed to drivers in several
ways. Each frame transmitted to a station includes a reference
to the associated node in the field. This reference must be re‐
claimed by the driver when transmit processing is done. For each
frame received the driver must lookup the table entry to use in
dispatching the frame This lookup implicitly obtains a reference
to the table entry and the driver must reclaim the reference when
frame processing is completed. Otherwise drivers frequently in‐
spect the contents of the node when handling state machine
changes as important information is maintained in the data struc‐
ture. The node table is opaque to drivers. Entries may be
looked up using one of the pre-defined API's or the call may be
used to iterate through all entries to do per-node processing or
implement some non-standard search mechanism. Note that is sin‐
gle-threaded per-device and the effort processing involved is
fairly substantial so it should be used carefully. Two routines
are provided to print the contents of nodes to the console for
debugging: displays the contents of a single node while displays
the contents of the specified node table. Nodes may also be dis‐
played using with the directive and the station node table can be
displayed with Node data structures may be extended by the driver
to include driver-private state. This is done by overriding the
method used to allocate a node table entry. The driver method
must allocate a structure that is an extension of the structure.
For example the driver defines a private node structure as:
struct iwi_node {
struct ieee80211_node in_node; int
in_station; }; and then provides a private allocation routine
that does this: static struct ieee80211_node * iwi_node_al‐
loc(struct ieee80211vap *vap,
const uint8_t mac[IEEE80211_ADDR_LEN]) {
struct iwi_node *in;
in = malloc(sizeof(struct iwi_node), M_80211_NODE,
M_NOWAIT | M_ZERO);
if (in == NULL)
return NULL;
in->in_station = -1;
return &in->in_node; } Note that when reclaiming a node
allocated by the driver the must be called to ensure state is re‐
claimed; for example: static void iwi_node_free(struct
ieee80211_node *ni) {
struct ieee80211com *ic = ni->ni_ic;
struct iwi_softc *sc = ic->ic_ifp->if_softc;
struct iwi_node *in = (struct iwi_node *)ni;
if (in->in_station != -1)
free_unr(sc->sc_unr, in->in_station);
sc->sc_node_free(ni); /* invoke net80211 free handler
*/ } Beware that care must be taken to avoid holding references
that might cause nodes from being reclaimed. will reclaim a node
when the last reference is reclaimed in its data structures.
However if a driver holds additional references then will not
recognize this and table entries will not be reclaimed. Such
references should not be needed if the driver overrides the
and/or methods. Node table lookups are typically done using a
hash of the stations' mac address. When receiving frames this is
sufficient to find the node table entry for the transmitter. But
some devices also identify the sending station in the device
state received with each frame and this data can be used to opti‐
mize lookups on receive using a companion table called the This
table records a separate node table reference that can be fetched
without any locking using the table index. This logic is handled
with the call: if a keytab entry is found using the specified in‐
dex then it is returned directly; otherwise a normal lookup is
done and the keytab entry is written using the specified index.
If the specified index is then a normal lookup is done without a
table update.