There was no such capability advertisement from the driver and thus the
current user space has to assume the driver to support all the AKMs. While
that may be the case with some drivers (e.g., mac80211-based ones), there
are cfg80211-based drivers that have constraints on which AKMs can be used.
Allow such drivers to advertise the exact set of supported AKMs so that
user space tools can determine what network profile options should be
allowed to be configured.
Signed-off-by: Veerendranath Jakkam <[email protected]>
---
include/net/cfg80211.h | 5 +++++
include/uapi/linux/nl80211.h | 4 ++++
net/wireless/nl80211.c | 6 ++++++
3 files changed, 15 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ede7fcd..7cff5ab 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4110,6 +4110,8 @@ struct cfg80211_pmsr_capabilities {
* @signal_type: signal type reported in &struct cfg80211_bss.
* @cipher_suites: supported cipher suites
* @n_cipher_suites: number of supported cipher suites
+ * @akm_suites: supported AKM suites
+ * @n_akm_suites: number of supported AKM suites
* @retry_short: Retry limit for short frames (dot11ShortRetryLimit)
* @retry_long: Retry limit for long frames (dot11LongRetryLimit)
* @frag_threshold: Fragmentation threshold (dot11FragmentationThreshold);
@@ -4308,6 +4310,9 @@ struct wiphy {
int n_cipher_suites;
const u32 *cipher_suites;
+ int n_akm_suites;
+ const u32 *akm_suites;
+
u8 retry_short;
u8 retry_long;
u32 frag_threshold;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 51bd85b..c21c238 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1558,6 +1558,10 @@ enum nl80211_commands {
* (a u32 with flags from &enum nl80211_wpa_versions).
* @NL80211_ATTR_AKM_SUITES: Used with CONNECT, ASSOCIATE, and NEW_BEACON to
* indicate which key management algorithm(s) to use (an array of u32).
+ * This attribute is also sent in response to @NL80211_CMD_GET_WIPHY,
+ * indicating the supported AKM suites. If there is no such notification
+ * from the driver, user space should assume the driver supports all the
+ * AKM suites.
*
* @NL80211_ATTR_REQ_IE: (Re)association request information elements as
* sent out by the card, for ROAM and successful CONNECT events.
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e20329b..3974752c 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2269,6 +2269,12 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
if (nl80211_send_pmsr_capa(rdev, msg))
goto nla_put_failure;
+ if (rdev->wiphy.akm_suites)
+ if (nla_put(msg, NL80211_ATTR_AKM_SUITES,
+ sizeof(u32) * rdev->wiphy.n_akm_suites,
+ rdev->wiphy.akm_suites))
+ goto nla_put_failure;
+
/* done */
state->split_start = 0;
break;
--
1.9.1
On Fri, 2018-11-16 at 17:13 +0530, Veerendranath Jakkam wrote:
> There was no such capability advertisement from the driver and thus the
> current user space has to assume the driver to support all the AKMs. While
> that may be the case with some drivers (e.g., mac80211-based ones), there
> are cfg80211-based drivers that have constraints on which AKMs can be used.
> Allow such drivers to advertise the exact set of supported AKMs so that
> user space tools can determine what network profile options should be
> allowed to be configured.
I think you need to explain here (and probably also in the docs) where
this actually matters. Clearly with drivers that do it all in userspace
it doesn't matter - so I guess it's intended for the offload cases?
Also, it'd be good to know which driver needs/implements this.
Finally,
> + if (rdev->wiphy.akm_suites)
> + if (nla_put(msg, NL80211_ATTR_AKM_SUITES,
> + sizeof(u32) * rdev->wiphy.n_akm_suites,
> + rdev->wiphy.akm_suites))
> + goto nla_put_failure;
That's probably better written as a single if statement.
johannes
On 2018-12-18 18:35, Johannes Berg wrote:
> On Fri, 2018-11-16 at 17:13 +0530, Veerendranath Jakkam wrote:
>> There was no such capability advertisement from the driver and thus
>> the
>> current user space has to assume the driver to support all the AKMs.
>> While
>> that may be the case with some drivers (e.g., mac80211-based ones),
>> there
>> are cfg80211-based drivers that have constraints on which AKMs can be
>> used.
>> Allow such drivers to advertise the exact set of supported AKMs so
>> that
>> user space tools can determine what network profile options should be
>> allowed to be configured.
>
> I think you need to explain here (and probably also in the docs) where
> this actually matters. Clearly with drivers that do it all in userspace
> it doesn't matter - so I guess it's intended for the offload cases?
>
> Also, it'd be good to know which driver needs/implements this.
This is required by the Wi-Fi driver/solution , where the SME is part of
the driver and does not define separate commands for authentication and
association. The driver we are targeting here is specific to Qualcomm
and the design needs update to support new AKM's. (For EX,this driver
needs an enhancement to trigger NL80211_CMD_EXTERNAL_AUTH for SAE AKM).
This commit addresses the requirement of user space entity to know the
supported AKM's by a specific driver version.
As you have rightly mentioned this capability would also be required for
the cases where an AKM is offloaded to the driver/firmware.
>
> Finally,
>
>> + if (rdev->wiphy.akm_suites)
>> + if (nla_put(msg, NL80211_ATTR_AKM_SUITES,
>> + sizeof(u32) * rdev->wiphy.n_akm_suites,
>> + rdev->wiphy.akm_suites))
>> + goto nla_put_failure;
>
> That's probably better written as a single if statement.
Thanks . We shall update this in the next version.
> johannes
There was no such capability advertisement from the driver and thus the
current user space has to assume the driver to support all the AKMs. While
that may be the case with some drivers (e.g., mac80211-based ones), there
are cfg80211-based drivers that implement SME and have constraints on
which AKMs can be supported (e.g., such drivers may need an update to
support SAE AKM using NL80211_CMD_EXTERNAL_AUTH). Allow such drivers to
advertise the exact set of supported AKMs so that user space tools can
determine what network profile options should be allowed to be configured.
Signed-off-by: Veerendranath Jakkam <[email protected]>
---
Changes since v1:
* Made commit message more clear
* Made %NL80211_ATTR_AKM_SUITES doc more clear
* Used single if statement instead of nested if statement
include/net/cfg80211.h | 5 +++++
include/uapi/linux/nl80211.h | 6 ++++++
net/wireless/nl80211.c | 6 ++++++
3 files changed, 17 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e0c41eb..ac68792 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4112,6 +4112,8 @@ struct cfg80211_pmsr_capabilities {
* @signal_type: signal type reported in &struct cfg80211_bss.
* @cipher_suites: supported cipher suites
* @n_cipher_suites: number of supported cipher suites
+ * @akm_suites: supported AKM suites
+ * @n_akm_suites: number of supported AKM suites
* @retry_short: Retry limit for short frames (dot11ShortRetryLimit)
* @retry_long: Retry limit for long frames (dot11LongRetryLimit)
* @frag_threshold: Fragmentation threshold (dot11FragmentationThreshold);
@@ -4310,6 +4312,9 @@ struct wiphy {
int n_cipher_suites;
const u32 *cipher_suites;
+ int n_akm_suites;
+ const u32 *akm_suites;
+
u8 retry_short;
u8 retry_long;
u32 frag_threshold;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 31ae5c7..50099a1 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1565,6 +1565,12 @@ enum nl80211_commands {
* (a u32 with flags from &enum nl80211_wpa_versions).
* @NL80211_ATTR_AKM_SUITES: Used with CONNECT, ASSOCIATE, and NEW_BEACON to
* indicate which key management algorithm(s) to use (an array of u32).
+ * This attribute is also sent in response to @NL80211_CMD_GET_WIPHY,
+ * indicating the supported AKM suites, intended for specific drivers which
+ * implement SME and have constraints on which AKMs are supported and also
+ * the cases where an AKM support is offloaded to the driver/firmware.
+ * If there is no such notification from the driver, user space should
+ * assume the driver supports all the AKM suites.
*
* @NL80211_ATTR_REQ_IE: (Re)association request information elements as
* sent out by the card, for ROAM and successful CONNECT events.
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 71a54ad..182110b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2278,6 +2278,12 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
if (nl80211_send_pmsr_capa(rdev, msg))
goto nla_put_failure;
+ if (rdev->wiphy.akm_suites &&
+ nla_put(msg, NL80211_ATTR_AKM_SUITES,
+ sizeof(u32) * rdev->wiphy.n_akm_suites,
+ rdev->wiphy.akm_suites))
+ goto nla_put_failure;
+
/* done */
state->split_start = 0;
break;
--
1.9.1
On Wed, 2018-12-19 at 17:59 +0530, [email protected] wrote:
> On 2018-12-18 18:35, Johannes Berg wrote:
> > On Fri, 2018-11-16 at 17:13 +0530, Veerendranath Jakkam wrote:
> > > There was no such capability advertisement from the driver and thus
> > > the
> > > current user space has to assume the driver to support all the AKMs.
> > > While
> > > that may be the case with some drivers (e.g., mac80211-based ones),
> > > there
> > > are cfg80211-based drivers that have constraints on which AKMs can be
> > > used.
> > > Allow such drivers to advertise the exact set of supported AKMs so
> > > that
> > > user space tools can determine what network profile options should be
> > > allowed to be configured.
> >
> > I think you need to explain here (and probably also in the docs) where
> > this actually matters. Clearly with drivers that do it all in userspace
> > it doesn't matter - so I guess it's intended for the offload cases?
> >
> > Also, it'd be good to know which driver needs/implements this.
>
> This is required by the Wi-Fi driver/solution , where the SME is part of
> the driver and does not define separate commands for authentication and
> association. The driver we are targeting here is specific to Qualcomm
> and the design needs update to support new AKM's. (For EX,this driver
> needs an enhancement to trigger NL80211_CMD_EXTERNAL_AUTH for SAE AKM).
This may be a bit repetitive ... but when are we going to see this
driver upstream? :-)
We keep adding APIs like this that you cannot actually use upstream,
which doesn't make me feel all that good about them.
johannes