Re: [PATCHv5 7/8] mac80211: add ap channel switch command/event

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

On Wed, Jan 02, 2013 at 02:47:49PM +0100, Johannes Berg wrote:
> On Thu, 2012-12-13 at 14:58 +0100, Simon Wunderlich wrote:
> 
> > +	mutex_lock(&local->mtx);
> > +	if (local->ap_cs_chandef.chan->flags & IEEE80211_CHAN_RADAR) {
> > +		sdata_info(sdata, "changing to DFS channel\n");
> > +		/* when changing to a DFS channel, stop AP. Userspace must
> > +		 * restart AP or do start radar detection first.
> > +		 */
> > +		stop_ap = true;
> 
> I don't see any value in this. You might just as well simply forbid
> requesting a channel change to a DFS channel, hostapd could then stop
> instead of doing the switch.
> 

We explicitly want the channel switch, this was the original idea in 802.11h
- announce the next channel, then switch. To announce the next channel, we
need to allow this.

As discussed before, doing stop_ap here is probably not a good idea. We
can change that back to let the driver disable transmissions and expect
an explicit enable_tx call from userspace after CAC on the new channel.

> > +	} else {
> > +		/* update the device channel directly */
> > +		sdata_info(sdata, "changing to non-DFS channel\n");
> > +
> > +		/* TODO: _oper_channel is deprecated ... use
> > +		 * vif_release/use_channel instead? In this case, we must make
> > +		 * sure that interface is down first ...
> > +		 */
> 
> Well, most likely need to modify the existing channel context instead.
> However, that's tricky, and what if there are other interfaces, what
> happens to those?

That's a fair question ... for the current DFS implementation, I except to
only have one interface (single only context) - for now. We have the same
discussion in the other thread (general design questions), so let's discuss
it there.

Cheers,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]