If suspend starts while ieee80211_scan_completed() is running, between
the point where SCAN_COMPLETED is set and the work is queued,
ieee80211_scan_cancel() will not catch the work and we may finish
suspending before the work is actually executed, leaving the scan
running while suspended.

To fix this race, queue the scan work during resume if the
SCAN_COMPLETED flag is set and flush it immediately.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

For drivers without beacon filtering, support beacon statistics
entirely, i.e. report the number of beacons and average signal.

For drivers with beacon filtering, give them the number of beacons
received by mac80211 -- in case the device reports only the number
of filtered beacons then driver doesn't have to count all beacons
again as mac80211 already does.
Signed-off-by: Johannes 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: Johannes Berg <johannes.berg@intel.com>

These conditions are rather difficult to follow, for example
because "!sta" only exists to not crash in the case that we
don't have a station pointer (WLAN_TDLS_SETUP_REQUEST) in
which the additional condition (peer supports HT) doesn't
actually matter anyway.

Cleaning this up only duplicates two lines of code but makes
the rest far easier to read, so do that.

As a side effect, smatch stops complaining about the lack of
a sta pointer test after the !sta (since the !sta goes away)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There's no need to use another local 'sta' variable as the
original (outer scope) one isn't needed any more and has
become invalid anyway when exiting the RCU read section.

Remove the inner scope one and along with it the useless NULL
initialization.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

smatch warns that we once checked request->ssids in two functions
and then unconditionally used it later again.

This is actually fine, because the code has a relationship between
attrs[NL80211_ATTR_SCAN_SSIDS], n_ssids and request->ssids, but
smatch isn't smart enough to realize that.

Suppress the warnings by always checking just n_ssids - that way
smatch won't know that request->ssids could be NULL, and since it
is only NULL when n_ssids is 0 we still check everything correctly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This reverts commit 2ae70efc.

The new peer events that are generated by the change are causing problems
with wpa_supplicant in userspace: wpa_s tries to restart SAE authentication
with the peer when receiving the event, even though authentication may be in
progress already, and it gets very confused.

Revert back to the original operating mode, which is to only get events when
there is no corresponding station entry.

Cc: Nishikawa, Kenzoh <Kenzoh.Nishikawa@jp.sony.com>
Cc: Masashi Honma <masashi.honma@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

It is possible that a deferred scan is queued after the queues are
flushed in __ieee80211_suspend().  The deferred scan work may be
scheduled by ROC or ieee80211_stop_poll().

To make sure don't start a new scan while suspending, check whether
we're quiescing or suspended and complete the scan immediately if
that's the case.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When we go to suspend, there is complex set of states that
avoids races. The quiescing variable is set whlie
__ieee80211_suspend is running. Then suspended is set.
The code makes sure there is no window without any of these
flags.

The problem is that workers can still be enqueued while we
are quiescing. This leads to situations where the driver is
already suspending and other flows like disassociation are
handled by a worker.

To fix this, we need to check quiescing and suspended flags
in the worker itself and not only before enqueueing it.
I also add here extensive documentation to ease the
understanding of these complex issues.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
[reword comment to be more accurate]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The userspace may want to delay the the first scheduled scan or
net-detect cycle.  Add an optional attribute to the scheduled scan
configuration to pass the delay to be (optionally) used by the driver.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
[add the attribute to the policy to validate it]
Signed-off-by: Johannes 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: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Added new NL80211_ATTR_NETNS_FD which allows to
set namespace via nl80211 by fd.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Johannes 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: Johannes 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: Johannes 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: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This reverts commit ba1debdf.

Oliver reported that it breaks network-manager, for some reason with
this patch NM decides that the device isn't wireless but "generic"
(ethernet), sees no carrier (as expected with wifi) and fails to do
anything else with it.

Revert this to unbreak userspace.
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The return value from nl80211_send_station() is the length of the
skb, or a negative error, so abort sending the message only when
the return value was negative.

This fixes the ibss_rsn wpa_supplicant test case.
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Signed-off-by: Johannes 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: Johannes 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.

In the userspace API the field remains reserved to preserve
API and ABI.
Signed-off-by: Johannes 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: Johannes Berg <johannes.berg@intel.com>

I removed the enum earlier, but forgot to remove it from the
documentation - do that now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Send the netdetect configuration information in the response to
NL8021_CMD_GET_WOWLAN commands.  This includes the scan interval,
SSIDs to match and frequencies to scan.

Additionally, add the NL80211_WOWLAN_TRIG_NET_DETECT with
NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When a system contains only self-managed regulatory devices all hints
from the regulatory core are ignored. Stop hint processing early in this
case. These systems usually don't have CRDA deployed, which results in
endless (irrelevent) logs of the form:
cfg80211: Calling CRDA to update world regulatory domain

Make sure there's at least one self-managed device before discarding a
hint, in order to prevent initial hints from disappearing on CRDA
managed systems.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

A self-managed device will sometimes need to set its regdomain synchronously.
Notably it should be set before usermode has a chance to query it. Expose
a new API to accomplish this which requires the RTNL.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes 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: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes 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: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes 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: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes 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: Arik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes 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: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Document the rfkill module parameters default_state and
master_switch_mode.
Signed-off-by: Andrew Clausen <andrew.p.clausen@gmail.com>
[rewrite commit message]
Signed-off-by: Johannes 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: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The functions called within the iterators must be called with
tasklets disabled, so use atomic iteration like the rest of
the code and disable tasklets around the whole operation.
Signed-off-by: Johannes 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: Johannes Berg <johannes.berg@intel.com>

The base for the current statistics is pretty mixed up, support
exporting RX/TX statistics for MSDUs per TID. This (currently)
covers received MSDUs, transmitted MSDUs and retries/failures
thereof.

Doing it per TID for MSDUs makes more sense than say only per AC
because it's symmetric - we could export per-AC statistics for all
frames (which AC we used for transmission can be determined also
for management frames) but per TID is better and usually data
frames are really the ones we care about. Also, on RX we can't
determine the AC - but we do know the TID for any QoS MPDU we
received.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The current statistics we keep aren't very clear, some are on
MPDUs and some on MSDUs/MMPDUs. Clarify the descriptions based
on the counters mac80211 keeps.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Add these two values:
 * BEACON_RX: number of beacons received from this peer
 * BEACON_SIGNAL_AVG: signal strength average for beacons only

These can then be used for Android Lollipop's statistics request.
Signed-off-by: Johannes 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: Johannes 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: Johannes Berg <johannes.berg@intel.com>