On Tue, 2014-02-04 at 12:24 +0100, Johannes Berg wrote: > On Tue, 2014-02-04 at 13:11 +0200, Luca Coelho wrote: > > > > Well, what I was describing was really only the default policy if > > > userspace didn't do anything useful, which IMHO should really just be: > > > > > > * client receives CSA - disconnect if it can't be done > > > * AP/GO wants CSA - refuse if it can't be done, let userspace sort it > > > out > > > > > > In the first case, userspace still has the time between receiving the > > > CSA and actually acting on it to make another decision. > > > > Right, this is okay, but the point is, what happens to the *other* > > interfaces? > > Nothing! As far as that's permissible. Ilan's patchset might change > that, but that's mostly a regulatory thing, rather than a CSA thing. Ah, you have some insider information! :P > > What does "it can't be done" mean for the client? If there's a GO in the > > same context and no free contexts for the switch, do we simply > > disconnect the client (and leave the GO hanging in the same channel)? We > > should probably tell the userspace and let it decide. > > Yes, but we should only disconnect when the CSA actually needs to be > done, rather than immediately on receiving it. Sure, but how does the userspace know that the other interface *needs* to be moved, regardless of regulatory problems? It needs to know that there are not enough contexts to keep the interfaces in different channels... > > ...and, if the userspace doesn't react, we disconnect the GO. I think > > it's safer this way for the GO-follows-STA case. > > That would be a consequence of Ilan's work, yes. Okay, if that's going to be guaranteed, I'm fine with it. > This typically won't happen, since userspace will do something else, but > we need to have some default policy. I don't think anything else makes > much sense? My point was that a CSA could have been triggered due to regulatory (which the AP/GO is monitoring), so the safest would be to move everyone out of the channel by default. But now I agree that this is an unrelated feature that also needs to be handled when we do have free contexts to make the switch (and keep the two interfaces in different channels). -- Luca. -- 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
