On Sun, Aug 26, 2012 at 11:10 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sun, 2012-08-26 at 10:58 +0300, Eliad Peller wrote: > >> > 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)? > > Well, it is still a bit different, we have no channel at all :) > right, but when the device is idle you are not expected to be tuned to any channel as well, so it's pretty similar :) >> this scenario (deauth after disassoc) also sounds pretty unlikely... > > It seems that it happens when you ask the supplicant to "disconnect" via > the CLI. > at least in my setup issuing a "disconnect" via the CLI ends only with a deauth (as the respective code in wpa_supplicant/ctrl_iface.c seems to call only wpa_supplicant_deauthenticate()) 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
