netdev - Re: Qualcomm rmnet driver and qmi

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

Subash Abhinov Kasiviswanathan <subashab@...eaurora.org> writes:

>> 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
>
>
> Hi Daniele / Bjørn
>
> Is it possible to define a pass through mode in qmi_wwan. This is to
> ensure that all packets in MAP format are passed through instead of
> processing in qmi_wwan layer. The pass through mode would just call
> netif_receive_skb() on all these packets.
>
> That would allow all the packets to be intercepted by the rx_handler
> attached by rmnet which would subsequently de-multiplex and process
> the packets.

This sounds like a good idea. I probably won't have any time to look at
this in the near future, though.  Sorry about that. Extremely overloaded
both at work and private right now...

But I trust that you and Daniele can work out something. Please keep me
CCed, but don't expect timely replies.


Bjørn