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 11:19:32 -0600
From:   Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
To:     Daniele Palmas <dnlplm@...il.com>
Cc:     Bjørn Mork <bjorn@...k.no>,
        Dan Williams <dcbw@...hat.com>, netdev@...r.kernel.org
Subject: Re: Qualcomm rmnet driver and qmi_wwan

> 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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ