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]
Message-ID: <6590efa9-8fcd-5d77-9dff-6f2d1244cdb0@linux.intel.com>
Date:   Wed, 23 Mar 2022 23:06:55 +0530
From:   "Kumar, M Chetan" <m.chetan.kumar@...ux.intel.com>
To:     "loic.poulain@...aro.org >> Loic Poulain" <loic.poulain@...aro.org>,
        Sergey Ryazanov <ryazanov.s.a@...il.com>
Cc:     Johannes Berg <johannes@...solutions.net>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        "Sudi, Krishna C" <krishna.c.sudi@...el.com>,
        Intel Corporation <linuxwwan@...el.com>
Subject: Re: net: wwan: ethernet interface support


On 3/23/2022 10:36 PM, Loic Poulain wrote:
> On Sat, 19 Mar 2022 at 19:34, Sergey Ryazanov <ryazanov.s.a@...il.com> wrote:
>>
>> Hello,
>>
>> On Sat, Mar 19, 2022 at 6:21 PM Kumar, M Chetan
>> <m.chetan.kumar@...ux.intel.com> wrote:
>>> Release16 5G WWAN Device need to support Ethernet interface for TSN requirement.
>>> So far WWAN interface are of IP type. Is there any plan to scale it to support
>>> ethernet interface type ?
>>
>> What did you mean when you talked about supporting interfaces of Ethernet type?
>>
>> The WWAN subsystem provides an interface for users to request the
>> creation of a network interface from a modem driver. At the moment,
>> all modem drivers that support the WWAN subsystem integration create
>> network interfaces of the ARPHRD_NONE or ARPHRD_RAWIP type. But it is
>> up to the driver what type of interface it will create. At any time,
>> the driver can decide to create an ARPHRD_ETHER network interface, and
>> it will be Ok.
> 
> Agree, WWAN does not require a specific type, so you can do whatever
> you want in the newlink callback.
> 
> Should a modem/driver be able to expose mixed interface types (e.g. ip
> + eth), in that case we probably need to add extra param to newlink.

The wwan device which is complaint to 3GPP release16 specification (TSN 
supported) will have to create both the types of interfaces ARPHRD_RAWIP/ 
ARPHRD_NONE to carry default IP traffic and ARPHRD_ETHER for carrying TSN 
specific traffic.

Since both can co-exist can we consider this extra param added to newlink to 
distinguish
1> Ethernet interface creation from ip interface
2> Ethernet interface to session id mapping.

Kindly provide your inputs.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ