RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Cc: "Vadim Yanitskiy"
	<axilirator-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Harald Welte" <laforge-TgoAw6mPHtdg9hUCZPvPmw@public.gmane.org>,
	"OpenBSC Mailing List"
	<openbsc-qjLDD68F18N4m7O/Vxda39i2O/JbrIOy@public.gmane.org>,
	"Sean Tranchetti"
	<stranche-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org,
	"Dan Williams" <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:NFC SUBSYSTEM"
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Aleksander Morgado"
	<aleksander-Dvg4H30XQSRVIjRurl1/8g@public.gmane.org>,
	"Subash Abhinov Kasiviswanathan"
	<subashab-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"Bjørn Mork" <bjorn-yOkvZcmFvRU@public.gmane.org>
Subject: Re: gsmtap design/extensions?
Date: Mon, 15 Apr 2019 11:11:54 +0200
Message-ID: <92e8e142b6d441c1c995abc57d64ad7b7747a688.camel@sipsolutions.net> (raw)
In-Reply-To: <D4D12CF9-9CE5-46FB-9738-F89DB6B6F9EA-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>

On Fri, 2019-04-12 at 21:49 +0200, Marcel Holtmann wrote:
> 
> > 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.

That's true, but as far as I can tell in a lot of cases the pipe is
actually still a virtual netdev (session, encoded in whatever way) using
some sort of serial line format on top?

But I agree that typically this will not be sufficient anyway.

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

Sure. Looking forward though, perhaps tracing *would* indeed be the
simplest thing to do.

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

>From a driver perspective I think it makes a difference. For example, if
you just have a single netdev from the driver, it gets harder to do
multiple TX/RX queues properly.

> 3GPP and 3GPP2 are not Ethernet frame based. We only have raw IPv4 and
> IPv6 packets for the data path.

Sure. Though some drivers/devices fake them anyway.

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

Right.

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

But you do - afaict there are no ways other than the netdevs to
communicate with the device, and people do things like "socat" to set up
PTYs and pretend to have serial channels there, on top of the netdevs?

johannes

  parent reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 13:50 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 [this message]
     [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

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=92e8e142b6d441c1c995abc57d64ad7b7747a688.camel@sipsolutions.net \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=aleksander-Dvg4H30XQSRVIjRurl1/8g@public.gmane.org \
    --cc=axilirator-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=bjorn-yOkvZcmFvRU@public.gmane.org \
    --cc=dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=laforge-TgoAw6mPHtdg9hUCZPvPmw@public.gmane.org \
    --cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=openbsc-qjLDD68F18N4m7O/Vxda39i2O/JbrIOy@public.gmane.org \
    --cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
    --cc=stranche-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=subashab-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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

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