IEEE80211_BEACON(9)

💫 ieee80211_beacon — 802.11 beacon support 💫

okay bestie, so this is a page from the Kernel Developer's Manual, and it's all about ieee80211_beacon — the 802.11 beacon support situation. buckle up, it's actually so good 🎀

---

🌸 SYNOPSIS 🌸

like, first you gotta pull in the header:

#include <net80211/ieee80211_var.h>

then the three iconic functions, exactly as they are:

struct mbuf *
ieee80211_beacon_alloc(struct ieee80211_node *,
    struct ieee80211_beacon_offsets *);

int
ieee80211_beacon_update(struct ieee80211_node *,
    struct ieee80211_beacon_offsets *, struct mbuf *, int mcast);

void
ieee80211_beacon_notify(struct ieee80211vap *, int what);

no cap, that's the whole API right there ✨

---

🦋 DESCRIPTION 🦋

the net80211 software layer is literally the supportive bestie of drivers — it gives you a whole support framework, including a template-based mechanism for dynamically updating beacon frames that get transmitted in hostap, adhoc, and mesh operating modes. main character framework energy fr fr 👑

so here's the tea: drivers should use ieee80211_beacon_alloc() to create an initial beacon frame. and the ieee80211_beacon_offsets structure? it holds info about what's inside the beacon, and that's what's used to optimize updates done with ieee80211_beacon_update(). iykyk 💅

---

important vibe check: update calls should only be done when something actually changes that affects the contents of the beacon frame. don't be out here updating for no reason 🙈

when a change happens, the iv_update_beacon method is invoked, and a driver-supplied routine must do the right thing. for devices that involve the host to transmit each beacon frame, that work may be as simple as marking a bit in the ieee80211_beacon_offsets structure, like this:

static void
ath_beacon_update(struct ieee80211vap *vap, int item)
{
        struct ieee80211_beacon_offsets *bo = &ATH_VAP(vap)->av_boff;
        setbit(bo->bo_flags, item);
}

and then the ieee80211_beacon_update() call gets done before the next beacon is to be sent. so efficient, we love her 🫶

devices that off-load beacon generation may instead choose to use this callback to push updates immediately to the device. exactly how that is accomplished is unspecified — so no guessing, bestie, the page doesn't say 😭. one possibility is to update the beacon frame contents and extract the appropriate information element, but other scenarios are possible. possibilities are endless, honestly 🌈

---

🔥 MULTI-VAP BEACON SCHEDULING 🔥

drivers that support multiple vaps that can each beacon need to consider how to schedule beacon frames. there are two possibilities at the moment:

1. burst all beacons at TBTT
2. stagger beacons over the beacon interval

so let's talk about it 💀

bursting beacon frames may result in aperiodic delivery, which can affect power save operation of associated stations. applying some jitter (e.g. by randomly ordering burst frames) may be sufficient to combat this, and typically this is not an issue unless stations are using aggressive power save techniques such as U-APSD (sometimes employed by VoIP phones). like, that's a very specific scenario but okay, noted 📞

staggering frames requires more interrupts and device support that may not be available. so it's giving high maintenance, but—

staggering beacon frames is usually superior to bursting frames, up to about eight vaps, at which point the overhead becomes significant and the channel becomes noticeably busy anyway. so basically, eight vaps is the vibe limit 👑✨

---

🎀 SEE ALSO 🎀

• ieee80211(9)

---

okay that's the whole thing, bestie, you're officially a beacon scheduling expert 💖

this page came from the Debian crew, dated August 4, 2009, and it's living inside the Kernel Developer's Manual — go off, legends 🫶✨