diff mbox series

Log falling back from SAE to WPA2

Message ID 20240109095926.1541238-1-fiona.klute@gmx.de (mailing list archive)
State New
Headers show
Series Log falling back from SAE to WPA2 | expand

Checks

Context Check Description
tedd_an/pre-ci_am success Success
prestwoj/iwd-alpine-ci-fetch success Fetch PR
prestwoj/iwd-ci-gitlint success GitLint
prestwoj/iwd-ci-fetch success Fetch PR
prestwoj/iwd-alpine-ci-makedistcheck success Make Distcheck
prestwoj/iwd-alpine-ci-incremental_build success Incremental build not run PASS
prestwoj/iwd-ci-makedistcheck success Make Distcheck
prestwoj/iwd-ci-incremental_build success Incremental build not run PASS
prestwoj/iwd-ci-build success Build - Configure
prestwoj/iwd-alpine-ci-build success Build - Configure
prestwoj/iwd-ci-makecheck success Make Check
prestwoj/iwd-ci-makecheckvalgrind success Make Check w/Valgrind
prestwoj/iwd-ci-clang success clang PASS
prestwoj/iwd-alpine-ci-makecheckvalgrind success Make Check w/Valgrind
prestwoj/iwd-alpine-ci-makecheck success Make Check
prestwoj/iwd-ci-testrunner success test-runner PASS

Commit Message

Fiona Klute Jan. 9, 2024, 9:59 a.m. UTC
I've had connections to a WPA3-Personal only network fail with no log
message from iwd, and eventually figured out to was because the driver
would've required using CMD_EXTERNAL_AUTH. With the added log messages
the reason becomes obvious.

Additionally the fallback may happen even if the user explicitly
configured WPA3 in NetworkManager, I believe a warning is appropriate
there.
---
 src/wiphy.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--
2.43.0

Comments

Denis Kenzior Jan. 10, 2024, 3:33 a.m. UTC | #1
Hi Fiona,

On 1/9/24 03:59, Fiona Klute wrote:
> I've had connections to a WPA3-Personal only network fail with no log
> message from iwd, and eventually figured out to was because the driver
> would've required using CMD_EXTERNAL_AUTH. With the added log messages
> the reason becomes obvious.

Interesting.  Last time I checked only the quantenna driver used this feature 
and it wasn't very common.  If it isn't a secret, what card / driver do you have?

> 
> Additionally the fallback may happen even if the user explicitly
> configured WPA3 in NetworkManager, I believe a warning is appropriate
> there.

There's currently no way to force WPA3-only in iwd.  Either configure the AP to 
be WPA3 only, or have the AP enforce transition-disable bit.  But this typically 
requires iwd to connect at least once with WPA3.  See 'TransitionDisable' and 
'DisabledTransitionModes' in man 5 iwd.network

> ---
>   src/wiphy.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/src/wiphy.c b/src/wiphy.c
> index 766df348..5530e9c6 100644
> --- a/src/wiphy.c
> +++ b/src/wiphy.c
> @@ -248,6 +248,8 @@ static bool wiphy_can_connect_sae(struct wiphy *wiphy)
>   		 *
>   		 * TODO: No support for CMD_EXTERNAL_AUTH yet.
>   		 */
> +		l_debug("Unsupported: %s needs CMD_EXTERNAL_AUTH for SAE",
> +			wiphy->driver_str);

I flipped this around and made this statement an l_warn to make it clearer that 
this is an iwd limitation.

>   		return false;
>   	}
> 
> @@ -312,8 +314,10 @@ enum ie_rsn_akm_suite wiphy_select_akm(struct wiphy *wiphy,
>   		if (ie_rsne_is_wpa3_personal(info)) {
>   			l_debug("Network is WPA3-Personal...");
> 
> -			if (!wiphy_can_connect_sae(wiphy))
> +			if (!wiphy_can_connect_sae(wiphy)) {
> +				l_warn("Can't use SAE, trying WPA-2");

And made this into l_debug.

>   				goto wpa2_personal;
> +			}
> 
>   			if (info->akm_suites &
>   					IE_RSN_AKM_SUITE_FT_OVER_SAE_SHA256)
> --

Regards,
-Denis
Fiona Klute Jan. 10, 2024, 11:33 a.m. UTC | #2
Hi Denis,

thanks for accepting the patch!

Am 10.01.24 um 04:33 schrieb Denis Kenzior:
> Interesting.  Last time I checked only the quantenna driver used this
> feature and it wasn't very common.  If it isn't a secret, what card /
> driver do you have?

It's the RTL8723CS chip used in Pinephone, the rtl8723cs driver
unfortunately still isn't in mainline. You can find it in the staging
directory of megi's tree:
https://codeberg.org/megi/linux/src/commit/f45c45abc5325682d06cb51c06aba1f817fba462/drivers/staging/rtl8723cs

I suspect getting the chip properly supported in mainline would be the
best way to get SAE working. If you have hints on how to get involved in
that I'm curious, so far my wireless driver experience is limited to
"add USB ID for a new device with already supported chip". ;-)

> There's currently no way to force WPA3-only in iwd.  Either configure
> the AP to be WPA3 only, or have the AP enforce transition-disable bit.
> But this typically requires iwd to connect at least once with WPA3.  See
> 'TransitionDisable' and 'DisabledTransitionModes' in man 5 iwd.network

Good point, it should be a task for NetworkManager to make that clear to
the user (and possibly set those options, if the user wants to enforce
WPA3-only).

>> ---
>>   src/wiphy.c | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/wiphy.c b/src/wiphy.c
>> index 766df348..5530e9c6 100644
>> --- a/src/wiphy.c
>> +++ b/src/wiphy.c
>> @@ -248,6 +248,8 @@ static bool wiphy_can_connect_sae(struct wiphy
>> *wiphy)
>>            *
>>            * TODO: No support for CMD_EXTERNAL_AUTH yet.
>>            */
>> +        l_debug("Unsupported: %s needs CMD_EXTERNAL_AUTH for SAE",
>> +            wiphy->driver_str);
>
> I flipped this around and made this statement an l_warn to make it
> clearer that this is an iwd limitation.

Makes sense. :-)

Best regards,
Fiona
Marcel Holtmann Jan. 10, 2024, 1:12 p.m. UTC | #3
Hi Denis,

>> I've had connections to a WPA3-Personal only network fail with no log
>> message from iwd, and eventually figured out to was because the driver
>> would've required using CMD_EXTERNAL_AUTH. With the added log messages
>> the reason becomes obvious.
> 
> Interesting.  Last time I checked only the quantenna driver used this feature and it wasn't very common.  If it isn't a secret, what card / driver do you have?

according to Arend on an email thread with the Apple WiFi support, he hinted that Broadcom with their devices/firmware opted for the CMD_EXTERNAL_AUTH option while the Cypress/Infineon devices with their firmware (like Raspberry Pi) are using the SAE offload feature.

So maybe it is time to implement support for CMD_EXTERNAL_AUTH.

Regards

Marcel
Denis Kenzior Jan. 10, 2024, 4:47 p.m. UTC | #4
Hi Marcel,

On 1/10/24 07:12, Marcel Holtmann wrote:
> Hi Denis,
> 
>>> I've had connections to a WPA3-Personal only network fail with no log
>>> message from iwd, and eventually figured out to was because the driver
>>> would've required using CMD_EXTERNAL_AUTH. With the added log messages
>>> the reason becomes obvious.
>>
>> Interesting.  Last time I checked only the quantenna driver used this feature and it wasn't very common.  If it isn't a secret, what card / driver do you have?
> 
> according to Arend on an email thread with the Apple WiFi support, he hinted that Broadcom with their devices/firmware opted for the CMD_EXTERNAL_AUTH option while the Cypress/Infineon devices with their firmware (like Raspberry Pi) are using the SAE offload feature.

Yeah I saw that as well.  I don't have any Cypress devices.  AFAIK Raspberry Pi 
uses brcmfmac + firmware that supports SAE authentication in CMD_CONNECT, not 
CMD_EXTERNAL_AUTH.  Someone who knows better please correct me.

> 
> So maybe it is time to implement support for CMD_EXTERNAL_AUTH.

Sure.  I don't have any devices that use CMD_EXTERNAL_AUTH, however.  Patches 
are always welcome though.

Regards,
-Denis
Denis Kenzior Jan. 10, 2024, 4:51 p.m. UTC | #5
Hi Fiona,

> 
> It's the RTL8723CS chip used in Pinephone, the rtl8723cs driver
> unfortunately still isn't in mainline. You can find it in the staging
> directory of megi's tree:
> https://codeberg.org/megi/linux/src/commit/f45c45abc5325682d06cb51c06aba1f817fba462/drivers/staging/rtl8723cs
> 
> I suspect getting the chip properly supported in mainline would be the
> best way to get SAE working. If you have hints on how to get involved in

Well, CMD_EXTERNAL_AUTH is part of the official nl80211 API.  When we 
implemented SAE there were no hw/drivers that used it that we could find.  Hence 
it isn't supported by iwd.

> that I'm curious, so far my wireless driver experience is limited to
> "add USB ID for a new device with already supported chip". ;-)

For getting it into mainline, I would start a conversation on linux-wireless 
and/or submit the driver upstream.

> 
>> There's currently no way to force WPA3-only in iwd.  Either configure
>> the AP to be WPA3 only, or have the AP enforce transition-disable bit.
>> But this typically requires iwd to connect at least once with WPA3.  See
>> 'TransitionDisable' and 'DisabledTransitionModes' in man 5 iwd.network
> 
> Good point, it should be a task for NetworkManager to make that clear to
> the user (and possibly set those options, if the user wants to enforce
> WPA3-only).
> 

Right.  NM makes many assumptions in its WiFi implementation based on how wpa_s 
works.  Some of these assumptions do not hold with iwd.

Regards,
-Denis
Marcel Holtmann Jan. 10, 2024, 5:05 p.m. UTC | #6
Hi Denis,

>>>> I've had connections to a WPA3-Personal only network fail with no log
>>>> message from iwd, and eventually figured out to was because the driver
>>>> would've required using CMD_EXTERNAL_AUTH. With the added log messages
>>>> the reason becomes obvious.
>>> 
>>> Interesting.  Last time I checked only the quantenna driver used this feature and it wasn't very common.  If it isn't a secret, what card / driver do you have?
>> according to Arend on an email thread with the Apple WiFi support, he hinted that Broadcom with their devices/firmware opted for the CMD_EXTERNAL_AUTH option while the Cypress/Infineon devices with their firmware (like Raspberry Pi) are using the SAE offload feature.
> 
> Yeah I saw that as well.  I don't have any Cypress devices.  AFAIK Raspberry Pi uses brcmfmac + firmware that supports SAE authentication in CMD_CONNECT, not CMD_EXTERNAL_AUTH.  Someone who knows better please correct me.

I got the impression that Apple M1/M2/M3 Macs (or even their Intel Macs) would be using CMD_EXTERNAL_AUTH, but details are unclear. Does wpa_supplicant actually supports it?

Regards

Marcel
Denis Kenzior Jan. 10, 2024, 5:10 p.m. UTC | #7
Hi Marcel,

On 1/10/24 11:05, Marcel Holtmann wrote:
> Hi Denis,
> 
>>>>> I've had connections to a WPA3-Personal only network fail with no log
>>>>> message from iwd, and eventually figured out to was because the driver
>>>>> would've required using CMD_EXTERNAL_AUTH. With the added log messages
>>>>> the reason becomes obvious.
>>>>
>>>> Interesting.  Last time I checked only the quantenna driver used this feature and it wasn't very common.  If it isn't a secret, what card / driver do you have?
>>> according to Arend on an email thread with the Apple WiFi support, he hinted that Broadcom with their devices/firmware opted for the CMD_EXTERNAL_AUTH option while the Cypress/Infineon devices with their firmware (like Raspberry Pi) are using the SAE offload feature.
>>
>> Yeah I saw that as well.  I don't have any Cypress devices.  AFAIK Raspberry Pi uses brcmfmac + firmware that supports SAE authentication in CMD_CONNECT, not CMD_EXTERNAL_AUTH.  Someone who knows better please correct me.
> 
> I got the impression that Apple M1/M2/M3 Macs (or even their Intel Macs) would be using CMD_EXTERNAL_AUTH, but details are unclear. Does wpa_supplicant actually supports it?

Seems that way:

https://w1.fi/cgit/hostap/commit/?id=5ff39c1380d9dea794c5102c0b6d11d1b1e23ad0

Regards,
-Denis
diff mbox series

Patch

diff --git a/src/wiphy.c b/src/wiphy.c
index 766df348..5530e9c6 100644
--- a/src/wiphy.c
+++ b/src/wiphy.c
@@ -248,6 +248,8 @@  static bool wiphy_can_connect_sae(struct wiphy *wiphy)
 		 *
 		 * TODO: No support for CMD_EXTERNAL_AUTH yet.
 		 */
+		l_debug("Unsupported: %s needs CMD_EXTERNAL_AUTH for SAE",
+			wiphy->driver_str);
 		return false;
 	}

@@ -312,8 +314,10 @@  enum ie_rsn_akm_suite wiphy_select_akm(struct wiphy *wiphy,
 		if (ie_rsne_is_wpa3_personal(info)) {
 			l_debug("Network is WPA3-Personal...");

-			if (!wiphy_can_connect_sae(wiphy))
+			if (!wiphy_can_connect_sae(wiphy)) {
+				l_warn("Can't use SAE, trying WPA-2");
 				goto wpa2_personal;
+			}

 			if (info->akm_suites &
 					IE_RSN_AKM_SUITE_FT_OVER_SAE_SHA256)