Message-ID: <35950fde52b5578e83b713cf8c90d4fc5fb77605.camel@sipsolutions.net>
Subject: Re: Reassociation is broken via CMD_CONNECT
From:   Johannes Berg <johannes@sipsolutions.net>
To:     James Prestwood <prestwoj@gmail.com>,
        linux-wireless@vger.kernel.org
Date:   Fri, 10 Feb 2023 13:13:38 +0100
In-Reply-To: <52d15e34cf20ddb372b2791c18776405f57d2516.camel@gmail.com>
References: <52d15e34cf20ddb372b2791c18776405f57d2516.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

Hi James,

Sorry, lost track of the mailing list a bit.

> "previous BSSID, to be used in ASSOCIATE and CONNECT commands to
> specify a request to reassociate within an ESS, i.e., to use
> Reassociate Request frame"
>=20
> But this actually isn't true when using CMD_CONNECT. The kernel does a
> full re-connect if PREV_BSSID is provided (easily verified by kernel
> logs which show an Authenticate frame being sent).

The authentication frame doesn't really have anything to do with whether
you use associate or reassociate? It's still required, unless you did
FT, but that's orthogonal?

Feels like it's working as designed?

johannes