8:11 a.m.
Hi all,
when entering a wrong password, I expected ConnMan to return the error
string "invalid-key". This worked with wpa_supplicant 2.5, but since
upgrading to wpa_supplicant 2.9, ConnMan returns "connect-failed".
ConnMan assumes the password to be incorrect, if wpa_supplicant was in
the 4WAY_HANDSHAKE state before disconnecting:
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/plugin
s/wifi.c?h=1.38#n2537
As far as I understand, the problem is that wpa_supplicant now
supports offloading the 4-way handshake into the driver and it skips
this state completely. For comparison, here is a D-Bus dump with wpa_supplicant 2.5:
https://pastebin.com/raw/60064sgt
and here with wpa_supplicant 2.9:
https://pastebin.com/raw/hQetZq7C
Thanks,
Sven
7:38 a.m.
Hi Sven,
On Mon, Jun 15, 2020 at 08:11:17AM -0000, Sven Dembianny wrote:
Hi all,
when entering a wrong password, I expected ConnMan to return the error
string "invalid-key". This worked with wpa_supplicant 2.5, but since
upgrading to wpa_supplicant 2.9, ConnMan returns "connect-failed".
ConnMan assumes the password to be incorrect, if wpa_supplicant was in
the 4WAY_HANDSHAKE state before disconnecting:
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/plugin
s/wifi.c?h=1.38#n2537
As far as I understand, the problem is that wpa_supplicant now
supports offloading the 4-way handshake into the driver and it skips
this state completely. For comparison, here is a D-Bus dump with wpa_supplicant 2.5:
https://pastebin.com/raw/60064sgt
and here with wpa_supplicant 2.9:
https://pastebin.com/raw/hQetZq7C
Many thanks to the bug report. Looking at the wpa_supplicant code this
can't be turned off.
static void wpas_start_assoc_cb(struct wpa_radio_work *work, int deinit)
{
[...]
if ((wpa_s->drv_flags & WPA_DRIVER_FLAGS_4WAY_HANDSHAKE_8021X) &&
(params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X ||
params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SHA256 ||
params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SUITE_B ||
params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SUITE_B_192))
params.req_handshake_offload = 1;
[...]
}
That means someone (and that's not me) needs to update our wifi plugin to work
with 2.9
The workaround is to use iwd for wifi.
Thanks,
Daniel
10:13 a.m.
New subject: [PATCH 0/1] ConnMan returns connect-failed when entering wrong
password
I updated the wifi plugin to work with our setup, but I'm not sure if
the assoc_code is driver / firmware specific.
Holesch, Simon (BSH) (1):
Detect invalid key with 4-way handshake offloading
plugins/wifi.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--
2.17.1
10:13 a.m.
New subject: [PATCH 1/1] Detect invalid key with 4-way handshake offloading
wpa_supplicant is able to offload the 4-way handshake into the driver.
In this case the 4wAY_HANDSHAKE state is skipped and therefore the
current mechanism to detect a wrong password doesn't work any more. This
patch extends the detection mechanism to also work with the offloading
feature. The status code 16 is relatively generic, so this can lead to
false positives.
---
plugins/wifi.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index fc304e3b..74b773bc 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -74,6 +74,7 @@
#define P2P_LISTEN_PERIOD 500
#define P2P_LISTEN_INTERVAL 2000
+#define ASSOC_STATUS_AUTH_TIMEOUT 16
#define ASSOC_STATUS_NO_CLIENT 17
#define LOAD_SHAPING_MAX_RETRIES 3
@@ -2422,7 +2423,9 @@ static bool handle_4way_handshake_failure(GSupplicantInterface
*interface,
{
struct connman_service *service;
- if (wifi->state != G_SUPPLICANT_STATE_4WAY_HANDSHAKE)
+ if ((wifi->state != G_SUPPLICANT_STATE_4WAY_HANDSHAKE) &&
+ !((wifi->state == G_SUPPLICANT_STATE_ASSOCIATING) &&
+ (wifi->assoc_code == ASSOC_STATUS_AUTH_TIMEOUT)))
return false;
if (wifi->connected)
--
2.17.1
7:35 p.m.
New subject: [PATCH 1/1] Detect invalid key with 4-way handshake offloading
Hi Simon,
On Tue, Sep 01, 2020 at 10:13:36AM +0000, Holesch, Simon (GED-SDD1) wrote:
wpa_supplicant is able to offload the 4-way handshake into the
driver.
In this case the 4wAY_HANDSHAKE state is skipped and therefore the
current mechanism to detect a wrong password doesn't work any more. This
patch extends the detection mechanism to also work with the offloading
feature. The status code 16 is relatively generic, so this can lead to
false positives.
Patch applied. Let's see how it behaves. If things break apart we can
still revert it.
Thanks,
Daniel
370
days inactive
464
days old
4 comments
3 participants
participants (3)
-
Daniel Wagner -
Holesch, Simon (GED-SDD1) -
Sven Dembianny