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. > 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. > ...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. 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? 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
