linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] cfg80211: Fix GO Concurrent relaxation on UNII-3
@ 2014-04-23  6:22 Ilan Peer
  2014-04-25 14:46 ` Johannes Berg
  0 siblings, 1 reply; 4+ messages in thread
From: Ilan Peer @ 2014-04-23  6:22 UTC (permalink / raw)
  To: linux-wireless; +Cc: mcgrof, Ilan Peer

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(-)

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;
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] cfg80211: Fix GO Concurrent relaxation on UNII-3
  2014-04-23  6:22 [PATCH] cfg80211: Fix GO Concurrent relaxation on UNII-3 Ilan Peer
@ 2014-04-25 14:46 ` Johannes Berg
  2014-04-27  9:33   ` Peer, Ilan
  0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2014-04-25 14:46 UTC (permalink / raw)
  To: Ilan Peer; +Cc: linux-wireless, mcgrof

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [PATCH] cfg80211: Fix GO Concurrent relaxation on UNII-3
  2014-04-25 14:46 ` Johannes Berg
@ 2014-04-27  9:33   ` Peer, Ilan
  2014-05-20  6:45     ` Luis R. Rodriguez
  0 siblings, 1 reply; 4+ messages in thread
From: Peer, Ilan @ 2014-04-27  9:33 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, mcgrof@do-not-panic.com

PiBPbiBXZWQsIDIwMTQtMDQtMjMgYXQgMDk6MjIgKzAzMDAsIElsYW4gUGVlciB3cm90ZToNCj4g
PiBBdCBzb21lIGxvY2F0aW9ucywgY2hhbm5lbHMgMTQ5LTE2NSBhcmUgY29uc2lkZXJlZCBhIHNp
bmdsZSBidW5kbGUsDQo+ID4gd2hpbGUgYXQgc29tZSBvdGhlciBsb2NhdGlvbnMsIGUuZy4sIElu
ZG9uZXNpYSwgY2hhbm5lbHMNCj4gPiAxNDktMTYxIGFyZSBjb25zaWRlcmVkIGEgc2luZ2xlIGJ1
bmRsZSwgd2hpbGUgY2hhbm5lbCAxNjUgYmVsb25ncyB0byBhDQo+ID4gZGlmZmVyZW50IGJ1bmRs
ZS4gVGhpcyBtZWFucyB0aGF0Og0KPiA+DQo+ID4gMS4gQSBzdGF0aW9uIGludGVyZmFjZSBjb25u
ZWN0aW9uIHRvIGFuIEFQIG9uIGNoYW5uZWwgMTY1IGFsbG93cw0KPiA+ICAgIHRoZSBpbnN0YW50
aWF0aW9uIG9mIGEgUDJQIEdPIG9uIGNoYW5uZWxzIDE0OS0xNjUuDQo+ID4gMi4gQSBzdGF0aW9u
IGludGVyZmFjZSBjb25uZWN0aW9uIHRvIGFuIEFQIG9uIGNoYW5uZWxzIDE0OS0xNjENCj4gPiAg
ICBkb2VzIE5PVCBhbGxvdyB0aGUgaW5zdGFudGlhdGlvbiBvZiBhIFAyUCBHTyBvbiBjaGFubmVs
IDE2NS4NCj4gPg0KPiA+IEZpeCB0aGlzLg0KPiANCj4gSSdsbCBhcHBseSB0aGlzLCBidXQgSSdt
IG5vdCBhIGJpZyBmYW4gb2YgaXQuIFBsZWFzZSB3b3JrIHdpdGggTHVpcyB0byBnZXQgc29tZQ0K
PiBpbmZvcm1hdGlvbiBpbnRvIHRoZSByZWd1bGF0b3J5IGRhdGFiYXNlLg0KPiANCg0KU3VyZS4g
THVpcywgaG93IHdvdWxkIGxpa2UgbWUgdG8gYWRkcmVzcyB0aGlzPyANCg0KPiBMdWlzIHBvaW50
ZWQgdGhpcyBvdXQgb3JpZ2luYWxseSBbMV0gd2hlbiB5b3Ugd2VyZSBhZGRpbmcgdGhlIFVOSUkt
MS8yLzMNCj4gdGhpbmdzIHRvIHRoZSBrZXJuZWwgdGhhdCBoZSBkaWRuJ3QgdGhpbmsgdGhleSdk
IGJlIHVuaXZlcnNhbGx5IGFwcGxpY2FibGUsIGJ1dA0KPiB5b3Ugc2FpZCB0aGV5IHdlcmUgLi4u
IEkgZ3Vlc3MgTHVpcyBhbHNvIHRob3VnaHQgaXQgd2FzIHRydWUgdGhvdWdoLCBhbmQgaXQNCj4g
ZG9lc24ndCBzZWVtIHRvIGJlICh3aGljaCBzZWVtcyB0byBiZSBiZWNhdXNlIG9mIHRoZSA4ME1I
eiB0aGluZyB3aXRoDQo+IGNoYW5uZWwgMTY1IEkgZ3Vlc3MpDQo+IA0KDQpTb3JyeSBmb3IgdGhp
cy4gQXQgdGhlIHRpbWUgSSB3YXMgdW5kZXIgdGhlIHVuZGVyc3RhbmRpbmcgdGhhdCB0aGVzZSB3
ZXJlIHVuaXZlcnNhbGx5IHRydWUuDQoNClJlZ2FyZHMsDQoNCklsYW4uDQo=

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] cfg80211: Fix GO Concurrent relaxation on UNII-3
  2014-04-27  9:33   ` Peer, Ilan
@ 2014-05-20  6:45     ` Luis R. Rodriguez
  0 siblings, 0 replies; 4+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20  6:45 UTC (permalink / raw)
  To: Peer, Ilan; +Cc: Johannes Berg, linux-wireless@vger.kernel.org

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-05-20  6:45 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-23  6:22 [PATCH] cfg80211: Fix GO Concurrent relaxation on UNII-3 Ilan Peer
2014-04-25 14:46 ` Johannes Berg
2014-04-27  9:33   ` Peer, Ilan
2014-05-20  6:45     ` Luis R. Rodriguez

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).