| Message ID | 1398234178-24685-1-git-send-email-ilan.peer@intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Wed, 2014-04-23 at 09:22 +0300, Ilan Peer wrote: > At some locations, channels 149-165 are considered a single > bundle, while at some other locations, e.g., Indonesia, channels > 149-161 are considered a single bundle, while channel 165 belongs > to a different bundle. This means that: > > 1. A station interface connection to an AP on channel 165 allows > the instantiation of a P2P GO on channels 149-165. > 2. A station interface connection to an AP on channels 149-161 > does NOT allow the instantiation of a P2P GO on channel 165. > > Fix this. I'll apply this, but I'm not a big fan of it. Please work with Luis to get some information into the regulatory database. Luis pointed this out originally [1] when you were adding the UNII-1/2/3 things to the kernel that he didn't think they'd be universally applicable, but you said they were ... I guess Luis also thought it was true though, and it doesn't seem to be (which seems to be because of the 80MHz thing with channel 165 I guess) johannes [1] http://mid.gmane.org/CAB=NE6VQXQPRK9_Q-Nh+ripRa +PdCd=4_EZvPxeghBjc32ejyQ@mail.gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Wed, 2014-04-23 at 09:22 +0300, Ilan Peer wrote: > > At some locations, channels 149-165 are considered a single bundle, > > while at some other locations, e.g., Indonesia, channels > > 149-161 are considered a single bundle, while channel 165 belongs to a > > different bundle. This means that: > > > > 1. A station interface connection to an AP on channel 165 allows > > the instantiation of a P2P GO on channels 149-165. > > 2. A station interface connection to an AP on channels 149-161 > > does NOT allow the instantiation of a P2P GO on channel 165. > > > > Fix this. > > I'll apply this, but I'm not a big fan of it. Please work with Luis to get some > information into the regulatory database. > Sure. Luis, how would like me to address this? > Luis pointed this out originally [1] when you were adding the UNII-1/2/3 > things to the kernel that he didn't think they'd be universally applicable, but > you said they were ... I guess Luis also thought it was true though, and it > doesn't seem to be (which seems to be because of the 80MHz thing with > channel 165 I guess) > Sorry for this. At the time I was under the understanding that these were universally true. Regards, Ilan.
On Sun, Apr 27, 2014 at 2:33 AM, Peer, Ilan <ilan.peer@intel.com> wrote: >> On Wed, 2014-04-23 at 09:22 +0300, Ilan Peer wrote: >> > At some locations, channels 149-165 are considered a single bundle, >> > while at some other locations, e.g., Indonesia, channels >> > 149-161 are considered a single bundle, while channel 165 belongs to a >> > different bundle. This means that: >> > >> > 1. A station interface connection to an AP on channel 165 allows >> > the instantiation of a P2P GO on channels 149-165. >> > 2. A station interface connection to an AP on channels 149-161 >> > does NOT allow the instantiation of a P2P GO on channel 165. >> > >> > Fix this. >> >> I'll apply this, but I'm not a big fan of it. Please work with Luis to get some >> information into the regulatory database. >> > > Sure. Luis, how would like me to address this? Generally we move things that are not universal as flags, or value attributes, the difficulty here lies in that we'd get different sets of groups that allow flexibility to lift restrictions. A flag would still work in the case of UNII 3 and would enable this permissive rule to be usable on other bands as well. It would also then make the restriction to Indonesia specific to that region. As far as I can tell P2P does mandate country IE to be set so this would make relying on the country IE to be available on clients associating, the flag could also be cleared upon disconnect as we clear all permissive flags as we do not after a disconnect / suspend / resume / reboot. Let me know what you think. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/wireless/chan.c b/net/wireless/chan.c index c61bcdd..fb8f6a3 100644 --- a/net/wireless/chan.c +++ b/net/wireless/chan.c @@ -750,8 +750,24 @@ static bool cfg80211_go_permissive_chan(struct cfg80211_registered_device *rdev, r1 = cfg80211_get_unii(chan->center_freq); r2 = cfg80211_get_unii(other_chan->center_freq); - if (r1 != -EINVAL && r1 == r2) + if (r1 != -EINVAL && r1 == r2) { + /* + * At some locations channels 149-165 are considered a + * bundle, but at other locations, e.g., Indonesia, + * channels 149-161 are considered a bundle while + * channel 165 is left out and considered to be in a + * different bundle. Thus, in case that there is a + * station interface connected to an AP on channel 165, + * it is assumed that channels 149-161 are allowed for + * GO operations. However, having a station interface + * connected to an AP on channels 149-161, does not + * allow GO operation on channel 165. + */ + if (chan->center_freq == 5825 && + other_chan->center_freq != 5825) + continue; return true; + } } return false;
At some locations, channels 149-165 are considered a single bundle, while at some other locations, e.g., Indonesia, channels 149-161 are considered a single bundle, while channel 165 belongs to a different bundle. This means that: 1. A station interface connection to an AP on channel 165 allows the instantiation of a P2P GO on channels 149-165. 2. A station interface connection to an AP on channels 149-161 does NOT allow the instantiation of a P2P GO on channel 165. Fix this. Signed-off-by: Ilan Peer <ilan.peer@intel.com> --- Applied on top of mac80211-next/master. net/wireless/chan.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)