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
