linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Sven Eckelmann <sven.eckelmann@openmesh.com>
Cc: Simon Wunderlich <simon.wunderlich@openmesh.com>,
	linux-wireless@vger.kernel.org,
	Benjamin Berg <benjamin@sipsolutions.net>
Subject: Re: [PATCH] mac80211: Allow multiple listeners for management frames.
Date: Tue, 14 Mar 2017 15:27:07 +0100	[thread overview]
Message-ID: <1489501627.10872.15.camel@sipsolutions.net> (raw)
In-Reply-To: <2459952.Zo1p5FTnYy@bentobox> (sfid-20170314_152123_171005_9062AC0F)

On Tue, 2017-03-14 at 15:21 +0100, Sven Eckelmann wrote:
> On Dienstag, 14. März 2017 15:13:12 CET Johannes Berg wrote:
> > > The idea was to grab probe requests from userspace with a program
> > > running next to hostapd.
> > 
> > I guess there are some efficiency problems with that right now, but
> > a
> > monitor mode interface should work just as well. Perhaps we can
> > allow
> > attaching a BPF program to a monitor mode interface, and run that
> > without cloning the SKB etc.?
> 
> This has also other problems. For example the ath10k fw will crash a
> lot when a monitor interface is active.

That's not an argument I can accept - the driver shouldn't even have to
*care* if one is active or not, especially not if you set the flags to
none. I'm not even sure we tell the driver about it in that case, but
it definitely sounds like something that should be fixed in the driver.

> I think that we saw also some
> performance regressions caused by the ath9k filtering behavior when a
> monitor mode interface is active (without actually listening on it).

Ditto, the filtering can be fixed by passing "flags none" with iw (or
directly when creating with nl80211). The driver should be fixed to not
care about the interface at all in that case.

Regardless though, there *will* be some performance impact of this.
Hence my suggestion to add a BPF filter not to the socket, but to the
monitor interface itself.

Now I'm also wondering if we could implement cooked monitor that way,
might cut down some special code that we only keep for backwards
compatibility ...

Either way, due to the action frame issue I don't really want to apply
this patch. With probe requests it's a bit borderline, if you promise
to never send anything it would probably be OK, but it's still rather
strange to use this for monitor purposes.

johannes

      reply	other threads:[~2017-03-14 14:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10  9:34 [PATCH] mac80211: Allow multiple listeners for management frames Sven Eckelmann
2017-03-14 13:51 ` Johannes Berg
2017-03-14 14:06   ` Sven Eckelmann
2017-03-14 14:10     ` Simon Wunderlich
2017-03-14 14:13       ` Johannes Berg
2017-03-14 14:21         ` Sven Eckelmann
2017-03-14 14:27           ` Johannes Berg [this message]

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=1489501627.10872.15.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=benjamin@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=simon.wunderlich@openmesh.com \
    --cc=sven.eckelmann@openmesh.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).