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: <20190413064152.GB24451@nataraja>
Date:   Sat, 13 Apr 2019 08:41:52 +0200
From:   Harald Welte <laforge@...monks.org>
To:     Guy Harris <guy@...m.mit.edu>
Cc:     Johannes Berg <johannes@...solutions.net>,
        Vadim Yanitskiy <axilirator@...il.com>,
        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>, 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?

Dear Guy and others,

On Fri, Apr 12, 2019 at 03:47:26PM -0700, Guy Harris wrote:
> On Apr 12, 2019, at 12:54 PM, Guy Harris <guy@...m.mit.edu> wrote:
> 
> > I see nothing about a struct gsmtap_hdr:
> > 	http://osmocom.org/projects/baseband/wiki/GSMTAP
> > that...
> > 	2) would prevent it from being at the beginning of a LINKTYPE_GSMTAP/DLT_GSMTAP packet in a pcap or pcapng file.
> With a specification based on
> 	http://cgit.osmocom.org/libosmocore/plain/include/osmocom/core/gsmtap.h

I completely agree that there is no technical reason why one couldn't put GSMTAP
headers in current (v2) or future formats inside an ETHERTYPE / DLT and have
them natively appearing in a pcap file of the given DLT.  There would be no objections
from my side to do so.

One could then simply call the same dissector in wireshark from that DLT or from
the existing UDP port number based dispatch via the IANA-registered GSMTAP port
number.

However, among the existing users of GSMTAP in the last decade or so,
there would be no advantage, as the related sources of GSMTAP frames all
exist in userspace and are feeding data, particularly from potentially
multiple sources, which can very well run on different hosts.

But that of course doesn't prevent new users from using different
transport mechanisms of getting GSMTAP from e.g. the kernel into
userspace.

Regards,
	Harald
-- 
- Harald Welte <laforge@...monks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ