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;
Message-ID: <ca53bf4ce43f967723125313d5285cc40eb7d3f4.camel@sipsolutions.net>
Subject: Re: [PATCH] mac80211: Reset MBSSID parameters upon connection
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Cc:     linux-wireless@vger.kernel.org
Date:   Wed, 27 Apr 2022 21:11:22 +0200
In-Reply-To: <20220427182305.11703-1-quic_mpubbise@quicinc.com>
References: <20220427182305.11703-1-quic_mpubbise@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 2022-04-27 at 23:53 +0530, Manikanta Pubbisetty wrote:
> Currently MBSSID parameters in struct ieee80211_bss_conf
> are not reset upon connection. This could be problematic
> with some drivers in a scenario where the device first
> connects to a non-transmit BSS and then connects to a
> transmit BSS of a Multi BSS AP. The MBSSID parameters
> which are set after connecting to a non-transmit BSS will
> not be reset and the same parameters will be passed on to
> the driver during the subsequent connection to a transmit
> BSS of a Multi BSS AP.
> 
> For example, firmware running on the ath11k device uses the
> Multi BSS data for tracking the beacon of a non-transmit BSS
> and reports the driver when there is a beacon miss. If we do
> not reset the MBSSID parameters during the subsequent
> connection to a transmit BSS, then the driver would have
> wrong MBSSID data and FW would be looking for an incorrect
> BSSID in the MBSSID beacon of a Multi BSS AP and reports
> beacon loss leading to an unstable connection.
> 
> Reset the MBSSID parameters upon every connection to solve this
> problem.

Oops. Please add (or at least provide) a Fixes line though.

johannes