Hey James,

Thanks for quick fix. I can confirm that the patches with a locally built iwd work fine for me ("Forcing default SAE group 19").

I'm assuming these will end up in iwd 1.18 once merged?

Alex.

On Tue, 24 Aug 2021 at 19:39, James Prestwood <prestwoj@gmail.com> wrote:
Hi Alex,

There are 4 patches on the mailing list which hopefully fix this for you. I've also attached them as well.

Thanks,
James

On Mon, 2021-08-23 at 22:30 +0100, Alex Cepoi wrote:
Hey James,

Your theory seems to be correct. Adding "sae_groups=20 19" seems to make authentication fail.

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