Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT

[Johannes Berg <johannes@sipsolutions.net>]

> 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