From: Johannes Berg <johannes@sipsolutions.net>
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
Vidyullatha Kanchanapally <vidyullatha@codeaurora.org>
Cc: linux-wireless@vger.kernel.org, jouni@qca.qualcomm.com,
vkanchan@qti.qualcomm.com, amarnath@qti.qualcomm.com,
usdutt@qti.qualcomm.com, vamsin@qti.qualcomm.com
Subject: Re: [PATCH] nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS
Date: Thu, 29 Mar 2018 13:16:06 +0200 [thread overview]
Message-ID: <1522322166.5932.13.camel@sipsolutions.net> (raw)
In-Reply-To: <5ABCCA33.8070501@broadcom.com> (sfid-20180329_131256_170260_82227DE0)
Hi Arend,
> Picking up a somewhat old thread as I did not see a follow-up on this
> patch. I got queried about it over here by our FILS team. So what is
> needed for this patch to pass the bar?
That's indeed a bit old :-)
> > > + * @UPDATE_FILS_ERP_INFO: Indicates that FILS connection parameters (realm,
> > > + * username, erp sequence number and rrk) are updated
> > > + * @UPDATE_AUTH_TYPE: Indicates that Authentication type is updated
> >
> > These are new here, but you don't know if they were actually supported:
> >
> > > + if (wiphy_ext_feature_isset(&rdev->wiphy,
> > > + NL80211_EXT_FEATURE_FILS_SK_OFFLOAD) &&
> >
> > here.
>
> The description of the FILS_SK_OFFLOAD currently says:
>
> * @NL80211_EXT_FEATURE_FILS_SK_OFFLOAD: Driver SME supports FILS
> shared key
> * authentication with %NL80211_CMD_CONNECT.
>
> Are you suggesting a new flag to cover the new update attributes?
[snip]
> > Again, how do you know the driver will actually look at
> > UPDATE_AUTH_TYPE?
>
> If they don't they are broken, right? And if they are broken, the
> connection will drop and regular connect will happen anyway, no?
>
> We could add a new flag to signal driver will handle the extra
> parameters in UPDATE_CONNECT_PARAMS, but it is not clear why it would be
> needed. Seems to me user-space has all the info needed with the existing
> flag(s).
Agree, and we don't even have any drivers that are setting the
FILS_SK_OFFLOAD flag anyway, so we can still redefine its semantics to
some extent.
So yeah, I'd argue that what the patch needed was somebody taking a
critical look at my review ;-)
And perhaps fixing the weird flags thing I pointed out.
johannes
next prev parent reply other threads:[~2018-03-29 11:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-25 9:20 [PATCH] nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS Vidyullatha Kanchanapally
2017-12-11 11:12 ` Johannes Berg
2018-03-29 11:12 ` Arend van Spriel
2018-03-29 11:16 ` Johannes Berg [this message]
2018-03-29 11:31 ` Arend van Spriel
2018-04-04 9:21 ` Arend van Spriel
2018-04-04 10:36 ` Johannes Berg
2018-04-04 13:19 ` Arend van Spriel
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=1522322166.5932.13.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=amarnath@qti.qualcomm.com \
--cc=arend.vanspriel@broadcom.com \
--cc=jouni@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=usdutt@qti.qualcomm.com \
--cc=vamsin@qti.qualcomm.com \
--cc=vidyullatha@codeaurora.org \
--cc=vkanchan@qti.qualcomm.com \
/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).