On Sat, 2020-04-25 at 18:57 +0300, Jouni Malinen wrote:
> +++ b/net/mac80211/offchannel.c
> @@ -955,6 +955,12 @@ int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> IEEE80211_SKB_CB(skb)->hw_queue =
> local->hw.offchannel_tx_hw_queue;
>
> + /* remember a random MAC address for Management frame exchange */
> + if (wiphy_ext_feature_isset(wiphy,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA) &&
> + !ether_addr_equal(mgmt->sa, wdev_address(wdev)))
> + memcpy(local->mgmt_tx_rand_addr, mgmt->sa, ETH_ALEN);
> +
> /* This will handle all kinds of coalescing and immediate TX */
> ret = ieee80211_start_roc_work(local, sdata, params->chan,
> params->wait, cookie, skb,
This feels wrong to me. It seems it should be made part of the roc work
item, and only copied over when that item actually starts, and also used
to not coalesce different items if they specify conflicting temporary
addresses.
> @@ -971,6 +977,9 @@ int ieee80211_mgmt_tx_cancel_wait(struct wiphy *wiphy,
> {
> struct ieee80211_local *local = wiphy_priv(wiphy);
>
> + /* stop using the random MAC address for Management frame exchange */
> + eth_zero_addr(local->mgmt_tx_rand_addr);
> +
> return ieee80211_cancel_roc(local, cookie, true);
Similar here, not clear that the ROC item even started yet at this
point.
It seems to me it needs to be pushed a layer deeper, say into
ieee80211_handle_roc_started() and ieee80211_offchannel_return() or so.
johannes
