Search Linux Wireless

Re: [PATCH 9/9] mac80211: save transmit power envelope element and power constraint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-08-13 15:25, Johannes Berg wrote:
On Fri, 2021-08-13 at 09:19 +0200, Johannes Berg 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.



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux