All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Steve deRosier <derosier@gmail.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
	Avinash Patil <avinashp@quantenna.com>,
	Julian Calaby <julian.calaby@gmail.com>
Subject: Re: [PATCH] iw: add command to register and capture mgmt frames
Date: Mon, 16 Oct 2017 11:48:11 +0300	[thread overview]
Message-ID: <20171016084810.plzog2dtzakra4ae@bars> (raw)
In-Reply-To: <1508138777.10607.14.camel@sipsolutions.net>

Hello Johannes and all,

> So first, I'll say that I have no objection in principle to the patch,
> as a debugging aid.
> 
> However, the story is more complicated.
> 
> > IIUC tshark and other specific capture tools need wireless netdevice
> > to be in monitor mode.
> 
> This is correct, but shouldn't be a problem.
> 
> > This particular iw command is based on
> > NL80211_CMD_REGISTER_FRAME
> > and related cfg80211 ops. In fact, this command can be used to
> > subscribe
> > to mgmt frames when wireless device is up and running in AP or STA
> > mode.
> > That can be convenient for monitor and debug purposes. There is a
> > limitation though: currently cfg80211 core allows only one subscriber
> > for each particular frame/pattern.
> 
> If you're looking for a tool to actually do something like sniffer,
> this API isn't the right thing to do.
> 
> That's why I also don't think it should be added to tshark.
> 
> Remember that with the use of this API also come certain obligations.
> For example, if you subscribe to (certain) action frames and then don't
> actually process them as described by the spec, then the subscriber
> MUST generate responses with the 0x80 bit ORed into the action code,
> returning the frame as not understood. Clearly, this isn't something
> that iw does and can implement.
> 
> Additionally, as you noted, and it's for this exact reason because
> otherwise responsibilities wouldn't be clearly defined, there can only
> be a single subscriber to a certain set of frames, as specified by the
> subtype and match prefix, so using it as a type of sniffer or debug
> tool may affect other functional operation.
> 
> 
> In mac80211, it's _always_ possible to add a monitor interface, and
> given no special flags (which may or may not be supported by a given
> driver anyway) this monitor interface is a pure software construct and
> will in no way affect device operation - apart from sending all
> received frames to the monitor interface at the beginning of mac80211's
> operation.
> 
> I see no reason, other than needing a little bit of coding, that this
> couldn't similarly be supported in qtnfmac.

Well, monitor mode support in qtnfmac is in our todo list for sure. Meanwhile
the purpose of the patch was not to implement a full-fledged mgmt packet
capture. We have monitor mode and mature capture tools for that.

Nevertheless in certain cases it is handy to dump selected types of mgmt frames
while system is up and running without adding the whole monitor overhead. The
idea was that NL80211_CMD_REGISTER_FRAME and iw are the right tools for that
task. Anyway, iw is something like a 'swiss-army-knife' tool for various tasks
related to mac80211/cfg80211 reporting and troubleshooting.

Speaking of the patch, you mentioned that you have no objection in principle.
Let me know if you have any objections to implementation details :)
Then I will resubmit it addressing all the comments. Besides I am going
to change command name from 'capture' to 'dump' to avoid confusion.
Finally, I will update commit message adding information about unicast
nature of those registrations.

Regards,
Sergey

  reply	other threads:[~2017-10-16  8:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-14 21:00 [PATCH] iw: add command to register and capture mgmt frames Sergey Matyukevich
2017-10-14 22:15 ` Steve deRosier
2017-10-15  9:51   ` Sergey Matyukevich
2017-10-15 13:41     ` Julian Calaby
2017-10-16  7:26     ` Johannes Berg
2017-10-16  8:48       ` Sergey Matyukevich [this message]
2017-10-16  9:24         ` Johannes Berg
2017-10-16  9:43           ` Sergey Matyukevich
2017-10-16 19:17           ` Igor Mitsyanko
2017-10-17  6:03             ` Johannes Berg

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=20171016084810.plzog2dtzakra4ae@bars \
    --to=sergey.matyukevich.os@quantenna.com \
    --cc=avinashp@quantenna.com \
    --cc=derosier@gmail.com \
    --cc=igor.mitsyanko.os@quantenna.com \
    --cc=johannes@sipsolutions.net \
    --cc=julian.calaby@gmail.com \
    --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.