Hi, On Thu, Sep 18, 2014 at 7:13 AM, Sujith Manoharan <sujith@xxxxxxxxxxx> wrote: > Sujith Manoharan wrote: >> I don't think trying to switch channel contexts in the flush() callback >> is a good idea. We would be changing the meaning of the callback if >> we do that. Moreover flush() is called from many other places too, like the >> PS code. >> >> It seems appropriate to instruct a driver to make the necessary >> preparations before sending a deauth frame. Do you see any problems >> if mgd_prepare_tx() is called before initiating deauth ? > > Calling mgd_prepare_tx() in ieee80211_send_deauth_disassoc(), which > was the case originally, is probably more correct, since there are other > situations where this will be a problem. > > CSA is one example. The driver can receive a beacon, mac80211 begins to > process the CSA and if multiple contexts are active, initiates a disconnect > operation. But, in the meantime, if the driver has switched to a different > context, things will break. > I still think it does not match the original intent of mgd_prepare_tx(). The way I see it, mgd_prepare_tx() ensures that the Tx *will* happen in cases the driver has no specific reason to be on channel, mainly because the context is not associated yet. Note that after association mac80211 does not interfere with the context switches. The driver is in charge of all this - why would it be different in this case? flush() makes sure that the Tx *has* happened before destroying things. The context switches from association until destruction are under the driver's responsibility. At least this is the way I see it. We (Intel) will not break if you add this call, but in my eyes this does not comply with the design. I guess you can always send a patch to add it and see what others will say, but Johannes is away right now. If you choose to do that, please add a reason as a parameter to mgd_prepare_tx() so that we can ignore it when it is called before sending a frame that is flush()'ed. I still prefer to rely on flush(). And I agree that flush() isn't a trivial implementation. Note that the only reason I implemented flush() is because of 11w that forces us to make sure that the deauth is sent, otherwise you'd be kicked by the AP after 3 cycles of association / disassociation. So not sending the deauth from time to time isn't really a big deal in my eyes, but one can argue about that (just like about pretty much everything) :) -- 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
