kernel/linux.git/net/mac80211/agg-rx.c, branch v6.6

wifi: mac80211: remove support for AddBA with fragmentation

2022-10-07T13:24:31+00:00

HE added support for dynamic fragmentation inside aggregation sessions, but no existing driver ever advertises it. Thus, remove the code for now, it cannot work as-is in MLO. For it to properly work in MLO, we'd need to validate that the frag level is identical across all the link bands/iftypes, which is a good amount of complex code that's just not worth it as long as no driver has support for it. Signed-off-by: Johannes Berg

wifi: mac80211: agg-rx: avoid band check

2022-10-07T13:24:27+00:00

If the deflink of the station is on 6 GHz, then it won't have HT. If at the same time we're using MLO, then vif.bss_conf isn't used, and thus vif.bss_conf.chandef.chan is NULL, causing the code to crash. Fix this by just checking for both HT and HE, and refusing the aggregation session if both are not present. This might be a bit wrong since it would accept an aggregation session from a peer that has HE but no HT on 2.4 or 5 GHz, but such a peer shouldn't exist in the first place, and it probably supports aggregation if it has HE support. Signed-off-by: Johannes Berg

wifi: mac80211: change AddBA deny error message

2022-10-07T13:24:23+00:00

If the station has no HT, we deny the aggregation session but the error message talks about QoS; change it to say HT instead. Signed-off-by: Johannes Berg

wifi: mac80211: fix AddBA response addressing

2022-10-07T13:24:11+00:00

Since this frame is addressed from/to an MLD, it should be built with the correct AP MLD address (in station mode) to be encrypted properly. Signed-off-by: Johannes Berg

wifi: mac80211: fix multi-BSSID element parsing

2022-07-15T09:43:17+00:00

When parsing a frame containing a multi-BSSID element, we need to know both the transmitted and non-transmitted BSSID so we can parse it correctly. Unfortunately, in quite a number of cases, we got this wrong and were passing the wrong BSSID or useless information: * the mgmt->bssid from a frame is only the transmitted BSSID if the frame is a beacon * passing just one of the parameters as non-NULL isn't useful and ignored In those case where we need to parse for a specific BSS we always have a BSS structure pointer, representing the BSS we need, whether transmitted or not. Thus, pass that pointer to the parsing function instead of the two BSSIDs. Also fix two bugs: * we need to re-parse all the elements for the other BSS when iterating the non-transmitted BSSes in scan * we need to parse for the correct BSS when setting up the channel data in client code Fixes: 78ac51f81532 ("mac80211: support multi-bssid") Signed-off-by: Johannes Berg

wifi: mac80211: reorg some iface data structs for MLD

2022-06-20T10:55:06+00:00

Start reorganizing interface related data structures toward MLD. The most complex part here is for the keys, since we have to split the various kinds of GTKs off to the link but still need to use (for WEP) the other keys as a fallback even for multicast frames. Signed-off-by: Johannes Berg

mac80211: prepare sta handling for MLO support

2022-04-11T14:42:03+00:00

Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg

mac80211: parse AddBA request with extended AddBA element

2022-02-16T14:44:37+00:00

In EHT requesting aggregation with 1K needs the use of extended the AddBA element for the buffer size, so add the logic to parse it and make sure it's in limits of the EHT aggregation size. Signed-off-by: Mordechay Goodstein Link: https://lore.kernel.org/r/20220214173004.8209cae9d9e4.I434f5588602f83b4e658c660120040913b3a2e3d@changeid Signed-off-by: Johannes Berg

ieee80211: add EHT 1K aggregation definitions

2022-02-16T14:42:18+00:00

We add the fields for parsing extended ADDBA request/respond, and new max 1K aggregation for limit ADDBA request/respond. Adjust drivers to use the proper macro, IEEE80211_MAX_AMPDU_BUF -> IEEE80211_MAX_AMPDU_BUF_HE. Signed-off-by: Mordechay Goodstein Link: https://lore.kernel.org/r/20220214173004.b8b447ce95b7.I0ee2554c94e89abc7a752b0f7cc7fd79c273efea@changeid Signed-off-by: Johannes Berg

mac80211: fix lookup when adding AddBA extension element

2021-12-14T10:21:05+00:00

We should be doing the HE capabilities lookup based on the full interface type so if P2P doesn't have HE but client has it doesn't get confused. Fix that. Fixes: 2ab45876756f ("mac80211: add support for the ADDBA extension element") Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20211129152938.010fc1d61137.If3a468145f29d670cb00a693bed559d8290ba693@changeid Signed-off-by: Johannes Berg