When sending authentication/association frames they
might take a bit of time to go out because we may
have to synchronise with the AP, in particular in
the case where it's really a P2P GO. In this case
the 200ms fixed timeout could potentially be too
short if the beacon interval is relatively large.

For drivers that report TX status we can do better.
Instead of starting the timeout directly, start it
only when the frame status arrives. Since then the
frame was out on the air, we can wait shorter (the
typical response time is supposed to be 30ms, wait
100ms.) Also, if the frame failed to be transmitted
try again right away instead of waiting.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently, when the driver requires the DTIM period,
mac80211 will wait to hear a beacon before association.
This behavior is suboptimal since some drivers may be
able to deal with knowing the DTIM period after the
association, if they get it at all.

To address this, notify the drivers with bss_info_changed
with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM
becomes known. This might be when changing to associated,
or later when the entire association was done with only
probe response information.

Rename the hardware flag for the current behaviour to
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately
reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is
no longer accurate as all drivers get the DTIM period
now, just not before association.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the driver's resume function can't completely
restore the configuration in the device, it returns
1 from the callback which will be treated like a HW
restart request, but done directly.

In this case, also call the driver's restart_complete()
function so it can finish the reconfiguration there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

My commit 529ba6e9
("mac80211: clean up association better in suspend")
introduced a bug when resuming from WoWLAN when a
device reset is desired. This case must not use the
suspend_bss_conf as it hasn't been stored.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The initiator/tx doesn't really identify why an
aggregation session is stopped, give a reason
for stopping that more clearly identifies what's
going on. This will help tell the driver clearly
what is expected of it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For AP/IBSS/mesh interfaces, call the driver to reconfigure
bss_info_changed only if the interface was beaconing before
suspend, otherwise we call the driver and it might interpret
the change as going from enabled to disabled.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When suspending, bss_info_changed() is called to
disable beacons, but managed mode interfaces are
simply removed (bss_info_changed() is called with
"no change" only). This can lead to problems.

To fix this and copy the BSS configuration, clear
it during suspend and restore it on resume.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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

Instead of allocating a temporary buffer to build IEs
build them right into the SKB.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of assuming 200 bytes are always enough for
all the IEs we add, give the length of the buffer
to the function and warn instead of overrunning.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the low-level driver wants to support P2P GO
powersave configuration, it must set the cfg80211
flags and mac80211 will pass the parameters to it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add support to mac80211 for having drivers report
received VHT MCS information.
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>

Sujith reported warnings with suspend/resume due to
channel contexts. When I looked into it, I realised
that the code was completely broken as it unassigned
the channel contexts when suspending, which actually
means they are destroyed.

Eliad Peller then pointed out that we also need to
remove the channel contexts from the driver. When I
looked into this, I also noticed that the code isn't
handling the virtual monitor interface correctly (if
it exists.)

Fix this by calling just the driver methods (if they
are implemented) instead of using the channel context
management code. Also add reconfiguration for the
virtual monitor interface.
Reported-by: NSujith Manoharan <sujith@msujith.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

During testing our mac80211 driver a fatal error occurred which was
signalled to mac80211. Upon performing the reconfiguration of the
device a WARN_ON was triggered. This warning checked the return value
of drv_add_chanctx(). However, this returns -EOPNOTSUPP when the
driver does not provide the callback. As the callback is optional
better check it is defined before calling drv_add_chanctx().
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Allow drivers to indicate their mactime is at RX completion and adjust
for this in mac80211. Also rename the existing RX_FLAG_MACTIME_MPDU to
RX_FLAG_MACTIME_START to clarify its intent. Based on similar code by
Johannes Berg.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
[fix docs, atheros drivers]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since channel contexts are usually present before
stations can be added to an interface, reassign
before stations them in reconfiguration as well.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

During hardware restart, all interfaces are iterated even
though they haven't been re-added to the driver, document
this behaviour. The same also happens during resume, which
is even more confusing since all of the interfaces were
previously removed from the driver. Make this optional so
drivers relying on the current behaviour can still use it,
but to let drivers that don't want this behaviour disable
it.

Also convert all API users, keeping the old semantics
except in hwsim, where the new normal ones are desired.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the driver requests a restart (reconfiguration) it
gets all the normal method calls, but can't really tell
why they're happening. Call a new restart_complete op
in the driver when the restart completes, so it could
keep its own state about the restart and clear it there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

On resume or firmware recovery, mac80211 sends a null
data packet to see if the AP is still around and hasn't
disconnected us. However, it always does this even if
it wasn't even connected before, leading to a warning
in the new channel context code. Fix this by checking
that it's associated.

Cc: stable@vger.kernel.org
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
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>

Depending on the driver, a lot of setup may be
necessary to start operating as an AP, some of
which may fail. Add an explicit AP start driver
method to make such failures easier to handle,
and add an AP stop driver method for symmetry.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For a local variable there's no need to use the atomic
set_bit() operation, use __set_bit() instead.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of the current whitelist which accepts duplicates
only for the quiet and vendor IEs, use a blacklist of all
IEs (that we currently parse) that can't be duplicated.

This avoids detecting a beacon as corrupt in the future
when new IEs are added that can be duplicated.

Cc: stable@vger.kernel.org
Signed-off-by: NPaul Stewart <pstew@chromium.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>

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>

Free tx status skbs when draining power save buffers, pending frames, or
when tearing down a vif.
Fixes remaining conditions that can lead to hostapd/wpa_supplicant hangs when
running out of socket write memory.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.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>