diff options
| author | Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com> | 2025-06-06 16:14:36 +0530 |
|---|---|---|
| committer | Johannes Berg <johannes.berg@intel.com> | 2025-09-04 11:47:03 +0200 |
| commit | e53f8b12a21c2974b66fa8c706090182da06fff3 (patch) | |
| tree | d4902222ce97def6e5607447dd20dcdd08e20214 /rust/helpers/platform.c | |
| parent | 7a7458ed0df90d4870f902fddc85b4a413ef7de4 (diff) | |
wifi: mac80211: Fix 6 GHz Band capabilities element advertisement in lower bands
Currently, when adding the 6 GHz Band Capabilities element, the channel
list of the wiphy is checked to determine if 6 GHz is supported for a given
virtual interface. However, in a multi-radio wiphy (e.g., one that has
both lower bands and 6 GHz combined), the wiphy advertises support for
all bands. As a result, the 6 GHz Band Capabilities element is incorrectly
included in mesh beacon and station's association request frames of
interfaces operating in lower bands, without verifying whether the
interface is actually operating in a 6 GHz channel.
Fix this by verifying if the interface operates on 6 GHz channel
before adding the element. Note that this check cannot be placed
directly in ieee80211_put_he_6ghz_cap() as the same function is used to
add probe request elements while initiating scan in which case the
interface may not be operating in any band's channel.
Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com>
Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20250606104436.326654-1-rameshkumar.sundaram@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'rust/helpers/platform.c')
0 files changed, 0 insertions, 0 deletions
