On Fri, Aug 24, 2012 at 12:29 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2012-07-27 at 13:16 +0200, Johannes Berg wrote: > >> Comments welcome! > > Ilan pointed me to a problem here yesterday. > > Say we authenticate, then at that time we'll bind the virtual interface > into an appropriate channel context. Now we associate, and keep that > channel context. So far, so good. > > Now say we disassociate. At this point, the connection is gone, so we > remove the channel context. > > Now if the supplicant wants to deauthenticate as well, we have no > channel context to use for it. We could use remain-on-channel? Or we > could create a new channel context? Or just ignore the deauth? I haven't > found a good solution yet... We also can't rely on the supplicant always > doing a deauth, so we don't want to keep the channel context around > until the deauth either. > > Obviously the same can also happen if the supplicant just asks us to > deauthenticate without ever having connected at all, but that's a rather > unlikely case. > > Anyone have any idea? :) > is it really different from the situation today, when we'll try tx on idle device/interface (afaict)? this scenario (deauth after disassoc) also sounds pretty unlikely... Eliad. -- 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
