> I'm afraid to consider what you're like when you _are_ 'super' > against something :) Why, that's easy, there wouldn't be a long discussion like that ;-) > So here's a quick test, with the client triggering authenticate, then > crashing: > < Request: Authenticate (0x25) len 52 > [ack] 362.339712 > [...] > > Event: Del Station (0x14) len > 1144 367.442024 > Pay attention to the time stamps. The del station event comes in 5 > seconds or so after our client has aborted. So for 5 seconds we have > an unmanaged link to some AP. No, this is the part you didn't understand. Simply authenticating doesn't actually create anything like a "link" to the AP. The only reason we keep the station entry around for a few seconds is that it *probably* will be used next to associate. But if you don't do that, or authenticate to some other AP, or do whatever else - nothing stops you from doing that. There's no connection, nothing really stays active except for this 5 second grace period to associate. So even if you crash here like in the example, there's nothing to clean up, a subsequent authentication attempt to the same or another AP will go through anyway. Therefore, there's nothing to "own" with an authentication attempt, since it doesn't actually keep any (permanent) state in the kernel, and keeping the station entry around is just an optimisation. I don't think it's worth trying to clean that up. Also, consider that authentication doesn't block anything, so another socket might immediately do another authentication/association, and you don't want to kill that even when the first one dies. Corner case, sure, but at least with association the second one would get "-EBUSY" or so, whereas authentication keeps no state in the kernel. johannes
