This was missed in the previous patch, add some documentation
for rate_ctrl_lock to avoid docbook warnings.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The GO_CONCURRENT regulatory definition can be extended to station
interfaces requesting to IR as part of TDLS off-channel operations.
Rename the GO_CONCURRENT flag to IR_CONCURRENT and allow the added
use-case.

Change internal users of GO_CONCURRENT to use the new definition.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Declare that MCS 0-9 are supported for all Rx chains.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Previously, VHT capabilities and supported MCSs where set for all
bands, although VHT is only allowed on 5.2 GHz band. Fix it.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If a P2P GO was allowed on a channel because of the GO concurrent
relaxation, i.e., another station interface was associated to an AP on
the same channel or the same UNII band, and the station interface
disconnected from the AP, allow the following use cases unless the
channel is marked as indoor only and the device is not operating in an
indoor environment:

1. Allow the P2P GO to stay on its current channel. The rationale behind
   this is that if the channel or UNII band were allowed by the AP they
   could still be used to continue the P2P GO operation, and avoid connection
   breakage.
2. Allow another P2P GO to start on the same channel or another channel
   that is in the same UNII band as the previous instantiated P2P GO.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently, a cipher scheme can advertise an arbitrarily long
sequence counter, but mac80211 only supports up to 16 bytes
and the initial value from userspace will be truncated.

Fix two things:
 * don't allow the driver to register anything longer than
   the 16 bytes that mac80211 reserves space for
 * require userspace to specify a starting value with the
   correct length (or none at all)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For ciphers not supported by mac80211, the function currently
doesn't return any PN data. Fix this by extending the driver's
get_key_seq() a little more to allow moving arbitrary PN data.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Extend the function to read the TKIP IV32/IV16 to read the IV/PN for
all ciphers in order to allow drivers with full hardware crypto to
properly support this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

No current (and planned, as far as I know) wifi devices support
encapsulation checksum offload, so remove the useless test here.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When LED triggers are compiled in, but not used, mac80211 will still
call them to update the status. This isn't really a problem for the
assoc and radio ones, but the TX/RX (and to a certain extend TPT)
ones can be called very frequently (for every packet.)

In order to avoid that when they're not used, track their activation
and call the corresponding trigger (and in the TPT case, account for
throughput) only when the trigger is actually used by an LED.

Additionally, make those trigger functions inlines since theyre only
used once in the remaining code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is just a code cleanup, make the LED trigger names const
as they're not expected to be modified by drivers.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Remove items that can be retrieved through nl80211. This also
removes two items (tx_packets and tx_bytes) where only the VO
counter was exposed since they are split up per AC but in the
debugfs file only the first AC was shown.

Also remove the useless "dev" file - the stations have long
been in a sub-directory of the netdev so there's no need for
that any more.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This counter is unsafe with concurrent TX and is only exposed
through debugfs and ethtool. Instead of trying to fix it just
remove it for now, if it's really needed then it should be
exposed through nl80211 and in a way that drivers that do the
fragmentation in the device could support it as well.
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>

Currently while associated to an AP and sending a (public) action
frame to a different AP on the same channel, the action frame will
be sent like a regular tx frame without going off channel.

When power save is enabled this can cause problems, since the device
can go into power save and miss the response to the action frame
that is sent by the other AP.

Force off-channel transmission to avoid this issue in case
- HW offchannel is used,
- the user didn't forbid transmitting frames off channel
- the frame is not sent to the AP that we are associated with
  (if it is we assume the response would be bufferable)
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
[reword commit message a bit]
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 will allow mac80211 to forbid sleeping from the
event_callback callback.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

HT and VHT override configurations were ignored during association and
applied only when first beacon recived, or not applied at all.

Fix the code to apply HT/VHT overrides during association. This is a bit
tricky since the channel was already configured during authentication
and we don't want to reconfigure it unless there's really a change.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

wpa_supplicant or authsae handles the mesh peering in user
space, but the plink state is still managed in kernel space.
Currently, there is no implementation by wpa_supplicant or
authsae to block the plink state after it is set to ESTAB.

By applying this patch, we can use the "iw mesh0 station set
<MAC address> plink_action block" to block the peer mesh STA.
This is useful for experimenting purposes.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.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>

This isn't necessary any more as the stack will automatically
update the TXQ's trans_start after calling ndo_start_xmit().
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>

Allow debug builds to configure the station hash table maximum
size in order to run with hash collisions in limited scenarios
such as hwsim testing. The default remains 0 which effectively
means no limit.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Implement the necessary software segmentation on the normal
TX path so that fast-xmit can use segmentation offload if
the hardware (or driver) supports it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If drivers want to support S/G (really just gather DMA on TX) then
we can now easily support this on the fast-xmit path since it just
needs to write to the ethernet header (and already has a check for
that being possible.)

However, disallow this on the regular TX path (which has to handle
fragmentation, software crypto, etc.) by calling skb_linearize().

Also allow the related HIGHDMA since that's not interesting to the
code in mac80211 at all anyway.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When we go through the complete TX processing, there are a number
of things like fragmentation and software crypto that require the
checksum to be calculated already.

In favour of maintainability, instead of adding the necessary call
to skb_checksum_help() in all the places that need it, just do it
once before the regular TX processing.

Right now this only affects the TI wlcore and QCA ath10k drivers
since they're the only ones using checksum offload. The previous
commits enabled fast-xmit for them in almost all cases.

For wlcore this even fixes a corner case: when a key fails to be
programmed to hardware software encryption gets used, encrypting
frames with a bad checksum.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The driver can clearly enable fast-xmit since it does rate
control in the device and thus must do duration calculation
there as well.
Acked-by: NKalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The driver can clearly enable fast-xmit since it does rate
control in the device and thus must do duration calculation
there as well.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

IBSS can be supported very easily since it uses the standard station
authorization state etc. so it just needs to be covered by the header
building switch statement.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When crypto is offloaded then in some cases it's all handled
by the device, and in others only some space for the IV must
be reserved in the frame. Handle both of these cases in the
fast-xmit path, up to a limit of 18 bytes of space for IVs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the driver handles fragmentation then it wouldn't
be done in software so we can still use the fast-xmit
path in that case.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For hwsim, the duration field in frames is already not valid for
the common case of HT/VHT MCSes, so there's little point in trying
to keep it accurate for the legacy rates. Enable the fast-xmit code
to allow testing that, although given the dependency on hardware
crypto it will only be enabled in open network configurations.
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>

A couple of enums in mac80211.h became structures recently, but the
comments didn't follow suit, leading to errors like:

  Error(.//include/net/mac80211.h:367): Cannot parse enum!
  Documentation/DocBook/Makefile:93: recipe for target 'Documentation/DocBook/80211.xml' failed
  make[1]: *** [Documentation/DocBook/80211.xml] Error 1
  Makefile:1361: recipe for target 'mandocs' failed
  make: *** [mandocs] Error 2

Fix the comments comments accordingly.  Added a couple of other small
comment fixes while I was there to silence other recently-added docbook
warnings.
Reported-by: NJim Davis <jim.epost@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
control aren't properly taking concurrency into account. It's
likely that the same is true for other rate control algorithms.

In the case of minstrel this manifests itself in crashes when an
update and other data access are run concurrently, for example
when the stations change bandwidth or similar. In iwlwifi, this
can cause firmware crashes.

Since fixing all rate control algorithms will be very difficult,
just provide locking for invocations. This protects the internal
data structures the algorithms maintain.

I've manipulated hostapd to test this, by having it change its
advertised bandwidth roughly ever 150ms. At the same time, I'm
running a flood ping between the client and the AP, which causes
this race of update vs. get_rate/status to easily happen on the
client. With this change, the system survives this test.
Reported-by: NSven Eckelmann <sven@open-mesh.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>