Re: gsmtap design/extensions?

Hi Johannes,

>> 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.
>=20
> Yes, that's true, though the control path is actually going through =
one
> of the data pipes as well.

I think that viewpoint is too simplistic. And for sure we have no such =
system where the control path is done as IP packets for Ethernet =
packets.

>> =46rom 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.=20
>=20
> So the control path *itself* would be there, I guess, but ...
>=20
>> The majority of the debugging is really done for the control path. =
For
>> oFono that is OFONO_DEBUG=3D1 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.
>=20
> there's definitely room for more information than _just_ the control
> path "chat", also application state etc. would be useful, and logging
> etc.
>=20
> 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.
>=20
>> 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.
>=20
> Right. This is something we'd typically use tracing for in wifi.

Same thing, but different way of doing it. Mind you that Bluetooth =
support is older than tracing.

> I don't really know what the right model for WWAN would be, I guess.
>=20
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> 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.

I do not follow on why is that. Why would I care if wwan0 is =
self-sustained of just a VLAN device. Or for that matter any other kind =
of slave/child device. 3GPP and 3GPP2 are not Ethernet frame based. We =
only have raw IPv4 and IPv6 packets for the data path.

> 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.
>=20
> 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.

And for 3GPP you have context identifiers that at least within the =
context of the control path make logical sense of the data streams and =
what they are assigned to. This goes back to my original point. You need =
to capture the control path to see what APN context is set up and how. =
Mind you that you also have the fun between primary context and =
secondary context (primarily for quality of service in VoLTE cases).

> 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.
>=20
> 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.

As I said, as long as you do not get the QMI, AT command, MBIM etc. =
control path session recorded as well, you have nothing to really =
analyze.

Regards

Marcel