STRUCT IEEE80211_BSS_CONF(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ¦‹ struct ieee80211_bss_conf β€” the Kernel API Manual tea 🫢

okay so bestie, welcome to struct ieee80211_bss_conf, which is literally the struct that holds the BSS's changing parameters. yes, changing. it's giving "the vibes of a BSS are always in flux and this is where we keep track" energy. πŸ’…


✨ SYNOPSIS ✨

no cap, here's the whole thing, character for character, because we do not play about struct definitions:

struct ieee80211_bss_conf {
    struct ieee80211_vif *vif;
    struct cfg80211_bss *bss;
    const u8 *bssid;
    unsigned int link_id;
    u8 addr[ETH_ALEN];
    u8 htc_trig_based_pkt_ext;
    bool uora_exists;
    u8 uora_ocw_range;
    u16 frame_time_rts_th;
    bool he_support;
    bool twt_requester;
    bool twt_responder;
    bool twt_protected;
    bool twt_broadcast;
    bool use_cts_prot;
    bool use_short_preamble;
    bool use_short_slot;
    bool enable_beacon;
    u8 dtim_period;
    u16 beacon_int;
    u16 assoc_capability;
    u64 sync_tsf;
    u32 sync_device_ts;
    u8 sync_dtim_count;
    u32 basic_rates;
    struct ieee80211_rate *beacon_rate;
    int mcast_rate[NUM_NL80211_BANDS];
    u16 ht_operation_mode;
    s32 cqm_rssi_thold;
    u32 cqm_rssi_hyst;
    s32 cqm_rssi_low;
    s32 cqm_rssi_high;
    struct ieee80211_chan_req chanreq;
    struct ieee80211_mu_group_data mu_group;
    bool qos;
    bool hidden_ssid;
    int txpower;
    enum nl80211_tx_power_setting txpower_type;
    struct ieee80211_p2p_noa_attr p2p_noa_attr;
    bool allow_p2p_go_ps;
    u16 max_idle_period;
    bool protected_keep_alive;
    bool ftm_responder;
    struct ieee80211_ftm_responder_params *ftmr_params;
    bool nontransmitted;
    struct ieee80211_bss_conf *tx_bss_conf;
    u8 transmitter_bssid[ETH_ALEN];
    u8 bssid_index;
    u8 bssid_indicator;
    bool ema_ap;
    u8 profile_periodicity;
    struct {
      u32 params;
      u16 nss_set;
    } he_oper;
    struct ieee80211_he_obss_pd he_obss_pd;
    struct cfg80211_he_bss_color he_bss_color;
    struct ieee80211_fils_discovery fils_discovery;
    u32 unsol_bcast_probe_resp_interval;
    struct cfg80211_bitrate_mask beacon_tx_rate;
    enum ieee80211_ap_reg_power power_type;
    struct ieee80211_parsed_tpe tpe;
    u8 pwr_reduction;
    bool eht_support;
    bool epcs_support;
    bool uhr_support;
    bool csa_active;
    bool mu_mimo_owner;
    struct ieee80211_chanctx_conf *chanctx_conf;
    bool color_change_active;
    u8 color_change_color;
    bool ht_ldpc;
    bool vht_ldpc;
    bool he_ldpc;
    bool vht_su_beamformer;
    bool vht_su_beamformee;
    bool vht_mu_beamformer;
    bool vht_mu_beamformee;
    bool he_su_beamformer;
    bool he_su_beamformee;
    bool he_mu_beamformer;
    bool he_full_ul_mumimo;
    bool eht_su_beamformer;
    bool eht_su_beamformee;
    bool eht_mu_beamformer;
    bool eht_80mhz_full_bw_ul_mumimo;
    bool eht_disable_mcs15;
    u8 bss_param_ch_cnt;
    u8 bss_param_ch_cnt_link_id;
    u8 enh_bss_param_ch_cnt;
    u8 enh_bss_param_ch_cnt_link_id;
    u8 s1g_long_beacon_period;
    struct ieee80211_bss_npca_params npca;
};

✨ iconic. no notes. moving on to the members, because there are so many and every single one is getting its moment. πŸ’–


🌸 Members 🌸

  • vif β€” reference to owning VIF. the main character VIF, fr fr.
  • bss β€” the cfg80211 bss descriptor. Valid only for a station, and only when associated. Note: This contains information which is not necessarily authenticated. For example, information coming from probe responses. πŸ‘€ so like, don't blindly trust it, bestie.
  • bssid β€” The BSSID for this BSS.
  • link_id β€” link ID, or 0 for non-MLO.
  • addr β€” (link) address used locally.
  • htc_trig_based_pkt_ext β€” default PE in 4us units, if BSS supports HE.
  • uora_exists β€” is the UORA element advertised by AP.
  • uora_ocw_range β€” UORA element's OCW Range field.
  • frame_time_rts_th β€” HE duration RTS threshold, in units of 32us.
  • he_support β€” does this BSS support HE.
  • twt_requester β€” does this BSS support TWT requester (relevant for managed mode only, set if the AP advertises TWT responder role).
  • twt_responder β€” does this BSS support TWT requester (relevant for managed mode only, set if the AP advertises TWT responder role). yes, the description says requester again β€” we are keeping it exactly as the original says it. no editing the lore. πŸ’…
  • twt_protected β€” does this BSS support protected TWT frames.
  • twt_broadcast β€” does this BSS support broadcast TWT.
  • use_cts_prot β€” use CTS protection.
  • use_short_preamble β€” use 802.11b short preamble.
  • use_short_slot β€” use short slot time (only relevant for ERP).
  • enable_beacon β€” whether beaconing should be enabled or not.
  • dtim_period β€” num of beacons before the next DTIM, for beaconing, valid in station mode only if after the driver was notified with the BSS_CHANGED_BEACON_INFO flag, will be non-zero then.
  • beacon_int β€” beacon interval.
  • assoc_capability β€” capabilities taken from assoc resp.
  • sync_tsf β€” last beacon's/probe response's TSF timestamp (could be old as it may have been received during scanning long ago). If the HW flag IEEE80211_HW_TIMING_BEACON_ONLY is set, then this can only come from a beacon, but might not become valid until after association when a beacon is received (which is notified with the BSS_CHANGED_DTIM flag.). See also sync_dtim_count important notice.
  • sync_device_ts β€” the device timestamp corresponding to the sync_tsf, the driver/device can use this to calculate synchronisation (see sync_tsf). See also sync_dtim_count important notice.
  • sync_dtim_count β€” Only valid when IEEE80211_HW_TIMING_BEACON_ONLY is requested, see sync_tsf/sync_device_ts. IMPORTANT: These three sync_* parameters would possibly be out of sync by the time the driver will use them. The synchronized view is currently guaranteed only in certain callbacks. Note also that this is not used with MLD associations, mac80211 doesn't know how to track beacons for all of the links for this. 😭 so yeah, timing is a whole situation.
  • basic_rates β€” bitmap of basic rates, each bit stands for an index into the rate table configured by the driver in the current band.
  • beacon_rate β€” associated AP's beacon TX rate.
  • mcast_rate β€” per-band multicast rate index + 1 (0: disabled).
  • ht_operation_mode β€” HT operation mode like in struct ieee80211_ht_operation. This field is only valid when the channel is a wide HT/VHT channel. Note that with TDLS this can be the case (channel is HT, protection must be used from this field) even when the BSS association isn't using HT.
  • cqm_rssi_thold β€” Connection quality monitor RSSI threshold, a zero value implies disabled. As with the cfg80211 callback, a change here should cause an event to be sent indicating where the current value is in relation to the newly configured threshold.
  • cqm_rssi_hyst β€” Connection quality monitor RSSI hysteresis.
  • cqm_rssi_low β€” Connection quality monitor RSSI lower threshold, a zero value implies disabled. This is an alternative mechanism to the single threshold event and can't be enabled simultaneously with it.
  • cqm_rssi_high β€” Connection quality monitor RSSI upper threshold.
  • chanreq β€” Channel request for this BSS β€” the hardware might be configured a higher bandwidth than this BSS uses, for example. πŸ’… hardware doing the most, as usual.
  • mu_group β€” VHT MU-MIMO group membership data.
  • qos β€” This is a QoS-enabled BSS.
  • hidden_ssid β€” The SSID of the current vif is hidden. Only valid in AP-mode.
  • txpower β€” TX power in dBm. INT_MIN means not configured.
  • txpower_type β€” TX power adjustment used to control per packet Transmit Power Control (TPC) in lower driver for the current vif. In particular TPC is enabled if value passed in txpower_type is NL80211_TX_POWER_LIMITED (allow using less than specified from userspace), whereas TPC is disabled if txpower_type is set to NL80211_TX_POWER_FIXED (use value configured from userspace).
  • p2p_noa_attr β€” P2P NoA attribute for P2P powersave.
  • allow_p2p_go_ps β€” indication for AP or P2P GO interface, whether it's allowed to use P2P PS mechanism or not. AP/P2P GO is not allowed to use P2P PS if it has associated clients without P2P PS support.
  • max_idle_period β€” the time period during which the station can refrain from transmitting frames to its associated AP without being disassociated. In units of 1000 TUs. Zero value indicates that the AP did not include a (valid) BSS Max Idle Period Element.
  • protected_keep_alive β€” if set, indicates that the station should send an RSN protected frame to the AP to reset the idle timer at the AP for the station.
  • ftm_responder β€” whether to enable or disable fine timing measurement FTM responder functionality.
  • ftmr_params β€” configurable lci/civic parameter when enabling FTM responder.
  • nontransmitted β€” this BSS is a nontransmitted BSS profile.
  • tx_bss_conf β€” Pointer to the BSS configuration of transmitting interface if MBSSID is enabled. This pointer is RCU-protected due to CSA finish and BSS color change flows accessing it. πŸ”₯ RCU-protected, bestie, respect the RCU.
  • transmitter_bssid β€” the address of transmitter AP.
  • bssid_index β€” index inside the multiple BSSID set.
  • bssid_indicator β€” 2^bssid_indicator is the maximum number of APs in set.
  • ema_ap β€” AP supports enhancements of discovery and advertisement of nontransmitted BSSIDs.
  • profile_periodicity β€” the least number of beacon frames need to be received in order to discover all the nontransmitted BSSIDs in the set.
  • he_oper β€” HE operation information of the BSS (AP/Mesh) or of the AP we are connected to (STA).
  • he_obss_pd β€” OBSS Packet Detection parameters.
  • he_bss_color β€” BSS coloring settings, if BSS supports HE.
  • fils_discovery β€” FILS discovery configuration.
  • unsol_bcast_probe_resp_interval β€” Unsolicited broadcast probe response interval.
  • beacon_tx_rate β€” The configured beacon transmit rate that needs to be passed to driver when rate control is offloaded to firmware.
  • power_type β€” power type of BSS for 6 GHz.
  • tpe β€” the transmit power envelope info πŸ’« like, the actual power vibes this BSS is serving.
  • pwr_reduction β€” the power constraint of the BSS. lowkey a budget cap on wattage πŸ“
  • eht_support β€” does this BSS support EHT? yes or no bestie ✨
  • epcs_support β€” does this BSS support EPCS? πŸ‘‘
  • uhr_support β€” does this BSS support UHR? πŸ’…
  • csa_active β€” marks whether a channel switch is going on. like a little "brb moving" sign πŸ¦‹
  • mu_mimo_owner β€” indicates the interface owns MU-MIMO capability πŸ™ˆ it's giving main character holding the keys
  • chanctx_conf β€” the channel context this interface is assigned to, or NULL when it's not assigned. and here's the tea: this pointer is RCU-protected, because the TX path needs to access it. so even though the netdev carrier will always be off when it's NULL, there can still be races, and packets could be processed after it switches back to NULL. so like, don't get cocky about it 😭
ngl, that one's a real one β€” the pointer going NULL doesn't magically stop everything, so respect the RCU rules fr fr.
  • color_change_active β€” marks whether a color change is ongoing 🎨✨
  • color_change_color β€” the bss color that'll be used after the change. so like, the glow-up target πŸ’œ
  • ht_ldpc β€” in AP mode, indicates the interface has HT LDPC capability 🫢
  • vht_ldpc β€” in AP mode, indicates the interface has VHT LDPC capability πŸ’–
  • he_ldpc β€” in AP mode, indicates the interface has HE LDPC capability 🌸
  • vht_su_beamformer β€” in AP mode, does this BSS support operating as an VHT SU beamformer? πŸ“‘
  • vht_su_beamformee β€” in AP mode, does this BSS support operating as an VHT SU beamformee? πŸ“‘
  • vht_mu_beamformer β€” in AP mode, does this BSS support operating as an VHT MU beamformer? πŸ“‘
  • vht_mu_beamformee β€” in AP mode, does this BSS support operating as an VHT MU beamformee? πŸ“‘
  • he_su_beamformer β€” in AP mode, does this BSS support operating as an HE SU beamformer? πŸ”₯
  • he_su_beamformee β€” in AP mode, does this BSS support operating as an HE SU beamformee? πŸ”₯
  • he_mu_beamformer β€” in AP mode, does this BSS support operating as an HE MU beamformer? πŸ”₯
  • he_full_ul_mumimo β€” does this BSS support reception (on an AP) or transmission (on a non-AP STA) of an HE TB PPDU on an RU that spans the entire PPDU bandwidth? literally the whole bandwidth, no crumbs 😀
  • eht_su_beamformer β€” in AP mode, does this BSS enable operation as an EHT SU beamformer? ⭐
  • eht_su_beamformee β€” in AP mode, does this BSS enable operation as an EHT SU beamformee? ⭐
  • eht_mu_beamformer β€” in AP mode, does this BSS enable operation as an EHT MU beamformer? ⭐
  • eht_80mhz_full_bw_ul_mumimo β€” in AP mode, does this BSS support reception of an EHT TB PPDU on an RU that spans the entire PPDU bandwidth? bestie that's the full 80mhz of it, iconic πŸ†
  • eht_disable_mcs15 β€” disables EHT-MCS 15 reception capability. like, turning it off on purpose 🚫
  • bss_param_ch_cnt β€” in BSS mode, the BSS params change count. this is the latest known value, and it can come from this link's beacon or from a beacon sent by another link. sneaky but valid πŸ‘€
  • bss_param_ch_cnt_link_id β€” in BSS mode, the link_id of the beacon that updated bss_param_ch_cnt. okay example time because this one's a whole saga: if link 1 doesn't hear its beacons, and link 2 sends a beacon with an RNR element that updated link 1's BSS params change count, then link 1's bss_param_ch_cnt_link_id will be 2. that means link 1 knows that link 2 was the link that updated its bss_param_ch_cnt value. and if link 1 hears its own beacon again, bss_param_ch_cnt_link_id gets updated to 1 β€” even if bss_param_ch_cnt didn't change. this lets the link know it heard the latest value from its own beacon, as opposed to hearing its value from another link's beacon. chef's kiss tracking 🧚
  • enh_bss_param_ch_cnt β€” in BSS mode, the enhanced BSS parameters change counter. see bss_param_ch_cnt β€” it works the exact same way πŸ’«
  • enh_bss_param_ch_cnt_link_id β€” in BSS mode, the link_id for the enhanced BSS parameter change counter. see bss_param_ch_cnt_link_id πŸŽ€
  • s1g_long_beacon_period β€” number of beacon intervals between each long beacon transmission. so like, the gap between the long ones πŸ¦‹
  • npca β€” NPCA parameters 🌈

πŸ›°οΈ Description πŸ›°οΈ

okay so the whole vibe of this structure is: it keeps information about a BSS β€” and an association to that BSS β€” that can change during the lifetime of the BSS. like, it's the living document of a BSS, not the frozen-at-birth stuff. if it evolves mid-run, it lives here πŸ’–

πŸ‘€ SEE ALSO πŸ‘€

okay bestie, deep breath. this is the part where the page stops explaining and just lists. and lists. and lists. it is giving phone-book energy, i'm not gonna lie to you. but every single one of these is a real section (9) page and every single one of them is here, so scroll with me and don't skip, i'm watching 🫢

first up, the mac80211 starter pack:

  • ./include/net/mac80211.h β€” the kernel file this whole page lives in, paired with Introduction(9)
  • Calling mac80211 from interrupts(9)
  • Warning(9)
  • Frame format(9)
  • mac80211 workqueue(9)
  • mac80211 software tx queueing(9)
  • HW timestamping(9)

then the queue + channel-context girlies πŸ’…

  • enum ieee80211_max_queues(9)
  • enum ieee80211_ac_numbers(9)
  • struct ieee80211_tx_queue_params(9)
  • enum ieee80211_chanctx_change(9)
  • struct ieee80211_chan_req(9)
  • struct ieee80211_chanctx_conf(9)
  • enum ieee80211_chanctx_switch_mode(9)
  • struct ieee80211_vif_chanctx_switch(9)

events, measurement, and a whole nan era 🌸

  • enum ieee80211_bss_change(9)
  • enum ieee80211_event_type(9)
  • enum ieee80211_rssi_event_data(9)
  • struct ieee80211_rssi_event(9)
  • enum ieee80211_mlme_event_data(9)
  • enum ieee80211_mlme_event_status(9)
  • struct ieee80211_mlme_event(9)
  • struct ieee80211_ba_event(9)
  • struct ieee80211_event(9)
  • struct ieee80211_mu_group_data(9)
  • struct ieee80211_ftm_responder_params(9)
  • struct ieee80211_fils_discovery(9)
  • struct ieee80211_parsed_tpe(9)
  • struct ieee80211_bss_npca_params(9)
  • struct ieee80211_nan_channel(9)
  • struct ieee80211_nan_peer_map(9)
  • struct ieee80211_nan_peer_sched(9)

tx/rx era β€” the flags, the rates, the statuses ✨

  • enum mac80211_tx_info_flags(9)
  • enum mac80211_tx_control_flags(9)
  • enum mac80211_tx_status_flags(9)
  • enum mac80211_rate_control_flags(9)
  • struct ieee80211_tx_rate(9)
  • struct ieee80211_tx_info(9)
  • struct ieee80211_tx_status(9)
  • struct ieee80211_scan_ies(9)
  • ieee80211_tx_info_clear_status(9)
  • enum mac80211_rx_flags(9)
  • enum mac80211_rx_encoding_flags(9)
  • struct ieee80211_rx_status(9)

conf, vif config, and ttlm things (say that three times fast, i dare you):

  • enum ieee80211_conf_flags(9)
  • enum ieee80211_conf_changed(9)
  • enum ieee80211_smps_mode(9)
  • struct ieee80211_conf(9)
  • struct ieee80211_channel_switch(9)
  • enum ieee80211_vif_flags(9)
  • enum ieee80211_offload_flags(9)
  • struct ieee80211_eml_params(9)
  • struct ieee80211_nan_sched_cfg(9)
  • struct ieee80211_vif_cfg(9)
  • struct ieee80211_neg_ttlm(9)
  • enum ieee80211_neg_ttlm_res(9)

the vif + key crowd πŸ”‘

stations, hardware, and the little helpers that hold it all together πŸ’–

and here are the ones with the cute prose titles instead of an underscore situation, no cap:

  • Hardware crypto acceleration(9)
  • Powersave support(9)
  • Beacon filter support(9)
  • Spatial multiplexing power save(9)
  • Frame filtering(9)
  • AP support for powersaving clients(9)
  • HW queue control(9)

back to the underscored icon lineup:

  • enum ieee80211_filter_flags(9)
  • enum ieee80211_ampdu_mlme_action(9)
  • struct ieee80211_ampdu_params(9)
  • enum ieee80211_frame_release_type(9)
  • enum ieee80211_rate_control_changed(9)
  • enum ieee80211_roc_type(9)
  • enum ieee80211_reconfig_type(9)
  • struct ieee80211_prep_tx_info(9)
  • struct ieee80211_ops(9)

allocating, registering, and all the LED cuteness (the LEDs are genuinely iconic, i don't make the rules):

rx, powersave, and tx status β€” the whole data path bestie 🌈

beacon era πŸŽ€ (yes there are this many, yes they all matter)

all the frame getters and their duration besties:

tkip + key sequence things, very "i know what an IV is" of them πŸ’…

queue control + scanning:

iteration girlies (the for_each_* ones are lowkey the moment):

aggregation, stations, and airtime πŸ”₯

iteration round two + all the "something went wrong" notifications 😭

rate control, capability checks, and the noa/tdls crew πŸ¦‹

and the final stretch, we made it, i'm so proud of you 🏁


and that's the whole list, bestie. every single one, not a crumb left behind. okay bye, ily, go read a struct πŸ’œ

this page calls ./include/net home, it's dated October 2026, and it is, forever and always, struct ieee80211_bss_conf(9) β€” periodt πŸŽ€

πŸ“¦ where this page comes from