IEEE80211_INPUT(9)

IEEE80211_INPUT 💖 (section 9, Kernel Developer's Manual, bestie)

okay so welcome to the ieee80211_input page, aka the software 802.11 stack input functions ✨ this is a section 9 joint so it's for the kernel girlies writing drivers, not for the casual user typing commands 💅

✨ NAME ✨

ieee80211_input — software 802.11 stack input functions 🦋

✨ SYNOPSIS ✨

#include <net80211/ieee80211_var.h>

void
ieee80211_input(struct ieee80211_node *, struct mbuf *, int rssi,
    int noise);

void
ieee80211_input_all(struct ieee80211com *, struct mbuf *, int rssi,
    int noise);

✨ DESCRIPTION ✨

so the net80211 layer that carries 802.11 device drivers requires that receive processing be single-threaded. no cap. typically this gets done with a dedicated driver taskqueue(9) thread, and that's the whole vibe. ieee80211_input() and ieee80211_input_all() are the functions that process received 802.11 frames, and they're literally designed to be used in that context — meaning: no driver locks may be held. none. zero. put them down 🫶

The frame you pass up in the mbuf must have the 802.11 protocol header sitting right at the front. all the device-specific information and/or PLCP has to be removed first, and any CRC has to be stripped off the end of the frame. the 802.11 protocol header should be 32-bit aligned for optimal performance, but receive processing does not require it — it's giving "nice to have, not a rule" 💅 and if the frame holds a payload and that payload isn't aligned to a 32-bit boundary, the payload will get re-aligned so it's suitable for processing by protocols such as ip(4). so thoughtful, honestly 😭

If a device (like ath(4), you know the one) inserts padding after the 802.11 header to align the payload to a 32-bit boundary, then the IEEE80211_C_DATAPAD capability must be set. otherwise header and payload are assumed contiguous in the mbuf chain. no padding detective work, just vibes.

If a received frame has to pass through the A-MPDU receive reorder buffer, then the mbuf must be marked with the M_AMPDU flag. ⭐ note that for the moment this is required of all frames received from a station and TID where a Block ACK stream is active — not just A-MPDU aggregates. it is sufficient to check for IEEE80211_NODE_HT in the ni_flags of the station's node table entry, and any frames that do not require reorder processing will be dispatched with only minimal overhead. slay, efficient queen 👑

Now the parameters, bestie:

• rssi is the Receive Signal Strength Indication of the frame, measured in 0.5dBm units relative to the noise floor.
• noise is the best approximation of the noise floor, in dBm units, at the time the frame was received.

RSSI and noise are used by the net80211 layer to make scanning and roaming decisions in station mode, and to do auto channel selection for hostap and similar modes. otherwise the values get made available to user applications — with the rssi presented as a filtered average over the last ten values and the noise floor as the last reported value. ten values, periodt 🎀

✨ SEE ALSO ✨

• ieee80211(9)

okay that's the whole page, you ate it, go write your driver 💖 and for the cute sign-off: this one came from Debian, dated August 4, 2009 🌸 like, a whole era ago, and it's still serving. bye bestie 🦋💜