This set addresses comments from Luis:
1. Added a regulatory flag that can be used by drivers to disable the P2P
GO relaxation.
2. Renamed the configuration option to CONFIG_CFG80211_REG_P2P_GO_RELAX.
3. Some code cleanups.
------
As before, this series addresses the option of enabling additional channels for
use based on the following relaxations:
1. Indoor operation, where a device can use channels requiring indoor
operation, subject to that it can guarantee indoor operation.
2. Concurrent GO operation, where devices may instantiate a P2P GO
while they are under the guidance of an authorized master.
The series includes:
* Some clarification (mainly in documentation) about the intended usage of
channels marked as INDOOR_ONLY and CONCURRENT GO.
* Mapping of NL80211_RFF_NO_OUTDOOR to NL80211_CHAN_INDOOR_ONLY
* Support for a user hint that the platform is operating in an indoor
environment, i.e., channel marked as INDOOR_ONLY can be used.
* Allow initiating radiation on channel marked with INDOOR_ONLY also
for scanning an frame injection in monitor mode.
* Some additional fixes for comments I got.
Following is an example of a possible channel map that can be used to allow
the INDOOR_ONLY and CONCURRENT_GO relaxations. Note that:
* Channels 12,13 are marked as Concurrent GO, so even in the lack of exact
information about the current regulatory domain, these channels can be used
for GO instantiation based on the concurrent GO relaxation.
* The above is also true for channels 149-165 (a.k.a U-NII 3).
* Channels 36-48 (a.k.a thee U-NII 1), are marked both with Concurrent GO and
indoor only. While the Concurrent GO can be used as described above, the
indoor only setting allows to use these channels given the platform is
identified as an indoor one, i.e., media server.
2412 MHz [1] (16.0 dBm)
2417 MHz [2] (16.0 dBm)
2422 MHz [3] (16.0 dBm)
2427 MHz [4] (16.0 dBm)
2432 MHz [5] (16.0 dBm)
2437 MHz [6] (16.0 dBm)
2442 MHz [7] (16.0 dBm)
2447 MHz [8] (16.0 dBm)
2452 MHz [9] (16.0 dBm)
2457 MHz [10] (16.0 dBm)
2462 MHz [11] (16.0 dBm)
2467 MHz [12] (16.0 dBm) (no IR, Concurrent GO)
2472 MHz [13] (16.0 dBm) (no IR, Concurrent GO)
5180 MHz [36] (16.0 dBm) (no IR, Indoor Only, Concurrent GO)
5200 MHz [40] (16.0 dBm) (no IR, Indoor Only, Concurrent GO)
5220 MHz [44] (16.0 dBm) (no IR, Indoor Only, Concurrent GO)
5240 MHz [48] (16.0 dBm) (no IR, Indoor Only, Concurrent GO)
5260 MHz [52] (16.0 dBm) (no IR, radar detection)
5280 MHz [56] (16.0 dBm) (no IR, radar detection)
5300 MHz [60] (16.0 dBm) (no IR, radar detection)
5320 MHz [64] (16.0 dBm) (no IR, radar detection)
5500 MHz [100] (16.0 dBm) (no IR, radar detection)
5520 MHz [104] (16.0 dBm) (no IR, radar detection)
5540 MHz [108] (16.0 dBm) (no IR, radar detection)
5560 MHz [112] (16.0 dBm) (no IR, radar detection)
5580 MHz [116] (16.0 dBm) (no IR, radar detection)
5600 MHz [120] (16.0 dBm) (no IR, radar detection)
5620 MHz [124] (16.0 dBm) (no IR, radar detection)
5640 MHz [128] (16.0 dBm) (no IR, radar detection)
5660 MHz [132] (16.0 dBm) (no IR, radar detection)
5680 MHz [136] (16.0 dBm) (no IR, radar detection)
5700 MHz [140] (16.0 dBm) (no IR, radar detection)
5720 MHz [144] (16.0 dBm) (no IR, radar detection)
5745 MHz [149] (16.0 dBm) (no IR, Concurrent GO)
5765 MHz [153] (16.0 dBm) (no IR, Concurrent GO)
5785 MHz [157] (16.0 dBm) (no IR, Concurrent GO)
5805 MHz [161] (16.0 dBm) (no IR, Concurrent GO)
5825 MHz [165] (16.0 dBm) (no IR, Concurrent GO)
Thanks in advance,
Ilan.
David Spinadel (1):
cfg80211: Add indoor only and GO concurrent channel attributes
Ilan Peer (5):
cfg80211: Add Kconfig option for cellular BS hints
cfg80211: Enable GO operation on additional channels
cfg80211: Add an option to hint indoor operation
cfg80211: Enable GO operation on indoor channels
mac80211: Enable initiating radiation on indoor channels
include/net/cfg80211.h | 41 ++++++++++++++++++++-
include/net/regulatory.h | 4 ++
include/uapi/linux/nl80211.h | 10 +++++
net/mac80211/ibss.c | 9 +++--
net/mac80211/scan.c | 15 +++++---
net/mac80211/tx.c | 3 +-
net/wireless/Kconfig | 21 +++++++++++
net/wireless/chan.c | 74 +++++++++++++++++++++++++++++++++++--
net/wireless/mesh.c | 3 +-
net/wireless/nl80211.c | 35 +++++++++++-------
net/wireless/reg.c | 84 ++++++++++++++++++++++++++++++++++++++++--
net/wireless/reg.h | 13 +++++++
net/wireless/trace.h | 11 ++++--
13 files changed, 286 insertions(+), 37 deletions(-)
--
1.7.10.4
Move the regulatory cellular base station hints support under
a specific configuration option and make the option depend
on CFG80211_CERTIFICATION_ONUS.
Signed-off-by: Ilan Peer <[email protected]>
---
net/wireless/Kconfig | 7 +++++++
net/wireless/reg.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 16d08b3..81c05e4 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -95,6 +95,13 @@ config CFG80211_CERTIFICATION_ONUS
you are a wireless researcher and are working in a controlled
and approved environment by your local regulatory agency.
+config CFG80211_REG_CELLULAR_HINTS
+ bool "cfg80211 regulatory support for cellular base station hints"
+ depends on CFG80211_CERTIFICATION_ONUS
+ ---help---
+ This option adds support for drivers that can receive regulatory
+ hints from cellular base stations
+
config CFG80211_DEFAULT_PS
bool "enable powersave by default"
depends on CFG80211
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 82e387c..8a81913 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1019,7 +1019,7 @@ bool reg_last_request_cell_base(void)
return reg_request_cell_base(get_last_request());
}
-#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
+#ifdef CONFIG_CFG80211_REG_CELLULAR_HINTS
/* Core specific check */
static enum reg_request_treatment
reg_ignore_cell_hint(struct regulatory_request *pending_request)
--
1.7.10.4
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 <[email protected]>
---
net/mac80211/scan.c | 15 +++++++++------
net/mac80211/tx.c | 3 ++-
2 files changed, 11 insertions(+), 7 deletions(-)
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);
--
1.7.10.4
From: David Spinadel <[email protected]>
The FCC are clarifying some soft configuration requirements,
which among other include the following:
1. Indoor operation, where a device can use channels requiring indoor
operation, subject to that it can guarantee indoor operation,
i.e., the device is connected to AC Power or the device is under
the control of a local master that is acting as an AP and is
connected to AC Power.
2. Concurrent GO operation, where devices may instantiate a P2P GO
while they are under the guidance of an authorized master. For example,
on a channel on which a BSS is connected to an authorized master, i.e.,
with DFS and radar detection capability in the UNII band.
See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122
Add support for advertising Indoor-only and GO-Concurrent channel
properties.
Signed-off-by: David Spinadel <[email protected]>
Signed-off-by: Ilan Peer <[email protected]>
---
include/net/cfg80211.h | 23 +++++++++++++++++++++++
include/uapi/linux/nl80211.h | 7 +++++++
net/wireless/nl80211.c | 6 ++++++
net/wireless/reg.c | 2 ++
4 files changed, 38 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b1f84b0..dbc5490 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -109,6 +109,27 @@ 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.
+ * A channel marked with IEEE80211_CHAN_INDOOR_ONLY can only be used when
+ * there is a clear assessment that the device is operating in an indoor
+ * surroundings, i.e., it is connected to AC power (and not through
+ * portable DC inverters) or is under the control of a master that is
+ * acting as an AP and is connected to AC power.
+ * @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.
+ * Instantiating a GO on a channel marked with IEEE80211_CHAN_GO_CONCURRENT
+ * can be done when there is a clear assessment that the device is
+ * operating under the guidance of an authorized master, i.e., setting up a
+ * GO while the device is also connected to an AP with DFS and radar
+ * detection on the UNII band (however, this example does not imply that
+ * all channels marked with IEEE80211_CHAN_RADAR must also be marked with
+ * IEEE80211_CHAN_GO_CONCURRENT and vise versa).
+ *
+ * See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122
+ * for more information on the FCC description of the relaxations allowed
+ * by IEEE80211_CHAN_INDOOR_ONLY and IEEE80211_CHAN_GO_CONCURRENT.
+ *
*/
enum ieee80211_channel_flags {
IEEE80211_CHAN_DISABLED = 1<<0,
@@ -120,6 +141,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 91054fd..06440ac 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2304,6 +2304,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
@@ -2322,6 +2327,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 d0afd82..3c1587f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -608,6 +608,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,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 9b897fc..82e387c 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -776,6 +776,8 @@ static u32 map_regdom_flags(u32 rd_flags)
channel_flags |= IEEE80211_CHAN_RADAR;
if (rd_flags & NL80211_RRF_NO_OFDM)
channel_flags |= IEEE80211_CHAN_NO_OFDM;
+ if (rd_flags & NL80211_RRF_NO_OUTDOOR)
+ channel_flags |= IEEE80211_CHAN_INDOOR_ONLY;
return channel_flags;
}
--
1.7.10.4
Add the option to hint the wireless core that it is operating in an indoor
environment.
In addition add regulatory_ir_allowed(), that can be used to
test if initiation radiation is allowed based on the channel flags
and the wireless core indoor hint.
Signed-off-by: Ilan Peer <[email protected]>
---
include/net/cfg80211.h | 14 +++++++++++
include/uapi/linux/nl80211.h | 3 +++
net/wireless/nl80211.c | 18 +++++++-------
net/wireless/reg.c | 54 +++++++++++++++++++++++++++++++++++++++---
net/wireless/reg.h | 1 +
5 files changed, 77 insertions(+), 13 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 317bd06..6e6c42c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3627,6 +3627,20 @@ const struct ieee80211_reg_rule *freq_reg_info(struct wiphy *wiphy,
*/
const char *reg_initiator_name(enum nl80211_reg_initiator initiator);
+/**
+ * regulatory_ir_allowed - is it allowed to initiate radiation on the channel.
+ * @wiphy: the wiphy for which we want to test channel.
+ * @chan: the channel
+ *
+ * Generally, it is not allowed to initiate radiation on a channel marked with
+ * IEEE80211_CHAN_NO_IR. The exception is operation on channels marked with
+ * IEEE80211_CHAN_INDOOR_ONLY. For such channels, initiating radiation is
+ * allowed iff the wireless core was notified that it operates in an indoor
+ * environment.
+ */
+bool regulatory_ir_allowed(struct wiphy *wiphy,
+ struct ieee80211_channel *chan);
+
/*
* callbacks for asynchronous cfg80211 methods, notification
* functions and BSS handling helpers
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 06440ac..1dbf6d3 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2533,10 +2533,13 @@ enum nl80211_dfs_regions {
* present has been registered with the wireless core that
* has listed NL80211_FEATURE_CELL_BASE_REG_HINTS as a
* supported feature.
+ * @NL80211_USER_REG_HINT_INDOOR: a user sent an hint indicating that the
+ * platform is operating in an indoor environment.
*/
enum nl80211_user_reg_hint_type {
NL80211_USER_REG_HINT_USER = 0,
NL80211_USER_REG_HINT_CELL_BASE = 1,
+ NL80211_USER_REG_HINT_INDOOR = 2,
};
/**
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b37b36e..b33f346 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4664,7 +4664,6 @@ static int parse_reg_rule(struct nlattr *tb[],
static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
{
- int r;
char *data = NULL;
enum nl80211_user_reg_hint_type user_reg_hint_type;
@@ -4677,11 +4676,6 @@ static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
if (unlikely(!rcu_access_pointer(cfg80211_regdomain)))
return -EINPROGRESS;
- if (!info->attrs[NL80211_ATTR_REG_ALPHA2])
- return -EINVAL;
-
- data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
-
if (info->attrs[NL80211_ATTR_USER_REG_HINT_TYPE])
user_reg_hint_type =
nla_get_u32(info->attrs[NL80211_ATTR_USER_REG_HINT_TYPE]);
@@ -4691,14 +4685,18 @@ static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
switch (user_reg_hint_type) {
case NL80211_USER_REG_HINT_USER:
case NL80211_USER_REG_HINT_CELL_BASE:
- break;
+ if (!info->attrs[NL80211_ATTR_REG_ALPHA2])
+ return -EINVAL;
+
+ data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
+ return regulatory_hint_user(data, user_reg_hint_type);
+ case NL80211_USER_REG_HINT_INDOOR:
+ return regulatory_hint_indoor_user();
default:
return -EINVAL;
}
- r = regulatory_hint_user(data, user_reg_hint_type);
-
- return r;
+ return 0;
}
static int nl80211_get_mesh_config(struct sk_buff *skb,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index ec38f5d..2f2d5db 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -110,6 +110,14 @@ const struct ieee80211_regdomain __rcu *cfg80211_regdomain;
*/
static int reg_num_devs_support_basehint;
+/*
+ * State variable indicating if the platform on which the devices
+ * are attached is operating in an indoor environment. The state variable
+ * is relevant for all registered devices.
+ * Note: currently not protected by any synchronization primitive.
+ */
+static bool reg_is_indoor;
+
static const struct ieee80211_regdomain *get_cfg80211_regdom(void)
{
return rtnl_dereference(cfg80211_regdomain);
@@ -1014,6 +1022,13 @@ static bool reg_request_cell_base(struct regulatory_request *request)
return request->user_reg_hint_type == NL80211_USER_REG_HINT_CELL_BASE;
}
+static bool reg_request_indoor(struct regulatory_request *request)
+{
+ if (request->initiator != NL80211_REGDOM_SET_BY_USER)
+ return false;
+ return request->user_reg_hint_type == NL80211_USER_REG_HINT_INDOOR;
+}
+
bool reg_last_request_cell_base(void)
{
return reg_request_cell_base(get_last_request());
@@ -1450,6 +1465,11 @@ __reg_process_hint_user(struct regulatory_request *user_request)
{
struct regulatory_request *lr = get_last_request();
+ if (reg_request_indoor(user_request)) {
+ reg_is_indoor = true;
+ return REG_REQ_ALREADY_SET;
+ }
+
if (reg_request_cell_base(user_request))
return reg_ignore_cell_hint(user_request);
@@ -1685,9 +1705,6 @@ static void reg_process_hint(struct regulatory_request *reg_request)
struct wiphy *wiphy = NULL;
enum reg_request_treatment treatment;
- if (WARN_ON(!reg_request->alpha2))
- return;
-
if (reg_request->wiphy_idx != WIPHY_IDX_INVALID)
wiphy = wiphy_idx_to_wiphy(reg_request->wiphy_idx);
@@ -1847,6 +1864,22 @@ int regulatory_hint_user(const char *alpha2,
return 0;
}
+int regulatory_hint_indoor_user(void)
+{
+ struct regulatory_request *request;
+
+ request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ if (!request)
+ return -ENOMEM;
+
+ request->wiphy_idx = WIPHY_IDX_INVALID;
+ request->initiator = NL80211_REGDOM_SET_BY_USER;
+ request->user_reg_hint_type = NL80211_USER_REG_HINT_INDOOR;
+ queue_regulatory_request(request);
+
+ return 0;
+}
+
/* Driver hints */
int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
{
@@ -2014,6 +2047,8 @@ static void restore_regulatory_settings(bool reset_user)
ASSERT_RTNL();
+ reg_is_indoor = false;
+
reset_regdomains(true, &world_regdom);
restore_alpha2(alpha2, reset_user);
@@ -2515,6 +2550,19 @@ int cfg80211_get_unii(int freq)
return -EINVAL;
}
+bool regulatory_ir_allowed(struct wiphy *wiphy, struct ieee80211_channel *chan)
+{
+ if (config_enabled(CONFIG_CFG80211_REG_RELAX_NO_IR) &&
+ !(wiphy->regulatory_flags & REGULATORY_DISABLE_RELAX_NO_IR) &&
+ reg_is_indoor && (chan->flags & IEEE80211_CHAN_INDOOR_ONLY))
+ return true;
+
+ if (chan->flags & IEEE80211_CHAN_NO_IR)
+ return false;
+ return true;
+}
+EXPORT_SYMBOL(regulatory_ir_allowed);
+
int __init regulatory_init(void)
{
int err = 0;
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index 4d44cd4..2960024 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -25,6 +25,7 @@ enum nl80211_dfs_regions reg_get_dfs_region(struct wiphy *wiphy);
int regulatory_hint_user(const char *alpha2,
enum nl80211_user_reg_hint_type user_reg_hint_type);
+int regulatory_hint_indoor_user(void);
int reg_device_uevent(struct device *dev, struct kobj_uevent_env *env);
void wiphy_regulatory_register(struct wiphy *wiphy);
--
1.7.10.4
Allow GO operation on a channel marked with IEEE80211_CHAN_INDOOR_ONLY
iff there is a user hint indicating that the platform is operating in
an indoor environment, i.e., the platform is a printer or media center
device.
Signed-off-by: Ilan Peer <[email protected]>
---
net/wireless/chan.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 87a9d0e..4ae3cd0 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -611,14 +611,20 @@ EXPORT_SYMBOL(cfg80211_chandef_usable);
* IEEE80211_CHAN_GO_CONCURRENT and there is an additional station interface
* associated to an AP on the same channel or on the same UNII band
* (assuming that the AP is an authorized master).
+ * In addition allow the GO to operate on a channel on which indoor operation is
+ * allowed, iff we are currently operating in an indoor environment.
*/
static bool cfg80211_go_permissive_chan(struct cfg80211_registered_device *rdev,
struct ieee80211_channel *chan)
{
struct wireless_dev *wdev_iter;
+ struct wiphy *wiphy = wiphy_idx_to_wiphy(rdev->wiphy_idx);
ASSERT_RTNL();
+ if (regulatory_ir_allowed(wiphy, chan))
+ return true;
+
if (!(chan->flags & IEEE80211_CHAN_GO_CONCURRENT))
return false;
--
1.7.10.4
Allow GO operation on a channel marked with IEEE80211_CHAN_GO_CONCURRENT
iff there is an active station interface that is associated to
an AP operating on the same channel in 2.4 or the same UNII band in 5.2
(assuming that the AP is an authorized master)
Note that this is a permissive approach to the FCC definitions,
that require a clear assessment that the device operating the AP is
an authorized master, i.e., with radar detection and DFS capabilities.
It is assumed that such restrictions are enforced by user space.
Furthermore, it is assumed, that if the conditions that allowed for
the operation of the GO on such a channel change, i.e., the station
interface disconnected from the AP, it is the responsibility of user
space to evacuate the GO from the channel.
Signed-off-by: Ilan Peer <[email protected]>
---
include/net/cfg80211.h | 4 ++-
include/net/regulatory.h | 4 +++
net/mac80211/ibss.c | 9 ++++--
net/wireless/Kconfig | 14 ++++++++++
net/wireless/chan.c | 68 ++++++++++++++++++++++++++++++++++++++++++++--
net/wireless/mesh.c | 3 +-
net/wireless/nl80211.c | 11 +++++---
net/wireless/reg.c | 26 ++++++++++++++++++
net/wireless/reg.h | 12 ++++++++
net/wireless/trace.h | 11 +++++---
10 files changed, 146 insertions(+), 16 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index dbc5490..317bd06 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4520,12 +4520,14 @@ void cfg80211_report_obss_beacon(struct wiphy *wiphy,
* cfg80211_reg_can_beacon - check if beaconing is allowed
* @wiphy: the wiphy
* @chandef: the channel definition
+ * @iftype: interface type
*
* Return: %true if there is no secondary channel or the secondary channel(s)
* can be used for beaconing (i.e. is not a radar channel etc.)
*/
bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
- struct cfg80211_chan_def *chandef);
+ struct cfg80211_chan_def *chandef,
+ enum nl80211_iftype iftype);
/*
* cfg80211_ch_switch_notify - update wdev channel and notify userspace
diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index b07cdc9..fab0c37 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -131,6 +131,9 @@ struct regulatory_request {
* all country IE information processed by the regulatory core. This will
* override %REGULATORY_COUNTRY_IE_FOLLOW_POWER as all country IEs will
* be ignored.
+ * @REGULATORY_DISABLE_RELAX_NO_IR: for devices that do not wish to allow the
+ * NO_IR relaxation, which enables transmissions on channels on which
+ * otherwise initiating radiation is not allowed.
*/
enum ieee80211_regulatory_flags {
REGULATORY_CUSTOM_REG = BIT(0),
@@ -138,6 +141,7 @@ enum ieee80211_regulatory_flags {
REGULATORY_DISABLE_BEACON_HINTS = BIT(2),
REGULATORY_COUNTRY_IE_FOLLOW_POWER = BIT(3),
REGULATORY_COUNTRY_IE_IGNORE = BIT(4),
+ REGULATORY_DISABLE_RELAX_NO_IR = BIT(5),
};
struct ieee80211_freq_range {
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 771080e..3503ddb 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -263,7 +263,8 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
/* make a copy of the chandef, it could be modified below. */
chandef = *req_chandef;
chan = chandef.chan;
- if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
+ if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef,
+ NL80211_IFTYPE_ADHOC)) {
if (chandef.width == NL80211_CHAN_WIDTH_5 ||
chandef.width == NL80211_CHAN_WIDTH_10 ||
chandef.width == NL80211_CHAN_WIDTH_20_NOHT ||
@@ -275,7 +276,8 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
chandef.width = NL80211_CHAN_WIDTH_20;
chandef.center_freq1 = chan->center_freq;
/* check again for downgraded chandef */
- if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
+ if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef,
+ NL80211_IFTYPE_ADHOC)) {
sdata_info(sdata,
"Failed to join IBSS, beacons forbidden\n");
return;
@@ -868,7 +870,8 @@ ieee80211_ibss_process_chanswitch(struct ieee80211_sub_if_data *sdata,
goto disconnect;
}
- if (!cfg80211_reg_can_beacon(sdata->local->hw.wiphy, ¶ms.chandef)) {
+ if (!cfg80211_reg_can_beacon(sdata->local->hw.wiphy, ¶ms.chandef,
+ NL80211_IFTYPE_ADHOC)) {
sdata_info(sdata,
"IBSS %pM switches to unsupported channel (%d MHz, width:%d, CF1/2: %d/%d MHz), disconnecting\n",
ifibss->bssid,
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 81c05e4..6335590 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -102,6 +102,20 @@ config CFG80211_REG_CELLULAR_HINTS
This option adds support for drivers that can receive regulatory
hints from cellular base stations
+config CFG80211_REG_RELAX_NO_IR
+ bool "cfg80211 support for NO_IR relaxation"
+ depends on CFG80211_CERTIFICATION_ONUS
+ ---help---
+ This option enables relaxation of the NO_IR flag. The relaxation
+ allows initiating radiation on channels that are marked with the
+ NO_IR flag which forbids transmissions on the channel.
+
+ For example, enabling this option allows the operation of a P2P
+ group owner on channels marked with NO_IR if there is an additional
+ BSS interface which is connected to an AP which is assumed to be
+ an authorized master, i.e., with radar detection support and DFS
+ capabilities
+
config CFG80211_DEFAULT_PS
bool "enable powersave by default"
depends on CFG80211
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 78559b5..87a9d0e 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -605,15 +605,77 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
}
EXPORT_SYMBOL(cfg80211_chandef_usable);
+/*
+ * For GO only, check if the channel can be used under permissive conditions
+ * mandated by the some regulatory bodies, i.e., the channel is marked with
+ * IEEE80211_CHAN_GO_CONCURRENT and there is an additional station interface
+ * associated to an AP on the same channel or on the same UNII band
+ * (assuming that the AP is an authorized master).
+ */
+static bool cfg80211_go_permissive_chan(struct cfg80211_registered_device *rdev,
+ struct ieee80211_channel *chan)
+{
+ struct wireless_dev *wdev_iter;
+
+ ASSERT_RTNL();
+
+ if (!(chan->flags & IEEE80211_CHAN_GO_CONCURRENT))
+ return false;
+
+ list_for_each_entry(wdev_iter, &rdev->wdev_list, list) {
+ struct ieee80211_channel *other_chan = NULL;
+ int r1, r2;
+
+ if (wdev_iter->iftype != NL80211_IFTYPE_STATION ||
+ !netif_running(wdev_iter->netdev))
+ continue;
+
+ wdev_lock(wdev_iter);
+ if (wdev_iter->current_bss)
+ other_chan = wdev_iter->current_bss->pub.channel;
+ wdev_unlock(wdev_iter);
+
+ if (!other_chan)
+ continue;
+
+ if (chan == other_chan)
+ return true;
+
+ if (chan->band != IEEE80211_BAND_5GHZ)
+ continue;
+
+ r1 = cfg80211_get_unii(chan->center_freq);
+ r2 = cfg80211_get_unii(other_chan->center_freq);
+
+ if (r1 != -EINVAL && r1 == r2)
+ return true;
+ }
+
+ return false;
+}
+
bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
- struct cfg80211_chan_def *chandef)
+ struct cfg80211_chan_def *chandef,
+ enum nl80211_iftype iftype)
{
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
bool res;
u32 prohibited_flags = IEEE80211_CHAN_DISABLED |
- IEEE80211_CHAN_NO_IR |
IEEE80211_CHAN_RADAR;
- trace_cfg80211_reg_can_beacon(wiphy, chandef);
+ trace_cfg80211_reg_can_beacon(wiphy, chandef, iftype);
+
+ /*
+ * Under certain conditions suggested by the some regulatory bodies
+ * a GO can operate on channels marked with IEEE80211_NO_IR
+ * so set this flag only if such relaxations are not enabled and
+ * the conditions are not met.
+ */
+ if (iftype != NL80211_IFTYPE_P2P_GO ||
+ !config_enabled(CONFIG_CFG80211_REG_RELAX_NO_IR) ||
+ (wiphy->regulatory_flags & REGULATORY_DISABLE_RELAX_NO_IR) ||
+ !cfg80211_go_permissive_chan(rdev, chandef->chan))
+ prohibited_flags |= IEEE80211_CHAN_NO_IR;
if (cfg80211_chandef_dfs_required(wiphy, chandef) > 0 &&
cfg80211_chandef_dfs_available(wiphy, chandef)) {
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index 8858624..93c4d42 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -175,7 +175,8 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
scan_width);
}
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef))
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef,
+ NL80211_IFTYPE_MESH_POINT))
return -EINVAL;
err = cfg80211_chandef_dfs_required(wdev->wiphy, &setup->chandef);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 3c1587f..b37b36e 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1914,7 +1914,7 @@ static int __nl80211_set_channel(struct cfg80211_registered_device *rdev,
result = -EBUSY;
break;
}
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, &chandef)) {
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, &chandef, iftype)) {
result = -EINVAL;
break;
}
@@ -3263,7 +3263,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
} else if (!nl80211_get_ap_channel(rdev, ¶ms))
return -EINVAL;
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef))
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef,
+ wdev->iftype))
return -EINVAL;
err = cfg80211_chandef_dfs_required(wdev->wiphy, ¶ms.chandef);
@@ -5852,7 +5853,8 @@ skip_beacons:
if (err)
return err;
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef))
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef,
+ wdev->iftype))
return -EINVAL;
if (dev->ieee80211_ptr->iftype == NL80211_IFTYPE_AP ||
@@ -6623,7 +6625,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
if (err)
return err;
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef))
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef,
+ NL80211_IFTYPE_ADHOC))
return -EINVAL;
switch (ibss.chandef.width) {
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 8a81913..ec38f5d 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2489,6 +2489,32 @@ static void reg_timeout_work(struct work_struct *work)
rtnl_unlock();
}
+int cfg80211_get_unii(int freq)
+{
+ /* UNII-1 */
+ if (freq >= 5150 && freq <= 5250)
+ return 0;
+
+ /* UNII-2A */
+ if (freq > 5250 && freq <= 5350)
+ return 1;
+
+ /* UNII-2B */
+ if (freq > 5350 && freq <= 5470)
+ return 2;
+
+ /* UNII-2C */
+ if (freq > 5470 && freq <= 5725)
+ return 3;
+
+ /* UNII-3 */
+ if (freq > 5725 && freq <= 5825)
+ return 4;
+
+ WARN_ON(1);
+ return -EINVAL;
+}
+
int __init regulatory_init(void)
{
int err = 0;
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index 02bd8f4..4d44cd4 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -103,4 +103,16 @@ void regulatory_hint_country_ie(struct wiphy *wiphy,
*/
void regulatory_hint_disconnect(void);
+/**
+ * cfg80211_get_unii - get the U-NII band for the frequency
+ * @freq: the frequency for which we want to get the UNII band.
+
+ * Get a value specifying the U-NII band frequency belongs to.
+ * U-NII bands are defined by the FCC in C.F.R 47 part 15.
+ *
+ * Returns -EINVAL if freq is invalid, 0 for UNII-1, 1 for UNII-2A,
+ * 2 for UNII-2B, 3 for UNII-2C and 4 for UNII-3.
+ */
+int cfg80211_get_unii(int freq);
+
#endif /* __NET_WIRELESS_REG_H */
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index fbcc23e..3ba80c1 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2189,18 +2189,21 @@ TRACE_EVENT(cfg80211_cqm_rssi_notify,
);
TRACE_EVENT(cfg80211_reg_can_beacon,
- TP_PROTO(struct wiphy *wiphy, struct cfg80211_chan_def *chandef),
- TP_ARGS(wiphy, chandef),
+ TP_PROTO(struct wiphy *wiphy, struct cfg80211_chan_def *chandef,
+ enum nl80211_iftype iftype),
+ TP_ARGS(wiphy, chandef, iftype),
TP_STRUCT__entry(
WIPHY_ENTRY
CHAN_DEF_ENTRY
+ __field(enum nl80211_iftype, iftype)
),
TP_fast_assign(
WIPHY_ASSIGN;
CHAN_DEF_ASSIGN(chandef);
+ __entry->iftype = iftype;
),
- TP_printk(WIPHY_PR_FMT ", " CHAN_DEF_PR_FMT,
- WIPHY_PR_ARG, CHAN_DEF_PR_ARG)
+ TP_printk(WIPHY_PR_FMT ", " CHAN_DEF_PR_FMT ", iftype=%d",
+ WIPHY_PR_ARG, CHAN_DEF_PR_ARG, __entry->iftype)
);
TRACE_EVENT(cfg80211_chandef_dfs_required,
--
1.7.10.4
On Mon, 2014-01-27 at 12:21 +0200, Ilan Peer wrote:
> It is assumed that such restrictions are enforced by user space.
> Furthermore, it is assumed, that if the conditions that allowed for
> the operation of the GO on such a channel change, i.e., the station
> interface disconnected from the AP, it is the responsibility of user
> space to evacuate the GO from the channel.
For the latter here, don't we need some sort of flag with userspace
saying "trust me, I know what I'm doing"? Or put another way - how does
this not make us break compliance when running with old versions of
wpa_supplicant?
johannes
> From: Peer, Ilan
> Sent: Monday, January 27, 2014 12:22
> To: [email protected]
> Cc: [email protected]; Peer, Ilan
> Subject: [PATCH v3 0/6] Enable additional channels for use
>
> This set addresses comments from Luis:
>
> 1. Added a regulatory flag that can be used by drivers to disable the P2P
> GO relaxation.
> 2. Renamed the configuration option to
> CONFIG_CFG80211_REG_P2P_GO_RELAX.
Correction. Renamed it to CONFIG_CFG80211_REG_RELAX_NO_IR ...
Ilan.
On Mon, 2014-01-27 at 12:21 +0200, Ilan Peer wrote:
> switch (user_reg_hint_type) {
> case NL80211_USER_REG_HINT_USER:
> case NL80211_USER_REG_HINT_CELL_BASE:
> - break;
> + if (!info->attrs[NL80211_ATTR_REG_ALPHA2])
> + return -EINVAL;
> +
> + data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
> + return regulatory_hint_user(data, user_reg_hint_type);
> + case NL80211_USER_REG_HINT_INDOOR:
> + return regulatory_hint_indoor_user();
> default:
> return -EINVAL;
> }
>
> - r = regulatory_hint_user(data, user_reg_hint_type);
> -
> - return r;
> + return 0;
Isn't that "return 0" dead code now?
johannes
On Sun, Feb 9, 2014 at 8:06 AM, Peer, Ilan <[email protected]> wrote:
> Did you get a chance to look at this patch set?
Looking at them now.
Luis
I'll abandon this change ...
Thanks,
Ilan.
> -----Original Message-----
> From: Luis R. Rodriguez [mailto:[email protected]] On Behalf Of Luis R.
> Rodriguez
> Sent: Wednesday, February 19, 2014 02:15
> To: Peer, Ilan
> Cc: [email protected]; [email protected]
> 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 <[email protected]>
>
> 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.
On Wed, Feb 19, 2014 at 11:58 PM, Peer, Ilan <[email protected]> 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
Hi Luis,
Did you get a chance to look at this patch set?
Thanks in advance,
Ilan.
> -----Original Message-----
> From: Peer, Ilan
> Sent: Monday, January 27, 2014 12:22
> To: [email protected]
> Cc: [email protected]; Peer, Ilan
> Subject: [PATCH v3 0/6] Enable additional channels for use
>
> This set addresses comments from Luis:
>
> 1. Added a regulatory flag that can be used by drivers to disable the P2P
> GO relaxation.
> 2. Renamed the configuration option to
> CONFIG_CFG80211_REG_P2P_GO_RELAX.
> 3. Some code cleanups.
>
> ------
>
> As before, this series addresses the option of enabling additional channels
> for use based on the following relaxations:
>
> 1. Indoor operation, where a device can use channels requiring indoor
> operation, subject to that it can guarantee indoor operation.
> 2. Concurrent GO operation, where devices may instantiate a P2P GO
> while they are under the guidance of an authorized master.
>
> The series includes:
>
> * Some clarification (mainly in documentation) about the intended usage of
> channels marked as INDOOR_ONLY and CONCURRENT GO.
> * Mapping of NL80211_RFF_NO_OUTDOOR to
> NL80211_CHAN_INDOOR_ONLY
> * Support for a user hint that the platform is operating in an indoor
> environment, i.e., channel marked as INDOOR_ONLY can be used.
> * Allow initiating radiation on channel marked with INDOOR_ONLY also
> for scanning an frame injection in monitor mode.
> * Some additional fixes for comments I got.
>
> Following is an example of a possible channel map that can be used to allow
> the INDOOR_ONLY and CONCURRENT_GO relaxations. Note that:
>
> * Channels 12,13 are marked as Concurrent GO, so even in the lack of exact
> information about the current regulatory domain, these channels can be
> used
> for GO instantiation based on the concurrent GO relaxation.
> * The above is also true for channels 149-165 (a.k.a U-NII 3).
> * Channels 36-48 (a.k.a thee U-NII 1), are marked both with Concurrent GO
> and
> indoor only. While the Concurrent GO can be used as described above, the
> indoor only setting allows to use these channels given the platform is
> identified as an indoor one, i.e., media server.
>
> 2412 MHz [1] (16.0 dBm)
> 2417 MHz [2] (16.0 dBm)
> 2422 MHz [3] (16.0 dBm)
> 2427 MHz [4] (16.0 dBm)
> 2432 MHz [5] (16.0 dBm)
> 2437 MHz [6] (16.0 dBm)
> 2442 MHz [7] (16.0 dBm)
> 2447 MHz [8] (16.0 dBm)
> 2452 MHz [9] (16.0 dBm)
> 2457 MHz [10] (16.0 dBm)
> 2462 MHz [11] (16.0 dBm)
> 2467 MHz [12] (16.0 dBm) (no IR, Concurrent GO)
> 2472 MHz [13] (16.0 dBm) (no IR, Concurrent GO)
> 5180 MHz [36] (16.0 dBm) (no IR, Indoor Only, Concurrent GO)
> 5200 MHz [40] (16.0 dBm) (no IR, Indoor Only, Concurrent GO)
> 5220 MHz [44] (16.0 dBm) (no IR, Indoor Only, Concurrent GO)
> 5240 MHz [48] (16.0 dBm) (no IR, Indoor Only, Concurrent GO)
> 5260 MHz [52] (16.0 dBm) (no IR, radar detection)
> 5280 MHz [56] (16.0 dBm) (no IR, radar detection)
> 5300 MHz [60] (16.0 dBm) (no IR, radar detection)
> 5320 MHz [64] (16.0 dBm) (no IR, radar detection)
> 5500 MHz [100] (16.0 dBm) (no IR, radar detection)
> 5520 MHz [104] (16.0 dBm) (no IR, radar detection)
> 5540 MHz [108] (16.0 dBm) (no IR, radar detection)
> 5560 MHz [112] (16.0 dBm) (no IR, radar detection)
> 5580 MHz [116] (16.0 dBm) (no IR, radar detection)
> 5600 MHz [120] (16.0 dBm) (no IR, radar detection)
> 5620 MHz [124] (16.0 dBm) (no IR, radar detection)
> 5640 MHz [128] (16.0 dBm) (no IR, radar detection)
> 5660 MHz [132] (16.0 dBm) (no IR, radar detection)
> 5680 MHz [136] (16.0 dBm) (no IR, radar detection)
> 5700 MHz [140] (16.0 dBm) (no IR, radar detection)
> 5720 MHz [144] (16.0 dBm) (no IR, radar detection)
> 5745 MHz [149] (16.0 dBm) (no IR, Concurrent GO)
> 5765 MHz [153] (16.0 dBm) (no IR, Concurrent GO)
> 5785 MHz [157] (16.0 dBm) (no IR, Concurrent GO)
> 5805 MHz [161] (16.0 dBm) (no IR, Concurrent GO)
> 5825 MHz [165] (16.0 dBm) (no IR, Concurrent GO)
>
> Thanks in advance,
>
> Ilan.
>
> David Spinadel (1):
> cfg80211: Add indoor only and GO concurrent channel attributes
>
> Ilan Peer (5):
> cfg80211: Add Kconfig option for cellular BS hints
> cfg80211: Enable GO operation on additional channels
> cfg80211: Add an option to hint indoor operation
> cfg80211: Enable GO operation on indoor channels
> mac80211: Enable initiating radiation on indoor channels
>
> include/net/cfg80211.h | 41 ++++++++++++++++++++-
> include/net/regulatory.h | 4 ++
> include/uapi/linux/nl80211.h | 10 +++++
> net/mac80211/ibss.c | 9 +++--
> net/mac80211/scan.c | 15 +++++---
> net/mac80211/tx.c | 3 +-
> net/wireless/Kconfig | 21 +++++++++++
> net/wireless/chan.c | 74
> +++++++++++++++++++++++++++++++++++--
> net/wireless/mesh.c | 3 +-
> net/wireless/nl80211.c | 35 +++++++++++-------
> net/wireless/reg.c | 84
> ++++++++++++++++++++++++++++++++++++++++--
> net/wireless/reg.h | 13 +++++++
> net/wireless/trace.h | 11 ++++--
> 13 files changed, 286 insertions(+), 37 deletions(-)
>
> --
> 1.7.10.4
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 <[email protected]>
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
On Tue, Feb 18, 2014 at 2:17 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Sun, Feb 9, 2014 at 8:06 AM, Peer, Ilan <[email protected]> wrote:
>> Did you get a chance to look at this patch set?
>
> Looking at them now.
Please CC me on future patches you'd like me to review as well, it'll
help digging them up.
Luis
On Sat, Feb 22, 2014 at 10:55 AM, Peer, Ilan <[email protected]> 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
Add the option to hint the wireless core that it is operating in an indoor
environment.
In addition add regulatory_ir_allowed(), that can be used to
test if initiation radiation is allowed based on the channel flags
and the wireless core indoor hint.
Signed-off-by: Ilan Peer <[email protected]>
---
include/net/cfg80211.h | 14 +++++++++++
include/uapi/linux/nl80211.h | 3 +++
net/wireless/nl80211.c | 18 ++++++--------
net/wireless/reg.c | 54 +++++++++++++++++++++++++++++++++++++++---
net/wireless/reg.h | 1 +
5 files changed, 76 insertions(+), 14 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 317bd06..6e6c42c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3627,6 +3627,20 @@ const struct ieee80211_reg_rule *freq_reg_info(struct wiphy *wiphy,
*/
const char *reg_initiator_name(enum nl80211_reg_initiator initiator);
+/**
+ * regulatory_ir_allowed - is it allowed to initiate radiation on the channel.
+ * @wiphy: the wiphy for which we want to test channel.
+ * @chan: the channel
+ *
+ * Generally, it is not allowed to initiate radiation on a channel marked with
+ * IEEE80211_CHAN_NO_IR. The exception is operation on channels marked with
+ * IEEE80211_CHAN_INDOOR_ONLY. For such channels, initiating radiation is
+ * allowed iff the wireless core was notified that it operates in an indoor
+ * environment.
+ */
+bool regulatory_ir_allowed(struct wiphy *wiphy,
+ struct ieee80211_channel *chan);
+
/*
* callbacks for asynchronous cfg80211 methods, notification
* functions and BSS handling helpers
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 06440ac..1dbf6d3 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2533,10 +2533,13 @@ enum nl80211_dfs_regions {
* present has been registered with the wireless core that
* has listed NL80211_FEATURE_CELL_BASE_REG_HINTS as a
* supported feature.
+ * @NL80211_USER_REG_HINT_INDOOR: a user sent an hint indicating that the
+ * platform is operating in an indoor environment.
*/
enum nl80211_user_reg_hint_type {
NL80211_USER_REG_HINT_USER = 0,
NL80211_USER_REG_HINT_CELL_BASE = 1,
+ NL80211_USER_REG_HINT_INDOOR = 2,
};
/**
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b37b36e..cac9ae4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4664,7 +4664,6 @@ static int parse_reg_rule(struct nlattr *tb[],
static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
{
- int r;
char *data = NULL;
enum nl80211_user_reg_hint_type user_reg_hint_type;
@@ -4677,11 +4676,6 @@ static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
if (unlikely(!rcu_access_pointer(cfg80211_regdomain)))
return -EINPROGRESS;
- if (!info->attrs[NL80211_ATTR_REG_ALPHA2])
- return -EINVAL;
-
- data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
-
if (info->attrs[NL80211_ATTR_USER_REG_HINT_TYPE])
user_reg_hint_type =
nla_get_u32(info->attrs[NL80211_ATTR_USER_REG_HINT_TYPE]);
@@ -4691,14 +4685,16 @@ static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
switch (user_reg_hint_type) {
case NL80211_USER_REG_HINT_USER:
case NL80211_USER_REG_HINT_CELL_BASE:
- break;
+ if (!info->attrs[NL80211_ATTR_REG_ALPHA2])
+ return -EINVAL;
+
+ data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
+ return regulatory_hint_user(data, user_reg_hint_type);
+ case NL80211_USER_REG_HINT_INDOOR:
+ return regulatory_hint_indoor_user();
default:
return -EINVAL;
}
-
- r = regulatory_hint_user(data, user_reg_hint_type);
-
- return r;
}
static int nl80211_get_mesh_config(struct sk_buff *skb,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index ec38f5d..2f2d5db 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -110,6 +110,14 @@ const struct ieee80211_regdomain __rcu *cfg80211_regdomain;
*/
static int reg_num_devs_support_basehint;
+/*
+ * State variable indicating if the platform on which the devices
+ * are attached is operating in an indoor environment. The state variable
+ * is relevant for all registered devices.
+ * Note: currently not protected by any synchronization primitive.
+ */
+static bool reg_is_indoor;
+
static const struct ieee80211_regdomain *get_cfg80211_regdom(void)
{
return rtnl_dereference(cfg80211_regdomain);
@@ -1014,6 +1022,13 @@ static bool reg_request_cell_base(struct regulatory_request *request)
return request->user_reg_hint_type == NL80211_USER_REG_HINT_CELL_BASE;
}
+static bool reg_request_indoor(struct regulatory_request *request)
+{
+ if (request->initiator != NL80211_REGDOM_SET_BY_USER)
+ return false;
+ return request->user_reg_hint_type == NL80211_USER_REG_HINT_INDOOR;
+}
+
bool reg_last_request_cell_base(void)
{
return reg_request_cell_base(get_last_request());
@@ -1450,6 +1465,11 @@ __reg_process_hint_user(struct regulatory_request *user_request)
{
struct regulatory_request *lr = get_last_request();
+ if (reg_request_indoor(user_request)) {
+ reg_is_indoor = true;
+ return REG_REQ_ALREADY_SET;
+ }
+
if (reg_request_cell_base(user_request))
return reg_ignore_cell_hint(user_request);
@@ -1685,9 +1705,6 @@ static void reg_process_hint(struct regulatory_request *reg_request)
struct wiphy *wiphy = NULL;
enum reg_request_treatment treatment;
- if (WARN_ON(!reg_request->alpha2))
- return;
-
if (reg_request->wiphy_idx != WIPHY_IDX_INVALID)
wiphy = wiphy_idx_to_wiphy(reg_request->wiphy_idx);
@@ -1847,6 +1864,22 @@ int regulatory_hint_user(const char *alpha2,
return 0;
}
+int regulatory_hint_indoor_user(void)
+{
+ struct regulatory_request *request;
+
+ request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ if (!request)
+ return -ENOMEM;
+
+ request->wiphy_idx = WIPHY_IDX_INVALID;
+ request->initiator = NL80211_REGDOM_SET_BY_USER;
+ request->user_reg_hint_type = NL80211_USER_REG_HINT_INDOOR;
+ queue_regulatory_request(request);
+
+ return 0;
+}
+
/* Driver hints */
int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
{
@@ -2014,6 +2047,8 @@ static void restore_regulatory_settings(bool reset_user)
ASSERT_RTNL();
+ reg_is_indoor = false;
+
reset_regdomains(true, &world_regdom);
restore_alpha2(alpha2, reset_user);
@@ -2515,6 +2550,19 @@ int cfg80211_get_unii(int freq)
return -EINVAL;
}
+bool regulatory_ir_allowed(struct wiphy *wiphy, struct ieee80211_channel *chan)
+{
+ if (config_enabled(CONFIG_CFG80211_REG_RELAX_NO_IR) &&
+ !(wiphy->regulatory_flags & REGULATORY_DISABLE_RELAX_NO_IR) &&
+ reg_is_indoor && (chan->flags & IEEE80211_CHAN_INDOOR_ONLY))
+ return true;
+
+ if (chan->flags & IEEE80211_CHAN_NO_IR)
+ return false;
+ return true;
+}
+EXPORT_SYMBOL(regulatory_ir_allowed);
+
int __init regulatory_init(void)
{
int err = 0;
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index 4d44cd4..2960024 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -25,6 +25,7 @@ enum nl80211_dfs_regions reg_get_dfs_region(struct wiphy *wiphy);
int regulatory_hint_user(const char *alpha2,
enum nl80211_user_reg_hint_type user_reg_hint_type);
+int regulatory_hint_indoor_user(void);
int reg_device_uevent(struct device *dev, struct kobj_uevent_env *env);
void wiphy_regulatory_register(struct wiphy *wiphy);
--
1.7.10.4
PiA+PiBUaGUgb3JpZ2luYWwgYmVhY29uIGhpbnQgbWVjaGFuaXNtIGlzIHZlcnkgZXhwYW5zaXZl
IHRvIGFsbCBiZWFjb25zDQo+ID4+IG9uIG5vbiA1IEdIeiBERlMgY2hhbm5lbHMgYW5kIG5vbiAy
LjQgY2hhbm5lbA0KPiA+PiAxMiBvciAxMy4gSWYgYSB2ZW5kb3IgY2FuIHBvc3NpYmx5IG5vdCBs
aWtlIHRoYXQgYmVhY29uIGhpbnQNCj4gPj4gaW1wbGVtZW50YXRpb24gYXMgaXRzIHRvbyBwZXJt
aXNzaXZlIChhbmQgSSBkb24ndCB0aGluayBpdCBpcykgYnV0DQo+ID4+IHRoZXkgZG8gd2FudCB0
byB0cnVzdCBiZWFjb24gaGludHMgZnJvbSBBUHMgaW4gdGhlIGNhc2UgeW91IGFyZQ0KPiA+PiBk
ZXNjcmliaW5nIHRoZW4geW91IGNhbiBlbmFibGUgYSBuZXcgZmVhdHVyZSBmbGFnIHRvIGRpc3Rp
bmd1aXNoDQo+ID4+IHRoaXMuIFRoZSBiZWFjb24gaW5mcmFzdHJ1Y3R1cmUgY29kZSB3b3VsZCB0
aGVuIGlnbm9yZSB0aGUgcmVndWxhcg0KPiA+PiBiZWFjb24gaGludHMgb24gZGV2aWNlcyB0aGF0
IGRvbid0IGhhdmUgdGhlIG9sZCBmbGFnLCBidXQgd291bGQgdHJ1c3QNCj4gPj4gdGhpcyBuZXcg
Zm9ybSBvZiBiZWFjb24gaGludC4gSWYgYSBkZXZpY2Ugc3VwcG9ydGVkIHRoZSBvbGQgYWxsDQo+
ID4+IGluY2x1c2l2ZSBmbGFnIHRoZXknZCB0cnVzdCBib3RoLiBZb3UnZCBoYXZlIHRvIHVwZGF0
ZSB0aGUga2RvY3MgZm9yIHRoZSBvbGQNCj4gb25lLCBhbmQgbGlrZWx5IGFkZCBhIG5ldyByb3V0
aW5lIHNpbWlsYXIgdG8gcmVndWxhdG9yeV9oaW50X2ZvdW5kX2JlYWNvbigpLg0KPiA+Pg0KPiA+
DQo+ID4gVGhpcyBtYWtlIHNlbnNlIChhbHNvIGdvdCBhIGRpcmVjdCBhbnN3ZXIgZnJvbSBvdXIg
cmVndWxhdG9yeSBmb2xrcyBvbg0KPiA+IHRoaXMgLi4uIGZpbmFsbHkgOykpDQo+IA0KPiBPaCB3
b3csIGFyZSB0aGV5IG9uIHRoZSB3aXJlbGVzcy1yZWdkYiBsaXN0Pw0KDQpOb3Qgc3VyZSAuLi4g
SSBhc2tlZCB0aGVtIHRvIGpvaW4gc29tZSB0aW1lIGFnbyAuLi4NCg0KPiANCj4gPj4gSSdtIG5v
dCBzdXJlIGl0cyB3b3J0aCBpdCB0aG91Z2gsIEknZCByYXRoZXIgcHVzaCB2ZW5kb3JzIHRvIGNv
bnNpZGVyDQo+ID4+IGZpcnN0IHVzaW5nIHRoZSByZWd1bGFyIGJlY2FvbiBoaW50IG1lY2hhbmlz
bSBhbmQgdHJ1c3RpbmcgaXQuIE1heWJlDQo+ID4+IGRldmljZXMgdGhhdCB3YW50IHRoaXMgbmV3
IGZ1bmN0aW9uYWxpdHkgeW91IGFyZSB0cnVzdGluZyBzaG91bGQNCj4gPj4gaW1wbGljYXRlIHJl
dmlzaW5nIHRydXN0aW5nIGJlYWNvbiBoaW50IG1lY2hhbmlzbSA/DQo+ID4+DQo+ID4NCj4gPiBP
dXIgcmVndWxhdG9yeSBwZW9wbGUgc2FpZCB0aGF0IGEgc2ltaWxhciBhcHByb2FjaCBpcyBXSVAg
aW4gdGhlIEZDQyB3aGVyZQ0KPiB0aGV5IGFyZSB3aWxsaW5nIHRvIHVzZSBhIHNpbWlsYXIgcmVs
YXhhdGlvbiBhcyB0aGUgYmVhY29ucyBoaW50cyBidXQgd2l0aCBzb21lDQo+IGxpbWl0YXRpb25z
IHN1Y2ggYXMgaGF2aW5nIGF0IGxlYXN0IGEgbnVtYmVyIG9mIEFQcyBvcGVyYXRpbmcgb24gdGhl
IGNoYW5uZWwNCj4gZXRjLg0KPiANCj4gVGhhdCBzZWVtcyB0byBiZSBiaWFzZWQgdG93YXJkcyBw
b3B1bGF0ZWQgc3BlY3RydW0gYXJlYXMuIEkgc3VzcGVjdCB0aGUNCj4gY29uZmxpY3QgaGVyZSB3
b3VsZCBiZSBub3Qgd2FudGluZyB0byB0cnVzdCBHTydzLCBidXQgY29uc2lkZXINCg0KQWN0dWFs
bHkgbm8uIFRoZSBjb25jZXJuIGlzIG1vcmUgdG8gdGhlIGluY3JlYXNpbmcgbnVtYmVyIG9mIEFQ
cyB0aGF0IGFyZSBib3VnaHQgaXQgb25lIGNvdW50cnkgYW5kIHRoZW4gdXNlZCBpbiBzb21lIG90
aGVyIGNvdW50cnksIHRodXMgcG9zc2libHkgdmlvbGF0aW5nIHJlZ3VsYXRvcnkuIEFGQUlLLCBv
bmUgb2YgdGhlIG9wdGlvbnMgdGhleSBhcmUgY29uc2lkZXJpbmcgaXMgdG8gYWxsb3cgc3VjaCBy
ZWxheGF0aW9uIGlmIGJlYWNvbiBmcm9tIHNldmVyYWwgKD4xKSBkaWZmZXJlbnQgQlNTIHdhcyBy
ZWNlaXZlZC4NCg0KPiB0aGlzOiB3aHkgbm90PyBHTydzIHdvbid0IElSIHVubGVzcyB0aGV5IGhh
dmUgc29tZSBoZXVyaXN0aWNzIGxpa2UgdGhlIG9uZQ0KPiB5b3UgYXJlIGFkZGluZyB0byBkZXRl
cm1pbmUgaXRzIE9LIHRvIElSLiBGdXJ0aGVybW9yZSBvdXIgb3duIGJlYWNvbiBoaW50DQo+IGlu
ZnJhc3RydWN0dXJlIGluIHRoZSBrZXJuZWwgZG9lcyBjaGVjayB0byBlbnN1cmUgd2UgZG9uJ3Qg
dHJ1c3QgbWVzaCBvcg0KPiBJQlNTLCB3ZSBlbnN1cmUgaXRzIGZyb20gYW4gRVNTLCBpZSBXTEFO
X0NBUEFCSUxJVFlfRVNTOg0KPiANCj4gaWYgKHJlcy0+cHViLmNhcGFiaWxpdHkgJiBXTEFOX0NB
UEFCSUxJVFlfRVNTKQ0KPiAgIHJlZ3VsYXRvcnlfaGludF9mb3VuZF9iZWFjb24od2lwaHksIGNo
YW5uZWwsIGdmcCk7DQo+IA0KPiBCVFcgSSBqdXN0IHVwZGF0ZWQgb3VyIGRvY3VtZW50YXRpb24g
Zm9yIHRoaXMsIGhlcmU6DQo+IA0KPiBodHRwOi8vd2lyZWxlc3Mua2VybmVsLm9yZy9lbi9kZXZl
bG9wZXJzL1JlZ3VsYXRvcnkvcHJvY2Vzc2luZ19ydWxlcyNCZWENCj4gY29uX2hpbnRzDQo+IA0K
PiBQbGVhc2UgZmVlbCBmcmVlIHRvIHNvY2lhbGl6ZSB0aGlzIGFsZ29yaXRobSB3aXRoIHRoZSBG
Q0MgUEhCcyBhbmQgb3RoZXINCj4gcmVndWxhdG9yeSBmb2xrcyB0byBzZWUgaWYgdGhleSBjYW4g
c2VlIGFueSBsb29waG9sZXMgb3Igd291bGQgcHJlZmVyIGFueQ0KPiBvdGhlciBjb25zaWRlcmF0
aW9ucyBvciBBUElzIHRvIGJlIGV4dGVuZGVkLiBJIHRoaW5rIHRoaXMgaXMgcHJldHR5IHNhZmUg
YW5kIEknZA0KPiBsb3ZlIHRvIGtub3cgb2YgaXNzdWVzIHRoYXQgcGVvcGxlIGNvdWxkIGJlIGNv
bmNlcm5lZCBvdmVyIHRoaXMuDQo+IA0KDQpTdXJlLCBidXQgYXMgSSB3cm90ZSBhYm92ZSwgdGhl
IEZDQyBkb2VzIG5vdCBjb25zaWRlciBhIGJlYWNvbiBvZiBhIHNpbmdsZSBCU1Mgc3VmZmljaWVu
dCBhbmQgd291bGQgbGlrZSBiZXR0ZXIgYXNzdXJhbmNlIHRoYXQgaXQgaXMgc2FmZSB0byBlbmFi
bGUgSVIuIFdpbGwgdXBkYXRlIG9uY2UgSSBnZXQgc29tZSBhbnN3ZXJzLg0KDQo+ID4gSWYgaXRz
IG9rIHdpdGggeW91IEkgcHJlZmVyIHRvIGxlYXZlIHRoaW5ncyBhcyBpcyBmb3Igbm93Lg0KPiAN
Cj4gWW91IG1lYW4geW91J2xsIGRyb3AgdGhpcyBwYXRjaCBmb3Igc3VyZSB0aGVuIHdoaWxlIHdl
IGhvcGUgYSBzb2NpYWxpemF0aW9uIG9mDQo+IG91ciBhbGdvcml0aG0gY2FuIGJlIHByb3ZlbiBh
cyByZWFzb25hYmxlIGZvciBJbnRlbCB0byBlbWJyYWNlIDopID8NCg0KRFNUTSA7KSAuLi4gYW55
d2F5LCBJJ2xsIGRyb3AgaXQgc2luY2UgSSBkbyBub3Qgc2VlIHRoZSBiZW5lZml0IGFuZCBzaW5j
ZSB5b3VyIGFyZ3VtZW50IGFib3V0IGluZG9vciBub3QgaW1wbHlpbmcgSVIgaXMgdHJ1ZSBhbmQg
SSdtIHdhaXRpbmcgZm9yIGFuc3dlcnMgaWYgdGhpcyBpcyBhbHNvIGFsbG93ZWQgYW5vdGhlciB0
aGUgTk9fSVIgcmVsYXhhdGlvbnMuDQoNClJlZ2FyZHMsDQoNCklsYW4uDQo=
SGkgSm9oYW5uZXMsIA0KDQo+ID4gSXQgaXMgYXNzdW1lZCB0aGF0IHN1Y2ggcmVzdHJpY3Rpb25z
IGFyZSBlbmZvcmNlZCBieSB1c2VyIHNwYWNlLg0KPiA+IEZ1cnRoZXJtb3JlLCBpdCBpcyBhc3N1
bWVkLCB0aGF0IGlmIHRoZSBjb25kaXRpb25zIHRoYXQgYWxsb3dlZCBmb3INCj4gPiB0aGUgb3Bl
cmF0aW9uIG9mIHRoZSBHTyBvbiBzdWNoIGEgY2hhbm5lbCBjaGFuZ2UsIGkuZS4sIHRoZSBzdGF0
aW9uDQo+ID4gaW50ZXJmYWNlIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBBUCwgaXQgaXMgdGhlIHJl
c3BvbnNpYmlsaXR5IG9mIHVzZXINCj4gPiBzcGFjZSB0byBldmFjdWF0ZSB0aGUgR08gZnJvbSB0
aGUgY2hhbm5lbC4NCj4gDQo+IEZvciB0aGUgbGF0dGVyIGhlcmUsIGRvbid0IHdlIG5lZWQgc29t
ZSBzb3J0IG9mIGZsYWcgd2l0aCB1c2Vyc3BhY2Ugc2F5aW5nDQo+ICJ0cnVzdCBtZSwgSSBrbm93
IHdoYXQgSSdtIGRvaW5nIj8gT3IgcHV0IGFub3RoZXIgd2F5IC0gaG93IGRvZXMgdGhpcyBub3QN
Cj4gbWFrZSB1cyBicmVhayBjb21wbGlhbmNlIHdoZW4gcnVubmluZyB3aXRoIG9sZCB2ZXJzaW9u
cyBvZg0KPiB3cGFfc3VwcGxpY2FudD8NCj4gDQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyB3
aWxsIGJlIG5lZWRlZCwgYXMgY3VycmVudCB3cGFfc3VwcGxpY2FudCBsb2dpYyBpcyBub3QgYXdh
cmUgb2YgdGhlIEdPX0NPTkNVUlJFTlQgYW5kIElORE9PUl9PTkxZIGZsYWdzIChsZWF2aW5nIHRo
ZW0gaWdub3JlZCkgYW5kIGRvZXMgbm90IGFsbG93IGluc3RhbnRpYXRpbmcgYW4gQVAvR08gb24g
Y2hhbm5lbHMgbWFya2VkIHdpdGggTk9fSVIuIEluIGFkZGl0aW9uIGFzIHRoaXMgZmVhdHVyZSBt
dXN0IGJlIGVuYWJsZWQgdW5kZXIgQ09ORklHX09OVVMsIEkgZXhwZWN0IHRoYXQgd2hvZXZlciB1
c2VzIGl0IHVzZXMga25vdyB3aGF0J3MgaXMgZG9pbmcuDQoNClN1Y2ggbG9naWMgbWlnaHQgYmUg
bmVlZGVkIGlmIGtlcm5lbCBlbmZvcmNlcyByZWd1bGF0b3J5IGNvbXBsaWFuY2UgYWZ0ZXIgdGhl
IEdPX0NPTkNVUlJFTlQgcmVsYXhhdGlvbiBjb25kaXRpb25zIGFyZSBubyBsb25nZXIgbWV0IChz
dGF0aW9uIGludGVyZmFjZSBsZWF2ZXMgdGhlIGNoYW5uZWwpLCB3aGVyZSBpZiBzdWNoIGEgY2Fz
ZSBpcyB0cnVlLCBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBhZGQgYW4gaW5kaWNhdGlvbiB0
byB0aGUga2VybmVsIHRlbGxpbmcgaXQgdGhhdCB1c2VyIHNwYWNlIGtub3dzIHdoYXQgaXQncyBk
b2luZywgc28gdGhlIGtlcm5lbCB3aWxsIG5vdCBkbyBhbnkgcXVpZXNjaW5nIGxvZ2ljIChzaW1p
bGFyIHRvIHdoYXQgTHVpcyBzdWdnZXN0ZWQpLg0KDQpSZWdhcmRzLA0KDQpJbGFuLg0KDQoNCg0K
DQo=
On Mon, Jan 27, 2014 at 12:21:55PM +0200, Ilan Peer wrote:
> Allow GO operation on a channel marked with IEEE80211_CHAN_GO_CONCURRENT
> iff there is an active station interface that is associated to
> an AP operating on the same channel in 2.4 or the same UNII band in 5.2
> (assuming that the AP is an authorized master)
>
> Note that this is a permissive approach to the FCC definitions,
> that require a clear assessment that the device operating the AP is
> an authorized master, i.e., with radar detection and DFS capabilities.
OK It seems here you are clarifying that the feature is only when
you can verify the AP is DFS-capable. How can you verify that?
> It is assumed that such restrictions are enforced by user space.
> Furthermore, it is assumed, that if the conditions that allowed for
> the operation of the GO on such a channel change, i.e., the station
> interface disconnected from the AP, it is the responsibility of user
> space to evacuate the GO from the channel.
This is a pretty important piece of information as well. Once
these patches go in I really want to make it clear that we should
update the documentation the wiki as noted before.
> Signed-off-by: Ilan Peer <[email protected]>
> ---
> include/net/cfg80211.h | 4 ++-
> include/net/regulatory.h | 4 +++
> net/mac80211/ibss.c | 9 ++++--
> net/wireless/Kconfig | 14 ++++++++++
> net/wireless/chan.c | 68 ++++++++++++++++++++++++++++++++++++++++++++--
> net/wireless/mesh.c | 3 +-
> net/wireless/nl80211.c | 11 +++++---
> net/wireless/reg.c | 26 ++++++++++++++++++
> net/wireless/reg.h | 12 ++++++++
> net/wireless/trace.h | 11 +++++---
> 10 files changed, 146 insertions(+), 16 deletions(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index dbc5490..317bd06 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -4520,12 +4520,14 @@ void cfg80211_report_obss_beacon(struct wiphy *wiphy,
> * cfg80211_reg_can_beacon - check if beaconing is allowed
> * @wiphy: the wiphy
> * @chandef: the channel definition
> + * @iftype: interface type
> *
> * Return: %true if there is no secondary channel or the secondary channel(s)
> * can be used for beaconing (i.e. is not a radar channel etc.)
> */
> bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
> - struct cfg80211_chan_def *chandef);
> + struct cfg80211_chan_def *chandef,
> + enum nl80211_iftype iftype);
>
> /*
> * cfg80211_ch_switch_notify - update wdev channel and notify userspace
> diff --git a/include/net/regulatory.h b/include/net/regulatory.h
> index b07cdc9..fab0c37 100644
> --- a/include/net/regulatory.h
> +++ b/include/net/regulatory.h
> @@ -131,6 +131,9 @@ struct regulatory_request {
> * all country IE information processed by the regulatory core. This will
> * override %REGULATORY_COUNTRY_IE_FOLLOW_POWER as all country IEs will
> * be ignored.
> + * @REGULATORY_DISABLE_RELAX_NO_IR: for devices that do not wish to allow the
> + * NO_IR relaxation, which enables transmissions on channels on which
> + * otherwise initiating radiation is not allowed.
Please provide an example. A read of this documentation likely
cannot guess the available relaxations available, and this is
only obvious to the reader of this patch series. If you are
adding a Kconfig entry you can refer to it, or you can refer
to the channel flags as pointers to further documentation.
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 81c05e4..6335590 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -102,6 +102,20 @@ config CFG80211_REG_CELLULAR_HINTS
> This option adds support for drivers that can receive regulatory
> hints from cellular base stations
>
> +config CFG80211_REG_RELAX_NO_IR
> + bool "cfg80211 support for NO_IR relaxation"
> + depends on CFG80211_CERTIFICATION_ONUS
> + ---help---
> + This option enables relaxation of the NO_IR flag. The relaxation
> + allows initiating radiation on channels that are marked with the
> + NO_IR flag which forbids transmissions on the channel.
> +
> + For example, enabling this option allows the operation of a P2P
> + group owner on channels marked with NO_IR if there is an additional
> + BSS interface which is connected to an AP which is assumed to be
> + an authorized master, i.e., with radar detection support and DFS
> + capabilities
Please use:
This option enables support for relaxation of the NO_IR flag
for situations that certain regulatory bodies have provided
clarifications on how relaxation can occur. This feature
has an inherent dependency on userspace features which must
have been properly tested and as such is not enabled by
default.
A relaxation feature example is allowing the operation of a P2P
group owner (GO) on channels marked with NO_IR if there is an
additional BSS interface which associated to an AP which
userspace assumes or confirems to be an authorized master,
i.e., with radar detection support and DFS capabilities.
Ilan, also extend the above with language similar to the one
I provided on the cellular base station hints if you ended
up adding a device feature capability.
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index 78559b5..87a9d0e 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -605,15 +605,77 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
> }
> EXPORT_SYMBOL(cfg80211_chandef_usable);
>
> +/*
> + * For GO only, check if the channel can be used under permissive conditions
> + * mandated by the some regulatory bodies, i.e., the channel is marked with
> + * IEEE80211_CHAN_GO_CONCURRENT and there is an additional station interface
> + * associated to an AP on the same channel or on the same UNII band
> + * (assuming that the AP is an authorized master).
> + */
> +static bool cfg80211_go_permissive_chan(struct cfg80211_registered_device *rdev,
> + struct ieee80211_channel *chan)
> +{
> + struct wireless_dev *wdev_iter;
> +
> + ASSERT_RTNL();
You can simplify the check that calls this by having the
config_enabled() check here. You can also add the check
for REGULATORY_DISABLE_RELAX_NO_IR here.
> +
> + if (!(chan->flags & IEEE80211_CHAN_GO_CONCURRENT))
> + return false;
> +
> + list_for_each_entry(wdev_iter, &rdev->wdev_list, list) {
> + struct ieee80211_channel *other_chan = NULL;
> + int r1, r2;
> +
> + if (wdev_iter->iftype != NL80211_IFTYPE_STATION ||
> + !netif_running(wdev_iter->netdev))
> + continue;
> +
> + wdev_lock(wdev_iter);
> + if (wdev_iter->current_bss)
> + other_chan = wdev_iter->current_bss->pub.channel;
> + wdev_unlock(wdev_iter);
Please wrap this up into a helper either for this series or after.
Just a friendly reminder :)
> +
> + if (!other_chan)
> + continue;
> +
> + if (chan == other_chan)
> + return true;
This seems to me to indicate that we have allowed here
daisy chaining / trust on another GO who also trusted
its AP. That is, we are leaving it up to the kernel for
the above few lines of code to check if the STA was
associated to an AP that had DFS support. How do we
know the AP the STA was associated to was not another
GO that ran through this permissive check? Is the FCC
happy with that?
Also to be clear, you check for IEEE80211_CHAN_GO_CONCURRENT
only on the caller's channel, not the STA's device, is that
OK ? Lets consider the case case of two different types of
interfaces on the same system. I am aware of at least one
802.11 AP company selling devices with one 802.11 vendor as
the AP and another as the STA. I don't consider this rare
anymore now, as such please think about this case as well.
> +
> + if (chan->band != IEEE80211_BAND_5GHZ)
> + continue;
> +
> + r1 = cfg80211_get_unii(chan->center_freq);
> + r2 = cfg80211_get_unii(other_chan->center_freq);
> +
> + if (r1 != -EINVAL && r1 == r2)
> + return true;
Looks good, the same concern about IEEE80211_CHAN_GO_CONCURRENT
on the other_chan applies here.
> + }
> +
> + return false;
> +}
> +
> bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
> - struct cfg80211_chan_def *chandef)
> + struct cfg80211_chan_def *chandef,
> + enum nl80211_iftype iftype)
> {
> + struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
> bool res;
> u32 prohibited_flags = IEEE80211_CHAN_DISABLED |
> - IEEE80211_CHAN_NO_IR |
> IEEE80211_CHAN_RADAR;
>
> - trace_cfg80211_reg_can_beacon(wiphy, chandef);
> + trace_cfg80211_reg_can_beacon(wiphy, chandef, iftype);
> +
> + /*
> + * Under certain conditions suggested by the some regulatory bodies
> + * a GO can operate on channels marked with IEEE80211_NO_IR
> + * so set this flag only if such relaxations are not enabled and
> + * the conditions are not met.
> + */
> + if (iftype != NL80211_IFTYPE_P2P_GO ||
> + !config_enabled(CONFIG_CFG80211_REG_RELAX_NO_IR) ||
> + (wiphy->regulatory_flags & REGULATORY_DISABLE_RELAX_NO_IR) ||
> + !cfg80211_go_permissive_chan(rdev, chandef->chan))
This is the check I was saying you could simplify by tossing the
config checks and wiphy->regulatory_flags check there.
> + prohibited_flags |= IEEE80211_CHAN_NO_IR;
>
> if (cfg80211_chandef_dfs_required(wiphy, chandef) > 0 &&
> cfg80211_chandef_dfs_available(wiphy, chandef)) {
> diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
> index 8858624..93c4d42 100644
> --- a/net/wireless/mesh.c
> +++ b/net/wireless/mesh.c
> @@ -175,7 +175,8 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
> scan_width);
> }
>
> - if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef))
> + if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef,
> + NL80211_IFTYPE_MESH_POINT))
> return -EINVAL;
>
> err = cfg80211_chandef_dfs_required(wdev->wiphy, &setup->chandef);
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 3c1587f..b37b36e 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -1914,7 +1914,7 @@ static int __nl80211_set_channel(struct cfg80211_registered_device *rdev,
> result = -EBUSY;
> break;
> }
> - if (!cfg80211_reg_can_beacon(&rdev->wiphy, &chandef)) {
> + if (!cfg80211_reg_can_beacon(&rdev->wiphy, &chandef, iftype)) {
> result = -EINVAL;
> break;
> }
> @@ -3263,7 +3263,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
> } else if (!nl80211_get_ap_channel(rdev, ¶ms))
> return -EINVAL;
>
> - if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef))
> + if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef,
> + wdev->iftype))
> return -EINVAL;
>
> err = cfg80211_chandef_dfs_required(wdev->wiphy, ¶ms.chandef);
> @@ -5852,7 +5853,8 @@ skip_beacons:
> if (err)
> return err;
>
> - if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef))
> + if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef,
> + wdev->iftype))
> return -EINVAL;
>
> if (dev->ieee80211_ptr->iftype == NL80211_IFTYPE_AP ||
> @@ -6623,7 +6625,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
> if (err)
> return err;
>
> - if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef))
> + if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef,
> + NL80211_IFTYPE_ADHOC))
> return -EINVAL;
>
> switch (ibss.chandef.width) {
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 8a81913..ec38f5d 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -2489,6 +2489,32 @@ static void reg_timeout_work(struct work_struct *work)
> rtnl_unlock();
> }
>
>
> +int cfg80211_get_unii(int freq)
A reference to where this is documented would be good.
> +{
> + /* UNII-1 */
> + if (freq >= 5150 && freq <= 5250)
> + return 0;
> +
> + /* UNII-2A */
> + if (freq > 5250 && freq <= 5350)
> + return 1;
> +
> + /* UNII-2B */
> + if (freq > 5350 && freq <= 5470)
> + return 2;
> +
> + /* UNII-2C */
> + if (freq > 5470 && freq <= 5725)
> + return 3;
> +
> + /* UNII-3 */
> + if (freq > 5725 && freq <= 5825)
> + return 4;
> +
> + WARN_ON(1);
probably best to avoid that warning -- there are some
4 GHz channels used out there, and pretty sure we'll hit
this fast.
Luis
On Sat, Feb 22, 2014 at 11:23 PM, Peer, Ilan <[email protected]> wrote:
>>
>> On Sat, Feb 22, 2014 at 10:55 AM, Peer, Ilan <[email protected]> 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
On Sun, 2014-02-02 at 19:20 +0000, Peer, Ilan wrote:
> I do not think that this will be needed, as current wpa_supplicant
> logic is not aware of the GO_CONCURRENT and INDOOR_ONLY flags (leaving
> them ignored) and does not allow instantiating an AP/GO on channels
> marked with NO_IR. In addition as this feature must be enabled under
> CONFIG_ONUS, I expect that whoever uses it uses know what's is doing.
Ok, thanks for the clarification. I wasn't sure how existing wpa_s
versions would treat this.
> Such logic might be needed if kernel enforces regulatory compliance
> after the GO_CONCURRENT relaxation conditions are no longer met
> (station interface leaves the channel), where if such a case is true,
> it would be appropriate to add an indication to the kernel telling it
> that user space knows what it's doing, so the kernel will not do any
> quiescing logic (similar to what Luis suggested).
I'm not convinced that is necessary - the "quiescing" would be good I
suppose, but there should be plenty of time before it for userspace to
request an appropriate CSA so I don't think any additional flag is
needed.
Assuming we're talking about the same scenario? I guess it should be
like this:
- STA connected to AP on an "additional" channel
- GO operating on the same channel
- AP starts to advertise CSA
- wpa_s will request CSA for GO as well
- all will be fine
If wpa_s is broken, then at the time that the CSA actually kicks in the
GO would be stopped, since it didn't switch channel, but I don't think
there's a need for any additional flags.
johannes
On Mon, Jan 27, 2014 at 12:21:57PM +0200, Ilan Peer wrote:
> Allow GO operation on a channel marked with IEEE80211_CHAN_INDOOR_ONLY
> iff there is a user hint indicating that the platform is operating in
> an indoor environment, i.e., the platform is a printer or media center
> device.
>
> Signed-off-by: Ilan Peer <[email protected]>
> ---
> net/wireless/chan.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index 87a9d0e..4ae3cd0 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -611,14 +611,20 @@ EXPORT_SYMBOL(cfg80211_chandef_usable);
> * IEEE80211_CHAN_GO_CONCURRENT and there is an additional station interface
> * associated to an AP on the same channel or on the same UNII band
> * (assuming that the AP is an authorized master).
> + * In addition allow the GO to operate on a channel on which indoor operation is
> + * allowed, iff we are currently operating in an indoor environment.
> */
> static bool cfg80211_go_permissive_chan(struct cfg80211_registered_device *rdev,
> struct ieee80211_channel *chan)
> {
> struct wireless_dev *wdev_iter;
> + struct wiphy *wiphy = wiphy_idx_to_wiphy(rdev->wiphy_idx);
>
> ASSERT_RTNL();
>
> + if (regulatory_ir_allowed(wiphy, chan))
> + return true;
> +
> if (!(chan->flags & IEEE80211_CHAN_GO_CONCURRENT))
> return false;
Looks good.
Luis
On Wed, Feb 19, 2014 at 02:52:13PM +0000, Peer, Ilan wrote:
> > Ilan, also extend the above with language similar to the one I provided on the
> > cellular base station hints if you ended up adding a device feature capability.
> >
>
> You mean specify that this option is enabled, drivers can still use
> the device specific flags to disable this?
Yeap! In particular its important to make it clear that
enabling this option isn't enough to get enable this feature,
this option will only be usable on device drivers that have
support for this feature.
> > > +
> > > + if (!other_chan)
> > > + continue;
> > > +
> > > + if (chan == other_chan)
> > > + return true;
> >
> > This seems to me to indicate that we have allowed here daisy chaining / trust
> > on another GO who also trusted its AP. That is, we are leaving it up to the
> > kernel for the above few lines of code to check if the STA was associated to
> > an AP that had DFS support. How do we know the AP the STA was associated
> > to was not another GO that ran through this permissive check? Is the FCC
> > happy with that?
> >
>
> This verification should be done by user space, i.e., if the station
> is a legacy client associated to a GO, then wpa_supplicant should not
> allow the GO_CONCURRENT relaxation. In addition, a GO instantiated on
> channel based on this relaxation should not allow connection from
> legacy clients ... again this should be enforced by user space. System
> wise this should adhere to the FCC expectations and prevent daisy
> chaining.
Wow this is a hugely important piece of information, please toss it into
the documentation both kconfig and wiki (once accepted upstream). As for
references to userspace you can mention supplicant (wpa_supplicant).
> > Also to be clear, you check for IEEE80211_CHAN_GO_CONCURRENT only on
> > the caller's channel, not the STA's device, is that OK ? Lets
> > consider the case case of two different types of interfaces on the
> > same system. I am aware of at least one 802.11 AP company selling
> > devices with one 802.11 vendor as the AP and another as the STA. I
> > don't consider this rare anymore now, as such please think about
> > this case as well.
>
> The property is of the channel so this should suffice. Overall, I
> think that the FCC definition rules are centered on the UNII bands, so
> the rules mandated for a given channel in a specific channel should
> also hold to other channels in the same UNII band. Ultimately, I would
> expect all channels in the same UNII band to share the same settings.
OK.
> The iteration in this case is over all the interfaces of the same
> registered device
This feature seems limited then. Can this be extended to relay on the
information from any other registered device? I suspect folks may soon
enter bug reports for this otherwise. That carefulness here seems to
be an implementation preference, but is it a hard requirement? If not
then please considering revising all registered devices.
Luis
On Mon, Jan 27, 2014 at 12:21:53PM +0200, Ilan Peer wrote:
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index b1f84b0..dbc5490 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -109,6 +109,27 @@ 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.
> + * A channel marked with IEEE80211_CHAN_INDOOR_ONLY can only be used when
> + * there is a clear assessment that the device is operating in an indoor
> + * surroundings, i.e., it is connected to AC power (and not through
> + * portable DC inverters)
Curious, what are the plans to avoid the situation of portable DC
inverters from being used in this case ? Stating that is in
the documentation alludes that this is possible in userspace.
Is it?
> or is under the control of a master that is
> + * acting as an AP and is connected to AC power.
> + * @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.
What do you mean "on 5.2" ? Maybe just "the 5 GHz band" would be better
if this is not UNII specific. If the rule applies to a UNII band then
mentioning the band name nomenclature would make it clearer, ie, UNII-1,
or UNII-2. If this flag could later be used by other 5 GHz UNII bands then
making it in the documentation UNII band agnostic and just using 5 GHz
would suffice, while your handler in code adjusts as regulations change.
> + * Instantiating a GO on a channel marked with IEEE80211_CHAN_GO_CONCURRENT
> + * can be done when there is a clear assessment that the device is
> + * operating under the guidance of an authorized master, i.e., setting up a
> + * GO while the device is also connected to an AP with DFS and radar
> + * detection on the UNII band (however, this example does not imply that
> + * all channels marked with IEEE80211_CHAN_RADAR must also be marked with
> + * IEEE80211_CHAN_GO_CONCURRENT and vise versa).
Your mentioning of DFS here makes things a bit confusing. We should be
distinguishing between the case of a device beign associated to on a BSS
where the AP is on a DFS channel, and the case where the AP is not on
a DFS channel. Are you saying that if IEEE80211_CHAN_GO_CONCURRENT is
enabled on a channel that also has IEEE80211_CHAN_RADAR that the device
can start GO on the same channel if it *doesn't support DFS itself* if
its associated to a real AP, which presumably supports DFS? If so
consider then a third GO which would associate to the secondary GO,
we now have a link of 3 devices and an inherent delay can be created
letting a master device do things. How do we avoid latency issues
in communication in this type of setup?
If IEEE80211_CHAN_GO_CONCURRENT is meant only for channels that do not
have IEEE80211_CHAN_RADAR that makes it simpler but I think you were
trying to clarify that daisy chaning trust on the root AP is valid.
Please clarify both use cases on the documentation.
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 91054fd..06440ac 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -2304,6 +2304,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.
Same UNII band clarification applies here.
Luis
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:[email protected]] On Behalf Of Luis R.
> > Rodriguez
> > Sent: Wednesday, February 19, 2014 02:15
> > To: Peer, Ilan
> > Cc: [email protected]; [email protected]
> > 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 <[email protected]>
> >
> > 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
IA0KPiA+IFN1Y2ggbG9naWMgbWlnaHQgYmUgbmVlZGVkIGlmIGtlcm5lbCBlbmZvcmNlcyByZWd1
bGF0b3J5IGNvbXBsaWFuY2UNCj4gPiBhZnRlciB0aGUgR09fQ09OQ1VSUkVOVCByZWxheGF0aW9u
IGNvbmRpdGlvbnMgYXJlIG5vIGxvbmdlciBtZXQNCj4gPiAoc3RhdGlvbiBpbnRlcmZhY2UgbGVh
dmVzIHRoZSBjaGFubmVsKSwgd2hlcmUgaWYgc3VjaCBhIGNhc2UgaXMgdHJ1ZSwNCj4gPiBpdCB3
b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBhZGQgYW4gaW5kaWNhdGlvbiB0byB0aGUga2VybmVsIHRl
bGxpbmcgaXQNCj4gPiB0aGF0IHVzZXIgc3BhY2Uga25vd3Mgd2hhdCBpdCdzIGRvaW5nLCBzbyB0
aGUga2VybmVsIHdpbGwgbm90IGRvIGFueQ0KPiA+IHF1aWVzY2luZyBsb2dpYyAoc2ltaWxhciB0
byB3aGF0IEx1aXMgc3VnZ2VzdGVkKS4NCj4gDQo+IEknbSBub3QgY29udmluY2VkIHRoYXQgaXMg
bmVjZXNzYXJ5IC0gdGhlICJxdWllc2NpbmciIHdvdWxkIGJlIGdvb2QgSQ0KPiBzdXBwb3NlLCBi
dXQgdGhlcmUgc2hvdWxkIGJlIHBsZW50eSBvZiB0aW1lIGJlZm9yZSBpdCBmb3IgdXNlcnNwYWNl
IHRvDQo+IHJlcXVlc3QgYW4gYXBwcm9wcmlhdGUgQ1NBIHNvIEkgZG9uJ3QgdGhpbmsgYW55IGFk
ZGl0aW9uYWwgZmxhZyBpcyBuZWVkZWQuDQo+IA0KPiBBc3N1bWluZyB3ZSdyZSB0YWxraW5nIGFi
b3V0IHRoZSBzYW1lIHNjZW5hcmlvPyBJIGd1ZXNzIGl0IHNob3VsZCBiZSBsaWtlDQo+IHRoaXM6
DQo+IA0KPiAgLSBTVEEgY29ubmVjdGVkIHRvIEFQIG9uIGFuICJhZGRpdGlvbmFsIiBjaGFubmVs
DQo+ICAtIEdPIG9wZXJhdGluZyBvbiB0aGUgc2FtZSBjaGFubmVsDQo+ICAtIEFQIHN0YXJ0cyB0
byBhZHZlcnRpc2UgQ1NBDQo+ICAtIHdwYV9zIHdpbGwgcmVxdWVzdCBDU0EgZm9yIEdPIGFzIHdl
bGwNCg0KVGhpcyBhbHNvIHJlcXVpcmVzIGEgZml4LCBhcyBjdXJyZW50bHkgdGhlIHdwYV9zdXBw
bGljYW50IGlzIG5vdCBhd2FyZSBvZiB0aGUgc3RhdGlvbiBzd2l0Y2hpbmcgY2hhbm5lbCBkdWUg
dG8gQVAncyBDU0EuDQoNCj4gIC0gYWxsIHdpbGwgYmUgZmluZQ0KDQpZZXMuIFRoZSB3cGFfc3Vw
cGxpY2FudCBzaG91bGQgYmUgYXdhcmUgb2YgdGhlIGN1cnJlbnQgdXNhZ2Ugb2YgdGhlIGNoYW5u
ZWxzIGFuZCBhY3QgYWNjb3JkaW5nbHksIGkuZS4sIGlmIHRoZSBHTyBpcyBlc3RhYmxpc2hlZCBv
biBhIGNoYW5uZWwgZHVlIHRvIEdPX0NPTkNVUlJFTlQgcmVsYXhhdGlvbiwgaXQgc2hvdWxkIGV2
YWN1YXRlIHRoZSBjaGFubmVsIG9uY2UgdGhlcmUgaXMgbm8gc3RhdGlvbiBvbiB0aGF0IGNoYW5u
ZWwgKG9yIG9uIHRoYXQgVU5JSSBiYW5kKS4gSSdtIGN1cnJlbnRseSBlbmFibGluZyB0aGlzIGxv
Z2ljIGluIHRoZSB3cGFfc3VwcGxpY2FudC4NCg0KUmVnYXJkcywNCg0KSWxhbi4NCg==
PiANCj4gT24gU2F0LCBGZWIgMjIsIDIwMTQgYXQgMTA6NTUgQU0sIFBlZXIsIElsYW4gPGlsYW4u
cGVlckBpbnRlbC5jb20+IHdyb3RlOg0KPiA+IEFGQUlLLCBvbmUgb2YgdGhlIG9wdGlvbnMgdGhl
eSBhcmUgY29uc2lkZXJpbmcgaXMgdG8gYWxsb3cgc3VjaCByZWxheGF0aW9uIGlmDQo+IGJlYWNv
biBmcm9tIHNldmVyYWwgKD4xKSBkaWZmZXJlbnQgQlNTIHdhcyByZWNlaXZlZC4NCj4gDQo+IFRo
aXMgY2FuIGp1c3QgZ28gdXBzdHJlYW0sIGllIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBj
YW4gYmUgbW9kaWZpZWQgdG8NCj4gYWNjb3VudCBmb3IgdGhpcyBmb3IgRkNDIG9ubHkuDQo+IA0K
DQpZZXAgLi4uIHRoaXMgaXMgV0lQIHdpdGggdGhlIHJlZ3VsYXRvcnkgcGVvcGxlIC4uLiBuZWVk
IHRvIGdldCBzb21lIGFuc3dlcnMgLi4uDQoNCklsYW4uIA0K
On Mon, Jan 27, 2014 at 12:21:56PM +0200, Ilan Peer wrote:
> @@ -1450,6 +1465,11 @@ __reg_process_hint_user(struct regulatory_request *user_request)
> {
> struct regulatory_request *lr = get_last_request();
>
> + if (reg_request_indoor(user_request)) {
> + reg_is_indoor = true;
> + return REG_REQ_ALREADY_SET;
Please use another return value here and document it. This would
enable other type of userspace hints and would not make this an
obscure thing.
> @@ -2014,6 +2047,8 @@ static void restore_regulatory_settings(bool reset_user)
>
> ASSERT_RTNL();
>
> + reg_is_indoor = false;
:D
> +
> reset_regdomains(true, &world_regdom);
> restore_alpha2(alpha2, reset_user);
>
> @@ -2515,6 +2550,19 @@ int cfg80211_get_unii(int freq)
> return -EINVAL;
> }
>
> +bool regulatory_ir_allowed(struct wiphy *wiphy, struct ieee80211_channel *chan)
> +{
> + if (config_enabled(CONFIG_CFG80211_REG_RELAX_NO_IR) &&
> + !(wiphy->regulatory_flags & REGULATORY_DISABLE_RELAX_NO_IR) &&
Don't you want to make the flag REGULATORY_DISABLE_RELAX_NO_IR positive,
that is REGULATORY_ENABLE_RELAX_NO_IR as otherwise you'd require
everyone to disable it by default. I think we want to *disable* it by
default it and let drivers set it explicitly to declare support.
> + reg_is_indoor && (chan->flags & IEEE80211_CHAN_INDOOR_ONLY))
> + return true;
> +
> + if (chan->flags & IEEE80211_CHAN_NO_IR)
> + return false;
> + return true;
> +}
> +EXPORT_SYMBOL(regulatory_ir_allowed);
Please use EXPORT_SYMBOL_GPL() moving forward for regulatory core stuff.
Proprietary drivers can kiss my hairy ass.
Luis
Hi Luis,
Thanks for the comments.
Ilan.
> > + * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on
> this channel.
> > + * A channel marked with IEEE80211_CHAN_INDOOR_ONLY can only be
> used when
> > + * there is a clear assessment that the device is operating in an indoor
> > + * surroundings, i.e., it is connected to AC power (and not through
> > + * portable DC inverters)
>
> Curious, what are the plans to avoid the situation of portable DC inverters
> from being used in this case ? Stating that is in the documentation alludes
> that this is possible in userspace.
>
> Is it?
>
The motivation here was to allow this in cases that the device is truly an indoor device such as media center etc. I am not aware of plans to avoid such situations. Will take this with our regulatory people.
> > or is under the control of a master that is
> > + * acting as an AP and is connected to AC power.
> > + * @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.
>
> What do you mean "on 5.2" ? Maybe just "the 5 GHz band" would be better
> if this is not UNII specific. If the rule applies to a UNII band then mentioning
> the band name nomenclature would make it clearer, ie, UNII-1, or UNII-2. If
> this flag could later be used by other 5 GHz UNII bands then making it in the
> documentation UNII band agnostic and just using 5 GHz would suffice, while
> your handler in code adjusts as regulations change.
>
As far as I understand the concept of UNII bands, a UNII band is a group of channels/frequencies that share the same regulatory rules. Thus, if we are currently connected to a BSS on a channel in a specific UNII band, we can deduce that operating on all the channels in the same UNII band is allowed as these channels share the same operating rules as the channel we are currently connected to on the BSS interface. I'll rephrase the comment to better express so.
> > + * Instantiating a GO on a channel marked with
> IEEE80211_CHAN_GO_CONCURRENT
> > + * can be done when there is a clear assessment that the device is
> > + * operating under the guidance of an authorized master, i.e., setting
> up a
> > + * GO while the device is also connected to an AP with DFS and radar
> > + * detection on the UNII band (however, this example does not imply
> that
> > + * all channels marked with IEEE80211_CHAN_RADAR must also be
> marked with
> > + * IEEE80211_CHAN_GO_CONCURRENT and vise versa).
>
> Your mentioning of DFS here makes things a bit confusing. We should be
> distinguishing between the case of a device beign associated to on a BSS
> where the AP is on a DFS channel, and the case where the AP is not on a DFS
> channel. Are you saying that if IEEE80211_CHAN_GO_CONCURRENT is
> enabled on a channel that also has IEEE80211_CHAN_RADAR that the device
> can start GO on the same channel if it *doesn't support DFS itself* if its
> associated to a real AP, which presumably supports DFS? If so consider then a
> third GO which would associate to the secondary GO, we now have a link of 3
> devices and an inherent delay can be created letting a master device do
> things. How do we avoid latency issues in communication in this type of
> setup?
>
> If IEEE80211_CHAN_GO_CONCURRENT is meant only for channels that do
> not have IEEE80211_CHAN_RADAR that makes it simpler but I think you were
> trying to clarify that daisy chaning trust on the root AP is valid.
>
> Please clarify both use cases on the documentation.
Yep this required more clarification: the GO concurrent relaxation is intended for the NO_IR flag and not for the RADAR flag. If RADAR is set then a GO cannot be instantiated. I will clarify this in the documentation.
>
> > diff --git a/include/uapi/linux/nl80211.h
> > b/include/uapi/linux/nl80211.h index 91054fd..06440ac 100644
> > --- a/include/uapi/linux/nl80211.h
> > +++ b/include/uapi/linux/nl80211.h
> > @@ -2304,6 +2304,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.
>
> Same UNII band clarification applies here.
>
> Luis
On Mon, Jan 27, 2014 at 12:21:54PM +0200, Ilan Peer wrote:
> Move the regulatory cellular base station hints support under
> a specific configuration option and make the option depend
> on CFG80211_CERTIFICATION_ONUS.
>
> Signed-off-by: Ilan Peer <[email protected]>
> ---
> net/wireless/Kconfig | 7 +++++++
> net/wireless/reg.c | 2 +-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 16d08b3..81c05e4 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -95,6 +95,13 @@ config CFG80211_CERTIFICATION_ONUS
> you are a wireless researcher and are working in a controlled
> and approved environment by your local regulatory agency.
>
> +config CFG80211_REG_CELLULAR_HINTS
> + bool "cfg80211 regulatory support for cellular base station hints"
> + depends on CFG80211_CERTIFICATION_ONUS
> + ---help---
> + This option adds support for drivers that can receive regulatory
> + hints from cellular base stations
Please use:
This option enables support for parsing regulatory
hints from cellular base stations. If enabled and at
least one driver claims support for parsing cellular
base station hints the regulatory core will allow and
parse these regulatory hints. The regulatory core will
only apply these regulatory hints on drivers that support
this feature. You should only enable this feature if you
have tested and validated this feature on your systems.
Luis
Hi Luis,
Thanks again,
Ilan.
> On Mon, Jan 27, 2014 at 12:21:56PM +0200, Ilan Peer wrote:
> > @@ -1450,6 +1465,11 @@ __reg_process_hint_user(struct
> > regulatory_request *user_request) {
> > struct regulatory_request *lr = get_last_request();
> >
> > + if (reg_request_indoor(user_request)) {
> > + reg_is_indoor = true;
> > + return REG_REQ_ALREADY_SET;
>
> Please use another return value here and document it. This would enable
> other type of userspace hints and would not make this an obscure thing.
>
Sure. This will require documenting the other return values as well .. hope I'll not make a mess.
> > @@ -2014,6 +2047,8 @@ static void restore_regulatory_settings(bool
> > reset_user)
> >
> > ASSERT_RTNL();
> >
> > + reg_is_indoor = false;
>
> :D
>
> > +
> > reset_regdomains(true, &world_regdom);
> > restore_alpha2(alpha2, reset_user);
> >
> > @@ -2515,6 +2550,19 @@ int cfg80211_get_unii(int freq)
> > return -EINVAL;
> > }
> >
> > +bool regulatory_ir_allowed(struct wiphy *wiphy, struct
> > +ieee80211_channel *chan) {
> > + if (config_enabled(CONFIG_CFG80211_REG_RELAX_NO_IR) &&
> > + !(wiphy->regulatory_flags &
> REGULATORY_DISABLE_RELAX_NO_IR) &&
>
> Don't you want to make the flag REGULATORY_DISABLE_RELAX_NO_IR
> positive, that is REGULATORY_ENABLE_RELAX_NO_IR as otherwise you'd
> require everyone to disable it by default. I think we want to *disable* it by
> default it and let drivers set it explicitly to declare support.
>
>
Sure ... will make it positive ... will fix the previous patches as well.
> > + reg_is_indoor && (chan->flags &
> IEEE80211_CHAN_INDOOR_ONLY))
> > + return true;
> > +
> > + if (chan->flags & IEEE80211_CHAN_NO_IR)
> > + return false;
> > + return true;
> > +}
> > +EXPORT_SYMBOL(regulatory_ir_allowed);
>
> Please use EXPORT_SYMBOL_GPL() moving forward for regulatory core stuff.
> Proprietary drivers can kiss my hairy ass.
>
With pleasure :)
> > Note that this is a permissive approach to the FCC definitions, that
> > require a clear assessment that the device operating the AP is an
> > authorized master, i.e., with radar detection and DFS capabilities.
>
> OK It seems here you are clarifying that the feature is only when you can
> verify the AP is DFS-capable. How can you verify that?
The assumption here is that if the AP is operating under the known regulatory restrictions, and radar detection capabilities are ONLY given as an example.
As you pointed in the previous patch, regardless of the AP regulatory constraints, if the local device thinks that the current operating channel of the AP is a radar channel this relaxation is not allowed. Will clarify this in the commit message.
>
> > It is assumed that such restrictions are enforced by user space.
> > Furthermore, it is assumed, that if the conditions that allowed for
> > the operation of the GO on such a channel change, i.e., the station
> > interface disconnected from the AP, it is the responsibility of user
> > space to evacuate the GO from the channel.
>
> This is a pretty important piece of information as well. Once these patches go
> in I really want to make it clear that we should update the documentation the
> wiki as noted before.
>
Sure.
[...]
> > + * @REGULATORY_DISABLE_RELAX_NO_IR: for devices that do not wish
> to allow the
> > + * NO_IR relaxation, which enables transmissions on channels on which
> > + * otherwise initiating radiation is not allowed.
>
> Please provide an example. A read of this documentation likely cannot guess
> the available relaxations available, and this is only obvious to the reader of
> this patch series. If you are adding a Kconfig entry you can refer to it, or you
> can refer to the channel flags as pointers to further documentation.
>
I will add a reference to the Kconfig option.
> > +config CFG80211_REG_RELAX_NO_IR
> > + bool "cfg80211 support for NO_IR relaxation"
> > + depends on CFG80211_CERTIFICATION_ONUS
> > + ---help---
> > + This option enables relaxation of the NO_IR flag. The relaxation
> > + allows initiating radiation on channels that are marked with the
> > + NO_IR flag which forbids transmissions on the channel.
> > +
> > + For example, enabling this option allows the operation of a P2P
> > + group owner on channels marked with NO_IR if there is an
> additional
> > + BSS interface which is connected to an AP which is assumed to be
> > + an authorized master, i.e., with radar detection support and DFS
> > + capabilities
>
> Please use:
>
> This option enables support for relaxation of the NO_IR flag for situations
> that certain regulatory bodies have provided clarifications on how relaxation
> can occur. This feature has an inherent dependency on userspace features
> which must have been properly tested and as such is not enabled by default.
>
> A relaxation feature example is allowing the operation of a P2P group owner
> (GO) on channels marked with NO_IR if there is an additional BSS interface
> which associated to an AP which userspace assumes or confirems to be an
> authorized master, i.e., with radar detection support and DFS capabilities.
>
>
Done.
> Ilan, also extend the above with language similar to the one I provided on the
> cellular base station hints if you ended up adding a device feature capability.
>
You mean specify that this option is enabled, drivers can still use the device specific flags to disable this?
> > diff --git a/net/wireless/chan.c b/net/wireless/chan.c index
> > 78559b5..87a9d0e 100644
> > --- a/net/wireless/chan.c
> > +++ b/net/wireless/chan.c
> > @@ -605,15 +605,77 @@ bool cfg80211_chandef_usable(struct wiphy
> > *wiphy, } EXPORT_SYMBOL(cfg80211_chandef_usable);
> >
> > +/*
> > + * For GO only, check if the channel can be used under permissive
> > +conditions
> > + * mandated by the some regulatory bodies, i.e., the channel is
> > +marked with
> > + * IEEE80211_CHAN_GO_CONCURRENT and there is an additional station
> > +interface
> > + * associated to an AP on the same channel or on the same UNII band
> > + * (assuming that the AP is an authorized master).
> > + */
> > +static bool cfg80211_go_permissive_chan(struct
> cfg80211_registered_device *rdev,
> > + struct ieee80211_channel *chan)
> > +{
> > + struct wireless_dev *wdev_iter;
> > +
> > + ASSERT_RTNL();
>
> You can simplify the check that calls this by having the
> config_enabled() check here. You can also add the check for
> REGULATORY_DISABLE_RELAX_NO_IR here.
Done.
>
> > +
> > + if (!(chan->flags & IEEE80211_CHAN_GO_CONCURRENT))
> > + return false;
> > +
> > + list_for_each_entry(wdev_iter, &rdev->wdev_list, list) {
> > + struct ieee80211_channel *other_chan = NULL;
> > + int r1, r2;
> > +
> > + if (wdev_iter->iftype != NL80211_IFTYPE_STATION ||
> > + !netif_running(wdev_iter->netdev))
> > + continue;
> > +
> > + wdev_lock(wdev_iter);
> > + if (wdev_iter->current_bss)
> > + other_chan = wdev_iter->current_bss-
> >pub.channel;
> > + wdev_unlock(wdev_iter);
>
> Please wrap this up into a helper either for this series or after.
> Just a friendly reminder :)
Ok.
> > +
> > + if (!other_chan)
> > + continue;
> > +
> > + if (chan == other_chan)
> > + return true;
>
> This seems to me to indicate that we have allowed here daisy chaining / trust
> on another GO who also trusted its AP. That is, we are leaving it up to the
> kernel for the above few lines of code to check if the STA was associated to
> an AP that had DFS support. How do we know the AP the STA was associated
> to was not another GO that ran through this permissive check? Is the FCC
> happy with that?
>
This verification should be done by user space, i.e., if the station is a legacy client associated to a GO, then wpa_supplicant should not allow the GO_CONCURRENT relaxation. In addition, a GO instantiated on channel based on this relaxation should not allow connection from legacy clients ... again this should be enforced by user space. System wise this should adhere to the FCC expectations and prevent daisy chaining.
> Also to be clear, you check for IEEE80211_CHAN_GO_CONCURRENT only on
> the caller's channel, not the STA's device, is that OK ? Lets consider the case
> case of two different types of interfaces on the same system. I am aware of
> at least one
> 802.11 AP company selling devices with one 802.11 vendor as the AP and
> another as the STA. I don't consider this rare anymore now, as such please
> think about this case as well.
The property is of the channel so this should suffice. Overall, I think that the FCC definition rules are centered on the UNII bands, so the rules mandated for a given channel in a specific channel should also hold to other channels in the same UNII band. Ultimately, I would expect all channels in the same UNII band to share the same settings.
The iteration in this case is over all the interfaces of the same registered device
> > +
> > + if (chan->band != IEEE80211_BAND_5GHZ)
> > + continue;
> > +
> > + r1 = cfg80211_get_unii(chan->center_freq);
> > + r2 = cfg80211_get_unii(other_chan->center_freq);
> > +
> > + if (r1 != -EINVAL && r1 == r2)
> > + return true;
>
> Looks good, the same concern about IEEE80211_CHAN_GO_CONCURRENT
> on the other_chan applies here.
>
Same as above.
> > + }
> > +
> > + return false;
> > +}
> > + /*
> > + * Under certain conditions suggested by the some regulatory bodies
> > + * a GO can operate on channels marked with IEEE80211_NO_IR
> > + * so set this flag only if such relaxations are not enabled and
> > + * the conditions are not met.
> > + */
> > + if (iftype != NL80211_IFTYPE_P2P_GO ||
> > + !config_enabled(CONFIG_CFG80211_REG_RELAX_NO_IR) ||
> > + (wiphy->regulatory_flags & REGULATORY_DISABLE_RELAX_NO_IR)
> ||
> > + !cfg80211_go_permissive_chan(rdev, chandef->chan))
>
> This is the check I was saying you could simplify by tossing the config checks
> and wiphy->regulatory_flags check there.
>
Ok :)
> >
> >
> > +int cfg80211_get_unii(int freq)
>
> A reference to where this is documented would be good.
>
Done.
> > +{
> > + /* UNII-1 */
> > + if (freq >= 5150 && freq <= 5250)
> > + return 0;
> > +
> > + /* UNII-2A */
> > + if (freq > 5250 && freq <= 5350)
> > + return 1;
> > +
> > + /* UNII-2B */
> > + if (freq > 5350 && freq <= 5470)
> > + return 2;
> > +
> > + /* UNII-2C */
> > + if (freq > 5470 && freq <= 5725)
> > + return 3;
> > +
> > + /* UNII-3 */
> > + if (freq > 5725 && freq <= 5825)
> > + return 4;
> > +
> > + WARN_ON(1);
>
> probably best to avoid that warning -- there are some
> 4 GHz channels used out there, and pretty sure we'll hit this fast.
>
Done.
Thanks,
Ilan.
>
> 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.
>
> On Wed, Feb 19, 2014 at 02:52:13PM +0000, Peer, Ilan wrote:
> > > Ilan, also extend the above with language similar to the one I
> > > provided on the cellular base station hints if you ended up adding a
> device feature capability.
> > >
> >
> > You mean specify that this option is enabled, drivers can still use
> > the device specific flags to disable this?
>
> Yeap! In particular its important to make it clear that enabling this option isn't
> enough to get enable this feature, this option will only be usable on device
> drivers that have support for this feature.
>
Great :) already added it in the previous patch set.
> > > > +
> > > > + if (!other_chan)
> > > > + continue;
> > > > +
> > > > + if (chan == other_chan)
> > > > + return true;
> > >
> > > This seems to me to indicate that we have allowed here daisy
> > > chaining / trust on another GO who also trusted its AP. That is, we
> > > are leaving it up to the kernel for the above few lines of code to
> > > check if the STA was associated to an AP that had DFS support. How
> > > do we know the AP the STA was associated to was not another GO that
> > > ran through this permissive check? Is the FCC happy with that?
> > >
> >
> > This verification should be done by user space, i.e., if the station
> > is a legacy client associated to a GO, then wpa_supplicant should not
> > allow the GO_CONCURRENT relaxation. In addition, a GO instantiated on
> > channel based on this relaxation should not allow connection from
> > legacy clients ... again this should be enforced by user space. System
> > wise this should adhere to the FCC expectations and prevent daisy
> > chaining.
>
> Wow this is a hugely important piece of information, please toss it into the
> documentation both kconfig and wiki (once accepted upstream). As for
> references to userspace you can mention supplicant (wpa_supplicant).
>
Sure.
> > > Also to be clear, you check for IEEE80211_CHAN_GO_CONCURRENT only
> on
> > > the caller's channel, not the STA's device, is that OK ? Lets
> > > consider the case case of two different types of interfaces on the
> > > same system. I am aware of at least one 802.11 AP company selling
> > > devices with one 802.11 vendor as the AP and another as the STA. I
> > > don't consider this rare anymore now, as such please think about
> > > this case as well.
> >
> > The property is of the channel so this should suffice. Overall, I
> > think that the FCC definition rules are centered on the UNII bands, so
> > the rules mandated for a given channel in a specific channel should
> > also hold to other channels in the same UNII band. Ultimately, I would
> > expect all channels in the same UNII band to share the same settings.
>
> OK.
>
> > The iteration in this case is over all the interfaces of the same
> > registered device
>
> This feature seems limited then. Can this be extended to relay on the
> information from any other registered device? I suspect folks may soon
> enter bug reports for this otherwise. That carefulness here seems to be an
> implementation preference, but is it a hard requirement? If not then please
> considering revising all registered devices.
>
I think that this might be problematic in cases where the HW/FW has additional enforcement for GO concurrent cases, and thus will not allow to instantiate a GO although there is a station connection on another device. Eventually, it really comes to the question of can one device rely on another device for regulatory compliance?
Need to think about this option and take it with our regulatory people. For now I would prefer to stay with this limitation.
Thanks,
Ilan.