Mesh failure average never be more than 100. Only in case of
fixed path, average will be more than threshold limit (95%).
With recent EWMA changes it may go upto 99 as it is scaled to
100. It make sense to return maximum metric when average is
greater than threshold limit.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

We don't really need three different bits for each, since the
types are mutually exclusive. Use just two bits for it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This pointer really isn't needed, so remove it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This matches the spec, and otherwise things are really
confusing with the next patch adding CCFS2.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When disassociation happens only numeric reason is printed
in ieee80211_rx_mgmt_disassoc(). Add text variant, too.
Signed-off-by: NArkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As moving average is not considering fractional part, it will
get stuck at the same level after certain state. For example,
with current values, it can get stuck at 96. Fortunately the
current threshold 95%, but if it were increased to 96 or more
mesh paths would never be deactivated. Fix failure average
movement by using EWMA helpers, which does take into account
fractional parts.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
[johannes: pick a larger EWMA factor for more precision with
 the limited range that we will feed into it, adjust to new API]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

We don't actually need the full rculist.h header in sched.h anymore,
we will be able to include the smaller rcupdate.h header instead.

But first update code that relied on the implicit header inclusion.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Declaring the factor is counter-intuitive, and people are prone
to using small(-ish) values even when that makes no sense.

Change the DECLARE_EWMA() macro to take the fractional precision,
in bits, rather than a factor, and update all users.

While at it, add some more documentation.
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When I originally introduced using the driver-indicated station as an
optimisation to avoid the hashtable lookup/iteration, of course it
wasn't intended to really functionally change anything.

I neglected, however, to take into account VLAN interfaces, which have
the property that management and data frames are handled differently:
data frames go directly to the station and the VLAN while management
frames continue to be processed over the underlying/associated AP-type
interface. As a consequence, when a driver used this optimisation for
management frames and the user enabled VLANs, my change broke things
since any management frames, particularly disassoc/deauth, were missed
by hostapd.

Fix this by restoring the original code path for non-data frames, they
aren't critical for performance to begin with.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=194713.

Big thanks goes to Jarek who bisected the issue and provided a very
detailed bug report, including the crucial information that he was
using VLANs in his configuration.

Cc: stable@vger.kernel.org
Fixes: 771e846bea9e ("mac80211: allow passing transmitter station on RX")
Reported-and-tested-by: NJarek Kamiński <jarek@freeside.be>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Fix typos and add the following to the scripts/spelling.txt:

  swith||switch
  swithable||switchable
  swithed||switched
  swithing||switching

While we are here, fix the "update" to "updates" in the touched hunk in
drivers/net/wireless/marvell/mwifiex/wmm.c.

Link: http://lkml.kernel.org/r/1481573103-11329-2-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Tracing is limited to 100 characters and this message passes
the limit when there are a few buffered frames. Shorten it.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

iwlwifi now supports RSS and can't let mac80211 track the
PS state based on the Rx frames since they can come out of
order. iwlwifi is now advertising AP_LINK_PS, and uses
explicit notifications to teach mac80211 about the PS state
of the stations and the PS poll / uAPSD trigger frames
coming our way from the peers.

Because of that, the TIM stopped being maintained in
mac80211. I tried to fix this in commit c68df2e7
("mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE")
but that was later reverted by Felix in commit 6c18a6b4
("Revert "mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE")
since it broke drivers that do not implement set_tim.

Since none of the drivers that set AP_LINK_PS have the
set_tim() handler set besides iwlwifi, I can bail out in
__sta_info_recalc_tim if AP_LINK_PS AND .set_tim is not
implemented.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When running a BA session, the driver (or the hardware) already takes
care of retransmitting failed frames, since it has to keep the receiver
reorder window in sync.

Adding another layer of retransmit around that does not improve
anything. In fact, it can only lead to some strong reordering with huge
latency.

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When RX aggregation starts, transmitter may continue send frames
with SN smaller than SSN until the AddBA response is received.
However, the reorder buffer is already initialized at this point,
which will cause the drop of such frames as duplicates since the
head SN of the reorder buffer is set to the SSN, which is bigger.

Cc: stable@vger.kernel.org
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The issue was found when entering suspend and resume.
It triggers a warning in:
mac80211/key.c: ieee80211_enable_keys()
...
WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt ||
             sdata->crypto_tx_tailroom_pending_dec);
...

It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully
in a delayed_work during suspend. Add a flush_delayed_work to fix it.

Cc: stable@vger.kernel.org
Signed-off-by: NMatt Chen <matt.chen@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When adding per-CPU statistics, which added statistics back
to mac80211 for the fast-RX path, I evidently forgot to add
the "stats->packets++" line. The reason for that is likely
that I didn't see it since it's done in defragmentation for
the regular RX path.

Add the missing line to properly count received packets in
the fast-RX case.

Fixes: c9c5962b ("mac80211: enable collecting station statistics per-CPU")
Reported-by: NOren Givon <oren.givon@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

It is a relatively common idiom (8 instances) to first look up an IDR
entry, and then remove it from the tree if it is found, possibly doing
further operations upon the entry afterwards.  If we change idr_remove()
to return the removed object, all of these users can save themselves a
walk of the IDR tree.
Signed-off-by: NMatthew Wilcox <mawilcox@microsoft.com>

Add the missing IBSS capability flag during capability init as it needs
to be inserted into the generated beacon in order for CSA to work.

Fixes: cd7760e6 ("mac80211: add support for CSA in IBSS mode")
Signed-off-by: NPiotr Gawlowicz <gawlowicz@tkn.tu-berlin.de>
Signed-off-by: NMikołaj Chwalisz <chwalisz@tkn.tu-berlin.de>
Tested-by: NKoen Vandeputte <koen.vandeputte@ncentric.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Update the drivers to pass the RSSI level as a cfg80211_cqm_rssi_notify
parameter and pass this value to userspace in a new nl80211 attribute.
This helps both userspace and also helps in the implementation of the
multiple RSSI thresholds CQM mechanism.

Note for marvell/mwifiex I pass 0 for the RSSI value because the new
RSSI value is not available to the driver at the time of the
cfg80211_cqm_rssi_notify call, but the driver queries the new value
immediately after that, so it is actually available just a moment later
if we wanted to defer caling cfg80211_cqm_rssi_notify until that moment.
Without this, the new cfg80211 code (patch 3) will call .get_station
which will send a duplicate HostCmd_CMD_RSSI_INFO command to the hardware.
Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Extend ieee80211_cqm_rssi_notify with a rssi_level parameter so that
this information can be passed to netlink clients in the next patch, if
available.  Most drivers will have this value at hand.  wl1251 receives
events from the firmware that only tell it whether latest measurement
is above or below threshold so we don't pass any value at this time
(parameter is 0).
Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

kmalloc() can fail.  Also let's move the allocation out of the
declaration block so it's easier to read.

Fixes: 4a5eccaa ("mac80211: Show pending txqlen in debugfs.")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of open coding the CMAC algorithm in the mac80211 driver using
byte wide xors and calls into the crypto layer for each block of data,
instantiate a cmac(aes) synchronous hash and pass all the data into it
directly. This does not only simplify the code, it also allows the use
of more efficient and more secure implementations, especially on
platforms where SIMD ciphers have a considerable setup cost.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Switch the FILS AEAD code to use a cmac(aes) shash instantiated by the
crypto API rather than reusing the open coded implementation in
aes_cmac_vector(). This makes the code more understandable, and allows
platforms to implement cmac(aes) in a more secure (*) and efficient way
than is typically possible when using the AES cipher directly.

So replace the crypto_cipher by a crypto_shash, and update the aes_s2v()
routine to call the shash interface directly.

* In particular, the generic table based AES implementation is sensitive
  to known-plaintext timing attacks on the key, to which AES based MAC
  algorithms are especially vulnerable, given that their plaintext is not
  usually secret. Time invariant alternatives are available (e.g., based
  on SIMD algorithms), but may incur a setup cost that is prohibitive when
  operating on a single block at a time, which is why they don't usually
  expose the cipher API.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Somehow these files were never present or lost, but the code
is there and they seem somewhat useful, so add them back.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
return value in mesh_add_vendor_ies must therefore be checked against
ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
WLAN_EID_VENDOR_SPECIFIC will be rejected.

Fixes: 082ebb0c ("mac80211: fix mesh beacon format")
Signed-off-by: NThorsten Horstmann <thorsten@defutech.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
[sven@narfation.org: Add commit message]
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The skcipher could have been of the async variant which may return from
skcipher_encrypt() with -EINPROGRESS after having queued the request.
The FILS AEAD implementation here does not have code for dealing with
that possibility, so allocate a sync cipher explicitly to avoid
potential issues with hardware accelerators.

This is based on the patch sent out by Ard.

Fixes: 39404fee ("mac80211: FILS AEAD protection for station mode association frames")
Reported-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Incorrect num_elem parameter value (1 vs. 5) was used in the
aes_siv_encrypt() call. This resulted in only the first one of the five
AAD vectors to SIV getting included in calculation. This does not
protect all the contents correctly and would not interoperate with a
standard compliant implementation.

Fix this by using the correct number. A matching fix is needed in the AP
side (hostapd) to get FILS authentication working properly.

Fixes: 39404fee ("mac80211: FILS AEAD protection for station mode association frames")
Reported-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

cleanup patch to make use of ieee80211_ac_from_tid() to retrieve ac from
ieee802_1d_to_ac[]
Signed-off-by: NAmadeusz Sławiński <amadeusz.slawinski@tieto.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In my previous patch, I missed that rate_control_rate_init() is
called from some places that cannot sleep, so it cannot call
ieee80211_recalc_min_chandef(). Remove that call for now to fix
the context bug, we'll have to find a different way to fix the
minimum channel width issue.

Fixes: 96aa2e7c ("mac80211: calculate min channel width correctly")
Reported-by: NXiaolong Ye (via lkp-robot) <xiaolong.ye@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Station structure is considered as not uploaded
(to driver) until drv_sta_state() finishes. This
call is however done after the structure is
attached to mac80211 internal lists and hashes.
This means mac80211 can lookup (and use) station
structure before it is uploaded to a driver.

If this happens (structure exists, but
sta->uploaded is false) fast_tx path can still be
taken. Deep in the fastpath call the sta->uploaded
is checked against to derive "pubsta" argument for
ieee80211_get_txq(). If sta->uploaded is false
(and sta is actually non-NULL) ieee80211_get_txq()
effectively downgraded to vif->txq.

At first glance this may look innocent but coerces
mac80211 into a state that is almost guaranteed
(codel may drop offending skb) to crash because a
station-oriented skb gets queued up on
vif-oriented txq. The ieee80211_tx_dequeue() ends
up looking at info->control.flags and tries to use
txq->sta which in the fail case is NULL.

It's probably pointless to pretend one can
downgrade skb from sta-txq to vif-txq.

Since downgrading unicast traffic to vif->txq must
not be done there's no txq to put a frame on if
sta->uploaded is false. Therefore the code is made
to fall back to regular tx() op path if the
described condition is hit.

Only drivers using wake_tx_queue were affected.

Example crash dump before fix:

 Unable to handle kernel paging request at virtual address ffffe26c
 PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
 [<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
 [<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
 [<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
 [<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
 [<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
 [<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
 [<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
 [<c0572e90>] (net_rx_action+0xac/0x160)
Reported-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

ibss and mesh modes copy the ht capabilites from the band without
overriding the SMPS state. Unfortunately the default value 0 for the
SMPS field means static SMPS instead of disabled.

This results in HT ibss and mesh setups using only single-stream rates,
even though SMPS is not supposed to be active.

Initialize SMPS to disabled for all bands on ieee80211_hw_register to
ensure that the value is sane where it is not overriden with the real
SMPS state.
Reported-by: NElektra Wagenrad <onelektra@gmx.net>
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
[move VHT TODO comment to a better place]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There may be situations in which the in-kernel originator of an
SKB cares about its wifi transmission status. To have that, set
the wifi_acked[_valid] bits before freeing/orphaning the SKB if
the destructor is set. The originator can then use it in there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a flag that indicates that the WEP ICV was stripped from an
RX packet, allowing the device to not transfer that if it's
already checked.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When an associated station changes its VHT operating mode this
can/will affect the bandwidth it's using, and consequently we
must recalculate the minimum bandwidth we need to use. Failure
to do so can lead to one of two scenarios:
 1) we use a too high bandwidth, this is benign
 2) we use a too narrow bandwidth, causing rate control and
    actual PHY configuration to be out of sync, which can in
    turn cause problems/crashes
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In the current minimum chandef code there's an issue in that the
recalculation can happen after rate control is initialized for a
station that has a wider bandwidth than the current chanctx, and
then rate control can immediately start using those higher rates
which could cause problems.

Observe that first of all that this problem is because we don't
take non-associated and non-uploaded stations into account. The
restriction to non-associated is quite pointless and is one of
the causes for the problem described above, since the rate init
will happen before the station is set to associated; no frames
could actually be sent until associated, but the rate table can
already contain higher rates and that might cause problems.

Also, rejecting non-uploaded stations is wrong, since the rate
control can select higher rates for those as well.

Secondly, it's then necessary to recalculate the minimal config
before initializing rate control, so that when rate control is
initialized, the higher rates are already available. This can be
done easily by adding the necessary function call in rate init.

Change-Id: Ib9bc02d34797078db55459d196993f39dcd43070
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In the commit below, I forgot to translate the mac80211's
AC to QoS IE order. Moreover, the condition in the if was
wrong. Fix both issues.
This bug would hit only with clients that didn't set all
the ACs as delivery enabled.

Fixes: f438ceb8 ("mac80211: uapsd_queues is in QoS IE order")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This patch fix issue introduced by my previous commit that
tried to ensure enough headroom was present, and instead
broke it.

When forwarding mesh pkt, mac80211 may also add security header,
and it must therefore be taken into account in the needed headroom.

Fixes: d8da0b5d ("mac80211: Ensure enough headroom when forwarding mesh pkt")
Signed-off-by: NCedric Izoard <cedric.izoard@ceva-dsp.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>