If the association is in progress while we suspend, the
stack will be in a messed up state. Clean it before we
suspend.

This patch completes Johannes's patch:

1a1cb744
Author: Johannes Berg <johannes.berg@intel.com>

    mac80211: fix suspend vs. authentication race

Cc: <stable@vger.kernel.org>
Fixes: 12e7f517 ("mac80211: cleanup generic suspend/resume procedures")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

On 2.4Ghz band, the channels overlap since the delta
between different channels is 5Mhz while the width of the
receiver is 20Mhz (at least).

This means that we can hear beacons or probe responses from
adjacent channels. These frames will have a significant
lower RSSI which will feed all kinds of logic with inaccurate
data. An obvious example is the roaming algorithm that will
think our AP is getting weak and will try to move to another
AP.

In order to avoid this, update the signal only if the frame
has been heard on the same channel as the one advertised by
the AP in its DS / HT IEs.
We refrain from updating the values only if the AP is
already in the BSS list so that we will still have a valid
(but inaccurate) value if the AP was heard on an adjacent
channel only.

To achieve this, stop taking the channel from DS / HT IEs
in mac80211. The DS / HT IEs is taken into account to
discard the frame if it was received on a disabled channel.
This can happen due to the same phenomenon: the frame is
sent on channel 12, but heard on channel 11 while channel
12 can be disabled on certain devices. Since this check
is done in cfg80211, stop even checking this in mac80211.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
[remove unused rx_freq variable]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since Stanislaw's patch removing the quiescing code, mac80211 had
a race regarding suspend vs. authentication: as cfg80211 doesn't
track authentication attempts, it can't abort them. Therefore the
attempts may be kept running while suspending, which can lead to
all kinds of issues, in at least some cases causing an error in
iwlmvm firmware.

Fix this by aborting the authentication attempt when suspending.

Cc: stable@vger.kernel.org
Fixes: 12e7f517 ("mac80211: cleanup generic suspend/resume procedures")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When still authenticating the mac80211 code handling a deauthentication
requests from userspace doesn't verify that the request is valid in any
way, fix that. Additionally, it never returns an error, even if there's
no connection or authentication attempt, fix that as well.

While at it, move the message to not print a message in the error case
and to distinguish between the two cases.

Also simplify the code by duplicating the cfg80211 call.
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The bss struct might be freed in ieee80211_rx_bss_put(),
so we shouldn't use it afterwards.

Cc: stable@vger.kernel.org (3.10+)
Fixes: 817cee76 ("mac80211: track AP's beacon rate and give it to the driver")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a VHT network uses 20 or 40 MHz as per the HT operation
information, the channel center frequency segment 0 field in
the VHT operation information is reserved, so ignore it.

This fixes association with such networks when the AP puts 0
into the field, previously we'd disconnect due to an invalid
channel with the message
wlan0: AP VHT information is invalid, disable VHT

Cc: stable@vger.kernel.org
Fixes: f2d9d270 ("mac80211: support VHT association")
Reported-by: NTim Nelson <tim.l.nelson@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The MLME code in mac80211 must track whether or not the AP changed
bandwidth, but if there's no change while tracking it shouldn't do
anything, otherwise regulatory updates can make it impossible to
connect to certain APs if the regulatory database doesn't match the
information from the AP. See the precise scenario described in the
code.

This still leaves some possible problems with CSA or if the AP
actually changed bandwidth, but those cases are less common and
won't completely prevent using it.

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

Cc: stable@vger.kernel.org
Reported-and-tested-by: NNate Carlson <kernel@natecarlson.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Create a function to return a descriptive string for each reason code,
and print that in addition to the numeric value in the kernel log. These
codes are easily found on popular search engines, but one is generally
not able to access the internet when dealing with wireless connectivity
issues.
Signed-off-by: NCalvin Owens <jcalvinowens@gmail.com>
[use 'unknown' rather than 'invalid' since more valid codes exist]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In case ieee80211_prep_connection() fails to dereference
sdata->vif.chanctx_conf, the function returns and doesn't
free new_sta. fixed.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In case of beacon_loss with IEEE80211_HW_CONNECTION_MONITOR
device, mac80211 probes the ap (and disconnects on timeout)
but ignores the ack.

If we already got an ack, there's no reason to continue
disconnecting. this can help devices that supports
IEEE80211_HW_CONNECTION_MONITOR only partially (e.g. take
care of keep alives, but does not probe the ap.

In case the device wants to disconnect without probing,
it can just call ieee80211_connection_loss.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In association request frames, there may be IEs passed from
userspace (such as interworking IEs) between HT and VHT, so
add code to insert those inbetween them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The sdata->vif.csa_active could be left set after,
e.g. channel context constraints check fail in STA
mode leaving the interface in a strange state for
a brief period of time until it is disconnected.
This was harmless but ugly.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Restrict our published beamformee STS capability according
to the AP value.
Some AP show bad behaviour in interoperability testing
when our capabilities are better.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The scan code creates an iflist_mtx -> mtx locking dependency,
and a few other places, notably radar detection, were creating
the opposite dependency, causing lockdep to complain. As scan
and radar detection are mutually exclusive, the deadlock can't
really happen in practice, but it's still bad form.

A similar issue exists in the monitor mode code, but this is
only used by channel-context drivers right now and those have
to have hardware scan, so that also can't happen.

Still, fix these issues by making some of the channel context
code require the mtx to be held rather than acquiring it, thus
allowing the monitor/radar callers to keep the iflist_mtx->mtx
lock ordering.

While at it, also fix access to the local->scanning variable
in the radar code, and document that radar_detect_enabled is
now properly protected by the mtx.

All this would now introduce an ABBA deadlock between the DFS
work cancelling and local->mtx, so change the locking there a
bit to not need to use cancel_delayed_work_sync() but be able
to just use cancel_delayed_work(). The work is also safely
stopped/removed when the interface is stopped, so no extra
changes are needed.
Reported-by: NKalle Valo <kvalo@qca.qualcomm.com>
Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If we can assume that stations are never referenced by the
driver after sta_state returns (and this is true since the
previous iwlmvm patch and for all other drivers) then we
don't need to delay station destruction, and don't need to
play tricks with rcu_barrier() etc.

This should speed up some scenarios like hostapd shutdown.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's a bug in tracking HT opmode changes in mac80211, it
fails to update the driver when the channel parameters don't
change.

Move the code to do the HT opmode checking independently of
the channel/bandwidth tracking.
Signed-off-by: NAvri Altman <avri.altman@intel.com>
[edit commit message]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There is no reason why we should have only one channel switch
announcement at a time for a single phy.  When support for channel
switch with multiple contexts and multiple vifs per context is
implemented, we will need the chandef data for each vif.  Move the
csa_chandef structure to sdata to prepare for this.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
[Fixed compilation with mesh]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This adds generic cipher scheme support to mac80211, such schemes
are fully under control by the driver. On hw registration drivers
may specify additional HW ciphers with a scheme how these ciphers
have to be handled by mac80211 TX/RR. A cipher scheme specifies a
cipher suite value, a size of the security header to be added to
or stripped from frames and how the PN is to be verified on RX.
Signed-off-by: NMax Stepanov <Max.Stepanov@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

To report channel width correctly we have
to send correct channel parameters from
mac80211 when calling cfg80211_cac_event().

This is required in case of using channel width
higher than 20MHz and we have to set correct
dfs channel state after CAC (NL80211_DFS_AVAILABLE).
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Coverity points out that checking assoc_data->ie is
completely useless since it's an array in the struct
and can't be NULL - remove the useless checks.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Commit 392b9ffb ("mac80211: change beacon/connection polling")
removed the IEEE80211_STA_BEACON_POLL flag.

However, it accidentally removed the setting of
IEEE80211_STA_CONNECTION_POLL, making the connection polling
completely useless (the flag is always clear, so the result
is never being checked). Fix it.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Refactor the channel switch IE parsing to reduce the number
of function parameters.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the driver requests to move to STATIC or DYNAMIC SMPS,
we send an action frame to each associated station and
reconfigure the channel context / driver.
Of course, non-MIMO stations are ignored.

The beacon isn't updated. The association response will
include the original capabilities. Stations that associate
while in non-OFF SMPS mode will get an action frame right
after association to inform them about our current state.
Note that we wait until the end of the EAPOL. Sending an
action frame before the EAPOL is finished can be an issue
for a few clients. Clients aren't likely to send EAPOL
frames in MIMO anyway.

When the SMPS configuration gets more permissive (e.g.
STATIC -> OFF), we don't wake up stations that are asleep
We remember that they don't know about the change and send
the action frame when they wake up.

When the SMPS configuration gets more restrictive (e.g.
OFF -> STATIC), we set the TIM bit for every sleeping STA.
uAPSD stations might send MIMO until they poll the action
frame, but this is for a short period of time.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
[fix vht streams loop, initialisation]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some APs (notably a Sitecom WL-153 v1 with firmware 1.45) are sending
invalid WMM parameters setting AIFSN, ECWmin and ECWmax to zero. The
spec mandates that the value of AIFSN is at least 2, and some cards
(e.g. Intel with the iwldvm driver) can't transmit when the invalid
QoS parameters are actually uploaded to the firmware.

Since there's little chance of being able to guess the values that
the AP actually meant, disable WMM if such an invalid case is found.
Since ECWmin/ECWmax are allowed to be zero, only verify AIFSN >= 2
and ECWmin <= ECWmax.
Reviewed-by: NEliad Peller <eliad@wizery.com>
Reported-by: NAntonio Quartulli <antonio@meshcoding.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Limit the current implementation to a single channel context used by
a single vif, thereby avoiding multi-vif/channel complexities.

Reuse the main function from AP CSA code, but move a portion out in
order to fit the STA scenario.

Add a new mac80211 HW flag so we don't break devices that don't support
channel switch with channel-contexts. The new behavior will be opt-in.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The channel switch parsing function can be re-used for the IBSS code,
put the common part into an extra function.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
[also move/rename chandef_downgrade]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since when we detect beacon lost we do active AP probing (using nullfunc
frame or probe request) there is no need to have beacon polling. Flags
IEEE80211_STA_BEACON_POLL seems to be used just for historical reasons.

Change also make that after we start connection poll due to beacon loss,
next received beacon will abort the poll.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Seth reports that some APs, notably the Netgear WNDAP360, send
invalid ECSA IEs in probe response frames with the operating
class and channel number both set to zero, even when no channel
switch is being done. As a result, any scan while connected to
such an AP results in the connection being dropped.

Fix this by ignoring any channel switch announcment in probe
response frames entirely, since we're connected to the AP we
will be receiving a beacon (and maybe even an action frame) if
a channel switch is done, which is sufficient.

Cc: stable@vger.kernel.org # 3.10
Reported-by: NSeth Forshee <seth.forshee@canonical.com>
Tested-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In case the AP has different regulatory information than we do,
it can happen that we connect to an AP based on e.g. the world
roaming regulatory data, and then update our database with the
AP's country information disables the channel the AP is using.
If this happens on an HT AP, the bandwidth tracking code will
hit the WARN_ON() and disconnect. Since that's not very useful,
ignore the channel-disable flag in bandwidth tracking.

Cc: stable@vger.kernel.org
Reported-by: NChris Wright <chrisw@sous-sol.org>
Tested-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

While we're connected, the AP shouldn't change the primary channel
in the HT information. We checked this, and dropped the connection
if it did change it.

Unfortunately, this is causing problems on some APs, e.g. on the
Netgear WRT610NL: the beacons seem to always contain a bad channel
and if we made a connection using a probe response (correct data)
we drop the connection immediately and can basically not connect
properly at all.

Work around this by ignoring the HT primary channel information in
beacons if we're already connected.

Also print out more verbose messages in the other situations to
help diagnose similar bugs quicker in the future.

Cc: stable@vger.kernel.org [3.10]
Acked-by: NAndy Isaacson <adi@hexapodia.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

TX status notification can get lost, or the frames could
get stuck on the queue, so don't wait for the callback
from the driver forever and instead time out after half
a second.

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

Commit "3d9646d0 mac80211: fix channel selection bug" introduced a possible
infinite loop by moving the out target above the chandef_downgrade
while loop.  When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
back up to re-run the while loop...indefinitely.  Replace goto with
break and carry on.  This may not be sufficient to connect to the AP,
but will at least keep the cpu from livelocking.  Thanks to Derek Atkins
as an extra pair of debugging eyes.

Cc: stable@kernel.org
Signed-off-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some regulations (like germany, but also FCC) express their transmission
power limit in dBm/MHz or mW/MHz. To cope with that and be on the safe
side, reduce the maximum power to half (10 MHz) or quarter (5 MHz)
when operating on these reduced bandwidth channels.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

The various components accessing the bitrates table must use consider
the used channel bandwidth to select only available rates or calculate
the bitrate correctly.

There are some rates in reduced bandwidth modes which can't be
represented as multiples of 500kbps, like 2.25 MBit/s in 5 MHz mode. The
standard suggests to round up to the next multiple of 500kbps, just do
that in mac80211 as well.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
[make rate unsigned in ieee80211_add_tx_radiotap_header(), squash fix]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

Doing so will allow us to hold the BSS (not just ref it) over the
association process, thus ensuring that it doesn't time out and
gets invisible to the user (e.g. in 'iw wlan0 link'.)

This also fixes a leak in mac80211 where it doesn't always release
the BSS struct properly in all cases where calling this function.
This leak was reported by Ben Greear.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is a collection of minor fixes:
 * don't allow HT IEs in IBSS for 5/10 MHz
 * don't allow HT IEs in Mesh for 5/10 MHz
 * don't downgrade from/to 5 and 10 MHz channels
 * don't try HT rates for 5 and 10 MHz channels when selecting rates
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Track the AP's beacon rate in the scan BSS data and in the
interface configuration to let the drivers know which rate
the AP is using. This information may be used by drivers,
in our case to let the firmware optimise beacon RX.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There are some APs, notably 2G/3G/4G Wifi routers, specifically the
"Onda PN51T", "Vodafone PocketWiFi 2", "ZTE MF60" and a similar
T-Mobile branded device [1] that erroneously don't include all the
needed information in (re)association response frames. Work around
this by assuming the information is the same as it was in the
beacon or probe response and using the data from there instead.

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

[1] https://bbs.archlinux.org/viewtopic.php?pid=1277305

Note that this requires marking the first ieee802_11_parse_elems()
argument const, otherwise we'd get a compiler warning.

Cc: stable@vger.kernel.org
Reported-and-tested-by: NMichal Zajac <manwe@manwe.pl>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently beacon availability upon association is marked by have_beacon
flag of assoc_data structure that becomes unavailable when association
completes. However beacon availability indication is required also after
association to inform a driver. Currently dtim_period parameter is used
for this purpose. Move have_beacon flag to another structure, persistant
throughout a interface's life cycle. Use suitable sematics for beacon
availability indication.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
[fix another instance of BSS_CHANGED_DTIM_PERIOD in docs]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>