Re: [RFC v5 3/9] nl80211: Add CONTROL_PORT_OVER_NL80211 attribute

2018-03-21 Thread Johannes Berg
On Wed, 2018-03-21 at 10:01 -0500, Denis Kenzior wrote:
> Hi Johannes,
> 
> On 03/21/2018 02:47 AM, Johannes Berg wrote:
> > On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:
> > > 
> > > + if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]) {
> > > + if (!info->attrs[NL80211_ATTR_SOCKET_OWNER])
> > > + return -EINVAL;
> > > 
> > 
> > There might be value in adding GENL_SET_ERR_MSG() calls to new
> > instances of -EINVAL, but if you don't want to do that now I won't
> > insist (and perhaps add some when I apply the patches).
> > 
> 
> Sure, that sounds easy enough.  Did you see the TODO comments I added in 
> RFC v5 0/9 message?  I need your help figuring out how you want to 
> handle those.  Those are pretty esoteric though and would require more 
> surgery.

Sorry, I hadn't. I'll take a look now.

> Any chance that we can merge the non-controversial bits of this RFC so 
> that we can get some wider testing and start encouraging non-mac80211 
> based drivers to support these mechanisms?

Yeah, sure, we can do that.

johannes


Re: [RFC v5 3/9] nl80211: Add CONTROL_PORT_OVER_NL80211 attribute

2018-03-21 Thread Denis Kenzior

Hi Johannes,

On 03/21/2018 02:47 AM, Johannes Berg wrote:

On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:


+   if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]) {
+   if (!info->attrs[NL80211_ATTR_SOCKET_OWNER])
+   return -EINVAL;


There might be value in adding GENL_SET_ERR_MSG() calls to new
instances of -EINVAL, but if you don't want to do that now I won't
insist (and perhaps add some when I apply the patches).



Sure, that sounds easy enough.  Did you see the TODO comments I added in 
RFC v5 0/9 message?  I need your help figuring out how you want to 
handle those.  Those are pretty esoteric though and would require more 
surgery.


Any chance that we can merge the non-controversial bits of this RFC so 
that we can get some wider testing and start encouraging non-mac80211 
based drivers to support these mechanisms?


Regards,
-Denis


Re: [RFC v5 3/9] nl80211: Add CONTROL_PORT_OVER_NL80211 attribute

2018-03-21 Thread Johannes Berg
On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:
> 
> + if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]) {
> + if (!info->attrs[NL80211_ATTR_SOCKET_OWNER])
> + return -EINVAL;
> 
There might be value in adding GENL_SET_ERR_MSG() calls to new
instances of -EINVAL, but if you don't want to do that now I won't
insist (and perhaps add some when I apply the patches).

johannes


[RFC v5 3/9] nl80211: Add CONTROL_PORT_OVER_NL80211 attribute

2018-03-13 Thread Denis Kenzior
Signed-off-by: Denis Kenzior 
---
 include/net/cfg80211.h   |  3 +++
 include/uapi/linux/nl80211.h | 14 +-
 net/wireless/nl80211.c   | 13 +
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 76b6783f35f6..2e7f30c66913 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -646,6 +646,8 @@ struct survey_info {
  * allowed through even on unauthorized ports
  * @control_port_no_encrypt: TRUE to prevent encryption of control port
  * protocol frames.
+ * @control_port_over_nl80211: TRUE if userspace expects to exchange control
+ * port frames over NL80211 instead of the network interface.
  * @wep_keys: static WEP keys, if not NULL points to an array of
  * CFG80211_MAX_WEP_KEYS WEP keys
  * @wep_tx_key: key index (0..3) of the default TX static WEP key
@@ -661,6 +663,7 @@ struct cfg80211_crypto_settings {
bool control_port;
__be16 control_port_ethertype;
bool control_port_no_encrypt;
+   bool control_port_over_nl80211;
struct key_params *wep_keys;
int wep_tx_key;
const u8 *psk;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 77675ae3e475..1cdac3d732c1 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -542,7 +542,8 @@
  * IEs in %NL80211_ATTR_IE, %NL80211_ATTR_AUTH_TYPE, %NL80211_ATTR_USE_MFP,
  * %NL80211_ATTR_MAC, %NL80211_ATTR_WIPHY_FREQ, %NL80211_ATTR_CONTROL_PORT,
  * %NL80211_ATTR_CONTROL_PORT_ETHERTYPE,
- * %NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT, %NL80211_ATTR_MAC_HINT, and
+ * %NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT,
+ * %NL80211_ATTR_CONTROL_PORT_OVER_NL80211, %NL80211_ATTR_MAC_HINT, and
  * %NL80211_ATTR_WIPHY_FREQ_HINT.
  * If included, %NL80211_ATTR_MAC and %NL80211_ATTR_WIPHY_FREQ are
  * restrictions on BSS selection, i.e., they effectively prevent roaming
@@ -1488,6 +1489,15 @@ enum nl80211_commands {
  * @NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT: When included along with
  * %NL80211_ATTR_CONTROL_PORT_ETHERTYPE, indicates that the custom
  * ethertype frames used for key negotiation must not be encrypted.
+ * @NL80211_ATTR_CONTROL_PORT_OVER_NL80211: A flag indicating whether control
+ * port frames (e.g. of type given in %NL80211_ATTR_CONTROL_PORT_ETHERTYPE)
+ * will be sent directly to the network interface or sent via the NL80211
+ * socket.  If this attribute is missing, then legacy behavior of sending
+ * control port frames directly to the network interface is used.  If the
+ * flag is included, then control port frames are sent over NL80211 instead
+ * using %CMD_CONTROL_PORT_FRAME.  If control port routing over NL80211 is
+ * to be used then userspace must also use the %NL80211_ATTR_SOCKET_OWNER
+ * flag.
  *
  * @NL80211_ATTR_TESTDATA: Testmode data blob, passed through to the driver.
  * We recommend using nested, driver-specific attributes within this.
@@ -2641,6 +2651,8 @@ enum nl80211_attrs {
NL80211_ATTR_NSS,
NL80211_ATTR_ACK_SIGNAL,
 
+   NL80211_ATTR_CONTROL_PORT_OVER_NL80211,
+
/* 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 3c4dbfa0ca71..24b1bd940fca 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -287,6 +287,7 @@ static const struct nla_policy 
nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_CONTROL_PORT] = { .type = NLA_FLAG },
[NL80211_ATTR_CONTROL_PORT_ETHERTYPE] = { .type = NLA_U16 },
[NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT] = { .type = NLA_FLAG },
+   [NL80211_ATTR_CONTROL_PORT_OVER_NL80211] = { .type = NLA_FLAG },
[NL80211_ATTR_PRIVACY] = { .type = NLA_FLAG },
[NL80211_ATTR_CIPHER_SUITE_GROUP] = { .type = NLA_U32 },
[NL80211_ATTR_WPA_VERSIONS] = { .type = NLA_U32 },
@@ -8227,6 +8228,18 @@ static int nl80211_crypto_settings(struct 
cfg80211_registered_device *rdev,
} else
settings->control_port_ethertype = cpu_to_be16(ETH_P_PAE);
 
+   if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]) {
+   if (!info->attrs[NL80211_ATTR_SOCKET_OWNER])
+   return -EINVAL;
+
+   if (!rdev->ops->tx_control_port ||
+   !wiphy_ext_feature_isset(&rdev->wiphy,
+
NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211))
+   return -EOPNOTSUPP;
+
+   settings->control_port_over_nl80211 = true;
+   }
+
if (info->attrs[NL80211_ATTR_CIPHER_SUITES_PAIRWISE]) {
void *data;
int len, i;
-- 
2.13.5