Received-SPF: pass (google.com: domain of linux-wireless+bounces-4877-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <804e3864-5782-ebff-54ad-df9dacf1a400@quicinc.com>
Date: Tue, 19 Mar 2024 10:07:16 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Subject: Re: [RFC 0/2] Handle BSS critical update procedure for probe
To: Johannes Berg <johannes@sipsolutions.net>
CC: <linux-wireless@vger.kernel.org>
References: <20240318053607.1056739-1-quic_rrchinan@quicinc.com>
 <5cf776357daf3a612b40a38cfe0328438c90451b.camel@sipsolutions.net>
Content-Language: en-US
From: Rathees Kumar R Chinannan <quic_rrchinan@quicinc.com>
In-Reply-To: <5cf776357daf3a612b40a38cfe0328438c90451b.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Johannes,

FW is doing the below additional changes on beacon, that requires to get 
the critical and BPCC values from FW.

1. Host driver sets critical bit on beacon template WMI command in 
impacted link, but FW is taking care of synchronization among partner 
links like updating critical bits and BPCC on partner link BMLE perSTA 
profile.
If hostapd and mac80211 does CU and BPCC count changes on beacons,
then synchronization of the same across links is cumbersome since FW 
knows when next beacon on partner link will be sent.
After sending beacon template, host is not aware of when actually the 
beacon sent out with updated critical/BPCC values on all links
and if probe/assoc request frame received in between time,  hostapd 
generated probe/assoc response frame could have different
values compared to that of values in beacon. To avoid this issue, these 
values are obtained from FW.

2. In some cases like Target Wake Time (TWT), FW will add TWT element IE 
on beacon and it is a critical update that hostapd is not aware of.

3. Critical bit should be cleared after DTIM interval and currently 
hostapd is not running any timer for DTIM period to clear these flags.

4. In case of Channel switch /BSS color code change, kernel should have 
switch counts, but hostapd has to provide multiple offsets to update
the count on CSA/BCCA element added on BMLE perSTA profile of partner 
links and RNR element. To avoid adding multiple offsets , these values
are passed to hostapd.

Thanks,
Rathees Kumar

On 3/18/2024 3:25 PM, Johannes Berg wrote:
> On Mon, 2024-03-18 at 11:06 +0530, Rathees Kumar R Chinannan wrote:
>>
>> Add an ieee80211_critical_update() API to send the parameters to cfg80211
>> and call it when event received from firmware to update critical
>> parameters to user space.
>>
> 
> I'm confused, _why_? What does the firmware do that changes the beacon
> that doesn't _already_ need hostapd to know about it?!
> 
> johannes