Re: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting
On Fri, Feb 20, 2015 at 7:02 AM, Jonathan Bither jonbit...@gmail.com wrote: On 02/19/2015 08:03 PM, valdis.kletni...@vt.edu wrote: On Fri, 20 Feb 2015 01:53:44 +0100, Luis R. Rodriguez said: Wider community: anyone aware of any *need* in the kernel to know whether one is indoor or not on a device running Linux other than wifi? Clearly it should be something that might be of interest to at least other RF devices, so that is at least one possibilty to consider already, but what else? I can think of a lot of reasons for the kernel to make indoor/outdoor status available to userspace, but am coming up empty why the kernel itself should care That made me try to think of the possible uses for such a variable but I imagine that they can all be handled by userspace as well. Powering down GPS chips for energy consumption. Applying filters to cameras for fluorescent lights. These days such devices are bundled with all these devices typically aiming towards single-chip, ie one devices with multiple functions and sharing as much as possible, as such it should be possible architecturally to share this. So far then it seems this can just live under its hood under cfg80211 then. Luis -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting
On 02/19/2015 08:03 PM, valdis.kletni...@vt.edu wrote: On Fri, 20 Feb 2015 01:53:44 +0100, Luis R. Rodriguez said: Wider community: anyone aware of any *need* in the kernel to know whether one is indoor or not on a device running Linux other than wifi? Clearly it should be something that might be of interest to at least other RF devices, so that is at least one possibilty to consider already, but what else? I can think of a lot of reasons for the kernel to make indoor/outdoor status available to userspace, but am coming up empty why the kernel itself should care That made me try to think of the possible uses for such a variable but I imagine that they can all be handled by userspace as well. Powering down GPS chips for energy consumption. Applying filters to cameras for fluorescent lights. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting
Hi Luis, This differs from the country setting that would potentially require user space interaction and might invoke more complex flows. The flow in this case is immediate, and does not require the somewhat complex handling of country settings (it even complicates the flow unnecessarily, with the REG_REQ_USER_HINT_HANDLED etc.). There's two things you should address then: 0) Try to mitigate the issue with the old userspace API if possible. This will enable old userspace to continue to work with the old API but also mitigate the issue you have described for which you are providing a new optimized solution for but that requires a new API. Not sure I have a good solution for this. The problem here is that with the current API, the indoor setting will stick as long as a station interface is connected, although the indoor setting might no longer be true. For example when a station interface is connected to P2P GO (or a soft AP) and both devices are moving out of the indoor environment. The motivation for this patch was to move the full control of this setting to user space. Any suggestion are welcomed. 1) With the new API have userspace be able to send to the kernel that userspace will do socket monitoring and because of this and the reasons you mentioned it will have more control over the environment boolean. Ok. Will add such an API. 2. Track the socket on which the indoor hint is issued, and reset indoor setting if the socket was released. The motivation here is to force a user space process that sets the indoor setting to constantly monitor this setting, and be responsible to correctly toggling it, so indoor operation will not be enabled uncontrolled. That seems to imply a new requirement for something that used to work, what having an option to set this requirement? (Sadly) I would not consider the previous implementation as working as it would leave the regulatory core in a state that it considers to be indoor although it is no longer true. Let's review the current implementation for indoor thing. We assume we're not indoor unless userspace sends a regulatory_hint_indoor_user(), this is with the user reg hint type set to NL80211_USER_REG_HINT_INDOOR. For country IEs we never trust the country IE data since it may contain bogus data, but we also end up ignoring the environment aspect too. If we disconnect we should be reseting the indoor setting to false. I just checked and restore_regulatory_settings() does set reg_is_indoor = false so if we are keeping the indoor setting I am missing something here, and it does indeed rather an issue that should be fixed. Where is the indoor setting being upkept? This is generally true, but is not fully compatible with moving APs/P2P GOs, where you can be indoor, connect to an AP/P2P GO, and then move out of the indoor environment, while connected. Point is the being connected does not guarantee that the indoor setting is kept. 3. Do not reset the indoor setting when restoring the regulatory settings as it has nothing to do with CRDA or interface disconnection. I disagree, if we disconnect we want the more restrictive setting and if we put the indoor setting out of general regulatory requests then we do want to reset this no? I do not think so. This setting is in the responsibility of the user space daemon, so it should be the one controlling it. Right now the API requires sending the userspace regulatory hint and the kenrel should indeed reset to non-indoor upon disconnect, the later is an issue which should be fixed and what you introduce seems rather complex for something that should be fixed within the existing API. The kernel does not have enough information to deduce indoor environment or not (as pointed above), only user space has the full information in this case, and should be responsible for controlling the setting. A disconnection of the station interface does not imply that we are no longer operating in an indoor environment. I am confused you seem to be disagreeing with your above statement that says otherwise where you said that we leave the indoor setting in place if we disconnect. Can you clarify what you mean? What I meant is that a disconnection of the station interface does not imply that we are no longer operating in an indoor environment. For example, in an enterprise environment, disconnections/reconnection would happen all the time due to roaming etc., but in all this cases that device indoor setting would continue to be true. Do you mean that you don't wish to fix it so that upon disconnect we never get an indoor setting and instead prefer this to be a matter of socket monitoring? What I mean is that I want to make it the responsibility of the user space and not be depended on kernel wifi flows. This also related
RE: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting
Hi Luis,
-Original Message-
From: Luis R. Rodriguez [mailto:mcg...@suse.com]
Sent: Saturday, February 07, 2015 01:58
To: Peer, Ilan
Cc: linux-wireless@vger.kernel.org; ArikX Nemtsov
Subject: Re: [PATCH v4 1/2] cfg80211: Add API to change the indoor
regulatory setting
On Mon, Feb 02, 2015 at 09:59:25AM -0500, Ilan Peer wrote:
As the operating environment of a device can change, add API for user
space to indicate a change of indoor settings.
In addition modify the handling of the indoor processing as
follows:
1. Directly update the indoor setting without wrapping it as a
regulatory request.
Why? We have this present as part of the request as it was part of the
country IE, that's all. I can see for instance then that it is wise to
require the
supplicant for instance to be still connected to the AP and the socket
tracking
as solution to the problem. Does that summarize the logic ?
This differs from the country setting that would potentially require user space
interaction and might invoke more complex flows. The flow in this case is
immediate, and does not require the somewhat complex handling of country
settings (it even complicates the flow unnecessarily, with the
REG_REQ_USER_HINT_HANDLED etc.).
2. Track the socket on which the indoor hint is issued, and reset
indoor setting if the socket was released. The motivation here is to
force a user space process that sets the indoor setting to constantly
monitor this setting, and be responsible to correctly toggling it,
so indoor operation will not be enabled uncontrolled.
That seems to imply a new requirement for something that used to work,
what having an option to set this requirement?
(Sadly) I would not consider the previous implementation as working as it would
leave the regulatory core in a state that it considers to be indoor although it
is no longer true.
3. Do not reset the indoor setting when restoring the regulatory
settings as it has nothing to do with CRDA or interface
disconnection.
I disagree, if we disconnect we want the more restrictive setting and if we
put the indoor setting out of general regulatory requests then we do want to
reset this no?
I do not think so. This setting is in the responsibility of the user space
daemon, so it should be the one controlling it. A disconnection of the station
interface does not imply that we are no longer operating in an indoor
environment. This also related to #2 above that tightens the responsibility of
the user space daemon controlling this setting.
Signed-off-by: Ilan Peer ilan.p...@intel.com
Signed-off-by: ArikX Nemtsov a...@wizery.com
---
include/uapi/linux/nl80211.h | 5 +++
net/wireless/nl80211.c | 10 +-
net/wireless/reg.c | 80 +
---
net/wireless/reg.h | 15 -
4 files changed, 73 insertions(+), 37 deletions(-)
diff --git a/include/uapi/linux/nl80211.h
b/include/uapi/linux/nl80211.h index 68b294e..d80edcc 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1739,6 +1739,9 @@ enum nl80211_commands {
*
* @NL80211_ATTR_SCHED_SCAN_DELAY: delay before a scheduled scan
(or a
* WoWLAN net-detect scan) is started, u32 in seconds.
+
+ * @NL80211_ATTR_REG_INDOOR: flag attribute, if set indicates that the
device
+ * is operating in an indoor environment.
*
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined @@
-2107,6 +2110,8 @@ enum nl80211_attrs {
NL80211_ATTR_SCHED_SCAN_DELAY,
+ NL80211_ATTR_REG_INDOOR,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index
454d7a0..e78b096 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -399,6 +399,7 @@ static const struct nla_policy
nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_WIPHY_SELF_MANAGED_REG] = { .type =
NLA_FLAG },
[NL80211_ATTR_NETNS_FD] = { .type = NLA_U32 },
[NL80211_ATTR_SCHED_SCAN_DELAY] = { .type = NLA_U32 },
+ [NL80211_ATTR_REG_INDOOR] = { .type = NLA_FLAG },
};
/* policy for the key attributes */
@@ -4955,6 +4956,7 @@ static int parse_reg_rule(struct nlattr *tb[],
static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info
*info) {
char *data = NULL;
+ bool is_indoor;
enum nl80211_user_reg_hint_type user_reg_hint_type;
/*
@@ -4981,7 +4983,8 @@ static int nl80211_req_set_reg(struct sk_buff
*skb, struct genl_info *info)
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
Re: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting
On Mon, Feb 02, 2015 at 09:59:25AM -0500, Ilan Peer wrote:
As the operating environment of a device can change, add
API for user space to indicate a change of indoor settings.
In addition modify the handling of the indoor processing as
follows:
1. Directly update the indoor setting without wrapping it as a
regulatory request.
Why? We have this present as part of the request as it was part
of the country IE, that's all. I can see for instance then that
it is wise to require the supplicant for instance to be still
connected to the AP and the socket tracking as solution to the
problem. Does that summarize the logic ?
2. Track the socket on which the indoor hint is issued, and reset
indoor setting if the socket was released. The motivation here is to
force a user space process that sets the indoor setting to constantly
monitor this setting, and be responsible to correctly toggling it,
so indoor operation will not be enabled uncontrolled.
That seems to imply a new requirement for something that used to work,
what having an option to set this requirement?
3. Do not reset the indoor setting when restoring the regulatory
settings as it has nothing to do with CRDA or interface
disconnection.
I disagree, if we disconnect we want the more restrictive setting
and if we put the indoor setting out of general regulatory requests
then we do want to reset this no?
Signed-off-by: Ilan Peer ilan.p...@intel.com
Signed-off-by: ArikX Nemtsov a...@wizery.com
---
include/uapi/linux/nl80211.h | 5 +++
net/wireless/nl80211.c | 10 +-
net/wireless/reg.c | 80
+---
net/wireless/reg.h | 15 -
4 files changed, 73 insertions(+), 37 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 68b294e..d80edcc 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1739,6 +1739,9 @@ enum nl80211_commands {
*
* @NL80211_ATTR_SCHED_SCAN_DELAY: delay before a scheduled scan (or a
* WoWLAN net-detect scan) is started, u32 in seconds.
+
+ * @NL80211_ATTR_REG_INDOOR: flag attribute, if set indicates that the device
+ * is operating in an indoor environment.
*
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
@@ -2107,6 +2110,8 @@ enum nl80211_attrs {
NL80211_ATTR_SCHED_SCAN_DELAY,
+ NL80211_ATTR_REG_INDOOR,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 454d7a0..e78b096 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -399,6 +399,7 @@ static const struct nla_policy
nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_WIPHY_SELF_MANAGED_REG] = { .type = NLA_FLAG },
[NL80211_ATTR_NETNS_FD] = { .type = NLA_U32 },
[NL80211_ATTR_SCHED_SCAN_DELAY] = { .type = NLA_U32 },
+ [NL80211_ATTR_REG_INDOOR] = { .type = NLA_FLAG },
};
/* policy for the key attributes */
@@ -4955,6 +4956,7 @@ static int parse_reg_rule(struct nlattr *tb[],
static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
{
char *data = NULL;
+ bool is_indoor;
enum nl80211_user_reg_hint_type user_reg_hint_type;
/*
@@ -4981,7 +4983,8 @@ static int nl80211_req_set_reg(struct sk_buff *skb,
struct genl_info *info)
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();
+ is_indoor = !!info-attrs[NL80211_ATTR_REG_INDOOR];
+ return regulatory_hint_indoor(is_indoor, info-snd_portid);
So we break old functionality ? No bueno.
Luis
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
