summaryrefslogtreecommitdiff
path: root/net/mac80211
AgeCommit message (Collapse)Author
2025-09-19wifi: mac80211: Extend support for changing NAN configurationIlan Peer
As 'struct cfg80211_nan_config' was updated, update the relevant logic to accommodate these changes. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250908140015.92b530ddaedf.I2b6d6f6074e25487303fde573ce764a64f87bdcd@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-19wifi: mac80211: Export an API to check if NAN is startedIlan Peer
So it can be used by drivers to check if NAN Device interface is started or not. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250908140015.c69652f77eb6.Ie4f3d197e0706e742e3d97614fadc11b22adfbc6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-19wifi: mac80211: Get the correct interface for non-netdev skb statusIlan Peer
The function ieee80211_sdata_from_skb() always returned the P2P Device interface in case the skb was not associated with a netdev and didn't consider the possibility that an NAN Device interface is also enabled. To support configurations where both P2P Device and a NAN Device interface are active, extend the function to match the correct interface based on address 2 in the 802.11 MAC header. Since the 'p2p_sdata' field in struct ieee80211_local is no longer needed, remove it. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250908140015.5252d2579a49.Id4576531c6b2ad83c9498b708dc0ade6b0214fa8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-19wifi: mac80211: Track NAN interface start/stopIlan Peer
In case that NAN is started, mark the device as non idle, and set LED triggering similar to scan and ROC. Set the device to idle once NAN is stopped. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250908140015.2711d62fce22.I9b9f826490e50967a66788d713b0eba985879873@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-19wifi: mac80211: Accept management frames on NAN interfaceIlan Peer
Accept Public Action frames and Authentication frames on NAN Device interface to support flows that require these frames: - SDFs: For user space Discovery Engine (DE) implementation. - NAFs: For user space NAN Data Path (NDP) establishment. - Authentication frames: For NAN Pairing and Verification. Accept only frames from devices that are part of the NAN cluster. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250908140015.46528d69e881.Ifccd87fb2a49a3af05238f74f52fa6da8de28811@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-19wifi: mac80211: Support Tx of action frame for NANIlan Peer
Add support for sending management frame over a NAN Device interface: - Declare support for the supported management frames types. - Since action frame transmissions over a NAN Device interface do not necessarily require a channel configuration, e.g., they can be transmitted during DW, modify the Tx path to avoid accessing channel information for NAN Device interface. - In addition modify the points in the Tx path logic to account for cases that a band is not specified in the Tx information. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250908140015.23b160089228.I65a58af753bcbcfb5c4ad8ef372d546f889725ba@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-11Merge tag 'wireless-next-2025-09-11' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Plenty of things going on, notably: - iwlwifi: major cleanups/rework - brcmfmac: gets AP isolation support - mac80211: gets more S1G support * tag 'wireless-next-2025-09-11' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (94 commits) wifi: mwifiex: fix endianness handling in mwifiex_send_rgpower_table wifi: cfg80211: Remove the redundant wiphy_dev wifi: mac80211: fix incorrect comment wifi: cfg80211: update the time stamps in hidden ssid wifi: mac80211: Fix HE capabilities element check wifi: mac80211: add tx_handlers_drop statistics to ethtool wifi: mac80211: fix reporting of all valid links in sta_set_sinfo() wifi: iwlwifi: mld: CHANNEL_SURVEY_NOTIF is always supported wifi: iwlwifi: mld: remove support of iwl_esr_mode_notif version 1 wifi: iwlwifi: mld: remove support from of sta cmd version 1 wifi: iwlwifi: mld: remove support of roc cmd version 5 wifi: iwlwifi: mld: remove support of mac cmd ver 2 wifi: iwlwifi: mld: don't consider phy cmd version 5 wifi: iwlwifi: implement wowlan status notification API update wifi: iwlwifi: fw: Add ASUS to PPAG and TAS list wifi: iwlwifi: add kunit tests for nvm parse wifi: iwlwifi: api: add a flag to iwl_link_ctx_modify_flags wifi: iwlwifi: pcie: move ltr_enabled to the specific transport wifi: iwlwifi: pcie: move pm_support to the specific transport wifi: iwlwifi: rename iwl_finish_nic_init ... ==================== Link: https://patch.msgid.link/20250911100854.20445-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-10wifi: mac80211: fix incorrect commentMiri Korenblit
As opposed to what the comment says, we don't count in the skb size of the association request frame the length of the Per STA Profile of the association link. Fix the comment. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250908122652.7022f33b1f33.Iac0d35744df883e8b96d71bbe8da518cc5d514bf@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-10wifi: mac80211: Fix HE capabilities element checkIlan Peer
The element data length check did not account for the extra octet used for the extension ID. Fix it. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250907115109.8da0012e2286.I8c0c69a0011f7153c13b365b14dfef48cfe7c3e3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-10wifi: mac80211: add tx_handlers_drop statistics to ethtoolSarika Sharma
Currently tx_handlers_drop statistics are handled only for slow TX path and only at radio level. This also requires CONFIG_MAC80211_DEBUG_COUNTERS to be enabled to account the dropped packets. There is no way to check these stats for fast TX, at interface level and monitor without enabling the debug configuration. Hence, add a new counter at the sdata level to track packets dropped with reason as TX_DROP during transmission for fast path, slow path and other tx management packets. Expose this via ethtool statistics, to improve visibility into transmission failures at interface level and aid debugging and performance monitoring. Place the counter in ethtool with other available tx_* stats for better readability and accurate tracking. Sample output: root@buildroot:~# ethtool -S wlan0 NIC statistics: rx_packets: 5904 rx_bytes: 508122 rx_duplicates: 12 rx_fragments: 5900 rx_dropped: 12 tx_packets: 391487 tx_bytes: 600423383 tx_filtered: 0 tx_retry_failed: 10332 tx_retries: 1548 tx_handlers_drop: 4 .... Co-developed-by: Hari Chandrakanthan <quic_haric@quicinc.com> Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com> Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Link: https://patch.msgid.link/20250822052110.513804-1-quic_sarishar@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-10wifi: mac80211: fix reporting of all valid links in sta_set_sinfo()Sarika Sharma
Currently, sta_set_sinfo() fails to populate link-level station info when sinfo->valid_links is initially 0 and sta->sta.valid_links has bits set for links other than link 0. This typically occurs when association happens on a non-zero link or link 0 deleted dynamically. In such cases, the for_each_valid_link(sinfo, link_id) loop only executes for link 0 and terminates early, since sinfo->valid_links remains 0. As a result, only MLD-level information is reported to userspace. Hence to fix, initialize sinfo->valid_links with sta->sta.valid_links before entering the loop to ensure loop executes for each valid link. During iteration, mask out invalid links from sinfo->valid_links if any of sta->link[link_id], sdata->link[link_id], or sinfo->links[link_id] are not present, to report only valid link information. Fixes: 505991fba9ec ("wifi: mac80211: extend support to fill link level sinfo structure") Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Link: https://patch.msgid.link/20250904104054.790321-1-quic_sarishar@quicinc.com [clarify comment] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: mac80211: Fix 6 GHz Band capabilities element advertisement in lower bandsRamya Gnanasekar
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>
2025-09-04wifi: mac80211: reduce the scope of rts_thresholdMiri Korenblit
This is only needed within the 'if' scope, not in the function scope. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250903083904.1972284-3-miriam.rachel.korenblit@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: mac80211: reduce the scope of link_idMiri Korenblit
Reduce the scope of the link_id variable in sta_set_sinfo to the 'if' scope. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250903083904.1972284-2-miriam.rachel.korenblit@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: drivers: indicate support for attributes in NL80211_CMD_SET_BSSArend van Spriel
The command NL80211_CMD_SET_BSS has a number of individual attributes and the driver can advertise which of those it will handle when it is changed by user-space. For drivers providing an empty .change_bss() the callback has been removed. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20250817190435.1495094-3-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: mac80211: consider links for validating SCAN_FLAG_AP in scan request ↵Aditya Kumar Singh
during MLO Commit 78a7a126dc5b ("wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO") introduced a check that rejects scan requests if any link is already beaconing. This works fine when all links share the same radio, but breaks down in multi-radio setups. Consider a scenario where a 2.4 GHz link is beaconing and a scan is requested on a 5 GHz link, each backed by a different physical radio. The current logic still blocks the scan, even though it should be allowed. As a result, interface bring-up fails unnecessarily in valid configurations. Fix this by checking whether the scan is being requested on the same underlying radio as the beaconing link. Only reject the scan if it targets a link that is already beaconing and the NL80211_FEATURE_AP_SCAN is not set. This ensures correct behavior in multi-radio environments and avoids false rejections. Fixes: 78a7a126dc5b ("wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO") Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250812-fix_scan_ap_flag_requirement_during_mlo-v4-3-383ffb6da213@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: mac80211: simplify return value handling of ↵Aditya Kumar Singh
cfg80211_get_radio_idx_by_chan() In several instances where cfg80211_get_radio_idx_by_chan() is called, redundant checks are performed across function — such as verifying if wiphy->n_radio < 2 or if the returned index is negative. These checks are unnecessary, as the return value can be directly compared. Moreover, the function can be safely called even when radio-level properties are not explicitly advertised since in such case in each call it is going to get same error value. Therefore, simplify the usage of this function across all such cases by removing redundant conditions and relying on the return value directly. Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250812-fix_scan_ap_flag_requirement_during_mlo-v4-2-383ffb6da213@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: mac80211: kunit: add kunit tests for S1G PVB decodingLachlan Hodges
Add support for testing the 6 examples mentioned in IEEE80211-2024 Annex L. These tests cover the 3 mandatory decoding modes being block bitmap, single AID and OLB alongside their equivalent inverses. Test output: 1..6 s1g_tim_block_test: Block 0 (ENC=BLOCK, blk_off=0, inverse=0) s1g_tim_block_test: octet 1 (ctrl) : 00000000 (0x00) s1g_tim_block_test: octet 2 (blk-map) : 00000101 (0x05) s1g_tim_block_test: octet 3 (SB 0) : 01000010 (0x42) s1g_tim_block_test: octet 4 (SB 2) : 10100000 (0xa0) ok 1 s1g_tim_block_test s1g_tim_single_test: Block 0 (ENC=SINGLE, blk_off=0, inverse=0) s1g_tim_single_test: octet 1 (ctrl) : 00000001 (0x01) s1g_tim_single_test: octet 2 (single) : 00011111 (0x1f) ok 2 s1g_tim_single_test s1g_tim_olb_test: Block 0 (ENC=OLB, blk_off=0, inverse=0) s1g_tim_olb_test: octet 1 (ctrl) : 00000010 (0x02) s1g_tim_olb_test: octet 2 (len= 9) : 00001001 (0x09) s1g_tim_olb_test: octet 3 (SB 0) : 01000010 (0x42) s1g_tim_olb_test: octet 4 (SB 1) : 10100000 (0xa0) s1g_tim_olb_test: octet 5 (SB 2) : 01000010 (0x42) s1g_tim_olb_test: octet 6 (SB 3) : 10100000 (0xa0) s1g_tim_olb_test: octet 7 (SB 4) : 01000010 (0x42) s1g_tim_olb_test: octet 8 (SB 5) : 10100000 (0xa0) s1g_tim_olb_test: octet 9 (SB 6) : 01000010 (0x42) s1g_tim_olb_test: octet 10 (SB 7) : 10100000 (0xa0) s1g_tim_olb_test: octet 11 (SB 8) : 01000010 (0x42) ok 3 s1g_tim_olb_test s1g_tim_inverse_block_test: Block 0 (ENC=BLOCK, blk_off=0, inverse=1) s1g_tim_inverse_block_test: octet 1 (ctrl) : 00000100 (0x04) s1g_tim_inverse_block_test: octet 2 (blk-map) : 00000101 (0x05) s1g_tim_inverse_block_test: octet 3 (SB 0) : 01000010 (0x42) s1g_tim_inverse_block_test: octet 4 (SB 2) : 10100000 (0xa0) ok 4 s1g_tim_inverse_block_test s1g_tim_inverse_single_test: Block 0 (ENC=SINGLE, blk_off=0, inverse=1) s1g_tim_inverse_single_test: octet 1 (ctrl) : 00000101 (0x05) s1g_tim_inverse_single_test: octet 2 (single) : 00011111 (0x1f) ok 5 s1g_tim_inverse_single_test s1g_tim_inverse_olb_test: Block 0 (ENC=OLB, blk_off=0, inverse=1) s1g_tim_inverse_olb_test: octet 1 (ctrl) : 00000110 (0x06) s1g_tim_inverse_olb_test: octet 2 (len= 9) : 00001001 (0x09) s1g_tim_inverse_olb_test: octet 3 (SB 0) : 01000010 (0x42) s1g_tim_inverse_olb_test: octet 4 (SB 1) : 10100000 (0xa0) s1g_tim_inverse_olb_test: octet 5 (SB 2) : 01000010 (0x42) s1g_tim_inverse_olb_test: octet 6 (SB 3) : 10100000 (0xa0) s1g_tim_inverse_olb_test: octet 7 (SB 4) : 01000010 (0x42) s1g_tim_inverse_olb_test: octet 8 (SB 5) : 10100000 (0xa0) s1g_tim_inverse_olb_test: octet 9 (SB 6) : 01000010 (0x42) s1g_tim_inverse_olb_test: octet 10 (SB 7) : 10100000 (0xa0) s1g_tim_inverse_olb_test: octet 11 (SB 8) : 01000010 (0x42) ok 6 s1g_tim_inverse_olb_test mac80211-s1g-tim: pass:6 fail:0 skip:0 total:6 Totals: pass:6 fail:0 skip:0 total:6 Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250725132221.258217-4-lachlan.hodges@morsemicro.com [make tim_push() void, non-inline] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: mac80211: support parsing S1G TIM PVBLachlan Hodges
An S1G TIM PVB has 3 mandatory encoding modes, that being block bitmap, single AID and OBL alongside the ability for each encoding mode to be inverted. Introduce the ability to parse the 3 encoding formats. The implementation specification for the encoding formats can be found in IEEE80211-2024 9.4.2.5. Signed-off-by: Arien Judge <arien.judge@morsemicro.com> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250725132221.258217-3-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-04wifi: mac80211: support block bitmap S1G TIM encodingLachlan Hodges
An S1G TIM PVB is encoded differently compared to a non-s1g TIM PVB. As the AP dictates which encoding mode it uses, here we only implement block bitmap encoding. This is the default encoding mode used by all current vendor implementations. Additionally, S1G has a maximum AID count of 8192, however we are limiting the current implementation to 1600. This has no resemblence to the standard and is purely an implementation detail. The reason for this is due to the TIM elements maximum length of 255. This allows for, at most, 25 encoded blocks for a PVB encoded with block bitmap. Support for the maximum of 8192 AIDs will require an implementation of page slicing to be added to mac80211. As a result, we perform extra validation on both the STA and AP side when receiving an AID as an S1G interface. Add support for block bitmap encoding for an S1G AP and limit the maximum AID count to 1600 for the current mac80211 implementations. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250725132221.258217-2-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-03wifi: mac80211: count reg connection element in the sizeMiri Korenblit
We currently don't count the reg connection length in the per-link capability length. Fix it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250826202512.b14fc82f736b.I03442382e8a07f6f9836bcdac2e22ce8afbe6a21@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-03wifi: mac80211: Make CONNECTION_MONITOR optional for MLO staLorenzo Bianconi
Since commit '1bc892d76a6f ("wifi: mac80211: extend connection monitoring for MLO")' mac80211 supports connection monitor for MLO client interfaces. Remove the CONNECTION_MONITOR requirement in ieee80211_register_hw routine. Fixes: 1bc892d76a6f ("wifi: mac80211: extend connection monitoring for MLO") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250826-remove-conn-mon-check-ieee80211_register_hw-v2-1-5a1e2f038245@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-08-28wifi: mac80211: do not permit 40 MHz EHT operation on 5/6 GHzBenjamin Berg
The EHT PHY requirements state that 80 MHz must be supported on the 5 and 6 GHz bands unless the STA is 20 MHz only. So if the channel width is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and downgrade to HE. The primary case where this can happen is if the hardware disables puncturing using IEEE80211_HW_DISALLOW_PUNCTURING. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250826202553.a6582f3abf57.Ic670429dc7127f68c818b4290d950ebfb5a0b9e1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-08-26wifi: mac80211: increase scan_ies_len for S1GLachlan Hodges
Currently the S1G capability element is not taken into account for the scan_ies_len, which leads to a buffer length validation failure in ieee80211_prep_hw_scan() and subsequent WARN in __ieee80211_start_scan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250826085437.3493-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-08-26wifi: mac80211: fix incorrect type for retLiao Yuanhong
The variable ret is declared as a u32 type, but it is assigned a value of -EOPNOTSUPP. Since unsigned types cannot correctly represent negative values, the type of ret should be changed to int. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://patch.msgid.link/20250825022911.139377-1-liaoyuanhong@vivo.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: mac80211: fix WARN_ON for monitor mode on some devicesJohannes Berg
On devices without WANT_MONITOR_VIF (and probably without channel context support) we get a WARN_ON for changing the per-link setting of a monitor interface. Since we already skip AP_VLAN interfaces and MONITOR with WANT_MONITOR_VIF and/or NO_VIRTUAL_MONITOR should update the settings, catch this in the link change code instead of the warning. Reported-by: Martin Kaistra <martin.kaistra@linutronix.de> Link: https://lore.kernel.org/r/a9de62a0-28f1-4981-84df-253489da74ed@linutronix.de/ Fixes: c4382d5ca1af ("wifi: mac80211: update the right link for tx power") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22wifi: mac80211: fix unassigned variable accessAntonio Quartulli
In ieee80211_latest_active_link_conn_timeout() we loop over all sta->links in order to compute the timeout expiring last across all links. Such timeout is stored in `latest_timeout` which is used in the time_after() comparison before having been initialized. Fix this behaviour by initializing the variable to `jiffies` and adapt surrouding conditions accordingly. Note that the caller assumed latest_timeout to be 0 if no active link was found. This is not appropriate because jiffies=0 is a valid (and recurrent, although not often) point in time. By using `jiffies` as default value for latest_timeout, we can fix the caller as well. Address-Coverity-ID: 1647986 ("Uninitialized variables (UNINIT)") Fixes: 1bc892d76a6f ("wifi: mac80211: extend connection monitoring for MLO") Signed-off-by: Antonio Quartulli <antonio@mandelbit.com> Link: https://patch.msgid.link/20250722120634.3501-1-antonio@mandelbit.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22wifi: mac80211: don't require cipher and keylen in gtk rekeyMiri Korenblit
ieee80211_add_gtk_rekey receives a keyconf as an argument, and the cipher and keylen are taken from there to the new allocated key. But in rekey, both the cipher and the keylen should be the same as of the old key, so let ieee80211_add_gtk_rekey find those, so drivers won't have to fill it in. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250721214922.3c5c023bfae9.Ie6594ae2b4b6d5b3d536e642b349046ebfce7a5d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon()Kees Cook
While I caught the need for setting cnt early in nl80211_parse_rnr_elems() in the original annotation of struct cfg80211_rnr_elems with __counted_by, I missed a similar pattern in ieee80211_copy_rnr_beacon(). Fix this by moving the cnt assignment to before the loop. Fixes: 7b6d7087031b ("wifi: cfg80211: Annotate struct cfg80211_rnr_elems with __counted_by") Signed-off-by: Kees Cook <kees@kernel.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/20250721182521.work.540-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-21wifi: cfg80211/mac80211: report link ID for unexpected framesMichael-CY Lee
The upper layer may require the link ID to properly handle unexpected frames. For instance, if hostapd, operating as an AP MLD, receives a data frame from a non-associated STA, it must send deauthentication to the link on which the STA is operating. Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com> Reviewed-by: Money Wang <money.wang@mediatek.com> Link: https://patch.msgid.link/20250721065159.1740992-1-michael-cy.lee@mediatek.com [edit commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-21wifi: mac80211: determine missing link_id in ieee80211_rx_for_interface() ↵Michael-CY Lee
based on frequency For broadcast frames, every interface might have to process it and therefore the link_id cannot be determined in the driver. In mac80211, when the frame is about to be forwarded to each interface, we can use the member "freq" in struct ieee80211_rx_status to determine the "link_id" for each interface. Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com> Reviewed-by: Money Wang <money.wang@mediatek.com> Link: https://patch.msgid.link/20250721062929.1662700-1-michael-cy.lee@mediatek.com [simplify, remove unnecessary link->conf check] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-21wifi: mac80211: remove ieee80211_remove_keyMiri Korenblit
It is no longer used, remove it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250721091956.e964ceacd85c.Idecab8ef161fa58e000b3969bc936399284b79f0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18Reapply "wifi: mac80211: Update skb's control block key in ↵Remi Pommarel
ieee80211_tx_dequeue()" This reverts commit 0937cb5f345c ("Revert "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()""). This commit broke TX with 802.11 encapsulation HW offloading, now that this is fixed, reapply it. Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/66b8fc39fb0194fa06c9ca7eeb6ffe0118dcb3ec.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key()Remi Pommarel
With 802.11 encapsulation offloading, ieee80211_tx_h_select_key() is called on 802.3 frames. In that case do not try to use skb data as valid 802.11 headers. Reported-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/linux-wireless/20250410215527.3001-1-spasswolf@web.de Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/1af4b5b903a5fca5ebe67333d5854f93b2be5abe.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Don't call fq_flow_idx() for management framesAlexander Wetzel
skb_get_hash() can only be used when the skb is linked to a netdev device. Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Fixes: 73bc9e0af594 ("mac80211: don't apply flow control on management frames") Link: https://patch.msgid.link/20250717162547.94582-3-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Do not schedule stopped TXQsAlexander Wetzel
Ignore TXQs with the flag IEEE80211_TXQ_STOP when scheduling a queue. The flag is only set after all fragments have been dequeued and won't allow dequeueing other frames as long as the flag is set. For drivers using ieee80211_txq_schedule_start() this prevents an loop trying to push the queued frames while IEEE80211_TXQ_STOP is set: After setting IEEE80211_TXQ_STOP the driver will call ieee80211_return_txq(). Which calls __ieee80211_schedule_txq(), detects that there sill are frames in the queue and immediately restarts the stopped TXQ. Which can't dequeue any frame and thus starts over the loop. Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Link: https://patch.msgid.link/20250717162547.94582-2-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: support returning the S1G short beacon skbLachlan Hodges
When short beaconing is enabled, check the value of the sb_count to determine whether we are to send a long beacon or short beacon. sb_count represents the number of short beacons until the next long beacon, where if its value is 0 we are to send a long beacon. The value is then reset to the long beacon period, which represents the number of beacon intervals between each long beacon. The decrement process follows the same cadence as the decrement of the DTIM count value. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250717074205.312577-5-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: support initialising current S1G short beacon indexLachlan Hodges
Introduce the sb_count variable which tracks the number of beacon intervals until the next long beacon. To initialise this value, we find the current short beacon index into this period which represents the number of short beacons left to send before the next long beacon. We use the same TSF value used to initialise the DTIM count to ensure the short beacon count and DTIM count are in sync as its common for the long beacon period and DTIM period to be equivalent. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250717074205.312577-4-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: support initialising an S1G short beaconing BSSLachlan Hodges
Introduce the ability to parse the short beacon data and long beacon period. The long beacon period represents the number of beacon intervals between each long beacon transmission. Additionally, as a BSS cannot change its configuration such that short beaconing is dynamically disabled/enabled without tearing down the interface - we ensure we have an existing short beacon before performing the update. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250717074205.312577-3-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: reject TDLS operations when station is not associatedMoon Hee Lee
syzbot triggered a WARN in ieee80211_tdls_oper() by sending NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT, before association completed and without prior TDLS setup. This left internal state like sdata->u.mgd.tdls_peer uninitialized, leading to a WARN_ON() in code paths that assumed it was valid. Reject the operation early if not in station mode or not associated. Reported-by: syzbot+f73f203f8c9b19037380@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f73f203f8c9b19037380 Fixes: 81dd2b882241 ("mac80211: move TDLS data to mgd private part") Tested-by: syzbot+f73f203f8c9b19037380@syzkaller.appspotmail.com Signed-off-by: Moon Hee Lee <moonhee.lee.ca@gmail.com> Link: https://patch.msgid.link/20250715230904.661092-2-moonhee.lee.ca@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: extend connection monitoring for MLOMaharaja Kennadyrajan
Currently, reset connection monitor (ieee80211_sta_reset_conn_monitor()) timer is handled only for non-AP non-MLD STA and do not support non-AP MLD STA. The current implementation checks for the CSA active and update the monitor timer with the timeout value of deflink and reset the timer based on the deflink's timeout value else schedule the connection loss work when the deflink is timed out and it won't work for the non-AP MLD STA. Handle the reset connection monitor timer for non-AP MLD STA by updating the monitor timer with the timeout value which is determined based on the link that will expire last among all the links in MLO. If at least one link has not timed out, the timer is updated accordingly with the latest timeout value else schedule the connection loss work when all links have timed out. Remove the MLO-related WARN_ON() checks in the beacon and connection monitoring logic code paths as they support MLO now. Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250718060837.59371-5-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: extend beacon monitoring for MLOMaharaja Kennadyrajan
Currently, reset beacon monitor (ieee80211_sta_reset_beacon_monitor()) timer is handled only for non-AP non-MLD STA and do not support non-AP MLD STA. When the beacon loss occurs in non-AP MLD STA with the current implementation, it is treated as a single link and the timer will reset based on the timeout of the deflink, without checking all the links. Check the CSA flags for all the links in the MLO and decide whether to schedule the work queue for beacon loss. If any of the links has CSA active, then beacon loss work is not scheduled. Also, call the functions ieee80211_sta_reset_beacon_monitor() and ieee80211_sta_reset_conn_monitor() from ieee80211_csa_switch_work() only when all the links are CSA active. Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250718060837.59371-4-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: Add link iteration macro for link data with rcu_dereferenceMaharaja Kennadyrajan
Currently, the existing macro for_each_link_data() uses sdata_dereference() which requires the wiphy lock. This lock cannot be used in atomic or RCU read-side contexts, such as in the RX path. Introduce a new macro, for_each_link_data_rcu(), that iterates over link of sdata using rcu_dereference(), making it safe to use in RCU contexts. This allows callers to access link data without requiring the wiphy lock. The macro takes into account the vif.valid_links bitmap and ensures only valid links are accessed safely. Callers are responsible for ensuring that rcu_read_lock() is held when using this macro. Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250718060837.59371-3-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: mac80211: fix macro scoping in for_each_link_dataAditya Kumar Singh
The for_each_link_data() macro currently declares a local variable __sdata directly, which could lead to compiler warnings or errors when reused in the same function or within switch-case blocks due to variable redefinition or invalid scoping. To address this, restructure the macro to use an outer for-loop that runs only once, allowing safe declaration of __sdata without polluting the outer scope. This ensures compatibility with static analyzers. No functional changes; this is purely a cleanup to improve macro hygiene. Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250718060837.59371-2-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-18wifi: cfg80211/mac80211: remove wrong scan request n_channelsJohannes Berg
This (partially) reverts commits - 838c7b8f1f27 ("wifi: nl80211: Avoid address calculations via out of bounds array indexing") - f1d3334d604c ("wifi: cfg80211: sme: init n_channels before channels[] access") - 82bbe02b2500 ("wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request") These commits all set the structure to be in an inconsistent state, setting n_channels to some value before them actually being filled in. That's fine for what the code does now, but with the removal of __counted_by() in 444020f4bf06 ("wifi: cfg80211: remove scan request n_channels counted_by") it's no longer needed and it does leave a bit of a landmine there since breaking out of some code to send the scan or something would leave it wrong. Remove the now superfluous n_channels settings. Link: https://patch.msgid.link/20250718103237.59510b2384c5.Ied5ba9c5c49efc008f4491c8ca7a45858a83f064@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: use RCU-safe iteration in ieee80211_csa_finishMaharaja Kennadyrajan
The ieee80211_csa_finish() function currently uses for_each_sdata_link() to iterate over links of sdata. However, this macro internally uses wiphy_dereference(), which expects the wiphy->mtx lock to be held. When ieee80211_csa_finish() is invoked under an RCU read-side critical section (e.g., under rcu_read_lock()), this leads to a warning from the RCU debugging framework. WARNING: suspicious RCU usage net/mac80211/cfg.c:3830 suspicious rcu_dereference_protected() usage! This warning is triggered because wiphy_dereference() is not safe to use without holding the wiphy mutex, and it is being used in an RCU context without the required locking. Fix this by introducing and using a new macro, for_each_sdata_link_rcu(), which performs RCU-safe iteration over sdata links using list_for_each_entry_rcu() and rcu_dereference(). This ensures that the link pointers are accessed safely under RCU and eliminates the warning. Fixes: f600832794c9 ("wifi: mac80211: restructure tx profile retrieval for MLO MBSSID") Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250711033846.40455-1-maharaja.kennadyrajan@oss.qualcomm.com [unindent like the non-RCU macro] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: parse unsolicited broadcast probe response dataYuvarani V
During commands like channel switch and color change, the updated unsolicited broadcast probe response template may be provided. However, this data is not parsed or acted upon in mac80211. Add support to parse it and set the BSS changed flag BSS_CHANGED_UNSOL_BCAST_PROBE_RESP so that drivers could take further action. Signed-off-by: Yuvarani V <quic_yuvarani@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250710-update_unsol_bcast_probe_resp-v2-2-31aca39d3b30@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't use TPE data from assoc responseJohannes Berg
Since there's no TPE element in the (re)assoc response, trying to use the data from it just leads to using the defaults, even though the real values had been set during authentication from the discovered BSS information. Fix this by simply not handling the TPE data in assoc response since it's not intended to be present, if it changes later the necessary changes will be made by tracking beacons later. As a side effect, by passing the real frame subtype, now print a correct value for ML reconfiguration responses. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.caa1ca853f5a.I588271f386731978163aa9d84ae75d6f79633e16@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: handle WLAN_HT_ACTION_NOTIFY_CHANWIDTH asyncMiri Korenblit
If this action frame, with the value of IEEE80211_HT_CHANWIDTH_ANY, arrives right after a beacon that changed the operational bandwidth from 20 MHz to 40 MHz, then updating the rate control bandwidth to 40 can race with updating the chanctx width (that happens in the beacon proccesing) back to 40 MHz: cpu0 cpu1 ieee80211_rx_mgmt_beacon ieee80211_config_bw ieee80211_link_change_chanreq (*)ieee80211_link_update_chanreq ieee80211_rx_h_action (**)ieee80211_sta_cur_vht_bw (***) ieee80211_recalc_chanctx_chantype in (**), the maximum between the capability width and the bss width is returned. But the bss width was just updated to 40 in (*), so the action frame handling code will increase the width of the rate control before the chanctx was increased (in ***), leading to a FW error (at least in iwlwifi driver. But this is wrong regardless). Fix this by simply handling the action frame async, so it won't race with the beacon proccessing. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218632 Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.bb9dc6f36c35.I39782d6077424e075974c3bee4277761494a1527@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: simplify __ieee80211_rx_h_amsdu() loopJohannes Berg
The loop handling individual subframes can be simplified to not use a somewhat confusing goto inside the loop. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.a217a1e8c667.I5283df9627912c06c8327b5786d6b715c6f3a4e1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.0.4) at 2026-04-26 13:33:23 +0000