Re: [PATCH 9/9] mac80211: save transmit power envelope element and power constraint
From: Johannes Berg <johannes@sipsolutions.net>
Date: 2021-08-13 08:53:21
Also in:
ath11k
On Fri, 2021-08-13 at 16:47 +0800, Wen Gong wrote:
quoted
quoted
quoted
quoted
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. johannesI 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? And if we always defer this until the first beacon, that also feels wrong and bad? 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?) 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? johannes