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 Date: Fri, 13 Aug 2021 17:16:51 +0800 [thread overview] Message-ID: <465b6b8535fc17ae51ee2f3116af87bb@codeaurora.org> (raw) In-Reply-To: <f61cdc7bae2dd2a645e164ca143b9db402472559.camel@sipsolutions.net> 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
WARNING: multiple messages have this Message-ID (diff)
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 Date: Fri, 13 Aug 2021 17:16:51 +0800 [thread overview] Message-ID: <465b6b8535fc17ae51ee2f3116af87bb@codeaurora.org> (raw) In-Reply-To: <f61cdc7bae2dd2a645e164ca143b9db402472559.camel@sipsolutions.net> 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 -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k
next prev parent reply other threads:[~2021-08-13 9:16 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-17 20:19 [PATCH 0/9] cfg80211/mac80211: Add support for 6GHZ STA for various modes : LPI, SP and VLP Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-05-17 20:19 ` [PATCH 1/9] cfg80211: add power type definition for 6G Hz Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-07-23 9:22 ` Johannes Berg 2021-07-23 9:22 ` Johannes Berg 2021-05-17 20:19 ` [PATCH 2/9] mac80211: add definition of regulatory info in 6G Hz operation information Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-05-17 20:19 ` [PATCH 3/9] mac80211: add parse " Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-07-23 9:23 ` Johannes Berg 2021-07-23 9:23 ` Johannes Berg 2021-05-17 20:19 ` [PATCH 4/9] cfg80211: add definition for 6G power spectral density(psd) Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-07-23 9:24 ` Johannes Berg 2021-07-23 9:24 ` Johannes Berg 2021-07-30 10:00 ` Wen Gong 2021-07-30 10:00 ` Wen Gong 2021-05-17 20:19 ` [PATCH 5/9] cfg80211: save power spectral density(psd) of regulatory rule Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-07-23 9:27 ` Johannes Berg 2021-07-23 9:27 ` Johannes Berg 2021-07-30 10:06 ` Wen Gong 2021-07-30 10:06 ` Wen Gong 2021-05-17 20:19 ` [PATCH 6/9] mac80211: add definition for transmit power envelope element Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-07-23 9:29 ` Johannes Berg 2021-07-23 9:29 ` Johannes Berg 2021-07-23 9:31 ` Johannes Berg 2021-07-23 9:31 ` Johannes Berg 2021-07-30 10:27 ` Wen Gong 2021-07-30 10:27 ` Wen Gong 2021-05-17 20:19 ` [PATCH 7/9] mac80211: add parse " Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-07-23 9:33 ` Johannes Berg 2021-07-23 9:33 ` Johannes Berg 2021-07-30 10:16 ` Wen Gong 2021-07-30 10:16 ` Wen Gong 2021-05-17 20:19 ` [PATCH 8/9] mac80211: add transmit power envelope element and power constraint in bss_conf Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-07-23 9:33 ` Johannes Berg 2021-07-23 9:33 ` Johannes Berg 2021-05-17 20:19 ` [PATCH 9/9] mac80211: save transmit power envelope element and power constraint Wen Gong 2021-05-17 20:19 ` Wen Gong 2021-07-23 9:38 ` Johannes Berg 2021-07-23 9:38 ` Johannes Berg 2021-07-30 10:47 ` Wen Gong 2021-07-30 10:47 ` Wen Gong 2021-08-03 8:53 ` Wen Gong 2021-08-03 8:53 ` Wen Gong 2021-08-13 7:19 ` Johannes Berg 2021-08-13 7:19 ` Johannes Berg 2021-08-13 7:25 ` Johannes Berg 2021-08-13 7:25 ` Johannes Berg 2021-08-13 8:47 ` Wen Gong 2021-08-13 8:47 ` Wen Gong 2021-08-13 8:53 ` Johannes Berg 2021-08-13 8:53 ` Johannes Berg 2021-08-13 9:16 ` Wen Gong [this message] 2021-08-13 9:16 ` Wen Gong 2021-08-13 10:11 ` Johannes Berg 2021-08-13 10:11 ` Johannes Berg 2021-08-13 10:29 ` Wen Gong 2021-08-13 10:29 ` Wen Gong 2021-08-13 8:13 ` Wen Gong 2021-08-13 8:13 ` Wen Gong 2021-05-25 10:04 ` [PATCH 0/9] cfg80211/mac80211: Add support for 6GHZ STA for various modes : LPI, SP and VLP Wen Gong 2021-05-25 10:04 ` Wen Gong 2021-06-15 8:52 ` Wen Gong 2021-06-15 8:52 ` Wen Gong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=465b6b8535fc17ae51ee2f3116af87bb@codeaurora.org \ --to=wgong@codeaurora.org \ --cc=ath11k@lists.infradead.org \ --cc=johannes@sipsolutions.net \ --cc=linux-wireless@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.