March 2021 - iwd - Ml01.01.Org

[issue] Can't connect to a WPA2-Enterprise network: 4-way handshake timeout

by Arseny Maslennikov

Hi everyone! I'm running iwd 1.12 on Debian sid, package version 1.12-1. I'm trying to connect to a WPA2-Enterprise network with the following network config file produced by NetworkManager, to no avail: [Security] EAP-Method=PEAP EAP-Identity= EAP-PEAP-Phase2-Method=MSCHAPV2 EAP-PEAP-Phase2-Identity=<redacted> The password is stored by NM and provided to iwd on-demand. The connection fails due to 4-way handshake timeout. Setting the timeout period to 15 seconds in /etc/iwd/main.conf does not help, so it doesn't look like the APs are that slow. If I turn the iwd NM backend off and use wpa_supplicant instead, the connection succeeds and I'm able to use the network properly. Various Windows, Mac, iOS, Android clients work without issue as well. Here follows a log excerpt of wpa_supplicant successfully connecting to the same network: Dec 04 12:25:39 cello wpa_supplicant[981]: wlan0: Reject scan trigger since one is already pending Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: SME: Trying to authenticate with 00:25:84:0e:99:de (SSID='BMK_WIFI' freq=5200 MHz) Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: Trying to associate with 00:25:84:0e:99:de (SSID='BMK_WIFI' freq=5200 MHz) Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: Associated with 00:25:84:0e:99:de Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/CN=plat.redacted.cs.msu.su' hash=ad02acd8a22829f4a987495194bfbcfa0cb21f6a75eab12746d4c48fbf1e2dfd Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:plat.redacted.cs.msu.su Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/CN=plat.redacted.cs.msu.su' hash=ad02acd8a22829f4a987495194bfbcfa0cb21f6a75eab12746d4c48fbf1e2dfd Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:plat.redacted.cs.msu.su Dec 04 12:25:41 cello wpa_supplicant[981]: EAP-MSCHAPV2: Authentication succeeded Dec 04 12:25:41 cello wpa_supplicant[981]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: WPA: CCMP is used, but EAPOL-Key descriptor version (3) is not 2 Dec 04 12:25:41 cello wpa_supplicant[981]: wlan0: WPA: Interoperability workaround: allow incorrect (should have been HMAC-SHA1), but stronger (is AES-128-CMAC), descriptor version to be used Maybe that "Interoperability workaround" they do is a clue? If it's really a problem with the network, I have no way to explain it to our wifi admins — they do not recognise the problem and recommend to use wpa_supplicant, which works. Could this be fixed in iwd? I'm willing to help as much as I can, but I'm a WiFi noob and don't really know anything about 802.11i outside what's described in doc/wpa-auth.txt. I'm also attaching the output of `iwmon --nortnl' launched prior to connection. Sorry if this has been discussed before, searches on the list for the words "EAPoL" and "key descriptor version" give nothing. Thanks in advance!

1 year, 1 month

2
3
0 / 0

[PATCH v3 1/7] Fixes: 6e8b7652788ac (add check for CMD_AUTH/CMD_ASSOC support)

by James Prestwood

Commit 6e8b76527 added a switch statement for AKM suites which was not correct as this is a bitmask and may contain multiple values. Intead we can rely on wiphy_select_akm which is a more robust check anyways. --- src/wiphy.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) v3: * Return the result of wiphy_select_akm * Pass false for fils_hint parameter diff --git a/src/wiphy.c b/src/wiphy.c index 676f236c..ab57a2d2 100644 --- a/src/wiphy.c +++ b/src/wiphy.c @@ -407,24 +407,7 @@ bool wiphy_can_connect(struct wiphy *wiphy, struct scan_bss *bss) rsn_info.group_management_cipher)) return false; - - switch (rsn_info.akm_suites) { - case IE_RSN_AKM_SUITE_SAE_SHA256: - case IE_RSN_AKM_SUITE_FT_OVER_SAE_SHA256: - if (!wiphy_can_connect_sae(wiphy)) - return false; - - break; - case IE_RSN_AKM_SUITE_OWE: - case IE_RSN_AKM_SUITE_FILS_SHA256: - case IE_RSN_AKM_SUITE_FILS_SHA384: - case IE_RSN_AKM_SUITE_FT_OVER_FILS_SHA256: - case IE_RSN_AKM_SUITE_FT_OVER_FILS_SHA384: - if (!wiphy->support_cmds_auth_assoc) - return false; - - break; - } + return wiphy_select_akm(wiphy, bss, false); } else if (r != -ENOENT) return false; -- 2.26.2

1 year, 1 month

2
8
0 / 0

[PATCH v2 1/7] wiphy: add offload out parameter to wiphy_can_connect_sae

by James Prestwood

This will be set if the SAE connection requires offloading to work. --- src/wiphy.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/src/wiphy.c b/src/wiphy.c index 676f236c..35872577 100644 --- a/src/wiphy.c +++ b/src/wiphy.c @@ -126,7 +126,7 @@ enum ie_rsn_cipher_suite wiphy_select_cipher(struct wiphy *wiphy, uint16_t mask) return 0; } -static bool wiphy_can_connect_sae(struct wiphy *wiphy) +static bool wiphy_can_connect_sae(struct wiphy *wiphy, bool *offload) { /* * SAE support in the kernel is a complete mess in that there are 3 @@ -153,8 +153,11 @@ static bool wiphy_can_connect_sae(struct wiphy *wiphy) if (wiphy_has_feature(wiphy, NL80211_FEATURE_SAE)) { /* Case (1) */ - if (wiphy->support_cmds_auth_assoc) + if (wiphy->support_cmds_auth_assoc) { + if (offload) + *offload = false; return true; + } /* * Case (3) @@ -165,8 +168,12 @@ static bool wiphy_can_connect_sae(struct wiphy *wiphy) } else { /* Case (2) */ if (wiphy_has_ext_feature(wiphy, - NL80211_EXT_FEATURE_SAE_OFFLOAD)) + NL80211_EXT_FEATURE_SAE_OFFLOAD)) { + if (offload) + *offload = true; + return true; + } return false; } @@ -234,7 +241,7 @@ enum ie_rsn_akm_suite wiphy_select_akm(struct wiphy *wiphy, goto wpa2_personal; } - if (!wiphy_can_connect_sae(wiphy)) + if (!wiphy_can_connect_sae(wiphy, NULL)) goto wpa2_personal; if (info.akm_suites & @@ -411,7 +418,7 @@ bool wiphy_can_connect(struct wiphy *wiphy, struct scan_bss *bss) switch (rsn_info.akm_suites) { case IE_RSN_AKM_SUITE_SAE_SHA256: case IE_RSN_AKM_SUITE_FT_OVER_SAE_SHA256: - if (!wiphy_can_connect_sae(wiphy)) + if (!wiphy_can_connect_sae(wiphy, NULL)) return false; break; -- 2.26.2

1 year, 1 month

2
10
0 / 0

[PATCH] wiphy: fix wiphy_can_connect AKM checks

by James Prestwood

This was changed in commit 6e8b7652 to remove the IE_AKM_IS_SAE and instead use a switch statement. This is was incorrect since the akm_suites is actually a bitmask which could contain multiple AKM suites (hence the plural name). Instead a few macros were added which check the bitmask rather than the entire value. --- src/wiphy.c | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/src/wiphy.c b/src/wiphy.c index 676f236c..57c97367 100644 --- a/src/wiphy.c +++ b/src/wiphy.c @@ -388,6 +388,21 @@ const struct scan_freq_set *wiphy_get_supported_freqs( return wiphy->supported_freqs; } +#define AKM_IS_AUTH_ASSOC(akm) \ +( \ + akm & (IE_RSN_AKM_SUITE_OWE | \ + IE_RSN_AKM_SUITE_FILS_SHA256 | \ + IE_RSN_AKM_SUITE_FILS_SHA384 | \ + IE_RSN_AKM_SUITE_FT_OVER_FILS_SHA256 | \ + IE_RSN_AKM_SUITE_FT_OVER_FILS_SHA384) \ +) + +#define AKM_IS_SAE(akm) \ +( \ + akm & (IE_RSN_AKM_SUITE_SAE_SHA256 | \ + IE_RSN_AKM_SUITE_FT_OVER_SAE_SHA256) \ +) + bool wiphy_can_connect(struct wiphy *wiphy, struct scan_bss *bss) { struct ie_rsn_info rsn_info; @@ -407,23 +422,12 @@ bool wiphy_can_connect(struct wiphy *wiphy, struct scan_bss *bss) rsn_info.group_management_cipher)) return false; - - switch (rsn_info.akm_suites) { - case IE_RSN_AKM_SUITE_SAE_SHA256: - case IE_RSN_AKM_SUITE_FT_OVER_SAE_SHA256: + if (AKM_IS_SAE(rsn_info.akm_suites)) { if (!wiphy_can_connect_sae(wiphy)) return false; - - break; - case IE_RSN_AKM_SUITE_OWE: - case IE_RSN_AKM_SUITE_FILS_SHA256: - case IE_RSN_AKM_SUITE_FILS_SHA384: - case IE_RSN_AKM_SUITE_FT_OVER_FILS_SHA256: - case IE_RSN_AKM_SUITE_FT_OVER_FILS_SHA384: + } else if (AKM_IS_AUTH_ASSOC(rsn_info.akm_suites)) { if (!wiphy->support_cmds_auth_assoc) return false; - - break; } } else if (r != -ENOENT) return false; -- 2.26.2

1 year, 1 month

1
0
0 / 0

[PATCH 1/7] wiphy: add offload out parameter to wiphy_can_connect_sae

by James Prestwood

This will be set if the SAE connection requires offloading to work. --- src/wiphy.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/src/wiphy.c b/src/wiphy.c index 676f236c..35872577 100644 --- a/src/wiphy.c +++ b/src/wiphy.c @@ -126,7 +126,7 @@ enum ie_rsn_cipher_suite wiphy_select_cipher(struct wiphy *wiphy, uint16_t mask) return 0; } -static bool wiphy_can_connect_sae(struct wiphy *wiphy) +static bool wiphy_can_connect_sae(struct wiphy *wiphy, bool *offload) { /* * SAE support in the kernel is a complete mess in that there are 3 @@ -153,8 +153,11 @@ static bool wiphy_can_connect_sae(struct wiphy *wiphy) if (wiphy_has_feature(wiphy, NL80211_FEATURE_SAE)) { /* Case (1) */ - if (wiphy->support_cmds_auth_assoc) + if (wiphy->support_cmds_auth_assoc) { + if (offload) + *offload = false; return true; + } /* * Case (3) @@ -165,8 +168,12 @@ static bool wiphy_can_connect_sae(struct wiphy *wiphy) } else { /* Case (2) */ if (wiphy_has_ext_feature(wiphy, - NL80211_EXT_FEATURE_SAE_OFFLOAD)) + NL80211_EXT_FEATURE_SAE_OFFLOAD)) { + if (offload) + *offload = true; + return true; + } return false; } @@ -234,7 +241,7 @@ enum ie_rsn_akm_suite wiphy_select_akm(struct wiphy *wiphy, goto wpa2_personal; } - if (!wiphy_can_connect_sae(wiphy)) + if (!wiphy_can_connect_sae(wiphy, NULL)) goto wpa2_personal; if (info.akm_suites & @@ -411,7 +418,7 @@ bool wiphy_can_connect(struct wiphy *wiphy, struct scan_bss *bss) switch (rsn_info.akm_suites) { case IE_RSN_AKM_SUITE_SAE_SHA256: case IE_RSN_AKM_SUITE_FT_OVER_SAE_SHA256: - if (!wiphy_can_connect_sae(wiphy)) + if (!wiphy_can_connect_sae(wiphy, NULL)) return false; break; -- 2.26.2

1 year, 1 month

1
6
0 / 0

[PATCH v2 1/3] netdev: better handle associate timeouts with auth_protos

by James Prestwood

Any auth proto which did not implement the assoc_timeout handler could end up getting 'stuck' forever if there was an associate timeout. This is because in the event of an associate timeout IWD only sets a few flags and relies on the connect event to actually handle the failure. The problem is a connect event never comes if the failure was a timeout. To fix this we can explicitly fail the connection if the auth proto has not implemented assoc_timeout or if it returns false. --- src/netdev.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) v2: * Moved the failure into the actual timeout case as the connect event *does* come unless there was a timeout diff --git a/src/netdev.c b/src/netdev.c index 8d3f4a08..fcbb7d88 100644 --- a/src/netdev.c +++ b/src/netdev.c @@ -2280,7 +2280,15 @@ static void netdev_associate_event(struct l_genl_msg *msg, if (auth_proto_assoc_timeout(netdev->ap)) return; - goto assoc_failed; + /* + * There will be no connect event when Associate times + * out. The failed connection must be explicitly + * initiated here. + */ + netdev_connect_failed(netdev, + NETDEV_RESULT_ASSOCIATION_FAILED, + status_code); + return; case NL80211_ATTR_FRAME: frame = data; -- 2.26.2

1 year, 1 month

2
3
0 / 0

[PATCH 1/3] netdev: better handle associate timeouts with auth_protos

by James Prestwood

Any auth proto which did not implement the assoc_timeout handler could end up getting 'stuck' forever if there was an associate timeout. This is because in the event of an associate timeout IWD only sets a few flags and relies on the connect event to actually handle the failure. The problem is a connect event never comes when using CMD_AUTH/ASSOC directly. To fix this we can explicitly fail the connection if the auth proto has not implemented assoc_timeout or if it returns false. --- src/netdev.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/netdev.c b/src/netdev.c index 8d3f4a08..d5bad57e 100644 --- a/src/netdev.c +++ b/src/netdev.c @@ -2339,6 +2339,16 @@ static void netdev_associate_event(struct l_genl_msg *msg, return; assoc_failed: + /* + * There will be no connect event when using Auth/Assoc directly so + * the failed connection must be explicitly initiated here. + */ + if (netdev->ap) { + netdev_connect_failed(netdev, NETDEV_RESULT_ASSOCIATION_FAILED, + status_code); + return; + } + netdev->result = NETDEV_RESULT_ASSOCIATION_FAILED; netdev->last_code = status_code; netdev->expect_connect_failure = true; -- 2.26.2

1 year, 1 month

1
2
0 / 0

iwctl force autoconnect

by Yuri D'Elia

Is it possible to force iwd to connect to a known network without explicitly giving a network name? That is, to force attempting to autoconnect? Currently "station <net> connect" requires a ssid. It would be nice if that would be made optional, causing iwd to go through the automatic connect logic. I assumed that issuing a "station <net> scan" *would* attempt to autoconnect if a known network is seen and we're currently disconnected, but it's not always the case. If we disconnected from a known network due to AP disappearing and reappearing sometime later, "scan" will the network, but connection is still performed after some longer timeout. I want to bind an action to force a scan+connect without having to wait, and without having to hardcode a network name. When I'm moving a laptop between offices and go through some blind spots (elevator) I end-up in a situation where I'm disconnected, and I want to force a connection right away.

1 year, 1 month

3
7
0 / 0

[PATCH 1/3] station: clear out roam frequencies after roam

by James Prestwood

--- src/station.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/station.c b/src/station.c index ba4483e6..0d4cd47d 100644 --- a/src/station.c +++ b/src/station.c @@ -1442,6 +1442,11 @@ static void station_roamed(struct station *station) if (station->netconfig) netconfig_reconfigure(station->netconfig); + if (station->roam_freqs) { + scan_freq_set_free(station->roam_freqs); + station->roam_freqs = NULL; + } + station_enter_state(station, STATION_STATE_CONNECTED); } -- 2.26.2

1 year, 1 month

2
3
0 / 0

[PATCH v3 1/4] doc: document Security diagnostic value

by James Prestwood

--- doc/station-diagnostic-api.txt | 2 ++ 1 file changed, 2 insertions(+) v3: * Updated AKMSuite to Security diff --git a/doc/station-diagnostic-api.txt b/doc/station-diagnostic-api.txt index b5a73b5d..d1a340ad 100644 --- a/doc/station-diagnostic-api.txt +++ b/doc/station-diagnostic-api.txt @@ -23,6 +23,8 @@ Methods dict GetDiagnostics() Frequency - Frequency of currently connected BSS. + Security - The chosen security for the connection. + RSSI [optional] - The RSSI of the currently connected BSS. AverageRSSI [optional] - Average RSSI of currently connected BSS. -- 2.26.2

1 year, 1 month

2
4
0 / 0

2022

2021

2020

2019

iwd March 2021