On Tue, 2014-02-04 at 11:33 +0100, Johannes Berg wrote: > On Tue, 2014-02-04 at 12:07 +0200, Luca Coelho wrote: > > > > Hmm, that sounds a bit the wrong way around? Shouldn't the CSA not be > > > possible (userspace CSA) or cause the switching interface to disconnect, > > > rather than *others*?? > > > > It depends. And this logic is too complicated to stay in the kernel, > > IMHO. If we are in a GO-follows-STA scenario, we want to disconnect the > > GO. Now, if you have an AP (with tons of STAs connected to it) and a > > P2P client gets a CSA for whatever reason, do we really want to stop the > > AP? > > 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? 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. -- 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
