On Tue, 2014-02-04 at 13:11 +0200, Luca Coelho wrote: > 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. ...and, if the userspace doesn't react, we disconnect the GO. I think it's safer this way for the GO-follows-STA case. -- 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
