| Message ID | 1390818118-27261-7-git-send-email-ilan.peer@intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Mon, Jan 27, 2014 at 12:21:58PM +0200, Ilan Peer wrote: > Allow active scanning and frame injection on channels marked with > IEEE80211_CHAN_NO_IR iff the channel is also marked with > IEEE80211_CHAN_INDOOR_ONLY and the wireless core thinks that it > operates in an indoor environment. > > Signed-off-by: Ilan Peer <ilan.peer@intel.com> I don't see why being indoor should allow to override the NO-IR flag. I do see however why being indoor should enable to IR if you are IR if you have the indoor flag. Enabling to IR if you are indoor for all NO-IR channels is... pretty permissive I do not see the correlation. 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
I'll abandon this change ... Thanks, Ilan. > -----Original Message----- > From: Luis R. Rodriguez [mailto:mcgrof@gmail.com] On Behalf Of Luis R. > Rodriguez > Sent: Wednesday, February 19, 2014 02:15 > To: Peer, Ilan > Cc: linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org > Subject: Re: [PATCH v3 6/6] mac80211: Enable initiating radiation on indoor > channels > > On Mon, Jan 27, 2014 at 12:21:58PM +0200, Ilan Peer wrote: > > Allow active scanning and frame injection on channels marked with > > IEEE80211_CHAN_NO_IR iff the channel is also marked with > > IEEE80211_CHAN_INDOOR_ONLY and the wireless core thinks that it > > operates in an indoor environment. > > > > Signed-off-by: Ilan Peer <ilan.peer@intel.com> > > I don't see why being indoor should allow to override the NO-IR flag. I do see > however why being indoor should enable to IR if you are IR if you have the > indoor flag. Enabling to IR if you are indoor for all NO-IR channels is... pretty > permissive I do not see the correlation. > Make sense. I did not have such relaxations defined, just thought that similar relaxations could also be used in cases of scanning etc. but I guess this is not always true. -- 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, Feb 19, 2014 at 03:28:29PM +0000, Peer, Ilan wrote: > I'll abandon this change ... Wait lets talk about this. > > -----Original Message----- > > From: Luis R. Rodriguez [mailto:mcgrof@gmail.com] On Behalf Of Luis R. > > Rodriguez > > Sent: Wednesday, February 19, 2014 02:15 > > To: Peer, Ilan > > Cc: linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org > > Subject: Re: [PATCH v3 6/6] mac80211: Enable initiating radiation on indoor > > channels > > > > On Mon, Jan 27, 2014 at 12:21:58PM +0200, Ilan Peer wrote: > > > Allow active scanning and frame injection on channels marked with > > > IEEE80211_CHAN_NO_IR iff the channel is also marked with > > > IEEE80211_CHAN_INDOOR_ONLY and the wireless core thinks that it > > > operates in an indoor environment. > > > > > > Signed-off-by: Ilan Peer <ilan.peer@intel.com> > > > > I don't see why being indoor should allow to override the NO-IR flag. I do see > > however why being indoor should enable to IR if you are IR if you have the > > indoor flag. Enabling to IR if you are indoor for all NO-IR channels is... pretty > > permissive I do not see the correlation. > > > > Make sense. I did not have such relaxations defined, just thought that > similar relaxations could also be used in cases of scanning etc. but I > guess this is not always true. The original beacon hint mechanism is very expansive to all beacons on non 5 GHz DFS channels and non 2.4 channel 12 or 13. If a vendor can possibly not like that beacon hint implementation as its too permissive (and I don't think it is) but they do want to trust beacon hints from APs in the case you are describing then you can enable a new feature flag to distinguish this. The beacon infrastructure code would then ignore the regular beacon hints on devices that don't have the old flag, but would trust this new form of beacon hint. If a device supported the old all inclusive flag they'd trust both. You'd have to update the kdocs for the old one, and likely add a new routine similar to regulatory_hint_found_beacon(). I'm not sure its worth it though, I'd rather push vendors to consider first using the regular becaon hint mechanism and trusting it. Maybe devices that want this new functionality you are trusting should implicate revising trusting beacon hint mechanism ? Luis
> > On Wed, Feb 19, 2014 at 03:28:29PM +0000, Peer, Ilan wrote: > > I'll abandon this change ... > > Wait lets talk about this. > > > > I don't see why being indoor should allow to override the NO-IR > > > flag. I do see however why being indoor should enable to IR if you > > > are IR if you have the indoor flag. Enabling to IR if you are indoor > > > for all NO-IR channels is... pretty permissive I do not see the correlation. > > > > > > > Make sense. I did not have such relaxations defined, just thought that > > similar relaxations could also be used in cases of scanning etc. but I > > guess this is not always true. > > The original beacon hint mechanism is very expansive to all beacons on non 5 > GHz DFS channels and non 2.4 channel > 12 or 13. If a vendor can possibly not like that beacon hint implementation as > its too permissive (and I don't think it is) but they do want to trust beacon > hints from APs in the case you are describing then you can enable a new > feature flag to distinguish this. The beacon infrastructure code would then > ignore the regular beacon hints on devices that don't have the old flag, but > would trust this new form of beacon hint. If a device supported the old all > inclusive flag they'd trust both. You'd have to update the kdocs for the old > one, and likely add a new routine similar to regulatory_hint_found_beacon(). > This make sense (also got a direct answer from our regulatory folks on this ... finally ;)) > I'm not sure its worth it though, I'd rather push vendors to consider first using > the regular becaon hint mechanism and trusting it. Maybe devices that want > this new functionality you are trusting should implicate revising trusting > beacon hint mechanism ? > Our regulatory people said that a similar approach is WIP in the FCC where they are willing to use a similar relaxation as the beacons hints but with some limitations such as having at least a number of APs operating on the channel etc. If its ok with you I prefer to leave things as is for now. Regards, Ilan. -- 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, Feb 19, 2014 at 11:58 PM, Peer, Ilan <ilan.peer@intel.com> wrote: >> >> On Wed, Feb 19, 2014 at 03:28:29PM +0000, Peer, Ilan wrote: >> > I'll abandon this change ... >> >> Wait lets talk about this. >> >> > > I don't see why being indoor should allow to override the NO-IR >> > > flag. I do see however why being indoor should enable to IR if you >> > > are IR if you have the indoor flag. Enabling to IR if you are indoor >> > > for all NO-IR channels is... pretty permissive I do not see the correlation. >> > > >> > >> > Make sense. I did not have such relaxations defined, just thought that >> > similar relaxations could also be used in cases of scanning etc. but I >> > guess this is not always true. >> >> The original beacon hint mechanism is very expansive to all beacons on non 5 >> GHz DFS channels and non 2.4 channel >> 12 or 13. If a vendor can possibly not like that beacon hint implementation as >> its too permissive (and I don't think it is) but they do want to trust beacon >> hints from APs in the case you are describing then you can enable a new >> feature flag to distinguish this. The beacon infrastructure code would then >> ignore the regular beacon hints on devices that don't have the old flag, but >> would trust this new form of beacon hint. If a device supported the old all >> inclusive flag they'd trust both. You'd have to update the kdocs for the old >> one, and likely add a new routine similar to regulatory_hint_found_beacon(). >> > > This make sense (also got a direct answer from our regulatory folks on this ... finally ;)) Oh wow, are they on the wireless-regdb list? >> I'm not sure its worth it though, I'd rather push vendors to consider first using >> the regular becaon hint mechanism and trusting it. Maybe devices that want >> this new functionality you are trusting should implicate revising trusting >> beacon hint mechanism ? >> > > Our regulatory people said that a similar approach is WIP in the FCC where they are willing to use a similar relaxation as the beacons hints but with some limitations such as having at least a number of APs operating on the channel etc. That seems to be biased towards populated spectrum areas. I suspect the conflict here would be not wanting to trust GO's, but consider this: why not? GO's won't IR unless they have some heuristics like the one you are adding to determine its OK to IR. Furthermore our own beacon hint infrastructure in the kernel does check to ensure we don't trust mesh or IBSS, we ensure its from an ESS, ie WLAN_CAPABILITY_ESS: if (res->pub.capability & WLAN_CAPABILITY_ESS) regulatory_hint_found_beacon(wiphy, channel, gfp); BTW I just updated our documentation for this, here: http://wireless.kernel.org/en/developers/Regulatory/processing_rules#Beacon_hints Please feel free to socialize this algorithm with the FCC PHBs and other regulatory folks to see if they can see any loopholes or would prefer any other considerations or APIs to be extended. I think this is pretty safe and I'd love to know of issues that people could be concerned over this. > If its ok with you I prefer to leave things as is for now. You mean you'll drop this patch for sure then while we hope a socialization of our algorithm can be proven as reasonable for Intel to embrace :) ? 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
> >> The original beacon hint mechanism is very expansive to all beacons > >> on non 5 GHz DFS channels and non 2.4 channel > >> 12 or 13. If a vendor can possibly not like that beacon hint > >> implementation as its too permissive (and I don't think it is) but > >> they do want to trust beacon hints from APs in the case you are > >> describing then you can enable a new feature flag to distinguish > >> this. The beacon infrastructure code would then ignore the regular > >> beacon hints on devices that don't have the old flag, but would trust > >> this new form of beacon hint. If a device supported the old all > >> inclusive flag they'd trust both. You'd have to update the kdocs for the old > one, and likely add a new routine similar to regulatory_hint_found_beacon(). > >> > > > > This make sense (also got a direct answer from our regulatory folks on > > this ... finally ;)) > > Oh wow, are they on the wireless-regdb list? Not sure ... I asked them to join some time ago ... > > >> I'm not sure its worth it though, I'd rather push vendors to consider > >> first using the regular becaon hint mechanism and trusting it. Maybe > >> devices that want this new functionality you are trusting should > >> implicate revising trusting beacon hint mechanism ? > >> > > > > Our regulatory people said that a similar approach is WIP in the FCC where > they are willing to use a similar relaxation as the beacons hints but with some > limitations such as having at least a number of APs operating on the channel > etc. > > That seems to be biased towards populated spectrum areas. I suspect the > conflict here would be not wanting to trust GO's, but consider Actually no. The concern is more to the increasing number of APs that are bought it one country and then used in some other country, thus possibly violating regulatory. AFAIK, one of the options they are considering is to allow such relaxation if beacon from several (>1) different BSS was received. > this: why not? GO's won't IR unless they have some heuristics like the one > you are adding to determine its OK to IR. Furthermore our own beacon hint > infrastructure in the kernel does check to ensure we don't trust mesh or > IBSS, we ensure its from an ESS, ie WLAN_CAPABILITY_ESS: > > if (res->pub.capability & WLAN_CAPABILITY_ESS) > regulatory_hint_found_beacon(wiphy, channel, gfp); > > BTW I just updated our documentation for this, here: > > http://wireless.kernel.org/en/developers/Regulatory/processing_rules#Bea > con_hints > > Please feel free to socialize this algorithm with the FCC PHBs and other > regulatory folks to see if they can see any loopholes or would prefer any > other considerations or APIs to be extended. I think this is pretty safe and I'd > love to know of issues that people could be concerned over this. > Sure, but as I wrote above, the FCC does not consider a beacon of a single BSS sufficient and would like better assurance that it is safe to enable IR. Will update once I get some answers. > > If its ok with you I prefer to leave things as is for now. > > You mean you'll drop this patch for sure then while we hope a socialization of > our algorithm can be proven as reasonable for Intel to embrace :) ? DSTM ;) ... anyway, I'll drop it since I do not see the benefit and since your argument about indoor not implying IR is true and I'm waiting for answers if this is also allowed another the NO_IR relaxations. Regards, Ilan.
On Sat, Feb 22, 2014 at 10:55 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
> AFAIK, one of the options they are considering is to allow such relaxation if beacon from several (>1) different BSS was received.
This can just go upstream, ie the existing implementation can be
modified to account for this for FCC only.
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
PiANCj4gT24gU2F0LCBGZWIgMjIsIDIwMTQgYXQgMTA6NTUgQU0sIFBlZXIsIElsYW4gPGlsYW4u cGVlckBpbnRlbC5jb20+IHdyb3RlOg0KPiA+IEFGQUlLLCBvbmUgb2YgdGhlIG9wdGlvbnMgdGhl eSBhcmUgY29uc2lkZXJpbmcgaXMgdG8gYWxsb3cgc3VjaCByZWxheGF0aW9uIGlmDQo+IGJlYWNv biBmcm9tIHNldmVyYWwgKD4xKSBkaWZmZXJlbnQgQlNTIHdhcyByZWNlaXZlZC4NCj4gDQo+IFRo aXMgY2FuIGp1c3QgZ28gdXBzdHJlYW0sIGllIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBj YW4gYmUgbW9kaWZpZWQgdG8NCj4gYWNjb3VudCBmb3IgdGhpcyBmb3IgRkNDIG9ubHkuDQo+IA0K DQpZZXAgLi4uIHRoaXMgaXMgV0lQIHdpdGggdGhlIHJlZ3VsYXRvcnkgcGVvcGxlIC4uLiBuZWVk IHRvIGdldCBzb21lIGFuc3dlcnMgLi4uDQoNCklsYW4uIA0K -- 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 Sat, Feb 22, 2014 at 11:23 PM, Peer, Ilan <ilan.peer@intel.com> wrote: >> >> On Sat, Feb 22, 2014 at 10:55 AM, Peer, Ilan <ilan.peer@intel.com> wrote: >> > AFAIK, one of the options they are considering is to allow such relaxation if >> beacon from several (>1) different BSS was received. >> >> This can just go upstream, ie the existing implementation can be modified to >> account for this for FCC only. >> > > Yep ... this is WIP with the regulatory people ... need to get some answers ... Tell them I said hi. 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/mac80211/scan.c b/net/mac80211/scan.c index 88c8161..e78aa29 100644 --- a/net/mac80211/scan.c +++ b/net/mac80211/scan.c @@ -527,8 +527,8 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata, /* We need to ensure power level is at max for scanning. */ ieee80211_hw_config(local, 0); - if ((req->channels[0]->flags & - IEEE80211_CHAN_NO_IR) || + if (!regulatory_ir_allowed(local->hw.wiphy, + req->channels[0]) || !local->scan_req->n_ssids) { next_delay = IEEE80211_PASSIVE_CHANNEL_TIME; } else { @@ -568,13 +568,14 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata, } static unsigned long -ieee80211_scan_get_channel_time(struct ieee80211_channel *chan) +ieee80211_scan_get_channel_time(struct wiphy *wiphy, + struct ieee80211_channel *chan) { /* * TODO: channel switching also consumes quite some time, * add that delay as well to get a better estimation */ - if (chan->flags & IEEE80211_CHAN_NO_IR) + if (!regulatory_ir_allowed(wiphy, chan)) return IEEE80211_PASSIVE_CHANNEL_TIME; return IEEE80211_PROBE_DELAY + IEEE80211_CHANNEL_TIME; } @@ -588,6 +589,7 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local, struct ieee80211_sub_if_data *sdata; struct ieee80211_channel *next_chan; enum mac80211_scan_state next_scan_state; + struct wiphy *wiphy = local->hw.wiphy; /* * check if at least one STA interface is associated, @@ -623,7 +625,8 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local, */ bad_latency = time_after(jiffies + - ieee80211_scan_get_channel_time(next_chan), + ieee80211_scan_get_channel_time(wiphy, + next_chan), local->leave_oper_channel_time + HZ / 8); if (associated && !tx_empty) { @@ -698,7 +701,7 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local, * * In any case, it is not necessary for a passive scan. */ - if (chan->flags & IEEE80211_CHAN_NO_IR || + if (!regulatory_ir_allowed(local->hw.wiphy, chan) || !local->scan_req->n_ssids) { *next_delay = IEEE80211_PASSIVE_CHANNEL_TIME; local->next_scan_state = SCAN_DECISION; diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 27c990b..171d0c5 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1732,7 +1732,8 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb, * radar detection by itself. We can do that later by adding a * monitor flag interfaces used for AP support. */ - if ((chan->flags & (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR))) + if (!regulatory_ir_allowed(local->hw.wiphy, chan) || + chan->flags & IEEE80211_CHAN_RADAR) goto fail_rcu; ieee80211_xmit(sdata, skb, chan->band);
Allow active scanning and frame injection on channels marked with IEEE80211_CHAN_NO_IR iff the channel is also marked with IEEE80211_CHAN_INDOOR_ONLY and the wireless core thinks that it operates in an indoor environment. Signed-off-by: Ilan Peer <ilan.peer@intel.com> --- net/mac80211/scan.c | 15 +++++++++------ net/mac80211/tx.c | 3 ++- 2 files changed, 11 insertions(+), 7 deletions(-)