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