Slow rates that have >95% success probability do not need to be
monitored continuously. When the channel conditions change rapidly, the
slow sampling results are useless anyway. When conditions change slowly,
they will be monitored by gradual downgrading of the actively used
rates. This patch slightly improves throughput under good conditions.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Under load, otherwise stable rates can easily fluctuate because of
collisions. In my tests on a clean channel, the success probability of
the max throughput rate often stays somewhere between 90% and 100% under
load. This can cause some unnecessary switching to lower rates.
This patch improves stability by treating success probability values
between 90% and 100% the same.
In my tests on a 3x3 HT20 link with lots of TCP traffic, it improves the
average throughput by a few mbit/s.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This basically reverts commit b207cdb07f.
Now is possible to use drv_{add,remove}_interface() and vif->debugfs_dir
to create/remove per interface debugfs files. Remove redundant
callbacks.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There is need create driver own per interface debugfs files. This is
currently done by drv_{add,remove}_interface_debugfs() callbacks. But it
is possible that after we remove interface from the driver (i.e.
on suspend) we call drv_remove_interface_debugfs() function. Fixing this
problem will require to add call drv_{add,remove}_interface_debugfs()
anytime we create and remove interface in mac80211. So it's better to
add debugfs dir dentry to vif structure to allow to create/remove
custom debugfs driver files on drv_{add,remove}_interface().
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some devices have multicast filter capability for each individual
virtual interface rather than just a global one. Add an interface
specific driver callback allowing such drivers to configure this.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of calling synchronize_net() for every key
on an interface or when a station is removed, do it
only once for all keys in both of these cases.
As a side-effect, removing station keys now always
calls synchronize_net() even if there are no keys,
which fixes an issue with station removal happening
in the driver while the station could still be used
for TX.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When a key is allocated but not really added, there's no
need to go through the entire teardown process. Also, if
adding a key fails, ieee80211_key_link() can take care of
freeing it instead of the (only) caller.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It is possible that sta_info_recalc_tim() is called consecutively
without changing the station's tim bit. In such cases there is no
need to call the driver's set_tim() callback.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The irqsafe version ieee80211_sta_eosp_irqsafe() exists, but
drivers must not mix calls to any irqsafe/non-irqsafe function.
Both ath9k and iwlwifi, the likely first users of this interface,
use non-irqsafe RX/TX/TX status so must also use a non-irqsafe
version of this function. Since no driver uses the _irqsafe()
version, remove that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Make the TX bytes/packets counters race-free by keeping
them per AC so concurrent TX on queues can't cause lost
or wrong updates. This works since each station belongs
to a single interface. While at it also make the bytes
counters 64-bit.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There is a corner case which wasn't being covered:
userspace may authenticate and allocate stations,
but still leave the peering up to the kernel.
Initialize the peering timer if the MPM is not in
userspace, in a path which is taken by both the kernel and
userspace when allocating stations.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the user requested a userspace MPM, automatically
disable auto_open_plinks to fully disable the kernel MPM.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Earlier mac80211 would check whether some kind of mesh
security was enabled, when the real question was "is the
MPM in userspace"?
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The mesh station types used to refer to whether the
station was secure or nonsecure. Really the salient
information is whether it is managed by the kernel or
userspace
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Secure mesh had the implicit requirement that the Mesh
Peering Management entity be in userspace. However
userspace might want to implement an open MPM as well, so
specify a mesh setup parameter to indicate this.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This patch improves the way minstrel sorts rates according to throughput
and success probability. 3 FOR-loops across the entire rate set in function
minstrel_update_stats() which where used to determine the fastest, second
fastest and most robust rate are reduced to 1 FOR-loop.
The sorted list of rates according throughput is extended to the best four
rates as we need them in upcoming joint rate and power control. The sorting
is done via the new function minstrel_sort_best_tp_rates().
The most robust rate selection is aligned with minstrel_ht's approach.
Once any success probability is above 95% the one with the highest
throughput is chosen as most robust rate. If success probabilities of all
rates are below 95%, the rate with the highest succ. prob. is elected as
most robust one
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Based on minstrel_ht this patch treats success probabilities below 10% as
implausible values for throughput calculation in minstrel's statistics.
Current throughput per rate with such a low success probability is reset
to 0 MBit/s.
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
While minstrel bootstraps and fills the success probabilities of each
rate the lowest rate has typically a very high success probability
(often 100% in our tests).
Its statistics are never updated but considered to setup the mrr chain.
In our tests we see that especially the 3rd mrr stage (which is that
rate providing highest success probability) is filled with the lowest rate
because its initial high sucess probability is never updated. By design
the 4th mrr stage is filled with the lowest rate so often 3rd and 4th
mrr stage are equal.
This patch follows minstrels general approach of assuming as little
as possible about rate dependencies. Consequently we include the
lowest rate into the random sampling table to get balanced up-to-date
statistics of all rates and therefore balanced decisions.
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Minstrel's decision which rate should be directly sampled within the
1st mrr stage is limited to such rates faster than the current max
throughput rate. All rates below the current max. throughput rate
are indirectly sampled via the 2nd mrr stage.
This approach leads to deprecated per rate statistics and therfore
a deprecated mrr chain setup.
This patch uses the sampling approach from minstrel_ht. A counter is
added to sum all indirect sample attempts per rate. After 20 indirect
sampling attempts the rate is directly sampled within the 1st mrr stage.
Therefore more up-to-date statistics for all rates are maintained and
used to setup the mrr chain.
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add documentation and more verbose variable names to minstrel's
multi-rate-retry setup within function minstrel_get_rate() to
increase the readability of the algorithm.
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Both minstrel versions use individual ways to scale up integer values
to perform calculations. Merge minstrel_ht's scaling macros into
minstrels header file and use them in both minstrel versions.
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Both rate control algorithms (minstrel and minstrel_ht) calculate
averages based on EWMA. Shift function minstrel_ewma() into
rc80211_minstrel.h and make use of it in both minstrel version.
Also shift the default EWMA level (75%) definition to the header file
and clean up variable usage.
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The last minstrel_ht changes increased the sampling frequency for
potentially useful rates to decrease the response time to rate
fluctuations. This caused an increase in sampling frequency that can
slightly reduce throughput, so this patch limits the sampling attempts
to one per rate instead of two.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For VHT, the wider bandwidths (up to 160 MHz) need
to be allowed. Since world roaming only covers the
case of connecting to an AP, it can be opened up
there, we will rely on the AP to know the local
regulations.
Acked-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no reason TDLS should be prevented on P2P client
interfaces, and most of the code already handles it, so
allow adding stations for it.
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Implement restricting peer VHT capabilities to the device's own
capabilities. This is useful when a single driver supports more
than one device and the devices have different capabilities
(often they will differ in the number of spatial streams), but
in particular is also necessary for VHT capability overrides to
work correctly -- otherwise it'd be possible to e.g. advertise,
due to overrides, that TX-STBC is not supported, but then still
use it to TX to the AP because it supports RX-STBC.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
HT capabilites are asymmetric -- e.g. beamforming is both an
RX and TX capability. If, for example, we support RX but not
TX, the RX capability of the AP station is masked out (if it
supports it). This works correctly if it's really the driver
capability.
If, on the other hand, the reason for not supporting TX BF
is that it was removed by HT capability overrides then the
wrong thing happens: the AP's TX capability will be removed
rather than its RX capability, because the override function
works on own capabilities, not remote ones, and doesn't take
the asymmetry into account.
To fix this make a copy of our own capabilities, apply the
overrides to them (where needed) and then use that to set up
the peer's capabilities.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The HT overrides are intended only for the connection
to the AP, not for any other purpose. Therefore, don't
apply them to TDLS peers that are also stations added
to a managed station interface.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For AP interfaces, there's no need to flush stations
or keys again when the interface is stopped as already
happened when the BSS was stopped on the interface.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since hostapd will remove keys this isn't usually
an issue, but we shouldn't leak keys to the next
BSS started on the same interface. For VLANs this
also fixes a bug, keys that aren't removed would
otherwise be leaked.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.
To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.
Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.
(*) it starts at 0 because HW crypto is on, then goes to
1 when HW crypto is disabled for a key, then back to
0 because the key is deleted; this happens for both
keys in the example. When new keys are added, it goes
to 1 first because they're added in software; when a
key is moved to hardware it goes back to 0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no driver using this flag, so it seems
that all drivers support HW crypto with WMM or
don't support it at all. Remove the flag and
code setting it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove not used any longer suspend/resume code.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove not used any longer suspend/resume code.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove not used any longer suspend/resume code.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since now we disconnect before suspend, various code which save
connection state can now be removed from suspend and resume
procedure. Cleanup on resume side is smaller as ieee80211_reconfig()
is also used for H/W restart.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If possible that after suspend, cfg80211 will receive request to
disconnect what require action on interface that was removed during
suspend.
Problem can manifest itself by various warnings similar to below one:
WARNING: at net/mac80211/driver-ops.h:12 ieee80211_bss_info_change_notify+0x2f9/0x300 [mac80211]()
wlan0: Failed check-sdata-in-driver check, flags: 0x4
Call Trace:
[<c043e0b3>] warn_slowpath_fmt+0x33/0x40
[<f83707c9>] ieee80211_bss_info_change_notify+0x2f9/0x300 [mac80211]
[<f83a660a>] ieee80211_recalc_ps_vif+0x2a/0x30 [mac80211]
[<f83a6706>] ieee80211_set_disassoc+0xf6/0x500 [mac80211]
[<f83a9441>] ieee80211_mgd_deauth+0x1f1/0x280 [mac80211]
[<f8381b36>] ieee80211_deauth+0x16/0x20 [mac80211]
[<f8261e70>] cfg80211_mlme_down+0x70/0xc0 [cfg80211]
[<f8264de1>] __cfg80211_disconnect+0x1b1/0x1d0 [cfg80211]
To fix the problem disconnect from any associated network before
suspend. User space is responsible to establish connection again
after resume. This basically need to be done by user space anyway,
because associated stations can go away during suspend (for example
NetworkManager disconnects on suspend and connect on resume by default).
Patch also handle situation when driver refuse to suspend with wowlan
configured and try to suspend again without it.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since two years no mac80211 driver implement support for NAPI. Looks
this feature is unneeded, so remove it from generic mac80211 code.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A sample attempt should only count in mi->sample_tries if the sample
attempt wasn't skipped based on slower rate criteria.
This patch increases the sampling frequency for potentially desirable
rates and thus enables faster recovery from interference or collisions.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If a rate is below the max_tp_rate, sample it frequently if:
- it is above max_tp_rate2, or
- it is above max_prob_rate and is a candidate for max_prob_rate
(has fewer streams than max_tp_rate).
This helps the retry chain recover more quickly from bad statistics
caused by collisions or interference, and slightly reduces throughput
fluctuations with higher rates.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Try to sample all available rates, as sample attempts do not cost much
airtime and are appropriately spaced based on the average A-MPDU length.
This helps with faster recovery on rate fluctuations.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
max_prob_rate should be selected to be very reliable, however limiting
it to single-stream on 3-stream devices is a bit much.
Allow max_prob_rate to use one stream less than the max_tp_rate.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
At high data rates the average frame transmission durations are small
enough for rounding errors to matter, sometimes causing minstrel to use
slightly lower transmit rates than necessary.
To fix this, change the unit of the duration value to nanoseconds
instead of microseconds, and reorder the multiplications/divisions when
calculating the throughput metric so that they don't overflow or
truncate prematurely.
At 2-stream HT40 this makes TCP throughput a bit more stable.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add NL80211_CMD_UPDATE_FT_IES to support update of FT IEs to the WLAN
driver and NL80211_CMD_FT_EVENT to send FT events from the WLAN driver.
This will carry the target AP's MAC address along with the relevant
Information Elements. This event is used to report received FT IEs
(MDIE, FTIE, RSN IE, TIE, RICIE). These changes allow FT to be supported
with drivers that use an internal SME instead of user space option (like
FT implementation in wpa_supplicant with mac80211-based drivers).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It's not useful to specify a 0 keepalive interval, this
would send too much data. Prohibit this to also avoid
device issues.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
