On 31/01/2013 14:34, Johannes Berg wrote: > That seems reasonable. Actually there's no reason for wpa_s to "reset > the [...] sta_info", all it really has to do is set it to unauthorized > if it detects it was rebooted, and then start key negotiation again, I > think? I'm not sure why Antonio resetted the sta_info. Not resetting it when a node reboot is detected from userspace works for me anyway. >> If we want a working node reboot detection with the current wpasupplicant, we need, in >> IBSS mode, to only make the kernel send NEW_STA when a station is authenticated. There's >> not much choice here. >> >> If it's acceptable to not have node reboot detection with current wpasupplicant, we could >> make a future wpasupplicant add a flag saying it supports the new IBSS_STA event, and the >> kernel would only do reboot detection in this case. > > I think that's acceptable, but if it requires a wpa_s change anyway we > could just implement reboot detection there instead of adding all these > new events etc.? I.e. rather than having a new supplicant say "OK I will > listen to the right event when handling reboot detection", it could just > use the existing infrastructure and implement it itself? Well i already have wpa_supplicant patches for that. Might just need to clean that up a bit so it's at least configurable. But now i'm reminded that transmitting management frames from userspace requires a frequency. For wpasupp to be race-free during ibss merges, we should have a way to transmit management frames to the current bss without specifying a frequency... (Will once said he uses fixed-channel, so he is not affected) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html