<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/mac80211/tkip.c, branch v3.2.36</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>net: Add export.h for EXPORT_SYMBOL/THIS_MODULE to non-modules</title>
<updated>2011-10-31T23:30:30+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-07-15T15:47:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bc3b2d7fb9b014d75ebb79ba371a763dbab5e8cf'/>
<id>bc3b2d7fb9b014d75ebb79ba371a763dbab5e8cf</id>
<content type='text'>
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 &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: allow driver access to TKIP RX P1K</title>
<updated>2011-07-15T17:38:32+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-07-13T17:50:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8bca5d815311f53ada13b62f5e590df40fef317e'/>
<id>8bca5d815311f53ada13b62f5e590df40fef317e</id>
<content type='text'>
When the driver wants to pre-program the TKIP
RX phase 1 key, it needs to be able to obtain
it for the peer's TA. Add API to allow it to
generate it.

The generation uses a dummy on-stack context
since it doesn't know the RX queue.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When the driver wants to pre-program the TKIP
RX phase 1 key, it needs to be able to obtain
it for the peer's TA. Add API to allow it to
generate it.

The generation uses a dummy on-stack context
since it doesn't know the RX queue.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: allow driver to generate P1K for IV32</title>
<updated>2011-07-08T15:42:23+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-07-07T16:58:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=42d98795505314c7af42c7c6b988425300958ed3'/>
<id>42d98795505314c7af42c7c6b988425300958ed3</id>
<content type='text'>
In order to support pre-populating the P1K cache in
iwlwifi hardware for WoWLAN, we need to calculate
the P1K for the current IV32. Allow drivers to get
the P1K for any given IV32 instead of for a given
packet, but keep the packet-based version around as
an inline.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to support pre-populating the P1K cache in
iwlwifi hardware for WoWLAN, we need to calculate
the P1K for the current IV32. Allow drivers to get
the P1K for any given IV32 instead of for a given
packet, but keep the packet-based version around as
an inline.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix TKIP races, make API easier to use</title>
<updated>2011-07-08T15:11:19+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-07-07T20:28:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=523b02ea23b175dd3e46e3daf1bc9354376640a3'/>
<id>523b02ea23b175dd3e46e3daf1bc9354376640a3</id>
<content type='text'>
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 &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: remove the dependency on crypto_blkcipher</title>
<updated>2011-04-04T20:20:00+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2011-03-25T20:39:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5f9f1812b68a2979bc97399cd4954f1c191986af'/>
<id>5f9f1812b68a2979bc97399cd4954f1c191986af</id>
<content type='text'>
The only thing that using crypto_blkcipher with ecb does over just using
arc4 directly is wrapping the encrypt/decrypt function into a for loop,
looping over each individual character.
To be able to do this, it pulls in around 40 kb worth of unnecessary
kernel modules (at least on a MIPS embedded device).
Using arc4 directly not only eliminates those dependencies, it also makes
the code smaller.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The only thing that using crypto_blkcipher with ecb does over just using
arc4 directly is wrapping the encrypt/decrypt function into a for loop,
looping over each individual character.
To be able to do this, it pulls in around 40 kb worth of unnecessary
kernel modules (at least on a MIPS embedded device).
Using arc4 directly not only eliminates those dependencies, it also makes
the code smaller.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: remove wep dependency</title>
<updated>2010-07-08T20:35:50+00:00</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2010-07-07T19:07:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3473187d2459a078e00e5fac8aafc30af69c57fa'/>
<id>3473187d2459a078e00e5fac8aafc30af69c57fa</id>
<content type='text'>
The current mac80211 code assumes that WEP is always available.  If WEP
fails to initialize, ieee80211_register_hw will always fail.

In some cases (e.g. FIPS certification), the cryptography used by WEP is
unavailable.  However, in such cases there is no good reason why CCMP
encryption (or even no link level encryption) cannot be used.  So, this
patch removes mac80211's assumption that WEP (and TKIP) will always be
available for use.

Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current mac80211 code assumes that WEP is always available.  If WEP
fails to initialize, ieee80211_register_hw will always fail.

In some cases (e.g. FIPS certification), the cryptography used by WEP is
unavailable.  However, in such cases there is no good reason why CCMP
encryption (or even no link level encryption) cannot be used.  So, this
patch removes mac80211's assumption that WEP (and TKIP) will always be
available for use.

Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: pass vif and station to update_tkip_key</title>
<updated>2010-01-22T21:08:55+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes@sipsolutions.net</email>
</author>
<published>2010-01-21T10:40:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b3fbdcf49f940d0703c356441e0daf045e64e076'/>
<id>b3fbdcf49f940d0703c356441e0daf045e64e076</id>
<content type='text'>
When a TKIP key is updated, we should pass the station
pointer instead of just the address, since drivers can
use that to store their own data. We also need to pass
the virtual interface pointer.

Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a TKIP key is updated, we should pass the station
pointer instead of just the address, since drivers can
use that to store their own data. We also need to pass
the virtual interface pointer.

Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: move control.hw_key assignment</title>
<updated>2010-01-19T21:25:19+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes@sipsolutions.net</email>
</author>
<published>2010-01-17T00:47:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=813d76694043d00b59475baa1fbfaf54a2eb7fad'/>
<id>813d76694043d00b59475baa1fbfaf54a2eb7fad</id>
<content type='text'>
When mac80211 asks a driver to encrypt a frame, it
must assign the control.hw_key pointer for it to
know which key to use etc. Currently, mac80211 does
this whenever it would software-encrypt a frame.

Change the logic of this code to assign the hw_key
pointer when selecting the key, and later check it
when deciding whether to encrypt the frame or let
it be encrypted by the hardware. This allows us to
later simply skip the encryption function since it
no longer modifies the TX control.

Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When mac80211 asks a driver to encrypt a frame, it
must assign the control.hw_key pointer for it to
know which key to use etc. Currently, mac80211 does
this whenever it would software-encrypt a frame.

Change the logic of this code to assign the hw_key
pointer when selecting the key, and later check it
when deciding whether to encrypt the frame or let
it be encrypted by the hardware. This allows us to
later simply skip the encryption function since it
no longer modifies the TX control.

Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211 : fix a race with update_tkip_key</title>
<updated>2009-12-22T18:31:14+00:00</updated>
<author>
<name>gregor kowski</name>
<email>gregor.kowski@gmail.com</email>
</author>
<published>2009-12-09T22:25:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ca99861d5421c91f5a8fd3a77acb4b7be14f119d'/>
<id>ca99861d5421c91f5a8fd3a77acb4b7be14f119d</id>
<content type='text'>
The mac80211 tkip code won't call update_tkip_key, if rx packets
are received without KEY_FLAG_UPLOADED_TO_HARDWARE. This can happen on
first packet because the hardware key stuff is called asynchronously with
todo workqueue.

This patch workaround that by tracking if we sent the key to the driver.

Signed-off-by: Gregor Kowski &lt;gregor.kowski@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The mac80211 tkip code won't call update_tkip_key, if rx packets
are received without KEY_FLAG_UPLOADED_TO_HARDWARE. This can happen on
first packet because the hardware key stuff is called asynchronously with
todo workqueue.

This patch workaround that by tracking if we sent the key to the driver.

Signed-off-by: Gregor Kowski &lt;gregor.kowski@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: use fixed broadcast address</title>
<updated>2009-11-18T22:09:18+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes@sipsolutions.net</email>
</author>
<published>2009-11-17T12:34:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=15ff63653e507ec928a4a4386405a82446e096b1'/>
<id>15ff63653e507ec928a4a4386405a82446e096b1</id>
<content type='text'>
The netdev broadcast address cannot change from
all-ones so there's no need to use it; we can
instead hard-code it. Since we already have an
instance in tkip.c, which will be shared if it
is marked static const, doing this reduces text
size at no data/bss cost.

The real motivation for this is, of course, the
desire to get rid of almost all uses of netdevs
in mac80211 so that auditing their use becomes
easier.

Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The netdev broadcast address cannot change from
all-ones so there's no need to use it; we can
instead hard-code it. Since we already have an
instance in tkip.c, which will be shared if it
is marked static const, doing this reduces text
size at no data/bss cost.

The real motivation for this is, of course, the
desire to get rid of almost all uses of netdevs
in mac80211 so that auditing their use becomes
easier.

Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
