gsmtap design/extensions?

historical

Hi Johannes,

On Tue, Apr 09, 2019 at 03:50:45PM +0200, Johannes Berg wrote:
> As I'm looking into adding a generic cell modem framework to the linux
> kernel (to create session netdevs etc.), I started looking for a
> metadata encapsulation, a la Radiotap (I'm a wifi guy :-) ).

Is there any discussion about "session netdevs, etc." anywhere?  What exactly
do you have in mind for that "generic cell modem framework"?  I'm quite
curious to learn more about it and happy to provide feedback from the
perspective of my cellular protocols/specs/systems knowledge.

> So obviously, I found gsmtap, but for my use case it doesn't really
> address most of the interesting data, 

I have no knowledge of your use case, so I don't feel like I can
comment on that :/

> 1) Why the design with encapsulating it in UDP? Radiotap is just a raw
>    header without IP etc. in front, and you use it with tcpdump,
>    wireshark or similar tools on the local system. What's the value in
>    having something "network transparent"?

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.

The existing implementations of such protocols all live outside of the
kernel but in userspace.  So you either have

a) a pure SDR software implementation of a GSM phy, whether on the MS/UE
   side or on the BTS/network side, or whether in sniffing mode, running
   as a userspace process.  This could e.g. be airprobe or gr-gsm

b) a OsmocomBB phone attached over serial port running the Osmocom Layer1
   firmware on the baseband processor, with some userspace program on a Linux
   PC implementing higher layers

c) GSM base station software such as osmo-bts, running in userspace

d) Using an old nokia phone attached via serial cable to a Linux PC running
   dct3-gsmtap.

So for any of those, if you want to provide real-time data streams, you have to
somehow transmit those over some kind of network technology.   One could have
done raw ethernet frames or raw IP frames, but using UDP seemed straight-forward
as one can create UDP socket from non-privileged processes.

We also have a virtual physical layer between OsmocomBB and OsmoBTS called
virt_phy where the GSMTAP over multicast IP is used to simulate/virtualize
the entire Layer1 / PHY / radio interface between phone and base station.

Once again, all related network elements are implemented in userspace,
and having an 

> 2) The format of gsmtap doesn't seem very extensible, but I guess a new
>    version could be made that has a TLV-based format or so. I'd have
>    argued that a new version isn't even needed, but the length field is
>    only 8 bits right now which seems too short.

Yes, it's a known problem.  The format was originally designed for GSM,
that is circuit switched common and dedicated channels on the GSM Um interface.
It was later extended for GPRS, TETRA, SIM card protocol traces and many others,
but all of that was an afterthought.

For sure any future version should be more extensible and e.g. use TLVs

> (speaking of versions - the docs say "version, set to 0x01 currently"
> but "#define GSMTAP_VERSION 0x02")

Sorry, it's the usual "developer changes code but not comment". patches
are welcome, we use gerrit.osmocom.org :)

> 3) Does the packet data follow the gsmtap header? It's not really clear
>    to me based on reading the wireshark code.

Sure, the packet data follows the GSMTAP header, and the type of data
is defined by the GSMTAP type / sub-type as per the specific use case.  As
you can see, there's 18 TYPE by now (each of which has at least one
program/implementation generating the data).

I think the best way to learn about GSMTAP is to use any of the many
programs that support it by now.  I think not only the examples above
use it, but meanwhile many others like the independently-developed OpenBTS
project that's unrelated to Osmocom, as are other projects implementing LTE.

> In particular, the data I'm thinking of is higher-level things, like the
> session ID for a frame when it's going through the kernel, or perhaps a
> flow label on RX, etc.

I'm not quite sure how that relates to GSM?  GSMTAP so far was intended
to encapsulate ETSI/3GPP messages inside UDP/IP, particularly messages of
protocols that don't traditionally are transported over IP baesd transports.

Having said, we're open to extending the scope - it just all needs to make
sense

> Also, vendor-specific data would be useful, e.g. to encapsulate the
> device-specific headers like QMI, where such metadata is encapsulated in
> a vendor- or device-specific way, which you'd want to see for debugging
> certain things, but for other things the generic "session ID" type
> information - encoded in a vendor-agnostic way - would be better to show
> in wireshark.

I'm really not following you here.  What's a "session ID"?

In terms of vendor-specific encapsulations: We do have a GSMTAP sub-type
for Qualcomm DIAG, as well as the osmo-qcdiag program to take DIAG from
Qualcomm chips + put it in GSMTAP and I do have plenty of experimental
wireshark dissectors for various parts of the DIAG protocl in a branch
on git.osmocom.org.  This just never went anywhere complete enough that
I'd consider merging it.

> Since it doesn't seem possible to use gsmtap in the current version,
> would it make sense to define a new gsmtap that (say) has version 3 or
> something, followed by an overall length and TLVs? 

By all means.  Vadim has once presented some ideas/plans about exactly
that at an Osmocom conference, but I don't think any related work
ever started.

> I do note that this
> wouldn't be compatible with the current wireshark code as it doesn't
> check the version, just shows it...

If that's the case that's sad, and I should have paid more attention to
it when originally writing it.  We should get a related fix into
wireshark ASAP then.  But then, the current dissector would just state
something like unsupported version instead of showing some garbage it
cannot parse.  Either way, you will of course need new sources and
sink side implemetations.

> Or would it make more sense to define a new ARPHDR_WWANTAP like
> ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in
> IP/UDP, and then have a completely new (extensible) protocol inside of
> that? 

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.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)