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] [day] [month] [year] [list]

Date:   Mon, 15 Apr 2019 12:41:42 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Vadim Yanitskiy <axilirator@...il.com>,
        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 <netdev@...r.kernel.org>,
        "open list:NFC SUBSYSTEM" <linux-wireless@...r.kernel.org>,
        Aleksander Morgado <aleksander@...ksander.es>,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
Subject: Re: gsmtap design/extensions?

On Mon, 2019-04-15 at 12:29 +0200, Bjørn Mork wrote:
> 
> I don't understand where you are going here? Neither QMI, AT command nor
> MBIM management are transported over netdevs. AT is usually transported
> using simple USB bulk streams, exported to userspace as tty devices by
> some USB serial driver.  Both QMI and MBIM management are transported as
> USB control messages, and exported to userspace as chardevs.  There are
> no netdevs involved.

OK. I've also been looking at a driver for Intel modems, and I think it
works that way.

> > and people do things like "socat" to set up
> > PTYs and pretend to have serial channels there, on top of the netdevs?
> 
> I assume you are referring to my MBIM DSS examples here.

I was more thinking of what I've been told the Intel modem does,
actually. But that in turn might very well be inspired by what you
documented there. I think the folks doing this were just trying to make
it work and nobody really understands the whole landscape.

> I don't know
> if anyone is actually using that, so you should probably ignore it...
> I'll happily admit it was a bad idea.  Should have just added the
> necessary code to map DSS channels to some sort of character device in
> the driver, like most users requested.

OK. So I guess a framework should consider that possibility, and let you
create new chardevs for a given (DSS) channel?

> But there really isn't anything in the MBIM spec saying how DSS should
> be used. DSS is a generic data stream.  Could easily be connected to a
> single TCP session for example, in which case you'd probably want to
> connect it to a TCP session in the other end too.  So I wouldn't want to
> force DSS into character devices on the host end.  

Fair point.

I suppose some of these may also be debug channels that give you modem
debug information, which is useful (if you can interpret it).

> This doesn't rule out
> a userspace controlled optional mapping though. We could probably still
> add that, replacing the VLAN mapping with a chardev for a specific DSS
> session if requested by userspace.  I guess this is something to
> consider for a generic cellular framework - supporting non-ip data
> streams between modem and host.

Right.

> Adding to my previous excuses: The DSS implementation in the cdc_mbim
> driver was added without having seen a single modem firmware with *any*
> type of DSS support.  It was purely based on spec{ification,culation}.
> The VLAN mapping, along with examples of how to use socat to further map
> the streams from VLANs into suitable application specific forms, seemed
> like a simple and flexible enough solution.

:-)

johannes