netdev - Re: gsmtap design/extensions?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net>
Date:   Wed, 10 Apr 2019 09:23:13 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Vadim Yanitskiy <axilirator@...il.com>
Cc:     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@...r.kernel.org,
        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?

On Wed, 2019-04-10 at 13:35 +0700, Vadim Yanitskiy wrote:
> Hello Johannes,
> 
> FYI, there already was a discussion about GSMTAPv3:
> 
> https://www.youtube.com/watch?v=vum9jzavZi0&list=PL07C78AF831FFE8F9&index=10
> 
> but unfortunately, nobody has invested time into this (yet?).

2012! But, umm, I don't really have time for a whole video right now -
anyone have the slides? :-)

But yeah, the first slides look sensible :-)

> > 1) Why the design with encapsulating it in UDP?
> 
> This gives us a possibility to "demux" multiple GSMTAP streams on the
> receiving side, e.g. if you are running multiple processes.

Not sure I get this, but I also don't really care all that much. It's
just a pretty strange design if the kernel were to output this, I'm not
even sure how I'd do that properly. I don't want to be generating UDP
packets there...

Perhaps we can define something (GSMTAPv3) to not really care how it's
encapsulated, and for 'native' packet captures like what I want on Linux
when integrated with the driver, actually use an ARPHDR_GSMTAP, and
encapsulate in UDP when you create it in an application and want to send
it elsewhere, rather than just writing it to a pcap file?

johannes