From: Denis Kenzior <denkenz@gmail.com>
To: Jouni Malinen <jouni@qca.qualcomm.com>,
Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org,
Srinivas Dasari <dasaris@qti.qualcomm.com>
Subject: Re: [PATCH v2 1/3] cfg80211/nl80211: Optional authentication offload to userspace
Date: Thu, 4 Jan 2018 14:59:51 -0600 [thread overview]
Message-ID: <c2554a26-bbbc-3bd2-0091-06fc14e88946@gmail.com> (raw)
In-Reply-To: <1513960419-24780-1-git-send-email-jouni@qca.qualcomm.com>
Hi Jouni, Johannes,
<snip>> + * User space uses the %NL80211_CMD_CONNECT command to the host
driver for
> + * triggering a connection. The host driver selects a BSS and further uses
> + * this interface to offload only the authentication part to the user
> + * space. Authentication frames are passed between the driver and user
> + * space through the %NL80211_CMD_FRAME interface. The status of
So this implies userspace must pre-register for authentication
management frames, correct? And other applications could register to
receive these frames as well? Would it not be easier (and more secure)
to simply forward these directly to the application that triggered
CMD_CONNECT instead?
> + * authentication is further indicated by user space to the host driver
> + * with the %NL80211_CMD_EXTERNAL_AUTH command through
> + * %NL80211_ATTR_STATUS_CODE attribute. This enables the driver to proceed
> + * with association on successful authentication. Driver shall use this
> + * %NL80211_ATTR_STATUS_CODE attribute to report the connect result to
> + * user space on an authentication failure.
> + *
> * @NL80211_CMD_MAX: highest used command number
> * @__NL80211_CMD_AFTER_LAST: internal use
> */
<snip>
>
> +int cfg80211_external_auth_request(struct net_device *dev,
> + struct cfg80211_external_auth_params *params,
> + gfp_t gfp)
> +{
> + struct wireless_dev *wdev = dev->ieee80211_ptr;
> + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
> + struct sk_buff *msg;
> + void *hdr;
> +
> + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> + if (!msg)
> + return -ENOMEM;
> +
> + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_EXTERNAL_AUTH);
> + if (!hdr) {
> + nlmsg_free(msg);
> + return -ENOMEM;
> + }
> +
> + if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
> + nla_put_u32(msg, NL80211_ATTR_IFINDEX, dev->ifindex) ||
> + nla_put_u32(msg, NL80211_ATTR_AKM_SUITES, params->key_mgmt_suite) ||
> + nla_put_u32(msg, NL80211_ATTR_EXTERNAL_AUTH_ACTION,
> + params->action) ||
> + nla_put(msg, NL80211_ATTR_BSSID, ETH_ALEN, params->bssid) ||
> + nla_put(msg, NL80211_ATTR_SSID, params->ssid.ssid_len,
> + params->ssid.ssid))
> + goto nla_put_failure;
> +
> + genlmsg_end(msg, hdr);
> +
> + genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy), msg, 0,
> + NL80211_MCGRP_MLME, gfp);
Is there a reason this is being multicast and not unicast to the
application that triggered the CONNECT? Who else besides the supplicant
daemon might find this information useful?
> + return 0;
> +
> + nla_put_failure:
> + genlmsg_cancel(msg, hdr);
> + nlmsg_free(msg);
> + return -ENOBUFS;
> +}
> +EXPORT_SYMBOL(cfg80211_external_auth_request);
> +
> /* initialisation/exit functions */
>
> int __init nl80211_init(void)
Regards,
-Denis
next prev parent reply other threads:[~2018-01-04 20:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 16:33 [PATCH v2 1/3] cfg80211/nl80211: Optional authentication offload to userspace Jouni Malinen
2017-12-22 16:33 ` [PATCH v2 2/3] nl80211: Allow SAE Authentication for NL80211_CMD_CONNECT Jouni Malinen
2018-01-04 14:48 ` Johannes Berg
2017-12-22 16:33 ` [PATCH v2 3/3] nl80211: Introduce scan flags to emphasize requested scan behavior Jouni Malinen
2018-01-04 14:50 ` Johannes Berg
2018-01-04 14:47 ` [PATCH v2 1/3] cfg80211/nl80211: Optional authentication offload to userspace Johannes Berg
2018-01-04 20:59 ` Denis Kenzior [this message]
2018-01-15 12:22 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c2554a26-bbbc-3bd2-0091-06fc14e88946@gmail.com \
--to=denkenz@gmail.com \
--cc=dasaris@qti.qualcomm.com \
--cc=johannes@sipsolutions.net \
--cc=jouni@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).