netdev - Re: cellular modem driver APIs

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: <7980f3d8a567a16f94e03b4c90f14362fc901560.camel@sipsolutions.net>
Date:   Fri, 12 Apr 2019 14:01:58 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
Cc:     Dan Williams <dcbw@...hat.com>,
        Bjørn Mork <bjorn@...k.no>,
        netdev@...r.kernel.org, Sean Tranchetti <stranche@...eaurora.org>,
        Daniele Palmas <dnlplm@...il.com>,
        Aleksander Morgado <aleksander@...ksander.es>,
        netdev-owner@...r.kernel.org
Subject: Re: cellular modem driver APIs

On Wed, 2019-04-10 at 21:54 -0600, Subash Abhinov Kasiviswanathan wrote:

> > > We need raw IP frames from a embedded device transmitted to a PC
> > > and vice versa.
> > 
> > Sure. But you just need to encap them in some kind of ethernet frame to
> > transport them on the wire, but don't really need to care much about
> > how.
> > 
> 
> These packets will be processed as raw IP muxed frames on the PC as 
> well, not as ethernet though.

But in order to transport them, they're always encapsulated in ethernet?

> Currently, iproute2 can be used to add the underlying dev as real_dev 
> and create rmnet links over it (ip link add link rmnet_ipa0 name rmnet0 type 
> rmnet mux_id 1). Would this continue to work if -
> 1. the rmnet library were to be included directly as part of the 
> underlying driver itself
> 2. there is no underlying dev at all

Yeah, this is the big question.

If there's no underlying netdev at all, then no, it wouldn't work.
Though, it could be "faked" in a sense, by doing two things:

a) having the driver/infra always create a default channel interface,
   say mux_id 0?
b) by treating

	ip link add link rmnet_ipa0 name rmnet0 type rmnet mux_id 1

   as not creating a new netdev *on top of* but rather *as sibling to*
   "rmnet0".

The alternative is to just keep rmnet and the underlying driver, but tie
them together a little more closely so that they can - together -
register with a hypothetical new WWAN framework.

See - even if we create such a framework in a way that it doesn't
require an underlying netdev (which I think is the better choice for
various reasons, particularly related to 5G), then there's nothing that
says that you *cannot* have it anyway and keep the exact same rmnet +
underlying driver model.

> One additional use of underlying netdev is for RPS.
> This helps to separate out the processing of the underlying netdev and
> rmnet. If rmnet were to be converted into a library, we would still need
> this functionality.

Hmm, not sure I understand this. If you do RPS/RSS then that's a
hardware function, and the netdev doesn't really come into play
immediately? If the underlying driver directly deals with multiple
netdevs that's actually an *advantage*, no?

johannes