Message-ID: <1391512500.26522.77.camel@porter.coelho.fi> (sfid-20140204_121508_954738_A22C9096)
Subject: Re: [RFC 2/2] cfg80211: move channel switch logic to cfg80211
From: Luca Coelho <luca@coelho.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Michal Kazior <michal.kazior@tieto.com>,
	linux-wireless@vger.kernel.org
Date: Tue, 04 Feb 2014 13:15:00 +0200
In-Reply-To: <1391512311.26522.75.camel@porter.coelho.fi>
References: <1391421529-6067-1-git-send-email-michal.kazior@tieto.com>
	 <1391421529-6067-3-git-send-email-michal.kazior@tieto.com>
	 (sfid-20140203_110356_335827_0A67B036) <1391434913.4488.24.camel@jlt4.sipsolutions.net>
	 <1391508433.26522.61.camel@porter.coelho.fi>
	 <1391509992.4134.1.camel@jlt4.sipsolutions.net>
	 <1391512311.26522.75.camel@porter.coelho.fi>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Sender: linux-wireless-owner@vger.kernel.org

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.