IEEE80211_REGDOMAIN(9)

💖 ieee80211_regdomain — 802.11 regulatory support 💖

okay bestie, welcome to ieee80211_regdomain(9), aka the kernel developer's manual page for the net80211 regulatory support situation. this is section 9, it's giving ✨kernel internals✨, and it's literally all about who's allowed to use which radio channels and where. let's get into it 🦋

---

✨ SYNOPSIS ✨

#include <net80211/ieee80211_var.h>
#include <net80211/ieee80211_regdomain.h>

int
ieee80211_init_channels(struct ieee80211com *,
    const struct ieee80211_regdomain *, const uint8_t bands[]);

void
ieee80211_sort_channels(struct ieee80211_channel *, int nchans);

struct ieee80211_appie *
ieee80211_alloc_countryie(struct ieee80211com *);

---

🌸 DESCRIPTION 🌸

so the net80211 software layer is out here providing a whole support framework for drivers, and that framework includes comprehensive regulatory support. no cap. net80211 gives you the mechanisms that enforce regulatory policy by privileged user applications. the way that it does this... 💅

drivers define what a device can do, and they can intercept and control regulatory changes that get requested through net80211. the initial regulatory state — including the channel list — must be filled in by the driver before calling ieee80211_ifattach(). important!! 🫶

that channel list should reflect the set of channels the device is actually calibrated to be used on. you can also request it later through the ic_getradiocaps method in the ieee80211com structure. and like, ieee80211_init_channels() is there as a rudimentary fallback for drivers that don't (or literally cannot) fill in a proper channel list. iconic of it to have a backup plan tbh.

default regulatory state gets supplied too, including:

• the regulatory SKU
• the ISO country code
• the location (e.g. indoor, outdoor)
• a set of frequency bands the device is capable of operating on

and net80211 populates the channel table in ic_channels with a default set of channels and capabilities. 🎀

⚠️ bestie, be careful with this one. any mismatch between the channel list you create and the device's actual capabilities can result in runtime errors — like, a request to operate on a channel the device does not support. not cute. 💀

the SKU and country info get used for generating 802.11h protocol elements and related operation, like for 802.11d. if a driver mis-sets them it's not fatal, just potentially confusing. so like, mild chaos, not actual doom. 🙈

---

devices that don't have a fixed/default regulatory state can set the regulatory SKU to SKU_DEBUG and the country code to CTRY_DEFAULT, and then just leave proper setup to user applications. if the default settings are known, you can install them and/or dispatch an event to user space using ieee80211_notify_country() so that devd(8) will do the appropriate setup work at system boot (or at device insertion). team work makes the dream work 🌈

---

the channel table is sorted to optimize lookups, using the ieee80211_sort_channels() routine. this should be done whenever the channel table contents are modified. every single time, no exceptions, periodt. ✨

---

the ieee80211_alloc_countryie() function allocates an information element as specified by 802.11h. because this is expensive to generate, it gets cached in ic_countryie and is only generated when regulatory state changes. 💰

🚨 drivers that call ieee80211_alloc_countryie() directly should not help with this caching. doing so may confuse the net80211 layer. do not do it. i'm so serious. 😭

---

👑 DRIVER REGULATORY CONTROL 👑

drivers can control regulatory change requests by overriding the ic_setregdomain method, which checks change requests. 🦋

while drivers can reject any request that doesn't meet its requirements, it's recommended that you be lenient in what you accept and, whenever possible, instead of rejecting a request — alter it to be correct. slay, flexible king 💅

for example: if the transmit power cap for a channel is too high, the driver can either reject the request or (better) reduce the cap so it's compliant. main character choice fr fr.

requests that include unacceptable channels should cause the request to be rejected, because otherwise a mismatch may be created between the application state and the state managed by net80211. messy. not the vibe. 💀

the exact rules by which to operate are still being codified, so like... we're all figuring it out together bestie 🫶

---

🔥 SEE ALSO 🔥

• regdomain(5)
• ifconfig(8)
• ieee80211(9)

---

okay that's the whole page, you ate it up 💖 this was the Debian version of IEEE80211_REGDOMAIN(9) from way back on August 4, 2009 — old but iconic, the vintage of it all 🎀 stan a classic manual page, mwah, bye bestie! 💅✨🦋