IEEE80211_INPUT(9)

💖 IEEE80211_INPUT(9) — the ieee80211_input glow-up 💖

okay so bestie, we're deep in the net80211 manual pages (that's the ieee80211 corner of the Kernel Developer's Manual, iykyk) and this one is literally about how received 802.11 frames get fed into the software stack. strap in, it's giving low-level but make it cute 🎀

---

✨ 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);

two functions, same shape, one node vs. the whole ieee80211com — slay 💅

---

🌸 DESCRIPTION 🌸

so the net80211 layer (the thing that helps 802.11 device drivers do their thing) requires that receive processing be single-threaded. no cap. typically you pull this off with a dedicated driver taskqueue(9) thread — that's the whole vibe.

ieee80211_input() and ieee80211_input_all() process received 802.11 frames, and they're designed to be used in that context. which means: no driver locks may be held. literally none. don't do it 🫶

---

🦋 what the mbuf has to look like going in

the frame you pass up in the mbuf must have the 802.11 protocol header right at the front — and all the device-specific info and/or PLCP has to be removed first. also strip any CRC off the end of the frame, periodt.

• the 802.11 protocol header should be 32-bit aligned for optimal performance — but honestly receive processing doesn't require it, so it's a should, not a must 💫
• if the frame holds a payload and that payload isn't aligned to a 32-bit boundary, the payload gets re-aligned so it's all set for protocols like ip(4) to chew on. she fixes it for you, iconic.

---

🧚 padding & the IEEE80211_C_DATAPAD capability

if a device (think ath(4)) inserts padding after the 802.11 header to line the payload up to a 32-bit boundary, then you must set the IEEE80211_C_DATAPAD capability. no exceptions bestie.

otherwise (i.e. if you don't set it), header and payload are assumed to be contiguous in the mbuf chain. that's the deal.

---

🔥 the A-MPDU reorder buffer situation

if a received frame has to pass through the A-MPDU receive reorder buffer, the mbuf must be marked with the M_AMPDU flag. 🚩

heads up fr fr: 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. like, all of them. okay? 😭

and it's sufficient to check for IEEE80211_NODE_HT in the ni_flags of the station's node table entry. any frames that don't need reorder processing get dispatched with only minimal overhead, so you're not wasting cycles. efficient queen 👑

---

⭐ rssi & noise (the numbers)

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

what are they even for? glad you asked 💖 the net80211 layer uses RSSI and noise to make scanning and roaming decisions in station mode, and to do auto channel selection for hostap and similar modes. main character energy.

otherwise (when it's not doing any of that), the values are 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. cute little summary for the apps 🌈

---

👑 SEE ALSO 👑

• ieee80211(9)

---

and that's the page!! go forth and process those frames correctly, bestie 🦋💜

sign-off vibes: this one's from the Debian crew, dated August 4, 2009 — yeah, she's a legacy icon but she still ate 💅✨