From: Bruno Randolf <br1@einfach.org>
To: Jouni Malinen <j@w1.fi>
Cc: linville@tuxdriver.com, ath5k-devel@venema.h4ckr.net,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH 6/6] ath: Fix WEP hardware encryption
Date: Wed, 26 Jan 2011 11:38:53 +0900 [thread overview]
Message-ID: <201101261138.53169.br1@einfach.org> (raw)
In-Reply-To: <20110125183205.GA29410@jm.kir.nu>
On Wed January 26 2011 03:32:05 Jouni Malinen wrote:
> On Tue, Jan 25, 2011 at 01:15:49PM +0900, Bruno Randolf wrote:
> > In AP mode hardware encryption for WEP was not used on the RX side
> > because there was a mismatch in the key indices. The key index in the
> > WLAN header is 0-3 while the hardware key cache was configured for key
> > indices >= 4. This is ok for transmit but received packets were not
> > decrypted in HW and therefore mac80211 had to decrypt them in SW - this
> > can be easily seen by adding some debug prints in mac80211/wep.c (around
> > line 296). I have noticed it by watching the system CPU load under high
> > traffic.
> >
> > This patch configures WEP keys into the "standard" key indices 0-4 which
> > were reserved for that.
>
> Have you tested this with multiple vifs? I would assume it would break
> things pretty completely for all but one vif.. As such, I'm not sure
> that it would be that good of an idea to try to improve on something
> like WEP which is known to be completely insecure and unusable with
> 802.11n when it is likely to break use cases that are much more relevant
> in modern, post-WEP, time..
>
> If you really think you need this, there would need to be code somewhere
> kicking out the default keys from key cache if another vif is added.
> When working with the key cache implementation for ath9k, the extra
> effort did not seem to be justifiable for WEP and it is now couple of
> years from that and surely there is even less justification now.
Please let's not go into the discussion about the usefulness of WEP - there is
no need to convince me. But unfortunately there are users and customers who
still want to use WEP for a variety of reasons. Yes it's legacy, yes it's
flawed especially with regards to multiple vifs, but we still need to support
it.
Even without my patch, WEP does not work with multiple vifs.
(As far as i understand it, with WEP the lookup is just done based on the key
index in the WLAN header field. mac80211 (or is it hostapd?) sets up both keys
for both interfaces with a key index of 0, which causes the lookup to go to
the same key for both vifs. I guess mac80211 or hostapd would need to be
changed to use different key indices for different vif WEP keys, but then of
course we can only use 4 different WEP keys in sum, and not 4 different WEP
keys per vif. No big deal imho.)
My patch just adds a special case for WEP, so it does not break anything for
the other use cases. It improves the performance for the one vif case where
WEP works right now.
bruno
next prev parent reply other threads:[~2011-01-26 2:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-25 4:15 [PATCH 1/6] ath5k: ath5k_setup_channels cleanup and whitespace Bruno Randolf
2011-01-25 4:15 ` [PATCH 2/6] ath5k: Use local variable for capabilities Bruno Randolf
2011-01-25 4:15 ` [PATCH 3/6] ath: Add function to check if 4.9GHz channels are allowed Bruno Randolf
2011-01-25 4:15 ` [PATCH 4/6] ath5k: Enable 802.11j 4.9GHz frequencies Bruno Randolf
2011-01-25 4:15 ` [PATCH 5/6] ath9k: Remove unused IEEE80211_WEP_NKID Bruno Randolf
2011-01-25 4:15 ` [PATCH 6/6] ath: Fix WEP hardware encryption Bruno Randolf
2011-01-25 18:32 ` Jouni Malinen
2011-01-26 2:38 ` Bruno Randolf [this message]
2011-01-26 8:29 ` Johannes Berg
2011-01-26 9:21 ` [ath5k-devel] " Bruno Randolf
2011-01-26 9:23 ` Johannes Berg
2011-01-26 9:37 ` Jouni Malinen
2011-01-26 10:36 ` Bruno Randolf
2011-01-27 5:51 ` Vasanthakumar Thiagarajan
2011-01-27 9:19 ` Bruno Randolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201101261138.53169.br1@einfach.org \
--to=br1@einfach.org \
--cc=ath5k-devel@venema.h4ckr.net \
--cc=j@w1.fi \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.