cfg80211: Fix GO Concurrent relaxation on UNII-3
PATCH 1/1 cfg80211: Fix GO Concurrent relaxation on UNII-3
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.
---
Applied on top of mac80211-next/master.
net/wireless/chan.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
net/wireless/chan.c +17 -1
@@ -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;
Signature · 1 line
1.7.10.4
Johannes Berg
maintainerQuoted 11 lines · 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.
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
[email protected]
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=
Quoted 11 lines · Ilan
Quoted 11 lines · Ilan Peer
Quoted 10 lines
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.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
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