All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] iw: add command to register and capture mgmt frames
@ 2017-10-14 21:00 Sergey Matyukevich
  2017-10-14 22:15 ` Steve deRosier
  0 siblings, 1 reply; 10+ messages in thread
From: Sergey Matyukevich @ 2017-10-14 21:00 UTC (permalink / raw)
  To: Johannes Berg, linux-wireless
  Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich

Add new command to register for receiving multiple mgmt frames,
capture and print them. Frames are selected by their type and
pattern containing their the first several bytes of the frame
that should match.

Format:
$ iw dev <devname> frame <type> <pattern> [frame <type> <pattern>]* [count <frames>]

Example:
$ iw dev wlan0 mgmt capture frame 40 00 frame 40 01:02 count 10

Frame type is supplied as hex w/o leading 0x. Frame pattern is supplied
as hex pattern of the form aa:bb:cc w/o leading 0x as well.
Count is a number of frames to capture.

Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
 Makefile |   2 +-
 mgmt.c   | 149 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 150 insertions(+), 1 deletion(-)
 create mode 100644 mgmt.c

diff --git a/Makefile b/Makefile
index e61825e..38d782d 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,7 @@ OBJS = iw.o genl.o event.o info.o phy.o \
 	interface.o ibss.o station.o survey.o util.o ocb.o \
 	mesh.o mpath.o mpp.o scan.o reg.o version.o \
 	reason.o status.o connect.o link.o offch.o ps.o cqm.o \
-	bitrate.o wowlan.o coalesce.o roc.o p2p.o vendor.o
+	bitrate.o wowlan.o coalesce.o roc.o p2p.o vendor.o mgmt.o
 OBJS += sections.o
 
 OBJS-$(HWSIM) += hwsim.o
diff --git a/mgmt.c b/mgmt.c
new file mode 100644
index 0000000..c42d802
--- /dev/null
+++ b/mgmt.c
@@ -0,0 +1,149 @@
+#include <string.h>
+#include <errno.h>
+
+#include <netlink/genl/genl.h>
+#include <netlink/genl/family.h>
+#include <netlink/genl/ctrl.h>
+#include <netlink/msg.h>
+#include <netlink/attr.h>
+
+#include "nl80211.h"
+#include "iw.h"
+
+SECTION(mgmt);
+
+static int seq_handler(struct nl_msg *msg, void *arg)
+{
+	return NL_OK;
+}
+
+static int dump_mgmt_frame(struct nl_msg *msg, void *arg)
+{
+	struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+	struct nlattr *tb_msg[NL80211_ATTR_MAX + 1];
+
+	nla_parse(tb_msg, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+		  genlmsg_attrlen(gnlh, 0), NULL);
+
+	if (tb_msg[NL80211_ATTR_WIPHY_FREQ]) {
+		uint32_t freq = nla_get_u32(tb_msg[NL80211_ATTR_WIPHY_FREQ]);
+		printf("freq %u MHz\n", freq);
+	}
+
+	if (tb_msg[NL80211_ATTR_RX_SIGNAL_DBM]) {
+		uint32_t dbm = nla_get_u32(tb_msg[NL80211_ATTR_RX_SIGNAL_DBM]);
+		printf("signal %u dbm\n", dbm);
+	}
+
+	if (tb_msg[NL80211_ATTR_FRAME]) {
+		int len = nla_len(tb_msg[NL80211_ATTR_FRAME]);
+		uint8_t *data = nla_data(tb_msg[NL80211_ATTR_FRAME]);
+		iw_hexdump("mgmt frame", data, len);
+	}
+
+	return 0;
+}
+
+static int register_mgmt_frame(struct nl80211_state *state,
+			       struct nl_msg *msg, int argc, char **argv,
+			       enum id_input id)
+{
+	unsigned int type;
+	unsigned char *match;
+	size_t match_len;
+	int ret;
+
+	ret = sscanf(argv[0], "%x", &type);
+	if (ret != 1) {
+		printf("invalid frame type: %s\n", argv[0]);
+		return 2;
+	}
+
+	match = parse_hex(argv[1], &match_len);
+	if (!match) {
+		printf("invalid frame pattern: %s\n", argv[1]);
+		return 2;
+	}
+
+	NLA_PUT_U16(msg, NL80211_ATTR_FRAME_TYPE, type);
+	NLA_PUT(msg, NL80211_ATTR_FRAME_MATCH, match_len, match);
+
+	return 0;
+
+nla_put_failure:
+	return -ENOBUFS;
+}
+
+static int handle_mgmt_reg(struct nl80211_state *state,
+				    struct nl_msg *msg, int argc,
+				    char **argv, enum id_input id)
+{
+	return register_mgmt_frame(state, msg, argc, argv, id);
+}
+
+HIDDEN(mgmt, reg, "", NL80211_CMD_REGISTER_FRAME, 0, CIB_NETDEV, handle_mgmt_reg);
+
+static int handle_mgmt_capture(struct nl80211_state *state,
+			       struct nl_msg *msg, int argc,
+			       char **argv, enum id_input id)
+{
+	struct nl_cb *mgmt_cb;
+	char *ndev = argv[0];
+	int mgmt_argc = 5;
+	char **mgmt_argv;
+	unsigned int count = 0;
+	int err = 0;
+	int i;
+
+	mgmt_argv = calloc(mgmt_argc, sizeof(char*));
+	if (!mgmt_argv)
+		return -ENOMEM;
+
+	mgmt_argv[0] = ndev;
+	mgmt_argv[1] = "mgmt";
+	mgmt_argv[2] = "reg";
+
+	for (i = 3; i < argc; i += 3) {
+		if (strcmp(argv[i], "count") == 0) {
+			count = 1 + atoi(argv[i + 1]);
+			break;
+		}
+
+		if (strcmp(argv[i], "frame") != 0) {
+			err = 1;
+			goto out;
+		}
+
+		mgmt_argv[3] = argv[i + 1];
+		mgmt_argv[4] = argv[i + 2];
+
+		err = handle_cmd(state, II_NETDEV, mgmt_argc, mgmt_argv);
+		if (err)
+			goto out;
+	}
+
+	mgmt_cb = nl_cb_alloc(iw_debug ? NL_CB_DEBUG : NL_CB_DEFAULT);
+	if (!mgmt_cb) {
+		err = 1;
+		goto out;
+	}
+
+	/* need to turn off sequence number checking */
+	nl_cb_set(mgmt_cb, NL_CB_SEQ_CHECK, NL_CB_CUSTOM, seq_handler, NULL);
+	nl_cb_set(mgmt_cb, NL_CB_VALID, NL_CB_CUSTOM, dump_mgmt_frame, NULL);
+
+	while (--count)
+		nl_recvmsgs(state->nl_sock, mgmt_cb);
+
+	nl_cb_put(mgmt_cb);
+out:
+	free(mgmt_argv);
+	return err;
+}
+
+COMMAND(mgmt, capture, "frame <type as hex ab> <pattern as hex ab:cd:..> [frame <type> <pattern>]* [count <frames>]",
+	0, 0, CIB_NETDEV, handle_mgmt_capture,
+	"Register for receiving certain mgmt frames, capture and print them.\n"
+	"Frames are selected by their type and pattern containing\n"
+	"the first several bytes of the frame that should match.\n\n"
+	"Example: iw dev wlan0 mgmt capture frame 40 00 frame 40 01:02 count 10\n");
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  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
  0 siblings, 1 reply; 10+ messages in thread
From: Steve deRosier @ 2017-10-14 22:15 UTC (permalink / raw)
  To: Sergey Matyukevich
  Cc: Johannes Berg, linux-wireless, Igor Mitsyanko, Avinash Patil

Hi Sergey,

On Sat, Oct 14, 2017 at 2:00 PM, Sergey Matyukevich
<sergey.matyukevich.os@quantenna.com> wrote:
> Add new command to register for receiving multiple mgmt frames,
> capture and print them. Frames are selected by their type and
> pattern containing their the first several bytes of the frame
> that should match.
>

Forgive me for asking, what does this provide that isn't already
available in tshark? And since we already have user-space tools
tailored for capturing and filtering any frames, including management
frames, why do we need to add this to iw?

- Steve

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  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
  0 siblings, 2 replies; 10+ messages in thread
From: Sergey Matyukevich @ 2017-10-15  9:51 UTC (permalink / raw)
  To: Steve deRosier
  Cc: Johannes Berg, linux-wireless, Igor Mitsyanko, Avinash Patil

> > Add new command to register for receiving multiple mgmt frames,
> > capture and print them. Frames are selected by their type and
> > pattern containing their the first several bytes of the frame
> > that should match.
> >
> 
> Forgive me for asking, what does this provide that isn't already
> available in tshark? And since we already have user-space tools
> tailored for capturing and filtering any frames, including management
> frames, why do we need to add this to iw?

IIUC tshark and other specific capture tools need wireless netdevice to be
in monitor mode. 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.

It looks like 'capture' part of commit message is a bit confusing.

Regards,
Sergey

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  2017-10-15  9:51   ` Sergey Matyukevich
@ 2017-10-15 13:41     ` Julian Calaby
  2017-10-16  7:26     ` Johannes Berg
  1 sibling, 0 replies; 10+ messages in thread
From: Julian Calaby @ 2017-10-15 13:41 UTC (permalink / raw)
  To: Steve deRosier, Johannes Berg, linux-wireless, Igor Mitsyanko,
	Avinash Patil

Hi Sergey,

On Sun, Oct 15, 2017 at 8:51 PM, Sergey Matyukevich
<sergey.matyukevich.os@quantenna.com> wrote:
>> > Add new command to register for receiving multiple mgmt frames,
>> > capture and print them. Frames are selected by their type and
>> > pattern containing their the first several bytes of the frame
>> > that should match.
>> >
>>
>> Forgive me for asking, what does this provide that isn't already
>> available in tshark? And since we already have user-space tools
>> tailored for capturing and filtering any frames, including management
>> frames, why do we need to add this to iw?
>
> IIUC tshark and other specific capture tools need wireless netdevice to be
> in monitor mode. 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.

Stupid question: Can Wireshark / Tshark be taught how to do this?

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  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
  1 sibling, 1 reply; 10+ messages in thread
From: Johannes Berg @ 2017-10-16  7:26 UTC (permalink / raw)
  To: Sergey Matyukevich, Steve deRosier
  Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Julian Calaby

Hi,

Looks like this played out while I wasn't paying attention :-)

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.

Now, there *is* one problem with this - namely that this can
significantly affect performance. The reason is that all frames need to
be sent to the monitor interface, even if they're immediately discarded
using a BPF socket filter. Sending them there means allocating a new
SKB (not necessarily copying the data, but still), as well as
generating radiotap header information for the frames. In many cases
data frames are immediately discarded so all this work is for naught.

What I had worked on a while ago to solve this problem is an eBPF
filter attached just before the "branch point" to the monitor
interface, this filter gets access to the frame (without radiotap data)
and some limited RX status data.

You can find the code for this here (may need rebasing, but I have
merged all the RX path logic changes already):

https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
/log/?h=bpf


Now, there are two problems with this still (afaict):

   1. It doesn't cover the TX status path, which it should, since that
      also goes to the monitor interfaces. This is easily solved, I think
      I just forgot about it :) (This may need an additional field in the
      metadata, but that's not a problem)
   2. It doesn't deal with already decapsulated RX, i.e. devices where the
      802.11->ethernet decapsulation is done in the device already. This
      was the reason I didn't merge this, and the problem I see with this
      is that even if we do add additional metadata, it's hard to ensure
      that eBPF programs won't ignore it.

johannes

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  2017-10-16  7:26     ` Johannes Berg
@ 2017-10-16  8:48       ` Sergey Matyukevich
  2017-10-16  9:24         ` Johannes Berg
  0 siblings, 1 reply; 10+ messages in thread
From: Sergey Matyukevich @ 2017-10-16  8:48 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Steve deRosier, linux-wireless, Igor Mitsyanko, Avinash Patil,
	Julian Calaby

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  2017-10-16  8:48       ` Sergey Matyukevich
@ 2017-10-16  9:24         ` Johannes Berg
  2017-10-16  9:43           ` Sergey Matyukevich
  2017-10-16 19:17           ` Igor Mitsyanko
  0 siblings, 2 replies; 10+ messages in thread
From: Johannes Berg @ 2017-10-16  9:24 UTC (permalink / raw)
  To: Sergey Matyukevich
  Cc: Steve deRosier, linux-wireless, Igor Mitsyanko, Avinash Patil,
	Julian Calaby

On Mon, 2017-10-16 at 11:48 +0300, Sergey Matyukevich wrote:
> 
> Well, monitor mode support in qtnfmac is in our todo list for sure. 

Sure. I'm saying you don't really need full monitor support at all,
just a pure software construct for this.

> 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.

Right, and I didn't originally see the patch as such, just that the
discussion (and in particular Julian's suggestion) veered off in that
direction.

> 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.

I'd see this particular feature in iw more as a way to debug the
registrations, but whatever you ultimately want to use it for I neither
can nor want to control :-)

> Let me know if you have any objections to implementation details :)

Yeah, I'll need to review it, just need a bit more time for that.

> 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.

Sounds good :)

Do you want to resend before I review it?

johannes

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  2017-10-16  9:24         ` Johannes Berg
@ 2017-10-16  9:43           ` Sergey Matyukevich
  2017-10-16 19:17           ` Igor Mitsyanko
  1 sibling, 0 replies; 10+ messages in thread
From: Sergey Matyukevich @ 2017-10-16  9:43 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Steve deRosier, linux-wireless, Igor Mitsyanko, Avinash Patil,
	Julian Calaby

> > Let me know if you have any objections to implementation details :)
> 
> Yeah, I'll need to review it, just need a bit more time for that.
> 
> > 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.
> 
> Sounds good :)
> 
> Do you want to resend before I review it?

No, I will wait for code reviews, then I will resend the updated
patch including changes for all the upcoming comments.

Regards,
Sergey

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  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
  1 sibling, 1 reply; 10+ messages in thread
From: Igor Mitsyanko @ 2017-10-16 19:17 UTC (permalink / raw)
  To: Johannes Berg, Sergey Matyukevich
  Cc: Steve deRosier, linux-wireless, Avinash Patil, Julian Calaby

On 10/16/2017 02:24 AM, Johannes Berg wrote:
> 
> 
> Right, and I didn't originally see the patch as such, just that the
> discussion (and in particular Julian's suggestion) veered off in that
> direction.
> 
>> 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.
> 
> I'd see this particular feature in iw more as a way to debug the
> registrations, but whatever you ultimately want to use it for I neither
> can nor want to control :-)
> 

Maybe we could add an additional nl attribute to 
NL80211_CMD_REGISTER_FRAME command to allow applications to advertise 
what is their intention, something like NL80211_ATTR_MGMT_LISTENER_TYPE. 
Only allow to register more then one listener if it explicitly specifies 
that it will not try to answer (TYPE_LISTEN_ONLY or smth like that).
This will preserve behavior for existing userspace.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] iw: add command to register and capture mgmt frames
  2017-10-16 19:17           ` Igor Mitsyanko
@ 2017-10-17  6:03             ` Johannes Berg
  0 siblings, 0 replies; 10+ messages in thread
From: Johannes Berg @ 2017-10-17  6:03 UTC (permalink / raw)
  To: Igor Mitsyanko, Sergey Matyukevich
  Cc: Steve deRosier, linux-wireless, Avinash Patil, Julian Calaby

> Maybe we could add an additional nl attribute to 
> NL80211_CMD_REGISTER_FRAME command to allow applications to
> advertise 
> what is their intention, something like
> NL80211_ATTR_MGMT_LISTENER_TYPE. 
> Only allow to register more then one listener if it explicitly
> specifies 
> that it will not try to answer (TYPE_LISTEN_ONLY or smth like that).
> This will preserve behavior for existing userspace.

We could, in theory, but I don't like using this API for monitoring
purposes. We really should just come up with more generic and flexible
ways of doing that, and I think the eBPF thing is pretty good there.

johannes

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-10-17  6:03 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.