On Sun, Aug 26, 2012 at 11:10 AM, Johannes Berg
[off-list ref] wrote:

On Sun, 2012-08-26 at 10:58 +0300, Eliad Peller wrote:

quoted

quoted

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 :)

quoted

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.