summaryrefslogtreecommitdiffstats
path: root/net/mac80211/cfg.c
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: don't send SMPS action frame in AP mode when not neededEmmanuel Grumbach2017-06-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mac80211 allows to modify the SMPS state of an AP both, when it is started, and after it has been started. Such a change will trigger an action frame to all the peers that are currently connected, and will be remembered so that new peers will get notified as soon as they connect (since the SMPS setting in the beacon may not be the right one). This means that we need to remember the SMPS state currently requested as well as the SMPS state that was configured initially (and advertised in the beacon). The former is bss->req_smps and the latter is sdata->smps_mode. Initially, the AP interface could only be started with SMPS_OFF, which means that sdata->smps_mode was SMPS_OFF always. Later, a nl80211 API was added to be able to start an AP with a different AP mode. That code forgot to update bss->req_smps and because of that, if the AP interface was started with SMPS_DYNAMIC, we had: sdata->smps_mode = SMPS_DYNAMIC bss->req_smps = SMPS_OFF That configuration made mac80211 think it needs to fire off an action frame to any new station connecting to the AP in order to let it know that the actual SMPS configuration is SMPS_OFF. Fix that by properly setting bss->req_smps in ieee80211_start_ap. Fixes: f69931748730 ("mac80211: set smps_mode according to ap params") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Fix possible sband related NULL pointer de-referenceMohammed Shafi Shajakhan2017-04-281-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even if the channel context configuration is NULL. This crashes for chipsets which support 5 Ghz alone when it tries to access members of 'sband'. Channel context configuration can be NULL in multivif case and when channel switch is in progress (or) when it fails. Fix this by replacing the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which returns a NULL pointer for sband when the channel configuration is NULL. An example scenario is as below: In multivif mode (AP + STA) with drivers like ath10k, when we do a channel switch in the AP vif (which has a number of clients connected) and a STA vif which is connected to some other AP, when the channel switch in AP vif fails, while the STA vifs tries to connect to the other AP, there is a window where the channel context is NULL/invalid and this results in a crash while the clients connected to the AP vif tries to reconnect and this race is very similar to the one investigated by Michal in https://patchwork.kernel.org/patch/3788161/ and this does happens with hardware that supports 5Ghz alone after long hours of testing with continuous channel switch on the AP vif ieee80211 phy0: channel context reservation cannot be finalized because some interfaces aren't switching wlan0: failed to finalize CSA, disconnecting wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice (Reason: 3=DEAUTH_LEAVING) WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211] [<bf77272c>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211])) [<bf73cc50>] (nl80211_new_station [cfg80211]) Unable to handle kernel NULL pointer dereference at virtual address 00000014 pgd = d5f4c000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM PC is at sta_info_alloc+0x380/0x3fc [mac80211] LR is at sta_info_alloc+0x37c/0x3fc [mac80211] [<bf772738>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211]) [<bf73cc50>] (nl80211_new_station [cfg80211])) Cc: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: disentangle iflist_mtx and chanctx_mtxJohannes Berg2017-04-261-5/+1
| | | | | | | | | | | | | | | At least on iwlwifi, sometimes lockdep complains that we can lock chanctx_mtx -> mvm.mutex -> iflist_mtx (due to iterate_interfaces) and iflist_mtx -> chanctx_mtx Remove the latter dependency in mac80211 by using the RTNL that we already hold in one case, and can relatively easily achieve in the other case. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: add request id parameter to .sched_scan_stop() signatureArend Van Spriel2017-04-261-1/+2
| | | | | | | | | | | | For multiple scheduled scan support the driver needs to know which scheduled scan request is being stopped. Pass the request id in the .sched_scan_stop() callback. Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: use common code for monitor options in add/changeJohannes Berg2017-04-131-58/+64
| | | | | | | | | | Refactor the code to have common code for changing monitor options when adding and changing virtual interfaces. This will make it easier to add BPF filters to both paths. Note that this code carefully checks the error conditions first and only then applies the changes, to guarantee atomicity. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: move add/change interface monitor flags into paramsJohannes Berg2017-04-131-8/+7
| | | | | | | | | | | | Instead passing both flags, which can be NULL, and vif_params, which are never NULL, move the flags into the vif_params and use BIT(0), which is invalid from userspace, to indicate that the flags were changed. While updating all drivers, fix a small bug in wil6210 where it was setting the flags to 0 instead of leaving them unchanged. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: correct MU-MIMO monitor follow functionalityJohannes Berg2017-04-131-20/+58
| | | | | | | | | | | The MU-MIMO monitor follow functionality is broken because it doesn't clear the MU-MIMO owner even if both follow features are disabled. Fix that, and while at it move the code into a new helper function. Call this also when creating a new monitor interface to prepare for an upcoming cfg80211 change allowing that. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: allow leaving MU-MIMO monitor configuration unchangedJohannes Berg2017-04-131-4/+4
| | | | | | | | | | | | When changing monitor parameters, not setting the MU-MIMO attributes should mean that they're not changed - it's documented that to turn the feature off it's necessary to set all-zero group membership and an invalid follow-address. This isn't implemented. Fix this by making the parameters pointers, stop reusing the macaddr struct member, and documenting that NULL pointers mean unchanged. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: reject/clear user rate mask if not usableJohannes Berg2017-03-081-1/+17
| | | | | | | | | | | | | | | | | | | | If the user rate mask results in no (basic) rates being usable, clear it. Also, if we're already operating when it's set, reject it instead. Technically, selecting basic rates as the criterion is a bit too restrictive, but calculating the usable rates over all stations (e.g. in AP mode) is harder, and all stations must support the basic rates. Similarly, in client mode, the basic rates will be used anyway for control frames. This fixes the "no supported rates (...) in rate_mask ..." warning that occurs on TX when you've selected a rate mask that's not compatible with the connection (e.g. an AP that enables only the rates 36, 48, 54 and you've selected only 6, 9, 12.) Reported-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Add set_cqm_rssi_range_configAndrew Zaborowski2017-03-061-0/+28
| | | | | | | | | | Support .set_cqm_rssi_range_config if the beacons are available for processing in mac80211. There's no reason that this couldn't be offloaded by mac80211-based drivers but there's no driver method for that added in this patch. Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: fix NAN bands definitionLuca Coelho2017-02-091-2/+2
| | | | | | | | | | | | | | | The nl80211_nan_dual_band_conf enumeration doesn't make much sense. The default value is assigned to a bit, which makes it weird if the default bit and other bits are set at the same time. To improve this, get rid of NL80211_NAN_BAND_DEFAULT and add a wiphy configuration to let the drivers define which bands are supported. This is exposed to the userspace, which then can make a decision on which band(s) to use. Additionally, rename all "dual_band" elements to "bands", to make things clearer. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: multicast to unicast conversionMichael Braun2016-12-131-0/+12
| | | | | | | | | | | | | | | | | | | | | | | Add the ability for an AP (and associated VLANs) to perform multicast-to-unicast conversion for ARP, IPv4 and IPv6 frames (possibly within 802.1Q). If enabled, such frames are to be sent to each station separately, with the DA replaced by their own MAC address rather than the group address. Note that this may break certain expectations of the receiver, such as the ability to drop unicast IP packets received within multicast L2 frames, or the ability to not send ICMP destination unreachable messages for packets received in L2 multicast (which is required, but the receiver can't tell the difference if this new option is enabled.) This also doesn't implement the 802.11 DMS (directed multicast service). Signed-off-by: Michael Braun <michael-dev@fami-braun.de> [use true/false, rename label to the correct "multicast", use __be16 for ethertype and network order for constants] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: validate new interface's beacon intervalsJohannes Berg2016-10-271-1/+2
| | | | | | | | | | | As part of interface combination checking, verify any new interface's beacon intervals. In fact, just always add the beacon interval since that's harmless. With this patch, mac80211 is prepared for drivers that set the min_beacon_int_gcd parameter in interface combinations. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: filter multicast data packets on AP / AP_VLANMichael Braun2016-10-121-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds filtering for multicast data packets on AP_VLAN interfaces that have no authorized station connected and changes filtering on AP interfaces to not count stations assigned to AP_VLAN interfaces. This saves airtime and avoids waking up other stations currently authorized in this BSS. When using WPA, the packets dropped could not be decrypted by any station. The behaviour when there are no AP_VLAN interfaces is left unchanged. When there are AP_VLAN interfaces, this patch 1. adds filtering multicast data packets sent on AP_VLAN interfaces that have no authorized station connected. No filtering happens on 4addr AP_VLAN interfaces. 2. makes filtering of multicast data packets sent on AP interfaces depend on the number of authorized stations in this bss not assigned to an AP_VLAN interface. Therefore, a new num_mcast_sta counter is added for AP_VLAN interfaces. The existing one for AP interfaces is altered to not track stations assigned to an AP_VLAN interface. The new counter is exposed in debugfs. Signed-off-by: Michael Braun <michael-dev@fami-braun.de> [reformat commit message a bit, unline ieee80211_vif_{inc,dec}_num_mcast] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove unnecessary num_mcast_sta checkMichael Braun2016-10-121-7/+0
| | | | | | | | | | | | Checking for num_mcast_sta in __ieee80211_request_smps_ap() is unnecessary as sta list will be empty in this case anyway, so the list iteration will just exit immediately. Since this isn't a "hot" code path, it doesn't really matter, and the next patch will redefine num_mcast_sta to make this check invalid. Signed-off-by: Michael Braun <michael-dev@fami-braun.de> [change commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove unnecessary mesh checkJohannes Berg2016-10-121-4/+1
| | | | | | | | | sta_info_get_bss() is equivalent to sta_info_get() in the mesh case, since sta->sdata->bss will be NULL (it's only set for AP/AP_VLAN interfaces.) Thus, the mesh check here isn't actually needed - remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Add API to report NAN function matchAyala Beker2016-09-301-0/+25
| | | | | | | | | | Provide an API to report NAN function match. Mac80211 will lookup the corresponding cookie and report the match to cfg80211. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Implement add_nan_func and rm_nan_funcAyala Beker2016-09-301-0/+114
| | | | | | | | | | | Implement add/rm_nan_func functions and handle NAN function termination notifications. Handle instance_id allocation for NAN functions and implement the reconfig flow. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: implement nan_change_confAyala Beker2016-09-301-0/+31
| | | | | | | | | | | | | Implement nan_change_conf callback which allows to change current NAN configuration (master preference and dual band operation). Store the current NAN configuration in sdata, so it can be used both to provide the driver the updated configuration with changes and also it will be used in hw reconfig flows in next patches. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add boilerplate code for start / stop NANAyala Beker2016-09-301-0/+36
| | | | | | | | | | | This code doesn't do much besides allowing to start and stop the vif. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: add start / stop NAN commandsAyala Beker2016-09-301-0/+2
| | | | | | | | | | | | | | | | | This allows user space to start/stop NAN interface. A NAN interface is like P2P device in a few aspects: it doesn't have a netdev associated to it. Add the new interface type and prevent operations that can't be executed on NAN interface like scan. Define several attributes that may be configured by user space when starting NAN functionality (master preference and dual band operation) Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove pointless chanctx NULL checkJohannes Berg2016-09-151-4/+0
| | | | | | | | If chanctx is derived as container_of() from a non-NULL pointer, it can't ever be NULL. Since we checked conf before, that's true here, so remove the useless NULL check. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add support for MU-MIMO air snifferAviya Erenfeld2016-09-121-1/+22
| | | | | | | | | | | | | | | | | add support to MU-MIMO air sniffer according groupID: in monitor mode, use a given MU-MIMO groupID to monitor stations that belongs to that group using MU-MIMO. add support for following a station according to its MAC address using VHT MU-MIMO sniffer: the monitors wait until they get an action MU-MIMO notification frame, then parses it in order to find the groupID that corresponds to the given MAC address and monitors packets destined to that groupID using VHT MU-MIMO. Signed-off-by: Aviya Erenfeld <aviya.erenfeld@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: refactor monitor representation in sdataAviya Erenfeld2016-09-121-4/+4
| | | | | | | | | | | Insert the u32 monitor flags variable in a new structure that represents a monitor interface. This will allow to add more configuration variables to that structure which will happen in an upcoming change. Signed-off-by: Aviya Erenfeld <aviya.erenfeld@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix purging multicast PS buffer queueFelix Fietkau2016-08-051-1/+1
| | | | | | | | | | | | | The code currently assumes that buffered multicast PS frames don't have a pending ACK frame for tx status reporting. However, hostapd sends a broadcast deauth frame on teardown for which tx status is requested. This can lead to the "Have pending ack frames" warning on module reload. Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: Add mesh peer AID setting APIMasashi Honma2016-07-061-0/+1
| | | | | | | | | | Previously, mesh power management functionality works only with kernel MPM. Because user space MPM did not report mesh peer AID to kernel, the kernel could not identify the bit in TIM element. So this patch adds mesh peer AID setting API. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: remove enum ieee80211_bandJohannes Berg2016-04-121-7/+7
| | | | | | | | | This enum is already perfectly aliased to enum nl80211_band, and the only reason for it is that we get IEEE80211_NUM_BANDS out of it. There's no really good reason to not declare the number of bands in nl80211 though, so do that and remove the cfg80211 one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add fast-rx pathJohannes Berg2016-04-061-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The regular RX path has a lot of code, but with a few assumptions on the hardware it's possible to reduce the amount of code significantly. Currently the assumptions on the driver are the following: * hardware/driver reordering buffer (if supporting aggregation) * hardware/driver decryption & PN checking (if using encryption) * hardware/driver did de-duplication * hardware/driver did A-MSDU deaggregation * AP_LINK_PS is used (in AP mode) * no client powersave handling in mac80211 (in client mode) of which some are actually checked per packet: * de-duplication * PN checking * decryption and additionally packets must * not be A-MSDU (have been deaggregated by driver/device) * be data packets * not be fragmented * be unicast * have RFC 1042 header Additionally dynamically we assume: * no encryption or CCMP/GCMP, TKIP/WEP/other not allowed * station must be authorized * 4-addr format not enabled Some data needed for the RX path is cached in a new per-station "fast_rx" structure, so that we only need to look at this and the packet, no other memory when processing packets on the fast RX path. After doing the above per-packet checks, the data path collapses down to a pretty simple conversion function taking advantage of the data cached in the small fast_rx struct. This should speed up the RX processing, and will make it easier to reason about parallelizing RX (for which statistics will need to be per-CPU still.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: track and tell driver about GO client P2P PS abilitiesAyala Beker2016-04-051-0/+4
| | | | | | | | | | Legacy clients don't support P2P power save mechanism, and thus if a P2P GO has a legacy client connected to it, it should disable P2P PS mechanisms. Let the driver know about this with a new bss_conf parameter. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: mesh: move path tables into if_meshBob Copeland2016-04-051-2/+2
| | | | | | | | | | | | | | The mesh path and mesh gate hashtables are global, containing all of the mpaths for every mesh interface, but the paths are all tied logically to a single interface. The common case is just a single mesh interface, so optimize for that by moving the global hashtable into the per-interface struct. Doing so allows us to drop sdata pointer comparisons inside the lookups and also saves a few bytes of BSS and data. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: move TKIP TX IVs to public part of key structEliad Peller2016-02-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some drivers/devices might want to set the IVs by themselves (and still let mac80211 generate MMIC). Specifically, this is needed when the device does offloading at certain times, and the driver has to make sure that the IVs of new tx frames (from the host) are synchronized with IVs that were potentially used during the offloading. Similarly to CCMP, move the TX IVs of TKIP keys to the public part of the key struct, and export a function to add the IV right into the crypto header. The public tx_pn field is defined as atomic64, so define TKIP_PN_TO_IV16/32 helper macros to convert it to iv16/32 when needed. Since the iv32 used for the p1k cache is taken directly from the frame, we can safely remove iv16/32 from being protected by tkip.txlock. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: limit the A-MSDU Tx based on peer's capabilitiesEmmanuel Grumbach2016-02-241-0/+29
| | | | | | | | | | | | | | | | In VHT, the specification allows to limit the number of MSDUs in an A-MSDU in the Extended Capabilities IE. There is also a limitation on the byte size in the VHT IE. In HT, the only limitation is on the byte size. Parse the capabilities from the peer and make them available to the driver. In HT, there is another limitation when a BA agreement is active: the byte size can't be greater than 4095. This is not enforced here. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2015-12-171-2/+1
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/net/geneve.c Here we had an overlapping change, where in 'net' the extraneous stats bump was being removed whilst in 'net-next' the final argument to udp_tunnel6_xmit_skb() was being changed. Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: handle width changes from opmode notification IE in beaconEyal Shapira2015-12-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | An AP can send an operating channel width change in a beacon opmode notification IE as long as there's a change in the nss as well (See 802.11ac-2013 section 10.41). So don't limit updating to nss only from an opmode notification IE. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: simplify ack_skb handlingJohannes Berg2015-12-041-10/+8
| | | | | | | | | | | | | | | | | | | | Since the cookie is assigned inside ieee80211_make_ack_skb() now, we no longer need to return the ack_skb as the cookie and can simplify the function's return and the callers. Also rename it to ieee80211_attach_ack_skb() to more accurately reflect its purpose. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: move off-channel/mgmt-tx code to offchannel.cJohannes Berg2015-12-041-488/+16
| | | | | | | | | | | | | | This is quite a bit of code that logically depends here since it has to deal with all the remain-on-channel logic. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: properly free skb when r-o-c for TX failsJohannes Berg2015-12-041-1/+1
| | | | | | | | | | | | | | When freeing the TX skb for an off-channel TX, use the correct API to also free the ACK skb that might have been allocated. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | cfg80211: handle add_station auth/assoc flag quirksJohannes Berg2015-12-041-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a new station is added to AP/GO interfaces the default behaviour is for it to be added authenticated and associated, due to backwards compatibility. To prevent that, the driver must be able to do that (setting the NL80211_FEATURE_FULL_AP_CLIENT_STATE feature flag) and userspace must set the flag mask to auth|assoc and clear the set. Handle this quirk in the API entirely in nl80211, and always push the full flags to the drivers. NL80211_FEATURE_FULL_AP_CLIENT_STATE is still required for userspace to be allowed to set the mask including those bits, but after checking that add both flags to the mask and set in case userspace didn't set them otherwise. This obsoletes the mac80211 code handling this difference, no other driver is currently using these flags. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: Add support for aborting an ongoing scanVidyullatha Kanchanapally2015-12-041-0/+6
|/ | | | | | | | | | This commit adds implementation for abort scan in mac80211. Reviewed-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Vidyullatha Kanchanapally <vkanchan@qti.qualcomm.com> Signed-off-by: Sunil Dutt <usdutt@qti.qualcomm.com> [adjust to wdev change in previous patch and clean up code a bit] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix off-channel mgmt-tx uninitialized variable usageJohannes Berg2015-12-021-2/+6
| | | | | | | | | | | | | | | | | | | | | | In the last change here, I neglected to update the cookie in one code path: when a mgmt-tx has no real cookie sent to userspace as it doesn't wait for a response, but is off-channel. The original code used the SKB pointer as the cookie and always assigned the cookie to the TX SKB in ieee80211_start_roc_work(), but my change turned this around and made the code rely on a valid cookie being passed in. Unfortunately, the off-channel no-wait TX path wasn't assigning one at all, resulting in an uninitialized stack value being used. This wasn't handed back to userspace as a cookie (since in the no-wait case there isn't a cookie), but it was tested for non-zero to distinguish between mgmt-tx and off-channel. Fix this by assigning a dummy non-zero cookie unconditionally, and get rid of a misleading comment and some dead code while at it. I'll clean up the ACK SKB handling separately later. Fixes: 3b79af973cf4 ("mac80211: stop using pointers as userspace cookies") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: don't reconfigure sched scan in case of wowlanEliad Peller2015-11-031-3/+3
| | | | | | | | | | | | | | | | Scheduled scan has to be reconfigured only if wowlan wasn't configured, since otherwise it should continue to run (with the 'any' trigger) or be aborted. The current code will end up asking the driver to start a new scheduled scan without stopping the previous one, and leaking some memory (from the previous request.) Fix this by doing the abort/restart under the proper conditions. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove cfg.hJohannes Berg2015-10-141-1/+0
| | | | | | | The file contains just a single declaration that can easily move to another file - remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: move sta_set_rate_info_rx() and make it staticJohannes Berg2015-10-141-39/+0
| | | | | | | There's only a single caller of this function, so it can be moved to the same file and made static. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove PM-QoS listenerJohannes Berg2015-10-141-2/+2
| | | | | | | | | | As this API has never really seen any use and most drivers don't ever use the value derived from it, remove it. Change the only driver using it (rt2x00) to simply use the DTIM period instead of the "max sleep" time. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Revert "mac80211: remove exposing 'mfp' to drivers"Tamizh chelvam2015-10-131-0/+1
| | | | | | | | | | | | This reverts commit 5c48f1201744233d4f235c7dd916d5196ed20716. Some device drivers (ath10k) offload part of aggregation including AddBA/DelBA negotiations to firmware. In such scenario, the PMF configuration of the station needs to be provided to driver to enable encryption of AddBA/DelBA action frames. Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge tag 'mac80211-next-for-davem-2015-10-05' of ↵David S. Miller2015-10-071-15/+41
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== For the current cycle, we have the following right now: * many internal fixes, API improvements, cleanups, etc. * full AP client state tracking in cfg80211/mac80211 from Ayala * VHT support (in mac80211) for mesh * some A-MSDU in A-MPDU support from Emmanuel * show current TX power to userspace (from Rafał) * support for netlink dump in vendor commands (myself) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: advertise support for full station state in AP modeAyala Beker2015-09-291-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | This enables adding stations in unauthenticated mode, just after receiving the first authentication frame; which in turn allows sending a negative authentication reply if the station cannot be added. In addition init rate control for unassociated station only when it becomes associated, prior to that low rates will be used. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: introduce per vif frame registration APIAndrei Otcheretianski2015-09-221-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the cfg80211's frame registration api receives wdev, however mac80211 assumes per device filter configuration and ignores wdev. Per device filtering is too wasteful, especially for multi-channel devices. Introduce new per vif frame registration API and use it for probe request registrations in ieee80211_mgmt_frame_register() Also call directly to ieee80211_configure_filter instead of using a work since it is now allowed to sleep in ieee80211_mgmt_frame_register. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: debugfs: add file to disallow TDLS wider-bwArik Nemtsov2015-09-221-0/+1
| | | | | | | | | | | | | | | | | | | | Sometimes we are interested in testing TDLS performance in a specific width setting. Add the ability to disable the wider-band feature, thereby allowing the TDLS channel width to be controlled by the BSS width. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: reset CQM history upon reconfigurationSara Sharon2015-09-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current behavior of notifying CQM events is inconsistent: Upon first configuration there is a cqm event with the current status according to threshold configured, regardless of signal stability. When there is reconfiguration no event is sent unless there is a significant change to the signal level according to the new configuration. Since the current reconfiguration behavior might cause missing CQM events in case the current signal did not change but is on the other side of the new threshold, fix that by resetting the stored signal level upon reconfiguration. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-26 05:54:18 +0000