On Mon, 2014-01-20 at 15:21 +0100, Michal Kazior wrote: > It was possible to connect STA when AP CSA was in > progress which clearly was a bug. > > Deny attempts to increase chanctx refcount or > create chanctx. > > This effectively denies starting a new interface > and radar detection while CSA is in progress. > > Existing interfaces (including those with active > CSA) can be stopped though. I think this is the wrong approach. This makes more special cases for non-chanctx code, whereas I think the code should gain more channel context awareness. Luca has a patch to make channel switch work with channel contexts (by creating one on the new channel and then later switching to it), and I think this mechanism should be subsumed into the channel context reservation code, rather than being CSA specific. However, if there's only one channel context (or no support for channel contexts) then CSA becomes a special case in Luca's patch, I guess, because we can't be reserving a new one? Luca, this is probably something you need to look into - this goes back to the exact timing thing we just talked about. If we don't support channel contexts, then we can create a fake one to switch to, but then this fake one can't accept any further interfaces being bound to it since it will not be able to coexist with the other one. As far as this particular behaviour is concerned, I would then say that then the old channel context should also be marked as incompatible for the time of the CSA, so that no other (station) vif can attempt to use it. That'll result in a better solution overall, I think. johannes -- 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
