Add support for WLAN driver to report unsafe frequency range(s). User
space should move SAP/P2P-GO out of those unsafe frequency range(s).
User space may decide to continue operation on unsafe frequency but in
such case there might be impact on performance because of interference.
Signed-off-by: Rajesh Chauhan <[email protected]>
---
include/net/cfg80211.h | 30 +++++++++++++++++++
include/uapi/linux/nl80211.h | 31 ++++++++++++++++++++
net/wireless/nl80211.c | 68 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 129 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 45f6bf5..25b54dc 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1933,6 +1933,24 @@ struct cfg80211_update_ft_ies_params {
};
/**
+ * struct cfg80211_avoid_frequency_range - frequency range(s) to avoid
+ *
+ * This structure provides frequency range(s) that should be avoided
+ *
+ * @start_freq: start of frequency (KHz)
+ * @end_freq: end of frequency (KHz)
+ */
+struct cfg80211_avoid_frequency_range {
+ unsigned int start_freq;
+ unsigned int end_freq;
+};
+
+struct cfg80211_avoid_frequency_list {
+ unsigned int n_freq_ranges;
+ struct cfg80211_avoid_frequency_range *freq_range[0];
+};
+
+/**
* struct cfg80211_ops - backend description for wireless configuration
*
* This struct is registered by fullmac card drivers and/or wireless stacks
@@ -4340,6 +4358,18 @@ void cfg80211_ft_event(struct net_device *netdev,
struct cfg80211_ft_event_params *ft_event);
/**
+ * cfg80211_avoid_frequency_event - notify userspace about frequency range(s)
+ * @netdev: network device
+ * @freq_list: frequency range(s) information
+ * @gfp: allocation flags
+ *
+ * WLAN driver calls this function to notify userspace about frequency
+ * range(s) that should be avoided.
+ */
+void cfg80211_avoid_frequency_event(struct net_device *netdev,
+ struct cfg80211_avoid_frequency_list *freq_list, gfp_t gfp);
+
+/**
* cfg80211_get_p2p_attr - find and copy a P2P attribute from IE buffer
* @ies: the input IE buffer
* @len: the input length
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index fde2c02..457fd67 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -686,6 +686,13 @@
* other station that transmission must be blocked until the channel
* switch is complete.
*
+ * @NL80211_CMD_AVOID_FREQUENCIES_EVENT: Send range(s) of frequencies that
+ * should be avoided, from the WLAN driver to the user space. WLAN driver
+ * may send unsafe frequencies to avoid interference. User space should
+ * move SAP/P2P-GO out of those unsafe frequency ranges. User space may
+ * decide to continue operation on unsafe frequency but in such case,
+ * performance might get impact.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -853,6 +860,8 @@ enum nl80211_commands {
NL80211_CMD_CHANNEL_SWITCH,
+ NL80211_CMD_AVOID_FREQUENCIES_EVENT,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -1496,6 +1505,8 @@ enum nl80211_commands {
* @NL80211_ATTR_RXMGMT_FLAGS: flags for nl80211_send_mgmt(), u32.
* As specified in the &enum nl80211_rxmgmt_flags.
*
+ * @NL80211_ATTR_AVOID_FREQUENCIES: Avoid frequencies container information
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1806,6 +1817,8 @@ enum nl80211_attrs {
NL80211_ATTR_RXMGMT_FLAGS,
+ NL80211_ATTR_AVOID_FREQUENCIES,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -2255,6 +2268,24 @@ enum nl80211_frequency_attr {
#define NL80211_FREQUENCY_ATTR_MAX_TX_POWER NL80211_FREQUENCY_ATTR_MAX_TX_POWER
/**
+ * enum nl80211_avoid_frequency_attr - avoid frequency attributes
+ * @__NL80211_FREQUENCY_ATTR_INVALID: attribute number 0 is reserved
+ * @NL80211_AVOID_FREQUENCY_ATTR_START_FREQ: Start of frequency (KHz) range
+ * @NL80211_AVOID_FREQUENCY_ATTR_END_FREQ: End of frequency (KHz) range
+ * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
+ */
+enum nl80211_avoid_frequency_attr {
+ __NL80211_AVOID_FREQUENCY_ATTR_INVALID,
+ NL80211_AVOID_FREQUENCY_ATTR_START_FREQ,
+ NL80211_AVOID_FREQUENCY_ATTR_END_FREQ,
+
+ /* keep last */
+ __NL80211_AVOID_FREQUENCY_ATTR_AFTER_LAST,
+ NL80211_AVOID_FREQUENCY_ATTR_MAX =
+ __NL80211_AVOID_FREQUENCY_ATTR_AFTER_LAST - 1
+};
+
+/**
* enum nl80211_bitrate_attr - bitrate attributes
* @__NL80211_BITRATE_ATTR_INVALID: attribute number 0 is reserved
* @NL80211_BITRATE_ATTR_RATE: Bitrate in units of 100 kbps
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cbbef88..dc3443a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -354,6 +354,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_CSA_IES] = { .type = NLA_NESTED },
[NL80211_ATTR_CSA_C_OFF_BEACON] = { .type = NLA_U16 },
[NL80211_ATTR_CSA_C_OFF_PRESP] = { .type = NLA_U16 },
+ [NL80211_ATTR_AVOID_FREQUENCIES] = { .type = NLA_NESTED },
};
/* policy for the key attributes */
@@ -11234,6 +11235,73 @@ void cfg80211_ft_event(struct net_device *netdev,
}
EXPORT_SYMBOL(cfg80211_ft_event);
+void cfg80211_avoid_frequency_event(struct net_device *netdev,
+ struct cfg80211_avoid_frequency_list *freq_list, gfp_t gfp)
+{
+ struct wiphy *wiphy;
+ struct cfg80211_registered_device *rdev;
+ struct sk_buff *msg;
+ void *hdr;
+ struct nlattr *nl_ranges, *nl_range;
+ int err = -EINVAL;
+ unsigned int i;
+
+ if (!netdev || !netdev->ieee80211_ptr ||
+ !netdev->ieee80211_ptr->wiphy || !freq_list)
+ return;
+
+ wiphy = netdev->ieee80211_ptr->wiphy;
+ rdev = wiphy_to_dev(wiphy);
+
+ if (!rdev)
+ return;
+
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
+ if (!msg)
+ return;
+
+ hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_AVOID_FREQUENCIES_EVENT);
+ if (!hdr) {
+ nlmsg_free(msg);
+ return;
+ }
+
+ if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
+ nla_put_u32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex))
+ goto nla_put_failure;
+
+ nl_ranges = nla_nest_start(msg, NL80211_ATTR_AVOID_FREQUENCIES);
+ if (!nl_ranges)
+ goto nla_put_failure;
+
+ for (i = 0; i < freq_list->n_freq_ranges; i++) {
+ nl_range = nla_nest_start(msg, i);
+ if (!nl_range)
+ goto nla_put_failure;
+
+ if (nla_put_u32(msg, NL80211_AVOID_FREQUENCY_ATTR_START_FREQ,
+ freq_list->freq_range[i]->start_freq) ||
+ nla_put_u32(msg, NL80211_AVOID_FREQUENCY_ATTR_END_FREQ,
+ freq_list->freq_range[i]->end_freq))
+ goto nla_put_failure;
+ nla_nest_end(msg, nl_range);
+ }
+ nla_nest_end(msg, nl_ranges);
+
+ err = genlmsg_end(msg, hdr);
+ if (err < 0)
+ goto nla_put_failure;
+
+ genlmsg_multicast_netns(wiphy_net(&rdev->wiphy), msg, 0,
+ nl80211_mlme_mcgrp.id, gfp);
+ return;
+
+nla_put_failure:
+ genlmsg_cancel(msg, hdr);
+ nlmsg_free(msg);
+}
+EXPORT_SYMBOL(cfg80211_avoid_frequency_event);
+
void cfg80211_crit_proto_stopped(struct wireless_dev *wdev, gfp_t gfp)
{
struct cfg80211_registered_device *rdev;
--
1.8.4
SGkgSm9oYW5uZXMsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50LiBQdXJwb3NlIG9mIHRoaXMg
cGF0Y2ggaXMgdG8gYWRkIGFuIEFQSSBmb3IgV0xBTiBkcml2ZXIgdG8gcmVwb3J0IGZyZXF1ZW5j
eSByYW5nZXMgd2hpY2ggc2hvdWxkIGJlIGF2b2lkZWQgZm9yIFNBUC9QMlAtR08gYmVjYXVzZSBv
ZiBpbnRlcmZlcmVuY2UuDQoNCkhvdyBhYm91dCBpZiBJIHJld29yZCBjb21taXQgdGVzdCBhcyBi
ZWxvdz8NCg0KY2ZnODAyMTEvbmw4MDIxMTogQWRkIEFQSSB0byByZXBvcnQgZnJlcXVlbmN5IHJh
bmdlKHMpIHRvIGJlIGF2b2lkZWQNCg0KQWRkIHN1cHBvcnQgZm9yIFdMQU4gZHJpdmVyIHRvIHJl
cG9ydCBmcmVxdWVuY3kgcmFuZ2UocykgdG8gYmUgYXZvaWRlZCBiZWNhdXNlIG9mIGludGVyZmVy
ZW5jZS4gSWYgU0FQL1AyUC1HTyBpcyBvcGVyYXRpbmcgb24gaW50ZXJmZXJpbmcgZnJlcXVlbmN5
IHRoZW4gdXNlciBzcGFjZSBzaG91bGQgc3RvcCBhbmQgcmVzdGFydCB0aGVtIGF2b2lkaW5nIGlu
dGVyZmVyaW5nIGZyZXF1ZW5jeSByYW5nZShzKS4gVXNlciBzcGFjZSBtYXkgZGVjaWRlIHRvIGNv
bnRpbnVlIG9wZXJhdGlvbiBvbiBpbnRlcmZlcmluZyBmcmVxdWVuY3ksIGJ1dCBpbiBzdWNoIGNh
c2UsIHRoZXJlIG1pZ2h0IGJlIGltcGFjdCBvbiBwZXJmb3JtYW5jZS4NCg0KUmVnYXJkcywNClJh
amVzaCBDaGF1aGFuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaGFu
bmVzIEJlcmcgW21haWx0bzpqb2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0XSANClNlbnQ6IFRodXJz
ZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDc6NDEgQU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IFJvZHJpZ3VleiwgTHVpczsgTWFsaW5lbiwg
Sm91bmkNClN1YmplY3Q6IFJlOiBbUEFUQ0hdIGNmZzgwMjExL25sODAyMTE6IEFkZCBzdXBwb3J0
IHRvIHJlcG9ydCB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlcyhzKQ0KDQpPbiBXZWQsIDIwMTMtMTAt
MTYgYXQgMjE6NTcgLTA3MDAsIFJhamVzaCBDaGF1aGFuIHdyb3RlOg0KPiBBZGQgc3VwcG9ydCBm
b3IgV0xBTiBkcml2ZXIgdG8gcmVwb3J0IHVuc2FmZSBmcmVxdWVuY3kgcmFuZ2UocykuIA0KDQpX
aHk/DQoNCj4gVXNlcg0KPiBzcGFjZSBzaG91bGQgbW92ZSBTQVAvUDJQLUdPIG91dCBvZiB0aG9z
ZSB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlKHMpLg0KPiBVc2VyIHNwYWNlIG1heSBkZWNpZGUgdG8g
Y29udGludWUgb3BlcmF0aW9uIG9uIHVuc2FmZSBmcmVxdWVuY3kgYnV0IGluIA0KPiBzdWNoIGNh
c2UgdGhlcmUgbWlnaHQgYmUgaW1wYWN0IG9uIHBlcmZvcm1hbmNlIGJlY2F1c2Ugb2YgaW50ZXJm
ZXJlbmNlLg0KDQpTQVA/IEkgZG9uJ3QgdGhpbmsgU0FQIHdpbGwgbW92ZSAtIHRoZXkncmUgcHJl
dHR5IHN0dWNrIGluIFdhbGxkb3JmIDpQDQoNClRoaXMgaXMgcHJldHR5IHN0cmFuZ2UgcGF0Y2gs
IGFuZCB2ZXJ5IGxpdHRsZSBqdXN0aWZpY2F0aW9uLg0KDQoiVW5zYWZlIiBpcyBhbHNvIGEgcmVh
bGx5IGJhZCB3b3JkLg0KDQpqb2hhbm5lcw0KDQo=
On 10/28/2013 12:01 PM, Dan Williams wrote:
> On Mon, 2013-10-28 at 18:08 +0000, Chauhan, Rajesh wrote:
>> Hi Luis,
>>
>> For "enough information for proper usage" - how about if I add an attribute for the source of interference (say, for example, "cellular") for each of those frequency range?
> When you say "cellular" here, do mean a WWAN card in the same machine,
> sharing the antenna (or using a very very nearby antenna) with the WiFi
> card? Or do you mean a close-by phone, or a tower itself? How is this
> different from BT coexistence or WiMAX coexistence?
>
One use case would be a colocated WWAN card sharing an antenna or using
a very very nearby antenna. There could be other use cases. I would say
this is complimentary to coexistence. The idea is to tell userspace
which frequencies have know sources of interference so that they can be
avoided, and hence coexistence would not be required. If userspace
chooses to use an "unsafe" frequency, the the driver's coexistence logic
would then be utilized, but the user experience could suffer compared to
if a "safe" frequency had been selected.
The issue that has been debated internally is whether or not userspace
needs to know the source of the interference. In other words, if we
have an enumerated set of interference sources, would userspace behave
differently based upon the source?
This is, after all, just meant to be a hint to userspace to give it more
information to use when selected a channel to be used in a master mode
of operation.
On Thu, Oct 17, 2013 at 9:51 PM, Chauhan, Rajesh
<[email protected]> wrote:
> Hi Dan,
>
> Thanks for your comments.
>
> Current patch is to report event asynchronously and that would be needed even if we have your suggested interface of client collecting that information upfront, which seems like you also kind of agree, because RF environment may change later and generating an event at that time with frequency details would help. So your suggested approach of "mechanism for the client to get this information" in itself seems like a candidate for a separate patch.
The infrastructure for this sort of thing that me, Inaky and Marcel
had proposed in 2007 is the Frequency Broker:
http://wireless.kernel.org/en/developers/FrequencyBroker
> On the race condition which you described - thanks!, but it is something which implementation of driver would need to take care. Similarly, user space can have implementation to cache information on receipt of the event to use it later.
This patch is vague. Once we set something as API we have to live with
it, I am not comfortable with this patch having enough information for
proper usage by different drivers for the same purpose or intent. The
only real positive argument that could be used here is where something
like Android might have already embraced some similar API but are we
going to always just enable API on Linux just because Android did it
without thinking about proper long term architecture? I don't think
so.
Luis
SGkgSm9oYW5uZXMsDQoNCkluIGFub3RoZXIgZW1haWwsIEkgYW0gcHJvcG9zaW5nIHRvIGFkZCBh
biBhdHRyaWJ1dGUgZm9yIHRoZSBzb3VyY2Ugb2YgaW50ZXJmZXJlbmNlIChmb3IgZXhhbXBsZSwg
ImNlbGx1bGFyIikgZm9yIGVhY2ggZnJlcXVlbmN5IHJhbmdlLiBTbyB0aGF0IHdheSBkcml2ZXIg
d2lsbCBoYXZlIHRvIHNwZWNpZnkgZXhhY3Qgc291cmNlIG9mIGludGVyZmVyZW5jZSBhbmQgdGhh
dCB3b3VsZCBhbHNvIGF2b2lkIHJhbmRvbSBjaGFubmVsIHN0ZWVyaW5nLiBJIHdvdWxkIHNlbmQg
b3V0IHVwZGF0ZWQgcGF0Y2ggc2V0IHdpdGggdGhhdCBjaGFuZ2UuDQoNClJlZ2FyZHMsDQpSYWpl
c2ggQ2hhdWhhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9oYW5uZXMg
QmVyZyBbbWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdIA0KU2VudDogTW9uZGF5LCBP
Y3RvYmVyIDI4LCAyMDEzIDc6NDUgQU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBsaW51eC13
aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IFJvZHJpZ3VleiwgTHVpczsgTWFsaW5lbiwgSm91bmk7
IEJhaGluaSwgSGVucmk7IENoYW5nLCBMZW87IEx1bywgWHVuDQpTdWJqZWN0OiBSZTogW1BBVENI
XSBjZmc4MDIxMS9ubDgwMjExOiBBZGQgc3VwcG9ydCB0byByZXBvcnQgdW5zYWZlIGZyZXF1ZW5j
eSByYW5nZXMocykNCg0KT24gVGh1LCAyMDEzLTEwLTE3IGF0IDE3OjE5ICswMDAwLCBDaGF1aGFu
LCBSYWplc2ggd3JvdGU6DQo+IEhpIEpvaGFubmVzLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGNv
bW1lbnQuIFB1cnBvc2Ugb2YgdGhpcyBwYXRjaCBpcyB0byBhZGQgYW4gQVBJIGZvciANCj4gV0xB
TiBkcml2ZXIgdG8gcmVwb3J0IGZyZXF1ZW5jeSByYW5nZXMgd2hpY2ggc2hvdWxkIGJlIGF2b2lk
ZWQgZm9yIA0KPiBTQVAvUDJQLUdPIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KPiANCj4gSG93
IGFib3V0IGlmIEkgcmV3b3JkIGNvbW1pdCB0ZXN0IGFzIGJlbG93Pw0KPiANCj4gY2ZnODAyMTEv
bmw4MDIxMTogQWRkIEFQSSB0byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRvIGJlIGF2b2lk
ZWQNCj4gDQo+IEFkZCBzdXBwb3J0IGZvciBXTEFOIGRyaXZlciB0byByZXBvcnQgZnJlcXVlbmN5
IHJhbmdlKHMpIHRvIGJlIGF2b2lkZWQgDQo+IGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KDQpX
b3VsZG4ndCBpdCBtYWtlIG1vcmUgc2Vuc2UgdG8gcmFpc2UgYSAiZGV0ZWN0ZWQgaW50ZXJmZXJl
bmNlIiBldmVudD8NClRoZXJlJ3Mgbm8gd2F5IHRvIGtub3cgd2hhdCBjaGFubmVsIHJhbmdlIGlz
IGFmZmVjdGVkIGFueXdheS4gSSBmZWFyIHRoYXQgdGhpcyBpcyB2YWd1ZSBlbm91Z2ggZm9yIHlv
dSB0byAoYWIpdXNlIGl0IGZvciBhbGwga2luZHMgb2YgcmFuZG9tICJjaGFubmVsIHN0ZWVyaW5n
IiBmcm9tIHRoZSBkcml2ZXIuDQoNCmpvaGFubmVzDQoNCg==
On Mon, 2013-10-28 at 18:08 +0000, Chauhan, Rajesh wrote:
> Hi Luis,
>
> For "enough information for proper usage" - how about if I add an attribute for the source of interference (say, for example, "cellular") for each of those frequency range?
When you say "cellular" here, do mean a WWAN card in the same machine,
sharing the antenna (or using a very very nearby antenna) with the WiFi
card? Or do you mean a close-by phone, or a tower itself? How is this
different from BT coexistence or WiMAX coexistence?
Dan
> Regards,
> Rajesh Chauhan
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Luis R. Rodriguez
> Sent: Sunday, October 20, 2013 3:39 AM
> To: Chauhan, Rajesh
> Cc: Dan Williams; Johannes Berg; [email protected]; Malinen, Jouni; Bahini, Henri; Chang, Leo; Luo, Xun
> Subject: Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
>
> On Thu, Oct 17, 2013 at 9:51 PM, Chauhan, Rajesh <[email protected]> wrote:
> > Hi Dan,
> >
> > Thanks for your comments.
> >
> > Current patch is to report event asynchronously and that would be needed even if we have your suggested interface of client collecting that information upfront, which seems like you also kind of agree, because RF environment may change later and generating an event at that time with frequency details would help. So your suggested approach of "mechanism for the client to get this information" in itself seems like a candidate for a separate patch.
>
> The infrastructure for this sort of thing that me, Inaky and Marcel had proposed in 2007 is the Frequency Broker:
>
> http://wireless.kernel.org/en/developers/FrequencyBroker
>
> > On the race condition which you described - thanks!, but it is something which implementation of driver would need to take care. Similarly, user space can have implementation to cache information on receipt of the event to use it later.
>
> This patch is vague. Once we set something as API we have to live with it, I am not comfortable with this patch having enough information for proper usage by different drivers for the same purpose or intent. The only real positive argument that could be used here is where something like Android might have already embraced some similar API but are we going to always just enable API on Linux just because Android did it without thinking about proper long term architecture? I don't think so.
>
> Luis
On Wed, 2013-10-16 at 21:57 -0700, Rajesh Chauhan wrote:
> Add support for WLAN driver to report unsafe frequency range(s).
Why?
> User
> space should move SAP/P2P-GO out of those unsafe frequency range(s).
> User space may decide to continue operation on unsafe frequency but in
> such case there might be impact on performance because of interference.
SAP? I don't think SAP will move - they're pretty stuck in Walldorf :P
This is pretty strange patch, and very little justification.
"Unsafe" is also a really bad word.
johannes
SGkgSm9oYW5uZXMsDQoNCkxldCBtZSBhbHNvIHJlcGxhY2UgU0FQIHdpdGggU29mdEFQLg0KDQpT
byBub3cgY29tbWl0IHRleHQgd291bGQgYmU6DQoNCmNmZzgwMjExL25sODAyMTE6IEFkZCBBUEkg
dG8gcmVwb3J0IGZyZXF1ZW5jeSByYW5nZShzKSB0byBiZSBhdm9pZGVkDQoNCkFkZCBzdXBwb3J0
IGZvciBXTEFOIGRyaXZlciB0byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRvIGJlIGF2b2lk
ZWQgYmVjYXVzZSBvZiBpbnRlcmZlcmVuY2UuIElmIFNvZnRBUC9QMlAtR08gaXMgb3BlcmF0aW5n
IG9uIGludGVyZmVyaW5nIGZyZXF1ZW5jeSB0aGVuIHVzZXIgc3BhY2Ugc2hvdWxkIHN0b3AgYW5k
IHJlc3RhcnQgdGhlbSBhdm9pZGluZyBpbnRlcmZlcmluZyBmcmVxdWVuY3kgcmFuZ2UocykuIFVz
ZXIgc3BhY2UgbWF5IGRlY2lkZSB0byBjb250aW51ZSBvcGVyYXRpb24gb24gaW50ZXJmZXJpbmcg
ZnJlcXVlbmN5LCBidXQgaW4gc3VjaCBjYXNlLCB0aGVyZSBtaWdodCBiZSBpbXBhY3Qgb24gcGVy
Zm9ybWFuY2UuDQoNClJlZ2FyZHMsDQpSYWplc2ggQ2hhdWhhbg0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBDaGF1aGFuLCBSYWplc2ggDQpTZW50OiBUaHVyc2RheSwgT2N0
b2JlciAxNywgMjAxMyAxMDoyMCBBTQ0KVG86ICdKb2hhbm5lcyBCZXJnJw0KQ2M6IGxpbnV4LXdp
cmVsZXNzQHZnZXIua2VybmVsLm9yZzsgUm9kcmlndWV6LCBMdWlzOyBNYWxpbmVuLCBKb3VuaTsg
QmFoaW5pLCBIZW5yaTsgQ2hhbmcsIExlbzsgTHVvLCBYdW47IENoYXVoYW4sIFJhamVzaA0KU3Vi
amVjdDogUkU6IFtQQVRDSF0gY2ZnODAyMTEvbmw4MDIxMTogQWRkIHN1cHBvcnQgdG8gcmVwb3J0
IHVuc2FmZSBmcmVxdWVuY3kgcmFuZ2VzKHMpDQoNCkhpIEpvaGFubmVzLA0KDQpUaGFua3MgZm9y
IHlvdXIgY29tbWVudC4gUHVycG9zZSBvZiB0aGlzIHBhdGNoIGlzIHRvIGFkZCBhbiBBUEkgZm9y
IFdMQU4gZHJpdmVyIHRvIHJlcG9ydCBmcmVxdWVuY3kgcmFuZ2VzIHdoaWNoIHNob3VsZCBiZSBh
dm9pZGVkIGZvciBTQVAvUDJQLUdPIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KDQpIb3cgYWJv
dXQgaWYgSSByZXdvcmQgY29tbWl0IHRlc3QgYXMgYmVsb3c/DQoNCmNmZzgwMjExL25sODAyMTE6
IEFkZCBBUEkgdG8gcmVwb3J0IGZyZXF1ZW5jeSByYW5nZShzKSB0byBiZSBhdm9pZGVkDQoNCkFk
ZCBzdXBwb3J0IGZvciBXTEFOIGRyaXZlciB0byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRv
IGJlIGF2b2lkZWQgYmVjYXVzZSBvZiBpbnRlcmZlcmVuY2UuIElmIFNBUC9QMlAtR08gaXMgb3Bl
cmF0aW5nIG9uIGludGVyZmVyaW5nIGZyZXF1ZW5jeSB0aGVuIHVzZXIgc3BhY2Ugc2hvdWxkIHN0
b3AgYW5kIHJlc3RhcnQgdGhlbSBhdm9pZGluZyBpbnRlcmZlcmluZyBmcmVxdWVuY3kgcmFuZ2Uo
cykuIFVzZXIgc3BhY2UgbWF5IGRlY2lkZSB0byBjb250aW51ZSBvcGVyYXRpb24gb24gaW50ZXJm
ZXJpbmcgZnJlcXVlbmN5LCBidXQgaW4gc3VjaCBjYXNlLCB0aGVyZSBtaWdodCBiZSBpbXBhY3Qg
b24gcGVyZm9ybWFuY2UuDQoNClJlZ2FyZHMsDQpSYWplc2ggQ2hhdWhhbg0KDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWlsdG86am9oYW5uZXNA
c2lwc29sdXRpb25zLm5ldF0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDc6NDEg
QU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5v
cmc7IFJvZHJpZ3VleiwgTHVpczsgTWFsaW5lbiwgSm91bmkNClN1YmplY3Q6IFJlOiBbUEFUQ0hd
IGNmZzgwMjExL25sODAyMTE6IEFkZCBzdXBwb3J0IHRvIHJlcG9ydCB1bnNhZmUgZnJlcXVlbmN5
IHJhbmdlcyhzKQ0KDQpPbiBXZWQsIDIwMTMtMTAtMTYgYXQgMjE6NTcgLTA3MDAsIFJhamVzaCBD
aGF1aGFuIHdyb3RlOg0KPiBBZGQgc3VwcG9ydCBmb3IgV0xBTiBkcml2ZXIgdG8gcmVwb3J0IHVu
c2FmZSBmcmVxdWVuY3kgcmFuZ2UocykuIA0KDQpXaHk/DQoNCj4gVXNlcg0KPiBzcGFjZSBzaG91
bGQgbW92ZSBTQVAvUDJQLUdPIG91dCBvZiB0aG9zZSB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlKHMp
Lg0KPiBVc2VyIHNwYWNlIG1heSBkZWNpZGUgdG8gY29udGludWUgb3BlcmF0aW9uIG9uIHVuc2Fm
ZSBmcmVxdWVuY3kgYnV0IGluIA0KPiBzdWNoIGNhc2UgdGhlcmUgbWlnaHQgYmUgaW1wYWN0IG9u
IHBlcmZvcm1hbmNlIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KDQpTQVA/IEkgZG9uJ3QgdGhp
bmsgU0FQIHdpbGwgbW92ZSAtIHRoZXkncmUgcHJldHR5IHN0dWNrIGluIFdhbGxkb3JmIDpQDQoN
ClRoaXMgaXMgcHJldHR5IHN0cmFuZ2UgcGF0Y2gsIGFuZCB2ZXJ5IGxpdHRsZSBqdXN0aWZpY2F0
aW9uLg0KDQoiVW5zYWZlIiBpcyBhbHNvIGEgcmVhbGx5IGJhZCB3b3JkLg0KDQpqb2hhbm5lcw0K
DQo=
SGkgTHVpcywNCg0KRm9yICJlbm91Z2ggaW5mb3JtYXRpb24gZm9yIHByb3BlciB1c2FnZSIgLSBo
b3cgYWJvdXQgaWYgSSBhZGQgYW4gYXR0cmlidXRlIGZvciB0aGUgc291cmNlIG9mIGludGVyZmVy
ZW5jZSAoc2F5LCBmb3IgZXhhbXBsZSwgImNlbGx1bGFyIikgZm9yIGVhY2ggb2YgdGhvc2UgZnJl
cXVlbmN5IHJhbmdlPw0KDQpSZWdhcmRzLA0KUmFqZXNoIENoYXVoYW4NCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IG1jZ3JvZkBnbWFpbC5jb20gW21haWx0bzptY2dyb2ZAZ21h
aWwuY29tXSBPbiBCZWhhbGYgT2YgTHVpcyBSLiBSb2RyaWd1ZXoNClNlbnQ6IFN1bmRheSwgT2N0
b2JlciAyMCwgMjAxMyAzOjM5IEFNDQpUbzogQ2hhdWhhbiwgUmFqZXNoDQpDYzogRGFuIFdpbGxp
YW1zOyBKb2hhbm5lcyBCZXJnOyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE1hbGlu
ZW4sIEpvdW5pOyBCYWhpbmksIEhlbnJpOyBDaGFuZywgTGVvOyBMdW8sIFh1bg0KU3ViamVjdDog
UmU6IFtQQVRDSF0gY2ZnODAyMTEvbmw4MDIxMTogQWRkIHN1cHBvcnQgdG8gcmVwb3J0IHVuc2Fm
ZSBmcmVxdWVuY3kgcmFuZ2VzKHMpDQoNCk9uIFRodSwgT2N0IDE3LCAyMDEzIGF0IDk6NTEgUE0s
IENoYXVoYW4sIFJhamVzaCA8cmFqZXNoY0BxY2EucXVhbGNvbW0uY29tPiB3cm90ZToNCj4gSGkg
RGFuLA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQo+DQo+IEN1cnJlbnQgcGF0Y2gg
aXMgdG8gcmVwb3J0IGV2ZW50IGFzeW5jaHJvbm91c2x5IGFuZCB0aGF0IHdvdWxkIGJlIG5lZWRl
ZCBldmVuIGlmIHdlIGhhdmUgeW91ciBzdWdnZXN0ZWQgaW50ZXJmYWNlIG9mIGNsaWVudCBjb2xs
ZWN0aW5nIHRoYXQgaW5mb3JtYXRpb24gdXBmcm9udCwgd2hpY2ggc2VlbXMgbGlrZSB5b3UgYWxz
byBraW5kIG9mIGFncmVlLCBiZWNhdXNlIFJGIGVudmlyb25tZW50IG1heSBjaGFuZ2UgbGF0ZXIg
YW5kIGdlbmVyYXRpbmcgYW4gZXZlbnQgYXQgdGhhdCB0aW1lIHdpdGggZnJlcXVlbmN5IGRldGFp
bHMgd291bGQgaGVscC4gU28geW91ciBzdWdnZXN0ZWQgYXBwcm9hY2ggb2YgIm1lY2hhbmlzbSBm
b3IgdGhlIGNsaWVudCB0byBnZXQgdGhpcyBpbmZvcm1hdGlvbiIgaW4gaXRzZWxmIHNlZW1zIGxp
a2UgYSBjYW5kaWRhdGUgZm9yIGEgc2VwYXJhdGUgcGF0Y2guDQoNClRoZSBpbmZyYXN0cnVjdHVy
ZSBmb3IgdGhpcyBzb3J0IG9mIHRoaW5nIHRoYXQgbWUsIEluYWt5IGFuZCBNYXJjZWwgaGFkIHBy
b3Bvc2VkIGluIDIwMDcgaXMgdGhlIEZyZXF1ZW5jeSBCcm9rZXI6DQoNCmh0dHA6Ly93aXJlbGVz
cy5rZXJuZWwub3JnL2VuL2RldmVsb3BlcnMvRnJlcXVlbmN5QnJva2VyDQoNCj4gT24gdGhlIHJh
Y2UgY29uZGl0aW9uIHdoaWNoIHlvdSBkZXNjcmliZWQgLSB0aGFua3MhLCBidXQgaXQgaXMgc29t
ZXRoaW5nIHdoaWNoIGltcGxlbWVudGF0aW9uIG9mIGRyaXZlciB3b3VsZCBuZWVkIHRvIHRha2Ug
Y2FyZS4gU2ltaWxhcmx5LCB1c2VyIHNwYWNlIGNhbiBoYXZlIGltcGxlbWVudGF0aW9uIHRvIGNh
Y2hlIGluZm9ybWF0aW9uIG9uIHJlY2VpcHQgb2YgdGhlIGV2ZW50IHRvIHVzZSBpdCBsYXRlci4N
Cg0KVGhpcyBwYXRjaCBpcyB2YWd1ZS4gT25jZSB3ZSBzZXQgc29tZXRoaW5nIGFzIEFQSSB3ZSBo
YXZlIHRvIGxpdmUgd2l0aCBpdCwgSSBhbSBub3QgY29tZm9ydGFibGUgd2l0aCB0aGlzIHBhdGNo
IGhhdmluZyBlbm91Z2ggaW5mb3JtYXRpb24gZm9yIHByb3BlciB1c2FnZSBieSBkaWZmZXJlbnQg
ZHJpdmVycyBmb3IgdGhlIHNhbWUgcHVycG9zZSBvciBpbnRlbnQuIFRoZSBvbmx5IHJlYWwgcG9z
aXRpdmUgYXJndW1lbnQgdGhhdCBjb3VsZCBiZSB1c2VkIGhlcmUgaXMgd2hlcmUgc29tZXRoaW5n
IGxpa2UgQW5kcm9pZCBtaWdodCBoYXZlIGFscmVhZHkgZW1icmFjZWQgc29tZSBzaW1pbGFyIEFQ
SSBidXQgYXJlIHdlIGdvaW5nIHRvIGFsd2F5cyBqdXN0IGVuYWJsZSBBUEkgb24gTGludXgganVz
dCBiZWNhdXNlIEFuZHJvaWQgZGlkIGl0IHdpdGhvdXQgdGhpbmtpbmcgYWJvdXQgcHJvcGVyIGxv
bmcgdGVybSBhcmNoaXRlY3R1cmU/IEkgZG9uJ3QgdGhpbmsgc28uDQoNCiBMdWlzDQo=
On Thu, 2013-10-17 at 17:19 +0000, Chauhan, Rajesh wrote:
> Hi Johannes,
>
> Thanks for your comment. Purpose of this patch is to add an API for
> WLAN driver to report frequency ranges which should be avoided for
> SAP/P2P-GO because of interference.
>
> How about if I reword commit test as below?
>
> cfg80211/nl80211: Add API to report frequency range(s) to be avoided
>
> Add support for WLAN driver to report frequency range(s) to be avoided
> because of interference.
Wouldn't it make more sense to raise a "detected interference" event?
There's no way to know what channel range is affected anyway. I fear
that this is vague enough for you to (ab)use it for all kinds of random
"channel steering" from the driver.
johannes
On Thu, 2013-10-17 at 17:46 +0000, Chauhan, Rajesh wrote:
> Hi Johannes,
>
> Let me also replace SAP with SoftAP.
>
> So now commit text would be:
>
> cfg80211/nl80211: Add API to report frequency range(s) to be avoided
>
> Add support for WLAN driver to report frequency range(s) to be avoided because of interference. If SoftAP/P2P-GO is operating on interfering frequency then user space should stop and restart them avoiding interfering frequency range(s). User space may decide to continue operation on interfering frequency, but in such case, there might be impact on performance.
Wouldn't a better interface be to:
a) provide a list of undesirable frequencies at all times, instead of an
event, so that userspace can decide *before* creating a Soft AP or P2P
which is the best channel to use, if it wants. Possibly through the
same mechanisms that it's other capabilities are exposed through (like
the full list of supported frequencies, eg "iw phy phy0 info").
Driver can update this list at any time if it notices changes to the RF
environment.
b) if the current operating channel for some Soft AP or P2P interface
becomes undesirable, emit an event indicating that this channel is
undesirable. Userspace can then decide to continue operating on that
channel, or it can check the list of "undesirable" channels from (a) and
pick a different one, and move to it. This is essentially your current
patch, but the event need not carry the channel list, since that's
exposed by (a) already.
There is a small race between a client reading (a) and a client creating
the SoftAP/P2P interface, so it would also be useful that if the channel
a client is creating the SoftAP/P2P on is undesirable the event gets
emitted immediately after creation.
My issue with the original patch is that it only defines the event, it
doesn't define a mechanism for the client to get this information
*before* doing the operation that may be undesirable.
Dan
> Regards,
> Rajesh Chauhan
>
>
> -----Original Message-----
> From: Chauhan, Rajesh
> Sent: Thursday, October 17, 2013 10:20 AM
> To: 'Johannes Berg'
> Cc: [email protected]; Rodriguez, Luis; Malinen, Jouni; Bahini, Henri; Chang, Leo; Luo, Xun; Chauhan, Rajesh
> Subject: RE: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
>
> Hi Johannes,
>
> Thanks for your comment. Purpose of this patch is to add an API for WLAN driver to report frequency ranges which should be avoided for SAP/P2P-GO because of interference.
>
> How about if I reword commit test as below?
>
> cfg80211/nl80211: Add API to report frequency range(s) to be avoided
>
> Add support for WLAN driver to report frequency range(s) to be avoided because of interference. If SAP/P2P-GO is operating on interfering frequency then user space should stop and restart them avoiding interfering frequency range(s). User space may decide to continue operation on interfering frequency, but in such case, there might be impact on performance.
>
> Regards,
> Rajesh Chauhan
>
>
> -----Original Message-----
> From: Johannes Berg [mailto:[email protected]]
> Sent: Thursday, October 17, 2013 7:41 AM
> To: Chauhan, Rajesh
> Cc: [email protected]; Rodriguez, Luis; Malinen, Jouni
> Subject: Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
>
> On Wed, 2013-10-16 at 21:57 -0700, Rajesh Chauhan wrote:
> > Add support for WLAN driver to report unsafe frequency range(s).
>
> Why?
>
> > User
> > space should move SAP/P2P-GO out of those unsafe frequency range(s).
> > User space may decide to continue operation on unsafe frequency but in
> > such case there might be impact on performance because of interference.
>
> SAP? I don't think SAP will move - they're pretty stuck in Walldorf :P
>
> This is pretty strange patch, and very little justification.
>
> "Unsafe" is also a really bad word.
>
> johannes
>
> NrybXǧv^){.n+{*ޕ,{ay ʇڙ,jfhz w j:+vwjmzZ+ݢj"!
SGkgRGFuLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoNCkN1cnJlbnQgcGF0Y2ggaXMg
dG8gcmVwb3J0IGV2ZW50IGFzeW5jaHJvbm91c2x5IGFuZCB0aGF0IHdvdWxkIGJlIG5lZWRlZCBl
dmVuIGlmIHdlIGhhdmUgeW91ciBzdWdnZXN0ZWQgaW50ZXJmYWNlIG9mIGNsaWVudCBjb2xsZWN0
aW5nIHRoYXQgaW5mb3JtYXRpb24gdXBmcm9udCwgd2hpY2ggc2VlbXMgbGlrZSB5b3UgYWxzbyBr
aW5kIG9mIGFncmVlLCBiZWNhdXNlIFJGIGVudmlyb25tZW50IG1heSBjaGFuZ2UgbGF0ZXIgYW5k
IGdlbmVyYXRpbmcgYW4gZXZlbnQgYXQgdGhhdCB0aW1lIHdpdGggZnJlcXVlbmN5IGRldGFpbHMg
d291bGQgaGVscC4gU28geW91ciBzdWdnZXN0ZWQgYXBwcm9hY2ggb2YgIm1lY2hhbmlzbSBmb3Ig
dGhlIGNsaWVudCB0byBnZXQgdGhpcyBpbmZvcm1hdGlvbiIgaW4gaXRzZWxmIHNlZW1zIGxpa2Ug
YSBjYW5kaWRhdGUgZm9yIGEgc2VwYXJhdGUgcGF0Y2guDQoNCk9uIHRoZSByYWNlIGNvbmRpdGlv
biB3aGljaCB5b3UgZGVzY3JpYmVkIC0gdGhhbmtzISwgYnV0IGl0IGlzIHNvbWV0aGluZyB3aGlj
aCBpbXBsZW1lbnRhdGlvbiBvZiBkcml2ZXIgd291bGQgbmVlZCB0byB0YWtlIGNhcmUuIFNpbWls
YXJseSwgdXNlciBzcGFjZSBjYW4gaGF2ZSBpbXBsZW1lbnRhdGlvbiB0byBjYWNoZSBpbmZvcm1h
dGlvbiBvbiByZWNlaXB0IG9mIHRoZSBldmVudCB0byB1c2UgaXQgbGF0ZXIuDQoNClJlZ2FyZHMs
DQpSYWplc2ggQ2hhdWhhbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBE
YW4gV2lsbGlhbXMgW21haWx0bzpkY2J3QHJlZGhhdC5jb21dIA0KU2VudDogVGh1cnNkYXksIE9j
dG9iZXIgMTcsIDIwMTMgMTE6NDAgQU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBKb2hhbm5l
cyBCZXJnOyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IFJvZHJpZ3VleiwgTHVpczsg
TWFsaW5lbiwgSm91bmk7IEJhaGluaSwgSGVucmk7IENoYW5nLCBMZW87IEx1bywgWHVuDQpTdWJq
ZWN0OiBSZTogW1BBVENIXSBjZmc4MDIxMS9ubDgwMjExOiBBZGQgc3VwcG9ydCB0byByZXBvcnQg
dW5zYWZlIGZyZXF1ZW5jeSByYW5nZXMocykNCg0KT24gVGh1LCAyMDEzLTEwLTE3IGF0IDE3OjQ2
ICswMDAwLCBDaGF1aGFuLCBSYWplc2ggd3JvdGU6DQo+IEhpIEpvaGFubmVzLA0KPiANCj4gTGV0
IG1lIGFsc28gcmVwbGFjZSBTQVAgd2l0aCBTb2Z0QVAuDQo+IA0KPiBTbyBub3cgY29tbWl0IHRl
eHQgd291bGQgYmU6DQo+IA0KPiBjZmc4MDIxMS9ubDgwMjExOiBBZGQgQVBJIHRvIHJlcG9ydCBm
cmVxdWVuY3kgcmFuZ2UocykgdG8gYmUgYXZvaWRlZA0KPiANCj4gQWRkIHN1cHBvcnQgZm9yIFdM
QU4gZHJpdmVyIHRvIHJlcG9ydCBmcmVxdWVuY3kgcmFuZ2UocykgdG8gYmUgYXZvaWRlZCBiZWNh
dXNlIG9mIGludGVyZmVyZW5jZS4gSWYgU29mdEFQL1AyUC1HTyBpcyBvcGVyYXRpbmcgb24gaW50
ZXJmZXJpbmcgZnJlcXVlbmN5IHRoZW4gdXNlciBzcGFjZSBzaG91bGQgc3RvcCBhbmQgcmVzdGFy
dCB0aGVtIGF2b2lkaW5nIGludGVyZmVyaW5nIGZyZXF1ZW5jeSByYW5nZShzKS4gVXNlciBzcGFj
ZSBtYXkgZGVjaWRlIHRvIGNvbnRpbnVlIG9wZXJhdGlvbiBvbiBpbnRlcmZlcmluZyBmcmVxdWVu
Y3ksIGJ1dCBpbiBzdWNoIGNhc2UsIHRoZXJlIG1pZ2h0IGJlIGltcGFjdCBvbiBwZXJmb3JtYW5j
ZS4NCg0KV291bGRuJ3QgYSBiZXR0ZXIgaW50ZXJmYWNlIGJlIHRvOg0KDQphKSBwcm92aWRlIGEg
bGlzdCBvZiB1bmRlc2lyYWJsZSBmcmVxdWVuY2llcyBhdCBhbGwgdGltZXMsIGluc3RlYWQgb2Yg
YW4gZXZlbnQsIHNvIHRoYXQgdXNlcnNwYWNlIGNhbiBkZWNpZGUgKmJlZm9yZSogY3JlYXRpbmcg
YSBTb2Z0IEFQIG9yIFAyUCB3aGljaCBpcyB0aGUgYmVzdCBjaGFubmVsIHRvIHVzZSwgaWYgaXQg
d2FudHMuICBQb3NzaWJseSB0aHJvdWdoIHRoZSBzYW1lIG1lY2hhbmlzbXMgdGhhdCBpdCdzIG90
aGVyIGNhcGFiaWxpdGllcyBhcmUgZXhwb3NlZCB0aHJvdWdoIChsaWtlIHRoZSBmdWxsIGxpc3Qg
b2Ygc3VwcG9ydGVkIGZyZXF1ZW5jaWVzLCBlZyAiaXcgcGh5IHBoeTAgaW5mbyIpLg0KDQpEcml2
ZXIgY2FuIHVwZGF0ZSB0aGlzIGxpc3QgYXQgYW55IHRpbWUgaWYgaXQgbm90aWNlcyBjaGFuZ2Vz
IHRvIHRoZSBSRiBlbnZpcm9ubWVudC4NCg0KYikgaWYgdGhlIGN1cnJlbnQgb3BlcmF0aW5nIGNo
YW5uZWwgZm9yIHNvbWUgU29mdCBBUCBvciBQMlAgaW50ZXJmYWNlIGJlY29tZXMgdW5kZXNpcmFi
bGUsIGVtaXQgYW4gZXZlbnQgaW5kaWNhdGluZyB0aGF0IHRoaXMgY2hhbm5lbCBpcyB1bmRlc2ly
YWJsZS4gIFVzZXJzcGFjZSBjYW4gdGhlbiBkZWNpZGUgdG8gY29udGludWUgb3BlcmF0aW5nIG9u
IHRoYXQgY2hhbm5lbCwgb3IgaXQgY2FuIGNoZWNrIHRoZSBsaXN0IG9mICJ1bmRlc2lyYWJsZSIg
Y2hhbm5lbHMgZnJvbSAoYSkgYW5kIHBpY2sgYSBkaWZmZXJlbnQgb25lLCBhbmQgbW92ZSB0byBp
dC4gIFRoaXMgaXMgZXNzZW50aWFsbHkgeW91ciBjdXJyZW50IHBhdGNoLCBidXQgdGhlIGV2ZW50
IG5lZWQgbm90IGNhcnJ5IHRoZSBjaGFubmVsIGxpc3QsIHNpbmNlIHRoYXQncyBleHBvc2VkIGJ5
IChhKSBhbHJlYWR5Lg0KDQpUaGVyZSBpcyBhIHNtYWxsIHJhY2UgYmV0d2VlbiBhIGNsaWVudCBy
ZWFkaW5nIChhKSBhbmQgYSBjbGllbnQgY3JlYXRpbmcgdGhlIFNvZnRBUC9QMlAgaW50ZXJmYWNl
LCBzbyBpdCB3b3VsZCBhbHNvIGJlIHVzZWZ1bCB0aGF0IGlmIHRoZSBjaGFubmVsIGEgY2xpZW50
IGlzIGNyZWF0aW5nIHRoZSBTb2Z0QVAvUDJQIG9uIGlzIHVuZGVzaXJhYmxlIHRoZSBldmVudCBn
ZXRzIGVtaXR0ZWQgaW1tZWRpYXRlbHkgYWZ0ZXIgY3JlYXRpb24uDQoNCk15IGlzc3VlIHdpdGgg
dGhlIG9yaWdpbmFsIHBhdGNoIGlzIHRoYXQgaXQgb25seSBkZWZpbmVzIHRoZSBldmVudCwgaXQg
ZG9lc24ndCBkZWZpbmUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgdG8gZ2V0IHRoaXMgaW5m
b3JtYXRpb24NCipiZWZvcmUqIGRvaW5nIHRoZSBvcGVyYXRpb24gdGhhdCBtYXkgYmUgdW5kZXNp
cmFibGUuDQoNCkRhbg0KDQo+IFJlZ2FyZHMsDQo+IFJhamVzaCBDaGF1aGFuDQo+IA0KPiANCj4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2hhdWhhbiwgUmFqZXNoDQo+IFNl
bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDEwOjIwIEFNDQo+IFRvOiAnSm9oYW5uZXMg
QmVyZycNCj4gQ2M6IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZzsgUm9kcmlndWV6LCBM
dWlzOyBNYWxpbmVuLCBKb3VuaTsgDQo+IEJhaGluaSwgSGVucmk7IENoYW5nLCBMZW87IEx1bywg
WHVuOyBDaGF1aGFuLCBSYWplc2gNCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gY2ZnODAyMTEvbmw4
MDIxMTogQWRkIHN1cHBvcnQgdG8gcmVwb3J0IHVuc2FmZSANCj4gZnJlcXVlbmN5IHJhbmdlcyhz
KQ0KPiANCj4gSGkgSm9oYW5uZXMsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudC4gUHVy
cG9zZSBvZiB0aGlzIHBhdGNoIGlzIHRvIGFkZCBhbiBBUEkgZm9yIFdMQU4gZHJpdmVyIHRvIHJl
cG9ydCBmcmVxdWVuY3kgcmFuZ2VzIHdoaWNoIHNob3VsZCBiZSBhdm9pZGVkIGZvciBTQVAvUDJQ
LUdPIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KPiANCj4gSG93IGFib3V0IGlmIEkgcmV3b3Jk
IGNvbW1pdCB0ZXN0IGFzIGJlbG93Pw0KPiANCj4gY2ZnODAyMTEvbmw4MDIxMTogQWRkIEFQSSB0
byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRvIGJlIGF2b2lkZWQNCj4gDQo+IEFkZCBzdXBw
b3J0IGZvciBXTEFOIGRyaXZlciB0byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRvIGJlIGF2
b2lkZWQgYmVjYXVzZSBvZiBpbnRlcmZlcmVuY2UuIElmIFNBUC9QMlAtR08gaXMgb3BlcmF0aW5n
IG9uIGludGVyZmVyaW5nIGZyZXF1ZW5jeSB0aGVuIHVzZXIgc3BhY2Ugc2hvdWxkIHN0b3AgYW5k
IHJlc3RhcnQgdGhlbSBhdm9pZGluZyBpbnRlcmZlcmluZyBmcmVxdWVuY3kgcmFuZ2UocykuIFVz
ZXIgc3BhY2UgbWF5IGRlY2lkZSB0byBjb250aW51ZSBvcGVyYXRpb24gb24gaW50ZXJmZXJpbmcg
ZnJlcXVlbmN5LCBidXQgaW4gc3VjaCBjYXNlLCB0aGVyZSBtaWdodCBiZSBpbXBhY3Qgb24gcGVy
Zm9ybWFuY2UuDQo+IA0KPiBSZWdhcmRzLA0KPiBSYWplc2ggQ2hhdWhhbg0KPiANCj4gDQo+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaGFubmVzIEJlcmcgW21haWx0bzpq
b2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNywg
MjAxMyA3OjQxIEFNDQo+IFRvOiBDaGF1aGFuLCBSYWplc2gNCj4gQ2M6IGxpbnV4LXdpcmVsZXNz
QHZnZXIua2VybmVsLm9yZzsgUm9kcmlndWV6LCBMdWlzOyBNYWxpbmVuLCBKb3VuaQ0KPiBTdWJq
ZWN0OiBSZTogW1BBVENIXSBjZmc4MDIxMS9ubDgwMjExOiBBZGQgc3VwcG9ydCB0byByZXBvcnQg
dW5zYWZlIA0KPiBmcmVxdWVuY3kgcmFuZ2VzKHMpDQo+IA0KPiBPbiBXZWQsIDIwMTMtMTAtMTYg
YXQgMjE6NTcgLTA3MDAsIFJhamVzaCBDaGF1aGFuIHdyb3RlOg0KPiA+IEFkZCBzdXBwb3J0IGZv
ciBXTEFOIGRyaXZlciB0byByZXBvcnQgdW5zYWZlIGZyZXF1ZW5jeSByYW5nZShzKS4gDQo+IA0K
PiBXaHk/DQo+IA0KPiA+IFVzZXINCj4gPiBzcGFjZSBzaG91bGQgbW92ZSBTQVAvUDJQLUdPIG91
dCBvZiB0aG9zZSB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlKHMpLg0KPiA+IFVzZXIgc3BhY2UgbWF5
IGRlY2lkZSB0byBjb250aW51ZSBvcGVyYXRpb24gb24gdW5zYWZlIGZyZXF1ZW5jeSBidXQgDQo+
ID4gaW4gc3VjaCBjYXNlIHRoZXJlIG1pZ2h0IGJlIGltcGFjdCBvbiBwZXJmb3JtYW5jZSBiZWNh
dXNlIG9mIGludGVyZmVyZW5jZS4NCj4gDQo+IFNBUD8gSSBkb24ndCB0aGluayBTQVAgd2lsbCBt
b3ZlIC0gdGhleSdyZSBwcmV0dHkgc3R1Y2sgaW4gV2FsbGRvcmYgOlANCj4gDQo+IFRoaXMgaXMg
cHJldHR5IHN0cmFuZ2UgcGF0Y2gsIGFuZCB2ZXJ5IGxpdHRsZSBqdXN0aWZpY2F0aW9uLg0KPiAN
Cj4gIlVuc2FmZSIgaXMgYWxzbyBhIHJlYWxseSBiYWQgd29yZC4NCj4gDQo+IGpvaGFubmVzDQo+
IA0KPiBOcnliWMendl4p3rp7Lm4reyrelSx7YXkdyofamSxqIGZoeh53DQpqOit2d2ptIHpaK92i
aiIhDQoNCg0K
On Mon, Oct 28, 2013 at 10:11 PM, Jeffrey Johnson
<[email protected]> wrote:
> The issue that has been debated internally is whether or not userspace needs
> to know the source of the interference. In other words, if we have an
> enumerated set of interference sources, would userspace behave differently
> based upon the source?
This is ignoring my overall architectural considerations of this being
cross RF domains and likely being a better idea to instead consider a
frequency broker for this sort of information. The only reason I
believe we can let that argument go here is that in this particular
case the same antenna is being used and the information seems to be
coming from the wireless firmware, as such it is pertinent to the
struct wiphy, and hence seems proper placement for an nl80211 event.
In so far as the source of information -- as I have said internally,
although userspace may not use it today, it may tomorrow, and having
that information can be useful. I consider a random source of
associated "frequency advisory" simply pointless. At least with some
sort of category of source, userspace, say hostapd or the supplicant,
may decide to treat it in a very specific way today.
Luis