RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* gsmtap design/extensions?
@ 2019-04-09 13:50 Johannes Berg
       [not found] ` <CAPEnp=bHTVARr7WA9Qkq4=y7kk8_FLWhrkqKOEXubMO4X=BHCw@mail.gmail.com>
       [not found] ` <cf07ae24c436f92769f9289d208f01846ebe8826.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 2 replies; 24+ messages in thread
From: Johannes Berg @ 2019-04-09 13:50 UTC (permalink / raw)
  To: laforge-TgoAw6mPHtdg9hUCZPvPmw, openbsc-qjLDD68F18N4m7O/Vxda39i2O/JbrIOy
  Cc: radiotap-S783fYmB3Ccdnm+yROfE0A,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	Subash Abhinov Kasiviswanathan, Dan Williams, Bjørn Mork,
	netdev-u79uwXL29TY76Z2rM5mHXA, Sean Tranchetti,
	Aleksander Morgado

Hi,

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 :-) ).

So obviously, I found gsmtap, but for my use case it doesn't really
address most of the interesting data, and it got me wondering. So a few
questions, if I may:

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"?

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.

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

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


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.

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.


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? I do note that this
wouldn't be compatible with the current wireshark code as it doesn't
check the version, just shows it...

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? I'm not really sure I see the point of UDP encapsulation anyway.

Thanks,
johannes

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, back to index

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-09 13:50 gsmtap design/extensions? Johannes Berg
     [not found] ` <CAPEnp=bHTVARr7WA9Qkq4=y7kk8_FLWhrkqKOEXubMO4X=BHCw@mail.gmail.com>
     [not found]   ` <CAPEnp=bHTVARr7WA9Qkq4=y7kk8_FLWhrkqKOEXubMO4X=BHCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-04-10  7:23     ` Johannes Berg
     [not found]       ` <46474c61d7748042cc0a1f23773186786020638e.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-04-10  7:57         ` Marcel Holtmann
2019-04-10 23:45         ` Harald Welte
     [not found]       ` <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D@holtmann.org>
     [not found]         ` <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
2019-04-12 12:12           ` Johannes Berg
     [not found]             ` <1d64c578cd5b254d301cf1cac82f32a062916888.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-04-12 19:49               ` Marcel Holtmann
     [not found]             ` <D4D12CF9-9CE5-46FB-9738-F89DB6B6F9EA@holtmann.org>
     [not found]               ` <D4D12CF9-9CE5-46FB-9738-F89DB6B6F9EA-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
2019-04-15  9:11                 ` Johannes Berg
     [not found]                   ` <92e8e142b6d441c1c995abc57d64ad7b7747a688.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-04-15 10:29                     ` Bjørn Mork
     [not found]                       ` <87d0ln1s0a.fsf-3F4PFWf5pNjpjLOzFPqGjWGXanvQGlWp@public.gmane.org>
2019-04-15 10:41                         ` Johannes Berg
     [not found]       ` <20190410234555.GO25552@nataraja>
2019-04-12 17:15         ` Johannes Berg
     [not found]           ` <f0a64bb751b8c601f58130a7f3a3158d70f18f63.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-04-12 19:54             ` Guy Harris
2019-04-13  7:12             ` Harald Welte
2019-04-13  7:49               ` Guy Harris
     [not found]           ` <196E881D-AB4A-4569-9C1F-5BCB41FE832F@alum.mit.edu>
     [not found]             ` <196E881D-AB4A-4569-9C1F-5BCB41FE832F-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2019-04-12 22:47               ` Guy Harris
     [not found]                 ` <1D6FE33B-DC15-47D8-A1AD-E95608300FDC-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2019-04-13  6:41                   ` Harald Welte
     [not found]                 ` <20190413064152.GB24451@nataraja>
2019-04-13  7:36                   ` Guy Harris
     [not found] ` <cf07ae24c436f92769f9289d208f01846ebe8826.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-04-10  6:35   ` Vadim Yanitskiy
2019-04-10 23:32   ` Harald Welte
2019-04-12 12:24     ` Johannes Berg
     [not found]       ` <1462659018bc40830efbe2348791b8df45b54cff.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
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]       ` <1089142F-2966-4C41-921B-465FBA721E79@alum.mit.edu>
     [not found]         ` <1089142F-2966-4C41-921B-465FBA721E79-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2019-04-15  9:28           ` Johannes Berg

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 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/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git