| Message ID | 1542368582-3153-1-git-send-email-vjakkam@codeaurora.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | cfg80211: Allow drivers to advertise supported AKM suites | expand |
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
On Wed, 2018-12-19 at 17:59 +0530, vjakkam@codeaurora.org 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
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;
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 <vjakkam@codeaurora.org> --- include/net/cfg80211.h | 5 +++++ include/uapi/linux/nl80211.h | 4 ++++ net/wireless/nl80211.c | 6 ++++++ 3 files changed, 15 insertions(+)