On Sat, 2013-01-26 at 13:09 +0100, Nicolas Cavallari wrote: > Yes, this is what wpasupplicant assumes: When a station is added, it is > already authenticated. So wpasupplicant does not wait before sending > handshakes. > > This causes problem with the current kernel's behavior to send auth > frames, because it can race: wpasupplicant sometimes send it's first 1/4 > handshake before the kernel's auth frame. If the peer runs Linux with > the reboot detection, it is utterly confused : the peer's wpasupplicant > receives the 1/4 frame, answers it with 2/4, then the peer's kernel > receives the auth frames, and resets the station, discarding the state > of wpasupplicant, which no longer knows that it has started a handshake. > > Meanwhile, on the other host, wpasupplicant happily receives the 2/4 > response, and proceed with sending 3/4 frame. Then there is utter > confusion, because the other host does not know what to do with > handshake 3/4 and drops it. > > This is what the current patch tries to fix : by making wpasupplicant > waits for the kernel to tell it that it has completed an open system > authentication. This requires patch to both. Ok I guess that explains it a little better. > (and my take on this, is that we should just handle open system > authentication and reboot detection in userspace (i have code for that), > and revert the kernel to the old state where it would just answers an > open system authentication request if userspace is not handling it) I think that would make sense. However, to really implement that it seems that wpa_s should be able to control the in-kernel station "authenticated" state, not just "authorized" state? What's the status we have today in the kernel, without the patches, and what would that "revert" mean? > This patch (under the case when userspace is not handling auth frames) > defers authentication until an open system authentication is done or has > timed out, and uses a new event (IBSS_STA) to indicate that a station is > authenticated. > > But if you use the patched kernel with the current (unpatched) > wpasupplicant, wpasupplicant will still send handshakes right after a > station is added, even if the station is not authenticated. With enough > bad luck, the open system authentication request or response can be > lost, and wpa_supplicant might complete a handshake before the kernel's > open system authentication timeout, therefore, wpasupplicant would ask > the kernel to authorize a station which is even not authenticated. > > (and if you use a patched wpasupplicant with an unpatched kernel, it > will just wait for an event which will never happen) Yeah, both of these cases are really bad, in particular since there's no way for wpa_s to detect this, and it breaks backward compatibility. I guess I just made up my mind that I'm not going to apply this. What changes could we make today to solve this in a way that's compatible with today's wpa_supplicant (and maybe Will's SAE implementation, though maybe he wouldn't mind small changes too much)? johannes -- 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
