No need for ERR_PTR(PTR_ERR()) since there's ERR_CAST, use it.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In order to be able to (securely) keep connections alive after
the system was suspended for WoWLAN, we need some additional
APIs. We already have API (ieee80211_gtk_rekey_notify) to tell
wpa_supplicant about the new replay counter if GTK rekeying
was done by the device while the host was asleep, but that's
not sufficient.

If GTK rekeying wasn't done, we need to tell the host about
sequence counters for the GTK (and PTK regardless of rekeying)
that was used while asleep, add ieee80211_set_key_rx_seq() for
that.

If GTK rekeying was done, then we need to be able to disable
the old keys (with ieee80211_remove_key()) and allocate the
new GTK key(s) in mac80211 (with ieee80211_gtk_rekey_add()).

If protocol offload (e.g. ARP) is implemented, then also the
TX sequence counter for the PTK must be updated, using the new
ieee80211_set_key_tx_seq() function.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

mac80211 and the Intel drivers all define crypto
constants, move them to ieee80211.h instead.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of calling synchronize_net() for every key
on an interface or when a station is removed, do it
only once for all keys in both of these cases.

As a side-effect, removing station keys now always
calls synchronize_net() even if there are no keys,
which fixes an issue with station removal happening
in the driver while the station could still be used
for TX.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some key function don't exist without underscores, so
remove the underscores from those.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a key is allocated but not really added, there's no
need to go through the entire teardown process. Also, if
adding a key fails, ieee80211_key_link() can take care of
freeing it instead of the (only) caller.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.

To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.

Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.

(*) it starts at 0 because HW crypto is on, then goes to
    1 when HW crypto is disabled for a key, then back to
    0 because the key is deleted; this happens for both
    keys in the example. When new keys are added, it goes
    to 1 first because they're added in software; when a
    key is moved to hardware it goes back to 0
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no driver using this flag, so it seems
that all drivers support HW crypto with WMM or
don't support it at all. Remove the flag and
code setting it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since now we disconnect before suspend, various code which save
connection state can now be removed from suspend and resume
procedure. Cleanup on resume side is smaller as ieee80211_reconfig()
is also used for H/W restart.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There are hardwares which support offload of data packets
for example when auto ARP is enabled the hw will send
the ARP response. In such cases if WEP encryption is
configured the hw must know the default WEP key in order
to encrypt the packets correctly.

When hw_accel is enabled and encryption type is set to WEP,
the driver should get the default key index from mac80211.
Signed-off-by: NYoni Divinsky <yoni.divinsky@ti.com>
[cleanups, fixes, documentation]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Introduce IEEE80211_NUM_TIDS in the generic 802.11
header file and use it in place of STA_TID_NUM and
NUM_RX_DATA_QUEUES which are both really the number
of TIDs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of hardcoding its value (6), use the constant.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

__ieee80211_key_destroy() calls synchronize_rcu() in
order to sync the tx path before destroying the key.

However, synching the tx path can be done with
synchronize_net() as well, which is usually faster
(the timing might be important for roaming scenarios).
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This API call was intended to be used by drivers
if they want to optimize key handling by removing
one key when another is added. Remove it since no
driver is using it. If needed, it can always be
added back.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There are a few things that make the logging and
debugging in mac80211 less useful than it should
be right now:
 * a lot of messages should be pr_info, not pr_debug
 * wholesale use of pr_debug makes it require *both*
   Kconfig and dynamic configuration
 * there are still a lot of ifdefs
 * the style is very inconsistent, sometimes the
   sdata->name is printed in front

Clean up everything, introducing new macros and
separating out the station MLME debugging into
a new Kconfig symbol.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some files implicitly get this via mesh.h
which itself doesn't need it, so move the
inclusion into the right files. Some other
files don't need it at all but include it,
so remove it from there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If a station couldn't be uploaded to the driver but
is still kept (only in IBSS mode) we still shouldn't
try to program the keys for it into hardware; fix
this bug by skipping the key upload in this case.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Setting keys and updating TKIP keys must use the
BSS sdata (not AP_VLAN), so we translate. Move
the translation into driver-ops wrappers instead
of having it inline in the code to simplify the
normal code flow.

The same can be done for sta_add/remove which
already does the translation in the wrapper.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some cards can generate CCMP IVs in HW, but require the space for the IV
to be pre-allocated in the frame at the correct offset. Add a key flag
that allows us to achieve this.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These files are non modular, but need to export symbols using
the macros now living in export.h -- call out the include so
that things won't break when we remove the implicit presence
of module.h from everywhere.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

The flaglock in struct sta_info has long been
something that I wanted to get rid of, this
finally does the conversion to atomic bitops.

The conversion itself is straight-forward in
most places, a few things needed to change a
bit since we can no longer use multiple bits
at the same time.

On x86-64, this is a fairly significant code
size reduction:
   text	   data	    bss	    dec	    hex
 427861	  23648	   1008	 452517	  6e7a5	before
 425383	  23648	    976	 450007	  6ddd7	after
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_iter_keys() currently returns keys in
the backward order they were installed in, which
is a bit confusing. Add them to the tail of the
key list to make sure iterations go in the same
order that keys were originally installed in.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In order to implement GTK rekeying, the device needs
to be able to encrypt frames with the right PN/IV and
check the PN/IV in RX frames. To be able to tell it
about all those counters, we need to be able to get
them from mac80211, this adds the required API.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.

Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.

To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.

Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.

Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds the necessary mac80211 APIs to support
GTK rekey offload, mirroring the functionality
from cfg80211.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When in suspend/wowlan, devices might implement crypto
offload differently (more features), and might require
reprogramming keys for the WoWLAN (as it is the case
for Intel devices that use another uCode image). Thus
allow the driver to iterate all keys in this context.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Based on inputs from Johannes Berg <johannes@sipsolutions.net>
from http://article.gmane.org/gmane.linux.kernel.wireless.general/68193
and http://article.gmane.org/gmane.linux.kernel.wireless.general/71702

In xmit path, devices that do full hardware crypto (including
MMIC and ICV) need no tailroom. For such devices, tailroom
reservation can be skipped if all the keys are programmed into
the hardware (i.e software crypto is not used for any of the
keys) and none of the keys wants software to generate Michael
MIC and IV.

v2: Added check for IV along with MMIC.
Reported-by: NFabio Rossi <rossi.f@inwind.it>
Tested-by: NFabio Rossi <rossi.f@inwind.it>
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Cc: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>

v3: Fixing races to avoid WARNING: at net/mac80211/wpa.c:397
    ccmp_encrypt_skb+0xc4/0x1f0
Reported-by: NAndreas Hartmann <andihartmann@01019freenet.de>
Tested-by: NAndreas Hartmann <andihartmann@01019freenet.de>

v4: Added links with message ID
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit aac6af55.

Conflicts:

	net/mac80211/key.c

That commit has a race that causes a warning, as documented in the thread
here:

	http://marc.info/?l=linux-wireless&m=130717684914101&w=2Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds sparse RCU annotations to most of
mac80211, only the mesh code remains to be
done.

Due the the previous patches, the annotations
are pretty simple. The only thing that this
actually changes is removing the RCU usage of
key->sta in debugfs since this pointer isn't
actually an RCU-managed pointer (it only has
a single assignment done before the key even
goes live). As that is otherwise harmless, I
decided to make it part of this patch.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The code in ieee80211_del_key() doesn't acquire the
key_mtx properly when it dereferences the keys. It
turns out that isn't actually necessary since the
key_mtx itself seems to be redundant since all key
manipulations are done under the RTNL, but as long
as we have the key_mtx we should use it the right
way too.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The devices that require IV generation in software need tailroom
reservation  for ICVs used in TKIP or WEP encryptions.
Currently, decision to skip the tailroom reservation in the tx
path was taken only on whether driver wants MMIC to be generated
in software or not. Following patch appends IV generation check for
such decisions and fixes the following warning.

WARNING: at net/mac80211/wep.c:101 ieee80211_wep_add_iv+0x56/0xf3()
Hardware name: 64756D6
Modules linked in: ath9k ath9k_common ath9k_hw
Pid: 0, comm: swapper Tainted: G        W   2.6.39-rc5-wl
 Call Trace:
[<c102fd29>] warn_slowpath_common+0x65/0x7a
[<c1465c4e>] ? ieee80211_wep_add_iv+0x56/0xf3
[<c102fd4d>] warn_slowpath_null+0xf/0x13
[<c1465c4e>] ieee80211_wep_add_iv+0x56/0xf3
[<c1466007>] ieee80211_crypto_wep_encrypt+0x63/0x88
[<c1478bf3>] ieee80211_tx_h_encrypt+0x2f/0x63
[<c1478cba>] invoke_tx_handlers+0x93/0xe1
[<c1478eda>] ieee80211_tx+0x4b/0x6d
[<c147907c>] ieee80211_xmit+0x180/0x188
[<c147779d>] ? ieee80211_skb_resize+0x95/0xd9
[<c1479edf>] ieee80211_subif_start_xmit+0x64f/0x668
[<c13956fc>] dev_hard_start_xmit+0x368/0x48c
[<c13a8bd6>] sch_direct_xmit+0x4d/0x101
[<c1395ae1>] dev_queue_xmit+0x2c1/0x43f
[<c13a74a2>] ? eth_header+0x1e/0x90
[<c13a7400>] ? eth_type_trans+0x91/0xc2
[<c13a7484>] ? eth_rebuild_header+0x53/0x53
[<c139f079>] neigh_resolve_output+0x223/0x27e
[<c13c6b23>] ip_finish_output2+0x1d4/0x1fe
[<c13c6bc6>] ip_finish_output+0x79/0x7d
[<c13c6cbe>] T.1075+0x43/0x48
[<c13c6e6e>] ip_output+0x75/0x7b
[<c13c4970>] dst_output+0xc/0xe
[<c13c62c9>] ip_local_out+0x17/0x1a
[<c13c67bb>] ip_queue_xmit+0x2aa/0x2f8
[<c138b742>] ? sk_setup_caps+0x21/0x92
[<c13d95ea>] ? __tcp_v4_send_check+0x7e/0xb7
[<c13d5d2e>] tcp_transmit_skb+0x6a1/0x6d7
[<c13d533b>] ? tcp_established_options+0x20/0x8b
[<c13d6f28>] tcp_retransmit_skb+0x43a/0x527
[<c13d8d6d>] tcp_retransmit_timer+0x32e/0x45d
[<c13d8f23>] tcp_write_timer+0x87/0x16c
[<c103a030>] run_timer_softirq+0x156/0x1f9
[<c13d8e9c>] ? tcp_retransmit_timer+0x45d/0x45d
[<c1034d65>] __do_softirq+0x97/0x14a
[<c1034cce>] ? irq_enter+0x4d/0x4d

Cc: Yogesh Powar <yogeshp@marvell.com>
Reported-by: NFabio Rossi <rossi.f@inwind.it>
Tested-by: NFabio Rossi <rossi.f@inwind.it>
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In xmit path, devices that do full hardware crypto (including
TKIP MMIC) need no tailroom. For such devices, tailroom
reservation can be skipped if all the keys are programmed into
the hardware (i.e software crypto is not used for any of the
keys) and none of the keys wants software to generate Michael
MIC.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch moves 'key' dereference after BUG_ON(!key) so that when key is NULL
we will see proper trace instead of oops.
Signed-off-by: NMariusz Kozlowski <mk@lab.zgora.pl>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ieee80211_key struct can be kfree()d several times in the function, for
example if some of the key setup functions fails beforehand, but there's no
check if the struct is still valid before we call memcpy() and INIT_LIST_HEAD()
on it.  In some cases (like it was in my case), if there's missing aes-generic
module it could lead to the following kernel OOPS:

	Unable to handle kernel NULL pointer dereference at virtual address 0000018c
	....
	PC is at memcpy+0x80/0x29c
	...
	Backtrace:
	[<bf11c5e4>] (ieee80211_key_alloc+0x0/0x234 [mac80211]) from [<bf1148b4>] (ieee80211_add_key+0x70/0x12c [mac80211])
	[<bf114844>] (ieee80211_add_key+0x0/0x12c [mac80211]) from [<bf070cc0>] (__cfg80211_set_encryption+0x2a8/0x464 [cfg80211])
Signed-off-by: NPetr Štetiar <ynezz@true.cz>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The key documentation is slightly out of date, fix
that. Also, the list entry in the key struct is no
longer used that way, so list_del_init() isn't
necessary any more there.

Finally, ieee80211_key_link() is no longer invoked
under RCU read lock, but rather with an appropriate
station lock held.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit ad0e2b5a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jun 1 10:19:19 2010 +0200

    mac80211: simplify key locking

removed the synchronization against RCU and thus
opened a race window where we can use a key for
TX while it is already freed. Put a synchronisation
into the right place to close that window.
Reported-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: stable@kernel.org [2.6.36+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add support for split default keys (unicast
and multicast) in mac80211.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When using AP VLAN interfaces, each VLAN interface should be in its own
broadcast domain. Hostapd achieves this by assigning different GTKs to
different AP VLAN interfaces.

However, mac80211 drivers are not aware of AP VLAN interfaces and as
such mac80211 sends the GTK to the driver in the context of the base AP
mode interface. This causes problems when multiple AP VLAN interfaces
are used since the driver will use the same key slot for the different
GTKs (there's no way for the driver to distinguish the different GTKs
from different AP VLAN interfaces). Thus, only the clients associated
to one AP VLAN interface (the one that was created last) can actually
use broadcast traffic.

Fix this by not programming any GTKs for AP VLAN interfaces into the hw
but fall back to using software crypto. The GTK for the underlying AP
interface is still sent to the driver.

That means, broadcast traffic to stations associated to an AP VLAN
interface is encrypted in software whereas broadcast traffic to
stations associated to the non-VLAN AP interface is encrypted in
hardware.

Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds API to allow adding per-station GTKs,
updates mac80211 to support it, and also allows
drivers to remove a key from hwaccel again when
this may be necessary due to multiple GTKs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of using a WARN_ON(!mutex_is_locked())
use lockdep_assert_held() which compiles away
completely when lockdep isn't enabled, and
also is a more accurate assertion since it
checks that the current thread is holding the
mutex.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>