cfg80211_connect_bss(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– cfg80211_connect_bss(9) πŸ’–

okay so bestie, this page is from the Kernel API Manual, and it's all about cfg80211_connect_bss(9) β€” the function whose whole vibe is to notify cfg80211 of connection result. no cap. πŸ’…

✨ NAME ✨

cfg80211_connect_bss β€” notify cfg80211 of connection result.

πŸŽ€ SYNOPSIS πŸŽ€

       void cfg80211_connect_bss (struct net_device *dev , const u8 *bssid ,
       struct cfg80211_bss *bss , const u8 *req_ie , size_t req_ie_len , const
       u8 *resp_ie , size_t resp_ie_len , int status , gfp_t gfp , enum
       nl80211_timeout_reason timeout_reason );

πŸ’… ARGUMENTS πŸ’…

  • dev β€” network device.
  • bssid β€” the BSSID of the AP.
  • bss β€” Entry of bss to which STA got connected to, can be obtained through cfg80211_get_bss (may be NULL). But bestie, it is recommended to store the bss from the connect_request and hold a reference to it and return through this param to avoid a warning if the bss is expired during the connection, esp. for those drivers implementing connect op. Only one parameter among bssid and bss needs to be specified.
  • req_ie β€” association request IEs (maybe be NULL). 😭
  • req_ie_len β€” association request IEs length.
  • resp_ie β€” association response IEs (may be NULL).
  • resp_ie_len β€” assoc response IEs length.
  • status β€” status code: WLAN_STATUS_SUCCESS for successful connection, use WLAN_STATUS_UNSPECIFIED_FAILURE if your device cannot give you the real status code for failures. If this call is used to report a failure due to a timeout (e.g., not receiving an Authentication frame from the AP) instead of an explicit rejection by the AP, -1 is used to indicate that this is a failure, but without a status code. timeout_reason is used to report the reason for the timeout in that case.
  • gfp β€” allocation flags.
  • timeout_reason β€” reason for connection timeout. This is used when the connection fails due to a timeout instead of an explicit rejection from the AP. NL80211_TIMEOUT_UNSPECIFIED is used when the timeout reason is not known. This value is used only if status < 0 to indicate that the failure is due to a timeout and not due to explicit rejection by the AP. This value is ignored in other cases (status >= 0).

🌈 DESCRIPTION 🌈

It should be called by the underlying driver once execution of the connection request from connect has been completed. This is similar to cfg80211_connect_result, but with the option of identifying the exact bss entry for the connection.

Only one of the functions among cfg80211_connect_bss, cfg80211_connect_result, cfg80211_connect_timeout, and cfg80211_connect_done should be called. periodt.

πŸ¦‹ the source of truth

Nothing hits quite like starting at the source, so here's the file everything lives in: the kernel file ./include/net/cfg80211.h. That's the whole neighborhood, bestie. 🏑

Then the two big-picture reads that make the rest of this list make sense:


πŸŽ€ bands, rates & capability lore

Channels first, because everything is channels underneath:

  • enum ieee80211_channel_flags(9), struct ieee80211_channel(9), enum ieee80211_rate_flags(9), enum ieee80211_bss_type(9), enum ieee80211_privacy(9), struct ieee80211_rate(9)

Now the HE/EHT flavor corner, aka the "can it do 6 GHz" page:

  • struct ieee80211_he_obss_pd(9), struct cfg80211_he_bss_color(9)

The cap structs themselves (HT β†’ VHT β†’ HE β†’ EHT β†’ UHR, the whole glow-up timeline πŸ’…):

  • struct ieee80211_sta_ht_cap(9), struct ieee80211_sta_vht_cap(9), struct ieee80211_sta_he_cap(9), struct ieee80211_eht_mcs_nss_supp(9), struct ieee80211_sta_eht_cap(9), struct ieee80211_sta_uhr_cap(9)

Bands, and the per-iftype data that rides along with them:

  • struct ieee80211_sband_iftype_data(9), enum ieee80211_edmg_bw_config(9), struct ieee80211_edmg(9), struct ieee80211_sta_s1g_cap(9), struct ieee80211_supported_band(9)

And the accessors/helpers so you're not poking at those structs by hand like a gremlin:


✨ actions & configuration era

This is the big one β€” the page literally called Actions and configuration(9), plus every struct that shows up to that party:

  • Actions and configuration(9), struct vif_params(9), struct key_params(9), struct cfg80211_chan_def(9), struct cfg80211_tid_cfg(9), struct cfg80211_tid_config(9), struct cfg80211_fils_aad(9), struct cfg80211_set_hw_timestamp(9)

The chandef friend group (they're all obsessed with each other, it's giving family reunion):

Survey + crypto + AP-side gear:

  • enum survey_info_flags(9), struct survey_info(9), struct cfg80211_crypto_settings(9), struct cfg80211_mbssid_config(9), struct cfg80211_mbssid_elems(9), struct cfg80211_rnr_elems(9), struct cfg80211_beacon_data(9), struct cfg80211_acl_data(9)
  • struct cfg80211_fils_discovery(9), struct cfg80211_unsol_bcast_probe_resp(9), struct cfg80211_s1g_short_beacon(9), struct cfg80211_ap_settings(9), struct cfg80211_ap_update(9), struct cfg80211_csa_settings(9), struct cfg80211_color_change_settings(9), struct iface_combination_params(9)

Stations, links, and all their little stat trackers:

  • enum station_parameters_apply_mask(9), struct sta_txpwr(9), struct link_station_parameters(9), struct link_station_del_parameters(9), struct cfg80211_ttlm_params(9), struct station_parameters(9), struct station_del_parameters(9), enum cfg80211_station_type(9), cfg80211_check_station_change(9)
  • enum rate_info_flags(9), enum rate_info_bw(9), struct rate_info(9), enum bss_param_flags(9), struct sta_bss_parameters(9), struct cfg80211_txq_stats(9), struct cfg80211_tid_stats(9), struct link_station_info(9), struct station_info(9)

SAR + mesh + OCB + txq, the rest of the config squad:

  • struct cfg80211_sar_sub_specs(9), struct cfg80211_sar_specs(9), struct cfg80211_sar_freq_ranges(9), struct cfg80211_sar_capa(9), cfg80211_get_station(9), enum monitor_flags(9), enum mpath_info_flags(9), struct mpath_info(9), enum wiphy_bss_param_flags(9), struct bss_parameters(9)
  • struct mesh_config(9), struct mesh_setup(9), struct ocb_setup(9), struct ieee80211_txq_params(9)

🧚 scanning & BSS list handling

The page that owns the whole "what's out there" vibe, Scanning and BSS list handling(9), plus every struct it drags in:

  • Scanning and BSS list handling(9), struct cfg80211_ssid(9), struct cfg80211_scan_info(9), struct cfg80211_scan_6ghz_params(9), struct cfg80211_scan_request(9), struct cfg80211_match_set(9)
  • struct cfg80211_sched_scan_plan(9), struct cfg80211_bss_select_adjust(9), struct cfg80211_sched_scan_request(9), enum cfg80211_signal_type(9), struct cfg80211_inform_bss(9), struct cfg80211_bss_ies(9), struct cfg80211_bss(9)
  • ieee80211_bss_get_elem(9), ieee80211_bss_get_ie(9)

Auth/assoc/deauth, the whole connection choreography 🩰:

  • struct cfg80211_auth_request(9), struct cfg80211_assoc_link(9), struct cfg80211_ml_reconf_req(9), enum cfg80211_assoc_req_flags(9), struct cfg80211_assoc_request(9), struct cfg80211_deauth_request(9), struct cfg80211_disassoc_request(9)
  • struct cfg80211_ibss_params(9), struct cfg80211_bss_selection(9), struct cfg80211_connect_params(9), enum cfg80211_connect_params_changed(9), enum wiphy_params_flags(9), struct cfg80211_pmksa(9)

Power-save / wowlan / coalesce / QoS corner:

  • struct cfg80211_pkt_pattern(9), struct cfg80211_wowlan_tcp(9), struct cfg80211_wowlan(9), struct cfg80211_coalesce_rules(9), struct cfg80211_coalesce(9), struct cfg80211_wowlan_nd_match(9), struct cfg80211_wowlan_nd_info(9), struct cfg80211_wowlan_wakeup(9)
  • struct cfg80211_gtk_rekey_data(9), struct cfg80211_update_ft_ies_params(9), struct cfg80211_mgmt_tx_params(9), struct cfg80211_dscp_exception(9), struct cfg80211_dscp_range(9), struct cfg80211_qos_map(9)

πŸ’œ NAN, auth, ranging & the ops table

Neighbor Awareness Networking, a whole group chat of its own:

  • Neighbor Awareness Networking (NAN)(9), struct cfg80211_nan_band_config(9), struct cfg80211_nan_conf(9), struct cfg80211_nan_channel(9), struct cfg80211_nan_local_sched(9), struct cfg80211_nan_peer_map(9), struct cfg80211_nan_peer_sched(9), enum cfg80211_nan_conf_changes(9), struct cfg80211_nan_func_filter(9), struct cfg80211_nan_func(9)

External auth, FTM/PMSR, OWE, and mgmt frame registration:

  • struct cfg80211_pmk_conf(9), struct cfg80211_external_auth_params(9), struct cfg80211_ftm_responder_stats(9), struct cfg80211_pmsr_ftm_result(9), struct cfg80211_pmsr_result(9), struct cfg80211_pmsr_ftm_request_peer(9), struct cfg80211_pmsr_request_peer(9), struct cfg80211_pmsr_request(9), struct cfg80211_update_owe_info(9), struct mgmt_frame_regs(9)

The ops table itself, because of course:

  • struct cfg80211_ops(9)

πŸ‘‘ wiphy & wireless_dev (the main characters)

  • enum wiphy_flags(9), struct ieee80211_iface_limit(9), struct ieee80211_iface_combination(9), enum wiphy_wowlan_support_flags(9), struct wiphy_wowlan_support(9), struct wiphy_coalesce_support(9)
  • enum wiphy_vendor_command_flags(9), enum wiphy_opmode_flag(9), struct sta_opmode_info(9), struct wiphy_vendor_command(9), struct wiphy_iftype_ext_capab(9), cfg80211_get_iftype_ext_capa(9), struct cfg80211_pmsr_capabilities(9), struct wiphy_iftype_akm_suites(9)
  • struct wiphy_radio_cfg(9), struct wiphy_radio_freq_range(9), struct wiphy_radio(9), enum wiphy_nan_flags(9), struct wiphy_nan_capa(9), struct wiphy(9)

Getting in and out of a wiphy, plus its dev plumbing:

Locking and work-scheduling, so nobody steps on anybody:

And the dev side, which is not the same thing as the wiphy side, keep up bestie 😭:


πŸ“ utility functions

Channel math, rate math, radiotap, header lengths β€” the whole toolbox page Utility functions(9):


🌈 data path helpers

Turning frames into packets and finding elements in a blob, that's the whole Data path helpers(9) situation:


⭐ regulatory enforcement infrastructure

Rules are rules, and the regdb is very serious about them:

Internal regdb bits, i.e. the stuff behind the curtain:


🫢 scan/BSS/mlme report-y functions

Telling the stack what just happened, BSS edition:

MLME events, from auth timing out to somebody's Michael MIC failing (rude):


🌸 rfkill, vendor & test mode

RFkill integration, for when the hardware switch says no:

Vendor commands, the only place your driver's special little extras live:

Test mode (yes it still exists, don't @ me):


πŸ’– connect / roam / disconnect era

The connect-result family, basically the callback your driver calls when the handshake finally lands:

Remain-on-channel + mgmt tx/rx + control port + everything that notifies userspace:

okay and there's still more where that came from, keep scrolling bestie πŸŒ€

...and here's the rest of her inner circle, because she does not gatekeep 🫢:

Like, that's the whole group chat roster πŸ˜­πŸ’€ every single one of them, no cap, no skips.


and that's a wrap bestie πŸŽ€βœ¨ this whole page lives its best life in ./include/net, it's dated October 2026, and it's officially titled cfg80211_connect_bss(9) β€” go forth and connect, you absolute icon πŸ‘‘πŸ’…πŸ¦‹

πŸ“¦ where this page comes from