Just clarify that the delay is only before the first cycle.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Stop scan before authentication or association to make sure
that nothing interferes with connection flow.

Currently mac80211 defers RX auth and assoc packets (among other ones)
until after the scan is complete, so auth during scan is likely to fail
if scan took too much time.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Pass the initial net-detect delay (NL80211_ATTR_SCHED_SCAN_DELAY)
attribute in the WoWLAN info response.

Additionally, remove a bogus TODO comment.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This can allow the driver to take action based on the reason
of the deauth.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This can allow the driver to take action based on the
success / failure of the association.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This can allow the driver to take action based on the
success / failure of the authentication.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

We will be able to add more events, such as MLME events and
others. The low level driver may be interested in knowing
about these events to dump firmware data upon failures, or
to change parameters in case connection attempts fail etc...
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The rate control locking caused a potential deadlock here due to the
locks being acquired in different orders, so that change cannot yet
be applied. However, there's no fundamental reason for this code to
hold the sta->lock while transmitting frames.

Clearly it's better not to hold the lock for longer periods of time,
which can happen here since we call all the way down to the driver.
Change the code a bit to not hold it while doing that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This helps debug issues with VLAN modifications that are otherwise
not really visible in any tracing/debugging.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Instead of looking up the destination station twice in the TX path
(first to build the header, and then for control processing), save
it when building the header and use it later in the TX path.

To avoid having to look up the station in the many callers, allow
those to pass %NULL which keeps the existing lookup.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In ieee80211_build_hdr(), the station is looked up to build the
header correctly (QoS field) and to check for authorization. For
mesh, authorization isn't checked here, and QoS capability is
mandatory, so the station lookup can be avoided.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If there's no station on the 4-addr VLAN interface, then frames
cannot be transmitted. Drop such frames earlier, before setting
up all the information for them.

We should keep the old check though since that code might be used
for other internally-generated frames.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There's no need to look up the destination station twice while
building the 802.11 header for a given frame if the frame will
actually be transmitted to the station we initially looked up.

This happens for 4-addr VLAN interfaces and TDLS connections, which
both directly send the frame to the station they looked up, though
in the case of TDLS some station conditions need to be checked.

To avoid that, add a variable indicating that we've looked up the
station that the frame is going to be transmitted to, and avoid the
lookup/flag checking if it already has been done.

In the TDLS case, also move the authorized/wme_sta flag assignment
to the correct place, i.e. only when that station is really used.
Before this change, the new lookup should always have succeeded so
that the potentially erroneous data would be overwritten.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This mechanism was historic, and only ever used by IBSS, which
also doesn't need to have it as it properly manages station's
802.1X PAE state (or, with WEP, always has a key.)

Remove the mechanism to clean up the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When a key is installed using a cipher scheme, set a new
internal key flag (KEY_FLAG_CIPHER_SCHEME) on it, to allow
distinguishing such keys more easily.

In particular, use this flag on the TX path instead of
testing the sta->cipher_scheme pointer, as the station is
NULL for broad-/multicast message, and use the key's iv_len
instead of the cipher scheme information.
Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com>
[add missing documentation, rewrite commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Put station specific code in ieee80211_update_sta_info
function.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

On very high MCS bitrates, the calculated duration of rates that are
next to each other can be very imprecise, due to the small packet size
used as reference (1200 bytes).
This is most visible in VHT80 nss=2 MCS8/9, for which minstrel shows the
same throughput when the probability is also the same. This leads to a
bad rate selection for such rates.

Fix this issue by introducing an average A-MPDU size factor into the
calculation.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

It is possible that there are several regulatory requests
pending, but the processing of the last one does not call
CRDA, and thus the other requests are not handled.

Fix this by rescheduling the work until all requests have
been processed.
Signed-off-by: Ben Rosenfeld <ben.rosenfeld@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Currently when TDLS station in driver goes from authenticated
to associated state it can not use rate control parameters
because rate control is not initialized yet. Some drivers
require parameters already initialized by rate control when
entering associated state. It can be done by initializing
rate control after station transition to associated state but
before notifying driver about that.
Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
[fix comment to say 'associated' instead of 'authorized']
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The schedule_work()/mutex unlocking code is duplicated many times,
refactor that to a common place in the function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This will allow mac80211 drivers to call cfg80211 APIs with
the right handle.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Add a comment explaining how the RX path lock is used.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Move the netdev stats accounting into the common function
ieee80211_deliver_skb() that is called in both places.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Timeout was scheduled only in case CRDA was called due to user hints,
but was not scheduled for other cases. This can result in regulatory
hint processing getting stuck in case that there is no CRDA configured.

Change this by scheduling a timeout every time CRDA is called. In
addition, in restore_regulatory_settings() all pending requests are
restored (and not only the user ones).
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Acked-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Previously, the indoor setting configuration assumed that as
long as a station interface is connected, the indoor environment
setting does not change. However, this assumption is problematic
as:

- It is possible that a station interface is connected to a mobile
  AP, e.g., softAP or a P2P GO, where it is possible that both the
  station and the mobile AP move out of the indoor environment making
  the indoor setting invalid. In such a case, user space has no way to
  invalidate the setting.
- A station interface disconnection does not necessarily imply that
  the device is no longer operating in an indoor environment, e.g.,
  it is possible that the station interface is roaming but is still
  stays indoor.

To handle the above, extend the indoor configuration API to allow
user space to indicate a change of indoor settings, and allow it to
indicate weather it controls the indoor setting, such that:

1. If the user space process explicitly indicates that it is going
   to control the indoor setting, do not clear the indoor setting
   internally, unless the socket is released. The user space process
   should use the NL80211_ATTR_SOCKET_OWNER attribute in the command
   to state that it is going to control the indoor setting.
2. Reset the indoor setting when restoring the regulatory settings in
   case it is not owned by a user space process.

Based on the above, a user space tool that continuously monitors the
indoor settings, i.e., tracking power setting, location etc., can
indicate environment changes to the regulatory core.

It should be noted that currently user space is the only provided mechanism
used to hint to the regulatory core over the indoor/outdoor environment --
while the country IEs do have an environment setting this has been completely
ignored by the regulatory core by design for a while now since country IEs
typically can contain bogus data.
Acked-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: ArikX Nemtsov <arik@wizery.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Directly update the indoor setting without wrapping it as
a regulatory request, to simplify the processing.
Acked-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Jouni reported that certain combinations of hwsim test cases failed,
and we found that beaconing was erroneously enabled too early on any
channel switch, which lead to the BI of 2000 TU from the first test
case to leak into the second one, which then didn't beacon properly.

To fix this, set data->beacon_int to zero when all stop beaconing so
that beaconing cannot be started (which was intended as 'restarted')
elsewhere.

Additionally, Jouni found that due to this 'restart' and the beacon
interval handling station interfaces would also have a needlessly
running beacon timer all the time, of course not doing anything.

To also fix the latter case only use the beacon interval when it's
actually needed, i.e. when beaconing gets enabled.
Reported-by: Jouni Malinen <j@w1.fi>
Tested-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

timeout was being passed as int but assigned from u32/u16 values and used
as unsigned type. This is really only for better readability.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This is primarily an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var) which also handles
corner cases correctly.

There is a change of behavior as e.g. for HZ 100, t * HZ / 1000 will
return 0 for t < 10 but msecs_to_jiffies will return at least 1 always.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Some device drivers offload part of aggregation including AddBA/DelBA
negotiations to firmware. In such scenario, the PMF configuration of
the station needs to be provided to driver to enable encryption of
AddBA/DelBA action frames.
Signed-off-by: SenthilKumar Jegadeesan <sjegadee@qti.qualcomm.com>
[fix commit log, documentation]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Sometimes the driver might want to modify private data in interfaces
that are down. One possible use-case is cleaning up interface state
after HW recovery. Some interfaces that were up before the recovery took
place might be down now, but they might still be "dirty".

Introduce a new iterate_interfaces() API and a new ACTIVE iterator flag.
This way the internal implementation of the both active and inactive
APIs remains the same.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If the device supports waking up on 'any' signal - i.e. it continues
operating as usual and wakes up the host on pretty much anything that
happens, then it makes no sense to also configure the more restricted
WoWLAN mode where the device operates more autonomously but also in a
more restricted fashion.

Currently only cw2100 supports both 'any' and other triggers, but it
seems to be broken as it doesn't configure anything to the device, so
we can't currently get into a situation where both even can correctly
be configured. This is about to change (Intel devices are going to
support both and have different behaviour depending on configuration)
so make sure the conflicting modes cannot be configured.

(It seems that cw2100 advertises 'any' and 'disconnect' as a means of
saying that's what it will always do, but that isn't really the way
this API was meant to be used nor does it actually mean anything as
'any' always implies 'disconnect' already, and the driver doesn't
change device configuration in any way depending on the settings.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The ieee80211_tx_prepare_skb() function currently entirely ignores
the fact that the SKB that is passed in might be split into more
than one due to fragmentation and doesn't check the list of skbs
that the TX handlers may create. In case this happens, it would
leak them.

Fix this and also don't leave the skb next/prev pointers dangling
pointing to the on-stack sk_buff_head.
Reported-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In ieee80211_queue_work() we check if we're quiescing or suspended, so
it's not necessary to check for quiescing before calling this
function.  Remove duplicate checks.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

TDLS off-channel can be allowed in channels marked with GO_CONCURRENT,
provided the device is connected to an AP on the same UNII.
When relaxing the NO-IR requirements for TDLS, we might hit flows in
cfg80211_reg_can_beacon that acquire the wdev lock. Take some measures
to allow this during TDLS setup.
Acquire the RCU read lock later in the flow that invokes
cfg80211_reg_can_beacon.
Avoid taking local->mtx when preparing the setup packet to avoid
circular deadlocks with mac80211 code that is invoked with wdev-mtx
held.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If the driver rejects WoWLAN, restart the queues before returning
to cfg80211. cfg80211 will return to mac80211, but not before it
disconnects all interfaces. If we don't start the queues, any of
the packets needed for disconnecting won't be transmitted, which
is strange. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

We check local->open_count at the top of the __ieee80211_suspend(), so
there's no need to check for it again.  open_count is protected by the
rtnl, so there's no chance for it to have change between the two
calls.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Drivers can't really be expected to suspend properly while auth
or assoc is in progress since then they don't have any state
they could keep with WoWLAN, nor can they actually finish the
authentication or association. In fact, keeping this can cause
subtle issues with drivers like iwlwifi that refuse WoWLAN if
not associated, but have trouble figuring out what's going on
in the middle of association.

In any case, regardless of possible driver issues in this area,
it doesn't make sense for mac80211 to try to WoWLAN-suspend in
the middle of such operations, so stop them before.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If any interface fails to be added to the driver in during reconfig,
we should remove all the successfully added interfaces and report
reconfig failure, so things can be cleaned up properly.  Failing to do
so can lead to subsequent failures and leave the drivers in a messed
up state.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Since cfg80211 disconnects, but has no insight into the association
process, it can happen that it disconnects while association is in
progress. We then try to abort association in mac80211, but this is
only later so the association can complete between the two.

This results in removing an interface from the driver while bound
to the channel context, obviously causing confusion and issues.

Solve this by also checking if we're associated during quiesce and
if so deauthenticating. The frame will no longer go out to the AP
which is a bit unfortunate, but it'll resolve the crash (and before
we would have suspended without telling the AP as well.)

I'm working on a better, but more complex solution as well, which
should avoid that problem.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>