netdev - Re: [PATCH 3/3] qmi_wwan: Driver for WWAN devices requiring use of the QMI protocol

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, 16 Dec 2011 17:03:42 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Dan Williams <dcbw@...hat.com>
Cc:	netdev@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH 3/3] qmi_wwan: Driver for WWAN devices requiring use of the QMI protocol

Dan Williams <dcbw@...hat.com> writes:
> On Thu, 2011-12-15 at 11:02 +0100, Bjørn Mork wrote:
>
> But I agree that eventually the full QMI protocol should be made
>> available to userspace for other uses.  That should be fairly easy to do
>> if you just proxy the commands.  But I'm worring about the interface.
>> Is the /dev/qmi from GobiNet acceptable?  Why isn't it merged yet?
>
> It would have to be /dev/qmiX (in case you have more than one
> QMI-capable card in the system) and it would also have to have the right
> sysfs entries so that we could match the qmiX entry up with it's parent
> USB interface.  Not entirely sure how to do that.

The idea of creating multiple independent devices and then stitch them
together again using a sysfs API seems a little backwards to me.  How
about just use ioctls and forward both request and reply?  That won't
support unsolicited notifications, but otherwise it should be enough to
be useful.

The attached patch implements straight QMI forwarding.  Note that it is
only intended as a demo, and *not* a submission.  I have not yet decided
whether this is a good idea or not, and I assume that the API should
receive some more thought and blessings from others than me before
anything like this can be submitted.

It should maybe even be extended to something a little less
driver/device specific.  I believe a common WWAN API for settings things
like PIN code and APN would be very useful, in the same way the wireless
API has made WLAN usage possible without driver specific tools.

But anyway, the demo does work.  Using it to send this reqest for
firmware revision from userspace:

0000  01 0c 00 00 02 00 00 01  00 23 00 00 00

partly decoded as:

.tf = 0x01
.len = 0x000c
.ctrl = 0x00 control point
.service = 0x02
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x0001
.msgid = 0x0023
.len = 000000

I get the expected reply:

0000  01 4c 00 80 02 00 02 01  00 23 00 40 00 02 04 00
0010  00 00 00 00 01 36 00 4d  39 32 30 30 42 2d 53 43
0020  41 51 44 42 5a 44 2d 33  2e 30 2e 33 35 30 30 32
0030  35 54 20 20 31 20 20 5b  41 75 67 20 31 31 20 32
0040  30 31 31 20 30 32 3a 30  30 3a 30 30 5d

partly decoded as:

.tf = 0x01
.len = 0x004c
.ctrl = 0x80 service
.service = 0x02
.qmicid = 0x00
.flags = 0x02 response
.tid = 0x0001
.msgid = 0x0023
.len = 0x0040
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (54) 4d 39 32 30 30 42 2d 53 43 41 51 44 42 5a 44 2d 33 2e 30 2e 33 35 30 30 32 35 54 20 20 31 20 20 5b 41 75 67 20 31 31 20 32 30 31 31 20 30 32 3a 30 30 3a 30 30 5d   M9200B-SCAQDBZD-3.0.350025T  1  [Aug 11 2011 02:00:00]

This is while having an open connection and sending traffic over it (not
that that should matter, but anyway..)

> Huawei writes custom firmware for their dongles. 

Somehow I find that hard to believe.  I can believe that they *build* a
custom firmware, enabling a vendor specific set of options, setting
their own USB descriptors etc.  And maybe even write some vendor
specific feature.  But I would be surprised if most of their firmware
code didn't come directly from the chipset vendor example code.

And the same goes for every other dongle maker.

> Gobi devices and other
> devices that talk QMI don't  necessarily have such a full quite of AT
> commands, yet they all talk the same QMI protocol.  It makes sense to
> have a generic driver for this if we can.  That probably means a QMI
> core (like you've got with the qmi_wwan stuff) and device-specific
> drives.  The Huawei device would use the ECM-like stuff while the Gobi
> bits would implement what gobi_net does.  They might even be almost the
> same, I haven't looked in a while.  But they are similar enough that
> they should be sharing most of the code.

Yes, I absolutely agree. That's why I tried to keep the qmi specific
code as driver agnostic as possible.  Well, I could probably have done
better, but it's a start..

Bjørn

View attachment "0001-qmi_wwan-allow-QMI-proxying-via-netdev-ioctl.patch" of type "text/x-diff" (7561 bytes)