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. > > 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. johannes
