2011-01-11 13:34:45

by Wojciech Dubowik

Subject: [RFC] mac80211: Allow AP to change channels for DFS support

Hello,

I have started studying DFS support possibilities in ath9k
and I have noticed that at the moment AP is not allowed to
change channels when it's using beacons.

I have found that I can go around it by setting CHAN_MODE_UNDEFINED
for this case. Not sure whether we need extra mode for it but
to me this is a case when AP is neither fixed nor hopping.

--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -34,8 +34,11 @@
return CHAN_MODE_HOPPING;
}

- if (sdata->vif.type == NL80211_IFTYPE_AP &&
- !sdata->u.ap.beacon)
+
+ /* TODO: CHAN_MODE_FIXED shouldn't be set when
+ AP is on DFS channel. For now assume always
+ undefined */
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
continue;

return CHAN_MODE_FIXED;


It's also possible to check whether channel is of radar type
and set mode undefined for this case. Question is whether it's
needed at all.

Any comments?

Br,
Wojtek

2011-01-11 13:43:22

by Johannes Berg

Subject: Re: [RFC] mac80211: Allow AP to change channels for DFS support

On Tue, 2011-01-11 at 14:34 +0100, Wojciech Dubowik wrote:
> Hello,
>
> I have started studying DFS support possibilities in ath9k
> and I have noticed that at the moment AP is not allowed to
> change channels when it's using beacons.
>
> I have found that I can go around it by setting CHAN_MODE_UNDEFINED
> for this case. Not sure whether we need extra mode for it but
> to me this is a case when AP is neither fixed nor hopping.
>
> --- a/net/mac80211/chan.c
> +++ b/net/mac80211/chan.c
> @@ -34,8 +34,11 @@
> return CHAN_MODE_HOPPING;
> }
>
> - if (sdata->vif.type == NL80211_IFTYPE_AP &&
> - !sdata->u.ap.beacon)
> +
> + /* TODO: CHAN_MODE_FIXED shouldn't be set when
> + AP is on DFS channel. For now assume always
> + undefined */
> + if (sdata->vif.type == NL80211_IFTYPE_AP)
> continue;
>
> return CHAN_MODE_FIXED;
>
>
> It's also possible to check whether channel is of radar type
> and set mode undefined for this case. Question is whether it's
> needed at all.
>
> Any comments?

I don't think this is a good thing. Putting undefined here will inhibit
any other use of the channel since nothing can rely on it. However, in
the DFS case, everybody else will need to switch away as well, so ...

A similar issue exists with DFS clients too, btw, since they could also
hop channels which we don't currently really model.

johannes