Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230602225751.164525-1-kglund@google.com> <8545d75827ff8d85fece58542539db6c9930d3b6.camel@sipsolutions.net>
In-Reply-To: <8545d75827ff8d85fece58542539db6c9930d3b6.camel@sipsolutions.net>
From:   Kevin Lund <kglund@google.com>
Date:   Fri, 4 Aug 2023 11:29:09 -0600
Message-ID: <CADgzm_mvnoETW3y4hvhqdUSC1ByNEjy2BsQUqq_Va-YEaGzULg@mail.gmail.com>
Subject: Re: [PATCH 1/2] wifi: cfg80211: Reject (re-)association to the same BSSID
To:     linux-wireless@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Thanks for the response. I'm still a little bit confused because
AFAICT, over on the userspace SME side of things there are two
similar checks that reject both authentication [1] and association
[2] to a BSSID which we are already connected to. Wouldn't that
break the 11be flow which you're referring to?

In any case I'm ok with abandoning this patch. I'll resubmit the
other patch in this series [3] on its own.

[1] https://github.com/torvalds/linux/blob/master/net/wireless/mlme.c#L281
[2] https://github.com/torvalds/linux/blob/master/net/wireless/mlme.c#L342
[3] https://patchwork.kernel.org/project/linux-wireless/patch/2023060222575=
1.164525-2-kglund@google.com/

Thanks, and apologies for my late reply,
Kevin

On Mon, Jun 5, 2023 at 10:42=E2=80=AFAM Johannes Berg <johannes@sipsolution=
s.net> wrote:
>
> On Fri, 2023-06-02 at 16:57 -0600, Kevin Lund wrote:
> > Within cfg80211_connect, reject the (re-)association request if we are
> > already connected to the exact BSSID which is being requested. This
> > prevents an unnecessary attempt to connect which in the best case
> > leaves us back where we started.
> >
> > There is precedent for behaving this way over on the userspace SME side
> > of things in cfg80211_mlme_auth. Further, cfg80211_connect already make=
s
> > several basic checks to ensure the connection attempt is reasonable, so
> > this fits in that context.
> >
>
> I don't think this is right - we should be able to reassoc back to the
> same AP in some cases, for example in 11be this comes up when you want
> to change the negotiated links.
>
> johannes