Linux wireless drivers development
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org, hostap@lists.infradead.org
Subject: Re: WiFi constantly changes association
Date: Wed, 28 Aug 2024 22:00:22 +0300	[thread overview]
Message-ID: <Zs9zxsjJD2jQ/jBc@w1.fi> (raw)
In-Reply-To: <fa0c3a9f-7034-41c7-a066-08284d8a069b@rowland.harvard.edu>

On Wed, Aug 28, 2024 at 02:02:32PM -0400, Alan Stern wrote:
> Attached is a compressed file containing a 10-minute section of the 
> journalctl output.  wpa_supplicant was running with -ddt and without -s, 
> so this should contain all of its output.
> 
> Initially both wpa_supplicant and NetworkManager were turned off.  The 
> log starts at the time when I turned on wpa_supplicant, and a few 
> seconds later, turned on NetworkManager.  An INVALID_IE event occurred 
> at timestamp 12:03:59.  The output is so voluminous it's hard to see 
> what's really happening, however.

Thanks. This seems to make it clear that the AP has an issue in its FT
implementation at least in the BSS that operates on the 6 GHz band.
Based on the OUI, that AP is from HPE (Aruba?), so I guess I'll check
with them whether this is a known issue.

The log did not include any other attempt to use the FT protocol, so I
could not check whether it could have worked on other bands. However, I
do note that the RSNE from the 5 GHz band is indeed different and
matches the value that the AP included on the 6 GHz band in the
Reassociation Response frame, so this seems to point towards some
implementation or configuration issues on the AP side and that could
result in an issue that is specific to the 6 GHz band.

PS.

The reason for this particular sequence is in the STA first connecting
on the 5 GHz band and wpa_supplicant being configured to use bgscan
to find a better candidate. Background scan from that ends up finding a
6 GHz AP and that has better estimated throughput and wpa_supplicant
decides to roam based on that. Since FT is enabled here, that roam tries
to use FT from the 5 GHz AP to the 6 GHz one and that fails. This
results in the 6 GHz AP getting temporarily disabled and a 5 GHz AP
being selected as the next option. That succeeds with initial FT
mobility domain association (i.e., not using FT protocol). However, now
we get back to that same state where bgscan will find a better AP on 6
GHz and that will result in the same failure..

As far as I can tell, the main issue here is in AP misbehavior. This
could be worked around by disabling FT or bgscan. A potential
wpa_supplicant change could be considered to disable FT protocol for
that specific AP when this type of behavior is detected. I'll talk to
Aruba first to see if I can get a better understanding on what is behind
this AP behavior.

-- 
Jouni Malinen                                            PGP id EFC895FA

  reply	other threads:[~2024-08-28 19:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-26 19:06 WiFi constantly changes association Alan Stern
2024-08-26 19:14 ` Johannes Berg
2024-08-26 19:19   ` Johannes Berg
2024-08-27 19:09     ` Alan Stern
2024-08-28  7:19       ` Johannes Berg
2024-08-28  7:49         ` Jouni Malinen
2024-08-28  7:55           ` Johannes Berg
2024-08-28  8:50             ` Jouni Malinen
2024-08-28 18:02             ` Alan Stern
2024-08-28 19:00               ` Jouni Malinen [this message]
2024-08-28 19:07                 ` Alan Stern
2024-08-28 19:17                   ` Jouni Malinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zs9zxsjJD2jQ/jBc@w1.fi \
    --to=j@w1.fi \
    --cc=hostap@lists.infradead.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox