All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.