In interoperability testing some APs showed bad behaviour
if some of the VHT capabilities of the station are better
than their own. Restrict the assoc request parameters
 - beamformee capabable,
 - RX STBC and
 - RX MCS set
to the subset that the AP can support.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The probe response/beacon management frame RX code passes a
bool parameter to differentiate beacons and probe responses.
This is useless since we have the frame and can thus use its
frame control field. Moreover it is buggy since there is one
call to ieee80211_rx_bss_info with a beacon frame that is
indicated as a probe response, which is also fixed by using
the frame control field, so do that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The last fixes re-added the RCU synchronize penalty
on roaming to fix the races. Split up sta_info_flush()
now to get rid of that again, and let managed mode
(and only it) delay the actual destruction.
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When all interfaces have been removed, there can't
be any stations left over, so there's no need to
flush again. Remove this, and all code associated
with it, which also simplifies the function.
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When AP's SSID is hidden the BSS can appear several times in
cfg80211's BSS list: once with a zero-length SSID that comes
from the beacon, and once for each SSID from probe reponses.

Since the mac80211 stores its data in ieee80211_bss which
is embedded into cfg80211_bss, mac80211's data will be
duplicated too.

This becomes a problem when a driver needs the dtim_period
since this data exists only in the beacon's instance in
cfg80211 bss table which isn't the instance that is used
when associating.

Remove the DTIM period from the BSS table and track it
explicitly to avoid this problem.

Cc: stable@vger.kernel.org
Tested-by: NEfi Tubul <efi.tubul@intel.com>
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>

If channel contexts are enabled, the CSA should not be processed
further. A return is missing here.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a BSS struct is updated, the IEs are currently
overwritten or freed. This can lead to races if some
other CPU is accessing the BSS struct and using the
IEs concurrently.

Fix this by always allocating the IEs in a new struct
that holds the data and length and protecting access
to this new struct with RCU.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Determine the VHT channel from the AP's VHT operation IE
(if present) and configure the hardware to that channel
if it is supported. If channel contexts cause a channel
to not be usable, try a smaller bandwidth.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Convert mac80211 (and where necessary, some drivers a
little bit) to the new channel definition struct.

This will allow extending mac80211 for VHT, which is
currently restricted to channel contexts since there
are no drivers using that which makes it easier. As
I also don't care about VHT for drivers not using the
channel context API, I won't convert the previous API
to VHT support.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If ieee80211_prep_channel() decides that HT should be
disabled (because the HT IEs from the AP were invalid)
it will set the IEEE80211_STA_DISABLE_HT to not send
HT capabilities to the AP when associating. If this
happens during authentication, the flag will be lost
and we send HT frames, even if the channel config was
set up for non-HT. This can lead to issues.

Fix this by always resetting the ifmgd flags to zero
when the channel context is released so that the flag
resetting in ieee80211_mgd_assoc() isn't necessary.

To make the code a bit easier move the call to release
the channel in ieee80211_set_disassoc() to the end of
the function together with the flag resetting (which
needs to be at the end to avoid timers setting flags.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the AP doesn't support HT, or more importantly if
it does but we have to disable it because its IEs are
broken, don't advertise HT support in our association
request. Otherwise, we configure our channel to be a
20 MHz non-HT channel but the AP might still think we
support HT, or even 40 MHz.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since the 11n spec amendment was rolled into the
2012 version, "11n" no longer makes sense. Use
"HT" instead.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the driver doesn't support 40 MHz channels, then
mac80211 erroneously sets number of RX chains to one
although the number of chains is independent of the
support for 40 MHz channels.

Fix this by checking the 40 MHz support only for the
code that sets the 40 MHz channel not the complete
HT code block.

This also means the HT20 channel type will always be
set in the changed code block so there's no need to
set it in case we override the AP due to invalid IEs
in the probe response/beacon.

The indentation is a bit quirky, but I'm rewriting
this code for VHT support so this will change again
very soon.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

While connected to a GO, parse the P2P NoA attribute
and pass the CT Window and opportunistic powersave
parameters to the driver.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When userspace asks to deauthenticate and we're just
authenticated (or still authenticating) send a deauth
frame instead of deleting the auth request.

On the other hand, if we've just disassociated and
therefore deleted all our state already, drop the
deauth request because we no longer have a channel
context to send it on.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Even before channel contexts/multi-channel, having a
single global TX power limit was already problematic,
in particular if two managed interfaces connected to
two APs with different power constraints. The channel
context introduction completely broke this though and
in fact I had disabled TX power configuration there
for drivers using channel contexts.

Change everything to track TX power per interface so
that different user settings and different channel
maxima are treated correctly. Also continue tracking
the global TX power though for compatibility with
applications that attempt to configure the wiphy's
TX power globally.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Remove a duplicate check in ieee80211_rx_mgmt_beacon,
there is no need to make again the same check for the
IEEE80211_HW_PS_NULLFUNC_STACK twice; the two ifs can
be consolidated.
Signed-off-by: NRami Rosen <ramirose@gmail.com>
[reword commit message & break long lines and also
 clean up variable]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There are a number of unused variables that gcc
pointed out (when building with W=1) as well as
some conditions that can never be true due to
the datatypes used: unsigned values can't be
less than zero. Remove this code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some changes to fix issues with HT40 APs in Korea
and follow-up changes to allow using HT40 even if
the local regulatory database disallows it caused
issues with iwlwifi (and could cause issues with
other devices); iwlwifi firmware would assert if
you tried to connect to an AP that has an invalid
configuration (e.g. using HT40- on channel 140.)

Fix this, while avoiding the "Korean AP" issue by
disabling HT40 and advertising HT20 to the AP
when connecting.

Cc: stable@vger.kernel.org [3.6]
Reported-by: NFlorian Reitmeir <florian@reitmeir.org>
Tested-by: NFlorian Reitmeir <florian@reitmeir.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Save the AP's VHT capabilities (in managed
mode) and make them available to the driver
in the station information.

Unlike HT capabilities, they aren't restricted
to the common capabilities, so drivers must be
aware of their own capabilities.
Signed-off-by: NMahesh Palivela <maheshp@posedge.com>
[fix endian conversion bug ...]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Rename struct ieee80211_vht_capabilities to ieee80211_vht_cap
and renamed its member vht_capabilities_info to vht_cap_info.
Signed-off-by: NMahesh Palivela <maheshp@posedge.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

SAE uses two rounds of Authentication frames and both rounds require
considerable calculation to be done. This commit extends the existing
station mode authentication request to allow more control for user
space programs to build the SAE fields and to run the authentication
step ones. Only the second round with authentication transaction
sequence 2 will result in moving to authenticated state.
Signed-off-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is useful when debugging authentication process issues.
Signed-off-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Non-zero status code may be needed for Authentication frames, e.g.,
when using SAE.
Signed-off-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

On each channel that the device is operating on, it
may need to listen using one or more chains depending
on the SMPS settings of the interfaces using it. The
previous channel context changes completely removed
this ability (before, it was available as the SMPS
mode).

Add per-context tracking of the required static and
dynamic RX chains and notify the driver on changes.
To achieve this, track the chains and SMPS mode used
on each virtual interface and update the channel
context whenever this changes.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of operating on a single channel only,
use the new channel context infrastructure in
all mac80211 code.

This enables drivers that want to use the new
channel context infrastructure to use multiple
channels, while nothing should change for all
the other drivers that don't support it.

Right now this disables both TX power settings
and spatial multiplexing powersave. Both need
to be re-enabled on a channel context basis.

Additionally, when channel contexts are used
drop the connection when channel switch is
received rather than trying to handle it. This
will have to be improved later.

[With fixes from Eliad and Emmanuel incorporated]
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Avoid situation when we are on associate state in mac80211 and
on disassociate state in cfg80211. This can results on crash
during modules unload (like showed on this thread:
http://marc.info/?t=134373976300001&r=1&w=2) and possibly other
problems.
Reported-by: NPedro Francisco <pedrogfrancisco@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When we disassociate, it's not really useful to
send delBA action frames since we're going to send
disassoc/deauth anyway, so change that.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Make the function acquire the necessary mutex itself
to simplify the callers.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently, mac80211 uses the power constraint IE, and reduces
the regulatory max TX power by it. This can cause issues if
the AP is advertising a large power constraint value matching
a high TX power in its country IE, for example in this case:

...
Country: US  Environment: Indoor/Outdoor
    ...
    Channels [157 - 157] @ 30 dBm
    ...
Power constraint: 13 dB
...

What happened here is that our local regulatory TX power is
15 dBm, and gets reduced by 13 dB so we end up with only
2 dBm effective TX power, which is way too low.

Instead, handle the country IE/power constraint IE combined
and restrict our TX power to the max of the regulatory power
and the maximum power advertised by the AP, in this case
17 dBm (= 30 dBm - 13 dB).

Also print a message when this happens to let the user know
and help us debug issues with it.
Reported-by: NCarl A. Cook <CACook@quantum-equities.com>
Tested-by: NCarl A. Cook <CACook@quantum-equities.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Move ieee80211_send_deauth_disassoc() to util.c to make it
available for the rest of the mac80211 code.
Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
[reword commit message]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The power constraint IE is always a single byte
so check the size when parsing instead of later.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Disconnect from the AP if channel switching in the
driver failed or if the new channel is unavailable.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

ifmgd->bssid wasn't cleared properly in some
auth/assoc failure cases, causing mac80211 and
the low-level driver to go out of sync.

Clear ifmgd->bssid on failure, and notify the driver.

Cc: stable@kernel.org # 3.4+
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In multi-channel scenarios, the channel that we will
transmit a probe request on isn't always the current
channel (which will be NULL anyway) but will instead
be the channel that the AP is on. Pass the channel
to the ieee80211_send_probe_req() function so it can
be used in the different scenarios. The scan code
continues to pass the current channel, of course.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no need to declare the function in the
header file since it's only used in a single
place, so make it static.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The channel switch IE has a fixed size, so we can
discard it in parsing if it's not the right size
and use the right struct pointer.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The time until the channel switch is in TU,
not in milliseconds, so use TU_TO_EXP_TIME()
to correctly program the timer.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Clean up the CSA handling code by moving some
of it out of the if and using a C99 initializer
for the struct passed to the driver method.

While at it, also add a comment that we should
wait for a beacon after switching the channel.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>