When mac80211 disconnects, it drops all the packets on the
queues. This happens after the net stack has been notified
that we have no link anymore (netif_carrier_off).
netif_carrier_off ensures that no new packets are sent to
xmit() callback, but we might have older packets in the
middle of the Tx path. These packets will land in the
driver's queues after the latter have been flushed.
Synchronize_net() between netif_carrier_off and drv_flush()
will fix this.

Note that we can't call synchronize_net inside
ieee80211_flush_queues since there are flows that call
ieee80211_flush_queues and don't need synchronize_net()
which is an expensive operation.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
[reword comment to be more accurate]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Control per packet Transmit Power Control (TPC) in lower drivers
according to TX power settings configured by the user. In particular TPC is
enabled if value passed in enum nl80211_tx_power_setting is
NL80211_TX_POWER_LIMITED (allow using less than specified from userspace),
whereas TPC is disabled if nl80211_tx_power_setting is set to
NL80211_TX_POWER_FIXED (use value configured from userspace)
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some drivers unfortunately cannot support software crypto, but
mac80211 currently assumes that they do.

This has the issue that if the hardware enabling fails for some
reason, the software fallback is used, which won't work. This
clearly isn't desirable, the error should be reported and the
key setting refused.

Support this in mac80211 by allowing drivers to set a new HW
flag IEEE80211_HW_SW_CRYPTO_CONTROL, in which case mac80211 will
only allow software fallback if the set_key() method returns 1.
The driver will also need to advertise supported cipher suites
so that mac80211 doesn't advertise any (future) software ciphers
that the driver can't actually do.

While at it, to make it easier to support this, refactor the
ieee80211_init_cipher_suites() code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Station info state is started in allocation, so should be
destroyed on free (it's just a timer); rate control must
be freed if anything afterwards fails to initialize.

LED exit should be later, no need for locking there, but
it needs to be done also when rate init failed.

Also clean up the code by moving a label so the locking
doesn't have to be done separately.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

While suspending, we destroy the authentication /
association that might be taking place. While doing so, we
forgot to delete the timer which can be firing after
local->suspended is already set, producing the warning below.

Fix that by deleting the timer.

[66722.825487] WARNING: CPU: 2 PID: 5612 at net/mac80211/util.c:755 ieee80211_can_queue_work.isra.18+0x32/0x40 [mac80211]()
[66722.825487] queueing ieee80211 work while going to suspend
[66722.825529] CPU: 2 PID: 5612 Comm: kworker/u16:69 Tainted: G        W  O  3.16.1+ #24
[66722.825537] Workqueue: events_unbound async_run_entry_fn
[66722.825545] Call Trace:
[66722.825552]  <IRQ>  [<ffffffff817edbb2>] dump_stack+0x4d/0x66
[66722.825556]  [<ffffffff81075cad>] warn_slowpath_common+0x7d/0xa0
[66722.825572]  [<ffffffffa06b5b90>] ? ieee80211_sta_bcn_mon_timer+0x50/0x50 [mac80211]
[66722.825573]  [<ffffffff81075d1c>] warn_slowpath_fmt+0x4c/0x50
[66722.825586]  [<ffffffffa06977a2>] ieee80211_can_queue_work.isra.18+0x32/0x40 [mac80211]
[66722.825598]  [<ffffffffa06977d5>] ieee80211_queue_work+0x25/0x50 [mac80211]
[66722.825611]  [<ffffffffa06b5bac>] ieee80211_sta_timer+0x1c/0x20 [mac80211]
[66722.825614]  [<ffffffff8108655a>] call_timer_fn+0x8a/0x300
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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

For some reason, we made the bandwidth separate flags, which
is rather confusing - a single rate cannot have different
bandwidths at the same time.

Change this to no longer be flags but use a separate field
for the bandwidth ('bw') instead.

While at it, add support for 5 and 10 MHz rates - these are
reported as regular legacy rates with their real bitrate,
but tagged as 5/10 now to make it easier to distinguish them.

In the nl80211 API, the flags are preserved, but the code
now can also clearly only set a single one of the flags.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

These rates are treated the same as 160 MHz in the spec,
so it makes no sense to distinguish them. As no driver
uses them yet, this is also not a problem, just remove
them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Radar detection can last indefinite time. There is no
point in deferring a scan request in this case - simply
return -EBUSY.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

ctx->conf.radar_enabled should reflect whether radar
detection is enabled for the channel context.

When calculating it, make it consider only the vifs
that have this context assigned (instead of all the
vifs).
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

local->radar_detect_enabled should tell whether
radar_detect is enabled on any interface belonging
to local.

However, it's not getting updated correctly
in many cases (actually, when testing with hwsim
it's never been set, even when the dfs master
is beaconing).

Instead of handling all the corner cases
(e.g. channel switch), simply check whether
radar detection is enabled only when needed,
instead of caching the result.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The function adding the supported channels IE during a TDLS connection had
several issues:
1. If the entire subband is usable, the function exitted the loop without
   adding it
2. The function only checked chandef_usable, ignoring flags like RADAR
   which would prevent TDLS off-channel communcation.
3. HT20 was explicitly required in the chandef, while not a requirement
   for TDLS off-channel.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When roaming / suspending, it makes no sense to wait until
the transmit queues of the device are empty. In extreme
condition they can be starved (VO saturating the air), but
even in regular cases, it is pointless to delay the roaming
because the low level driver is trying to send packets to
an AP which is far away. We'd rather drop these packets and
let TCP retransmit if needed. This will allow to speed up
the roaming.

For suspend, the explanation is even more trivial.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a station disconnects with frames still pending, we clear
the TIM bit, but too late - it's only cleared when the station
is already removed from the driver, and thus the driver can get
confused (and hwsim will loudly complain.)

Fix this by clearing the TIM bit earlier, when the station has
been unlinked but not removed from the driver yet. To do this,
refactor the TIM recalculation to in that case ignore traffic
and simply assume no pending traffic - this is correct for the
disconnected station even though the frames haven't been freed
yet at that point.

This patch isn't needed for current drivers though as they don't
check the station argument to the set_tim() operation and thus
don't really run into the possible confusion.
Reported-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Implement the new counters cfg80211 can now advertise to userspace.
The TX code is in the sequence number handler, which is a bit odd,
but that place already knows the TID and frame type, so it was
easiest and least impact there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is really just duplicating the list of information that's
already available in the nl80211 attribute, so remove the list.
Two small changes are needed:
 * remove STATION_INFO_ASSOC_REQ_IES complete, but the length
   (assoc_req_ies_len) can be used instead
 * add NL80211_STA_INFO_RX_DROP_MISC which exists internally
   but not in nl80211 yet

This gets rid of the duplicate maintenance of the two lists.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In many cases, drivers can filter things like beacons that will
skew statistics reported by mac80211. To get correct statistics
in these cases, call drivers to obtain statistics and let them
override all values, filling values from mac80211 if the driver
didn't provide them. Not all of them make sense for the driver
to fill, so some are still always done by mac80211.

Note that this doesn't currently allow a driver to say "I know
this value is wrong, don't report it at all", or to sum it up
with a mac80211 value (as could be useful for "dropped misc"),
that can be added if it turns out to be needed.

This also gets rid of the get_rssi() method as is can now be
implemented using sta_statistics().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Use the new cfg80211_del_sta_sinfo() function to send the
statistics about the deleted station with the delete event.
This lets userspace see how much traffic etc. the deleted
station used.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

All of the survey data is (currently) per channel anyway,
so having the word "channel" in the name does nothing. In
the next patch I'll introduce global data to the survey,
where the word "channel" is actually confusing.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When hw acceleration is enabled, the GENERATE_IV or PUT_IV_SPACE flags
only require headroom space. Therefore, the tailroom-needed counter can
safely be decremented for most drivers.

The older incarnation of this patch (ca34e3b5) assumed that the above
holds true for all drivers. As reported by Christopher Chavez and
researched by Christian Lamparter and Larry Finger, this isn't a valid
assumption for p54 and cw1200.

Drivers that still require tailroom for ICV/MIC even when HW encryption
is enabled can use IEEE80211_KEY_FLAG_RESERVE_TAILROOM to indicate it.
Signed-off-by: NIdo Yariv <idox.yariv@intel.com>
Cc: Christopher Chavez <chrischavez@gmx.us>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The patch "40a11ca8 mac80211: check if channels allow 80 MHz for VHT
probe requests" considered disabled channels as VHT enabled, and
mistakenly sent out probe-requests with the VHT IE.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This reverts commit ca34e3b5.

It turns out that the p54 and cw2100 drivers assume that there's
tailroom even when they don't say they really need it. However,
there's currently no way for them to explicitly say they do need
it, so for now revert this.

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

Cc: stable@vger.kernel.org
Fixes: ca34e3b5 ("mac80211: Fix accounting of the tailroom-needed counter")
Reported-by: NChristopher Chavez <chrischavez@gmx.us>
Bisected-by: NLarry Finger <Larry.Finger@lwfinger.net>
Debugged-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

dot11MulticastTransmittedFrameCount should be updated according
to the DA, which might be different from A1. Checking A1 results
in the counter being 0 in case of station, as to-DS data frames
use A1 for the BSSID.

This behaviour is defined in state machines, specifically in the
sta_tx_dcf_3.1d(10) description of 802.11-2012.
Signed-off-by: NEliad Peller <eliad@wizery.com>
[rewrite commit message]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

On minstrel_ht, the size of the per-sta struct is almost 18k, making it
an order-3 allocation.
A few fields inside the per-rate statistics are bigger than they need to
be. This patch reduces the size enough to cut down the per-sta struct to
about 13k (order-2 allocation).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If there are no interfaces up, there is no reason
to continue the reconfig flow.

The current code might end up calling driver
callbacks (e.g. resume(), reconfig_complete())
while the driver is already stopped.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The ht_oper variable is assigned a value, but never used in
ieee80211_parse_ch_switch_ie().  Remove it.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Commit e1a0c6b3 ("mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40")
mistakenly removed the actual update of sta->sta.bandwidth.

Refactor ieee80211_sta_cur_vht_bw() into multiple functions
(calculate caps-bw and chandef-bw separately, and min them
with cur_max_bandwidth).

On ht chanwidth action frame set only cur_max_bandwidth
(according to the sta capabilities) and recalc the sta bw.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In beacons, handle the Country IE even if no Power Constraint IE
is present, and, capability wise, also in case that the Radio
Measurements capability is enabled.

In cases where the Country IE should be handled and that the
Power Constraint IE is not present, the Country IE alone will
set the power limit (and not both Country and Power Constraint
IEs).
Signed-off-by: NMoshe Benji <moshe.benji@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

HT override configurations was ignored when choosing the channel
(until now, the override configuration affected only the
capabilities shown in the IEs).

The override configurations received only on association time,
so in this case we should determine the channel again.
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>

When writing the code to allow per-station GTKs, I neglected to
take into account the management frame keys (index 4 and 5) when
freeing the station and only added code to free the first four
data frame keys.

Fix this by iterating the array of keys over the right length.

Cc: stable@vger.kernel.org
Fixes: e31b8213 ("cfg80211/mac80211: allow per-station GTKs")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of sending peer candidate events just once, send them as long
as the peer remains in the LISTEN state in the peering state machine,
when userspace is implementing the peering manager.
Userspace may silence the events from a peer by progressing the state
machine or by setting the link state to BLOCKED.

Fixes the problem that a mesh peering process won't be fired again after
the previous first peering trial fails due to like air propagation error
if the peering is managed by user space such as wpa_supplicant.

This patch works with another patch for wpa_supplicant described here
which fires a peering process again triggered by the notice from kernel.
http://lists.shmoo.com/pipermail/hostap/2014-November/031235.htmlSigned-off-by: NKenzoh Nishikawa <Kenzoh.Nishikawa@jp.sony.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The call to cfg80211_ch_switch_notify() should be at the end of the
ieee80211_chswitch_post_beacon() function, because it should only be
sent if everything succeeded.

Fixes: d04b5ac9 ("cfg80211/mac80211: allow any interface to send channel switch notifications")
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When using IBSS in HT mode, we always get NSS=1
in rc_update callback. Force NSS recalculation when
rates updated and notify driver that NSS changed.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In order to let drivers have more dynamic U-APSD support,
move the enablement flag to the virtual interface driver
flags. This lets drivers not only set it up differently
for different interfaces, but also enable/disable on the
fly if needed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The power level might have been set, but as the interface was idle
it might not have taken effect yet. Ask the driver to check the
power level when starting up an AP so that in this case the correct
power level is used in case the device/driver can only set it when
the interface is actually active.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since multicast frames are marked as no-ack, using
IEEE80211_TX_STAT_ACK to check if they have been
successfully transmitted by the driver is incorrect
since a driver can choose to ignore transmission status
for no-ack frames. This results in incorrect accounting
for such frames.

To fix this issue, this patch introduces a new flag
that can be used by drivers to indicate error-free
transmission of no-ack frames.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
[add a note about not setting the flag for non-no-ack frames]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Move IEEE80211_TX_CTL_PS_RESPONSE to info->control.flags since
this is used only in the TX path (by ath9k). This frees up
a bit which can be used for other purposes.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the channel switch has been made, a vif is now using
the channel context which was reserved. When that happens,
we need to update the channel context since its parameters
may change.

I hit a case in which I switched to a 40Mhz channel but the
reserved channel context was still on 20Mhz. The rate control
would try to send 40Mhz packets on a 20Mhz channel context and
that made iwlwifi's firmware unhappy.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As multicast-frames can't be fragmented, "dot11MulticastReceivedFrameCount"
stopped being incremented after the use-after-free fix. Furthermore, the
RX-LED will be triggered by every multicast frame (which wouldn't happen
before) which wouldn't allow the LED to rest at all.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=89431 which also had the
patch.

Cc: stable@vger.kernel.org
Fixes: b8fff407 ("mac80211: fix use-after-free in defragmentation")
Signed-off-by: NAndreas Müller <goo@stapelspeicher.org>
[rewrite commit message]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Avoid a case where we would access uninitialized stack data if the AP
advertises HT support without 40MHz channel support.

Cc: stable@vger.kernel.org
Fixes: f3000e1b ("mac80211: fix broken use of VHT/20Mhz with some APs")
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>