Received-SPF: softfail (google.com: domain of transitioning linux-wireless-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Thu, 5 May 2022 21:19:17 +0300
From:   Jouni Malinen <j@w1.fi>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Veerendranath Jakkam <quic_vjakkam@quicinc.com>,
        linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] cfg80211: Add support for sending more than two AKMs
 in crypto settings
Message-ID: <20220505181917.GA25102@w1.fi>
References: <1650344143-1615-1-git-send-email-quic_vjakkam@quicinc.com>
 <cb419675d2ae276d9b4eac8ab5deafe62167051f.camel@sipsolutions.net>
 <22bf2f78-587d-429b-867f-f73e542018d2@quicinc.com>
 <53062c8fbe3eaaa281f24c4808a15804938c83ef.camel@sipsolutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53062c8fbe3eaaa281f24c4808a15804938c83ef.camel@sipsolutions.net>
Precedence: bulk

On Thu, May 05, 2022 at 09:18:40AM +0200, Johannes Berg wrote:
> I also came to think - where's the upstream driver using this?

This capability is needed to implement WPA3-Personal transition mode
correctly with any driver that handles roaming internally, i.e., that
advertises NL80211_ATTR_ROAM_SUPPORT (WIPHY_FLAG_SUPPORTS_FW_ROAM). It
looks like there are two such drivers in the upstream tree today: ath6kl
and brcmfmac. Since WPA3 requires PMF, ath6kl is not really a candidate
for the main use for this (having to indicate PSK, PSK-SHA-256, and SAE
AKMs as allowed), but brcmfmac looks like an example that would need
this to allow the local network profile parameters to be set
appropriately to the driver to allow all the desired roaming cases
between BSSs using different AKM suite selectors to be performed.

That said, I do not know whether someone would be planning on using this
additional capability to extend brcmfmac to take benefit of the proposed
extension. I would support this capability in wpa_supplicant, though, so
the information would be available for that purpose.

> I've been saying this for something like a decade now, I think I'll stop
> investing time in such patches.

Do you have any preference on how to address out-of-the-tree driver
needs for this type of functionality? Many cases today can be covered
through the use of vendor specific commands and events, but there are
some inconvenient examples like the Connect command that is not really
straightforward to replace or extend with vendor commands due to the
concept of tracking the user space process associated with the
connection and internal cfg80211 tracking of the connection in general.

If additional nl80211 attributes cannot be accepted into the upstream
tree for such specific needs, could there be some way of allowing
vendor specific attributes to be added into the Connect command? Or
would this need to use some kind of ugly combination of a vendor
specific command first to modify the behavior of the following Connect
command to address this type of needs?

-- 
Jouni Malinen                                            PGP id EFC895FA