On Fri, 2025-05-23 at 05:54 -0700, James Prestwood wrote:
>
> It logs and returns:
>
> static void nl80211_assoc_comeback(struct wpa_driver_nl80211_data *drv,
> struct nlattr *mac, struct nlattr *timeout)
> {
> if (!mac || !timeout)
> return;
> wpa_printf(MSG_DEBUG, "nl80211: Association comeback requested by "
> MACSTR " (timeout: %u ms)",
> MAC2STR((u8 *) nla_data(mac)), nla_get_u32(timeout));
> }
>
> Its relying on its connection timer though, which is why it "works".
> Opt-in or userspace providing a maximum is definitely a step in the
> right direction IMO.
Hah, ok, I only saw it doing something other than "get stuck" in the
explicit tests :)
> I'll admit, from a single AP use-case if the AP _REALLY_ needs you to
> wait that long you are right in that we have no other choice. I question
> under what circumstances the AP would need that though; when your
> talking on the order of minutes or even 10-15 seconds the AP feels
> broken at that point. I'm also not a vendor and don't know what
> conditions would even trigger this in the first place. Maybe this piece
> of information is what I need to convince me either direction, a
> legitimate reason for an AP to tell the station to wait, and an amount
> of time that would be for.
I don't really have that either, but simply looking at hostapd says 1
second is even default. So where do you draw the line? 10x that? 100x
that? Who knows? Why bother?
> From a user-experience point of view I think most people watching their
> device trying to connect for more than about 20-30 seconds is going to
> trigger a "wtf, this is broken" response. And I know if my router was
> taking that long to accept connections it would be promptly rebooted.
> Its a long way of saying that I think there is some reasonable value here.
We don't just implement wifi for laptops though. I mean we, Intel, do,
but generally the stack gets used elsewhere. The random IOT device out
in my garage? I don't really care where it waits, it only gets a single
BSSID it could ever use.
johannes
