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]
Date:   Fri, 8 Jun 2018 12:21:51 +0200
From:   Daniele Palmas <dnlplm@...il.com>
To:     Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
        Bjørn Mork <bjorn@...k.no>
Cc:     Dan Williams <dcbw@...hat.com>, netdev@...r.kernel.org
Subject: Re: Qualcomm rmnet driver and qmi_wwan

Hi Dan and Subash,

2018-06-05 19:38 GMT+02:00 Subash Abhinov Kasiviswanathan
<subashab@...eaurora.org>:
> On 2018-06-05 08:54, Dan Williams wrote:
>>
>> On Tue, 2018-06-05 at 11:38 +0200, Daniele Palmas wrote:
>>>
>>> Hi,
>>>
>>> 2018-02-21 20:47 GMT+01:00 Subash Abhinov Kasiviswanathan
>>> <subashab@...eaurora.org>:
>>> > On 2018-02-21 04:38, Daniele Palmas wrote:
>>> > >
>>> > > Hello,
>>> > >
>>> > > in rmnet kernel documentation I read:
>>> > >
>>> > > "This driver can be used to register onto any physical network
>>> > > device in
>>> > > IP mode. Physical transports include USB, HSIC, PCIe and IP
>>> > > accelerator."
>>> > >
>>> > > Does this mean that it can be used in association with the
>>> > > qmi_wwan
>>> > > driver?
>>> > >
>>> > > If yes, can someone give me an hint on the steps to follow?
>>> > >
>>> > > If not, does anyone know if it is possible to modify qmi_wwan in
>>> > > order
>>> > > to take advantage of the features provided by the rmnet driver?
>>> > >
>>> > > In this case hint on the changes for modifying qmi_wwan are
>>> > > welcome.
>>> > >
>>> > > Thanks in advance,
>>> > > Daniele
>>> >
>>> >
>>> > Hi
>>> >
>>> > I havent used qmi_wwan so the following comment is based on code
>>> > inspection.
>>> > qmimux_register_device() is creating qmimux devices with usb net
>>> > device as
>>> > real_dev. The Multiplexing and aggregation header (qmimux_hdr) is
>>> > stripped
>>> > off
>>> > in qmimux_rx_fixup() and the packet is passed on to stack.
>>> >
>>> > You could instead create rmnet devices with the usb netdevice as
>>> > real dev.
>>> > The packets from the usb net driver can be queued to network stack
>>> > directly
>>> > as rmnet driver will setup a RX handler. rmnet driver will process
>>> > the
>>> > packets
>>> > further and then queue to network stack.
>>> >
>>>
>>> in kernel documentation I read that rmnet user space configuration is
>>> done through librmnetctl available at
>>>
>>> https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource
>>> /dataservices/tree/rmnetctl
>>>
>>> However it seems to me that this is a bit outdated (e.g. it does not
>>> properly build since it is looking for kernel header
>>> linux/rmnet_data.h that, as far as I understand, is no more present).
>>>
>>> Is there available a more recent version of the tool?
>
>
> Hi Daniele
>
> The attached patch should have an updated version of the tool.
> Usage -
>
> rmnetcli -n newlink wwan0 rmnet0 1 1
> where wwan0 is the physical device
> rmnet0 is the virtual device to be created
> 1 is the mux id
> the other 1 is the flag to configure DL de-aggregation by default
>
> To delete a device -
>
> ip link delete rmnet0
>
>>
>> I'd expect that somebody (Subash?) would add support for the
>> rmnet/qmimux options to iproute2 via 'ip link' like exists for most
>> other device types.
>
>
> Hi Dan
>
> Yes, I can do that and update the documentation to point to using iproute2.
>

I followed Dan's advice and prepared a very basic test patch
(attached) for testing it through ip link.

Basically things seem to be properly working with qmicli, but I needed
to modify a bit qmi_wwan, so I'm adding Bjørn that maybe can help.

Bjørn,

I'm trying to add support to rmnet in qmi_wwan: I had to modify the
code as in the attached test patch, but I'm not sure it is the right
way.

This is done under the assumption that the rmnet device would be the
only one to register an rx handler to qmi_wwan, but it is probably
wrong.

Basically I'm wondering if there is a more correct way to understand
if an rmnet device is linked to the real qmi_wwan device.

Thanks,
Daniele

>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

View attachment "0001-usb-net-qmi_wwan-add-support-for-rmnet-device.patch" of type "text/x-patch" (942 bytes)

View attachment "0001-ip-add-rmnet-initial-support.patch" of type "text/x-patch" (3606 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ