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:
signature.asc
Description: Digital signature
