Message-ID: <1d64c578cd5b254d301cf1cac82f32a062916888.camel@sipsolutions.net>
Date:   Fri, 12 Apr 2019 14:12:44 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Vadim Yanitskiy <axilirator@...il.com>,
        Harald Welte <laforge@...monks.org>,
        OpenBSC Mailing List <openbsc@...ts.osmocom.org>,
        Sean Tranchetti <stranche@...eaurora.org>, radiotap@...bsd.org,
        Dan Williams <dcbw@...hat.com>,
        netdev <netdev@...r.kernel.org>,
        "open list:NFC SUBSYSTEM" <linux-wireless@...r.kernel.org>,
        Aleksander Morgado <aleksander@...ksander.es>,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
        Bjørn Mork <bjorn@...k.no>
Subject: Re: gsmtap design/extensions?

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
etc.

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
way.

> 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
preferable.

johannes

Powered by blists - more mailing lists