Hey James,

Your theory seems to be correct. Adding "sae_groups=20 19" seems to make
authentication fail.
Here's what I tried:
https://gist.github.com/alexcepoi/71f1b1fb579b26e0abaa5b7f818923be

Alex.

On Mon, 23 Aug 2021 at 21:03, James Prestwood <prestwoj@gmail.com> wrote:

> Hi Alex,
>
>
> On Mon, 23 Aug 2021 at 18:21, James Prestwood <prestwoj@gmail.com> wrote:
>
> Hi Alex,
>
> On Sun, 2021-08-22 at 04:47 +0100, Alex Cepoi wrote:
>
> Hi everyone,
>
> I'm having trouble connecting to a WPA3 network after updating from 1.15
> to 1.16. Can reproduce consistently (100% success rate on 1.15, 0% success
> rate on 1.16).
>
> You can see debug logs before and after in
> https://gist.github.com/alexcepoi/eef301a56e5e40826a8a416cbfb684e6
>
> Diff shows some new "SAE Hunting and Pecking" algorithm used and a "AP did
> not include group number in response!" info, though not sure if related.
>
>
> In your case the effective difference between IWD 1.16 and 1.15 is that we
> now try SAE groups in decending order. This is because higher group numbers
> are more secure. BUT the only group that is required for a device to
> support is group 19, which it seems your AP falls under. So we have this
> situation where we try group 20, fail, then try 19, but something else goes
> wrong.
>
> We don't think IWD is behaving out of what the spec requries in this
> situation (and we even test for this rejected group scenario) but there are
> several red flag commits in hostapd from 2018/2019 which describe fixing
> some behavior that sounds similar to this. Its difficult to know because we
> don't have your AP's hostapd or kernel version to try out ourselves.
>
> tl;dr
>
> We think we can 'fix' this by simply using group 19 by default (or a
> config option) but thats not optimal since you really want to use the most
> secure group if it is available. What we can do to verify that your AP is
> to blame is try wpa_supplicant and include this option:
>
> sae_groups=20 19
>
> This *should* try group 20 first and behave similarly to IWD. If this also
> results in the same issue we know the AP is to blame. Knowing this will at
> least give us some justification for adding a config option as a fix.
>
> Thanks,
> James
>
>