2024-03-28 15:23:52

by James Prestwood

[permalink] [raw]
Subject: No way to cancel SAE after CMD_AUTHENTICATE?

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?

Thanks,

James



2024-03-28 16:05:33

by Johannes Berg

[permalink] [raw]
Subject: Re: No way to cancel SAE after CMD_AUTHENTICATE?

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).

johannes

2024-03-28 17:30:35

by James Prestwood

[permalink] [raw]
Subject: Re: No way to cancel SAE after CMD_AUTHENTICATE?

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