On Apr 12, 2019, at 5:24 AM, Johannes Berg <johannes(a)sipsolutions.net> wrote:
On Thu, 2019-04-11 at 01:32 +0200, Harald Welte
wrote:
GSMTAP was designed as a format to encapsulate
protocols normally not spoken over IP
(such as classic GSM radio protocols, e.g. the Layer 2 LAPDm over GSM Um)
inside an IP transport.
Sure, but wifi is also not spoken over IP, yet we don't encapsulate our
802.11 frames into IP to show them in wireshark :-)
That's just because the rpcap protocol hasn't been revved yet to handle the new
create/set options/activate mechanism in libpcap to allow monitor-mode capturing, so you
only get to see fake Ethernet frames. :-)
I.e., there's a split there between "capture" and "getting the packets
from a capture delivered to you over an IP network".
Perhaps there should be a GSMTAP link-layer header type, so you can have a GSMTAP pcap
file or GSMTAP interface in a pcapng file, combined with a more general "remote
capture" mechanism in libpcap so that you could capture on gsmtap://host:port and
capture from a host using the GSMTAP-over-UDP encapsulation - or capture using rpcap.
No userspace
source would ever be able to generate such data and stream
it real-time into wireshark, would it? Sure, I can write pcap file with
such ARPHDR_* values, but I could never do this in real-time. For many
but not all use cases, that's really what it is: A vehicle to stream
real-time non-IP protocol traces into wireshark so it can visualize
the protocol traces.
I think you can pipe a stream into wireshark?
1) You could pipe into libpcap or otherwise have a way for a libpcap module to connect to
a user space source and get packets from it.
2) You could pipe a pcap file into tcpdump/Wireshark/etc..
3) You could have an extcap program:
https://www.wireshark.org/docs/wsdg_html_chunked/ChCaptureExtcap.html
provide packets to Wireshark.
To me it feels like the wrong thing to actually make
wireshark listen on
"lo" or "eth0" or something to get data from the cellular that's
(locally) generated by another application, but I guess that's only
about how you think about it - and if it's not generated locally then
that's an easy transport. I'm not sure it makes *sense* because then you
need permissions to capture on the wired network etc.
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.
where you don't *really* need that for this stream
If there's a need for that, whatever provides the packets could impose that (by
finding out the UID/GID of the other process if this is going over a UNIX-domain socket,
at least on some UN*Xes, or by requiring a login if this is going over a network).