Received-SPF: pass (google.com: domain of linux-wireless+bounces-5480-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <b650863e-10cb-4fa0-8718-bbb349415674@gmail.com>
Date: Thu, 28 Mar 2024 10:30:22 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: No way to cancel SAE after CMD_AUTHENTICATE?
Content-Language: en-US
To: Johannes Berg <johannes@sipsolutions.net>,
 "open list:MEDIATEK MT76 WIRELESS LAN DRIVER"
 <linux-wireless@vger.kernel.org>
References: <055b857a-83f0-4abb-b6ff-f0eaaf572e64@gmail.com>
 <968024261cf1d4e72832451e1c4cc64922d05364.camel@sipsolutions.net>
From: James Prestwood <prestwoj@gmail.com>
In-Reply-To: <968024261cf1d4e72832451e1c4cc64922d05364.camel@sipsolutions.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Johannes,

On 3/28/24 9:05 AM, Johannes Berg wrote:
> On Thu, 2024-03-28 at 08:23 -0700, James Prestwood wrote:
>> Hi,
>>
>> I noticed some odd behavior where userspace is unable to cancel an SAE
>> connection until associated. If you issue a CMD_AUTHENTICATE then
>> immediately (or prior to association) send a CMD_DISCONNECT the kernel
>> will not cancel the authentication and afaict ignore the CMD_DISCONNECT.
>> The kernel will continue to send authenticate events, and even retry
>> authentication until the retry limit after CMD_DISCONNECT is issued.
>>
>> I see the checks in cfg80211_disconnect which seem to back up this
>> behavior where its essentially ignored if not "connected". I'm not sure
>> where to actually fix this since the auth retries are internal to
>> mac80211. Since the device isn't even authenticated I'm unsure what
>> value/structure to even check in order to detect this situation and
>> clean up. But there needs to be some way to cancel the authentication,
>> right?
> NL80211_CMD_DEAUTHENTICATE should do that? I'm not really surprised you
> cannot disconnet when you're not even connected yet, for the most part
> the kernel doesn't care about tracking auth state (any more, for many
> years now).

Your right, I did try that so I thought but I must have screwed up the 
test. Swapping the CMD_DISCONNECT call with CMD_DEAUTHENTICATE does stop 
the retry attempts, and in turn get an expected deauth event. Sorry for 
the noise.

Thanks,

James

>
> johannes