All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Tomas Winkler <tomasw@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org
Subject: Re: wireless mini-summit agenda proposals?
Date: Fri, 01 Feb 2008 15:11:54 -0500	[thread overview]
Message-ID: <1201896714.20566.8.camel@localhost.localdomain> (raw)
In-Reply-To: <1ba2fa240802011147j4cd027e8gacf2d5a6de65443d@mail.gmail.com>

On Fri, 2008-02-01 at 21:47 +0200, Tomas Winkler wrote:
> On Feb 1, 2008 9:15 PM, Dan Williams <dcbw@redhat.com> wrote:
> > On Fri, 2008-02-01 at 20:29 +0200, Tomas Winkler wrote:
> > > On Feb 1, 2008 2:42 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > > >
> > > > > cfg80211/nl80211 - overview, get Johannes to disseminate knowledge
> > > > > because email isn't optimal for this.  I haven't had enough time to jump
> > > > > into it yet, but the fact that Johannes is the vast majority of the
> > > > > effort here is worrisome.  Having a reference implementation (airo,
> > > > > atmel, maybe libertas) of a fullmac driver ported to cfg80211 would
> > > > > probably be very useful, even just to get a sense of how the API works.
> > > >
> > > > cfg80211/nl80211 is no further for fullmac drivers than a year ago, all
> > > > work it got so far is for hostapd.
> > > >
> > > > I have a fairly decent plan how to add association/... support but it
> > > > lacks execution because it's completely boring work that doesn't buy us
> > > > any new features since we still have to support wext.
> > > >
> > > Security setting is a bit  broken. There is a missing separation
> > > between static and dynamic./WPA wep keys.
> >
> > How do you mean?
> 
> In wext there is encoding setting for static keys only for wep and
> extended encoding for dynamic keys including wep keys. In mac80211
> both setting are funneled to the same point which is incorrect since
> the usage is not the same. The major problem is in HW acceleration.
> The static wep keys are passed as belonging to the station with
> broadcast address and the driver cannot distinguish if the wep key is
> dynamic key for the bcast address or it is a static wep key that has
> to be used for all traffic. The problem is of course visible mostly in
> AP mode.

Ah; right.  I don't think there really should be a difference in the API
to differentiate static vs. dynamic WEP keys.  Instead each key sent to
the driver (be it WEP, TKIP, or CCMP) should definitely have a BSSID to
which it applies which the userspace caller must set, and if the key is
to be used for _all_ traffic, then maybe have a flag for that or use
00:00:00:00:00:00 as the BSSID.  If we use "magic" #s like 00:00... for
the BSSID then we've got to be sure to document that magic # which is
where we all fell down with WEXT.  Hence I prefer flags, but whatever.

Dan



  reply	other threads:[~2008-02-01 20:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31 16:25 wireless mini-summit agenda proposals? John W. Linville
2008-01-31 17:52 ` Dan Williams
2008-01-31 19:42   ` Inaky Perez-Gonzalez
2008-02-01 12:42   ` Johannes Berg
2008-02-01 18:29     ` Tomas Winkler
2008-02-01 19:15       ` Dan Williams
2008-02-01 19:47         ` Tomas Winkler
2008-02-01 20:11           ` Dan Williams [this message]
2008-02-01 21:21             ` Tomas Winkler
2008-02-01 21:31               ` Dan Williams
2008-03-28 20:32   ` John W. Linville
2008-03-31 20:12     ` John W. Linville
2008-04-01 12:23       ` Johannes Berg
2008-04-01 14:12         ` Johannes Berg
2008-04-01 23:00           ` Nick Kossifidis
2008-04-02  0:18             ` John W. Linville
2008-02-01 16:16 ` Johannes Berg
2008-02-01 19:07   ` Nick Kossifidis
2008-02-01 20:11     ` Johannes Berg
2008-02-01 20:29       ` Luis Carlos Cobo
2008-02-02  3:32         ` Luis Carlos Cobo
2008-02-01 21:28       ` Tomas Winkler

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=1201896714.20566.8.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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 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.