On 7 December 2016 at 07:19, Johannes Berg <[email protected]> wrote: >> Possibly Johanness refers to the fact that if you use >> CMD_AUTHENTICATE, or if you use CMD_CONNECT but the driver implements >> the SME -- doesn't use the cfg80211 software SME -- then >> cfg80211_disconnect won't do anything if we're not associated, only >> authenticated. Currently cfg80211 doesn't have knowledge of whether >> it is authenticated and where to. > > We used to track it, but it was a nightmare and just always buggy :) > >> With the software SME current_bss would be set from the moment the >> authentication attempt starts, > > I'm almost certain this isn't true, what makes you think so?
Ok, I think I misread the code, indeed it looks consistent between the driver SME and cfg80211 SME. I'm fine only adding the socket owner flag to CMD_ASSOCIATE and CMD_CONNECT. I'll need to store the bssid of the association in progress so we can send the Deauthenticate if the socket is closed before association finishes. > >> so there seems to be an inconsistency >> which would affect for example the NL80211_BSS_STATUS_ASSOCIATED >> flags in the result of CMD_GET_SCAN. > > Thus this can't be the case. > >> Perhaps this can be fixed by always >> setting current_bss on auth attempt start, with flags to indicate >> whether authentication has happened and whether association happened. > > No! That would be wrong! > >> At the very least with this patch if you set the socket owner during >> CMD_AUTHENTICATE and then separately associate, you'd get the >> expected deauthentication. > > That would *NOT* be expected. There's no need to even authenticate > through CMD_AUTHENTICATE at all to connect to (another) AP! > > You need to think beyond the 1996 version of 802.11 ;-) Best regards
