Public Action frames use special rules for how the BSSID field (Address
3) is set. A wildcard BSSID is used in cases where the transmitter and
recipient are not members of the same BSS. As such, we need to accept
Public Action frames with wildcard BSSID.

Commit db8e1732 ("mac80211: ignore frames between TDLS peers when
operating as AP") added a rule that drops Action frames to TDLS-peers
based on an Action frame having different DA (Address 1) and BSSID
(Address 3) values. This is not correct since it misses the possibility
of BSSID being a wildcard BSSID in which case the Address 1 would not
necessarily match.

Fix this by allowing mac80211 to accept wildcard BSSID in an Action
frame when in AP mode.

Fixes: db8e1732 ("mac80211: ignore frames between TDLS peers when operating as AP")
Cc: stable@vger.kernel.org
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Just like for CCMP we need to check that for GCMP the fragments
have PNs that increment by one; the spec was updated to fix this
security issue and now has the following text:

	The receiver shall discard MSDUs and MMPDUs whose constituent
	MPDU PN values are not incrementing in steps of 1.

Adapt the code for CCMP to work for GCMP as well, luckily the
relevant fields already alias each other so no code duplication
is needed (just check the aliasing with BUILD_BUG_ON.)

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

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: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This really should never happen except very early in the process
of bringing up a new driver, at which point you'll have to add
more debugging in the driver and this string isn't useful. Remove
it and save some size (when it's even compiled in.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Group station statistics by where they're (mostly) updated
(TX, RX and TX-status) and group them into sub-structs of
the struct sta_info.

Also rename the variables since the grouping now makes it
obvious where they belong.

This makes it easier to identify where the statistics are
updated in the code, and thus easier to think about them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Reduce indentation a bit to make the condition more readable.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of using the out-of-line average calculation, use the new
DECLARE_EWMA() macro to declare a signal EWMA, and use that.

This actually *reduces* the code size slightly (on x86-64) while
also reducing the station info size by 80 bytes.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently OCB mode accepts frames with bssid==broadcast and type!=beacon.
Some non-data frames are sent matching this, for example probe responses.
This results in unnecessary creation of STA entries.
Signed-off-by: NBertold Van den Bergh <bertold.vandenbergh@esat.kuleuven.be>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Move TDLS channel-switch Rx handling into an RTNL locked work. This is
required to add proper regulatory checking to incoming channel-switch
requests.
Queue incoming requests in a dedicated skb queue and handle the request
in a device-specific work to avoid deadlocking on interface removal.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's a long-standing TODO item to use this flag in the cooked
monitor RX, but clearly it was never needed and now this hasn't
been used by userspace for a long time, so no userspace changes
could require it now.

Remove the unused flag.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This counter is inherently racy (since it can be incremented by RX
as well as by concurrent TX) and only available in debugfs. Instead
of fixing it to be per-CPU or similar, remove it for now. If needed
it should be added without races and with proper nl80211, perhaps
even addressing the threshold reporting TODO item that's been there
since the code was originally added.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As there's no driver using this capability and reporting zero-length
A-MPDU subframes for radiotap monitoring, remove the capability to
free up two RX flags.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When introducing multiple RX queues, a single NAPI struct will not
be sufficient. Instead of trying to store multiple, simply change
the API to have the NAPI struct passed to the RX function. This of
course means that drivers using rx_irqsafe() cannot use NAPI, but
that seems a reasonable trade-off, particularly since only two of
all drivers are currently using it at all.

While at it, we can now remove the IEEE80211_RX_REORDER_TIMER flag
again since this code path cannot have a napi struct anyway.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This function is only used in the RX code, so moving it into
that file gives the compiler better optimisation possibilities
and also allows us to remove the check for short frames (which
in the RX path cannot happen, but as a generic utility needed
to be checked.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Short frames less than 16 octets are already blocked in the monitor
code by the should_drop_frame() function, and cannot get into the
regular RX path. Therefore, this check can never trigger and the
counter invariably stays zero. Remove the useless code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

We typically use 'sta' for the station info struct, and if needed
'pubsta' for the public (driver-visible) portion thereof. Do this
in the ieee80211_sta_ps_transition() function.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.

This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.

The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

No matter how the driver manages its NAPI context, there's no way
sending frames to it from a timer can be correct, since it would
corrupt the internal GRO lists.

To avoid that, always use the non-NAPI path when releasing frames
from the timer.

Cc: stable@vger.kernel.org
Reported-by: NJean Trivelly <jean.trivelly@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since these counters can only be read through debugfs, there's
very little point in maintaining them all the time. However,
even just making them depend on debugfs is pointless - they're
not normally used. Additionally a number of them aren't even
concurrency safe.

Move them under MAC80211_DEBUG_COUNTERS so they're normally
not even compiled in.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The debugfs statistics macros are pointlessly verbose, so change
that macro to just have a single argument. While at it, remove
the unused counters and rename rx_expand_skb_head2 to the better
rx_expand_skb_head_defrag.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When frames time out in the reordering buffer, it is a
good indication that something went wrong and the driver
may want to know about that to take action or trigger
debug flows.
It is pointless to notify the driver about each frame that
is released. Notify each time the timer fires.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When we receive a BAR, this typically means that our peer
doesn't hear our Block-Acks or that we can't hear its
frames. Either way, it is a good indication that the link
is in a bad condition. This is why it can serve as a probe
to the driver.
Use the event_callback callback for this.
Since more events with the same data will be added in the
feature, the structure that describes the data attached to
the event is called in a generic name: ieee80211_ba_event.

This also means that from now on, the event_callback can't
sleep.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This isn't all that relevant for RX right now, but TX can be concurrent
due to multi-queue and the accounting is therefore broken.

Use the standard per-CPU statistics to avoid this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The OCB input path already checked that the BSSID is the broadcast
address, so the later check can never fail.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The function really shouldn't be called prepare_for_handlers(),
all it does is check if the frame should be dropped. Rename it
to ieee80211_accept_frame() and clean it up a bit.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

With promisc support gone, only AP and P2P-Device type interfaces
still clear IEEE80211_RX_RA_MATCH. In both cases this isn't really
necessary though, so we can remove that flag and the code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This support is essentially useless as typically networks are encrypted,
frames will be filtered by hardware, and rate scaling will be done with
the intended recipient in mind. For real monitoring of the network, the
monitor mode support should be used instead.

Removing it removes a lot of corner cases.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In order to speed up mac80211's TX path, add the "fast-xmit" cache
that will cache the data frame 802.11 header and other data to be
able to build the frame more quickly. This cache is rebuilt when
external triggers imply changes, but a lot of the checks done per
packet today are simplified away to the check for the cache.

There's also a more detailed description in the code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows drivers to request per-vif and per-sta-tid queues from which
they can pull frames. This makes it easier to keep the hardware queues
short, and to improve fairness between clients and vifs.

The task of scheduling packet transmission is left up to the driver -
queueing is controlled by mac80211. Drivers can only dequeue packets by
calling ieee80211_tx_dequeue. This makes it possible to add active queue
management later without changing drivers using this code.

This can also be used as a starting point to implement A-MSDU
aggregation in a way that does not add artificially induced latency.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
[resolved minor context conflict, minor changes, endian annotations]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's an issue with the way the RX A-MPDU reorder timer is
deleted that can cause a kernel crash like this:

 * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
 * station is destroyed
 * reorder timer fires before ieee80211_free_tid_rx() runs,
   accessing the station, thus potentially crashing due to
   the use-after-free

The station deletion is protected by synchronize_net(), but
that isn't enough -- ieee80211_free_tid_rx() need not have
run when that returns (it deletes the timer.) We could use
rcu_barrier() instead of synchronize_net(), but that's much
more expensive.

Instead, to fix this, add a field tracking that the session
is being deleted. In this case, the only re-arming of the
timer happens with the reorder spinlock held, so make that
code not rearm it if the session is being deleted and also
delete the timer after setting that field. This ensures the
timer cannot fire after ___ieee80211_stop_rx_ba_session()
returns, which fixes the problem.

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

We currently have a hand-rolled table with 256 entries and are
using the last byte of the MAC address as the hash. This hash
is obviously very fast, but collisions are easily created and
we waste a lot of space in the common case of just connecting
as a client to an AP where we just have a single station. The
other common case of an AP is also suboptimal due to the size
of the hash table and the ease of causing collisions.

Convert all of this to use rhashtable with jhash, which gives
us the advantage of a far better hash function (with random
perturbation to avoid hash collision attacks) and of course
that the hash table grows and shrinks dynamically with chain
length, improving both cases above.

Use a specialised hash function (using jhash, but with fixed
length) to achieve better compiler optimisation as suggested
by Sergey Ryazanov.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This mechanism was historic, and only ever used by IBSS, which
also doesn't need to have it as it properly manages station's
802.1X PAE state (or, with WEP, always has a key.)

Remove the mechanism to clean up the code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a comment explaining how the RX path lock is used.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Move the netdev stats accounting into the common function
ieee80211_deliver_skb() that is called in both places.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The mesh forwarding path was not checking that data
frames were protected when running an encrypted network;
add the necessary check.

Cc: stable@vger.kernel.org
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows mac80211 to configure BIP-GMAC-128 and BIP-GMAC-256 to the
driver and also use software-implementation within mac80211 when the
driver does not support this with hardware accelaration.
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows mac80211 to configure BIP-CMAC-256 to the driver and also
use software-implementation within mac80211 when the driver does not
support this with hardware accelaration.
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows mac80211 to configure CCMP-256 to the driver and also use
software-implementation within mac80211 when the driver does not support
this with hardware accelaration.
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
[squash ccmp256 -> mic_len argument change]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows mac80211 to configure GCMP and GCMP-256 to the driver and
also use software-implementation within mac80211 when the driver does
not support this with hardware accelaration.
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
[remove a spurious newline]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In the case of non-QoS association, the counter was actually
wrong. The right index isn't security_idx but seqno_idx, as
security_idx will be 0 for data frames, while 16 is needed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>