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 |
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 |
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
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
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
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
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
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
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 --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)