Hi Alex, > 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. It is. Looks like the Nest advertises SAE H2E support and we try to use that but something goes wrong. Can you capture a log with iwmon? https://iwd.wiki.kernel.org/debugging Regards, -Denis

I don't see H2E being attempted in this log?  I'm curious how you got the log in your first message on this topic?

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. I'm using a Google Nest Wifi router if that helps. I'm on Gentoo Linux ( https://packages.gentoo.org/packages/net-wireless/iwd). Does the router have any logging by chance? Generally consumer devices don't give you much but worth a shot. Thanks, James

Hi Alex, On Mon, 23 Aug 2021 at 18:21, James Prestwood <prestwoj(a)gmail.com&gt; 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

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(a)gmail.com&gt; wrote: > Hi Alex, > > > > > On Mon, 23 Aug 2021 at 18:21, James Prestwood > > <prestwoj(a)gmail.com&gt; 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 >

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(a)gmail.com&gt; 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. > > Here's what I > > tried:  > > > https://gist.github.com/alexcepoi/71f1b1fb579b26e0abaa5b7f818923be > > > > Alex. > > > > On Mon, 23 Aug 2021 at 21:03, James Prestwood > > <prestwoj(a)gmail.com&gt; wrote: > > > Hi Alex, > > > > > > > > > > > On Mon, 23 Aug 2021 at 18:21, James Prestwood > > > > <prestwoj(a)gmail.com&gt; 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 > > > > >