Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: wgong=codeaurora.org@mg.codeaurora.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Fri, 13 Aug 2021 17:16:51 +0800
From:   Wen Gong <wgong@codeaurora.org>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     ath11k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 9/9] mac80211: save transmit power envelope element and
 power constraint
In-Reply-To: <f61cdc7bae2dd2a645e164ca143b9db402472559.camel@sipsolutions.net>
References: <20210517201932.8860-1-wgong@codeaurora.org>
 <20210517201932.8860-10-wgong@codeaurora.org>
 (sfid-20210517_222034_029448_A9A89D57)
 <d9491db4ece67ac78eb39a1078b91a106770fbb0.camel@sipsolutions.net>
 <1126f8d996e895ae048092b3f8aad19b@codeaurora.org>
 <38e7d9d2eebafa7245a36a0a0396094526eb3efd.camel@sipsolutions.net>
 <1273cc1a399a7457c3d908648a7651c8fe9b93f3.camel@sipsolutions.net>
 <a056e32d4911400fb0822bf02167e91c@codeaurora.org>
 <f61cdc7bae2dd2a645e164ca143b9db402472559.camel@sipsolutions.net>
Message-ID: <465b6b8535fc17ae51ee2f3116af87bb@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk

On 2021-08-13 16:53, Johannes Berg wrote:
> On Fri, 2021-08-13 at 16:47 +0800, Wen Gong wrote:
>> > > > > 2) Should we at least check it again from the protected beacon or such
>> > > > > after association, so we don't blindly trust the probe response or
>> > > > > beacon (received during scan, not validated) at least when BIGTK is in
>> > > > > use?
>> > > >
>> > > > May we add support for BIGTK in future with another patch?
>> > >
>> > > We already have BIGTK support in mac80211, so if we don't do that now
>> > > we're almost certainly not going to do it, so I'd really prefer if you
>> > > did it here, or if a separate patch still did it now.
>> >
>> > Actually, I should say though - the question was more whether we even
>> > need/want that, rather than whether we can do it later or not.
>> >
>> > If we should protect this data/information then IMHO we should do it
>> > now, but it's not clear to me that we should, given that we also don't
>> > have encrypted association response and we still take information from
>> > there too, etc.
>> >
>> > johannes
>> I prefer to add a new enum(not use BSS_CHANGED_TXPOWER),e.g,
>> BSS_CHANGED_PWR_ENV.
>> And add check in ieee80211_rx_mgmt_beacon() as well as
>> ieee80211_handle_pwr_constr(),
>> when the value of pwr_reduction or content of elems.tx_pwr_env 
>> changed,
>> save the pwr_reduction and elems.tx_pwr_env to ieee80211_bss_conf, and
>> notify lower
>> driver with BSS_CHANGED_PWR_ENV, then lower driver will do next 
>> action.
>> 
> I don't really have any objection to this, but OTOH it feels like
> drivers will probably not really listen to this if it can only happen
> due to BIGTK?
yes, it should have some flag/logic to check whether it is BIGTK.
If you know it, you can tell me. :)
> 
> And if we always defer this until the first beacon, that also feels
> wrong and bad?
It can not defer this untill the 1st beacon which pass BIGTK verify.
Lower driver need this info to set power before TX data include EAPOL.
> 
> I'm not sure what the right answer here is, TBH.
> 
> Maybe the right answer is to indeed ignore beacon protection for this,
> and do exactly what you did here, and say that the TX power envelope
> thing is just not meant to be protected, because the protection is 
> meant
> to protect the connection etc. and not the performance (and 
> regulatory?)
Yes, the lower driver also have the max power limit itself. If power 
calulated
from the fake beacon is bigger than the max power limit, then it will be
ignored.
> 
> Do we get this *only* in the beacon, or also in the association
> response? If it's also in the association response we could use the 
> data
> from *there*, and basically say that the association response might 
> need
> some protection (later) anyway?
> 
The Transmit Power Envelope is not existed in the assoc response, it is 
existed
in beacon. So it can not use assoc response.

beacon:
IEEE 802.11 wireless LAN
     Fixed parameters (12 bytes)
         Timestamp: 0x0000005070684036
         Beacon Interval: 0.102400 [Seconds]
         Capabilities Information: 0x0511
     Tagged parameters (264 bytes)
         Tag: SSID parameter set: Renhui-6G
         Tag: Supported Rates and BSS Membership Selectors 6.0(B), 9, 
12.0(B), 18, 24(B), 36, 48, 54, [Mbit/sec]
         Tag: Traffic Indication Map (TIM): DTIM 0 of
         Tag: Country Information: Country Code US, Environment Unknown 
(0x04)
         Tag: Power Constraint: 3
         Tag: TPC Report Transmit Power: 17, Link Margin: 0
         Tag: Extended Supported Rates and BSS Membership Selectors BSS 
requires support for direct hashing to elements in SAE, [Mbit/sec]
         Tag: RSN Information
         Tag: Extended Capabilities (11 octets)
         Tag: Transmit Power Envelope
         Tag: Transmit Power Envelope
         Ext Tag: Reserved (55)
         Ext Tag: HE Capabilities (IEEE Std 802.11ax/D2.0)
         Ext Tag: HE Operation (IEEE Std 802.11ax/D2.0)
         Ext Tag: Spatial Reuse Parameter Set
         Ext Tag: MU EDCA Parameter Set
         Ext Tag: 6GHz Band Capabilities

assoc response:
IEEE 802.11 wireless LAN
     Fixed parameters (6 bytes)
         Capabilities Information: 0x0511
         Status code: Successful (0x0000)
         ..00 0000 0001 0001 = Association ID: 0x0011
     Tagged parameters (169 bytes)
         Tag: Supported Rates and BSS Membership Selectors 6.0(B), 9, 
12.0(B), 18, 24(B), 36, 48, 54, [Mbit/sec]
         Tag: Extended Supported Rates and BSS Membership Selectors BSS 
requires support for direct hashing to elements in SAE, [Mbit/sec]
         Tag: Extended Capabilities (11 octets)
         Ext Tag: HE Capabilities (IEEE Std 802.11ax/D2.0)
         Ext Tag: HE Operation (IEEE Std 802.11ax/D2.0)
         Ext Tag: Spatial Reuse Parameter Set
         Ext Tag: MU EDCA Parameter Set
         Ext Tag: 6GHz Band Capabilities

> johannes