Hi,
On 5/23/25 5:34 AM, Johannes Berg wrote:
Hi,
(uh, please trim quotes)
1. The kernel takes the delay in the association response frame and
waits, but has no sane bounds for how long the wait is. An AP could send
0xffffffff and the kernel will just block for that entire duration.
For some value of "block", it's not really blocking in the (traditional)
threading sense of the word :)
Yes, true, its not blocking the kernel. Just blocks userspace unless
that event is handled, which isn't handled by any userspace supplicants
AFAICT.
wpa_supplicant seems to handle it just fine? I guess in an ideal world
we'd have made it some kind of opt-in, or the supplicant would've given
some sort of maximum wait value.
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.
Oh, so you're just trying to sell us a missing implementation in iwd as
a kernel security bug? :-)
Depends on how you look at it I guess. Handling the event in userspace
almost feels like an escape hatch for the kernel having used untrusted
input but that's just how I see it. Waiting 15 minutes for a WiFi
connection that should take 200ms is on the level of absurd and
unreasonable from my view, but that's just my opinion.
But it shouldn't take 200ms. The comeback can be larger and you may
actually want to wait for it if you have no other choice of AP anyway.
Sure it takes less than 200ms to connect in normal cases, but comeback
already isn't an immediate connection. Whether that then is 15 seconds
or 15 minutes - sure, the latter seems excessive, but I'm not sure I'd
want to define a timeout somewhere between there. Given your
argumentation it sounds like you'd say "1 second is excessive", but
that's just under the _default_ setting in hostapd for
assoc_sa_query_max_timeout.
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.
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.
Thanks,
James
johannes
