This reverts commit 6d810f10

In this way an IBSS station will not use the AUTH messages
to trigger a state reinitialisation anymore.

The behaviour was racy and was not working properly.
It has been introduced to help wpa_supplicant to support
IBSS/RSN, however all the logic is now getting moved into
wpa_s itself which will also be in charge of handling the
AUTH messages thanks to the mgmt frame registration.

If userspace does not register for receiving AUTH frames
then mac80211 will still reply by itself.

At the same time, the auth frame registration counter can be
removed since it is not needed anymore.
Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
[remove unused variable]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This should make some parts cleaner and is also required for handling
5/10 MHz properly.
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>

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>

Instead of updating the mesh beacon immediately when
requested (which would require the sdata_lock()), defer it
to the mac80211 workqueue.

Fixes yet another deadlock on calling sta_info_flush()
with the sdata_lock() held from ieee80211_stop_mesh(). We
could just drop the sdata_lock() around the
mesh_sta_cleanup() call, but this path is also taken from
several non-locked error paths.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
[fix comment position]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NIlan Peer <ilan.peer@intel.com>
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>

All accesses of the tid_start_tx lock should be protected
by sta->lock if there is any chance that another thread
could still be accessing the sta object.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Ben reports that kmemleak is saying TX aggregation TID
structs are leaked. Given his workload, I suspect that
they're leaked because stations are destroyed before
their aggregation sessions get a chance to start. Fix
this by simply freeing structs that are not used yet.
Reported-by: NBen Greear <greearb@candelatech.com>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The order of parameters was mixed up, introduced in commit
"mac80211: improve the rate control API"

Cc: Felix Fietkau <nbd@openwrt.org>
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>

When a CAC is running and stop_ap is called (e.g. when hostapd is killed
while performing CAC), the CAC must be aborted immediately.
Otherwise ieee80211_stop_ap() will try to stop it when it's too late -
wdev->channel is already NULL and the abort event can not be generated.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
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>

cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case. Fail if offchan is required.
Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
[fix RCU locking]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently mesh uses mandatory rates as the default basic rates. Allow basic
rates to be configured during mesh join. Basic rates are applied only if
channel is also provided with mesh join command.
Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
[some whitespace fixes, refuse basic rates w/o channel]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The time it takes to see the peer link expire may differ
by a minute since sta_expire() is run once a minute as a
mesh housekeeping task.
Signed-off-by: NColleen Twitty <colleen@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The patch "cfg80211/mac80211: use cfg80211 wdev mutex in
mac80211" introduced several deadlocks by converting the
ifmsh->mtx to wdev->mtx. Solve these by:

1. drop the cancel_work_sync() in ieee80211_stop_mesh().
   Instead make the mesh work conditional on whether the mesh
   is running or not.
2. lock the mesh work with sdata_lock() to protect beacon
   updates and prevent races with wdev->mesh_id_len or
   cfg80211.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some kernel-doc fixes for forgotten fields and renamed things.
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>

ieee80211_rx_bss_info() deals with dtim_period setting and PS update
when associated. Move all these to another locations cleaning this
function. Also, the current implementation is buggy because when it
calls ieee80211_recalc_ps() bss_conf->dtim_period is notset properly
yet and thus nothing will happen.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Do some cleanups in the cfg80211 SME APIs, which are
only used by mac80211.

Most of these functions get a frame passed, and there
isn't really any reason to export multiple functions
as cfg80211 can check the frame type instead, do that.

Additionally, the API functions have confusing names
like cfg80211_send_...() which was meant to indicate
that it sends an event to userspace, but gets a bit
confusing when there's both TX and RX and they're not
all clearly labeled.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The connection monitor needs to know the tx status of
nullframes to work properly.
Signed-off-by: NPontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no need to take up the space for devices that don't
support WoWLAN, and most drivers can even make the support
data static const (except where it's modified at runtime.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Cap max peerings at 63 in accordance with IEEE-2012 8.4.2.100.7.
Triggers a beacon regeneration every time the number of peerings changes.
Previously this would only happen if the "accepting peerings" bit changed.
Signed-off-by: NJacob Minshall <jacob@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

nl80211 has already verified the mesh TTL on setting the
mesh config, so no need to check it again in mac80211.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

My cfg80211/mac80211 locking unification broke the sdata
locking in ieee80211_set_power_mgmt, it needs to acquire
the lock for __ieee80211_request_smps(). Add the locking.
Reported-by: NJakub Kicinski <kubakici@wp.pl>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the driver advertised support for a CAB queue, then we
should put all multicast frames there, otherwise sending
them can be racy with clients going to sleep while we TX
a frame. To avoid this, always TX multicast frames on the
multicast queue.

It seems like even drivers not using the queue framework
might want to do this which would mean also moving the
IEEE80211_TX_CTL_SEND_AFTER_DTIM flag assignment, but it
also seems that drivers behave differently here so that
just moving it wouldn't be a good idea. It'd be better to
modify those drivers to use the queue framework.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Support them only if the driver advertises support for them via
IEEE80211_HW_SUPPORTS_ACTIVE_MONITOR. Unlike normal monitor interfaces,
they are added to the driver, along with their MAC address.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When changing the MAC address of a single vif mac80211 will check if
the new address fits into the address mask specified by the driver.
This only needs to be done when using multiple BSSIDs. Hence, check
the new address only against all other vifs.

Also fix the MAC address assignment on new interfaces if the user
changed the address of a vif such that perm_addr is not covered by
addr_mask anymore.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=57371Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJakub Kicinski <kubakici@wp.pl>
Reported-by: NAlessandro Lannocca <alessandro.lannocca@gmail.com>
Cc: Alessandro Lannocca <alessandro.lannocca@gmail.com>
Cc: Bruno Randolf <br1@thinktube.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since Eric's commit efe117ab ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.

Cc: stable@vger.kernel.org [2.6.33+]
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A lot of code in mac80211 assumes that the hw queues are
set up correctly for all interfaces (except for monitor)
but this isn't true for AP_VLAN interfaces. Fix this by
copying the AP master configuration when an AP VLAN is
brought up, after this the AP interface can't change its
configuration any more and needs to be brought down to
change it, which also forces AP_VLAN interfaces down, so
just copying in open() is sufficient.
Reported-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Using separate locks in cfg80211 and mac80211 has always
caused issues, for example having to unlock in places in
mac80211 to call cfg80211, which even needed a framework
to make cfg80211 calls after some functions returned etc.

Additionally, I suspect some issues people have reported
with the cfg80211 state getting confused could be due to
such issues, when cfg80211 is asking mac80211 to change
state but mac80211 is in the process of telling cfg80211
that the state changed (in another way.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Move mandatory rates calculation to cfg80211, shared with non mac80211 drivers.
Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
[extend documentation]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As estab_plinks is not a statistics member, don't show its debug information
along with other mesh stat members
Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some chips can tell us if received frame was
encoded with STBC or not. To make this information available
in user space we can use updated radiotap specification:
http://www.radiotap.org/defined-fields/MCS

This patch will set number of STBC encoded spatial streams (Nss).
The HAVE_STBC flag should be provided by driver.
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since Eric's commit efe117ab ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.

Cc: stable@vger.kernel.org [2.6.33+]
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A lot of code in mac80211 assumes that the hw queues are
set up correctly for all interfaces (except for monitor)
but this isn't true for AP_VLAN interfaces. Fix this by
copying the AP master configuration when an AP VLAN is
brought up, after this the AP interface can't change its
configuration any more and needs to be brought down to
change it, which also forces AP_VLAN interfaces down, so
just copying in open() is sufficient.
Reported-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The code I added in "mac80211: don't start new netdev queues
if driver stopped" crashes for monitor and AP VLAN interfaces
because while they have a netdev, they don't have queues set
up by the driver.

To fix the crash, exclude these from queue accounting here
and just start their netdev queues unconditionally.

For monitor, this is the best we can do, as we can redirect
frames there to any other interface and don't know which one
that will since it can be different for each frame.

For AP VLAN interfaces, we can do better later and actually
properly track the queue status. Not doing this is really a
separate bug though.
Reported-by: NIlan Peer <ilan.peer@intel.com>
Reported-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

We send direct probe to broadcast address, as some APs do not respond to
unicast PROBE frames when unassociated. Broadcast frames are not acked,
so we can not use that for trigger MLME state machine, but we need to
use old timeout mechanism.

This fixes authentication timed out like below:

[ 1024.671974] wlan6: authenticate with 54:e6:fc:98:63:fe
[ 1024.694125] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3)
[ 1024.695450] wlan6: direct probe to 54:e6:fc:98:63:fe (try 2/3)
[ 1024.700586] wlan6: send auth to 54:e6:fc:98:63:fe (try 3/3)
[ 1024.701441] wlan6: authentication with 54:e6:fc:98:63:fe timed out

With fix, we have:

[ 4524.198978] wlan6: authenticate with 54:e6:fc:98:63:fe
[ 4524.220692] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3)
[ 4524.421784] wlan6: send auth to 54:e6:fc:98:63:fe (try 2/3)
[ 4524.423272] wlan6: authenticated
[ 4524.423811] wlan6: associate with 54:e6:fc:98:63:fe (try 1/3)
[ 4524.427492] wlan6: RX AssocResp from 54:e6:fc:98:63:fe (capab=0x431 status=0 aid=1)

Cc: stable@vger.kernel.org # 3.9
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Generally, the DTIM period is available after a beacon has
been received, and if no beacon has been received enabling
powersave is problematic anyway for synchronisation. Since
some drivers may require the DTIM period for powersave,
don't enable powersave until it becomes available in case
the scan/association managed to not receive a beacon.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Previously the mesh_auth_id was disabled.  Instead set the
correct mesh authentication bit based on the mesh setup.
Signed-off-by: NColleen Twitty <colleen@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>