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>

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>

Make the function acquire the necessary mutex itself
to simplify the callers.
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>

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>

After cfg80211 got a P2P Device abstraction, add
support to mac80211. Whether it really is supported
or not will depend on whether or not the driver has
support for it, but mac80211 needs to change to be
able to support drivers that need a P2P Device.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In order to support using a different MAC address
for the P2P Device address we must first have a
P2P Device abstraction that can be assigned a MAC
address.

This abstraction will also be useful to support
offloading P2P operations to the device, e.g.
periodic listen for discoverability.

Currently, the driver is responsible for assigning
a MAC address to the P2P Device, but this could be
changed by allowing a MAC address to be given to
the NEW_INTERFACE command.

As it has no associated netdev, a P2P Device can
only be identified by its wdev identifier but the
previous patches allowed using the wdev identifier
in various APIs, e.g. remain-on-channel.
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>

When sending probe requests, e.g. during software scanning,
these will go out on the *current* channel, so their IEs
need to be built from the current channel. At other times,
e.g. for beacons or probe request templates, the IEs will
be used on the *operating* channel and using the current
channel instead might result in errors.

Add the appropriate parameters to respect the difference.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Using hw.conf.channel is wrong as it could be the
temporary channel if any function like the beacon
get function is called while scanning or during
other temporary out-of-channel activities.

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

Currently, ps mode is indicated per device (rather than
per interface), which doesn't make a lot of sense.

Moreover, there are subtle bugs caused by the inability
to indicate ps change along with other changes
(e.g. when the AP deauth us, we'd like to indicate
CHANGED_PS | CHANGED_ASSOC, as changing PS before
notifying about disassociation will result in null-packets
being sent (if IEEE80211_HW_SUPPORTS_DYNAMIC_PS) while
the sta is already disconnected.)

Keep the current per-device notifications, and add
parallel per-vif notifications.

In order to keep it simple, the per-device ps and
the per-vif ps are orthogonal - the per-vif ps
configuration is determined only by the user
configuration (enable/disable) and the connection
state, and is not affected by other vifs state and
(temporary) dynamic_ps/offchannel operations
(unlike per-device ps).
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the virtual monitor interface is requested
by the driver, it should also be iterated over
when the driver wants to iterate all active
interfaces.

To allow that protect it with the iflist_mtx.

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

The function building probe-request IEs does not validate the band is
supported before dereferencing it. This can result in a panic when
all bands are traversed, as done during sched-scan start.

Warn when this happens and return an empty probe request. Also fix
sched-scan to not waste memory on unsupported bands.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Larry (and some others I think) reported that with
single-queue drivers mac80211 crashes when waking
the queues. This happens because we allocate just
a single queue for each virtual interface in case
the driver doesn't have at least 4 queues, but the
code stopping/waking the virtual interface queues
wasn't taking this into account.
Reported-by: NLarry Finger <Larry.Finger@lwfinger.net>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the interfaces were removed just before a restart
work was started, open_count will be 0, and most of
the reconfig work will be skipped, including the
resetting of local->in_reconfig to false.

Leaving local->inconfig = true will result in
dropping any incoming packet.

Fix it by always setting local->in_reconfig = false
(even if there are no active interfaces).
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Insert the VHT capability IE into probe requests.
Signed-off-by: NMahesh Palivela <maheshp@posedge.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This and ieee80211_add_ext_srates_ie() aren't
exported, so can't be used by drivers anyway,
but there's also no reason that they should be
so make them private to mac80211 and use sdata
instead of vif arguments.
Acked-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

While HW reconfig is in progress, drop all incoming Rx. This prevents
incoming packets from changing the internal state of the driver or
calling callbacks of the low level driver while it is in inconsistent
state.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When performing a HW restart for an AP mode interface, add stations back
only after the AP is beaconing. This mimics the normal flow of STA
addition on AP.

Some devices (wlcore) do not support adding stations before beaconing,
so this has the added benefit of making recovery work for them.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For each EDCA TX queue change default settings (in STA mode) to conform
old 802.11b/g channel access rules. This is needed for drivers that do
not have QoS enable/disable "switch" (like rt2x00) to make them work
properly with legacy APs.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As part of hardware reconfig mac80211 tries
to restore the station state to its values
before the hardware reconfig, but it only
goes to the last-state - 1. Fix this
off-by-one error.

Cc: stable@kernel.org [3.4]
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

WLAN_STA_BLOCK_BA is set while suspending but doesn't get cleared
when resuming in case of wowlan. This causes further ADDBA requests
received to be rejected. Fix it by clearing it in the wowlan path
as well.
Signed-off-by: NEyal Shapira <eyal@wizery.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
Reviewed-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Average beacon signal only keep tracked by managed interface,
give warning and return 0 for the others.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_ave_rssi need to be declare as export for driver to use it.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

According to IEEE 802.11 8.4.2.59, set the "STA channel width" bit to 0
if transmitting STA is using a 20mhz channel.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add utility function to provide the average rssi per vif
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Removes hw.conf.channel usage from the following functions:
 * ieee80211_mandatory_rates
 * ieee80211_sta_get_rates
 * ieee80211_frame_duration
 * ieee80211_rts_duration
 * ieee80211_ctstoself_duration

This is in preparation for multi-channel operation.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 currently only supports one hardware queue
per AC. This is already problematic for off-channel
uses since if we go off channel while the BE queue
is full and then try to send an off-channel frame
the frame will never go out. This will become worse
when we support multi-channel since then a queue on
one channel might be full, but we have to stop the
software queue for all channels. That is obviously
not desirable.

To address this problem allow drivers to register
more hardware queues, and allow them to map them to
virtual interfaces. When they stop a hardware queue
the corresponding AC software queues on the correct
interfaces will be stopped as well. Additionally,
there's an off-channel queue to solve that problem
and a per-interface after-DTIM beacon queue. This
allows drivers to manage software queues closer to
how the hardware works.

Currently, there's a limit of 16 hardware queues.
This may or may not be sufficient, we can adjust it
as needed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The queue mapping redesign that I'm planning to do
will break pure injection unless we handle monitor
interfaces explicitly. One possible option would
be to have the driver tell mac80211 about monitor
mode queues etc., but that would duplicate the API
since we already need to have queue assignments
handled per virtual interface.

So in order to solve this, have a virtual monitor
interface that is added whenever all active vifs
are monitors. We could also use the state of one
of the monitor interfaces, but managing that would
be complicated, so allocate separate state.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Basic rates are added with supported rates IE and extended supported
rates IE.
Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When adding pending SKBs there's no need to
stop all queues, we only need to stop those
that we're adding frames to. Implement that
by lazily stopping a queue as we add an SKB.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the queue status changes we need to do a fair
bit of work, so ignore no-op changes early.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Drivers that don't support QoS also don't support
setting up their ACs, catch that early. While at
it, remove the input check since cfg80211 does it
now.

Also fix up the restart code to not try to set up
the queues in this case.

Finally also change the tx_conf array to have
IEEE80211_NUM_ACS entries instead of # of queues
since that's what it really needs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use the AC constants instead of hard-coding
the numbers with comments.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>