On Apr 12, 2019, at 5:24 AM, Johannes Berg johannes@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).