From: Johannes Berg <johannes@sipsolutions.net> To: Wen Gong <wgong@codeaurora.org>, ath11k@lists.infradead.org Cc: linux-wireless@vger.kernel.org Subject: Re: [PATCH 9/9] mac80211: save transmit power envelope element and power constraint Date: Fri, 23 Jul 2021 11:38:02 +0200 [thread overview] Message-ID: <d9491db4ece67ac78eb39a1078b91a106770fbb0.camel@sipsolutions.net> (raw) In-Reply-To: <20210517201932.8860-10-wgong@codeaurora.org> (sfid-20210517_222034_029448_A9A89D57) On Mon, 2021-05-17 at 16:19 -0400, Wen Gong wrote: > > + if (is_6ghz) { > + struct ieee802_11_elems elems; > + struct ieee80211_bss_conf *bss_conf; > + u8 i, n; > + > + ieee802_11_parse_elems(ies->data, ies->len, false, &elems, > + NULL, NULL); > + bss_conf = &sdata->vif.bss_conf; > + bss_conf->pwr_reduction = 0; > + if (elems.pwr_constr_elem) > + bss_conf->pwr_reduction = *elems.pwr_constr_elem; > + > + memset(bss_conf->tx_pwr_env, 0, sizeof(bss_conf->tx_pwr_env)); > + bss_conf->tx_pwr_env_num = elems.tx_pwr_env_num; > + n = min_t(u8, elems.tx_pwr_env_num, > + ARRAY_SIZE(elems.tx_pwr_env)); If anything, that min_t would make sense only if you were actually using ARRAY_SIZE(bss_conf->tx_pwr_env), but like this it's quite pointless, just checking again if the element parsing was internally consistent? I'd probably remove it and throw in a BUILD_BUG_ON(ARRAY_SIZE(bss_conf->tx_pwr_env) != ARRAY_SIZE(elems.tx_pwr_env)); instead. > + for (i = 0; i < n; i++) > + memcpy(&bss_conf->tx_pwr_env[i], elems.tx_pwr_env[i], > + elems.tx_pwr_env_len[i]); You also never validated that the element wasn't too long! If you connect to 6 Ghz with this, and then again to another AP that doesn't, you'll have it stuck at the old values. You need to reset at some point (during disconnect). And then two more questions: 1) Could this information change? Should we track it in beacons? 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? johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net> To: Wen Gong <wgong@codeaurora.org>, ath11k@lists.infradead.org Cc: linux-wireless@vger.kernel.org Subject: Re: [PATCH 9/9] mac80211: save transmit power envelope element and power constraint Date: Fri, 23 Jul 2021 11:38:02 +0200 [thread overview] Message-ID: <d9491db4ece67ac78eb39a1078b91a106770fbb0.camel@sipsolutions.net> (raw) In-Reply-To: <20210517201932.8860-10-wgong@codeaurora.org> (sfid-20210517_222034_029448_A9A89D57) On Mon, 2021-05-17 at 16:19 -0400, Wen Gong wrote: > > + if (is_6ghz) { > + struct ieee802_11_elems elems; > + struct ieee80211_bss_conf *bss_conf; > + u8 i, n; > + > + ieee802_11_parse_elems(ies->data, ies->len, false, &elems, > + NULL, NULL); > + bss_conf = &sdata->vif.bss_conf; > + bss_conf->pwr_reduction = 0; > + if (elems.pwr_constr_elem) > + bss_conf->pwr_reduction = *elems.pwr_constr_elem; > + > + memset(bss_conf->tx_pwr_env, 0, sizeof(bss_conf->tx_pwr_env)); > + bss_conf->tx_pwr_env_num = elems.tx_pwr_env_num; > + n = min_t(u8, elems.tx_pwr_env_num, > + ARRAY_SIZE(elems.tx_pwr_env)); If anything, that min_t would make sense only if you were actually using ARRAY_SIZE(bss_conf->tx_pwr_env), but like this it's quite pointless, just checking again if the element parsing was internally consistent? I'd probably remove it and throw in a BUILD_BUG_ON(ARRAY_SIZE(bss_conf->tx_pwr_env) != ARRAY_SIZE(elems.tx_pwr_env)); instead. > + for (i = 0; i < n; i++) > + memcpy(&bss_conf->tx_pwr_env[i], elems.tx_pwr_env[i], > + elems.tx_pwr_env_len[i]); You also never validated that the element wasn't too long! If you connect to 6 Ghz with this, and then again to another AP that doesn't, you'll have it stuck at the old values. You need to reset at some point (during disconnect). And then two more questions: 1) Could this information change? Should we track it in beacons? 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? johannes -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k
next prev parent reply other threads:[~2021-07-23 9:38 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 [this message] 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 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=d9491db4ece67ac78eb39a1078b91a106770fbb0.camel@sipsolutions.net \ --to=johannes@sipsolutions.net \ --cc=ath11k@lists.infradead.org \ --cc=linux-wireless@vger.kernel.org \ --cc=wgong@codeaurora.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.