summaryrefslogtreecommitdiff
path: root/net/mac80211
AgeCommit message (Collapse)AuthorFilesLines
2023-10-06Merge wireless into wireless-nextJohannes Berg9-28/+85
Resolve several conflicts, mostly between changes/fixes in wireless and the locking rework in wireless-next. One of the conflicts actually shows a bug in wireless that we'll want to fix separately. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org>
2023-09-30wifi: mac80211: add back SPDX identifierJohannes Berg1-0/+1
Looks like I lost that by accident, add it back. Fixes: 076fc8775daf ("wifi: cfg80211: remove wdev mutex") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-30wifi: mac80211: fix ieee80211_drop_unencrypted_mgmt return type/valueJohannes Berg1-2/+3
Somehow, I managed to botch this and pretty much completely break wifi. My original patch did contain these changes, but I seem to have lost them before sending to the list. Fix it now. Reported-and-tested-by: Kalle Valo <kvalo@kernel.org> Fixes: 6c02fab72429 ("wifi: mac80211: split ieee80211_drop_unencrypted_mgmt() return value") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-26wifi: mac80211: expand __ieee80211_data_to_8023() statusJohannes Berg2-12/+14
Make __ieee80211_data_to_8023() return more individual drop reasons instead of just doing RX_DROP_U_INVALID_8023. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-26wifi: mac80211: split ieee80211_drop_unencrypted_mgmt() return valueJohannes Berg2-12/+18
This has many different reasons, split the return value into the individual reasons for better traceability. Also, since symbolic tracing doesn't work for these, add a few comments for the numbering. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-26wifi: mac80211: remove RX_DROP_UNUSABLEJohannes Berg4-52/+84
Convert all instances of RX_DROP_UNUSABLE to indicate a better reason, and then remove RX_DROP_UNUSABLE. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-26wifi: mac80211: fix check for unusable RX resultJohannes Berg2-1/+4
If we just check "result & RX_DROP_UNUSABLE", this really only works by accident, because SKB_DROP_REASON_SUBSYS_MAC80211_UNUSABLE got to have the value 1, and SKB_DROP_REASON_SUBSYS_MAC80211_MONITOR is 2. Fix this to really check the entire subsys mask for the value, so it doesn't matter what the subsystem value is. Fixes: 7f4e09700bdc ("wifi: mac80211: report all unusable beacon frames") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-26wifi: mac80211: Create resources for disabled linksBenjamin Berg1-3/+4
When associating to an MLD AP, links may be disabled. Create all resources associated with a disabled link so that we can later enable it without having to create these resources on the fly. Fixes: 6d543b34dbcf ("wifi: mac80211: Support disabled links during association") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://lore.kernel.org/r/20230925173028.f9afdb26f6c7.I4e6e199aaefc1bf017362d64f3869645fa6830b5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: allow transmitting EAPOL frames with tainted keyWen Gong1-1/+2
Lower layer device driver stop/wake TX by calling ieee80211_stop_queue()/ ieee80211_wake_queue() while hw scan. Sometimes hw scan and PTK rekey are running in parallel, when M4 sent from wpa_supplicant arrive while the TX queue is stopped, then the M4 will pending send, and then new key install from wpa_supplicant. After TX queue wake up by lower layer device driver, the M4 will be dropped by below call stack. When key install started, the current key flag is set KEY_FLAG_TAINTED in ieee80211_pairwise_rekey(), and then mac80211 wait key install complete by lower layer device driver. Meanwhile ieee80211_tx_h_select_key() will return TX_DROP for the M4 in step 12 below, and then ieee80211_free_txskb() called by ieee80211_tx_dequeue(), so the M4 will not send and free, then the rekey process failed becaue AP not receive M4. Please see details in steps below. There are a interval between KEY_FLAG_TAINTED set for current key flag and install key complete by lower layer device driver, the KEY_FLAG_TAINTED is set in this interval, all packet including M4 will be dropped in this interval, the interval is step 8~13 as below. issue steps: TX thread install key thread 1. stop_queue -idle- 2. sending M4 -idle- 3. M4 pending -idle- 4. -idle- starting install key from wpa_supplicant 5. -idle- =>ieee80211_key_replace() 6. -idle- =>ieee80211_pairwise_rekey() and set currently key->flags |= KEY_FLAG_TAINTED 7. -idle- =>ieee80211_key_enable_hw_accel() 8. -idle- =>drv_set_key() and waiting key install complete from lower layer device driver 9. wake_queue -waiting state- 10. re-sending M4 -waiting state- 11. =>ieee80211_tx_h_select_key() -waiting state- 12. drop M4 by KEY_FLAG_TAINTED -waiting state- 13. -idle- install key complete with success/fail success: clear flag KEY_FLAG_TAINTED fail: start disconnect Hence add check in step 11 above to allow the EAPOL send out in the interval. If lower layer device driver use the old key/cipher to encrypt the M4, then AP received/decrypt M4 correctly, after M4 send out, lower layer device driver install the new key/cipher to hardware and return success. If lower layer device driver use new key/cipher to send the M4, then AP will/should drop the M4, then it is same result with this issue, AP will/ should kick out station as well as this issue. issue log: kworker/u16:4-5238 [000] 6456.108926: stop_queue: phy1 queue:0, reason:0 wpa_supplicant-961 [003] 6456.119737: rdev_tx_control_port: wiphy_name=phy1 name=wlan0 ifindex=6 dest=ARRAY[9e, 05, 31, 20, 9b, d0] proto=36488 unencrypted=0 wpa_supplicant-961 [003] 6456.119839: rdev_return_int_cookie: phy1, returned 0, cookie: 504 wpa_supplicant-961 [003] 6456.120287: rdev_add_key: phy1, netdev:wlan0(6), key_index: 0, mode: 0, pairwise: true, mac addr: 9e:05:31:20:9b:d0 wpa_supplicant-961 [003] 6456.120453: drv_set_key: phy1 vif:wlan0(2) sta:9e:05:31:20:9b:d0 cipher:0xfac04, flags=0x9, keyidx=0, hw_key_idx=0 kworker/u16:9-3829 [001] 6456.168240: wake_queue: phy1 queue:0, reason:0 kworker/u16:9-3829 [001] 6456.168255: drv_wake_tx_queue: phy1 vif:wlan0(2) sta:9e:05:31:20:9b:d0 ac:0 tid:7 kworker/u16:9-3829 [001] 6456.168305: cfg80211_control_port_tx_status: wdev(1), cookie: 504, ack: false wpa_supplicant-961 [003] 6459.167982: drv_return_int: phy1 - -110 issue call stack: nl80211_frame_tx_status+0x230/0x340 [cfg80211] cfg80211_control_port_tx_status+0x1c/0x28 [cfg80211] ieee80211_report_used_skb+0x374/0x3e8 [mac80211] ieee80211_free_txskb+0x24/0x40 [mac80211] ieee80211_tx_dequeue+0x644/0x954 [mac80211] ath10k_mac_tx_push_txq+0xac/0x238 [ath10k_core] ath10k_mac_op_wake_tx_queue+0xac/0xe0 [ath10k_core] drv_wake_tx_queue+0x80/0x168 [mac80211] __ieee80211_wake_txqs+0xe8/0x1c8 [mac80211] _ieee80211_wake_txqs+0xb4/0x120 [mac80211] ieee80211_wake_txqs+0x48/0x80 [mac80211] tasklet_action_common+0xa8/0x254 tasklet_action+0x2c/0x38 __do_softirq+0xdc/0x384 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Link: https://lore.kernel.org/r/20230801064751.25803-1-quic_wgong@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: reject MLO channel configuration if not supportedBenjamin Berg1-3/+13
Reject configuring a channel for MLO if either EHT is not supported or the BSS does not have the correct ML element. This avoids trying to do a multi-link association with a misconfigured AP. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.80c3b8e5a344.Iaa2d466ee6280994537e1ae7ab9256a27934806f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: report per-link error during associationBenjamin Berg1-1/+3
With this cfg80211 can report the link that caused the error to userspace which is then able to react to it by e.g. removing the link from the association and retrying. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.275fc7f5c426.I8086c0fdbbf92537d6a8b8e80b33387fcfd5553d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: support antenna control in injectionJohannes Berg1-0/+14
Support antenna control for injection by parsing the antenna radiotap field (which may be presented multiple times) and telling the driver about the resulting antenna bitmap. Of course there's no guarantee the driver will actually honour this, just like any other injection control. If misconfigured, i.e. the injected HT/VHT MCS needs more chains than antennas are configured, the bitmap is reset to zero, indicating no selection. For now this is only set up for two anntenas so we keep more free bits, but that can be trivially extended if any driver implements support for it that can deal with hardware with more antennas. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.f71001aa4da9.I00ccb762a806ea62bc3d728fa3a0d29f4f285eeb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: support handling of advertised TID-to-link mappingAyala Beker2-0/+211
Support handling of advertised TID-to-link mapping elements received in a beacon. These elements are used by AP MLD to disable specific links and force all clients to stop using these links. By default if no TID-to-link mapping is advertised, all TIDs shall be mapped to all links. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.623c4b692ff9.Iab0a6f561d85b8ab6efe541590985a2b6e9e74aa@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: add support for parsing TID to Link mapping elementAyala Beker2-0/+11
Add the relevant definitions for TID to Link mapping element according to the P802.11be_D4.0. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.9ea9b0b4412a.I2281ab2c70e8b43a39032dc115db6a80f1f0b3f4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: Notify the low level driver on change in MLO valid linksIlan Peer2-1/+4
Notify the low level driver when there is change in the valid links. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.4fc85b0a51b0.I64238e0e892709a2bd4764b3bca93cdcf021e2fd@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: describe return values in kernel-docJohannes Berg2-0/+4
Add descriptions for two return values for two functions that are missing them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.79307c341723.Ibae386f0354f2e215d4955752ac378acc2466b51@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: don't connect to an AP while it's in a CSA processAyala Beker1-1/+33
Connection to an AP that is running a CSA flow may end up with a failure as the AP might change its channel during the connection flow while we do not track the channel change yet. Avoid that by rejecting a connection to such an AP. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.e5001a762a4a.I9745c695f3403b259ad000ce94110588a836c04a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: update the rx_chains after set_antenna()Emmanuel Grumbach1-1/+7
rx_chains was set only upon registration and it we rely on it for the active chains upon SMPS configuration after association. When we use the set_antenna() API to limit the rx_chains from 2 to 1, this caused issues with iwlwifi since we still had 2 active_chains requested. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.2dde4da246b2.I904223c868c77cf2ba132a3088fe6506fcbb443b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: use bandwidth indication element for CSAJohannes Berg4-18/+45
In CSA, parse the (EHT) bandwidth indication element and use it (in fact prefer it if present). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230920211508.43ef01920556.If4f24a61cd634ab1e50eba43899b9e992bf25602@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: cfg80211: split struct cfg80211_ap_settingsJohannes Berg1-1/+1
Using the full struct cfg80211_ap_settings for an update is misleading, since most settings cannot be updated. Split the update case off into a new struct cfg80211_ap_update. Change-Id: I3ba4dd9280938ab41252f145227a7005edf327e4 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: ethtool: always hold wiphy mutexJohannes Berg1-1/+8
Drivers should really be able to rely on the wiphy mutex being held all the time, unless otherwise documented. For ethtool, that wasn't quite right. Fix and clarify this in both code and documentation. Reported-by: syzbot+c12a771b218dcbba32e1@syzkaller.appspotmail.com Fixes: 0e8185ce1dde ("wifi: mac80211: check wiphy mutex in ops") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: work around Cisco AP 9115 VHT MPDU lengthJohannes Berg6-7/+44
Cisco AP module 9115 with FW 17.3 has a bug and sends a too large maximum MPDU length in the association response (indicating 12k) that it cannot actually process. Work around that by taking the minimum between what's in the association response and the BSS elements (from beacon or probe response). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230918140607.d1966a9a532e.I090225babb7cd4d1081ee9acd40e7de7e41c15ae@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: cfg80211: make read-only array centers_80mhz static constColin Ian King1-1/+1
Don't populate the read-only array lanes on the stack, instead make it static const. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20230919095205.24949-1-colin.i.king@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: fix potential key leakJohannes Berg1-5/+15
When returning from ieee80211_key_link(), the key needs to have been freed or successfully installed. This was missed in a number of error paths, fix it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-25wifi: mac80211: fix potential key use-after-freeJohannes Berg2-1/+4
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add(). Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-13wifi: mac80211: don't return unset power in ieee80211_get_tx_power()Ping-Ke Shih1-0/+4
We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level". UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] In this case, simply return an error instead, to indicate that no data is available. Cc: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://lore.kernel.org/r/20230203023636.4418-1-pkshih@realtek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-13wifi: mac80211: Sanity check tx bitrate if not provided by driverStephen Douthit2-2/+3
If the driver doesn't fill NL80211_STA_INFO_TX_BITRATE in sta_set_sinfo() then as a fallback sta->deflink.tx_stats.last_rate is used. Unfortunately there's no guarantee that this has actually been set before it's used. Originally found when 'iw <dev> link' would always return a tx rate of 6Mbps regardless of actual link speed for the QCA9337 running firmware WLAN.TF.2.1-00021-QCARMSWP-1 in my netbook. Use the sanity check logic from ieee80211_fill_rx_status() and refactor that to use the new inline function. Signed-off-by: Stephen Douthit <stephen.douthit@gmail.com> Link: https://lore.kernel.org/r/20230213204024.3377-1-stephen.douthit@gmail.com [change to bool ..._rate_valid() instead of int ..._rate_invalid()] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-13wifi: mac80211: additions to change_beacon()Aloka Dixit1-0/+13
Process FILS discovery and unsolicited broadcast probe response transmission configurations in ieee80211_change_beacon(). Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230727174100.11721-6-quic_alokad@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-13wifi: cfg80211: modify prototype for change_beaconAloka Dixit1-6/+8
Modify the prototype for change_beacon() in struct cfg80211_op to accept cfg80211_ap_settings instead of cfg80211_beacon_data so that it can process data in addition to beacons. Modify the prototypes of ieee80211_change_beacon() and driver specific functions accordingly. Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230727174100.11721-4-quic_alokad@quicinc.com [while at it, remove pointless "if (info)" check in tracing that just makes all the lines longer than they need be - it's never NULL] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-13wifi: mac80211: fixes in FILS discovery updatesAloka Dixit1-37/+40
FILS discovery configuration gets updated only if the maximum interval is set to a non-zero value, hence there is no way to reset this value to 0 once set. Replace the check for interval with a new flag which is set only if the configuration should be updated. Add similar changes for the unsolicited broadcast probe response handling. Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230727174100.11721-3-quic_alokad@quicinc.com [move NULL'ing to else branch to not have intermediate NULL visible] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-13wifi: mac80211: remove shifted rate supportJohannes Berg9-151/+53
We really cannot even get into this as we can't have a BSS with a 5/10 MHz (scan) width, and therefore all the code handling shifted rates cannot happen. Remove it all, since it's broken anyway, at least with MLO. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-13wifi: cfg80211: remove scan_width supportJohannes Berg4-86/+23
There really isn't any support for scanning at different channel widths than 20 MHz since there's no way to set it. Remove this support for now, if somebody wants to maintain this whole thing later we can revisit how it should work. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-13wifi: mac80211: fix mesh id corruption on 32 bit systemsFelix Fietkau2-5/+5
Since the changed field size was increased to u64, mesh_bss_info_changed pulls invalid bits from the first 3 bytes of the mesh id, clears them, and passes them on to ieee80211_link_info_change_notify, because ifmsh->mbss_changed was not updated to match its size. Fix this by turning into ifmsh->mbss_changed into an unsigned long array with 64 bit size. Fixes: 15ddba5f4311 ("wifi: mac80211: consistently use u64 for BSS changes") Reported-by: Thomas Hühn <thomas.huehn@hs-nordhausen.de> Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230913050134.53536-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: fix channel switch link dataJohannes Berg2-5/+7
Use the correct link ID and per-link puncturing data instead of hardcoding link ID 0 and using deflink puncturing. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.0b6a211c8e75.I5724d32bb2dae440888efbc47334d8c115db9d50@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: Do not force off-channel for management Tx with MLOIlan Peer1-1/+6
When user space transmits a management frame it is expected to use the MLD addresses if the connection is an MLD one. Thus, in case the management Tx is using the MLD address and no channel is configured off-channel should not be used (as one of the active links would be used). Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.73c8efce252f.Ie4b0a842debb24ef25c5e6cb2ad69b9f46bc4b2a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: take MBSSID/EHT data also from probe respJohannes Berg1-10/+15
The code that sets up the assoc link will currently take the BSS element data from the beacon only. This is correct for some of the data, notably the timing and the "have_beacon", but all the data about MBSSID and EHT really doesn't need to be taken from there, and if the EHT puncturing is misconfigured on the AP but we didn't receive a beacon yet, this causes us to connect but immediately disconnect upon receiving the first beacon, rather than connecting without EHT in the first place. Change the code to take MBSSID and EHT data also from the probe response, for a better picture of what the BSS capabilities are and to avoid that EHT puncturing problem. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.3c7e52d49482.Iba6b672f6dc74b45bba26bc497e953e27da43ef9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: Print local link address during authenticationIlan Peer1-2/+14
To ease debugging, mostly in cases that authentication fails. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.9c08605e2691.I0032e9d6e01325862189e4a20b02ddbe8f2f5e75@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: fix # of MSDU in A-MSDU calculationJohannes Berg1-1/+1
During my refactoring I wanted to get rid of the switch, but replaced it with the wrong calculation. Fix that. Fixes: 175ad2ec89fe ("wifi: mac80211: limit A-MSDU subframes for client too") Reported-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.51bf1b8b0adb.Iffbd337fdad2b86ae12f5a39c69fb82b517f7486@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: fix various kernel-doc issuesJohannes Berg2-10/+12
There are various kernel-doc issues here, fix them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.7ce9761f9ebb.I0f44e76c518f72135cc855c809bfa7a5e977b894@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: remove unnecessary struct forward declarationJohannes Berg1-1/+0
This just causes kernel-doc to complain at this spot, but isn't actually needed anyway, so remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.33a5591dfdeb.If4e7e1a1cb4c04f0afd83db7401c780404dca699@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: add more warnings about inserting sta infoBenjamin Berg1-2/+6
The sta info needs to be inserted before its links may be modified. Add a few warnings to prevent accidental usage of these functions. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.eeb43b3cc9e3.I5fd8236f70e64bf6268f33c883f7a878d963b83e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: cfg80211: add ieee80211_fragment_element to public APIBenjamin Berg2-31/+0
This function will be used by the kunit tests within cfg80211. As it is generally useful, move it from mac80211 to cfg80211. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.5af9391659f5.Ie534ed6591ba02be8572d4d7242394f29e3af04b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: add an element parsing unit testJohannes Berg6-0/+130
Add a unit test for the parsing of a fragmented sta profile sub-element inside a fragmented multi-link element. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.333bc75df13f.I0ddfeb6a88a4d89e7c7850e8ef45a4b19b5a061a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: add support for mld in ieee80211_chswitch_doneEmmanuel Grumbach4-31/+48
This allows to finalize the CSA per link. In case the switch didn't work, tear down the MLD connection. Also pass the ieee80211_bss_conf to post_channel_switch to let the driver know which link completed the switch. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230828130311.3d3eacc88436.Ic2d14e2285aa1646216a56806cfd4a8d0054437c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: cfg80211/mac80211: hold link BSSes when assoc fails for MLO connectionWen Gong1-5/+6
When connect to MLO AP with more than one link, and the assoc response of AP is not success, then cfg80211_unhold_bss() is not called for all the links' cfg80211_bss except the primary link which means the link used by the latest successful association request. Thus the hold value of the cfg80211_bss is not reset to 0 after the assoc fail, and then the __cfg80211_unlink_bss() will not be called for the cfg80211_bss by __cfg80211_bss_expire(). Then the AP always looks exist even the AP is shutdown or reconfigured to another type, then it will lead error while connecting it again. The detail info are as below. When connect with muti-links AP, cfg80211_hold_bss() is called by cfg80211_mlme_assoc() for each cfg80211_bss of all the links. When assoc response from AP is not success(such as status_code==1), the ieee80211_link_data of non-primary link(sdata->link[link_id]) is NULL because ieee80211_assoc_success()->ieee80211_vif_update_links() is not called for the links. Then struct cfg80211_rx_assoc_resp resp in cfg80211_rx_assoc_resp() and struct cfg80211_connect_resp_params cr in __cfg80211_connect_result() will only have the data of the primary link, and finally function cfg80211_connect_result_release_bsses() only call cfg80211_unhold_bss() for the primary link. Then cfg80211_bss of the other links will never free because its hold is always > 0 now. Hence assign value for the bss and status from assoc_data since it is valid for this case. Also assign value of addr from assoc_data when the link is NULL because the addrs of assoc_data and link both represent the local link addr and they are same value for success connection. Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link") Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Link: https://lore.kernel.org/r/20230825070055.28164-1-quic_wgong@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: fix RCU usage warning in mesh fast-xmitJohannes Berg1-1/+1
In mesh_fast_tx_flush_addr() we already hold the lock, so don't need additional hashtable RCU protection. Use the rhashtable_lookup_fast() variant to avoid RCU protection warnings. Fixes: d5edb9ae8d56 ("wifi: mac80211: mesh fast xmit support") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: cfg80211: annotate iftype_data pointer with sparseJohannes Berg1-5/+2
There were are a number of cases in mac80211 and iwlwifi (at least) that used the sband->iftype_data pointer directly, instead of using the accessors to find the right array entry to use. Make sparse warn when such a thing is done. To not have a lot of casts, add two helper functions/macros - ieee80211_set_sband_iftype_data() - for_each_sband_iftype_data() Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: fix BA session teardown raceJohannes Berg3-8/+15
As previously reported by Alexander, whose commit 69403bad97aa ("wifi: mac80211: sdata can be NULL during AMPDU start") I'm reverting as part of this commit, there's a race between station destruction and aggregation setup, where the aggregation setup can happen while the station is being removed and queue the work after ieee80211_sta_tear_down_BA_sessions() has already run in __sta_info_destroy_part1(), and thus the worker will run with a now freed station. In his case, this manifested in a NULL sdata pointer, but really there's no guarantee whatsoever. The real issue seems to be that it's possible at all to have a situation where this occurs - we want to stop the BA sessions when doing _part1, but we cannot be sure, and WLAN_STA_BLOCK_BA isn't necessarily effective since we don't know that the setup isn't concurrently running and already got past the check. Simply call ieee80211_sta_tear_down_BA_sessions() again in the second part of station destruction, since at that point really nothing else can hold a reference to the station any more. Also revert the sdata checks since those are just misleading at this point. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: mac80211: fix TXQ error path and cleanupJohannes Berg2-2/+3
We currently call ieee80211_txq_teardown_flows() as part of ieee80211_remove_interfaces(), but that's not really right in case of HW registration failures, specifically rate control. Call it separately to fix that issue. Reported-by: Zhengchao Shao <shaozhengchao@huawei.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-09-11wifi: cfg80211: remove wdev mutexJohannes Berg15-282/+86
Since we're now protecting everything with the wiphy mutex (and were really using it for almost everything before), there's no longer any real reason to have a separate wdev mutex. It may feel better, but really has no value. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-27 14:28:40 +0300