16 Aug, 2013
1 commit
-
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: Johannes Berg
17 May, 2013
1 commit
-
mac80211 and the Intel drivers all define crypto
constants, move them to ieee80211.h instead.Reviewed-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
11 Mar, 2013
3 commits
-
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: Johannes Berg
-
Some key function don't exist without underscores, so
remove the underscores from those.Signed-off-by: Johannes Berg
-
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: Johannes Berg
06 Mar, 2013
3 commits
-
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 0Signed-off-by: Johannes Berg
-
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: Johannes Berg
-
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: Stanislaw Gruszka
Signed-off-by: Johannes Berg
18 Jan, 2013
1 commit
-
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: Yoni Divinsky
[cleanups, fixes, documentation]
Signed-off-by: Johannes Berg
19 Nov, 2012
2 commits
-
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: Johannes Berg
-
Instead of hardcoding its value (6), use the constant.
Signed-off-by: Johannes Berg
06 Sep, 2012
1 commit
-
__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: Eliad Peller
Signed-off-by: Johannes Berg
09 Jul, 2012
1 commit
-
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: Johannes Berg
24 Jun, 2012
1 commit
-
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 frontClean up everything, introducing new macros and
separating out the station MLME debugging into
a new Kconfig symbol.Signed-off-by: Johannes Berg
28 Feb, 2012
1 commit
-
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: Johannes Berg
Signed-off-by: John W. Linville
07 Feb, 2012
2 commits
-
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: Johannes Berg
Signed-off-by: John W. Linville -
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: Johannes Berg
Signed-off-by: John W. Linville
18 Nov, 2011
1 commit
-
…wireless-next into for-davem
Conflicts:
include/net/bluetooth/bluetooth.h
09 Nov, 2011
1 commit
-
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: Arik Nemtsov
Signed-off-by: John W. Linville
01 Nov, 2011
1 commit
-
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: Paul Gortmaker
01 Oct, 2011
1 commit
-
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 afterSigned-off-by: Johannes Berg
Signed-off-by: John W. Linville
16 Jul, 2011
1 commit
-
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: Johannes Berg
Signed-off-by: John W. Linville
08 Jul, 2011
2 commits
-
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: Johannes Berg
Signed-off-by: John W. Linville -
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: Johannes Berg
Signed-off-by: John W. Linville
07 Jul, 2011
2 commits
-
This adds the necessary mac80211 APIs to support
GTK rekey offload, mirroring the functionality
from cfg80211.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
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: Johannes Berg
Signed-off-by: John W. Linville
06 Jul, 2011
1 commit
-
Based on inputs from Johannes Berg
from http://article.gmane.org/gmane.linux.kernel.wireless.general/68193
and http://article.gmane.org/gmane.linux.kernel.wireless.general/71702In 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: Fabio Rossi
Tested-by: Fabio Rossi
Signed-off-by: Mohammed Shafi Shajakhan
Cc: Mohammed Shafi Shajakhanv3: Fixing races to avoid WARNING: at net/mac80211/wpa.c:397
ccmp_encrypt_skb+0xc4/0x1f0
Reported-by: Andreas Hartmann
Tested-by: Andreas Hartmannv4: Added links with message ID
Signed-off-by: Yogesh Ashok Powar
Signed-off-by: John W. Linville
07 Jun, 2011
1 commit
-
This reverts commit aac6af5534fade2b18682a0b9efad1a6c04c34c6.
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=2
Signed-off-by: John W. Linville
17 May, 2011
1 commit
-
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: Johannes Berg
Signed-off-by: John W. Linville
13 May, 2011
1 commit
-
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: Johannes Berg
Signed-off-by: John W. Linville
05 May, 2011
1 commit
-
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:
[] warn_slowpath_common+0x65/0x7a
[] ? ieee80211_wep_add_iv+0x56/0xf3
[] warn_slowpath_null+0xf/0x13
[] ieee80211_wep_add_iv+0x56/0xf3
[] ieee80211_crypto_wep_encrypt+0x63/0x88
[] ieee80211_tx_h_encrypt+0x2f/0x63
[] invoke_tx_handlers+0x93/0xe1
[] ieee80211_tx+0x4b/0x6d
[] ieee80211_xmit+0x180/0x188
[] ? ieee80211_skb_resize+0x95/0xd9
[] ieee80211_subif_start_xmit+0x64f/0x668
[] dev_hard_start_xmit+0x368/0x48c
[] sch_direct_xmit+0x4d/0x101
[] dev_queue_xmit+0x2c1/0x43f
[] ? eth_header+0x1e/0x90
[] ? eth_type_trans+0x91/0xc2
[] ? eth_rebuild_header+0x53/0x53
[] neigh_resolve_output+0x223/0x27e
[] ip_finish_output2+0x1d4/0x1fe
[] ip_finish_output+0x79/0x7d
[] T.1075+0x43/0x48
[] ip_output+0x75/0x7b
[] dst_output+0xc/0xe
[] ip_local_out+0x17/0x1a
[] ip_queue_xmit+0x2aa/0x2f8
[] ? sk_setup_caps+0x21/0x92
[] ? __tcp_v4_send_check+0x7e/0xb7
[] tcp_transmit_skb+0x6a1/0x6d7
[] ? tcp_established_options+0x20/0x8b
[] tcp_retransmit_skb+0x43a/0x527
[] tcp_retransmit_timer+0x32e/0x45d
[] tcp_write_timer+0x87/0x16c
[] run_timer_softirq+0x156/0x1f9
[] ? tcp_retransmit_timer+0x45d/0x45d
[] __do_softirq+0x97/0x14a
[] ? irq_enter+0x4d/0x4dCc: Yogesh Powar
Reported-by: Fabio Rossi
Tested-by: Fabio Rossi
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville
29 Apr, 2011
1 commit
-
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: Yogesh Ashok Powar
Signed-off-by: John W. Linville
29 Mar, 2011
2 commits
-
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: Mariusz Kozlowski
Acked-by: Johannes Berg
Signed-off-by: John W. Linville -
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:
[] (ieee80211_key_alloc+0x0/0x234 [mac80211]) from [] (ieee80211_add_key+0x70/0x12c [mac80211])
[] (ieee80211_add_key+0x0/0x12c [mac80211]) from [] (__cfg80211_set_encryption+0x2a8/0x464 [cfg80211])Signed-off-by: Petr Štetiar
Reviewed-by: Johannes Berg
Signed-off-by: John W. Linville
06 Jan, 2011
1 commit
05 Jan, 2011
2 commits
-
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: Johannes Berg
Signed-off-by: John W. Linville -
commit ad0e2b5a00dbec303e4682b403bb6703d11dcdb2
Author: Johannes Berg
Date: Tue Jun 1 10:19:19 2010 +0200mac80211: 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: Jussi Kivilinna
Cc: stable@kernel.org [2.6.36+]
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
14 Dec, 2010
1 commit
-
Add support for split default keys (unicast
and multicast) in mac80211.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
23 Nov, 2010
1 commit
-
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
Signed-off-by: Helmut Schaa
Signed-off-by: John W. Linville
07 Oct, 2010
1 commit
-
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: Johannes Berg
Signed-off-by: John W. Linville