Linux wireless drivers development
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [WIP] mac80211: kill mgmt interface
Date: Thu, 21 Jun 2007 06:35:56 -0700	[thread overview]
Message-ID: <20070621133556.GJ5361@jm.kir.nu> (raw)
In-Reply-To: <1182418939.10821.8.camel@johannes.berg>

On Thu, Jun 21, 2007 at 11:42:19AM +0200, Johannes Berg wrote:

> This patch kills the management interface type now that we can
> see transmitted frames on monitor interfaces.

Has someone tested that this works with programs that use the management
interface (mainly, hostapd and wpa_supplicant)? Is all the needed
functionality available with the alternative solution?

> I renamed the req_tx_status to reliable_tx_mntr and the flag
> constant as well since that's what they now mean. It is always
> set for injected frames so that hostapd can rely on seeing the
> frames it sent.

I'm not sure I follow this explanation fully.. How would hostapd learn
whether the destination address acknowledged a unicast frame?

> There are a few minor remaining problems:
>  * some notifications are now missing
>    (radar, key threshold, michael MIC failure, wep unknown key)
>    [radar, key threshold aren't used anywhere so can probably
>     be left out for now]

I would not remove key threshold notification and we must most certainly
not remove Michal MIC failure before there is a reliable way of doing
the same functionality.

>  * injected frames aren't sent to AC_VO pending on the radiotap
>    definition for access category

This is not good either since management frames should be sent at a high
priority.

> The biggest problem, however, and I'm not sure how to solve it, is
> that hostapd will see either encrypted or unencrypted frames on the
> monitor interface depending on whether hardware encryption is used
> or not. However, hostapd really needs to see eapol frames to do
> whatever it needs to with them. Right now, I don't really have an
> idea except maybe to send these packets to hostapd via nl80211,
> or to introduce some sort of "decrypted soft monitor" iface.

If I've understood correctly (please correct me, if not), this patch is
proposing to remove an interface that works currently and leave the
stack in state that does not work. I can only strongly recommend this
patch not to be applied at this point. It is not a good direction to
start removing working code before there is a good alternative available
and that alternative has actually been tested to provide the needed
functionality.

I don't really see need for getting rid of the management interface, but
if there is consensus on doing that, we would need to have another way
of being able to receive and transmit management frames and data frames
from/to user space in a way that provides at least following
functionality:
- transmit management frames at high priority
- control whether transmitted frames will be encrypted or not
- get callback to report TX status for unicast frames (whether the
  receiver sent control::ack for the frame)
- receive management frames
- receive data frames EAPOL/etc. ethertypes in decrypted form
- delivery of notifications to user space for Michael MIC errors and
  other similar events

-- 
Jouni Malinen                                            PGP id EFC895FA

  parent reply	other threads:[~2007-06-21 13:36 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
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 [this message]
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=20070621133556.GJ5361@jm.kir.nu \
    --to=j@w1.fi \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox