- 03 Jan, 2024 10 commits
-
-
Benjamin Berg authored
The comment was referencing the wrong section of the documentation and was also subtly wrong as it assumed the rules that apply when sending probe requests directly to a nontransmitted AP. However, in that case the response comes from the transmitting AP and the AP MLD ID will be included. Fixes: 2481b5da ("wifi: cfg80211: handle BSS data contained in ML probe responses") Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240102213313.0917ab4b5d7f.I76aff0e261a5de44ffb467e591a46597a30d7c0a@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Ilan Peer authored
The default DSCP-to-UP mapping method defined in RFC8325 applied to packets marked per recommendations in RFC4594 and destined to 802.11 WLAN clients will yield a number of inconsistent QoS mappings. To handle this, modify the mapping of specific DSCP values for which the default mapping will create inconsistencies, based on the recommendations in section 4 in RFC8325. Note: RFC8235 is used as it referenced by both IEEE802.11Revme_D4.0 and WFA QoS Management Specification. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Reviewed-by:
Gregory Greenman <gregory.greenman@intel.com> Signed-off-by:
-
Benjamin Berg authored
This adds some scanning related tests, mainly exercising the ML element parsing and inheritance. Signed-off-by:
-
Johannes Berg authored
Extend the MFP tests to handle the case of deauth/disassoc and robust action frames (that are not protected dual of public action frames). Reviewed-by:
-
Johannes Berg authored
Generalize the test to be able to handle arbitrary action categories and non-action frames, for further test expansion. Reviewed-by:
-
Johannes Berg authored
Check the logic in ieee80211_drop_unencrypted_mgmt() according to a list of test cases derived from the spec. Reviewed-by:
-
Benjamin Berg authored
Add a simple convenience helper to allocate and zero fill an SKB for the use by a kunit test. Also provide a way to free it again in case that may be desirable. This simply mirrors the kunit_kmalloc API. Signed-off-by:
David Gow <davidgow@google.com> Link: https://msgid.link/20231220151952.415232-3-benjamin@sipsolutions.net [adjust file description as discussed] Signed-off-by:
-
Benjamin Berg authored
The existing KUNIT_ARRAY_PARAM macro requires a separate function to get the description. However, in a lot of cases the description can just be copied directly from the array. Add a second macro that avoids having to write a static function just for a single strscpy. Signed-off-by:
-
Zheng tan authored
Fix spelling of "attributes" in a comment. Reported-by:
k2ci <kernel-bot@kylinos.cn> Signed-off-by:
Zheng tan <tanzheng@kylinos.cn> Link: https://msgid.link/20240102015418.3673858-1-tanzheng@kylinos.cnSigned-off-by:
-
Edward Adam Davis authored
Replace rcu_dereference() with rcu_access_pointer() since we hold the lock here (and aren't in an RCU critical section). Fixes: 32af9a9e ("wifi: cfg80211: free beacon_ies when overridden from hidden BSS") Reported-and-tested-by: syzbot+864a269c27ee06b58374@syzkaller.appspotmail.com Signed-off-by:
Edward Adam Davis <eadavis@qq.com> Link: https://msgid.link/tencent_BF8F0DF0258C8DBF124CDDE4DD8D992DCF07@qq.comSigned-off-by:
-
- 21 Dec, 2023 30 commits
-
-
Andrei Otcheretianski authored
ENOTSUPP isn't a standard error code, don't use it. Replace with EOPNOTSUPP instead. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by:
-
Emmanuel Grumbach authored
The firmware can allow to clear the internal debug buffer. This can be used to sanitize the data when requested to. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by:
-
Johannes Berg authored
For now, this isn't allowed. The API to mac80211 isn't great for this, but we need to change the API to move puncturing into the chanctx/chandef, and will do it better then. Signed-off-by:
-
Johannes Berg authored
We don't want to duplicate the definitions later, so add them to the API. Signed-off-by:
-
Mukesh Sisodiya authored
Add the CSR register details for new wifi7 devices and correctly set rf_name for devices with FM and WP radios. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Reviewed-by:
-
Miri Korenblit authored
We don't support such device. Reviewed-by:
-
Miri Korenblit authored
eSR is activated when a chanctx is assigned to more than one link. During eSR activation we should disable RLC for both phys, and configure the FW with a special phy command for both phys. Currently we assign the phy_ctxt to the link only after eSR activation, so RLC is not disabled for the new phy_ctxt, and a cmd is not sent to FW. Fix this by first assigning the new phy_ctxt to the link and then doing the eSR activation. Fixes: 12bacfc2 ("wifi: iwlwifi: handle eSR transitions") Reviewed-by:
-
Anjaneyulu authored
The driver copies the userspace buffer into an internal NUL byte terminated buffer. While doing so, it was reading beyond the end of the userspace buffer, overwriting its own NUL termination in the process. Fix this by only copying the correct number of bytes. Fixes: 3f244876 ("wifi: iwlwifi: make debugfs entries link specific") Signed-off-by:
Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Reviewed-by:
-
Ilan Peer authored
It is possible that though multiple links are enabled we cannot enabled EMLSR enable more than a single link, e.g., all valid links are on the same band etc. Thus, do not warn in case no valid link pair is found. Fixes: b9be67fb ("wifi: iwlwifi: mvm: Add basic link selection logic") Signed-off-by:
-
Johannes Berg authored
Now with the mac80211 locking model changed, we no longer can cause any bad dependencies here between mvm->mutex and other mutexes in mac80211, so we no longer need to drop the mutex early or even temporarily. Clean this up. Signed-off-by:
-
Johannes Berg authored
If we want to drop packets, that's surely a good thing to do when we want to enter rfkill. Send this command despite rfkill so we can successfully clean up everything, we need to handle it separately since it has CMD_WANT_SKB, so it's not going to automatically return success when in rfkill. Fixes: d4e3a341 ("iwlwifi: mvm: add support for new flush queue response") Signed-off-by:
-
Andrei Otcheretianski authored
The NVM_CHANNEL_ACTIVE bit means that active scanning/beaconing is allowed, however it's not an exact opposite of IEEE80211_CHAN_NO_IR. For example, NVM_CHANNEL_ACTIVE bit is not set on DFS channels, while cfg80211 doesn't really expect NO-IR on DFS channels. Signed-off-by:
-
Andrei Otcheretianski authored
AX210 devices allow concurrent P2P operation on DFS channels. Signed-off-by:
-
Johannes Berg authored
The firmware changed their mind, don't set the chains to zero, instead set them to 1 as we normally would for connections to APs that don't use MIMO. Fixes: 2a7ce54c ("iwlwifi: mvm: honour firmware SMPS requests") Signed-off-by:
Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Miri Korenblit authored
During ieee80211_set_active_links() we do (among the others): 1. Call drv_change_vif_links() with both old_active and new_active 2. Unassign the chanctx for the removed link(s) (if any) 3. Assign chanctx to the added link(s) (if any) 4. Call drv_change_vif_links() with the new_active links bitmap The problem here is that during step #1 the driver doesn't know whether we will activate multiple links simultaneously or are just doing a link switch, so it can't check there if multiple links are supported/enabled. (Some of the drivers might enable/disable this option dynamically) And during step #3, in which the driver already knows that, returning an error code (for example when multiple links are not supported or disabled), will cause a warning, and we will still complete the transition to the new_active links. (It is hard to undo things in that stage, since we released channels etc.) Therefore add a driver callback to check if the desired new_active links will be supported by the driver or not. This callback will be called in the beginning of ieee80211_set_active_links() so we won't do anything before we are sure it is supported. Signed-off-by:
-
Ayala Beker authored
Handle a case of time overflow, where the switch time might be smaller than the partial TSF in the beacon. Additionally, apply advertised TTLM earlier in order to be ready on time on the newly activated links. Fixes: 702e8047 ("wifi: mac80211: support handling of advertised TID-to-link mapping") Signed-off-by:
Ayala Beker <ayala.beker@intel.com> Reviewed-by:
-
Benjamin Berg authored
cfg80211_update_known_bss will always consume the passed IEs. As such, cfg80211_update_assoc_bss_entry also needs to always set the pointers to NULL so that no double free can occur. Note that hitting this would probably require being connected to a hidden BSS which is then doing a channel switch while also switching to be not hidden anymore at the same time. Signed-off-by:
-
Benjamin Berg authored
cfg80211_bss_update is expected to consume the IEs that are passed into it in the temporary internal BSS. This did not happen in some error cases (which are also WARN_ON paths), so change the code to use a common label and use that everywhere. Signed-off-by:
-
Benjamin Berg authored
This is a more of a cosmetic fix. The branch will only be taken if proberesp_ies is set, which implies that beacon_ies is not set unless we are connected to an AP that just did a channel switch. And, in that case we should have found the BSS in the internal storage to begin with. Signed-off-by:
-
Johannes Berg authored
When reporting the radiotap timestamp, the mactime field is usually unused, we take the data from the device_timestamp. However, there can be cases where the radiotap timestamp is better reported as a 64-bit value, so since the mactime is free, add a flag to support using the mactime as a 64-bit radiotap timestamp. Signed-off-by:
-
Johannes Berg authored
We only have a single flag free, and before using that for another mactime flag, instead refactor the mactime flags to use a 2-bit field. Signed-off-by:
-
Mukesh Sisodiya authored
UHB AP send supported power type(LPI, SP, VLP) in beacon and probe response IE and STA should connect to these AP only if their regulatory support the AP power type. Beacon/Probe response are reported to userspace with reason "STA regulatory not supporting to connect to AP based on transmitted power type" and it should not connect to AP. Signed-off-by:
-
Andrei Otcheretianski authored
Add custom regulatory that marks DFS channels as DFS_CONCURRENT. Signed-off-by:
-
Andrei Otcheretianski authored
Some devices may support concurrent DFS operation which relies on the BSS channel width for its relaxations. Notify cfg80211 about BW change so it can schedule regulatory checks. Signed-off-by:
-
Andrei Otcheretianski authored
Due to different relaxation policies it may be needed to re-check channels after a BSS station interface is disconnected or performed a channel switch. Signed-off-by:
-
Andrei Otcheretianski authored
FCC-594280 D01 Section B.3 allows peer-to-peer and ad hoc devices to operate on DFS channels while they operate under the control of a concurrent DFS master. For example, it is possible to have a P2P GO on a DFS channel as long as BSS connection is active on the same channel. Allow such operation by adding additional regulatory flags to indicate DFS concurrent channels and capable devices. Add the required relaxations in DFS regulatory checks. Signed-off-by:
-
Jouni Malinen authored
It is possible for the TX status report for the (Re)Association Request frame to be delayed long enough for the AP's (Re)Association Response frame to be received and processed before it. If that were to happen for a case where the AP rejects the association with indication to come back later, the association timeout and retry state should not be modified anymore with the TX status information that would be processed after this. Updating the association timeout in such a reverse order of events could result in shortening the timeouts for the association comeback mechanism and that could result in the association failing. Track whether we have already processed association rejection with comeback time and if so, skip the timeout and retry update on any following TX status report. Signed-off-by:
Jouni Malinen <quic_jouni@quicinc.com> Link: https://msgid.link/20231219174814.2581575-1-j@w1.fiSigned-off-by:
-
Jonathan Corbet authored
include/net/mac80111.h contains a number of either excess or incorrect kerneldoc entries for structure members, leading to these warnings: ./include/net/mac80211.h:491: warning: Excess struct member 'rssi' description in 'ieee80211_event' ./include/net/mac80211.h:491: warning: Excess struct member 'mlme' description in 'ieee80211_event' ./include/net/mac80211.h:491: warning: Excess struct member 'ba' description in 'ieee80211_event' ./include/net/mac80211.h:777: warning: Excess struct member 'ack_enabled' description in 'ieee80211_bss_conf' ./include/net/mac80211.h:1222: warning: Excess struct member 'ampdu_ack_len' description in 'ieee80211_tx_info' ./include/net/mac80211.h:1222: warning: Excess struct member 'ampdu_len' description in 'ieee80211_tx_info' ./include/net/mac80211.h:1222: warning: Excess struct member 'ack_signal' description in 'ieee80211_tx_info' ./include/net/mac80211.h:2920: warning: Excess struct member 'radiotap_he' description in 'ieee80211_hw' Fix or remove the entries as needed. This change removes 208 warnings from a "make htmldocs" build. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://msgid.link/87zfy4bhxo.fsf@meer.lwn.netSigned-off-by:
-
Miri Korenblit authored
We are missing the flag that indicates that capability of 40 MHz bandwidth support in HE on the LB. Add it. Signed-off-by:
-
Jonathan Corbet authored
include/net/cfg80211.h includes a number of kerneldoc entries for struct members that do not exist, leading to these warnings: ./include/net/cfg80211.h:3192: warning: Excess struct member 'band_pref' description in 'cfg80211_bss_selection' ./include/net/cfg80211.h:3192: warning: Excess struct member 'adjust' description in 'cfg80211_bss_selection' ./include/net/cfg80211.h:6181: warning: Excess struct member 'bssid' description in 'wireless_dev' ./include/net/cfg80211.h:6181: warning: Excess struct member 'beacon_interval' description in 'wireless_dev' ./include/net/cfg80211.h:7299: warning: Excess struct member 'bss' description in 'cfg80211_rx_assoc_resp_data' Remove and/or repair each entry to address the warnings and ensure a proper docs build for the affected structures. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://msgid.link/87plz1g2sc.fsf@meer.lwn.netSigned-off-by:
-
