All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Green <andy@warmcat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Jiri Benc <jbenc@suse.cz>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [WIP] mac80211: kill mgmt interface
Date: Sun, 24 Jun 2007 09:51:21 +0100	[thread overview]
Message-ID: <467E3089.2080602@warmcat.com> (raw)
In-Reply-To: <1182635313.21939.122.camel@johannes.berg>

Johannes Berg wrote:

> Don't get me wrong, I fully support your patches. I can see usefulness
> in what you're doing there, I even based my recent patch-frenzy on top
> of your patches ;) But I'm not fully convinced that this will be the

Thanks for the faith Johannes :-)

> best path for the userspace MLME (in whatever form); I do however think
> that it is the best option for wireless analysis/hacking/... tools or
> something like your penumbra.
> 
>> But Jiri's encapsulation method is an improvement if it can be
>> implemented okay for unassociated interfaces and so on.
> 
> Not convinced; it solves only a minor part of the problem, the hard
> things aren't solved (like that we need to see the decrypted frames that
> would normally be dropped by the kernel). Hence, I don't see any value
> in it by itself without solving the harder parts as well (or better even
> first), when solving that may end up using netlink for frames anyway.

The thing that it buys is allowing injection in a standardized format on
interfaces in any mode.  Currently the fact that a TX packet comes on a
Monitor Mode interface is used to infer the format of it, that it will
have a radiotap header.  That's not too ugly, but allowing
injection/radiotap format packets to be accepted on any interface in any
mode (eg, Master) and to use an ethhdr to determine the structure of the
packet is a bit more general and clean, since that is the job of the
ethhdr everywhere.

> I think what we need to accept is that the long-touted concept of a
> "userspace MLME" isn't really that, while it's dead simple to do
> *everything* in userspace by using a monitor interface with injection
> and then a tun interface that isn't really what we want. We want to push
> parts of the complexity to userspace while still having it
> kernel-assisted for various reasons like performance.

It'll be interesting to see what the genuine primitives are for the MLME
after you are finished ejecting the ioctl type cruft.  I don't have much
idea of what is truly needed as it stands.

-Andy

  reply	other threads:[~2007-06-24  8:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-21  9:42 [WIP] mac80211: kill mgmt interface Johannes Berg
2007-06-21 12:35 ` Jiri Benc
2007-06-21 12:45   ` Johannes Berg
2007-06-21 13:14     ` Jiri Benc
2007-06-21 23:27       ` Andy Green
2007-06-22 13:45       ` Jiri Benc
2007-06-22 14:29         ` Andy Green
2007-06-22 15:30           ` Johannes Berg
2007-06-22 15:49             ` Jiri Benc
2007-06-22 20:20               ` Johannes Berg
2007-06-23  5:58                 ` Andy Green
2007-06-23  6:53                   ` Johannes Berg
2007-06-23  9:00                     ` Andy Green
2007-06-23 21:48                       ` Johannes Berg
2007-06-24  8:51                         ` Andy Green [this message]
2007-06-24  9:38                           ` Johannes Berg
2007-06-23 11:44                     ` Jiri Benc
2007-06-23 12:23                       ` Andy Green
2007-06-23 21:51                         ` Johannes Berg
2007-06-24  8:39                           ` Andy Green
2007-06-24 10:46                             ` Jiri Benc
2007-06-22 15:39           ` Jiri Benc
2007-06-22 17:00             ` Andy Green
2007-06-23  8:29               ` Andy Green
2007-06-23 21:41                 ` Johannes Berg
2007-06-21 13:35 ` Jouni Malinen
2007-06-22  5:05   ` Michael Wu
2007-06-22 10:12     ` Johannes Berg
2007-06-23  7:08   ` Johannes Berg
  -- strict thread matches above, loose matches on Subject: below --
2007-06-21 21:50 Joerg Pommnitz
2007-06-22  9:10 ` Johannes Berg
2007-06-22 13:15 ` Jiri Benc
2007-07-01  1:48   ` Cohen, Guy
2007-07-02 13:38 AW: " Joerg Pommnitz
2007-07-02 13:53 ` Jiri Benc
2007-07-04  6:13   ` 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=467E3089.2080602@warmcat.com \
    --to=andy@warmcat.com \
    --cc=jbenc@suse.cz \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /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.