| Message ID | 1372768095-26053-2-git-send-email-ilan.peer@intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Cc'ing a few other lists for a wider review. On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote: > From: David Spinadel <david.spinadel@intel.com> > > The FCC are clarifying some soft configuration requirements, > which among other includes the following: > > 1. Concurrent GO operation, where devices may support WFD in > bands where an authorized master (for example with DFS and > DFS and radar detection capability in the UNII band) is operating. Is WFD WiFi Display? Is there any strict relationship here to WFD and GO and regulatory or is WFD just a use case example? Are you indicating that the FCC is making special rules for cases in specific bands where GO *can* co-exist with other GO devices ? You annotate that this is somehow related to DFS, are the GO concurrent rules that the FCC is defining only applicable to DFS frequency ranges? If so would it suffice to only use DFS flag ? Or are there other special cases beyond DFS frequency ranges that the FCC is creating special handling? Apart from the FCC are you aware of special cases handling for other regulatory bodies at this point? Note that we have already these on regdb.h from CRDA: /* * The Linux map defined in <linux/uapi/nl80211.h> enum nl80211_reg_rule_flags */ enum reg_rule_flags { RRF_NO_OFDM = 1<<0, /* OFDM modulation not allowed */ RRF_NO_CCK = 1<<1, /* CCK modulation not allowed */ RRF_NO_INDOOR = 1<<2, /* indoor operation not allowed */ RRF_NO_OUTDOOR = 1<<3, /* outdoor operation not allowed */ RRF_DFS = 1<<4, /* DFS support is required to be * used */ RRF_PTP_ONLY = 1<<5, /* this is only for Point To Point * links */ RRF_PTMP_ONLY = 1<<6, /* this is only for Point To Multi * Point links */ RRF_PASSIVE_SCAN = 1<<7, /* passive scan is required */ RRF_NO_IBSS = 1<<8, /* IBSS is not allowed */ }; Historically we don't distinguish then a type of 802.11 device that initiates radiation except for the NO_IBSS rule, but that rule can be treated more as legacy given that the intent and motivation behind that was that some ODMs simply preferred an interpretation of regulatory rules and we *currently* don't use that in much places other than custom regulatory domains defined in the kernel. The PTP_ONLY and PTMP_ONLY are example other rules that could potentially have been used but to this day we haven't found a use case for it given that typical 802.11 devices are PTMP. I mention the NO_IBSS case as I'd like to try to avoid adding GO specific flag if we can figure out a way to make this more generic. At this point for example I think a more appropriate flag is in place: * NO_IR - cannot initiate radiation And this could in turn end up replacing most use cases of NO_IBSS and PASSIVE_SCAN givne that both of these imply we cannot initiate radiation unless specific things are done. I wonder if we can fold the GO flag into this and perhaps rename the NO_IBSS flag to the GO one. Also note that we should keep the flags in sync with the uapi nl80211 change. Please review these suggestions and let me know what you think. > 2. Indoor operation, where in bands requiring indoor operation, the > device must be programmed to detect indoor operation, or > - Device must be connected to AC Power Does anyone know if the FCC considers "indoor" if we power a device through the car on AC power through a converter ? Are we willing to ignore that corner case? > - Device must be under the control of a local master that is acting Interesting, so some APIs would be defined, I take it on hostapd to do the proper callbacks to 'slave' type of devices that depend on the local master(s). I could envision this being implemented on hostapd by expanding the AP interface type and associating 'slave' devices and callbacks for updates on AP device updates (channel changes, and so on). Is this work being planned? Luis > as an AP and is connected to AC Power. > > See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122 > > Add support for advertising Indoor-only and Concurrent-GO channel > properties. > > Signed-off-by: David Spinadel <david.spinadel@intel.com> > Signed-off-by: Ilan Peer <ilan.peer@intel.com> > --- > include/net/cfg80211.h | 6 ++++++ > include/uapi/linux/nl80211.h | 7 +++++++ > net/wireless/nl80211.c | 6 ++++++ > 3 files changed, 19 insertions(+) > > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h > index 7b0730a..f0badeb 100644 > --- a/include/net/cfg80211.h > +++ b/include/net/cfg80211.h > @@ -110,6 +110,10 @@ enum ieee80211_band { > * channel as the control or any of the secondary channels. > * This may be due to the driver or due to regulatory bandwidth > * restrictions. > + * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on this channel. > + * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this channel if > + * it's connected concurrently to a BSS on the same channel on 2.4 or > + * to a channel in the same UNII band on 5.2. > */ > enum ieee80211_channel_flags { > IEEE80211_CHAN_DISABLED = 1<<0, > @@ -121,6 +125,8 @@ enum ieee80211_channel_flags { > IEEE80211_CHAN_NO_OFDM = 1<<6, > IEEE80211_CHAN_NO_80MHZ = 1<<7, > IEEE80211_CHAN_NO_160MHZ = 1<<8, > + IEEE80211_CHAN_INDOOR_ONLY = 1<<9, > + IEEE80211_CHAN_GO_CONCURRENT = 1<<10, > }; > > #define IEEE80211_CHAN_NO_HT40 \ > diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h > index 861e5eb..09a4f6b 100644 > --- a/include/uapi/linux/nl80211.h > +++ b/include/uapi/linux/nl80211.h > @@ -2158,6 +2158,11 @@ enum nl80211_band_attr { > * @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not 80+80) channel > * using this channel as the primary or any of the secondary channels > * isn't possible > + * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is permitted > + * on this channel in current regulatory domain. > + * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is allowed on this > + * channel if it's connected concurrently to a BSS on the same channel on > + * 2.4 or to a channel in the same UNII band on 5.2. > * @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number > * currently defined > * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use > @@ -2176,6 +2181,8 @@ enum nl80211_frequency_attr { > NL80211_FREQUENCY_ATTR_NO_HT40_PLUS, > NL80211_FREQUENCY_ATTR_NO_80MHZ, > NL80211_FREQUENCY_ATTR_NO_160MHZ, > + NL80211_FREQUENCY_ATTR_INDOOR_ONLY, > + NL80211_FREQUENCY_ATTR_GO_CONCURRENT, > > /* keep last */ > __NL80211_FREQUENCY_ATTR_AFTER_LAST, > diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c > index 7dc3343..cf22b22 100644 > --- a/net/wireless/nl80211.c > +++ b/net/wireless/nl80211.c > @@ -563,6 +563,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg, > if ((chan->flags & IEEE80211_CHAN_NO_160MHZ) && > nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_160MHZ)) > goto nla_put_failure; > + if ((chan->flags & IEEE80211_CHAN_INDOOR_ONLY) && > + nla_put_flag(msg, NL80211_FREQUENCY_ATTR_INDOOR_ONLY)) > + goto nla_put_failure; > + if ((chan->flags & IEEE80211_CHAN_GO_CONCURRENT) && > + nla_put_flag(msg, NL80211_FREQUENCY_ATTR_GO_CONCURRENT)) > + goto nla_put_failure; > } > > if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER, > -- > 1.7.10.4 > -- 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
SGkgTHVpcywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBXaWxsIG5lZWQgc29tZSBtb3JlIHRp bWUgdG8gbG9vayBhdCB5b3VyIHN1Z2dlc3Rpb25zIGJlbG93IDopDQoNClJlZ2FyZHMsDQoNCkls YW4uDQoNCj4gDQo+IE9uIFR1ZSwgSnVsIDIsIDIwMTMgYXQgNToyOCBBTSwgSWxhbiBQZWVyIDxp bGFuLnBlZXJAaW50ZWwuY29tPiB3cm90ZToNCj4gPiBGcm9tOiBEYXZpZCBTcGluYWRlbCA8ZGF2 aWQuc3BpbmFkZWxAaW50ZWwuY29tPg0KPiA+DQo+ID4gVGhlIEZDQyBhcmUgY2xhcmlmeWluZyBz b21lIHNvZnQgY29uZmlndXJhdGlvbiByZXF1aXJlbWVudHMsIHdoaWNoDQo+ID4gYW1vbmcgb3Ro ZXIgaW5jbHVkZXMgdGhlIGZvbGxvd2luZzoNCj4gPg0KPiA+IDEuIENvbmN1cnJlbnQgR08gb3Bl cmF0aW9uLCB3aGVyZSBkZXZpY2VzIG1heSBzdXBwb3J0IFdGRCBpbg0KPiA+ICAgIGJhbmRzIHdo ZXJlIGFuIGF1dGhvcml6ZWQgbWFzdGVyIChmb3IgZXhhbXBsZSB3aXRoIERGUyBhbmQNCj4gPiAg ICBERlMgYW5kIHJhZGFyIGRldGVjdGlvbiBjYXBhYmlsaXR5IGluIHRoZSBVTklJIGJhbmQpIGlz IG9wZXJhdGluZy4NCj4gDQo+IElzIFdGRCBXaUZpIERpc3BsYXk/IElzIHRoZXJlIGFueSBzdHJp Y3QgcmVsYXRpb25zaGlwIGhlcmUgdG8gV0ZEIGFuZCBHTyBhbmQNCj4gcmVndWxhdG9yeSBvciBp cyBXRkQganVzdCBhIHVzZSBjYXNlIGV4YW1wbGU/IEFyZSB5b3UgaW5kaWNhdGluZyB0aGF0IHRo ZSBGQ0MNCj4gaXMgbWFraW5nIHNwZWNpYWwgcnVsZXMgZm9yIGNhc2VzIGluIHNwZWNpZmljIGJh bmRzIHdoZXJlIEdPICpjYW4qIGNvLWV4aXN0IHdpdGgNCj4gb3RoZXIgR08gZGV2aWNlcyA/DQoN CldGRCBpcyBXaUZpIGRpcmVjdCBpbiB0aGlzIGNvbnRleHQuIEkgZG8gbm90IHRoaW5rIHRoYXQg dGhlIEZDQyBhcmUgbWFraW5nIHNwZWNpYWwgcnVsZXMgb25seSBmb3IgR08gc3BlY2lmaWMgc2Nl bmFyaW9zIGJ1dCBhIG1vcmUgZ2VuZXJhbCBhcHByb2FjaCB3aGVyZSAiY29tcGxpYW5jZSBtYXkg YmUgYWNoaWV2ZWQgdW5kZXIgdGhlIGd1aWRhbmNlIG9mIGFuIGF1dGhvcml6ZWQgbWFzdGVyIi4g VGhlIFdGRC9QMlAgR08gY2FzZSBpcyBvbmx5IGFuIGV4YW1wbGUuDQoNCj4gWW91IGFubm90YXRl IHRoYXQgdGhpcyBpcyBzb21laG93IHJlbGF0ZWQgdG8gREZTLCBhcmUgdGhlIEdPIGNvbmN1cnJl bnQgcnVsZXMNCj4gdGhhdCB0aGUgRkNDIGlzIGRlZmluaW5nIG9ubHkgYXBwbGljYWJsZSB0byBE RlMgZnJlcXVlbmN5IHJhbmdlcz8gSWYgc28gd291bGQgaXQNCj4gc3VmZmljZSB0byBvbmx5IHVz ZSBERlMgZmxhZyA/IE9yIGFyZSB0aGVyZSBvdGhlciBzcGVjaWFsIGNhc2VzIGJleW9uZCBERlMN Cj4gZnJlcXVlbmN5IHJhbmdlcyB0aGF0IHRoZSBGQ0MgaXMgY3JlYXRpbmcgc3BlY2lhbCBoYW5k bGluZz8NCj4NCg0KREZTIHdhcyBnaXZlbiBoZXJlIGFzIGFuIGV4YW1wbGUuIEdlbmVyYWxseSwg SSB0aGluayB0aGF0IHRoZSBjaGFuZ2VzIHRoYXQgdGhlIEZDQyBhcmUgbWFraW5nIGFyZSB0YXJn ZXRpbmcgdmFyaW91cyBzY2VuYXJpb3MgYW5kIHZhcmlvdXMgUkYgZGV2aWNlcyAoZm9yIGV4YW1w bGUgdGhvc2UgZGVmaW5lZCBpbiBwYXJ0IDE1IG9mIENGUiB0aXRsZSA0NykuDQogDQo+IEFwYXJ0 IGZyb20gdGhlIEZDQyBhcmUgeW91IGF3YXJlIG9mIHNwZWNpYWwgY2FzZXMgaGFuZGxpbmcgZm9y IG90aGVyDQo+IHJlZ3VsYXRvcnkgYm9kaWVzIGF0IHRoaXMgcG9pbnQ/DQoNCk5vdCB0aGF0IEkn bSBhd2FyZSBvZi4gQWRkaW5nIHNvbWUgbW9yZSBwZW9wbGUgdGhhdCBtaWdodCBrbm93IG1vcmUu DQoNCj4gDQo+IE5vdGUgdGhhdCB3ZSBoYXZlIGFscmVhZHkgdGhlc2Ugb24gcmVnZGIuaCBmcm9t IENSREE6DQo+IA0KPiANCj4gLyoNCj4gICogVGhlIExpbnV4IG1hcCBkZWZpbmVkIGluIDxsaW51 eC91YXBpL25sODAyMTEuaD4gZW51bQ0KPiBubDgwMjExX3JlZ19ydWxlX2ZsYWdzICAqLyBlbnVt IHJlZ19ydWxlX2ZsYWdzIHsNCj4gICAgICAgICBSUkZfTk9fT0ZETSAgICAgICAgICAgICA9IDE8 PDAsIC8qIE9GRE0gbW9kdWxhdGlvbiBub3QgYWxsb3dlZCAqLw0KPiAgICAgICAgIFJSRl9OT19D Q0sgICAgICAgICAgICAgID0gMTw8MSwgLyogQ0NLIG1vZHVsYXRpb24gbm90IGFsbG93ZWQgKi8N Cj4gICAgICAgICBSUkZfTk9fSU5ET09SICAgICAgICAgICA9IDE8PDIsIC8qIGluZG9vciBvcGVy YXRpb24gbm90IGFsbG93ZWQgKi8NCj4gICAgICAgICBSUkZfTk9fT1VURE9PUiAgICAgICAgICA9 IDE8PDMsIC8qIG91dGRvb3Igb3BlcmF0aW9uIG5vdCBhbGxvd2VkICovDQo+ICAgICAgICAgUlJG X0RGUyAgICAgICAgICAgICAgICAgPSAxPDw0LCAvKiBERlMgc3VwcG9ydCBpcyByZXF1aXJlZCB0 byBiZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogdXNlZCAq Lw0KPiAgICAgICAgIFJSRl9QVFBfT05MWSAgICAgICAgICAgID0gMTw8NSwgLyogdGhpcyBpcyBv bmx5IGZvciBQb2ludCBUbyBQb2ludA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICogbGlua3MgKi8NCj4gICAgICAgICBSUkZfUFRNUF9PTkxZICAgICAgICAgICA9 IDE8PDYsIC8qIHRoaXMgaXMgb25seSBmb3IgUG9pbnQgVG8gTXVsdGkNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIFBvaW50IGxpbmtzICovDQo+ICAgICAgICAg UlJGX1BBU1NJVkVfU0NBTiAgICAgICAgPSAxPDw3LCAvKiBwYXNzaXZlIHNjYW4gaXMgcmVxdWly ZWQgKi8NCj4gICAgICAgICBSUkZfTk9fSUJTUyAgICAgICAgICAgICA9IDE8PDgsIC8qIElCU1Mg aXMgbm90IGFsbG93ZWQgKi8NCj4gfTsNCj4gDQo+IEhpc3RvcmljYWxseSB3ZSBkb24ndCBkaXN0 aW5ndWlzaCB0aGVuIGEgdHlwZSBvZiA4MDIuMTEgZGV2aWNlIHRoYXQgaW5pdGlhdGVzDQo+IHJh ZGlhdGlvbiBleGNlcHQgZm9yIHRoZSBOT19JQlNTIHJ1bGUsIGJ1dCB0aGF0IHJ1bGUgY2FuIGJl IHRyZWF0ZWQgbW9yZSBhcw0KPiBsZWdhY3kgZ2l2ZW4gdGhhdCB0aGUgaW50ZW50IGFuZCBtb3Rp dmF0aW9uIGJlaGluZCB0aGF0IHdhcyB0aGF0IHNvbWUgT0RNcw0KPiBzaW1wbHkgcHJlZmVycmVk IGFuIGludGVycHJldGF0aW9uIG9mIHJlZ3VsYXRvcnkgcnVsZXMgYW5kIHdlICpjdXJyZW50bHkq IGRvbid0DQo+IHVzZSB0aGF0IGluIG11Y2ggcGxhY2VzIG90aGVyIHRoYW4gY3VzdG9tIHJlZ3Vs YXRvcnkgZG9tYWlucyBkZWZpbmVkIGluIHRoZQ0KPiBrZXJuZWwuIFRoZSBQVFBfT05MWSBhbmQg UFRNUF9PTkxZIGFyZSBleGFtcGxlIG90aGVyIHJ1bGVzIHRoYXQgY291bGQNCj4gcG90ZW50aWFs bHkgaGF2ZSBiZWVuIHVzZWQgYnV0IHRvIHRoaXMgZGF5IHdlIGhhdmVuJ3QgZm91bmQgYSB1c2Ug Y2FzZSBmb3IgaXQNCj4gZ2l2ZW4gdGhhdCB0eXBpY2FsIDgwMi4xMSBkZXZpY2VzIGFyZSBQVE1Q Lg0KPiANCj4gSSBtZW50aW9uIHRoZSBOT19JQlNTIGNhc2UgYXMgSSdkIGxpa2UgdG8gdHJ5IHRv IGF2b2lkIGFkZGluZyBHTyBzcGVjaWZpYyBmbGFnIGlmDQo+IHdlIGNhbiBmaWd1cmUgb3V0IGEg d2F5IHRvIG1ha2UgdGhpcyBtb3JlIGdlbmVyaWMuIEF0IHRoaXMgcG9pbnQgZm9yIGV4YW1wbGUg SQ0KPiB0aGluayBhIG1vcmUgYXBwcm9wcmlhdGUgZmxhZyBpcyBpbiBwbGFjZToNCj4gDQoNCkFj dHVhbGx5LCB0aGlzIHNob3VsZCBiZSBhIEdPIG9ubHkgZmxhZywgbWVhbmluZyB0aGF0IHN1Y2gg cmVsYXhhdGlvbiBzaG91bGQgbm90IGJlIHZhbGlkIGZvciBzb2Z0IEFQLCBJQlNTIG9yIG1lc2gu IFRoZSBpbnRlbnRpb24gaGVyZSBpcyBsaW1pdCB0aGUgZXh0ZW5kIG9mIHRoZSBjZWxsLCBhbmQg cHJldmVudCBkYWlzeSBjaGFpbiBzY2VuYXJpb3MgKGFzc3VtZSB0aGF0IHlvdSBhbGxvdyBhIHNv ZnQgQVAgb24gc3VjaCBhIGNoYW5uZWwgYW5kIHRoYXQgYSBjbGllbnQgYXNzb2NpYXRlZCB0byBp dCwgYW5kIHRoZW4gdGhhdCBkZXZpY2UgY2FuIGFsc28gc3RhcnQgYSBzb2Z0IEFQIG9uIHRoZSBj aGFubmVsIC4uLi4pLiBBbnl3YXksIEknbGwgbmVlZCB0byBoYXZlIGFub3RoZXIgbG9vayBhdCB0 aGlzIChtaWdodCBiZSBwZXJtaXNzaWJsZSBmb3IgSUJTUyAuLi4pDQoNCj4gICAqIE5PX0lSIC0g Y2Fubm90IGluaXRpYXRlIHJhZGlhdGlvbg0KPiANCj4gQW5kIHRoaXMgY291bGQgaW4gdHVybiBl bmQgdXAgcmVwbGFjaW5nIG1vc3QgdXNlIGNhc2VzIG9mIE5PX0lCU1MgYW5kDQo+IFBBU1NJVkVf U0NBTiBnaXZuZSB0aGF0IGJvdGggb2YgdGhlc2UgaW1wbHkgd2UgY2Fubm90IGluaXRpYXRlIHJh ZGlhdGlvbg0KPiB1bmxlc3Mgc3BlY2lmaWMgdGhpbmdzIGFyZSBkb25lLiBJIHdvbmRlciBpZiB3 ZSBjYW4gZm9sZCB0aGUgR08gZmxhZyBpbnRvIHRoaXMgYW5kDQo+IHBlcmhhcHMgcmVuYW1lIHRo ZSBOT19JQlNTIGZsYWcgdG8gdGhlIEdPIG9uZS4NCj4gDQo+IEFsc28gbm90ZSB0aGF0IHdlIHNo b3VsZCBrZWVwIHRoZSBmbGFncyBpbiBzeW5jIHdpdGggdGhlIHVhcGkgbmw4MDIxMSBjaGFuZ2Uu DQo+IFBsZWFzZSByZXZpZXcgdGhlc2Ugc3VnZ2VzdGlvbnMgYW5kIGxldCBtZSBrbm93IHdoYXQg eW91IHRoaW5rLg0KPiANCg0KU3VyZS4gV2lsbCBuZWVkIHRvIHRha2UgYSBkZWVwZXIgbG9vayBh dCB0aGlzLg0KDQo+ID4gMi4gSW5kb29yIG9wZXJhdGlvbiwgd2hlcmUgaW4gYmFuZHMgcmVxdWly aW5nIGluZG9vciBvcGVyYXRpb24sIHRoZQ0KPiA+ICAgIGRldmljZSBtdXN0IGJlIHByb2dyYW1t ZWQgdG8gZGV0ZWN0IGluZG9vciBvcGVyYXRpb24sIG9yDQo+ID4gICAgLSBEZXZpY2UgbXVzdCBi ZSBjb25uZWN0ZWQgdG8gQUMgUG93ZXINCj4gDQo+IERvZXMgYW55b25lICBrbm93IGlmIHRoZSBG Q0MgY29uc2lkZXJzICJpbmRvb3IiIGlmIHdlIHBvd2VyIGEgZGV2aWNlIHRocm91Z2gNCj4gdGhl IGNhciBvbiBBQyBwb3dlciB0aHJvdWdoIGEgY29udmVydGVyID8gQXJlIHdlIHdpbGxpbmcgdG8g aWdub3JlIHRoYXQgY29ybmVyDQo+IGNhc2U/DQoNCk5vLiBBQyBwb3dlciBtZWFucyAibWFpbnMi IGFuZCBub3QgdGhyb3VnaCBwb3J0YWJsZSBEQyBjb252ZXJ0ZXJzIChzZWUgc2xpZGUgMTIgaW4g aHR0cHM6Ly9hcHBzLmZjYy5nb3YvZWFzL2NvbW1lbnRzL0dldFB1Ymxpc2hlZERvY3VtZW50Lmh0 bWw/aWQ9MzI3JnRuPSA1MjgxMjIpLiBJdCB3b3VsZCBiZSB1cCB0byB0aGUgdXNlciBzcGFjZSB0 byBpZGVudGlmeSB0aGUgZGV2aWNlIHR5cGUgZXRjLiBhbmQgaWRlbnRpZnkgaWYgdGhpcyBhIHRy dWx5IEFDIHBvd2VyZWQgQVAuDQoNCj4gDQo+ID4gICAgLSBEZXZpY2UgbXVzdCBiZSB1bmRlciB0 aGUgY29udHJvbCBvZiBhIGxvY2FsIG1hc3RlciB0aGF0IGlzIGFjdGluZw0KPiANCj4gSW50ZXJl c3RpbmcsIHNvIHNvbWUgQVBJcyB3b3VsZCBiZSBkZWZpbmVkLCBJIHRha2UgaXQgb24gaG9zdGFw ZCB0byBkbyB0aGUNCj4gcHJvcGVyIGNhbGxiYWNrcyB0byAnc2xhdmUnIHR5cGUgb2YgZGV2aWNl cyB0aGF0IGRlcGVuZCBvbiB0aGUgbG9jYWwgbWFzdGVyKHMpLiBJDQo+IGNvdWxkIGVudmlzaW9u IHRoaXMgYmVpbmcgaW1wbGVtZW50ZWQgb24gaG9zdGFwZCBieSBleHBhbmRpbmcgdGhlIEFQDQo+ IGludGVyZmFjZSB0eXBlIGFuZCBhc3NvY2lhdGluZyAnc2xhdmUnIGRldmljZXMgYW5kIGNhbGxi YWNrcyBmb3IgdXBkYXRlcyBvbiBBUA0KPiBkZXZpY2UgdXBkYXRlcyAoY2hhbm5lbCBjaGFuZ2Vz LCBhbmQgc28gb24pLiBJcyB0aGlzIHdvcmsgYmVpbmcgcGxhbm5lZD8NCg0KWWVzLiBXZSBoYXZl IHBsYW5zIHRvIGluY29ycG9yYXRlIG1vcmUgbG9naWMgdG8gaG9zdGFwIChjdXJyZW50bHkgaW50 byB3cGFfc3VwcGxpY2FudCBmb3IgUDJQIHVzZSBjYXNlcykuDQoNCg0K -- 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, Jul 10, 2013 at 3:43 AM, Peer, Ilan <ilan.peer@intel.com> wrote: >> On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote: >> > From: David Spinadel <david.spinadel@intel.com> >> > >> > The FCC are clarifying some soft configuration requirements, which >> > among other includes the following: >> > >> > 1. Concurrent GO operation, where devices may support WFD in >> > bands where an authorized master (for example with DFS and >> > DFS and radar detection capability in the UNII band) is operating. >> >> Is WFD WiFi Display? Is there any strict relationship here to WFD and GO and >> regulatory or is WFD just a use case example? Are you indicating that the FCC >> is making special rules for cases in specific bands where GO *can* co-exist with >> other GO devices ? > > WFD is WiFi direct in this context. I do not think that the FCC are making special rules only for GO specific scenarios but a more general approach where "compliance may be achieved under the guidance of an authorized master". The WFD/P2P GO case is only an example. OK then I think cullular base station regulatory hints might be another example. In fact I believe I am looking at the information you might be using as reference. I am looking at public draft edit for FCC KDB 594280: https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122 The original KDB: http://transition.fcc.gov/oet/ea/presentations/files/apr11/3b.SoftwareConfigurationControl-RDJS.pdf Specifically in the above document, the draft edit, I am looking at page 12. That actually references WiFi Direct precisely and considers the case that a GO may need to move out of its channel if its master device its using to configure itself also switches channels. Given that cellular base station hints could also technically be used this also would need to be considered for cellular base stations. But also note on page 14 it states clearly: "Mobile Country Codes (MCC) or Mobile Network Codes (MNC) are not acceptable for programming host compliance" So it seems cellular base station hints are simply not allowed by the FCC (unless specific approval is requested / revised). Even if the FCC allowed for it I believe an API would need to be provided should cellular base stations have a case where they may stop operating as well similar to DFS. BTW in future iterations of patches I'd appreciate if you can include the above references to documentation given that we've pulled them up now. >> You annotate that this is somehow related to DFS, are the GO concurrent rules >> that the FCC is defining only applicable to DFS frequency ranges? If so would it >> suffice to only use DFS flag ? Or are there other special cases beyond DFS >> frequency ranges that the FCC is creating special handling? >> > > DFS was given here as an example. Generally, I think that the changes that the FCC are making are targeting various scenarios and various RF devices (for example those defined in part 15 of CFR title 47). OK thanks. Things are clear now that I see the document that you might be referring to. >> Apart from the FCC are you aware of special cases handling for other >> regulatory bodies at this point? > > Not that I'm aware of. Adding some more people that might know more. Hey folks, anyone? :) >> Note that we have already these on regdb.h from CRDA: >> >> >> /* >> * The Linux map defined in <linux/uapi/nl80211.h> enum >> nl80211_reg_rule_flags */ enum reg_rule_flags { >> RRF_NO_OFDM = 1<<0, /* OFDM modulation not allowed */ >> RRF_NO_CCK = 1<<1, /* CCK modulation not allowed */ >> RRF_NO_INDOOR = 1<<2, /* indoor operation not allowed */ >> RRF_NO_OUTDOOR = 1<<3, /* outdoor operation not allowed */ >> RRF_DFS = 1<<4, /* DFS support is required to be >> * used */ >> RRF_PTP_ONLY = 1<<5, /* this is only for Point To Point >> * links */ >> RRF_PTMP_ONLY = 1<<6, /* this is only for Point To Multi >> * Point links */ >> RRF_PASSIVE_SCAN = 1<<7, /* passive scan is required */ >> RRF_NO_IBSS = 1<<8, /* IBSS is not allowed */ >> }; >> >> Historically we don't distinguish then a type of 802.11 device that initiates >> radiation except for the NO_IBSS rule, but that rule can be treated more as >> legacy given that the intent and motivation behind that was that some ODMs >> simply preferred an interpretation of regulatory rules and we *currently* don't >> use that in much places other than custom regulatory domains defined in the >> kernel. The PTP_ONLY and PTMP_ONLY are example other rules that could >> potentially have been used but to this day we haven't found a use case for it >> given that typical 802.11 devices are PTMP. >> >> I mention the NO_IBSS case as I'd like to try to avoid adding GO specific flag if >> we can figure out a way to make this more generic. At this point for example I >> think a more appropriate flag is in place: >> > > Actually, this should be a GO only flag, meaning that such relaxation should not be valid for soft AP, IBSS or mesh. The intention here is limit the extend of the cell, and prevent daisy chain scenarios (assume that you allow a soft AP on such a channel and that a client associated to it, and then that device can also start a soft AP on the channel ....). Anyway, I'll need to have another look at this (might be permissible for IBSS ...) Based on the documentation I reviewed and your proposal it'd seem to me that we can distinguish GO on the upper layers and determine if a channel is DFS or not by just the DFS flag. The next hint you'd need is if the GO got regulatory information from a master somehow, no? That is I am not seeing a need for a new flag at this point in wireless-regdb, given also I mentioned another type of case for regulatory hints technically possible (cellular base station hints but it seems only allowed with exceptional review by the FCC). I take it what you want to enable here is GO operation on DFS channels and use country IEs to determine if you can use GO, but if you do have GO enabled then you'd want hooks to not daisy chain, ack? >> > 2. Indoor operation, where in bands requiring indoor operation, the >> > device must be programmed to detect indoor operation, or >> > - Device must be connected to AC Power >> >> Does anyone know if the FCC considers "indoor" if we power a device through >> the car on AC power through a converter ? Are we willing to ignore that corner >> case? > > No. AC power means "mains" and not through portable DC converters (see slide 12 in https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn= 528122). It would be up to the user space to identify the device type etc. and identify if this a truly AC powered AP. OK thanks for the clarification. I wonder if we can distinguish between the two in userspace today. I'm happy to start pegging frequency ranges as indoor-only on wireless-regdb even if we don't have the userspace APIs to annotate when a device is indoor or not yet. Patches welcomed then. >> > - Device must be under the control of a local master that is acting >> >> Interesting, so some APIs would be defined, I take it on hostapd to do the >> proper callbacks to 'slave' type of devices that depend on the local master(s). I >> could envision this being implemented on hostapd by expanding the AP >> interface type and associating 'slave' devices and callbacks for updates on AP >> device updates (channel changes, and so on). Is this work being planned? > > Yes. We have plans to incorporate more logic to hostap (currently into wpa_supplicant for P2P use cases). Sweet. 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
Hi Luis, Once again, thanks for the comments :) Regards, Ilan. > >> Is WFD WiFi Display? Is there any strict relationship here to WFD and > >> GO and regulatory or is WFD just a use case example? Are you > >> indicating that the FCC is making special rules for cases in specific > >> bands where GO *can* co-exist with other GO devices ? > > > > WFD is WiFi direct in this context. I do not think that the FCC are making > special rules only for GO specific scenarios but a more general approach where > "compliance may be achieved under the guidance of an authorized master". > The WFD/P2P GO case is only an example. > > OK then I think cullular base station regulatory hints might be another example. > In fact I believe I am looking at the information you might be using as > reference. I am looking at public draft edit for FCC KDB 594280: > > https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=5 > 28122 This is indeed the relevant document. > > The original KDB: > > http://transition.fcc.gov/oet/ea/presentations/files/apr11/3b.SoftwareConfigur > ationControl-RDJS.pdf > > Specifically in the above document, the draft edit, I am looking at page 12. That > actually references WiFi Direct precisely and considers the case that a GO may > need to move out of its channel if its master device its using to configure itself > also switches channels. Given that cellular base station hints could also > technically be used this also would need to be considered for cellular base > stations. But also note on page 14 it states clearly: > > "Mobile Country Codes (MCC) or Mobile Network Codes > (MNC) are not acceptable for programming host compliance" > > So it seems cellular base station hints are simply not allowed by the FCC (unless > specific approval is requested / revised). Even if the FCC allowed for it I believe > an API would need to be provided should cellular base stations have a case > where they may stop operating as well similar to DFS. > > BTW in future iterations of patches I'd appreciate if you can include the above > references to documentation given that we've pulled them up now. > Sure. > >> You annotate that this is somehow related to DFS, are the GO > >> concurrent rules that the FCC is defining only applicable to DFS > >> frequency ranges? If so would it suffice to only use DFS flag ? Or > >> are there other special cases beyond DFS frequency ranges that the FCC is > creating special handling? > >> > > > > DFS was given here as an example. Generally, I think that the changes that > the FCC are making are targeting various scenarios and various RF devices (for > example those defined in part 15 of CFR title 47). > > OK thanks. Things are clear now that I see the document that you might be > referring to. > > >> Apart from the FCC are you aware of special cases handling for other > >> regulatory bodies at this point? > > > > Not that I'm aware of. Adding some more people that might know more. > > Hey folks, anyone? :) > > > > > Actually, this should be a GO only flag, meaning that such relaxation > > should not be valid for soft AP, IBSS or mesh. The intention here is > > limit the extend of the cell, and prevent daisy chain scenarios > > (assume that you allow a soft AP on such a channel and that a client > > associated to it, and then that device can also start a soft AP on the > > channel ....). Anyway, I'll need to have another look at this (might > > be permissible for IBSS ...) > > Based on the documentation I reviewed and your proposal it'd seem to me that > we can distinguish GO on the upper layers and determine if a channel is DFS or > not by just the DFS flag. The next hint you'd need is if the GO got regulatory > information from a master somehow, no? This should also be handled by user space, based on the device type/sub type of the local device directly, or indirectly through other means such a managed interface associating with an AP that it's device type value is 6 etc. > That is I am not seeing a need for a new flag at this point in wireless-regdb, > given also I mentioned another type of case for regulatory hints technically > possible (cellular base station hints but it seems only allowed with exceptional > review by the FCC). > > I take it what you want to enable here is GO operation on DFS channels and use > country IEs to determine if you can use GO, but if you do have GO enabled then > you'd want hooks to not daisy chain, ack? Currently, we do not intend to base the relaxation on the country IE directly, but base it on the fact that if there is a managed connection to an AP who's not a mobile device (assuming that it is an authorized master), than the channel used by the managed connection is valid for use (as long as the managed interface is connected to the AP on the channel). > > >> > 2. Indoor operation, where in bands requiring indoor operation, the > >> > device must be programmed to detect indoor operation, or > >> > - Device must be connected to AC Power > >> > >> Does anyone know if the FCC considers "indoor" if we power a device > >> through the car on AC power through a converter ? Are we willing to > >> ignore that corner case? > > > > No. AC power means "mains" and not through portable DC converters (see > slide 12 in > https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn= > 528122). It would be up to the user space to identify the device type etc. and > identify if this a truly AC powered AP. > > OK thanks for the clarification. I wonder if we can distinguish between the two > in userspace today. I'm happy to start pegging frequency ranges as indoor-only > on wireless-regdb even if we don't have the userspace APIs to annotate when a > device is indoor or not yet. Patches welcomed then. > Again, we are going to use the device type/sub type as an indication to an AP being AC powered. > >> > - Device must be under the control of a local master that is > >> > acting > >> > >> Interesting, so some APIs would be defined, I take it on hostapd to > >> do the proper callbacks to 'slave' type of devices that depend on the > >> local master(s). I could envision this being implemented on hostapd > >> by expanding the AP interface type and associating 'slave' devices > >> and callbacks for updates on AP device updates (channel changes, and so > on). Is this work being planned? > > Note sure that I follow ... However, we do intend to add this type of support to hostap. > > Yes. We have plans to incorporate more logic to hostap (currently into > wpa_supplicant for P2P use cases). > > Sweet. > > Luis
On Wed, Jul 17, 2013 at 11:47 AM, Peer, Ilan <ilan.peer@intel.com> wrote: > On some day Luis wrote: > >> Based on the documentation I reviewed and your proposal it'd seem to me that >> we can distinguish GO on the upper layers and determine if a channel is DFS or >> not by just the DFS flag. The next hint you'd need is if the GO got regulatory >> information from a master somehow, no? > > This should also be handled by user space, based on the device type/sub type of the local device directly, or > indirectly through other means such a managed interface associating with an AP that it's device type > value is 6 etc. This seems reasonable but we need to also consider state machine changes possible on the channel the GO is on as well and there are different reasons for the channel to change: * beacon hint - nl80211_send_beacon_hint_event() * regulatory change - nl80211_send_reg_change_event() The beacon hint multicast group message sends the channel prior to the beacon hint and after. The regulatory change event currently isn't as atomic and only provides the the fact that regulatory domain state machine has incurred a change. In this case it may make sense to send all wiphy information and have hostapd verify if a change has occurred on the channel. >> That is I am not seeing a need for a new flag at this point in wireless-regdb, >> given also I mentioned another type of case for regulatory hints technically >> possible (cellular base station hints but it seems only allowed with exceptional >> review by the FCC). >> >> I take it what you want to enable here is GO operation on DFS channels and use >> country IEs to determine if you can use GO, but if you do have GO enabled then >> you'd want hooks to not daisy chain, ack? > > Currently, we do not intend to base the relaxation on the country IE directly, Its still a possibility so it should be handled and we should consider it on core regulatory. One possible solution might be to not enable GO unless the the NL80211_ATTR_REG_INITIATOR was something appropriate for the wiphy. > but base it on the fact that if > there is a managed connection to an AP who's not a mobile device (assuming that it is an authorized master), How do you intend on verifying a device that has associated to an AP, that that AP is not a mobile device, ie that it fits this "authorized master" category ? > than the channel used by the managed connection is valid for use (as long as the managed interface > is connected to the AP on the channel). Makes sense. 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/include/net/cfg80211.h b/include/net/cfg80211.h index 7b0730a..f0badeb 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -110,6 +110,10 @@ enum ieee80211_band { * channel as the control or any of the secondary channels. * This may be due to the driver or due to regulatory bandwidth * restrictions. + * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on this channel. + * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this channel if + * it's connected concurrently to a BSS on the same channel on 2.4 or + * to a channel in the same UNII band on 5.2. */ enum ieee80211_channel_flags { IEEE80211_CHAN_DISABLED = 1<<0, @@ -121,6 +125,8 @@ enum ieee80211_channel_flags { IEEE80211_CHAN_NO_OFDM = 1<<6, IEEE80211_CHAN_NO_80MHZ = 1<<7, IEEE80211_CHAN_NO_160MHZ = 1<<8, + IEEE80211_CHAN_INDOOR_ONLY = 1<<9, + IEEE80211_CHAN_GO_CONCURRENT = 1<<10, }; #define IEEE80211_CHAN_NO_HT40 \ diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 861e5eb..09a4f6b 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -2158,6 +2158,11 @@ enum nl80211_band_attr { * @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not 80+80) channel * using this channel as the primary or any of the secondary channels * isn't possible + * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is permitted + * on this channel in current regulatory domain. + * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is allowed on this + * channel if it's connected concurrently to a BSS on the same channel on + * 2.4 or to a channel in the same UNII band on 5.2. * @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number * currently defined * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use @@ -2176,6 +2181,8 @@ enum nl80211_frequency_attr { NL80211_FREQUENCY_ATTR_NO_HT40_PLUS, NL80211_FREQUENCY_ATTR_NO_80MHZ, NL80211_FREQUENCY_ATTR_NO_160MHZ, + NL80211_FREQUENCY_ATTR_INDOOR_ONLY, + NL80211_FREQUENCY_ATTR_GO_CONCURRENT, /* keep last */ __NL80211_FREQUENCY_ATTR_AFTER_LAST, diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 7dc3343..cf22b22 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -563,6 +563,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg, if ((chan->flags & IEEE80211_CHAN_NO_160MHZ) && nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_160MHZ)) goto nla_put_failure; + if ((chan->flags & IEEE80211_CHAN_INDOOR_ONLY) && + nla_put_flag(msg, NL80211_FREQUENCY_ATTR_INDOOR_ONLY)) + goto nla_put_failure; + if ((chan->flags & IEEE80211_CHAN_GO_CONCURRENT) && + nla_put_flag(msg, NL80211_FREQUENCY_ATTR_GO_CONCURRENT)) + goto nla_put_failure; } if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,