Re: [EXT] Re: [PATCH v2 2/2] wifi: mwifiex: add support for WPA-PSK-SHA256

[Brian Norris]

Hi David and Sascha,

On Mon, Jul 22, 2024 at 1:46 AM David Lin <yu-hao.lin@xxxxxxx> wrote:
> > From: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>

> > Thinking about this again we really do need to use '|=' and not '='
> > to make the result independent of the ordering of the AKM suites array entries.
> >
>
> Yes, for our private driver. It uses '|=" and can work for firmware of IW416 and IW61x.
> For nxpwifi, it will follow mwifiex first and will be updated to use "|=" later.

Thanks for the reply, David. Treating this as a bitfield sounds good
to me, then.

> > > That would make sense to me, but I think that's in conflict with what
> > > David Lin said here:
...
> > > "Firmware can only support one of WLAN_AKM_SUITE_8021X,
> > > WLAN_AKM_SUITE_PSK, or WLAN_AKM_SUITE_SAE."
> >
> > I don't really know how this sentence was meant. It clearly works when both
> > WLAN_AKM_SUITE_PSK and WLAN_AKM_SUITE_SAE are advertised. Of course
> > in the only one of both is selected by the station.

Yeah, I was a little confused too. I don't have many AP systems to
test though -- all my use cases are STA.

> Mwifiex supports a lot of legacy devices, I don't know if modifications of the coding
> for the data of TLV_TYPE_UAP_AKMP will affect existed devices or not. Maybe you
> can follow the patch for host mlme to add a flag like ''host_mlme_enabled'' to enable
> this kind of change for specific device.

I don't love adding new flags for small changes just out of extreme
caution. If we find a good reason to, that's an option, but in this
case, it feels like the behavior is poorly defined and possibly
inconsistent or broken with the current code. Specifically, if anyone
was specifying PSK+EAP from user space, we didn't really guarantee
behavior. If users were really using that previously and are broken by
such a change ... well, we can figure out a way forward by introducing
such a flag.

Brian