RadioTap Archive on
 help / color / Atom feed
From: Harald Welte <>
To: Johannes Berg <>
Cc: "Vadim Yanitskiy"
	"OpenBSC Mailing List"
	"Sean Tranchetti"
	"Dan Williams" <>,,,
	"Aleksander Morgado"
	"Subash Abhinov Kasiviswanathan"
	"Bjørn Mork" <>
Subject: Re: gsmtap design/extensions?
Date: Thu, 11 Apr 2019 01:45:55 +0200
Message-ID: <20190410234555.GO25552__16868.7731189252$1554939977$gmane$org@nataraja> (raw)
In-Reply-To: <>

Hi Johannes,

On Wed, Apr 10, 2019 at 09:23:13AM +0200, Johannes Berg wrote:
> > but unfortunately, nobody has invested time into this (yet?).
> 2012! 

Well, Osmocom is a very small community, with probably somewhere less than
25 active developers over the last few years (less than 15 full-time),
with an *incredibly* large scope:  Implement virtually any protocol
layer of any protocol stack on any of the 3GPP interfaces and all their
related network elements for 2G/3G as well as even other technologies
like TETRA, GMR-1, ...

And all that in a field of technology that has less free software than
the Operating Systems world had in the mid-1990ies.  It really feels a
bit like the Linux community 20 years ago.

So resources are always *extremely* tight, and given those limited
resources, I'm actually very happy with the results by now, having
automatied CI, build verifications, unit tests, functional test suites,
end-to-end testing, and all the code we implemented on :)

While current GSMTAPv2 is ugly, it works rather solid for all known
existing use cases, so there was no urgency to introduce a new version
of it.

> Not sure I get this, but I also don't really care all that much. 

Well, with all respect, GSMTAP was created for a variety of use cases,
see my other lengthy mail.  It's fine if you don't care, but unless you
could explain your use cases with a few paragraphs, neither you nor us
are able to determine if there is common functionality and if it makes
sense to use GSMTAP or not :)

So far I have not seen any explanation about what kind of data you want
to encapsulate at all.

> just a pretty strange design if the kernel were to output this, I'm not
> even sure how I'd do that properly. I don't want to be generating UDP
> packets there...

There are well-established APIs for having sockets in the kernel and for
generating + receiving UDP packets from it.  NFS has been doing this for
decades, as do various kernel-side tunneling helpers including the GTP
kernel module.

I'm not saying it's the right approach for your problem, I'm just saying
kernel-side code can for sure use UDP sockets.

> Perhaps we can define something (GSMTAPv3) to not really care how it's
> encapsulated, and for 'native' packet captures like what I want on Linux
> when integrated with the driver, actually use an ARPHDR_GSMTAP, and
> encapsulate in UDP when you create it in an application and want to send
> it elsewhere, rather than just writing it to a pcap file?

Sure, that works.  But the real question is, to me:  Are there common
GSMTAP payload types that both the existing GSMTAP users carry, as well
as what you would want to carry?  If yes, then it makes sense to think
about a common encapsulation like GSMTAP.  If the payload types differ,
then it seems rather like there are two distinct use cases that
wouldn't benefit from standardizing on one format.

- Harald Welte <> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

  parent reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 13:50 Johannes Berg
     [not found] ` <>
     [not found]   ` <>
2019-04-10  7:23     ` Johannes Berg
     [not found]       ` <>
2019-04-10  7:57         ` Marcel Holtmann
2019-04-10 23:45         ` Harald Welte [this message]
     [not found]       ` <>
     [not found]         ` <>
2019-04-12 12:12           ` Johannes Berg
     [not found]             ` <>
2019-04-12 19:49               ` Marcel Holtmann
     [not found]             ` <>
     [not found]               ` <>
2019-04-15  9:11                 ` Johannes Berg
     [not found]                   ` <>
2019-04-15 10:29                     ` Bjørn Mork
     [not found]                       ` <>
2019-04-15 10:41                         ` Johannes Berg
     [not found]       ` <20190410234555.GO25552@nataraja>
2019-04-12 17:15         ` Johannes Berg
     [not found]           ` <>
2019-04-12 19:54             ` Guy Harris
2019-04-13  7:12             ` Harald Welte
2019-04-13  7:49               ` Guy Harris
     [not found]           ` <>
     [not found]             ` <196E881D-AB4A-4569-9C1F-5BCB41FE832F-FrUbXkNCsVf2fBVCVOL8/>
2019-04-12 22:47               ` Guy Harris
     [not found]                 ` <1D6FE33B-DC15-47D8-A1AD-E95608300FDC-FrUbXkNCsVf2fBVCVOL8/>
2019-04-13  6:41                   ` Harald Welte
     [not found]                 ` <20190413064152.GB24451@nataraja>
2019-04-13  7:36                   ` Guy Harris
     [not found] ` <>
2019-04-10  6:35   ` Vadim Yanitskiy
2019-04-10 23:32   ` Harald Welte
2019-04-12 12:24     ` Johannes Berg
     [not found]       ` <>
2019-04-12 19:48         ` Guy Harris
2019-04-13  7:35         ` Harald Welte
     [not found]       ` <20190413073505.GD24451@nataraja>
2019-04-13  7:55         ` Guy Harris
2019-04-15  9:26         ` Johannes Berg
     [not found]       ` <>
     [not found]         ` <1089142F-2966-4C41-921B-465FBA721E79-FrUbXkNCsVf2fBVCVOL8/>
2019-04-15  9:28           ` Johannes Berg

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='20190410234555.GO25552__16868.7731189252$1554939977$gmane$org@nataraja' \ \
    --cc=aleksander-Dvg4H30XQSRVIjRurl1/ \ \ \ \ \ \ \
    --cc=openbsc-qjLDD68F18N4m7O/Vxda39i2O/ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RadioTap Archive on

Archives are clonable:
	git clone --mirror radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ \
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone