summaryrefslogtreecommitdiffstats
path: root/net/mac80211
Commit message (Collapse)AuthorAgeFilesLines
* cfg80211/mac80211: ignore signal if the frame was heard on wrong channelEmmanuel Grumbach2014-03-192-20/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On 2.4Ghz band, the channels overlap since the delta between different channels is 5Mhz while the width of the receiver is 20Mhz (at least). This means that we can hear beacons or probe responses from adjacent channels. These frames will have a significant lower RSSI which will feed all kinds of logic with inaccurate data. An obvious example is the roaming algorithm that will think our AP is getting weak and will try to move to another AP. In order to avoid this, update the signal only if the frame has been heard on the same channel as the one advertised by the AP in its DS / HT IEs. We refrain from updating the values only if the AP is already in the BSS list so that we will still have a valid (but inaccurate) value if the AP was heard on an adjacent channel only. To achieve this, stop taking the channel from DS / HT IEs in mac80211. The DS / HT IEs is taken into account to discard the frame if it was received on a disabled channel. This can happen due to the same phenomenon: the frame is sent on channel 12, but heard on channel 11 while channel 12 can be disabled on certain devices. Since this check is done in cfg80211, stop even checking this in mac80211. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [remove unused rx_freq variable] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: release sched_scan_sdata when stopping sched scanAlexander Bondar2014-03-191-2/+4
| | | | | | | | | | | Assuming sched_scan_stop operation is synchronous the driver may not necessary call ieee80211_sched_scan_stopped_work. Since this work is the only place where sched_scan_sdata is released we can possibly run into situation when it is never released. Fix this by releasing it just after calling drv_sched_scan_stop. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix WPA with VLAN on AP side with ps-sta againMichael Braun2014-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | commit de74a1d9032f4d37ea453ad2a647e1aff4cd2591 "mac80211: fix WPA with VLAN on AP side with ps-sta" fixed an issue where queued multicast packets would be sent out encrypted with the key of an other bss. commit "7cbf9d017dbb5e3276de7d527925d42d4c11e732" "mac80211: fix oops on mesh PS broadcast forwarding" essentially reverted it, because vif.type cannot be AP_VLAN due to the check to vif.type in ieee80211_get_buffered_bc before. As the later commit intended to fix the MESH case, fix it by checking for IFTYPE_AP instead of IFTYPE_AP_VLAN. Cc: stable@vger.kernel.org Fixes: 7cbf9d017dbb ("mac80211: fix oops on mesh PS broadcast forwarding") Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix suspend vs. authentication raceJohannes Berg2014-03-193-3/+38
| | | | | | | | | | | | | | | Since Stanislaw's patch removing the quiescing code, mac80211 had a race regarding suspend vs. authentication: as cfg80211 doesn't track authentication attempts, it can't abort them. Therefore the attempts may be kept running while suspending, which can lead to all kinds of issues, in at least some cases causing an error in iwlmvm firmware. Fix this by aborting the authentication attempt when suspending. Cc: stable@vger.kernel.org Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: verify deauthentication and return error on failureJohannes Berg2014-03-191-13/+17
| | | | | | | | | | | | | | | When still authenticating the mac80211 code handling a deauthentication requests from userspace doesn't verify that the request is valid in any way, fix that. Additionally, it never returns an error, even if there's no connection or authentication attempt, fix that as well. While at it, move the message to not print a message in the error case and to distinguish between the two cases. Also simplify the code by duplicating the cfg80211 call. Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix potential use-after-freeJohannes Berg2014-03-191-1/+1
| | | | | | | | | The bss struct might be freed in ieee80211_rx_bss_put(), so we shouldn't use it afterwards. Cc: stable@vger.kernel.org (3.10+) Fixes: 817cee7675237 ("mac80211: track AP's beacon rate and give it to the driver") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add missing update on rx status VHT flagChun-Yeow Yeoh2014-03-031-0/+1
| | | | | | | | | | Add missing update on the rx status vht flag of the last data packet. Otherwise, cfg80211_calculate_bitrate_vht may not consider the channel width resulting in wrong calculation of the received bitrate. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: refactor channel switch functionMichal Kazior2014-03-031-50/+63
| | | | | | | | | The function was quite big. This splits out beacon updating into a separate function for improved maintenance and extension. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: DFS get CAC time from regulatory databaseJanusz Dziedzic2014-02-251-4/+4
| | | | | | | | | Send Channel Availability Check time as a parameter of start_radar_detection() callback. Get CAC time from regulatory database. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: ibss: handle cfg80211_chandef_dfs_required() error codesLuciano Coelho2014-02-211-0/+5
| | | | | | | | | Error codes returned by cfg80211_chandef_dfs_required() are ignored when trying to join an IBSS. Fix this by printing an error and returning. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow drivers to request SMPS offLuciano Coelho2014-02-211-2/+0
| | | | | | | | | Previously we were warning and using automatic when a driver sent an update request with SMPS off. This patch makes it possible for drivers to disable SMPS at runtime, for whatever reason. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow driver to return error from sched_scan_stopJohannes Berg2014-02-202-5/+9
| | | | | | | | | In order to solve races with sched_scan_stop, it is necessary for the driver to be able to return an error to propagate that to cfg80211 so it doesn't send an event. Reviewed-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: Pass TDLS peer capability information in tdls_mgmtSunil Dutt Undekari2014-02-201-2/+2
| | | | | | | | | | | | | | | | While framing the TDLS Setup Confirmation frame, the driver needs to know if the TDLS peer is VHT/HT/WMM capable and thus shall construct the VHT/HT operation / WMM parameter elements accordingly. Supplicant determines if the TDLS peer is VHT/HT/WMM capable based on the presence of the respective IEs in the received TDLS Setup Response frame. The host driver should not need to parse the received TDLS Response frame and thus, should be able to rely on the supplicant to indicate the capability of the peer through additional flags while transmitting the TDLS Setup Confirmation frame through tdls_mgmt operations. Signed-off-by: Sunil Dutt Undekari <usdutt@qti.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge remote-tracking branch 'wireless-next/master' into mac80211-nextJohannes Berg2014-02-205-35/+47
|\
| * Merge branch 'master' of ↵John W. Linville2014-02-135-35/+47
| |\ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
| | * mac80211: fix virtual monitor interface iterationJohannes Berg2014-02-061-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During channel context assignment, the interface should be found by interface iteration, so we need to assign the pointer before the channel context. Reported-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Tested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | * mac80211: fix fragmentation code, particularly for encryptionJohannes Berg2014-02-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "new" fragmentation code (since my rewrite almost 5 years ago) erroneously sets skb->len rather than using skb_trim() to adjust the length of the first fragment after copying out all the others. This leaves the skb tail pointer pointing to after where the data originally ended, and thus causes the encryption MIC to be written at that point, rather than where it belongs: immediately after the data. The impact of this is that if software encryption is done, then a) encryption doesn't work for the first fragment, the connection becomes unusable as the first fragment will never be properly verified at the receiver, the MIC is practically guaranteed to be wrong b) we leak up to 8 bytes of plaintext (!) of the packet out into the air This is only mitigated by the fact that many devices are capable of doing encryption in hardware, in which case this can't happen as the tail pointer is irrelevant in that case. Additionally, fragmentation is not used very frequently and would normally have to be configured manually. Fix this by using skb_trim() properly. Cc: stable@vger.kernel.org Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation") Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | * mac80211: Fix IBSS disconnectSujith Manoharan2014-02-061-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when a station leaves an IBSS network, the corresponding BSS is not dropped from cfg80211 if there are other active stations in the network. But, the small window that is present when trying to determine a station's status based on IEEE80211_IBSS_MERGE_INTERVAL introduces a race. Instead of trying to keep the BSS, always remove it when leaving an IBSS network. There is not much benefit to retain the BSS entry since it will be added with a subsequent join operation. This fixes an issue where a dangling BSS entry causes ath9k to wait for a beacon indefinitely. Cc: <stable@vger.kernel.org> Reported-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | * mac80211: release the channel in error path in start_apEmmanuel Grumbach2014-02-061-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | When the driver cannot start the AP or when the assignement of the beacon goes wrong, we need to unassign the vif. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | * mac80211: avoid deadlock revealed by lockdepEmmanuel Grumbach2014-02-063-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sdata->u.ap.request_smps_work can’t be flushed synchronously under wdev_lock(wdev) since ieee80211_request_smps_ap_work itself locks the same lock. While at it, reset the driver_smps_mode when the ap is stopped to its default: OFF. This solves: ====================================================== [ INFO: possible circular locking dependency detected ] 3.12.0-ipeer+ #2 Tainted: G O ------------------------------------------------------- rmmod/2867 is trying to acquire lock: ((&sdata->u.ap.request_smps_work)){+.+...}, at: [<c105b8d0>] flush_work+0x0/0x90 but task is already holding lock: (&wdev->mtx){+.+.+.}, at: [<f9b32626>] cfg80211_stop_ap+0x26/0x230 [cfg80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&wdev->mtx){+.+.+.}: [<c10aefa9>] lock_acquire+0x79/0xe0 [<c1607a1a>] mutex_lock_nested+0x4a/0x360 [<fb06288b>] ieee80211_request_smps_ap_work+0x2b/0x50 [mac80211] [<c105cdd8>] process_one_work+0x198/0x450 [<c105d469>] worker_thread+0xf9/0x320 [<c10669ff>] kthread+0x9f/0xb0 [<c1613397>] ret_from_kernel_thread+0x1b/0x28 -> #0 ((&sdata->u.ap.request_smps_work)){+.+...}: [<c10ae9df>] __lock_acquire+0x183f/0x1910 [<c10aefa9>] lock_acquire+0x79/0xe0 [<c105b917>] flush_work+0x47/0x90 [<c105d867>] __cancel_work_timer+0x67/0xe0 [<c105d90f>] cancel_work_sync+0xf/0x20 [<fb0765cc>] ieee80211_stop_ap+0x8c/0x340 [mac80211] [<f9b3268c>] cfg80211_stop_ap+0x8c/0x230 [cfg80211] [<f9b0d8f9>] cfg80211_leave+0x79/0x100 [cfg80211] [<f9b0da72>] cfg80211_netdev_notifier_call+0xf2/0x4f0 [cfg80211] [<c160f2c9>] notifier_call_chain+0x59/0x130 [<c106c6de>] __raw_notifier_call_chain+0x1e/0x30 [<c106c70f>] raw_notifier_call_chain+0x1f/0x30 [<c14f8213>] call_netdevice_notifiers_info+0x33/0x70 [<c14f8263>] call_netdevice_notifiers+0x13/0x20 [<c14f82a4>] __dev_close_many+0x34/0xb0 [<c14f83fe>] dev_close_many+0x6e/0xc0 [<c14f9c77>] rollback_registered_many+0xa7/0x1f0 [<c14f9dd4>] unregister_netdevice_many+0x14/0x60 [<fb06f4d9>] ieee80211_remove_interfaces+0xe9/0x170 [mac80211] [<fb055116>] ieee80211_unregister_hw+0x56/0x110 [mac80211] [<fa3e9396>] iwl_op_mode_mvm_stop+0x26/0xe0 [iwlmvm] [<f9b9d8ca>] _iwl_op_mode_stop+0x3a/0x70 [iwlwifi] [<f9b9d96f>] iwl_opmode_deregister+0x6f/0x90 [iwlwifi] [<fa405179>] __exit_compat+0xd/0x19 [iwlmvm] [<c10b8bf9>] SyS_delete_module+0x179/0x2b0 [<c1613421>] sysenter_do_call+0x12/0x32 Fixes: 687da132234f ("mac80211: implement SMPS for AP") Cc: <stable@vger.kernel.org> [3.13] Reported-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | * mac80211: move roc cookie assignment earlierEliad Peller2014-02-061-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ieee80211_start_roc_work() might add a new roc to existing roc, and tell cfg80211 it has already started. However, this might happen before the roc cookie was set, resulting in REMAIN_ON_CHANNEL (started) event with null cookie. Consequently, it can make wpa_supplicant go out of sync. Fix it by setting the roc cookie earlier. Cc: stable@vger.kernel.org Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: add NAPI support backJohannes Berg2014-02-123-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NAPI was originally added to mac80211 a long time ago (by John in commit 4e6cbfd09c66 in July 2010), but then removed years later (by Stanislaw in commit 30c97120c6c7 in February 2013). No driver ever used it, so that was fine. Now I'm adding support for NAPI to our driver, so add some code to mac80211 again to support NAPI. John was originally wrapping some (but not nearly all NAPI-related functions), but that doesn't scale very well with the number of functions that are there, some of which are even only inlines. Thus, instead of doing that, let the drivers manage the NAPI struct, except for napi_add() which is needed so mac80211 knows how to call napi_gro_receive(). Also remove some no longer needed definitions that were left when NAPI support was removed. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Eyal Shapira <eyal@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | ieee80211: Print human-readable disassoc/deauth reason codesCalvin Owens2014-02-121-6/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a function to return a descriptive string for each reason code, and print that in addition to the numeric value in the kernel log. These codes are easily found on popular search engines, but one is generally not able to access the internet when dealing with wireless connectivity issues. Signed-off-by: Calvin Owens <jcalvinowens@gmail.com> [use 'unknown' rather than 'invalid' since more valid codes exist] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: simplify roc check in idle calculationJohannes Berg2014-02-121-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | There's no need to start iterating the list only to break on the first item, just use !list_empty() and also simplify the whole conditional into a single expression. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: fix IE buffer lenDavid Spinadel2014-02-111-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove size of SSID IE from the IE buffer in scan and sched scan, since this IE isn't added to this buffer. Reviewed-by: Eliad Peller <eliad@wizery.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: add beacon_loss debugfs fileEliad Peller2014-02-111-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add beacon_loss debugfs file that emulates ieee80211_beacon_loss call from the driver. This can be used for various testing scenarios. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: reset probe_send_count also in HW_CONNECTION_MONITOR caseEliad Peller2014-02-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case of beacon_loss with IEEE80211_HW_CONNECTION_MONITOR device, mac80211 probes the ap (and disconnects on timeout) but ignores the ack. If we already got an ack, there's no reason to continue disconnecting. this can help devices that supports IEEE80211_HW_CONNECTION_MONITOR only partially (e.g. take care of keep alives, but does not probe the ap. In case the device wants to disconnect without probing, it can just call ieee80211_connection_loss. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: remove superfluous band variableJohannes Berg2014-02-061-3/+0
|/ / | | | | | | | | | | | | | | We already have a band variable, so the new one is just shadowing it, but the existing one already holds the same value so just remove the inner one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: propagate STBC / LDPC flags to radiotapEmmanuel Grumbach2014-02-061-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This capabilities weren't propagated to the radiotap header. We don't set here the VHT_KNOWN / MCS_HAVE flag because not all the low level drivers will know how to properly flag the frames, hence the low level driver will be in charge of setting IEEE80211_RADIOTAP_MCS_HAVE_FEC, IEEE80211_RADIOTAP_MCS_HAVE_STBC and / or IEEE80211_RADIOTAP_VHT_KNOWN_STBC according to its capabilities. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: move VHT related RX_FLAG to another variableEmmanuel Grumbach2014-02-064-10/+13
| | | | | | | | | | | | | | | | | | | | ieee80211_rx_status.flags is full. Define a new vht_flag variable to be able to set more VHT related flags and make room in flags. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath10k] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: remove unused radiotap vendor fields in ieee80211_rx_statusEmmanuel Grumbach2014-02-061-48/+5
| | | | | | | | | | | | | | | | The purpose of this housekeeping is to make some room for VHT flags. The radiotap vendor fields weren't in use. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: order IEs in association request correctlyJohannes Berg2014-02-051-0/+28
| | | | | | | | | | | | | | | | In association request frames, there may be IEs passed from userspace (such as interworking IEs) between HT and VHT, so add code to insert those inbetween them. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: order IEs in probe request correctlyJohannes Berg2014-02-051-2/+30
| | | | | | | | | | | | | | | | In probe request frames, the VHT IEs should come before any vendor IEs, but after interworking and similar, so add code to order them correctly wrt. the IEs passed from userspace. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: update opmode when adding new stationMarek Kwaczynski2014-02-053-7/+34
| | | | | | | | | | | | | | | | | | | | Update the operating mode field is needed when an association request contains the operating mode notification element and it's not just changed later on the fly. Signed-off-by: Marek Kwaczynski <marek.kwaczynski@tieto.com> [clarify commit log, comments & fix whitespace] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | cfg80211: fix channel configuration in IBSS joinAntonio Quartulli2014-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When receiving an IBSS_JOINED event select the BSS object based on the {bssid, channel} couple rather than the bssid only. With the current approach if another cell having the same BSSID (but using a different channel) exists then cfg80211 picks up the wrong BSS object. The result is a mismatching channel configuration between cfg80211 and the driver, that can lead to any sort of problem. The issue can be triggered by having an IBSS sitting on given channel and then asking the driver to create a new cell using the same BSSID but with a different frequency. By passing the channel to cfg80211_get_bss() we can solve this ambiguity and retrieve/create the correct BSS object. All the users of cfg80211_ibss_joined() have been changed accordingly. Moreover WARN when cfg80211_ibss_joined() gets a NULL channel as argument and remove a bogus call of the same function in ath6kl (it does not make sense to call cfg80211_ibss_joined() with a zero BSSID on ibss-leave). Cc: Kalle Valo <kvalo@qca.qualcomm.com> Cc: Arend van Spriel <arend@broadcom.com> Cc: Bing Zhao <bzhao@marvell.com> Cc: Jussi Kivilinna <jussi.kivilinna@iki.fi> Cc: libertas-dev@lists.infradead.org Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com> [minor code cleanup in ath6kl] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: fix bufferable MMPDU RX handlingJohannes Berg2014-02-042-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Action, disassoc and deauth frames are bufferable, and as such don't have the PM bit in the frame control field reserved which means we need to react to the bit when receiving in such a frame. Fix this by introducing a new helper ieee80211_is_bufferable_mmpdu() and using it for the RX path that currently ignores the PM bit in any non-data frames for doze->wake transitions, but listens to it in all frames for wake->doze transitions, both of which are wrong. Also use the new helper in the TX path to clean up the code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: remove set but unused variablesJohannes Berg2014-02-043-7/+1
| | | | | | | | | | | | | | Compiling with W=1 found a few variables that are set but not used (-Wunused-but-set-variable), remove them. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: send ibss probe responses with noack flagSimon Wunderlich2014-02-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | Responding to probe requests for scanning clients will often create excessive retries, as it happens quite often that the scanning client already left the channel. Therefore do it like hostapd and send probe responses for wildcard SSID only once by using the noack flag. Signed-off-by: Simon Wunderlich <simon@open-mesh.com> [fix typo & 'wildcard SSID' in commit log] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: ibss: remove unnecessary call to release channelLuciano Coelho2014-02-041-1/+0
| | | | | | | | | | | | | | | | | | The ieee80211_vif_use_channel() function calls ieee80211_vif_release_channel(), so there's no need to call it explicitly in __ieee80211_sta_join_ibss(). Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: add missing CSA lockingMichal Kazior2014-02-044-1/+12
| | | | | | | | | | | | | | | | The patch adds a missing sdata lock and adds a few lockdeps for easier maintenance. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: fix sdata->radar_required lockingMichal Kazior2014-02-043-3/+5
| | | | | | | | | | | | | | | | | | radar_required setting wasn't protected by local->mtx in some places. This should prevent from scanning/radar detection/roc colliding. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: move csa_active setting in STA CSAMichal Kazior2014-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The sdata->vif.csa_active could be left set after, e.g. channel context constraints check fail in STA mode leaving the interface in a strange state for a brief period of time until it is disconnected. This was harmless but ugly. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: fix possible memory leak on AP CSA failureMichal Kazior2014-02-041-2/+3
| | | | | | | | | | | | | | | | | | | | If CSA for AP interface failed and the interface was not stopped afterwards another CSA request would leak sdata->u.ap.next_beacon. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: batch CSA bss info notificationMichal Kazior2014-02-043-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of having ieee80211_bss_info_change_notify() scattered all over the place just call it once when finalizing CSA. As a side effect this patch adds missing error checking for IBSS CSA beacon update. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> [fix err vs. changed variable usage in ieee80211_csa_finalize()] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: add length check in ieee80211_is_robust_mgmt_frame()Johannes Berg2014-02-043-13/+11
| | | | | | | | | | | | | | | | | | | | | | A few places weren't checking that the frame passed to the function actually has enough data even though the function clearly documents it must have a payload byte. Make this safer by changing the function to take an skb and checking the length inside. The old version is preserved for now as the rtl* drivers use it and don't have a correct skb. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: send {ADD,DEL}BA on AC_VO like other mgmt frames, as per specKarl Beldan2014-02-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ATM, {ADD,DEL}BA and BAR frames are sent on the AC matching the TID of the BA parameters. In the discussion [1] about this patch, Johannes recalled that it fixed some races with the DELBA and indeed this behavior was introduced in [2]. While [2] is right for the BARs, the part queueing the {ADD,DEL}BAs on their BA params TID AC violates the spec and is more a workaround for some drivers. Helmut expressed some concerns wrt such drivers, in particular DELBAs in rt2x00. ATM, DELBAs are sent after a driver has called (hence "purposely") ieee80211_start_tx_ba_cb_irqsafe and Johannes and Emmanuel gave some details wrt intentions behind the split of the IEEE80211_AMPDU_TX_STOP_* given to the driver ampdu_action supposed to call this function, which could prove handy to people trying to do the right thing in faulty drivers (if their fw/hw don't get in their way). [1] http://mid.gmane.org/1390391564-18481-1-git-send-email-karl.beldan@gmail.com [2] Commit: cf6bb79ad828 ("mac80211: Use appropriate TID for sending BAR, ADDBA and DELBA frames") Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: remove module handling from rate control opsJohannes Berg2014-02-041-23/+9
| | | | | | | | | | | | | | | | | | | | | | | | There's not a single rate control algorithm actually in a separate module where the module refcount would be required. Similarly, there's no specific rate control module. Therefore, all the module handling code in rate control is really just dead code, so remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: minstrel_ht: sample_table can be __read_mostlyJohannes Berg2014-02-041-3/+2
| | | | | | | | | | | | | | | | | | | | The sample table is initialized only once at module start, so is really __read_mostly. Additionally, the code to init it can be marked __init since it will never be needed again, it is likely automatically inlined into the __init function already by the compiler, so this doesn't really make a difference. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: make cfg80211 ops and privid constJohannes Berg2014-02-044-4/+4
| | | | | | | | | | | | | | The wiphy privid (to identify wiphys) and the cfg80211 ops should both be const, so change them to be. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: make rate control ops constJohannes Berg2014-02-046-13/+13
| | | | | | | | | | | | | | | | Change the code to allow making all the rate control ops const, nothing ever needs to change them. Also change all drivers to make use of this and mark the ops const. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
OpenPOWER on IntegriCloud