RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Harald Welte <laforge-TgoAw6mPHtdg9hUCZPvPmw@public.gmane.org>
Cc: openbsc-qjLDD68F18N4m7O/Vxda39i2O/JbrIOy@public.gmane.org,
	radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Subash Abhinov Kasiviswanathan"
	<subashab-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"Dan Williams" <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"Bjørn Mork" <bjorn-yOkvZcmFvRU@public.gmane.org>,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Sean Tranchetti"
	<stranche-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"Aleksander Morgado"
	<aleksander-Dvg4H30XQSRVIjRurl1/8g@public.gmane.org>
Subject: Re: gsmtap design/extensions?
Date: Mon, 15 Apr 2019 11:26:22 +0200
Message-ID: <77ac708e198c8b04f45e47f53f63bd2f4ed006df.camel@sipsolutions.net> (raw)
In-Reply-To: <20190413073505.GD24451@nataraja>

Hi Harald,

> Agreed.  However, the protocol stacks on WiFi and cellular technologies
> are very different, to say the least.  There is no easy mapping of PHY
> related parameters to a given IP packet, and the related quality metrics
> of the radio channels don't work that way.

Sure. I'm (vaguely) aware of that.

> But yes, I agree, that whatever transport mechanism you wan to use between the modem
> and the user/Linux side should allow for additional, extensible metadata beyond
> the identifier of the PDP/PDN context.

Really the question it goes down to is whether there's possible overlap
here with GSMTAP or not.

If yes - we can define a GSMTAPv3, with TLVs or so, and add a "PDP/PDN
context" or "session" field or something like that, and maybe a tag that
says "IP packet is here", or some kind of "content type" field. I expect
there would be some such "sessions" that actually just transport the
local AT command chat.

If no, I guess we'll just define something else for this use case? Or,
perhaps, even get rid of it entirely and just rely on trace-cmd
recording or so, though then I guess we'd really want to teach libpcap
and/or wireshark to understand this in some way.

Though it almost sounds like in GSMTAP you're never actually
transporting IP data, but other types of packets that in turn transport
the (fragmented/compressed/encrypted) IP data. That would kinda mean
there's very little potential overlap.

> > This is the part I guess I don't understand. I haven't really tried, but
> > it seems you should be able to encapsulate arbitrary protocols into
> > 802.3 OUI-based ethertype or so?
> 
> But why?  I'm in an userspace program, and I want to send data to one or
> more other userspace programs.  Why would I not simply open a UDP socket
> to do so?  I would have to have CAP_NET_RAW and open a packet socket,
> and then generate ethernet frames from that?
> 
> I admit that the use case with wireshark is a bit odd, but there are
> other receivers out there.

Yeah, ok. I was thinking kinda the other way around - if all you need is
network transparency for wireshark it shouldn't matter, but that's
really discussed over in the other subthread with Guy Harris better.

Anyway it doesn't matter, and I'm beginning to understand that a (maybe
even the primary) use case is getting multiple parts of your stack to
talk to each other (over UDP).

> Yes, you're looking only at a single interface (the radio interface
> between one BSS and one STA).  You're not looking at five different
> interfaces at five different levels of network hierarchy/topology in the "wifi
> controller" and want to mix in a radio interface trace in the same
> timeline.

Indeed. Well, actually, we often do, but use different mechanics for
that (trace-cmd record comes to mind, it records all our driver/fw chat
as well as possibly adding in logging from wpa_supplicant etc.)

> > Basically, I was looking at it as if it was like WiFi in a sense - you
> > have an IP frame, you're going to transport it over some physical link,
> > so it gets PHY information in the sense of modulation etc.
> 
> As stated elsewhere, there's an M:N mapping between user (IP) payload
> and actual radio interface "MAC blocks", so I'm not aware of anyone
> mapping radio interface performance to user plane IP.

Right, OK.

> the "physical link info" is present in GSMTAP, but the granularity of
> GSMTAP frames is not user-IP frames, but "MAC blocks".  So your user IP
> frame might not be visible as it's still compressed, encrypted,
> fragmented, etc.

Sure. As Guy Harris pointed out, this is also true for wifi though - we
don't have compression, but certainly encryption & fragmentation,
wireshark was taught to handle that and recreate the original MSDU (mac
service data unit).

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
     [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 [this message]
     [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=77ac708e198c8b04f45e47f53f63bd2f4ed006df.camel@sipsolutions.net \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=aleksander-Dvg4H30XQSRVIjRurl1/8g@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=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