ios hotspot fix

ios hotspot fix

[Jeremy Whiting]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Register-EAPOL-frame-listeners-earlier.patch --]
[-- Type: text/x-patch, Size: 1591 bytes --]

From b19007431311e5f3fe1cd4e4149ec909c4e57ffb Mon Sep 17 00:00:00 2001
From: Ed Smith <ed.smith@collabora.com>
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

Re: ios hotspot fix

[James Prestwood]

Hi Jeremy,

On 3/25/24 10:26 AM, Jeremy Whiting wrote:
> 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).

Out of curiosity what client hardware are you using to test this? The 
early frame handling was added to support brcmfmac IIRC and as I 
understand it the EAPoL frame wasn't actually being sent too quickly, 
its just that brcmfmac was sending the events in an unexpected order.

So yes I suppose this could happen. There is even a comment in 
wpa_supplicant which seems to indicate the behavior your talking about:

https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c#n5498

Could you resend this using git-send-email so the patch is not an 
attachment. That makes it easier to comment. Looking at the patch the 
first thing that jumps out is you register prior to processing the auth 
event. If there was any failures you would have registered for EAPoL 
unnecessarily. Might as well move the registration until after the even 
was processed successfully.

Thanks,

James


>
> thanks,
> Jeremy

Re: ios hotspot fix

[Jeremy Whiting]

Hi James,

On 3/25/24 12:23, James Prestwood wrote:
> Hi Jeremy,
>
> On 3/25/24 10:26 AM, Jeremy Whiting wrote:
>> 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).
>
> Out of curiosity what client hardware are you using to test this? The 
> early frame handling was added to support brcmfmac IIRC and as I 
> understand it the EAPoL frame wasn't actually being sent too quickly, 
> its just that brcmfmac was sending the events in an unexpected order.


The bug we were experiencing was only on the OLED version of the steam 
deck. According to lscpi it uses this wifi chip:

3:00.0 Network controller: Qualcomm Technologies, Inc QCNFA765 Wireless 
Network Adapter (rev 01)
         DeviceName: Broadcom 5762
         Subsystem: Qualcomm Technologies, Inc QCNFA765 Wireless Network 
Adapter
         Flags: bus master, fast devsel, latency 0, IRQ 77
         Memory at 80000000 (64-bit, non-prefetchable) [size=2M]
         Capabilities: <access denied>
         Kernel driver in use: ath11k_pci
         Kernel modules: ath11k_pci

>
> So yes I suppose this could happen. There is even a comment in 
> wpa_supplicant which seems to indicate the behavior your talking about:
>
> https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c#n5498
>
> Could you resend this using git-send-email so the patch is not an 
> attachment. That makes it easier to comment. Looking at the patch the 
> first thing that jumps out is you register prior to processing the 
> auth event. If there was any failures you would have registered for 
> EAPoL unnecessarily. Might as well move the registration until after 
> the even was processed successfully.


Ok, I'll get git send-email set up today and update the patch to do the 
register after auth is done processing.

Thanks,

Jeremy

>
> Thanks,
>
> James
>
>
>>
>> thanks,
>> Jeremy

Re: ios hotspot fix

[James Prestwood]

Hi Jeremy,
>
> The bug we were experiencing was only on the OLED version of the steam 
> deck. According to lscpi it uses this wifi chip:
>
> 3:00.0 Network controller: Qualcomm Technologies, Inc QCNFA765 
> Wireless Network Adapter (rev 01)
>         DeviceName: Broadcom 5762
>         Subsystem: Qualcomm Technologies, Inc QCNFA765 Wireless 
> Network Adapter
>         Flags: bus master, fast devsel, latency 0, IRQ 77
>         Memory at 80000000 (64-bit, non-prefetchable) [size=2M]
>         Capabilities: <access denied>
>         Kernel driver in use: ath11k_pci
>         Kernel modules: ath11k_pci

Interesting, this is the same chip we have several devices running and I 
have never seen this behavior, granted I've never connected to an iOS 
hotspot. So maybe iOS does have some hand in it. This might be something 
I can reproduce when I have some time to set everything back up again 
because I do have this same chipset here locally.

fwiw the firmware we've been running is: 
WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.36

Thanks,

James