On Thu, 2013-01-03 at 08:47 +0100, Simon Wunderlich wrote:
> 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.
I just don't see that the clients will wait a minute (?) for the CAC on
the new channel, they'll probably just disconnect and look for another
AP. So I guess the question is whether we should ever switch to a radar
channel ...
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
