Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <292d11498e4b7c94aa716280361e56b065a2fd49.camel@sipsolutions.net>
Subject: Re: [PATCH v2] cfg80211: Add support for sending more than two AKMs
 in crypto settings
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Jouni Malinen <j@w1.fi>
Cc:     Veerendranath Jakkam <quic_vjakkam@quicinc.com>,
        linux-wireless@vger.kernel.org
Date:   Tue, 10 May 2022 21:14:01 +0200
In-Reply-To: <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>
         <20220505181917.GA25102@w1.fi>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Thu, 2022-05-05 at 21:19 +0300, Jouni Malinen wrote:
> 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.


Makes sense.

> 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.

:)

Honestly for this patch, I'd drop the dynamic allocation parts that are
problematic - assuming we can limit to something else that's sensible
like 4 or 5 entries?

> Do you have any preference on how to address out-of-the-tree driver
> needs for this type of functionality? 
> 

I don't - I'm just noting we keep having this discussion. And I'm just
grumpy because all my tests failed on this, probably with a kfree() of a
stray pointer or so :)

Upstream the driver? ;-)

johannes