netdev - Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8

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: <87mv3bilf4.fsf@miraculix.mork.no>
Date:   Fri, 24 Nov 2017 19:25:19 +0100
From:   Bjørn Mork <bjorn@...k.no>
To:     Reinhard Speyerer <rspmn@...or.de>
Cc:     netdev@...r.kernel.org, oliver.graute@...il.com
Subject: Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8

Reinhard Speyerer <rspmn@...or.de> writes:

> before posting this problem report
> https://developer.gemalto.com/threads/ipv6dualstack-problems-pls8-e-revision-03017
> in the Gemalto developer forum I tested the qmi_wwan/cdc_ether changes
> you suggested above and apart from having two working QMI interfaces
> the IPv6/dualstack problems observed with AT^SWWAN/cdc_ether were
> also gone when using WDSStartNetworkInterface and the QMI interface in
> raw IP mode instead.

Right. I did not know about the "carrier off" issue. But messed up
ethernet headers is a well known problem with all these Qualcomm based
modems. Switching them to raw IP mode is often the only way to make them
work consistently.

Having seen this problem with multiple vendors, where some even have
borrowed our workarounds for their own out-of-tree drivers, makes me
pretty sure that it isn't easily fixable. It's a Qualcomm bug, and I
guess no one is allowed to even look at the code.  Much less change it.
Which makes sense given the mess it must be...

> Unfortunately Gemalto does no seems to be willing to provide an
> alternative USB composition which includes QMI interfaces for the
> PLS8. Therefore applying the above changes to qmi_wwan/cdc_ether might
> make the PLS8 network interfaces stop working when Gemalto decides to
> replace their f_rmnet gadget in CDCECM mode with a f_ecm gadget when
> releasing a firmware update.

I don't think this is necessarily a problem. Only the QMI control
channel will stop working should this happen.  The qmi_wwan driver will
provide the same network device support as cdc_ether, using CDC ECM
framing.

And to be honest, such a redesign of the modem application for a mature
product is very unlikely, isn't it?  Why would Gemalto want to do all
that extra work, taking the risks involved?  For what possible purpose?
This is probably the reason they don't want to mess with alternative USB
compositions either.

In any case, I think it is worth adding this device to qmi_wwan if it
works with current firmwares and you, or anyone else, finds it useful.
And it does sound like that based on the IPv6 issues you mention..

But I'll leave the decision to you or anyone else with such a device.

Bjørn