From patchwork Mon Mar 25 17:26:09 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeremy Whiting X-Patchwork-Id: 13602564 Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A395E17BAB for ; Mon, 25 Mar 2024 17:26:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.227.194 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711387573; cv=none; b=SvzszFPbDtho3reAY4CocZw0MI0qQcvybyHj/jeRwkNN+w50wTMcjEZpsVpnCYDnVqpCaFG4gcJrjioowLbRd6EOw2vj75OTjXBN6fWWVvPORgtYJ2/23vJWwk6zuW8p8IEllOJwRVD5Oeai1QU9xV28UPUre+/iwmX3xXCzLfA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711387573; c=relaxed/simple; bh=4c96cP52Jcisq4O2sXae4VvdzUShSPS8ypLt+FY9+gk=; h=From:Content-Type:Date:Cc:To:MIME-Version:Message-ID:Subject; b=Tv1VG7wK3hlf/DB9ye3neZTWvHJSGXBcHU0gBb04ZBF0MsfQHvX6WOdr/TGSqoNp55voZNmYSf0bX0s5KzdCy2dzPjdkerEwWznT0fWp2z1NuCFLuNMFqLnHwDdOQeOcXr69IY+pS6FnM2vvYnzTZ+JEe9lwC+3MUNTzDG2rVdE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; arc=none smtp.client-ip=46.235.227.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Received: from harlem.collaboradmins.com (harlem.collaboradmins.com [IPv6:2a01:4f8:1c0c:5936::1]) by madrid.collaboradmins.com (Postfix) with ESMTP id 60C8A37810C0; Mon, 25 Mar 2024 17:26:09 +0000 (UTC) From: "Jeremy Whiting" X-Forward: 127.0.0.1 Date: Mon, 25 Mar 2024 17:26:09 +0000 Cc: "Edmund Smith" , "Alvaro Soliverez" To: iwd@lists.linux.dev Precedence: bulk X-Mailing-List: iwd@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <27b427-6601b380-b-46ef6f80@167641064> Subject: ios hotspot fix User-Agent: SOGoMail 5.10.0 Hello, In recent testing it has been found that when trying to connect to an ios hotspot some messages are missed by iwd. It seems to be a timing issue, doesn't happen every time, but does happen often enough to be a problem. In testing the device fails to connect more than half of the attempts. Ed Smith has created a patch that seems to fix the problem here. I've attached the patch after rebasing on iwd master. Here's a bit of background and explanation: iwd has difficulty in connecting to iOS hotspots as of 2.7 (and not fixed according to our testing as of 2.16 - latest at the time this is done). This is because of several factors: The iOS hotspot does not repeat its initial EAPOL challenge, where most APs will. The iOS hotspot is not reactive to EAPOL-Start (client request to be challenged); it sends exactly one challenge, and then the connection times out. The iOS hotspot sends its challenge very quickly, more quickly than iwd is prepared for. iwd is not ready to receive the challenge packet before the association event is fired by the kernel's wifi stack, but the iOS hotspot's challenge packet consistently arrives before this. This patch moves iwd's frame listener registration for EAPOL back to the authenticate event fired by the kernel. At this point, the necessary details about what kind of connection we expect to have (e.g. are we an AP) are available, but it's not possible for any plausible EAPOL packet to arrive yet (because authenticate requires us to take action - EAPOL happens after association, which can't happen before we respond to authenticate). thanks, Jeremy From b19007431311e5f3fe1cd4e4149ec909c4e57ffb Mon Sep 17 00:00:00 2001 From: Ed Smith Date: Thu, 21 Mar 2024 21:43:57 +0000 Subject: [PATCH] Register EAPOL frame listeners earlier If we register the main EAPOL frame listener as late as the associate event, it may not observe ptk_1_of_4. This defeats handling for early messages in eapol_rx_packet, which only sees messages once it has been registered. If we move registration to the authenticate event, then the EAPOL frame listeners should observe all messages, without any possible races. Note that the messages are not actually processed until eapol_start() is called, and we haven't moved that call site. All that's changing here is how early EAPOL messages can be observed. --- src/netdev.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/netdev.c b/src/netdev.c index 09fac959..3b6e2c26 100644 --- a/src/netdev.c +++ b/src/netdev.c @@ -2918,6 +2918,11 @@ static void netdev_authenticate_event(struct l_genl_msg *msg, return; } + if (!netdev->sm) { + netdev->sm = eapol_sm_new(netdev->handshake); + eapol_register(netdev->sm); + } + /* * During Fast Transition we use the authenticate event to start the * reassociation step because the FTE necessary before we can build @@ -3099,9 +3104,6 @@ static void netdev_associate_event(struct l_genl_msg *msg, netdev->ap = NULL; } - netdev->sm = eapol_sm_new(netdev->handshake); - eapol_register(netdev->sm); - /* Just in case this was a retry */ netdev->ignore_connect_event = false; -- 2.44.0