STRUCT CFG80211_CONNECT_RESP_PARAMS(9)

📦 version 7.3.1, in nixpkgs unstable

💖 NAME 💖

struct cfg80211_connect_resp_params — the connection response params situation, aka the manual page struct cfg80211_connect_resp_params(9) from the Kernel API Manual. Bestie, this is the struct your driver fills in when it's telling the kernel "okay so here's what happened when we tried to connect."

✨ SYNOPSIS ✨

struct cfg80211_connect_resp_params {
    int status;
    const u8 *req_ie;
    size_t req_ie_len;
    const u8 *resp_ie;
    size_t resp_ie_len;
    struct cfg80211_fils_resp_params fils;
    enum nl80211_timeout_reason timeout_reason;
    bool assoc_encrypted;
    const u8 *ap_mld_addr;
    u16 valid_links;
    struct {
      const u8 *addr;
      const u8 *bssid;
      struct cfg80211_bss *bss;
      u16 status;
    } links[IEEE80211_MLD_MAX_NUM_LINKS];
 };

Like, that's the whole shape of it. Slay. Let's go through every single member because we are not skipping any of them, periodt. 🎀

🦋 MEMBERS 🦋

  • status — the status code, bestie. Use WLAN_STATUS_SUCCESS for a successful connection. If your device literally cannot give you the real status code for failures, use WLAN_STATUS_UNSPECIFIED_FAILURE instead — no cap, that's the fallback. And if this call is being used to report a failure due to a timeout (think: not receiving an Authentication frame from the AP) instead of an explicit rejection by the AP, then -1 is used to indicate "yes this is a failure, but we don't have a status code for it." In that case, timeout_reason is what reports the reason for the timeout. 💅
  • req_ie — the Association request IEs. May be NULL, so don't panic.
  • req_ie_len — the Association request IEs length. It's giving "length of the thing above." 🌸
  • resp_ie — the Association response IEs. Also may be NULL.
  • resp_ie_len — the Association response IEs length. Matching pair, we love to see it.
  • fils — FILS connection response parameters. That's it, that's the member. 🧚
  • timeout_reason — the reason for the connection timeout. This one's used when the connection fails due to a timeout instead of an explicit rejection from the AP. NL80211_TIMEOUT_UNSPECIFIED is what you use when the timeout reason is not known. Important detail incoming: this value is used only if status < 0, to indicate the failure is due to a timeout and not an explicit rejection by the AP. In all other cases (status >= 0) this value is ignored. 🙈
  • assoc_encrypted — the driver should set this flag to indicate that the (Re)Association Request/Response frames are transmitted encrypted over the air. Encrypted over the air, iykyk. 🔥
  • ap_mld_addr — for an MLO connection, this is the MLD address of the AP. Otherwise NULL. Simple as that.
  • valid_links — for an MLO connection, this is the BIT mask of the valid link ids. Otherwise zero. Bitmask girlies rise. 👑
  • links — for an MLO connection, this contains link info for the valid links indicated using valid_links. For a non-MLO connection, links[0] contains the connected AP info. 🌈
  • links.addr — for an MLO connection, the MAC address of the STA link. Otherwise NULL.
  • links.bssid — for an MLO connection, the MAC address of the AP link. For a non-MLO connection, links[0].bssid points to the BSSID of the AP (may be NULL). 🫶
  • links.bss — for an MLO connection, the entry of bss to which the STA link is connected. For a non-MLO connection, links[0].bss points to the entry of bss to which the STA is connected. It can be obtained through cfg80211_get_bss (may be NULL). And listen — it is recommended to store the bss from the connect_request and hold a reference to it and return through this param, so you 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. Not both, bestie. Pick one. 💀
  • links.status — per-link status code. To report a status code that's not WLAN_STATUS_SUCCESS for a given link, it must also be in the valid_links bitmap and may have a BSS pointer (which is then released). ⭐
ok that's part 1, the vibes continue in part 2 — don't go anywhere 💜

💅 SEE ALSO 💅

okay bestie, this is the part where the manpage just dumps the entire friend group on you 😭 like not even kidding, this is the biggest "and also" ever. Every single one of these lil icons lives in the kernel file ./include/net/cfg80211.h, and they're all gonna want their own ✨ moment. Drink some water, stretch your wrists, and let's get through the roster together 🫶

like, that's genuinely the whole friend group 💀 every one of these has its own page, so if you clicked a name and got a whole new manpage, that's why — you're not lost, you're just networking ✨🌈

and yeah, that list just… ends with struct cfg80211_beaconing_check_config(9), comma and all, no goodbye, no "anyway"— which is so on brand for a kernel doc honestly 😭 anyway, there's still more coming so don't go anywhere bestie 🎀🦋

okay so the cross-refs keep coming and honestly? they ate ✨ this is the rest of the list, bestie — every single one, no skipping, no cap:

and that's a wrap on the whole thing, bestie 🫶 the page lives at ./include/net, the date on it is October 2026, and the header it's filed under is struct cfg8..._resp_params(9) (yes, truncated exactly like that, we don't fix it, we respect it 💅). go forth and read the cross-refs, iykyk 🌟

📦 where this page comes from