[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <446da2afcad3c7bb539027147030649ad08f3f33.camel@sipsolutions.net>
Date: Mon, 15 Apr 2019 11:28:30 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Guy Harris <guy@...m.mit.edu>
Cc: Harald Welte <laforge@...monks.org>, openbsc@...ts.osmocom.org,
radiotap@...bsd.org, linux-wireless@...r.kernel.org,
Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
Dan Williams <dcbw@...hat.com>,
Bjørn Mork <bjorn@...k.no>,
netdev@...r.kernel.org, Sean Tranchetti <stranche@...eaurora.org>,
Aleksander Morgado <aleksander@...ksander.es>
Subject: Re: gsmtap design/extensions?
On Fri, 2019-04-12 at 12:48 -0700, Guy Harris wrote:
> I.e., there's a split there between "capture" and "getting the packets
> from a capture delivered to you over an IP network".
Right. That's what I was trying to get at, you said it much more
succinctly.
> Depending on how your system is set up:
>
> $ ls -l /dev/bpf*
> crw-rw---- 1 root access_bpf 23, 0 Apr 10 22:57 /dev/bpf0
> crw-rw---- 1 root access_bpf 23, 1 Apr 10 22:56 /dev/bpf1
>
> ...
>
> and it could just be rw-rw-rw-. Perhaps other systems make it harder
> to grant capture privileges.
Yeah, generally it's not that *hard*. It still seems *wrong*, and e.g.
it would also mean if you do need to do it remotely you'd have to filter
out your own remote control (ssh) traffic lest you cause traffic
amplification, etc.
johannes
Powered by blists - more mailing lists