linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Tomas Winkler <tomasw@gmail.com>
Cc: JMF <tolas_feup@hotmail.com>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] iwlwifi: fix oops on wep key insertion
Date: Tue, 27 May 2008 09:53:43 -0400	[thread overview]
Message-ID: <1211896423.1746.9.camel@localhost.localdomain> (raw)
In-Reply-To: <1ba2fa240805270541wadf0f16t2001528f39b37ea8@mail.gmail.com>

On Tue, 2008-05-27 at 15:41 +0300, Tomas Winkler wrote:
> On Tue, May 27, 2008 at 1:58 PM, JMF <tolas_feup@hotmail.com> wrote:
> > Tomas Winkler <tomasw@...> writes:
> >
> >> WEP key is of fixed size 13 or  5 bytes, this setting should be
> >> refused somewhere in the mac wext handler.
> >> NACK.
> >> Tomas
> >  What about 256-bit WEP key (232-bit key I think), it won't be supported?
> >
> Not supported by iwlwifi HW, have to be done by SW, We need to check
> then probably in driver whether we support it or not and return error
> value in this case, in other cases I'm not sure how defensive the code
> should be....
> By the way isn't this a waste of bits. AES seams to be  secure enough.
> Who is implementing this at all?

IIRC D-Link is one manufacturer who implemented 152-bit and higher WEP
keys when people started to get scared about WEP, but before 802.11i/WPA
actually came out.

I'm pretty sure that not too many sites use greater than 104/128-bit
WEP, and the cards that support it in hardware (most cards were fullmac
at the time) we can probably count on one hand.  For softmac cards, we'd
have to weigh the maintenance cost of keeping the codepaths around that
most people wouldn't use and for hardware that nobody developing the
stack currently has to test against against the benefit of enabling
these users to work with legacy APs.

I've gotten maybe 1 or 2 requests for > 104/128-bit WEP key support for
NM in 3 years.  Nice to have, but I'm not sure it's worth the extra code
and maintenance burden?  Would be good to have somebody tell us what
hardware (APs and cards) support this though.

Dan


  reply	other threads:[~2008-05-27 13:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-27  5:13 [PATCH] iwlwifi: fix oops on wep key insertion Joonwoo Park
2008-05-27  6:41 ` Tomas Winkler
2008-05-27  7:10   ` Joonwoo Park
2008-05-27 10:58   ` JMF
2008-05-27 12:41     ` Tomas Winkler
2008-05-27 13:53       ` Dan Williams [this message]
2008-05-28  0:41         ` John W. Linville
2008-06-15 16:46           ` Joonwoo Park
2008-06-15 16:53             ` Tomas Winkler
2008-06-16  8:46               ` Johannes Berg
2008-06-16 14:30                 ` Dan Williams
2008-06-27 15:28                 ` John W. Linville
2008-06-27 16:07                   ` Dan Williams
2008-06-27 16:22                     ` Tomas Winkler
2008-06-27 18:10                       ` Dan Williams
2008-06-27 19:12                         ` Johannes Berg
2008-06-27 23:33                           ` Tomas Winkler
2008-05-28 10:14         ` JMF

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=1211896423.1746.9.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=tolas_feup@hotmail.com \
    --cc=tomasw@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).