RadioTap Archive on
 help / color / Atom feed
From: Johannes Berg <>
To: Marcel Holtmann <>
Cc: "Vadim Yanitskiy"
	"Harald Welte" <>,
	"OpenBSC Mailing List"
	"Sean Tranchetti"
	"Dan Williams" <>,
	netdev <>,
	"open list:NFC SUBSYSTEM"
	"Aleksander Morgado"
	"Subash Abhinov Kasiviswanathan"
	"Bjørn Mork" <>
Subject: Re: gsmtap design/extensions?
Date: Fri, 12 Apr 2019 14:12:44 +0200
Message-ID: <> (raw)
In-Reply-To: <>

Hi Marcel,

> before you go all out and define this, it would suggest to understand
> what meta-data for the connection contexts you actually need as well.
> The data path itself is just a pipe and has not all the information
> attached with it. That goes via the control path and that is normally
> in user space and carries the real important information to make
> useful analysis of how the data path / context is setup.

Yes, that's true, though the control path is actually going through one
of the data pipes as well.

> From what I am seeing right now is that unless you have a method to
> also feed the control path into your GSMTAPv3, then this is rather
> useless. 

So the control path *itself* would be there, I guess, but ...

> The majority of the debugging is really done for the control path. For
> oFono that is OFONO_DEBUG=1 environment variable and while it works it
> is not the most elegant solution. I would love to feed that into a
> generic debugging / tap that you can read out later.

there's definitely room for more information than _just_ the control
path "chat", also application state etc. would be useful, and logging

Typically on wifi we feed all of this together into kernel tracing (to
record with trace-cmd) rather than trying to encapsulate it some other

> As a side note, for Bluetooth we created a path where the bluetoothd
> can feed back its control debugging data back into the Bluetooth
> monitor in the kernel to allow combined userspace, mgmt and HCI
> tracing. Some really nasty issues could only be triaged by having all
> the meta data with a common timestamp.

Right. This is something we'd typically use tracing for in wifi.

I don't really know what the right model for WWAN would be, I guess.

Right now - and I really should've said this before - really the only
problem I was thinking of was how we can mux multiple "chat" sessions
with a device into a single data stream.

Currently, this is all vendor-specific. If you have a Qualcomm modem,
you'd be able to see all the open sessions on the underlying netdev, and
the QMI header tells you what session a given 'packet' belongs to, and
if you follow along maybe you can figure out if this is a control or IP
'packet' (could be an AT command).

cdc_mbim uses VLAN tags instead to achieve this, and decapsulates the
VLAN tags to send them down to the hardware in a different way.

There are a few reasons why I think that this model of having a single
underlying netdev controlled by the modem driver, with additional
netdevs layered on top in software will not work right in the future. I
think drivers should and will need to migrate to creating "real" netdevs
for the sessions instead of pure software ones.

But if you do this, you lose the ability to listen to all the session
streams at the same time, you can only do it for each netdev. Adding
this ability back seems worthwhile, but then we probably shouldn't do it
in a vendor-specific way, but rather in a generic way.

So basically right now that's all I'm trying to solve. In WiFi we don't
have the problem of "sessions" because we just use the addresses in the
frames to disambiguate - on such 'monitor' netdevs we see the frames
including full 802.11 headers.

Now, here's maybe where I'm getting off the right path - in wifi we
mostly couple that with PHY information as well, and so we have PHY
information + full 802.11 headers + data for capturing what's going on.
I figured that theoretically at least that would be possible/useful for
the modem as well (obviously control packets have no PHY data), but
there doesn't seem to be any hardware that would actually expose data in
this way. Everyone I've spoken to says these things are only available
as modem trace data. What I haven't figured out though is if that's by
some other design trade-off, or just because no such infrastructure
is/was available.

It may well be that doing kernel-tracing instead of doing it via some
kind of monitor netdev is perfectly sufficient, but I have a feeling
that the relative simplicity of starting tcpdump/wireshark might be


  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
     [not found]       ` <>
     [not found]         ` <>
2019-04-12 12:12           ` Johannes Berg [this message]
     [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 \ \ \
    --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